Как offline-предсказания попадают в production
Если embeddings, scores или recommendation lists считаются offline и лежат в S3/DWH, как безопасно передать эти результаты backend/serving-слою?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Публикуйте 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 на предыдущую, а не ручным поиском старых файлов.
Теория
Offline ML serving - это задача версионированной публикации данных и артефактов, а не только CI/CD сервиса.
Типичные ошибки
- Перезаписывать файлы на месте, пока backend их читает.
- Не хранить schema/model/version metadata.
- Не проверять coverage и freshness предсказаний.
Как отвечать на собеседовании
- Используйте формулировку “versioned artifact плюс active pointer”.
- Отделяйте deploy service code от publish model/data artifact.