The Revenge of the Data Scientist – Hamel’s Blog - Hamel Husain

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

Data Scientist (сущ.): человек, который разбирается в статистике лучше любого software engineer и в software engineering лучше любого статистика. — 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-стек: логи, метрики и трейсы, которые видны агенту, чтобы он мог понять, когда сходит с правильного пути. Помимо тестов и спецификаций, есть и метрики. Это ключевой компонент системы.

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

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

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

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

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

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

Generic-метрики

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

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

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

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

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

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

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

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

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

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

Берите few-shot примеры из своего training-сета. Hill-climbing’ом улучшайте промпт судьи против dev-сета. Держите test-сет в стороне, чтобы убедиться, что не переобучились. Если вы раньше занимались machine learning, всё это скучно. Но люди этого не делают. Валидация классификаторов стала утерянным искусством в современном AI.

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

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

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

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

Заземляйте синтетические данные в реальных логах или трейсах. Разберитесь, какие измерения варьировать. Внедряйте edge cases. Базируйте синтетические данные на реальных.

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

Плохие данные и лейблы

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

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

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

Data scientist’ы отстаивают это: усаживайте доменных экспертов и product-менеджеров перед сырыми данными, а не перед сводными оценками.

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

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

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↩︎