The Revenge of the Data Scientist

Is the heyday of the data scientist over? The Harvard Business Review once called it “The Sexiest Job of the 21st Century.”¹ In tech, data scientist roles were often among the best paid.² The job also demanded an unusual mix of skills:

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

Data Scientist (n.): Person who is better at statistics than any software engineer and better at software engineering than any statistician.

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

In addition to creating a high-barrier to entry, these skills enabled data scientists to build predicitive models, measure casuality and find patterns in data. Of these, predicitive modeling paid best. Companies later peeled that work off into a new title: Machine Learning Engineer (“MLE”).³

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

For years, shipping AI meant keeping data scientists and MLEs on the critical path. With LLMs, this stopped being the default. Foundation-model APIs now allow teams to integrate AI independently.

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

Getting cut out of the loop rattled data scientists and MLEs I know. If the company no longer needs you to ship AI, it is fair to wonder whether the job still has the same upside. The harsher story people tell themselves: unless you are pretraining at a foundation-model lab, you are not where the action is.

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

I read it the other way. Training models was never most of the job. The bulk of the work is setting up experiments to test how well the AI generalizes to unseen data, debugging stochastic systems, and designing good metrics. Calling an LLM over an API does not make this work go away.

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

I recently gave a talk titled “The Revenge of the Data Scientist” at PyAI Conf to make that case with examples rather than assertion alone. Below is an annotated version of that presentation.

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

The Harness Is Data Science

Harness — это data science

OpenAI published a blog post on harness engineering that I recommend reading. They describe how Codex worked on a software project for months, autonomously, with agents developing code bounded by a harness of tests and specifications.

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

One detail in that blog post is easy to miss. The harness includes an observability stack: logs, metrics, and traces exposed to the agent so it can tell when it is going off track. In addition to tests and specifications, there are metrics. That is a key component of the system.

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

Andrej Karpathy’s auto-research project shows the same pattern: models iteratively optimize against a validation loss metric. Same idea, different harness.

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

What I want to convince you of is that a large portion of the harness is data science.

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

Let’s take a step back and take stock of where we are.

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

Years ago, practitioners spent hours examining data, checking label alignment, and designing metrics. Today, we build on “vibes,” ask the model if it did a good job, and grab off-the-shelf metric libraries without looking at the data.

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

This shows up most around retrieval and evals. Without a data background, engineers fear what they don’t understand. They claim “RAG is dead” or “evals are dead,” yet build systems that depend on those concepts.

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

The rest of this post walks through five eval pitfalls I see repeatedly, and what a data scientist would do differently in each case.

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

Generic Metrics

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

The first pitfall is generic metrics.

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

It is tempting to reach for an eval framework and use its metrics off the shelf. The problem: you have no idea what is actually broken. Most teams put up a dashboard with helpfulness scores, coherence scores, hallucination scores. These sound reasonable. They are also generic enough to be useless for diagnosing your application’s failures.

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

A data scientist would not adopt metrics off the shelf. They would explore the data, explore the traces, ask “what is actually breaking here?”, and figure out the highest-value thing to start measuring. There are infinite things to measure. You have to form hypotheses and iterate.

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

The best medicine for this pitfall is looking at the data.

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

What does “looking at the data” mean in practice? It means reading traces. Code your own custom trace viewer so you can remove friction and customize the display for your domain’s quirks. Take notes on problems you find. Do error analysis: categorize failures, figure out what to prioritize, decide what to work on.

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

When you look at your data, you end up driving toward application-specific metrics. Off-the-shelf similarity metrics like ROUGE or BLEU rarely fit LLM outputs. The metrics that matter look like “Calendar Scheduling Failure” or “Failure to Escalate To Human.”

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

If there is one thing to take away from this post: look at the data. How to look at it is a separate question and takes practice. This is the higest ROI activity you can engage in and is often skipped.

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

Unverified Judges

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

The second pitfall is unverified judges. A lot of teams use an LLM as a judge to figure out whether their AI is working. Most of the time, nobody has a good answer to “how do you trust the judge?”

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

