Большинство провалов на ML System Design связаны с семью ошибками: отсутствием бизнес-цели, метриками без привязки к цели, игнорированием стоимости ошибок, недооценкой качества данных, попыткой закрыть всё универсальным LLM-агентом, слабой валидацией и мониторингом, неумением задавать уточняющие вопросы. Эти ловушки воспроизводятся от собеседования к собеседованию, хотя исправляются осознанной структурой ответа.
Разберу их на примере соревнования ML Kata, где команды проектировали голосового агента для клиники за 75 минут. Формат близок к интервью уровня middle и выше: ограниченное время, размытая постановка, несколько участников и требование предложить рабочую архитектуру.
Почему сильные кандидаты проваливают системный дизайн
Этап системного проектирования в 2026 году проверяет рассуждение, а не заученные решения. Интервьюеры не принимают шаблонный ответ про балансировщик нагрузки и базу данных. Ждут, что кандидат вслух выстроит цепочку: бизнес-задача, ограничения, данные, метрики, компромиссы, режимы отказа, стоимость. ИИ-нагрузки уже стали легитимными темами: инференс, векторный поиск, retrieval-конвейеры, потоковые обучающие данные. Сильные программисты отсеиваются на этом этапе, если не умеют структурировать ответ под ограничение времени.
Для распределённого хранения диалогов и состояния агента приходится рассуждать о консистентности, доступности и стоимости. Теорема CAP, формализованная Эриком Брюером в 2000 году и доказанная Гилбертом и Линчем в 2002, даёт язык для этого компромисса. Уметь называть выбор между consistency и availability лучше, чем говорить про репликацию без обоснования.
Ошибка 1: старт без бизнес-цели и уточняющих вопросов
Слабые команды ML Kata сразу выбирали LLM, ASR и TTS. Сильные начинали с вопросов.
- Какие звонки агент должен обрабатывать: запись, напоминания, симптомы, рецепты?
- Кто звонит: пожилой пациент, родитель с ребёнком, врач?
- Что считается успехом: доля завершённых записей, снижение пропущенных звонков, сокращение времени оператора?
- Где работает агент: в контакт-центре, на телефоне пациента, в браузере?
- Какие ограничения по приватности, задержке, бюджету и регуляторике?
Без ответов проектировщик строит универсальную систему, которая не решает конкретную задачу. Правильный ход: зафиксировать допущения, назвать цель и только затем переходить к архитектуре. На собеседовании это показывает, что вы управляете неопределённостью, а не игнорируете её.
Ошибка 2: метрики без привязки к цели и цене ошибки
Accuracy или F1 без контекста бесполезны. Для голосового агента клиники пропуск срочного симптома опаснее лишнего уточнения. Метрику нужно раскладывать по типам ошибок и считать их стоимость.
| Сценарий ошибки | Дешёвое последствие | Дорогое последствие |
|---|---|---|
| Ложное срабатывание на симптом | Лишний уточняющий вопрос | Пациент отменяет визит без основания |
| Пропуск срочного симптома | Перенос звонка на оператора | Риск для здоровья пациента |
Офлайн-метрики: recall по классу срочных обращений, word error rate на медицинских терминах, intent accuracy для намерений. Онлайн-метрики: доля успешно завершённых записей, среднее время разговора, доля эскалаций на оператора, число жалоб. Если recall ниже 0.95 по срочным симптомам, система не проходит, даже при высоком общем F1.
Ошибка 3: недооценка качества данных и конвейера
Голосовой агент сталкивается с шумом, разговорной речью, медицинскими терминами, акцентами и фоновыми звуками. Если проектировщик не упоминает аудиозаписи, разметку и проверку транскрипций, это красный флаг. Нужно описать источники: записи звонков, длительность, частоту дискретизации, наличие ground truth. Локальный синтез речи, например модель VoxCPM2, работает с непрерывными представлениями без токенизатора, выдаёт аудио 48 кГц и поддерживает около 30 языков. Для запуска нужны Python 3.10-3.12, PyTorch 2.5+, CUDA 12.0+ и около 4,96 ГБ весов. Это пригодится, если клиника не хочет отправлять аудио на сторонний сервер.
Качество данных закладывают до модели. Конвейер FineVideo показывает, как выстроить фильтрацию, разметку и QA-проверку датасета, чтобы модель не училась на мусоре: разбор конвейера FineVideo.
Ошибка 4: попытка сразу построить универсального LLM-агента
Часть команд ML Kata выбирала одного LLM-агента, который должен слушать, распознавать, классифицировать, рассуждать, генерировать речь и работать с API клиники. Это дорого, медленно и трудно отлаживать. Правильная декомпозиция: отдельно ASR, детектор языка, распознавание намерений, извлечение сущностей, диалоговый менеджер с правилами, TTS, интеграция с МИС. Детерминированный слой между LLM и API клиники снижает риск галлюцинаций и неверных действий.
Выбор модели под задачу не должен сводиться к бенчмаркам. Разбор практического теста DeepSeek-V4-Flash на ML-задачах показывает, как проверять модель на своих типах данных и замечать ограничения. Если часть сценариев закрывается локальной моделью, можно снизить задержку и стоимость инференса, но придётся учесть VRAM, кеш и требования к стеку. Сравнение локального и облачного инференса, а также стоимости за токен разобрано здесь: DeepSeek, Qwen и стоимость инференса в 2026 году.
Ошибка 5: валидация и мониторинг на потом
Слабые ответы заканчиваются после выбора модели. Сильные описывают, как проверить систему до выката и что контролировать после. Для голосового агента: офлайн-валидация на отложенных записях, shadow mode, A/B, канареечное внедрение, ручная проверка транскрипций. В проде собирают задержку, стоимость на звонок, ASR WER по неделям, долю эскалаций, recall по срочным симптомам, количество жалоб. Пороги алертов и владельцы метрик обязательны.
Отдельная сложность: наблюдаемость AI-слоя. Нужно логировать вызовы LLM, tool calls, извлечение сущностей. Иначе баги проявляются как плохие ответы, и команда не может найти причину.
Как выстроить сильный ответ за 45-75 минут
- Задать уточняющие вопросы о бизнес-цели, пользователях, ограничениях, доступных данных. Зафиксировать допущения.
- Сформулировать задачу как ML-пайплайн: вход, выход, онлайновые и оффлайновые метрики, стоимость ошибок.
- Выбрать декомпозицию: ASR, распознавание намерений, extraction, диалоговая политика, TTS, интеграция с клиникой.
- Определить данные: источники, разметка, объём, качество, возможные утечки.
- Спроектировать контур безопасности: валидация ответов, ограничение прав, human-in-the-loop для срочных сценариев.
- Описать развертывание и мониторинг: shadow, A/B, алерты, откат.
При ограничении 75 минут полезно выделить 10 минут на вопросы и уточнения, 35 минут на основную архитектуру, 15 минут на метрики и отказы, 15 минут на вопросы интервьюера. Тренироваться нужно вслух с доской.
Чек-лист перед собеседованием
- Проведите 3-5 mock-интервью с публичным разбором на доске.
- Для каждого кейса фиксируйте бизнес-цель, пользователей, ограничения и цену ошибок.
- Умейте назвать три режима отказа и метрики для каждого.
- Знайте, где применим локальный инференс, а где облачный API.
- Разберите один голосовой и один retrieval-кейс до уровня латентности, стоимости и безопасности.
Перед собеседованием выберите один кейс, прогоните его по схеме и запишите себя на диктофон. Это быстрее вскрывает провалы в рассуждениях, чем чтение конспектов.