GamerAM: Техническое собеседование

Сначала уточните бизнес-цель, действие в продукте, текущий baseline, пользователей, данные, метрику успеха и цену ошибок. Потом проверьте, нужен ли ML вообще, или задачу дешевле закрыть правилами, аналитикой или продуктовым изменением.

Начинать нужно с перевода идеи в измеримое решение: что именно должно измениться в продукте, кто пользователь решения, какое действие будет принимать система и какая метрика должна сдвинуться. Если формулировка размытая, надо отдельно уточнить baseline, ограничения, источники данных, момент принятия решения и то, как будут получаться labels.

Дальше проверяется реализуемость: есть ли сигнал в данных, не возникает ли leakage, можно ли наблюдать target до момента решения, насколько дорого ошибаться и какой no-ML baseline уже есть. Часто правильный первый шаг - не модель, а быстрый data audit или простое правило, чтобы понять масштаб эффекта.

Хороший итог такого обсуждения - короткая спецификация: objective metric, guardrails, label definition, candidate data sources, первый baseline, способ валидации и план rollout/A-B теста. Если данных или product value не хватает, это тоже нормальный результат: лучше остановиться рано, чем строить модель для плохо поставленной задачи.

Отталкивайтесь от поверхности продукта и доступных сигналов. Обычно нужен простой baseline, затем двухэтапная схема: candidate generation для recall и reranking/business rules для точности, разнообразия и ограничений.

Сначала фиксируется продуктовая поверхность: feed, matching, похожие товары, игры, подборки или другая рекомендация. От нее зависят labels, окно истории, negative sampling, offline metrics и guardrails. Для новой системы полезно начать с простого baseline: популярное, item-to-item, content-based похожесть или ручные правила.

Практичная архитектура обычно двухэтапная. Candidate generation достает сотни или тысячи кандидатов через collaborative signals, content embeddings, item-to-item similarity, graph methods, popularity или user history. Reranker дальше использует более тяжелые признаки, business constraints, diversity, freshness и safety rules.

Самая рискованная часть - данные. Нужны interaction logs, exposure logs, user/item attributes, timestamps и понятное определение positive/negative. Для холодного старта систему можно запускать через контентные признаки, popularity и exploration, а затем улучшать на online feedback.

Разделите сбор данных, training, validation, inference и publish на отдельные idempotent tasks. CPU-heavy подготовку и GPU-heavy обучение держите в разных контейнерах, версионируйте артефакты и мониторьте freshness, длительность, ресурсы и качество.

ML DAG лучше строить как набор явных стадий: extract, validate, feature/build dataset, train, evaluate, offline inference, publish и notify. Подготовка данных обычно CPU/Spark-heavy, а training или embedding inference требуют GPU, поэтому эти стадии не должны держать один и тот же дорогой ресурс.

Каждая стадия должна писать явный артефакт: датасет, feature snapshot, checkpoint, метрики, prediction file, manifest или publish marker. Это делает retries безопаснее и позволяет откатиться к предыдущей версии. Для регулярного переобучения важно не только запустить модель, но и проверить, что свежие данные реально дошли, схемы совместимы, а метрики не просели.

Оптимизация идет через partitioning, chunk-level parallelism, кэширование повторно используемых данных, контроль concurrency и устранение лишних shuffle/IO. Monitoring должен показывать duration по task, queue time, freshness, row counts, artifact sizes, GPU usage, failed publishes и model quality regression.

Публикуйте model artifacts и predictions как версионированные артефакты: пишите в новый путь, валидируйте counts/coverage/metrics, затем атомарно переключайте active pointer или manifest. Consumers должны уметь читать только активную версию и откатываться.

Offline serving - это не просто “модель посчитала файл”. Нужно договориться о publish contract: куда пишутся предсказания, какая схема, как backend понимает активную версию, как проверяются полнота и свежесть, что происходит при partial failure. Для рекомендаций это может быть DWH/table, Redis/KV, vector index или manifest в object storage.

