The Revenge of the Data Scientist

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

Data Scientist (сущ.): человек, который разбирается в статистике лучше любого программиста и в программировании лучше любого статистика. — JosH100 (@josh_wills) 3 мая 2012

Помимо высокого порога входа, эти навыки позволяли data scientist’ам строить предиктивные модели, измерять причинно-следственные связи и находить закономерности в данных. Из этого лучше всего оплачивалось именно предиктивное моделирование. Позже компании выделили эту работу в отдельную должность: Machine Learning Engineer («MLE»).3

Годами выпуск AI-продуктов означал, что data scientist’ы и MLE находятся на критическом пути. С появлением LLM это перестало быть правилом по умолчанию. API foundation-моделей теперь позволяют командам интегрировать AI самостоятельно.

Знакомых мне data scientist’ов и MLE выбило из колеи то, что их выводят из контура. Если компании больше не нужны вы, чтобы выпускать AI, резонно задаться вопросом, остаётся ли у этой профессии прежний потенциал. Жёстче люди формулируют это так: если ты не занимаешься претрейнингом в foundation-model лаборатории — ты не там, где происходит самое интересное.

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

Недавно я выступил с докладом «The Revenge of the Data Scientist» на PyAI Conf, чтобы подкрепить этот тезис примерами, а не одними утверждениями. Ниже — аннотированная версия этой презентации.

Harness — это data science

OpenAI опубликовали пост в блоге про harness engineering, который я рекомендую прочитать. Они описывают, как Codex месяцами автономно работал над программным проектом: агенты писали код, ограниченные harness’ом из тестов и спецификаций.

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

Auto-research проект Andrej Karpathy демонстрирует тот же паттерн: модели итеративно оптимизируются по метрике validation loss. Та же идея, другой harness.

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

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

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

Сильнее всего это проявляется вокруг retrieval и evals. Без data-фундамента инженеры боятся того, чего не понимают. Они заявляют, что «RAG умер» или «evals умерли», но при этом строят системы, которые на этих концепциях держатся.

Остальная часть поста — это разбор пяти типичных ошибок в evals, которые я вижу снова и снова, и того, что в каждом случае сделал бы data scientist.

Универсальные метрики

Первая ловушка — универсальные метрики.

Соблазн велик: взять готовый eval-фреймворк и использовать его метрики из коробки. Проблема в том, что вы не понимаете, что на самом деле ломается. Большинство команд вывешивают дашборд с helpfulness-, coherence- и hallucination-скорами. Звучит разумно. Это также достаточно общо, чтобы быть бесполезным для диагностики сбоев вашего приложения.

Data scientist не стал бы брать метрики с полки. Он бы исследовал данные, исследовал трейсы, спросил «а что здесь на самом деле ломается?» и определил, что выгоднее всего начать измерять. Измерять можно бесконечно много чего. Нужно формулировать гипотезы и итеративно их проверять.

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

Что значит «смотреть на данные» на практике? Это значит читать трейсы. Напишите собственный кастомный просмотрщик трейсов, чтобы убрать трение и подогнать отображение под особенности вашего домена. Записывайте найденные проблемы. Делайте error analysis: категоризируйте сбои, определяйте приоритеты, решайте, чем заниматься.

Когда вы смотрите на свои данные, вы естественным образом приходите к метрикам, специфичным для приложения. Готовые метрики похожести вроде ROUGE или BLEU редко подходят для выходов LLM. Метрики, которые имеют значение, выглядят как «Calendar Scheduling Failure» или «Failure to Escalate To Human».

Если из этого поста надо вынести одну мысль: смотрите на данные. Как именно смотреть — отдельный вопрос, требующий практики. Это активность с самым высоким ROI, и её часто пропускают.

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

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

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

Берите few-shot примеры из своего обучающего набора. Подгоняйте промпт судьи по dev-сету. Тестовый набор держите в стороне, чтобы убедиться, что вы не переобучились. Для тех, кто занимался machine learning, это скучно. Но люди этого не делают. Верификация классификаторов в современном AI стала забытым искусством.

Относитесь к судье как к классификатору и в том, как вы отчитываетесь о результатах. Куда ни глянь — все докладывают accuracy. Если режим сбоя возникает в 5% случаев, accuracy скрывает реальную работу системы. Используйте precision и recall.

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

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

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

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

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

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

Четвёртая ловушка — плохие данные и метки. Data scientist’ы не доверяют данным. Они не доверяют меткам. Они не доверяют ничему. Их учат быть скептиками. У AI-инженеров в массе своей эта мышца пока не накачана.

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

Но разметка важна и по более глубокой причине, чем качество меток. Невозможно понять, чего вы хотите, пока не посмотрите на данные. Есть концепция «criteria drift», валидированная в статье Shreya Shankar с соавторами: пользователям нужны критерии, чтобы оценивать выходы, но именно процесс оценки помогает им сформулировать эти критерии. Люди не знают, чего хотят, пока не увидят выходы LLM. Сам процесс разметки выявляет то, что важно.

Data scientist’ы отстаивают именно это: ставьте доменных экспертов и product manager’ов перед сырыми данными, а не перед агрегированными скорами.

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

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

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

Прочие ловушки

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

Неправильное использование метрик похожести. Расплывчатые вопросы судье вроде «полезно ли это?». Принуждение разметчиков читать сырой JSON. Доклад некалиброванных скоров без доверительных интервалов. Data drift, переобучение, неправильная выборка, дашборды, в которых ничего не понятно.

Соответствия

Если отдалить картинку, у каждой ловушки выше один и тот же корень: упущенная фундаментальная вещь из data science.

Чтение трейсов и категоризация сбоев — это Exploratory Data Analysis. Валидация LLM-судьи по человеческим меткам — Model Evaluation. Построение репрезентативных тест-сетов из продакшен-данных — Experimental Design. Привлечение доменных экспертов для разметки выходов — Data Collection. Мониторинг того, работает ли продукт в продакшене, — Production ML. Ничего нового в этом нет. Названия изменились, работа — нет.

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

Я собрал open-source плагин, в котором всё это раскрыто подробнее. Натравите его на свой eval-пайплайн, и он подскажет, что вы делаете не так — по крайней мере, постарается.

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

Если вам понравились мемы из этого доклада, на моём сайте их гораздо больше.

Если хотите глубже погрузиться в любую из этих тем, ниже есть слайды и видео.

Спасибо Shreya Shankar и Bryan Bischof за множество разговоров, которые сформировали этот доклад.

Видео и слайды

Ссылка на слайды

Сноски

https://hbr.org/2012/10/data-scientist-the-sexiest-job-of-the-21st-century↩︎ https://www.forbes.com/sites/louiscolumbus/2018/01/29/data-scientist-is-the-best-job-in-america-according-glassdoors-2018-rankings/↩︎ https://www.mckinsey.com/about-us/new-at-mckinsey-blog/ai-reinvents-tech-talent-opportunities↩︎