Вопросы на собеседовании: ML-инженер

Я бы начал с LightGBM, потому что это табличные данные средней ширины, а latency budget поощряет сильный и дешёвый baseline.

• Используется time-based split, native handling пропусков и categorical encodings, обученные только на training folds; отчёт включает PR-AUC и recall при мощности retention-команды.
• Модель из 1 000 деревьев часто выдаёт score за 1-3 мс на CPU, оставляя место для feature lookup внутри 10 мс.
• Neural model стоит тестировать, только если error analysis показывает обучаемые high-order interactions или embeddings дают прирост PR-AUC, оправдывающий latency и tuning cost.

Я бы использовал два этапа: дешёво получил несколько сотен candidates, затем rerank с богатым контекстом пользователя и товара.

• Item embeddings вычисляются заранее, а ANN index вроде ScaNN или FAISS получает около 500 candidates за 20 мс.
• Компактная ranking model оценивает эти 500 менее чем за 45 мс, 20 мс остаётся features и 35 мс сети и tail variance.
• Оцениваются retrieval recall@500, ranking NDCG@20, catalog coverage и online click или conversion lift, потому что хороший reranker не вернёт потерянные candidates.

Я бы начал с MobileNetV3 или EfficientNet-Lite и оптимизировал её на целевом телефоне, а не вслепую уменьшал server model.

• Training идёт на минимальном resolution, сохраняющем нужные классы, а export содержит только operators, поддерживаемые Core ML или TensorFlow Lite.
• INT8 quantization проверяется на representative calibration set с измерением model size, top-1 accuracy, p95 latency, memory и battery use на слабых устройствах.
• Если INT8 теряет больше 1 пункта, применяется quantization-aware training или distillation от крупного teacher до увеличения архитектуры.

Я бы сравнил TF-IDF linear model и небольшой distilled transformer до выбора полного BERT.

• Linear baseline даёт понятные per-label errors и обрабатывает больше 1 млн tickets в день внутри 15 мс на CPU.
• DistilBERT или MiniLM оправдан, только если macro-F1 редких intent labels растёт заметно, например с 0,71 минимум до 0,76.
• Full BERT плох как default, если требует GPU serving ради неприменимого прироста; я сравню cost per million tickets вместе с F1.

Я бы использовал global model, потому что общие сезонные и товарные сигналы дают sparse series больше статистической силы.

• Backtest делается rolling origins за последние 12 недель с weighted quantile loss по объёму и cold-start cohort.
• Product ID embeddings, price, promotion, calendar и stock status позволяют одному LightGBM, DeepAR или Temporal Fusion Transformer делить patterns между рядами.
• Seasonal-naive forecasts остаются fallback, а global model отклоняется, если не превосходит их на low-history products и aggregate inventory cost.

Я бы дал быстрой модели отвечать на уверенных примерах, а медленную вызывал только для uncertain cases.

• Fast model калибруется, а два confidence thresholds выбираются на validation data так, чтобы escalated traffic составлял около 20%.
• Ожидаемое model time равно 2 мс плюс 0,20 умножить на 45 мс, то есть 11 мс без routing overhead.
• Оцениваются end-to-end accuracy, escalation по cohorts, p99 latency и cost; distillation может быть проще, если slow path создаёт нестабильные хвосты.

Я бы выпустил ensemble, только если дополнительные 4 пункта recall покрывают стоимость, а модели действительно ошибаются по-разному.

• Измеряются pairwise error correlation и recall при одинаковой мощности false-positive review, а не три headline AUC.
• Parallel и sequential execution проверяются против p99 budget, а также считается стоимость каждого дополнительного предотвращённого fraud case.
• Если ensemble полезен, но дорог, его soft outputs distill в одного student с требованием recall в пределах 1 пункта от 82%.

Я бы протестировал shared encoder с task-specific heads, потому что малые tasks могут выиграть от задачи с 10 млн labels.

• Tasks сэмплируются явно, чтобы крупнейший dataset не доминировал каждый update, а loss weights настраиваются по gradient scale и validation behavior.
• Каждая task сравнивается со single-task baseline, особенно на negative transfer для labels с конфликтующим смыслом.
• Отдельные модели сохраняются, если две tasks теряют больше согласованного guardrail 1 F1 point или требуют несовместимых serving cadences.

Я бы использовал supervised learning там, где labels покрывают нужные failure modes, а anomaly detection для новых или неразмеченных отклонений.

• Time-based test set содержит все подтверждённые failures и representative normal operation, а отчёт показывает recall при фиксированном daily alert budget вместо accuracy.
• Gradient-boosted trees изучают известные failure modes с cost-sensitive loss, а autoencoder или isolation forest предлагает незнакомые cases для review.
• Hybrid route направляет на inspection высокий supervised risk или anomaly score, но thresholds калибруются под capacity команды, например 200 alerts в день.

Я бы ранжировал по incremental treatment effect, потому что высокая purchase probability не доказывает, что покупку вызвала скидка.

• На eligible holdout выполняется randomization, а uplift model обучается на treatment, outcome и pre-treatment features без post-offer leakage.
• Оцениваются uplift или Qini curves и incremental profit в top 5% с учётом discount cost, а не ROC-AUC.
• При слабом overlap или малом experiment используется сама randomized policy вместо нестабильной observational estimate, выдаваемой за causal.