Безопасный паттерн: записать данные в versioned path, прогнать validation, проверить row counts, coverage пользователей/items, метрики и размер артефакта, а затем переключить маленький pointer или manifest. Online service не должен читать файлы, которые еще пишутся. Для модели отдельно хранят checkpoint, feature schema, preprocessing version, training snapshot и совместимость с consumer code.

После публикации нужны monitoring и rollback: freshness, missing users/items, latency чтения, fallback rate, business KPI и версия активного артефакта. Если новая версия плохая, откат должен быть переключением pointer на предыдущую, а не ручным поиском старых файлов.

Выбор зависит от latency, recall, масштаба, update pattern, фильтров, memory cost и того, кто будет поддерживать инфраструктуру. Проверять нужно recall@K против exact search, p95 latency, build/update time, memory и downstream candidate coverage.

Сначала формулируется access pattern: сколько vectors, какой K, какой QPS, нужны ли filters, как часто обновляются embeddings, нужна ли persistence, GPU или CPU, batch search или online запросы. FAISS силен для high-performance ANN и GPU/batch сценариев. HNSW на CPU часто удобен для low-latency retrieval. Vector DB вроде Qdrant добавляют persistence, filters и operational API. Redis хорош, если уже используется как low-latency store. Elasticsearch полезен, когда vector search надо смешать с text search и фильтрами.

Сравнивать нужно эмпирически. Берем exact nearest-neighbor sample как baseline и меряем recall@K, p95/p99 latency, memory, build time, update cost и degradation при фильтрах. Для рекомендаций отдельно смотрим candidate coverage и downstream ranking/online metrics, потому что ANN recall сам по себе не гарантирует хороший продукт.

Для HNSW важны M, efConstruction и efSearch: они двигают trade-off memory/build time/recall/latency. Distance metric должна соответствовать обучению embedding: cosine для normalized vectors, dot product или L2 - если так задан objective.

Классический Redis выполняет команды для shard через single-threaded event loop: одна команда меняет in-memory состояние до конца, потом берется следующая. Но multi-command workflow все равно требует Lua, MULTI/EXEC, WATCH или idempotency.

Redis хранит данные в памяти и обрабатывает команды последовательно в event loop. Поэтому отдельная команда вроде SET, HSET или INCR не interleave-ится с другой mutating командой и выглядит атомарной для клиента. Это объясняет, почему простые операции не создают race внутри одного shard.

Но из этого не следует, что любой бизнес-процесс автоматически консистентен. Если клиент делает read-modify-write несколькими командами, между ними может вмешаться другой клиент. Для таких случаев нужны atomic commands, MULTI/EXEC, Lua scripts, optimistic locking через WATCH или application-level idempotency.

В распределенном Redis дополнительно появляются replication lag, failover и cluster sharding. Single-threaded execution объясняет локальную атомарность команды, но не решает все вопросы consistency между репликами и shard-ами.

RDD - низкоуровневая распределенная коллекция, DataFrame - таблица со схемой и оптимизацией Catalyst/Tungsten, Dataset добавляет типизированный API в JVM. Repartition делает shuffle под новое число партиций, coalesce чаще дешевле уменьшает число партиций, cache/persist материализуют переиспользуемые данные.

RDD дает низкоуровневый контроль над распределенной immutable-коллекцией, но Spark хуже понимает структуру вычисления. DataFrame представляет данные как таблицу со схемой и операциями над колонками, поэтому Catalyst может оптимизировать logical plan: проталкивать фильтры, убирать лишние колонки, переупорядочивать join-ы, выбирать физический план и генерировать код. Dataset в основном важен для Scala/Java как типизированный API поверх оптимизируемого плана.

DataFrame обычно быстрее не потому, что у него “есть индексы как в базе”, а потому что Spark видит колонки, predicates, aggregations и joins. Это позволяет убирать лишнюю работу и эффективнее исполнять пайплайн.

