ML System Design: что действительно оценивают на собеседовании
В эпоху кодинг-агентов роль разработчика постепенно смещается от написания отдельных фрагментов кода к проектированию сложных архитектур. Поэтому навык ML System Design становится особенно важным для Data Scientist и ML Engineer. На позициях уровня middle и выше работодателю важно понять не только, умеете ли вы выбрать модель, но и способны ли связать бизнес-цели, данные, алгоритмы, инфраструктуру, оценку качества и мониторинг в единую систему.
Формат проверки бывает разным. Иногда кандидату дают час или полтора на полноценный кейс в Miro или на виртуальной доске. В других случаях на финальном этапе оставляют всего 20-30 минут. Второй вариант сложнее: за короткое время необходимо показать ход мыслей, задать правильные вопросы и при этом не утонуть в технических деталях. Именно поэтому ML System Design собеседование требует отдельной подготовки, а не сводится к повторению теории по моделям и метрикам.
Полезный материал для такой подготовки - разбор типовых ошибок в задаче проектирования ML-системы: практический анализ ML System Design интервью. Он показывает, почему даже сильные команды теряют баллы не из-за неправильного выбора алгоритма, а из-за пропущенных этапов проектирования.
Начинать нужно с цели, а не с модели
Одна из самых распространённых ошибок - немедленный переход к обсуждению данных, архитектуры нейросети и инференса. Такой подход выглядит технически убедительно, но не гарантирует, что система решает нужную бизнес-задачу.
Например, в кейсе с голосовым медицинским агентом сначала следует выяснить:
- какую проблему бизнеса необходимо устранить;
- где компания теряет деньги или клиентов;
- кто будет пользоваться системой;
- какой сценарий считается успешным;
- где заканчивается зона ответственности агента.
Причины для внедрения могут быть разными: перегруженный call-центр, длительное ожидание, высокая доля пропущенных звонков, ошибки маршрутизации или слишком большая стоимость обработки обращения. От ответа зависит и итоговая архитектура. В одном случае приоритетом станет снижение нагрузки на операторов, в другом - сокращение времени ожидания или рост числа корректно оформленных записей.
Важно понять, что именно хочет сделать пользователь. Пациент может звонить, чтобы записаться на плановый приём, перенести визит, узнать информацию о существующей записи, выбрать специалиста или сообщить о срочной проблеме. Для каждого сценария потребуются разные данные, правила эскалации и критерии качества.
Метрики должны вытекать из бизнес-смысла
Нельзя объявлять главной метрикой количество записей, если агент должен прежде всего правильно решать проблему пациента. В противном случае система начнёт оптимизироваться под формальный показатель и подталкивать людей к записи даже тогда, когда она им не нужна.
В зависимости от задачи целевыми показателями могут стать:
- доля обращений, успешно завершённых без оператора;
- точность маршрутизации;
- среднее время ожидания;
- процент брошенных звонков;
- стоимость обработки обращения;
- удовлетворённость пользователей;
- доля клиентов, действительно решивших свой вопрос.
На собеседовании по ML System Design важно также проговорить компромиссы. Например, максимальная автоматизация может ухудшить пользовательский опыт, а чрезмерно осторожная система будет слишком часто передавать диалоги оператору. Хороший кандидат не просто перечисляет метрики, а объясняет, какая из них основная, какие являются ограничениями и как они связаны с экономикой продукта.
Цена ошибки важнее красивой средней метрики
Одинаковая ошибка может иметь совершенно разную стоимость. Неверно распознанная просьба перенести запись неприятна, но обычно обратима. Ошибка при обработке сообщения о неотложном состоянии может привести к серьёзным последствиям.
Поэтому архитектура должна учитывать классы риска:
- критические обращения необходимо передавать человеку;
- медицинские рекомендации нельзя выдавать без предусмотренных ограничений;
- при низкой уверенности модель должна задавать уточняющий вопрос или использовать эскалацию;
- для чувствительных сценариев нужны дополнительные проверки и журналирование.
Такой подход показывает зрелое понимание ML-системы: её качество определяется не только средней accuracy, но и тем, какие именно ошибки она совершает, как часто они возникают и что происходит после них.
Данные - это часть продукта
Даже сильная модель не компенсирует плохие данные. На интервью стоит заранее обсудить источники информации, их качество и ограничения: записи разговоров, расшифровки, историю обращений, расписание врачей, справочники услуг и результаты работы операторов.
Особое внимание следует уделить разметке. Необходимо определить, кто и как будет отмечать намерение пользователя, успешность диалога, факт корректной маршрутизации и причины передачи оператору. В реальной системе полезно закладывать цикл обратной связи: сложные случаи отправляются на разбор, исправления пополняют обучающую выборку, а новые версии модели проверяются на стабильном наборе данных.
Нельзя забывать о смещениях. Данные могут хуже представлять отдельные акценты, возрастные группы, шумные помещения или нестандартные формулировки. Если это не учитывать, модель будет демонстрировать хорошие средние результаты, но регулярно ошибаться на важных сегментах.
Не следует начинать с универсального LLM-агента
Ещё одна типичная ловушка - попытка сразу построить универсального агента, который умеет вести любой диалог и самостоятельно выполнять все действия. Для первого релиза разумнее ограничить область применения несколькими наиболее частыми сценариями.
MVP может поддерживать, например, запись и перенос визита, а сложные вопросы передавать оператору. Для этого потребуются классификатор намерения, распознавание речи, диалоговый модуль, интеграция с расписанием и механизм безопасной эскалации. Такой дизайн проще тестировать, контролировать и постепенно расширять.
LLM может использоваться там, где нужны гибкость и понимание свободной речи, но критические операции лучше ограничивать инструментами, правилами и строгими схемами вызова API. Это снижает риск выдуманных ответов и некорректных изменений в информационных системах.
Валидация начинается до запуска
До внедрения необходимо определить уровни проверки: офлайн-тестирование на отложенной выборке, симуляции диалогов, проверка отдельных компонентов и пилот на ограниченной группе пользователей. Нельзя оценивать только модель распознавания или только качество текста - проверять нужно полный сценарий от звонка до результата.
При раскатке полезны поэтапные стратегии: shadow mode, запуск на небольшой доле трафика, A/B-тестирование и ручной контроль критических обращений. Следует заранее определить условия остановки эксперимента: рост жалоб, увеличение числа ошибок, ухудшение конверсии или превышение допустимой доли эскалаций.
После запуска работа не заканчивается. Распределение данных меняется, пользователи начинают формулировать запросы иначе, обновляются расписания и бизнес-правила. Поэтому нужны мониторинг качества, задержки, стоимости инференса, доли отказов и частоты передачи оператору. Полезно отслеживать также дрейф данных и регулярно пересматривать тестовые наборы.
Вопросы кандидата - показатель системного мышления
На вопросы на собеседовании по ML System Design нельзя отвечать механически. Не менее важно самому задавать вопросы интервьюеру: какова основная бизнес-цель, какой объём трафика ожидается, насколько критичны ошибки, есть ли исторические данные, какие ограничения предъявляются к задержке и стоимости, кто отвечает за ручную проверку?
Если условие задачи неполное, это не препятствие, а возможность показать инженерный подход. Нужно зафиксировать допущения, обозначить альтернативы и объяснить, какие данные помогли бы принять окончательное решение. Такой формат ответа обычно сильнее, чем попытка угадать единственно правильную архитектуру.
Эффективная подготовка к ML System Design интервью должна включать тренировку полного цикла: формулировку цели, выделение пользователей, описание ограничений, выбор метрик, проектирование данных и моделей, оценку стоимости ошибок, план валидации и стратегию мониторинга. Практика на ограниченных по времени кейсах особенно полезна: она учит расставлять приоритеты и не уходить слишком глубоко в детали раньше времени.
Для системной подготовки можно использовать специализированный курс по ML System Design, разборы реальных кейсов и собственные тренировочные заметки. Главное - учиться не запоминать шаблоны, а последовательно обосновывать решения. Наиболее сильный ответ на архитектура ML систем собеседование демонстрирует не набор модных технологий, а способность построить надёжный, измеримый и экономически оправданный продукт.
