В эпоху активного развития кодинг-агентов, когда функция разработчика всё больше смещается от ручного написания кода к проектированию архитектуры, навык ML System Design становится всё более определяющим для Data Scientist. На собеседовании на грейд middle и выше вы часто столкнётесь с проверкой этого навыка, где необходимо не просто сказать, какую модель взять, а связать бизнес, данные, алгоритмы, инфраструктуру, валидацию и мониторинг. Это может быть отдельная секция, где за 1–1,5 часа необходимо на доске Miro решить кейс по проектированию ML-системы для решения реальной бизнесовой задачи. Либо это будет небольшая часть на 20–30 минут, обычно на финальном собеседовании, что, как по мне, гораздо хуже, потому что за такое время очень сложно пройтись по всем этапам дизайна и показать свои знания. Как же подготовиться к такому собеседованию, если в реальности таких задач за карьеру бывает не так много?
Недавно я участвовал в соревновании ML Kata: 6 команд, одна задача, 75 минут на ML System Design. Я считаю, что, проанализировав защиты команд и обратную связь от судей(одним из которых был Валерий Бабушкин), можно вкачать навык MLSD на уровень, достаточный для прохождения собеседования – при условии, что вы уже знаете метрики и модели для конкретной технической задачи. В этой статье я сделаю такой разбор за вас и систематизирую типовые ошибки участников, которых не избежал и сам.
Ловушка №0: без цели, без плана
Задание звучит просто: «Спроектировать голосового агента». Нормальное технарское желание – это сразу перейти к вопросам реализации: данные, модель, инференс. Но рано или поздно работу системы придётся оценивать. И тут было бы неплохо сразу договориться с бизнесом: а какую систему он вообще считает успешной? Иначе можно спроектировать технически красивое решение, которое оптимизирует вообще не ту задачу.
Именно в эту ловушку попали многие команды: они быстро ушли в техническую реализацию, но не смогли чётко сформулировать конечную цель системы.
Перед тем как обсуждать модели, стоило ответить на вопросы:
Какую бизнес-проблему мы решаем?
Чем вообще живёт бизнес и где он теряет деньги?
Например:
перегружен call-центр;
пациенты долго ждут ответа;
часть звонков теряется;
операторы ошибаются при маршрутизации;
стоимость обработки одного звонка слишком высокая.
Отсюда уже возникает вопрос: что именно мы хотим улучшить и на чём хотим заработать: снизить ФОТ операторов, уменьшить время ожидания и число брошенных звонков или увеличить количество успешных записей? Хотим разгрузить операторов только в пик или заменить часть операторов всегда?
Кто пользователь и какую задачу он пытается решить?
У одного и того же голосового агента могут быть совершенно разные сценарии:
записаться на плановый приём;
перенести запись;
понять, к какому специалисту обратиться;
решить срочную проблему;
уточнить информацию по существующей записи.
Без понимания этих сценариев невозможно определить ни требования к системе, ни корректные метрики.
Что считается успешным звонком?
Допустим, пациент позвонил, но его проблема в принципе не может быть решена записью к врачу. Должна ли система всё равно максимизировать вероятность записи? Очевидно, нет. Иначе легко прийти к абсурдной оптимизации: агент начинает «прогревать» на визит к врачу даже тогда, когда человеку он не нужен.
Поэтому важно заранее определить, что для нас важнее:
больше записей;
правильная маршрутизация;
меньше ожидания;
меньшая стоимость;
удовлетворённость пациента;
доля пользователей, которые действительно решили свою проблему.
Где заканчивается ответственность системы?
Следующая ошибка после отсутствия целей – отсутствие антицелей, или явного out-of-scope.
Для такого агента они могли бы звучать так:
не ставим диагноз;
не даём медицинские рекомендации;
экстренные случаи передаём человеку;
не оптимизируем количество записей любой ценой;
не пытаемся заменить врача;
не пытаемся сразу заменить весь call-центр;
в первом MVP не покрываем 100% типов звонков.
Судьи ожидали услышать это в начале, но не услышали почти ни у кого. Нечётко поставленная цель привела к неправильному выбору метрик, спорной схеме валидации и переусложнению архитектуры.
Что нужно проговорить на интервью:
«Перед тем как обсуждать модель, я сначала фиксирую, какую бизнес-проблему мы решаем и что считаем успехом. В данном случае цель может быть в снижении стоимости обработки звонка и нагрузки на call-центр без ухудшения качества обслуживания. Дальше определяю основные пользовательские сценарии: например, запись, перенос и маршрутизация к специалисту – и отдельно фиксирую out-of-scope: агент не ставит диагноз, не даёт медицинских рекомендаций, а критические и неизвестные сценарии передаёт человеку.
После этого договариваюсь о North Star и ограничениях. Например, основной результат – доля обращений, в которых пользователь действительно решил свою задачу, а не просто доля звонков, не дошедших до оператора. Сразу же определяем, какое ухудшение качества относительно текущего процесса допустимо и какие safety-метрики нарушать нельзя».
Ловушка №1: метрики без цели
Пока не выбрана цель ML-системы, любая метрика будет выглядеть правдоподобно, но почти любую можно абьюзить.
Пример:
«Конверсия звонка в запись» выглядит подходящей бизнес-метрикой, но если её максимизировать без guardrails-метрик, то агент начнёт записывать всех подряд. Получится, что бизнес-метрика растёт, а качество сервиса падает.
Проблемы с метриками можно разделить на следующие типы:
Запаздывающие метрики. Одна команда завязалась на фактической записи / конверсии, и судья дал жёсткий фидбэк: «У вас все метрики запаздывающие с большим лагом. Понимаете, почему это плохо? Через полгода увидите, что все беременные пришли к ортопеду. Запись к врачу на месяц вперёд + пока в очереди наберётся + пока пожалуются – клиника уже закрыться успеет».
Абьюзенная метрика. Команда предложила «меньше звонков доходит до живого оператора» как бизнес-метрику. Судья сразу: «Великолепно, всем говорим «пей парацетамол» – метрику «меньше звонков до оператора» выполнили. Просто никто не дошёл до врача».
Метрика без декомпозиции. Судья: «счастливые пациенты – это очень широкая метрика, такую можно почти к любому проекту прилепить, она не снижает энтропию». ««Пользователь вылечился» – это слишком широкая метрика, её тяжело мерить».
Метрика без корреляции. Proxy-метрики должны коррелировать с бизнес-метриками.
Вопросы к метрикам для самопроверки:
Какая у системы бизнес метрика и как она связана с деньгами?
Как система может эту метрику абьюзить?
Какие guardrails не позволят ей это сделать?
Какие метрики дадут сигнал об ошибке в течение часов, а какие только через недели?
Какие быстрые proxy мы используем для запаздывающей бизнес-метрики?
Проверяли ли мы, что эти proxy действительно коррелируют с бизнес-результатом?
Какие ML-метрики помогут локализовать проблему, если продуктовая метрика начнёт падать?
Что нужно проговорить на интервью:
Я бы строил иерархию метрик сверху вниз:
Уровень 1 – бизнес-метрики:
Cтоимость одного успешного обращения клиента.
Уровень 2 – online-метрики:
доля успешных записей (при условии, что клиент хотел записаться);
CSAT после визита;
время ожидания;
доля брошенных звонков;
жалобы врачей.
Уровень 3 – offline-метрики:
Точность маршрутизации «симптом → специальность» (с явным знаменателем!);
recall по критическим сценариям;
tool-calling success rate;
tool-calling selection accuracy;
scenario success rate.
Уровень 4 – системные:
end-to-end response latency: p50 / p95 / p99;
TTS latency;
LLM latency / TTFT;
availability;
timeout rate;
fallback rate.
Guardrails – защитные:
доля переводов на оператора;
доля медицинских рекомендаций, которые агент не должен давать;
доля пропущенных экстренных случаев, требующих перевода на оператора;
доля жалоб;
количество повторных обращений.
Ловушка №2: игнорирование стоимости ошибки
Ещё одна вещь, которую почти никто из команд явно не проговорил, – разные ошибки системы стоят по-разному.
Для медицинского голосового агента ошибка «лишний раз перевели человека на оператора» и ошибка «не распознали потенциально экстренный случай» могут встречаться с одинаковой частотой, но последствия у них совершенно разные.
Поэтому перед выбором threshold стоит задать вопрос: сколько нам стоит каждый тип ошибки в деньгах, пользовательском опыте и риске?
Тип ошибки | Что произошло | Последствие | Цена ошибки |
|---|---|---|---|
FP: лишняя эскалация | Безопасный кейс отправили живому оператору | Лишняя нагрузка на call-центр, рост стоимости обработки | Низкая |
FN: пропущенный критический кейс | Опасный случай не эскалировали человеку | Safety-риск, репутационные потери, возможные юридические последствия | Очень высокая |
Что нужно проговорить на интервью:
Для детекции критических сценариев ошибка FN существенно дороже FP, поэтому я выбираю threshold так, чтобы обеспечить высокий recall критических случаев, сознательно допуская некоторое количество лишних эскалаций. Лишний перевод на оператора увеличит стоимость обработки, но пропущенный критический случай для бизнеса неприемлем из-за репутационного и потенциально юридического рисков.
Ловушка №3: данные
В описании данных необходимо рассказать, откуда мы берём данные, кто будет их размечать (при необходимости), придумать фичи и, самое главное, определить, как будет выглядеть target.
В данной задаче было два скользких момента:
Если просто взять историю направлений пациентов от операторов, это ещё не означает, что это были правильные ответы. Пациента могли отправить к неправильному врачу, поэтому действия операторов – это noisy labels. Качество такой разметки необходимо дополнительно проверять экспертами.
Если используются внешние API или облачные модели, отдельно проверяем требования конкретной юрисдикции к персональным и медицинским данным. Для чувствительных данных возможными решениями могут быть обезличивание, self-hosted модели или инфраструктура провайдера, удовлетворяющая требованиям compliance.
Что нужно проговорить на интервью:
Для обучения я бы использовал историю звонков, транскрипты, действия операторов и контекст, который реально доступен системе в момент звонка. Никакая информация, появившаяся после принятия решения, не должна попадать во вход модели, чтобы избежать data leakage.
При этом действие оператора я не считаю автоматически правильным target – это noisy label. Для маршрутизации необходимо сформировать golden set с привлечением экспертов для разметки. Фактическую запись, повторное обращение, жалобу или последующую коррекцию маршрута можно хранить отдельно и использовать для анализа качества разметки.
Если используются внешние API или модели, заранее проверяю требования к передаче, хранению и логированию персональных и медицинских данных и минимизирую объём передаваемого контекста, либо использую, либо self-hosted решение.
Ловушка №4: сразу строить универсального LLM-агента
Многие команды пытались сразу строить универсального LLM-агента для 100% звонков, но 8 млн звонков в год – это масштаб, где стоимость обработки одного звонка становится решающей. Часть сценариев не требует диалогового агента: отмена, перенос, явная запись к конкретному врачу, справочная информация, нецелевые звонки. Судьи ожидали, что участники отсекут такой нецелевой трафик до того, как в дело вступает дорогой LLM-агент. Но только одна команда предложила rule-based IVR («нажмите 1, чтобы…») как Baseline 0, который снимает огромную часть нагрузки дёшево и детерминированно.
В MLSD необходимо строить иерархию бейзлайнов и моделей от простого к сложному, например:
Baseline 0: IVR и оператор;
Baseline 1: speech-to-text + классификация интентов;
MVP: диалоговый агент только для ограниченного набора сценариев.
Что нужно проговорить на интервью:
«Я бы не начинал с универсального LLM-агента на весь трафик. Сначала строю максимально простой рабочий baseline и проверяю, какую часть задачи вообще нужно решать ML.
На более сложное решение перехожу не потому, что оно технологически интереснее, а только если предыдущий baseline не достигает целевого качества или дополнительный uplift оправдывает рост стоимости, latency и сложности эксплуатации. При этом простой baseline полезно сохранить как fallback».
Ловушка №5: Валидация и раскатка
Для offline-валидации многие команды предложили использовать golden set – качественно размеченный набор сценариев, на котором можно регулярно сравнивать версии системы. Это правильная идея, но судьи дали фидбек, что в него стоит ещё добавить:
типовые пользовательские сценарии;
реальные исторические звонки;
редкие и критичные кейсы;
звонки с шумом и плохим качеством связи;
разные акценты и особенности речи;
пожилых пользователей;
оффтоп и неоднозначные ответы;
попытки вывести агента за разрешённый сценарий.
Однако для end-to-end валидации диалогового агента на исторических разговорах есть серьёзное ограничение. Участники не учли, что диалоги интерактивны: следующий вопрос агента меняет данные, которые он получит дальше, поэтому оператор и агент быстро расходятся по веткам диалога. Чтобы не нарваться на вопросы от судей, необходимо предложить решение этой проблемы: например, задавать вопросы по заранее определенной анкете либо использовать цифровых пациентов для симуляции.
По поводу раскатки судьи постоянно спрашивали: «Что является сделанной системой? Какой у вас критерий того, что модель готова к запуску в прод?» Здесь нужно заранее определить, может ли агент быть хуже оператора, но дешевле и какое ухудшение по качеству максимально допустимо.
Что нужно проговорить на интервью:
«Сначала я проверяю систему offline на golden set. Учитываем ограничения, т. к. агент не управляет разговором. Далее запускаю shadow mode на проде, который позволяет проверить интеграцию, latency, распределение ответов и компонентные метрики без воздействия на пользователя. Следующий этап – canary deployment. Я даю системе реальный трафик небольшого контролируемого online-пилота и постепенно увеличиваю долю при соблюдении guardrails. При критической деградации должен быть быстрый fallback на оператора/предыдущую систему.
Если нужно доказать именно causal uplift бизнес-метрики, отдельно провожу A/B-тест».
Ловушка №6: Задеплоили и забыли
Обычно мониторинг – это секция, на которую никогда не остаётся времени. Я думаю, лучше выделить заранее пару минут, чтобы закрыть этот блок хотя бы шаблонными ответом и показать, что вы в целом задумываетесь о мониторинге, не вынуждая собеседующего задавать вам дополнительный вопрос.
Метрика мониторинга должна отвечать на вопрос: «когда я узнаю, что всё сломалось?» Как раз таки здесь раскрывается проблема запаздывающих метрик. Поскольку true labels приходят с задержкой, необходимо как-то решить эту проблему. Один из вариантов – использовать быстрые proxy-метрики, другой – используя human in the loop для объективного контроля, который позволит давать моментальный фидбек. Это также даёт возможность по горячим следам перезвонить клиенту, если в разговоре с агентом что-то пошло не так.
Деградация также может происходить без единой ошибки в логах. Например, изменился состав звонков, появились новые пользовательские сценарии или клиника поменяла правила маршрутизации. Модель продолжает отвечать, но её решения уже менее релевантны. В MLSD это разделяется как минимум на data drift – изменилось распределение входных данных – и concept drift – изменилась сама связь между входом и правильным ответом. Поэтому качество модели нужно систематически сравнивать с историческими значениями и свежими размеченными production-кейсами.
Что нужно проговорить на интервью:
«В проде я мониторю всю цепочку от технической работоспособности до качества решения. На первом уровне – состояние сервиса: availability, end-to-end latency, timeout/error rate, успешность STT/TTS и tool calls. Это позволяет быстро понять, что система физически перестала нормально работать.
Второй уровень – поведение самой ML-системы: распределение интентов и сценариев, fallback/escalation rate, аномалии во входных данных и drift. Здесь задача – заметить ситуацию, когда сервис технически жив, но начинает работать на данных, отличающихся от тех, на которых мы его проверяли.
Третий уровень – продуктовые метрики: scenario completion, abandonment, repeat calls, ошибки маршрутизации и safety-нарушения. Поскольку настоящий ground truth приходит с задержкой, быстрые proxy смотрим постоянно, а на свежей выборке production-звонков регулярно делаем экспертную разметку и пересчитываем метрики.
Для критических показателей заранее определяем не только threshold алерта, но и реакцию на него. Например: рост технических ошибок – переключаемся на fallback; подозрение на drift – сначала проверяем качество данных и свежую размеченную выборку, а не автоматически переобучаем модель».
Ловушка №7: Отсутствие вопросов
Навык ML System Design подразумевает умение задавать вопросы бизнесу. Судьи не выдали сразу все цифры бизнеса в задании, ожидая дополнительные вопросы, которых так и не последовало. Вводные, необходимые для расчётов, были даны только в финале: 45% звонков заканчиваются записью, 3,6 млн записей в год, средняя длительность звонка 4,8 минуты, 420 операторов, среднее ожидание 2,8 минуты, брошенные звонки 11%, нежелательные повторные обращения 8,75%.
Команды вместо общих вопросов, снижающих энтропию, наоборот, уходили в конкретику, которая не влияет на систему. Во время прохождения секции MLSD собеседующий играет роль сразу и представителя бизнеса, и тех. лида, которому можно и нужно задавать уточняющие вопросы.
Главный совет
На собеседовании MLSD обычно очень мало времени. Даже если вы отлично знаете задачу, 40 минут незаметно уйдут просто на то, чтобы нарисовать архитектуру на miro-доске и проговорить пункты. Здесь простой совет: пройдитесь сначала базово по всем этапам, а потом, если останется время, спросите у собеседующего какой аспект необходимо разобрать подробнее. Желаю всем удачи и хороших офферов!
Больше постов про Data Science в TG-канале Data Criminality: без рекламы, инфобизнеса и нейрослопа — пишу только когда есть что сказать.