Repartition создает новое распределение партиций и обычно вызывает shuffle; его используют для увеличения параллелизма, перераспределения skew или подготовки к join/aggregation. Coalesce чаще уменьшает число партиций с меньшим shuffle, например перед записью. Cache и persist нужны только для переиспользуемых промежуточных данных; persist позволяет выбрать storage level: memory, disk, serialized.

GIL не дает нескольким потокам одновременно исполнять Python bytecode в CPython. Потоки полезны для I/O, процессы - для вычислительных Python-задач. Память в CPython в основном освобождается подсчетом ссылок, а циклический сборщик мусора добирает циклы ссылок.

GIL защищает внутреннее состояние интерпретатора CPython, поэтому несколько Python-потоков не исполняют Python bytecode параллельно. Это не значит, что потоки бесполезны: они хорошо подходят для ожидания сети, диска, базы данных и native extensions, которые отпускают GIL.

Для CPU-bound pure Python задач лучше использовать multiprocessing, векторизованные native libraries, compiled extensions или распределенное выполнение. Multiprocessing запускает отдельные процессы интерпретатора с отдельной памятью, поэтому использует несколько ядер, но платит за сериализацию, IPC и memory overhead.

CPython освобождает большинство объектов через подсчет ссылок: когда счетчик ссылок падает до нуля, объект можно удалить. Отдельно есть циклический сборщик мусора для циклов ссылок, которые подсчет ссылок сам не разорвет. В других runtime встречаются tracing collectors: mark-and-sweep, generational GC и похожие схемы.

Офлайн-эксперимент проверяет модель на исторических данных, но онлайн A/B нужен для оценки продуктового эффекта. До запуска фиксируют основную метрику, охранные метрики, MDE, alpha/power, длительность и долю трафика; после запуска смотрят статистическую значимость, сегменты и возможное взаимное влияние пользователей.

Офлайн-эксперимент полезен для быстрой фильтрации моделей: метрики ранжирования и поиска, регрессионный набор, задержка и стоимость. Но он не доказывает продуктовый эффект, потому что исторические логи собраны старой политикой выдачи. Для новой рекомендации нужен онлайн A/B или аккуратная выкатка.

Перед A/B фиксируют гипотезу, основную метрику, охранные метрики, MDE, alpha, power, долю трафика, длительность и правила остановки. MDE нужен, чтобы понять, какой минимальный эффект реально обнаружить при доступном трафике и дисперсии. p-value сам по себе не отвечает на вопрос бизнес-важности эффекта.

Для социальных и рекомендательных продуктов важны сетевые эффекты и взаимное влияние пользователей: изменение выдачи одному пользователю может менять поведение другого, экспозицию поставщиков контента или экосистему авторов. Поэтому нужны охранные метрики: удержание, жалобы и репорты, разнообразие и покрытие, задержка, качество совпадений, долгосрочные метрики и сегментный анализ.

Офлайн-подход подходит для тяжелых моделей, больших наборов признаков и заранее посчитанных списков кандидатов. Онлайн-инференс нужен для свежего контекста, но требует бюджета по задержке/RPS, легких моделей, кеширования и ограниченного числа кандидатов.

В рекомендациях часто есть несколько семейств подходов: popularity/item-to-item, collaborative filtering, content-based embeddings, graph models, two-tower retrieval, transformer/sequential models и reranking. Production-архитектура обычно делит систему на генератор кандидатов и reranker.

Выбор между онлайн- и офлайн-частью начинается со свежести и задержки. Offline precompute позволяет использовать тяжелые модели, посчитать эмбеддинги и признаки заранее, сделать сложные reranking heuristics и положить результат в DWH, KV-хранилище или vector index. Но он хуже реагирует на текущую сессию, новые объекты и быстрые изменения интересов.

