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

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 (сущ.): человек, который разбирается в статистике лучше любого software engineer и в software engineering лучше любого статистика. — 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.

Авто-исследовательский проект 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. Без бэкграунда в данных инженеры боятся того, чего не понимают. Они заявляют, что «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

Generic-метрики

The first pitfall is generic metrics.

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

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. Звучит разумно. Они также достаточно generic, чтобы быть бесполезными для диагностики провалов именно вашего приложения.

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.

Что значит «смотреть на данные» на практике? Это значит читать трейсы. Написать собственный кастомный viewer трейсов, чтобы убрать трение и настроить отображение под особенности вашего домена. Делать заметки о найденных проблемах. Проводить 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.

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

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 в роли судьи, чтобы понять, работает ли их 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 примеры из своего training-сета. Hill-climbing’ом улучшайте промпт судьи против dev-сета. Держите test-сет в стороне, чтобы убедиться, что не переобучились. Если вы раньше занимались 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 тестовых запросов». Они получают generic, нерепрезентативные данные. 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 cases. Базируйте синтетические данные на реальных.

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-вызов и по умолчанию используют шкалы Лайкерта 1–5. Data scientist уменьшил бы сложность, сделал бы каждую метрику actionable и привязал бы её к бизнес-исходу. Заменяйте субъективные шкалы бинарными pass/fail по чётко ограниченным критериям. Шкалы Лайкерта прячут двусмысленность и откладывают трудные решения о производительности системы.

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.

Когда дело доходит до разметки, большинство команд делают её чьей-то чужой проблемой. Разметка кажется неблагодарной работой, поэтому её делегируют команде разработки или отдают на аутсорс. 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-менеджеров перед сырыми данными, а не перед сводными оценками.

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