Подготовка к собеседованию по ML-платформам / MLOps
Вопросы для собеседования инженера по ML-платформам и MLOps
15 отобранных вопросов для собеседования по ML-платформам и MLOps, сгруппированных по уровню seniority. Используйте их для повторения основ, практических компромиссов и рассуждений старших специалистов о производственных аспектах.
1Что такое контракт данных в рабочей платформе машинного обучения и зачем он нужен?
Это версионируемое соглашение поставщиков и потребителей данных. Оно задаёт схему, смысл признаков, допустимые значения, правила для null, свежесть, ожидаемый объём и ответственных за изменения. Ошибочное значение может оставаться подходящим по типу, но изменить прогноз без явного исключения. Проверки контракта на входе помогают заметить несовместимое изменение, уменьшить расхождение между обучением и применением модели и вовремя уведомить владельца данных. Они дополняют мониторинг качества прогнозов.
2Какие проверки качества данных нужны помимо схемы и когда они должны останавливать обучение или выдачу прогнозов?
Проверяйте долю пропусков, диапазоны и справочники значений, объём, свежесть, полноту разделов, уникальность и долю успешных соединений. Сравнивайте распределения с подходящим исходным периодом, например по среднему, разбросу или расхождению Йенсена — Шеннона. Блокируйте публикацию или обучение, если отсутствуют ключи сущностей, повреждены метки или обязательный раздел пуст. При небольшом ожидаемом сдвиге или допустимом пропуске некритичного признака поднимайте предупреждение и используйте проверенный запасной режим. Пороги зависят от влияния на модель и данных сезона. Для онлайн-сервиса заранее определите, можно ли оставить последнюю пригодную версию признаков.
3Объясните назначение хранилища признаков и различие между онлайн-выдачей признаков и их офлайн-формированием.
Хранилище признаков (feature store) — централизованная платформа управления, хранения, поиска и выдачи ML-признаков для обучения и предсказаний. Основные цели — повторное использование признаков командами, устранение дублирующихся инженерных конвейеров и уменьшение расхождений между обучением и обслуживанием благодаря единым определениям признаков. Ключевой архитектурный подход — два хранилища. 1. Офлайн-хранилище для формирования признаков и обучения. Оно строится на аналитических движках и распределённых хранилищах, например Snowflake, BigQuery, S3/Parquet или Delta Lake. Оптимизировано для высокопроизводительной пакетной обработки, хранения истории и соединений, корректных на заданный момент времени (as-of). Историческое извлечение поддерживает соединения с учётом времени, но для восстановления без утечки также нужны правильные ключи сущностей, история событий и доступности, версии преобразований и временные границы меток. Офлайн-хранилище не обязательно само создаёт признаки: вычислять и загружать их могут внешние конвейеры. 2. Онлайн-хранилище для предсказаний в реальном времени. Оно строится на высокодоступных базах ключ–значение с малой задержкой, например Redis, DynamoDB или Cassandra. Оптимизировано для точечного получения последних значений признаков по ID сущностей, например user_id, чтобы дополнять запросы к модели. Фактическая задержка зависит от развёртывания и нагрузки. Реестр и совместимые определения связывают эти среды, а приём и синхронизацию может выполнять платформа признаков или внешние конвейеры. Возможности зависят от конкретного продукта.
Feature Definition: `user_30d_transaction_count`
|
+---------------+---------------+
| |
v v
[Offline Store] [Online Store]
- Tech: BigQuery, Iceberg, S3 - Tech: Redis, DynamoDB
- Workload: High-throughput batch - Workload: Low-latency point lookups
- Retention: Multi-year history - Retention: Latest entity state
- Usage: Point-in-time training - Usage: Real-time inference scoring
4Чем отличаются определение признака, значение признака, представление признаков и ключ сущности?
Ключ сущности идентифицирует объект, например пользователя по user_id, и связывает источники. Определение признака задаёт имя, тип и вычисление, например сумму покупок за последние 30 дней. Представление признаков объединяет связанные определения для выбранных ключей и описывает источник и правила времени, загрузки и хранения. Значение — конкретный результат для данного ключа на выбранный момент, например 452,10 для пользователя 1042. Оно может храниться заранее или вычисляться по запросу.
5Что такое прослеживаемость происхождения данных и как она помогает разбирать ухудшение модели?
Это запись о том, из каких источников, версий и преобразований получились наборы признаков и какие модели их использовали. При падении качества можно проследить путь назад: от версии модели к снимку обучающих данных, расчёту признака и исходной загрузке. Если нашли повреждённый раздел или неверное преобразование, пройдите вперёд и определите затронутые наборы, модели и развёртывания. Так можно ограничить исправление, пересчёт, переобучение или откат тем, чего действительно коснулась проблема.
[Degraded Model v3.1]
└── Trained on: [Dataset: training_set_2025_04_01]
└── Built from: [Feature View: user_features_v2 @ git_sha: abc1234]
└── Source Table: [raw_user_events @ batch_2025_03_31]
└── Issue Found: Logging bug produced 40% zero-filled values
Реестр объединяет версии модели под одним именем и связывает каждую с запуском обучения, кодом, снимком данных, параметрами и средой. Он хранит результаты оценки, сигнатуры входов и выходов, карточку модели и сведения об одобрении. В зависимости от системы он помогает управлять стадиями, доступом и продвижением версий. Когда реестр связан с развёртыванием, по нему можно установить, какая версия работала, и выбрать совместимую проверенную версию для отката.
7Зачем нужен план отката модели и что нужно сохранить для безопасного возврата?
План определяет, когда и как вернуть трафик к известной рабочей версии при ошибках, ухудшении качества или росте задержки. Сохраните артефакт модели, код и образ среды, версии зависимостей, предобработку и совместимые определения и схемы признаков. Зафиксируйте настройки маршрутизации и проверьте переключение заранее: прежняя версия должна работать с текущими данными и инфраструктурой. Если обе версии недоступны, используйте согласованный запасной режим, например правила или пригодный кэш, либо явный отказ.
8Чем проверка схемы при записи отличается от проверки при чтении в конвейере признаков?
При записи проверяют входящие данные до публикации в общем хранилище. Это позволяет рано отклонить или поместить в карантин несовместимую запись и сообщить поставщику. Подход полезен, когда один набор используют многие модели. При чтении потребитель проверяет данные перед расчётом признаков или обучением по требованиям конкретной модели. Это подходит для старых и внешних наборов, где входную проверку нельзя навязать. Часто их сочетают: общий контракт на записи, ограничения конкретной модели на чтении.
# 1. Write-Time Validation: Reject or quarantine bad records before landing in Feature Store
def write_to_feature_store(raw_records, schema_validator, feature_table, dlq_publisher):
valid_records = []
for record in raw_records:
if schema_validator.is_valid(record):
valid_records.append(record)
else:
dlq_publisher.publish(record, reason="write_time_validation_failed")
feature_table.append_batch(valid_records)
# 2. Read-Time Validation: Consumer pipeline applies defensive model-specific checks
def load_training_features(feature_table, model_schema):
df = feature_table.read_partition("2023-10-01")
# Model-specific consumer gate: drops non-conforming rows without halting upstream ingestion
clean_df = df[model_schema.validate_row_mask(df)]
return clean_df
9Как диагностировать конвейер, который завершается успешно, но теряет строки или подставляет значения, искажающие прогнозы?
Сверьте число строк и уникальных сущностей до и после загрузки, фильтрации, соединений и агрегирования. Проверьте ключи без пары, неожиданные дубли и изменение правил фильтрации. Посчитайте пропуски до и после преобразования типов и подстановки: SAFE_CAST или приведение с подавлением ошибки могут превратить неверное значение в NULL, а затем в обычный ноль. Сравните распределения признаков и прогнозов с сопоставимым периодом. После исправления добавьте проверки потерь и пропусков, пересчитайте затронутые разделы с возможностью безопасного повтора и проверьте результат на контрольных данных.
# Anti-Pattern: Succeeds green but corrupts feature data
# 1. Inner join silently drops users with missing profiles
# 2. errors='coerce' turns string typos into NaNs
# 3. fillna(0) injects artificial 0-values into feature distribution
df_corrupt = df_events.merge(df_profiles, on="user_id", how="inner")
df_corrupt["credit_score"] = pd.to_numeric(df_corrupt["raw_score"], errors="coerce").fillna(0)
# Robust Implementation: Explicit checks and observable failure
df_clean = df_events.merge(df_profiles, on="user_id", how="left")
join_match_rate = df_clean["user_id"].notna().mean()
if join_match_rate < 0.98:
raise RuntimeError(f"Severe join drop detected! Match rate: {join_match_rate:.2%}")
raw_nulls = df_clean["raw_score"].isna().mean()
if raw_nulls > 0.05:
raise ValueError(f"Anomalous raw_score missingness: {raw_nulls:.2%}")
10Сравните пакетные и потоковые конвейеры признаков для рабочих ML-систем с различными требованиями к актуальности, стоимости и надёжности.
Пакетные конвейеры обрабатывают ограниченные наборы данных по расписанию или триггеру, а потоковые — постепенно обрабатывают поступающие события. Выбирайте подход с учётом требуемой сквозной актуальности, объёма данных, размера состояния и поведения при восстановлении. Пакетные задания могут запускаться каждые несколько минут или по требованию: многочасовая задержка не является их обязательным свойством. Потоковая обработка может обеспечивать малую задержку, но актуальность всё равно зависит от задержек приёма, обработки и записи результата. Пакетная обработка часто проще в эксплуатации для крупных исторических пересчётов, но не всегда дешевле: инкрементальная потоковая обработка может избавить от повторных полных сканирований, а управляемые и бессерверные системы меняют стоимость вычислительных ресурсов. Сравнивайте измеренную стоимость реальной нагрузки. Обоим подходам нужны проверка схемы, обработка дубликатов и надёжная публикация результатов. В потоковом варианте особенно важны время события, опоздавшие данные, восстановление состояния и обратное давление. Гибридная архитектура часто сочетает потоковую обработку недавней активности с пакетными историческими агрегатами, используя согласованные определения и явную семантику времени доступности данных при обучении и обслуживании предсказаний.
11Разберите влияние опоздавших событий и событий, поступающих не по порядку, на обучающие данные, метки и онлайн-признаки в конвейерах признаков.
В распределённой потоковой обработке события часто поступают не по порядку из-за сетевых задержек, отказов систем или повторных попыток клиента. Время события — момент, когда оно действительно произошло на клиенте или исходном устройстве; время обработки — момент его обработки системой приёма или потоковым движком. Водяные знаки (watermarks) оценивают прогресс по времени событий, а окна и правила допустимого опоздания определяют, как опоздавшие события обновляют результаты, перенаправляются или отбрасываются. Они не гарантируют, что более раннее событие уже никогда не поступит. Последствия для систем признаков: 1. Обучающие данные и временная утечка. При сборке исторических наборов нужно учитывать и границы по времени событий, и данные, действительно доступные системе предсказаний в исторический момент решения. Опоздавшее событие может иметь старую временную метку, но поступить после предсказания, поэтому as-of-соединение только по времени события может допустить утечку. Сохраняйте историю доступности или наблюдений и версии преобразований. Временные метки обработки помогают установить доступность, но не взаимозаменяемы со временем событий. 2. Формирование меток. Многие метки поступают с переменной задержкой, например атрибуция конверсий или возвраты платежей из-за рекламного мошенничества. Если соединение меток не учитывает опоздания с помощью подходящих окон наблюдения и атрибуции, отрицательные метки, сформированные по неполным данным, создают смещение из-за ложноотрицательных результатов. 3. Онлайн-признаки. Записи из потока, поступающие не по порядку, могут повредить состояние или перезаписать его старыми данными, если хранилище безусловно заменяет значения. Используйте upsert с учётом времени события, проверки версий или коммутативные функции агрегирования, чтобы устаревшие данные не перезаписывали актуальное состояние.
import pandas as pd
# Prediction events (e.g., ad impressions at inference time)
observations = pd.DataFrame({
'user_id': [101, 102],
'pred_time': pd.to_datetime(['2023-10-01 10:00:00', '2023-10-01 10:30:00'])
})
# Feature updates with event-time timestamps
user_features = pd.DataFrame({
'user_id': [101, 101, 102],
'feature_time': pd.to_datetime([
'2023-10-01 09:30:00',
'2023-10-01 10:15:00', # Occurs after observation 1 pred_time
'2023-10-01 10:00:00'
]),
'click_count_1h': [3, 5, 1]
})
# Backward as-of join guarantees only feature state known at pred_time is joined
training_set = pd.merge_asof(
observations.sort_values('pred_time'),
user_features.sort_values('feature_time'),
left_on='pred_time',
right_on='feature_time',
by='user_id',
direction='backward'
)
print(training_set[['user_id', 'pred_time', 'feature_time', 'click_count_1h']])
12Объясните роль очередей необработанных сообщений (dead-letter queues), идемпотентности и контрольных точек в конвейерах обработки признаков в реальном времени.
Контрольная точка сохраняет согласованную позицию восстановления и состояние операторов, чтобы потоковое задание могло повторно прочитать вход после сбоя. Реальная гарантия зависит от возможности воспроизвести источник, настройки контрольных точек и согласования с приёмником: согласованное внутреннее состояние не обеспечивает автоматически однократность внешних эффектов. Идемпотентный приёмник сохраняет предполагаемый результат при повторном применении одного логического события. Детерминированная замена по стабильному ключу может быть идемпотентной, но атомарный upsert, увеличивающий счётчик, всё равно повторно учитывает попытки. Используйте идентификаторы дедупликации и атомарные изменения состояния либо поддерживаемый транзакционный приёмник. Сравнение временных меток требует детерминированного разрешения совпадений и не решает произвольное агрегирование событий вне порядка. Обработка через dead-letter queue изолирует некорректные записи с идентификаторами данных и причинами отказа для расследования и контролируемого повторного воспроизведения. Отслеживайте объём таких записей и затронутые сущности, согласуйте перенаправление с продвижением по источнику и ограничивайте либо переводите обслуживание в режим сниженной функциональности, если отброшенные входы делают признаки недопустимо неполными. Работающий основной конвейер сам по себе не доказывает корректность данных признаков.
def update_user_feature(redis_client, user_id: str, new_feature_val: float, event_timestamp: int):
lua_script = """
local current_ts = redis.call('HGET', KEYS[1], 'last_updated')
if not current_ts or tonumber(ARGV[1]) > tonumber(current_ts) then
redis.call('HSET', KEYS[1], 'feature_val', ARGV[2], 'last_updated', ARGV[1])
return 1
end
return 0
"""
# Atomic check-and-set: older replayed events are ignored
return bool(redis_client.eval(lua_script, 1, f"user:{user_id}", event_timestamp, new_feature_val))
13Как пересчитать исторические признаки, если исправление источника сделало прежние значения неверными?
По происхождению данных найдите затронутые разделы, наборы обучения, онлайн-хранилища и работающие модели. Учтите окна агрегации: исправление одного дня может менять признаки следующих дней. Пересчитайте значения в отдельную версию с закреплёнными входами. Сверьте ключи, схему, пропуски, ожидаемое изменение распределений и образцы расчёта. Оцените, какие модели нужно переобучить или откатить. Переключайте потребителей на совместимую версию поэтапно, ограничьте запись в онлайн-хранилище и проверяйте свежесть. Храните прежнюю версию по согласованной политике и удаляйте её только после проверки потребителей.
[Upstream Data Correction Event]
|
v
[1. Lineage Traversal] --------> Identifies: FeatureView_A, TrainingDataset_B, Model_C
|
v
[2. Isolated Reprocessing] ----> Writes to isolated staging: `features_v2_backfill`
|
v
[3. Validation Gate] ----------> Validates: Schema match, Null checks, PSI < 0.05
|
v
[4. Cutover & Retrain Trigger]-> Online: Atomic alias swap (`feature_v1` -> `feature_v2`)
Offline: Retrain Model_C on corrected historical split
14Спроектируйте систему получения онлайн-признаков с малой задержкой и объясните компромиссы хранения, кеширования, партиционирования и обработки горячих ключей.
Система выдаёт моделям предварительно вычисленные признаки и признаки реального времени при высокой пропускной способности и строгом SLA задержки, обычно p99 менее 5–20 мс. Хранение и архитектура: используйте распределённые базы ключ–значение с малой задержкой, например Redis, DynamoDB, Cassandra или Aerospike. Измеряйте p99 и стоимость для реальной сети, размеров записей, режима согласованности, нагрузки и отказов: ни одна из перечисленных баз не гарантирует одинаковую задержку для любой нагрузки. Признаки сущности часто размещают вместе и сериализуют через Protocol Buffers, FlatBuffers или MessagePack под ключом entity_id:feature_view_name, сокращая сетевые обращения и случайные чтения диска. Кеширование и получение: для очень часто запрашиваемых сущностей используйте локальный кеш процесса, например Caffeine/LRU в прокси обслуживания, поверх распределённого KV-хранилища. Запросы с множеством сущностей, например переранжирование 500 кандидатов, обслуживайте пакетными MGET или асинхронными scatter-gather-вызовами к шардам. Партиционирование и горячие ключи: согласованное хеширование равномерно распределяет ключи сущностей по узлам. Для горячих ключей — популярных пользователей, вирусных товаров, общих или резервных сущностей — применяйте: 1. Реплики чтения и локальный кеш для интенсивно читаемых значений. 2. Добавление соли к ключам или виртуальное шардирование. Для полных векторов признаков с преобладанием чтения храните версионированные копии под несколькими ключами и распределяйте чтения, учитывая размножение обновлений и устаревание копий. Если значение разбито на частичные агрегаты, чтение должно получить и корректно объединить нужные части. Простое добавление случайного суффикса не сохраняет полное значение и не решает проблему безопасно. 3. Ограничение частоты на клиенте и резервное поведение: при деградации выдавайте статические значения по умолчанию или кешированные резервные эмбеддинги.
# Conceptual Online Feature Client with Local LRU + Batched KV Fetch
import functools
from typing import List, Dict, Any
class OnlineFeatureClient:
def __init__(self, remote_kv_store, local_cache):
self.remote_kv = remote_kv_store
self.local_cache = local_cache
def get_online_features(self, entity_keys: List[str], feature_names: List[str]) -> Dict[str, Dict[str, Any]]:
results = {}
missing_keys = []
# 1. Check local in-memory L1 cache (mitigates hot-keys)
for key in entity_keys:
cached = self.local_cache.get(key)
if cached:
results[key] = cached
else:
missing_keys.append(key)
# 2. Batched async retrieval for missing keys from distributed store (e.g., Redis/DynamoDB)
if missing_keys:
fetched_records = self.remote_kv.mget(missing_keys)
for key, serialized_val in zip(missing_keys, fetched_records):
parsed_val = self._deserialize(serialized_val) # Proto/Msgpack
results[key] = parsed_val
self.local_cache.set(key, parsed_val, ttl=30) # Short TTL L1 cache
return results
def _deserialize(self, data): ...
15Чем централизованная ответственность за признаки отличается от ответственности предметных команд?
Центральная команда задаёт единые определения, проверки и правила доступа. Это облегчает повторное использование, но может замедлять запросы и не учитывать тонкости предметной области. Предметные команды быстрее меняют признаки и лучше понимают их смысл, однако возможны дубли, разные названия и неодинаковое качество. В смешанной модели платформа предоставляет каталог, общие проверки, доступ и инструменты, а предметные команды отвечают за вычисления, контракты, свежесть и устранение сбоев. Выбор зависит от зрелости команд и числа общих признаков.