Онлайн-инференс дает свежий контекст, но ограничен p95 latency, RPS, памятью и стоимостью. Поэтому в online часто берут легкие модели, маленькие наборы кандидатов, кеширование, approximate retrieval, feature store и graceful fallback. Хороший ответ на интервью должен явно назвать бюджет по задержке и объяснить, какие признаки и модели можно перенести в офлайн.

В RecSys граф обычно строится из user-item или item-item interactions. GCN агрегирует признаки соседей слоями по графу, а GraphSAGE учит агрегатор и sampling соседей, что удобнее для больших и новых графов.

Графовая постановка в рекомендациях появляется естественно: users, items, games, posts или tags становятся nodes, а interactions - edges. Разные типы действий можно хранить как разные edge types или графы. Цель - получить embeddings, которые учитывают не только признаки объекта, но и структуру соседей.

GCN делает message passing: на каждом слое node агрегирует информацию от соседей, поэтому после нескольких слоев representation содержит более широкий graph context. GraphSAGE похож по духу, но делает sampling соседей и учит aggregation function, поэтому лучше масштабируется на большие графы и может работать inductively для новых nodes с признаками.

Для рекомендаций важно сравнивать такие модели с простыми baselines: item-to-item, matrix factorization, two-tower, sequential/transformer recommender. Графовая модель не обязана выиграть, если interactions sparse, граф шумный или latency/complexity слишком высоки.

Receptive field - область входа, влияющая на output activation. При stride 1 две последовательные 3x3 свертки дают effective receptive field 5x5, но параметров меньше: 18C^2 против 25C^2 для одинаковых channels без учета bias.

Receptive field показывает, какую область исходного входа “видит” конкретная activation после одного или нескольких слоев. У одной 5x5 convolution при stride 1 receptive field равен 5x5. У одной 3x3 - 3x3.

Если поставить две 3x3 свертки подряд со stride 1 и padding, effective receptive field становится 5x5: каждый output второго слоя зависит от 3x3 activation первого слоя, а каждая из них зависит от своего 3x3 окна во входе. Если stride больше 1 или есть dilation, формула меняется.

По параметрам две 3x3 часто легче одной 5x5 при одинаковом числе input/output channels: 2 * 3 * 3 * C * C = 18C^2 против 25C^2. Плюс между двумя слоями можно поставить nonlinearity, что повышает выразительность.

Для нового пользователя можно начать с popular/trending, onboarding interests, демографических или контекстных признаков, похожих пользователей и content-based candidates. Затем быстро обновлять рекомендации по первым просмотрам, лайкам и пропускам.

Cold start означает, что у пользователя или item мало истории. Для нового пользователя базовый fallback - popular или trending content, но он быстро усиливает popularity bias. Лучше добавить onboarding: выбранные игры/жанры, язык, регион, platform, explicit dislikes или несколько стартовых вопросов.

User-based подход использует похожих пользователей по meta attributes или ранним событиям. Item/content-based подход использует признаки постов: game tag, текст, image embeddings, creator, language, freshness. Для ленты практично смешивать несколько источников кандидатов и давать exploration, чтобы быстро собрать индивидуальный сигнал.

После первых interactions систему надо быстро адаптировать: session features, recent likes/skips, dwell time, negative feedback. Важно не путать unseen с negative и не переобучать cold-start блок на старых heavy users, у которых уже много истории.

Борьба с overfitting: регуляризация, early stopping, контроль емкости модели, больше качественных данных, аугментации, корректный validation split и проверка leakage. Синтетика опасна, если не похожа на real distribution.

Классический набор против переобучения: L1/L2 или weight decay, dropout, early stopping, уменьшение capacity, data augmentation, больше real data, аккуратные features и проверка leakage. Для деревьев и бустинга это depth, min samples, learning rate, subsampling и регуляризация листьев; для нейросетей - weight decay, dropout, augmentation, normalization как optimization helper и validation-based early stopping.