The default: ask an LLM to rate outputs on a scale and use the numbers. A data scientist would treat the judge like a classifier. You have a black box giving you a prediction. How do you trust it? Get human labels, partition the data into train/dev/test, and measure whether the classifier is trustworthy.

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

Source few-shot examples from your training set. Hill-climb your judge’s prompt against a dev set. Keep a test set aside to confirm you haven’t overfit. If you have done machine learning before, this is boring. But people are not doing it. Verifying classifiers has become a lost art in modern AI.

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

Treat your judge like a classifier in how you report results, too. Everywhere I go I see accuracy reported. If a failure mode occurs 5% of the time, accuracy hides the system’s true performance. Use precision and recall.

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

Bad Experimental Design

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

The third pitfall is experimental design. There are many dimensions to this. Here are two that come up most.

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

The first is constructing test sets. Most teams generate synthetic data by prompting an LLM: “Give me 50 test queries.” They get generic, unrepresentative data. A data scientist would look at real production data first, use hypotheses to determine which dimensions matter, then generate synthetic examples along those dimensions.

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

Ground synthetic data in real logs or traces. Figure out what dimensions to vary. Inject edge cases. Base the synthetic data off real data.

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

The second is metric design. Teams bundle entire rubrics into a single LLM call and default to 1-5 Likert scales. A data scientist would reduce complexity, make each metric actionable, and tie it to a business outcome. Replace subjective scales with binary pass/fail on scoped criteria. Likert scales hide ambiguity and kick the can down the road on hard decisions about system performance.

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

Bad Data and Labels

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

The fourth pitfall is bad data and labels. Data scientists don’t trust the data. They don’t trust the labels. They don’t trust anything. They are skeptical by training. AI engineers at large have not built this muscle yet.

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

When it comes to labeling, most teams make it someone else’s problem. Labeling seems unglamorous, so it gets delegated to the dev team or outsourced. A data scientist would insist that domain experts label the data, stay skeptical of the labels, and look at the data.

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

But labeling matters for a deeper reason than label quality. It is impossible to know what you want unless you look at the data. There is a concept called “criteria drift,” validated in a paper by Shreya Shankar and colleagues: users need criteria to grade outputs, but grading outputs helps users define their criteria. People don’t know what they want until they see the LLM’s outputs. The labeling process itself surfaces what matters.

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

Data scientists champion this: get domain experts and product managers in front of raw data, not summary scores.

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

Automating Too Much

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

The fifth pitfall is automating too much. All of this is human work. The temptation is to automate it away.

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

LLMs can help wire things up, write the plumbing, generate boilerplate for evaluations. They cannot look at the data for you, for the exact reason we just discussed: you don’t know what you want until you see the outputs.

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

Other Pitfalls

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

We did not have time to cover every pitfall. Here is a speed run through the rest.

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

Misusing similarity scores. Asking the judge vague questions like “is it helpful?” Making annotators read raw JSON. Reporting uncalibrated scores without confidence intervals. Data drift, overfitting, not sampling correctly, dashboards that don’t make sense.

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

The Mapping

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

If you zoom out, every pitfall above has the same root cause: missing a data science fundamental.

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

Reading traces and categorizing failures is Exploratory Data Analysis. Validating an LLM judge against human labels is Model Evaluation. Building representative test sets from production data is Experimental Design. Getting domain experts to label outputs is Data Collection. Monitoring whether your product works in production is Production ML. None of this is new. The names changed, the work did not.

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

This is a Python conference, so: Python remains the best toolset for looking at your data and dealing with data.

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

I built an open-source plugin that goes into more depth. Point it at your eval pipeline and it will tell you what you are doing wrong, or try its best to.

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

Always look at the data.

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

If you enjoyed the memes in this talk, there are many more on my website.

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

If you want to go deeper on any of these topics, the slides and video are below.

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

Thanks to Shreya Shankar and Bryan Bischof for many conversations that shaped this talk.

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

Video & Slides

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

Link to the slides

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

Footnotes

Сноски

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