Месть дата-сайентиста: почему LLM не отменили нашу профессию

Закончилась ли золотая эпоха дата-сайентистов? Когда-то Harvard Business Review назвал эту профессию «самой сексуальной работой XXI века». В технологической индустрии позиции data scientist часто входили в число самых высокооплачиваемых. При этом работа требовала необычного сочетания навыков:

Data Scientist (сущ.): человек, который знает статистику лучше любого разработчика и разбирается в разработке лучше любого статистика.

— JosH100 (@josh_wills), 3 мая 2012 года ^[1]

Эти навыки не только поднимали порог входа в профессию. Они позволяли дата-сайентистам строить предиктивные модели, измерять причинно-следственные связи и находить закономерности в данных. Из всего этого лучше всего оплачивалось именно предиктивное моделирование. Позже компании выделили такую работу в отдельную роль — Machine Learning Engineer, или MLE.

Много лет выпуск AI-продуктов держался на дата-сайентистах и MLE: без них проект просто не проходил по критическому пути. С приходом LLM ^[2] это перестало быть правилом по умолчанию. API foundation-моделей позволяют командам встраивать AI самостоятельно.

То, что дата-сайентистов и MLE начали вырезать из процесса, заметно встревожило многих моих знакомых из этих областей. Если компании больше не нужны вы, чтобы выпускать AI, резонно спросить: остался ли у этой роли прежний потенциал? Более жёсткая версия этой мысли звучит так: если вы не занимаетесь предварительным обучением ^[3] в лаборатории фундаментальных моделей, то вы больше не в центре событий.

Я смотрю на это иначе. Обучение моделей никогда не было основной частью работы. Большая часть задач — это постановка экспериментов, которые проверяют, насколько хорошо AI обобщает на новые данные, отладка стохастических систем и проектирование хороших метрик. Вызов LLM через API никуда эту работу не убирает.

Недавно я выступил на PyAI Conf ^[4] с докладом «Реванш дата-сайентиста» и попытался показать это не только тезисами, но и примерами. Ниже — аннотированная версия этой презентации.

Harness — это data science

OpenAI недавно опубликовала статью ^[5] про harness engineering («инжиниринг обвязки»), я советую ее прочитать. Там описывается, как Codex месяцами автономно работал над software-проектом: агенты писали код, а их работа была ограничена harness — набором тестов и спецификаций.

В этой статье есть деталь, которую легко пропустить. Harness включает observability-стек: логи, метрики и трейсы, доступные агенту, чтобы он мог понять, что начинает уходить не туда. Помимо тестов и спецификаций, в системе есть метрики. И это ключевой компонент всей конструкции.

Проект auto-research ^[6] Андрея Карпатого показывает тот же паттерн: модели итеративно оптимизируются по метрике валидационная потеря. Та же идея, просто другой harness.

Я хочу убедить вас в том, что значительная часть harness — это data science.

Давайте сделаем шаг назад и посмотрим, где мы сейчас оказались.

Несколько лет назад практики часами разбирали данные, проверяли соответствие разметки и проектировали метрики. Сегодня мы часто строим всё «по ощущениям», спрашиваем модель, хорошо ли она справилась, и берём готовые библиотеки метрик, даже не заглянув в данные.

Особенно хорошо это видно вокруг retrieval и evals. Инженеры без бэкграунда в данных боятся того, чего не понимают. Они заявляют, что «RAG умер» или «evals умерли», но при этом строят системы, которые зависят от этих же концепций.

Дальше в статье я разберу пять типичных ловушек в evals, которые часто встречаю, и покажу, что в каждом случае дата-сайентист сделал бы иначе.

Общие метрики

Первая ловушка — общие метрики.

Очень соблазнительно взять eval-фреймворк и использовать его метрики «из коробки». Проблема в том, что вы не понимаете, что именно у вас сломано. Большинство команд поднимают дашборд с оценками полезности, связности и галлюцинаций. Звучит разумно. Но эти метрики настолько общие, что почти бесполезны для диагностики сбоев именно в вашем приложении.

Дата-сайентист не стал бы брать метрики «из коробки» без вопросов. Он бы сначала изучил данные, посмотрел трейсы, спросил: «А что у нас здесь на самом деле ломается?» — и понял, какую самую ценную вещь стоит начать измерять. Измерять можно бесконечно много всего. Поэтому приходится формулировать гипотезы и итеративно их проверять.

Лучшее лекарство от этой ловушки — смотреть в данные.

Что на практике значит «смотреть в данные»? Это значит читать трейсы. Напишите собственный trace viewer (просмотрщик трейсов), чтобы убрать лишнее трение и настроить отображение под особенности вашей предметной области. Фиксируйте найденные проблемы. Делайте анализ ошибок: классифицируйте сбои, определяйте приоритеты и решайте, за что браться дальше.

Когда вы смотрите в свои данные, вы неизбежно приходите к метрикам, специфичным для вашего приложения. Готовые метрики похожести вроде ROUGE или BLEU редко хорошо подходят для ответов LLM. Нужные метрики обычно выглядят как «ошибка при планировании встречи в календаре» или «не передали пользователя человеку, хотя надо было».

Если из этой статьи стоит вынести одну мысль, то вот она: смотрите в данные. Как именно в них смотреть — отдельный вопрос, и этому нужно учиться на практике. Но это занятие с максимальной отдачей, которое при этом часто пропускают.

Непроверенные судьи

Вторая ловушка — непроверенные judge-модели. Многие команды используют LLM в роли судьи, чтобы понять, работает ли их AI. Но чаще всего у них нет хорошего ответа на вопрос: «А почему вы доверяете этому судье?»