Effective batch равен 4 096 примерам, поэтому я проверю optimization на таком batch до принятия throughput gain.

• Расчёт: 32 GPU умножить на 64 примера и на 2 accumulated microbatches на optimizer step.
• DDP усредняет gradients между ranks, а loss normalization, clipping и learning-rate schedule двигаются по optimizer step, не microbatch.
• Я протестирую linear learning-rate scaling с warm-up, затем сравню time to target validation score, потому что 32x hardware редко даёт 32x полезную convergence.

Plain DDP недостаточно, потому что каждый rank держал бы около 208 ГБ mixed-precision parameters, gradients и AdamW state ещё до activations.

• DDP повторяет это состояние на каждой GPU, поэтому один activation checkpointing не поместит его в 80 ГБ.
• PyTorch FSDP FULL_SHARD или ZeRO-3 распределяет parameters, gradients и optimizer state по 64 ranks.
• Я оберну transformer blocks, использую BF16 и сравню all-gather overhead и tokens per GPU-second, а не выберу maximum sharding без измерений.

Я бы оставил communication-heavy tensor parallelism внутри каждого NVLink-узла из восьми GPU, а data или pipeline parallelism использовал между узлами.

• 8-way tensor-parallel group не отправляет collectives каждого layer через более медленный inter-node fabric.
• Pipeline stages добавляются, только если один узел не вмещает свою группу layers, с достаточными microbatches для pipeline bubble ниже 10%.
• Candidate layouts сравниваются по peak memory, tokens per second, exposed collective time и validation parity при одинаковом global batch.

Я бы накопил восемь microbatches, потому что 32 умножить на 8 и на 8 равно нужному global batch 2 048.

• Loss каждого microbatch делится на восемь перед backward или accumulated gradients усредняются ровно один раз.
• Gradient clipping, optimizer step, EMA и learning-rate schedule выполняются после восьмого microbatch, а DDP synchronization пропускается для первых семи.
• Я проверю BatchNorm и stochastic-layer behavior, потому что accumulation совпадает по размеру gradient, но не по всем операциям physical batch 2 048.

Я бы считал linear scaling стартовой гипотезой и перенастроил warm-up и число optimizer steps по validation quality.

• Рост batch в 16 раз допускает trial learning rate до 16x для SGD, но Adam часто требует меньшего роста и явного stability sweep.
• Epoch-based schedules теперь содержат в 16 раз меньше optimizer steps, поэтому warm-up, decay, EMA и checkpoint intervals задаются в updates или tokens.
• Сравниваются time и GPU-hours до одинаковой validation target, потому что быстрые epochs бесполезны при потере generalization или дополнительных data passes.

Я бы выбрал BF16, потому что exponent range уровня FP32 устраняет большинство loss-scaling failures при сохранении tensor-core throughput.

• Optimizer statistics, отдельные reductions и численно чувствительная normalization остаются в FP32.
• Step time, peak memory, non-finite gradients и validation loss сравниваются минимум за полный schedule, а не на speed sample 100 steps.
• FP16 остаётся разумным, только если dynamic loss scaling устраняет 0,4% failures без skipped updates или quality loss.

Я бы уменьшил exposed communication и улучшил overlap до добавления GPU.

• Профилируются gradient bucket readiness и NCCL link throughput, чтобы отличить poor overlap, tiny collectives, topology placement и slow rank.
• Тестируются larger microbatches, gradient accumulation, BF16 collectives и bucket sizes с overlap reduction и backward.
• Изменение принимается только при росте tokens per GPU-second и улучшении time to target quality, с целью collective time ниже 20% step.

Я бы изменил форму и кеширование input path, чтобы storage устойчиво давал минимум 50 ГБ/с с запасом до дальнейшего scale compute.

• Примеры упаковываются в immutable sequential shards по 1-4 ГБ вместо миллионов small files, с достаточным числом shards для независимого sampling ranks.
• Shards заранее читаются на node-local NVMe с parallel decoding, pinned memory и asynchronous host-to-device copy.
• Измеряются remote throughput, cache hit rate, decode time и dataloader wait, который должен быть ниже 10% step time на финальном dataset.

Я бы писал sharded checkpoint асинхронно и публиковал его только после надёжной записи всех обязательных shards.

• Model, optimizer, scheduler, scaler, RNG, sampler position и completed global step сохраняются с checksums под одним generation.
• Каждый rank пишет на local NVMe и загружает multipart objects в S3, пока training продолжается из immutable state snapshot.
• Manifest становится видимым после завершения всех shards, а restore тестируется на supported world sizes с проверкой subsequent loss и sample order.

Я бы использовал early-stopping search с жёстким GPU-hour budget вместо полного training фиксированного числа trials.

• Начинаются 40-80 random или Bayesian trials по conditional ranges с оценкой на сопоставимых token или step milestones.
• Ray Tune ASHA останавливает слабые trials и продвигает лучшие, а concurrency остаётся ниже насыщения storage и dataloader.
• Около 20% budget резервируется на repeated seeds и final retraining, затем выбор один раз проверяется на untouched test set.