Синтетические данные могут помочь, но опасны distribution mismatch: модель учится на артефактах генератора, которых нет в продакшене. Поэтому синтетику надо валидировать отдельно, смешивать осторожно, смотреть метрики на real validation/test и проверять slice quality.

Validation split нужен для оценки качества на unseen data, выбора hyperparameters, thresholds и момента early stopping. Split должен повторять production setting: time-based для временных задач, group/user split для избежания leakage, одинаковая population и label availability.

Переписывание оправдано, если техдолг измеримо ломает надежность, скорость разработки, стоимость эксплуатации или business-critical SLA сильнее, чем стоит миграция. По умолчанию лучше incremental migration с метриками, ownership и rollback.

Решение о rewrite должно начинаться с измеримого ущерба: частые incidents, невозможность деплоить модели, отсутствие monitoring, высокая latency/cost, долгий onboarding, постоянные ручные операции, плохая testability или риск для critical business path. “Код некрасивый” сам по себе не аргумент.

Нужно сравнить стоимость текущего состояния со стоимостью миграции: сколько developer time уходит на поддержку, какие product initiatives блокируются, насколько сложно обеспечить compatibility и кто будет владеть новой платформой. Если система стабильна и редко меняется, точечные улучшения могут быть дешевле.

Безопасный путь - не big bang, а strangler pattern: выделить target interfaces, обернуть старый сервис, перенести один workflow, запустить old/new параллельно, сравнить метрики и держать rollback. Success criteria должны быть заранее: latency, failure rate, deployment frequency, incident time, model rollout time или cost.

Подходит two-tower/siamese или metric learning: кодируем каждого пользователя, оцениваем пару через dot/cosine или learned head. Target лучше строить не только по односторонним лайкам, а по взаимному match, диалогу, ответу или другому mutual outcome с учетом exposure bias.

Для user-to-user matching естественны two-tower или siamese architectures: одна сеть кодирует каждого пользователя в общее пространство эмбеддингов, а пары оцениваются dot product, cosine similarity или небольшим interaction head. Loss может быть contrastive, triplet, sampled softmax/BPR-style ranking или binary cross-entropy по парам.

Ключевой вопрос - что считать positive. Односторонний лайк удобен, но может оптимизировать показ “самых желанных” профилей и ухудшить взаимный результат. Лучше смотреть mutual match, reply, conversation start, meaningful interaction, retention или взвешенный target из нескольких событий. Негативы должны учитывать exposure: если пользователь не видел профиль, это не настоящий negative.

В serving нужны ограничения: география, активность, safety, diversity, freshness, exposure caps и exploration. Для matching особенно важно не только “кого я хочу лайкнуть”, но и вероятность взаимного результата и качество пары для обеих сторон.

При сильных ресурсах можно использовать VLM/CLIP-style проверку image-text-tag consistency. При ограниченных ресурсах - каскад дешевых признаков: текст, OCR, image embeddings, tag metadata, lightweight classifier и human review для спорных случаев.

Задача - проверить consistency между заявленным tag и содержимым поста. Если доступны сильные multimodal models, можно подать image, text и tag в VLM или CLIP-like модель и получить score соответствия. Такой слой хорош для bootstrap labels, hard cases и объяснений для модерации, но дорог для каждого поста.

При ограниченных ресурсах нужен каскад. Сначала cheap filters: нормализация текста, язык, TF-IDF/char n-grams, compact BERT embeddings, OCR, lightweight image embeddings, metadata автора и tag history. Затем classifier решает “tag matches content” или отправляет uncertain cases на ручную проверку. Для новых игр и мемов нужен drift monitoring и регулярное обновление словаря/labels.

Важно учитывать цену ошибок. False positive удаляет нормальный контент, false negative портит рекомендации и модерацию. Поэтому threshold выбирают по precision/recall и cost, а не только по accuracy.