Типичный подход такой: попросить LLM оценить ответы по шкале и использовать получившиеся числа. Дата-сайентист отнёсся бы к judge-модели как к классификатору. У вас есть чёрный ящик, который выдаёт предсказание. Как понять, можно ли ему доверять? Собрать человеческую разметку, разделить данные на train/dev/test и измерить, насколько этот классификатор надёжен.

Берите несколько примеров из train-сета. Итеративно улучшайте промпт judge-модели на dev-выборке. Держите отдельную тестовую выборку, чтобы проверить, что вы не переобучились. Если вы раньше занимались машинным обучением, всё это звучит скучно. Но люди так не делают. В современной AI-разработке проверка классификаторов стала почти забытым искусством.

И результаты judge-модели тоже показывайте так, как показывали бы результаты классификатора. Куда ни посмотри, везде отчитываются по точности. Если нужный сценарий отказа встречается в 5% случаев, общая точность скрывает реальное качество системы. Используйте точность и полноту.

Плохой дизайн экспериментов

Третья ловушка — дизайн экспериментов. У неё много измерений. Вот два, которые всплывают чаще всего.

Первое — построение тестовой выборки. Большинство команд генерируют синтетические данные простым промптом к LLM: «Дай мне 50 тестовых запросов». На выходе получают общие, нерепрезентативные данные. Дата-сайентист сначала посмотрел бы на реальные production-данные, через гипотезы определил бы важные измерения, а уже потом сгенерировал бы синтетические примеры вдоль этих измерений.

Привязывайте синтетические данные к реальным логам или трейсами. Поймите, какие измерения нужно варьировать. Добавляйте пограничные случаи. Стройте синтетические данные на основе реальных.

Второе — дизайн метрик. Команды запихивают целые рубрики в один LLM-вызов и по умолчанию используют шкалы Лайкерта от 1 до 5. Дата-сайентист снизил бы сложность, сделал бы каждую метрику пригодной для действия и связал бы её с бизнес-результатом. Заменяйте субъективные шкалы бинарной оценкой pass/fail по чётко ограниченным критериям. Шкалы Лайкерта прячут неоднозначность и откладывают трудные решения о качестве системы на потом.

Плохие данные и разметка

Четвёртая ловушка — плохие данные и плохая разметка. Дата-сайентисты не доверяют данным. Не доверяют разметке. Вообще ничему не доверяют. Их этому учат. У AI-инженеров в целом этот навык пока не наработан.

Когда дело доходит до разметки, большинство команд перекладывают её на кого-то другого. Разметка кажется неблагодарной работой, поэтому её отдают dev-команде или выносят на аутсорс. Дата-сайентист настоял бы, чтобы данные размечали доменные эксперты, сам относился бы к разметке скептически и обязательно смотрел бы в данные.

Но разметка важна не только потому, что от неё зависит качество разметки. Есть более глубокая причина: невозможно понять, чего вы хотите, пока вы не посмотрели на данные. Есть понятие сдвига критериев (criteria drift) — его подтвердили в статье ^[7] Шреи Шанкар и коллег: пользователям нужны критерии, чтобы оценивать ответы, но сама оценка ответов помогает пользователям эти критерии сформулировать. Люди не знают, чего хотят, пока не увидят ответы LLM. Сам процесс разметки вытаскивает наружу то, что действительно важно.

Дата-сайентисты как раз за это и бьются: посадить доменных экспертов и продакт-менеджеров перед сырыми данными, а не перед агрегированными оценками.

Слишком много автоматизации

Пятая ловушка — слишком много автоматизации. Всё это человеческая работа. И очень хочется автоматизировать её целиком.

LLM могут помочь связать компоненты, написать обвязку, сгенерировать шаблонный код для оценок. Но они не могут посмотреть в данные за вас — ровно по той причине, о которой мы только что говорили: вы не знаете, чего хотите, пока не увидите выходные данные.

Другие ловушки

Мы не успели разобрать все ловушки. Пройдёмся по остальным коротко.

Неправильное использование оценки схожести. Расплывчатые вопросы judge-модели вроде «это полезно?». Заставлять аннотаторов читать сырой JSON. Репортить некалиброванные оценки без доверительных интервалов. Дрейф данных, переобучение, неправильная выборка, дашборды, в которых невозможно разобраться.

Карта соответствий

Если отойти на шаг назад, у всех ловушек выше одна и та же первопричина: в системе не хватает базовых вещей из data science.

Чтение трейсов и классификация сбоев — это разведочный анализ данных. Проверка LLM-судьи на человеческой разметке — оценка модели. Построение репрезентативных тестовых выборок на основе производственных данных — проектирование экспериментов. Привлечение доменных экспертов к разметке выходных данных — сбор данных. Мониторинг того, работает ли продукт в производственной среде, — производственное машинное обучение. ^[8] Ничего из этого не ново. Названия поменялись, работа осталась прежней.

Поскольку конференция посвящена Python, скажу отдельно: Python по-прежнему остаётся лучшим набором инструментов, чтобы смотреть в данные и работать с данными.

Я сделал open-source-плагин ^[9], где разбираю это подробнее. Направьте его на свой eval pipeline, и он расскажет, что вы делаете неправильно. Ну или хотя бы очень постарается.

Всегда смотрите в данные.

---

Эти темы можно продолжить на бесплатных уроках – преподаватели-практики покажут, как устроены мониторинг распределённых систем и инженерная обвязка ИИ-агентов. Заодно можно познакомиться с форматом обучения и задать вопросы экспертам.

• 10 июня, 20:00. «Мониторинг распределённых систем». Записаться ^[10]

• 15 июня, 20:00. «Интеграция ИИ-агентов в рабочую разработку: обвязка агента навыками и MCP». Записаться ^[11]

Больше бесплатных уроков июня смотрите в дайджесте. ^[12]