В 2026 году data scientist работает с LLM не только через отдельные промпты. Для многошаговой задачи приходится заранее собирать рабочую среду модели: инструкции, файлы с правилами, описание данных, доступные инструменты, память, критерии приемки и ограничения безопасности.
Prompt engineering помогает улучшить конкретный запрос. Context engineering проектирует весь процесс, в котором модель анализирует файлы, пишет код, запускает проверки, исправляет ошибки и передает результат на следующий этап. Качество зависит от связки «модель, данные, правила, инструменты и контроль».
Агентный режим подходит для повторяемых задач с понятными входами, выходами и проверками. Он не превращает LLM в автономного эксперта: специалист по-прежнему отвечает за постановку задачи, смысл интерпретаций, выбор метрик и финальное решение.
Context engineering для data scientist: короткий ответ
Context engineering, или проектирование контекста, описывает организацию информации вокруг модели. В контекст входят роль и цель задачи, постоянные правила проекта, сведения о датасете, документация, структура каталогов, доступные файлы, инструменты, история предыдущих шагов и формат результата.
Представим запрос: «Построй EDA по этому CSV». Модель может создать код, но ей придется угадывать смысл колонок, правила обработки пропусков, допустимость удаления выбросов и формат отчета. В подготовленном контексте эти условия зафиксированы заранее. В нем указано, что нужно проверить схему, типы, дубликаты, временную структуру, возможную утечку целевой переменной и сформировать отчет с нерешенными вопросами.
Главное изменение в работе data scientist связано с переносом усилий. Специалист проектирует процесс, распределяет задачу по навыкам, задает границы доступа и проверяет артефакты. Модель берет на себя часть повторяемых операций. Claude и другие модели могут по-разному работать с файлами, памятью, инструментами и длинными задачами, поэтому каждую связку нужно проверять на собственном сценарии.
Prompt engineering vs context engineering: что именно изменилось
Prompt отвечает за запрос, context - за рабочую среду
Промпт формулирует ближайшее действие: написать функцию, объяснить график, найти ошибку в ноутбуке. Контекст задает условия, при которых это действие должно выполняться.
Для задачи подготовки данных разница выглядит так:
- Запрос: «Очисти таблицу и подготовь признаки для обучения».
- Контекст: описание происхождения данных, типы колонок, целевая переменная, правила работы с пропусками, запрет на использование будущих значений, версия Python, разрешенные библиотеки, ожидаемые файлы и тесты.
Первый вариант просит результат. Второй описывает рабочий процесс и условия приемки. Context engineering включает prompt engineering, поскольку формулировка отдельных инструкций остается частью общей системы.
Из каких слоев состоит контекст
Универсального стандарта для всех агентных LLM-систем нет, но для data science-проекта удобно выделять несколько слоев:
- Роль и цель. Что должна сделать модель и какой вопрос решает команда.
- Правила проекта. Структура каталогов, стиль кода, разрешенные библиотеки, требования к тестам и работе с секретами.
- Описание данных. Происхождение датасета, смысл признаков, типы полей, пропуски, дубликаты, временная структура и ограничения приватности.
- Инструменты и файлы. Репозиторий, ноутбуки, документация, окружение, средства запуска и результаты предыдущих вычислений.
- Память. Решения, принятые на прошлых шагах, открытые вопросы и уже проверенные гипотезы.
- Формат результата. Ноутбук, отчет, Python-модуль, таблица экспериментов или инструкция запуска.
- Критерии приемки. Тесты, метрики, обязательные проверки и список условий, при которых результат нельзя считать готовым.
- Границы доступа. Действия без подтверждения и операции, для которых требуется ручное согласие.
Почему больше контекста не всегда означает лучше
Большая папка документов может ухудшить работу модели. Повторяющиеся правила конкурируют между собой, README устаревает, примеры кода противоречат текущей структуре, а длинная история скрывает свежие ограничения. Растут стоимость вызовов и время проверки.
Рабочий принцип выглядит так: передавать минимально достаточный контекст, указывать приоритеты и удалять устаревшие материалы. Для критичных правил полезно писать явные формулировки: «MUST», «SHOULD», «справочная информация». Если два документа расходятся, модель должна знать, какой из них считается источником истины.
Как спроектировать контекст для data science-проекта
Базовый файл с правилами проекта
Начните с короткого файла, который лежит рядом с кодом и обновляется вместе с проектом. В него можно включить:
- назначение проекта и описание целевого результата;
- структуру каталогов и правила именования;
- версию Python и разрешенные библиотеки;
- формат кода, требования к тестам и логированию;
- правила работы с секретами и персональными данными;
- команды для запуска проверок;
- критерии завершения задачи.
Разделите обязательные ограничения и предпочтения. Запрет на утечку целевой переменной должен иметь более высокий приоритет, чем пожелание использовать конкретный стиль визуализации.
Документация по данным и метрикам
Модель не должна угадывать семантику колонок. Для каждого важного поля укажите смысл, тип, единицу измерения, допустимый диапазон и связь с целевой переменной. Отдельно опишите происхождение данных, дату среза, порядок появления событий, правила анонимизации и известные ограничения выборки.
Для экспериментов зафиксируйте baseline, схему валидации, целевую метрику, допустимое время обучения, лимит памяти и правила сравнения моделей. Accuracy без контекста не говорит, подходит ли решение для несбалансированных классов. Временной ряд нельзя оценивать тем же способом, что и независимые случайные наблюдения.
Разбиение работы на отдельные навыки
Один длинный промпт быстро превращается в список конфликтующих пожеланий. Удобнее разделить процесс на модули:
| Навык | Вход | Артефакт | Проверка |
|---|---|---|---|
| Аудит данных | Схема и образец датасета | Отчет о качестве и список рисков | Проверены типы, пропуски, дубликаты и утечки |
| Подготовка | Правила преобразований | Код трансформаций | Тесты на схему и диапазоны значений |
| EDA | Очищенные данные и шаблон отчета | Ноутбук с графиками и оговорками | Выводы отделены от гипотез |
| Baseline | Разбиение и метрика | Воспроизводимый эксперимент | Результат сопоставлен с базовой линией |
| Упаковка кода | Рабочий ноутбук и требования среды | Модуль или сервис | Тесты, конфигурация и инструкция запуска |
Для каждого навыка задайте входы, действия, запрещенные шаги, выходной артефакт и критерии приемки. Такой формат облегчает повторный запуск и позволяет заменить один модуль без переписывания всего контекста.
Инструменты, память и границы доступа
Агентный сценарий может работать с репозиторием, ноутбуками, документацией, окружением и результатами прошлых запусков. Доступ к каждому ресурсу нужно описать отдельно. Чтение конфигурации и запуск дешевого теста обычно имеют меньший риск, чем удаление данных, изменение зависимостей или старт длительного обучения.
Подтверждение требуется для удаления файлов, публикации кода, работы с секретами, изменения схемы данных и дорогих вычислений. В контекст лучше передавать обезличенные примеры, а секреты хранить вне истории диалога. Практика ведения базы знаний с сущностями, дедупликацией и provenance показывает, почему происхождение каждого факта нужно сохранять при многошаговой работе: разбор конвейера сборки персональной книги знаний.
Как context engineering меняет типичные задачи data scientist
Подготовка данных: от разового скрипта к управляемому процессу
Агент может последовательно проверить схему, типы, пропуски, выбросы, дубликаты и подозрительные признаки. В контексте заранее указываются допустимые преобразования и запреты. Например, заполнение пропусков медианой допустимо для одного числового поля, но недопустимо для признака, где отсутствие значения само по себе несет смысл.
Результатом должен стать комплект артефактов: отчет аудита, код трансформаций и список вопросов. Удаление строк, изменение целевой переменной и спорные способы обработки выбросов требуют согласования. Агент может подготовить варианты, но решение зависит от происхождения данных и предметной области.
EDA: агент формирует гипотезы, специалист проверяет интерпретацию
При заданном шаблоне агент способен построить сводки, распределения, базовые визуализации и список аномалий. Контекст должен задать обязательные срезы: по времени, сегментам, источникам данных и целевой переменной.
Корреляция не доказывает причинность. Резкий рост показателя может быть следствием изменения схемы сбора, а не поведения пользователей. Специалист проверяет происхождение наблюдения, сопоставляет его с бизнес-событиями и отделяет подтвержденные факты от гипотез.
Настройка окружения и зависимости
Код из чата часто не запускается из-за несовпадения версии Python, отсутствующей библиотеки, другой структуры проекта или ограничений операционной системы. Контекст должен содержать способ запуска, список зависимостей, доступные ресурсы и правила воспроизводимости.
Безопасный порядок действий такой: сначала диагностировать среду, затем предложить минимальное изменение, выполнить проверку и зафиксировать результат. Агент не должен самостоятельно обновлять весь стек зависимостей ради одной ошибки импорта. Для работы с проектными файлами полезен отдельный агентный интерфейс с контролем изменений, например разбор Koda Desktop для работы с файлами, логами и документами. Конкретные возможности такого инструмента нужно сверять с его текущей документацией и настройками.
Обучение моделей и анализ экспериментов
Перед запуском эксперимента зафиксируйте схему валидации, baseline, метрику, лимит вычислений и правила работы с временными или несбалансированными данными. Агент может составить план, подготовить конфигурации, запустить серию экспериментов и собрать таблицу результатов.
Выбор допущений остается за data scientist. Рост метрики на одной случайной выборке не гарантирует улучшения решения. В отчете нужно хранить параметры, версии кода и данных, длительность запуска, ошибки и анализ случаев, где модель ошиблась.
Ноутбук и продакшен-код: разные требования к результату
Ноутбук рассчитан на быстрые итерации, визуальное исследование и последовательное выполнение ячеек. Продакшен-код требует тестируемости, конфигурации, логирования, обработки ошибок, контроля зависимостей и воспроизводимого запуска.
Фраза «сделай рабочий код» недостаточно точна. В контексте нужно указать целевой формат: ноутбук для исследования, Python-модуль для пайплайна или сервис с интерфейсом запуска. Перенос кода из ноутбука в сервис без тестов и проверки данных создает технический долг, даже если пример сразу выполняется.
Как уменьшить противоречия в инструкциях и повысить надежность
Разделяйте обязательные правила, предпочтения и справочную информацию
Используйте три уровня:
- MUST: обязательные условия, например запрет на утечку будущих значений;
- SHOULD: предпочтения, например использование существующего логгера;
- REFERENCE: справочные сведения, которые помогают интерпретировать данные.
Каждое критичное правило связывайте с проверкой. Требование «код должен быть надежным» расплывчато. Требование «добавить тест на отсутствие колонок, появившихся после даты прогноза» можно проверить.
Фиксируйте один источник истины
Назначьте отдельный документ для правил данных, окружения, метрик и формата кода. README, конфигурация и инструкции агента не должны содержать три разные версии одной политики.
Устаревшее правило удаляйте или помечайте датой и статусом. Если модель видит противоречие, она должна остановиться и задать вопрос, а не выбирать случайную формулировку.
Проверяйте каждый этап через артефакт
Результат нужно принимать по файлу, тесту или метрике. Для аудита данных это отчет и список рисков. Для EDA, ноутбук с графиками и оговорками. Для обучения, таблица экспериментов и анализ ошибок. Для продакшен-кода, тесты и инструкция запуска.
Паттерны с отдельной проверкой, агентом-скептиком и трассировкой действий помогают сделать ошибки заметнее. Практический разбор архитектуры LLM-агентов с верификацией показывает, как разделять генерацию результата и его контроль: архитектура LLM-агентов с верификацией.
Когда нужен agentic LLM для data science, а когда хватит обычного запроса
Признаки задачи, которую можно передать агенту
- Задача состоит из нескольких связанных операций.
- Процесс повторяется на похожих наборах данных.
- Есть фиксированный формат результата.
- Доступны тесты, метрики или чек-лист проверки.
- Файлы и инструменты можно ограничить.
- Человек понимает, как принять или отклонить результат.
Пример подходящего сценария: проверить схему нового CSV, сформировать отчет о качестве, создать черновик EDA и сохранить список вопросов для аналитика. На каждом шаге агент оставляет артефакт, а специалист подтверждает переход дальше.
Признаки задачи, где агентный режим избыточен
Обычный чат-запрос быстрее для объяснения концепции, разовой правки, генерации небольшой функции или обсуждения вариантов. Агентный режим добавляет оркестрацию, доступ к файлам и промежуточные действия. Если этих компонентов нет, сложность не окупается.
Агент плохо подходит для задачи с неполными вводными, неформализованным исследовательским решением или высокой ценой незаметной ошибки. Особенно осторожно нужно работать с изменением исходных данных, публикацией выводов и действиями, которые нельзя отменить.
Матрица выбора: сложность, автономность и цена ошибки
| Сложность | Автономность | Цена ошибки | Режим |
|---|---|---|---|
| Низкая | Любая | Низкая | Обычный запрос |
| Средняя | Ограниченная | Средняя | Агент по этапам с проверками |
| Высокая | Ограниченная | Высокая | Пошаговый агент и обязательное подтверждение |
| Высокая | Широкая | Высокая | Автономный запуск не оправдан |
Число файлов и инструментов увеличивает сложность. Цена ошибки определяется последствиями: испорченная временная копия данных и неверный вывод для публикации требуют разного уровня контроля.
Ограничения context engineering: где заканчивается автоматизация
Контекст не исправляет плохие данные и неверные постановки
Хорошо оформленный процесс может выдать убедительный, но бесполезный результат, если выборка смещена, целевая метрика неверна или описание данных неполно. Модель оформит ошибочное допущение аккуратно. Формат отчета не превращает его в правильное решение.
Воспроизводимость требует контроля версий и окружения
Сохраненный промпт не гарантирует повторяемость эксперимента. Для воспроизводимости нужны версии кода, данных, инструкций, зависимостей, параметров запуска и результатов. Следует фиксировать случайные зерна там, где это имеет смысл, и хранить сведения об аппаратной среде, если она влияет на результат.
Приватность, доступы и опасные действия
Перед передачей данных модели удалите секреты и по возможности обезличьте персональную информацию. Выдавайте минимальные права, разделяйте чтение и запись, ограничивайте каталоги и требуйте подтверждение необратимых операций.
Галлюцинации, ошибки в коде и неверная интерпретация сохраняются даже при аккуратной структуре контекста. Возможности Claude и других моделей зависят от конкретной версии, интерфейса, настроек и подключенных инструментов. Проверять нужно фактическое поведение в собственном процессе, а не переносить обещания из описания продукта.
Практический чек-лист внедрения в рабочий процесс
Начните с одной повторяемой задачи
Выберите аудит схемы данных, черновик EDA или проверку структуры ноутбука. У задачи должны быть понятные входы и выходы. Не начинайте с полного цикла обучения и публикации модели: у него слишком много зависимостей и точек отказа.
Опишите контекст и критерии приемки
Перед запуском запишите цель, источники, ограничения, доступные инструменты, ожидаемые файлы, обязательные тесты и вопросы, которые запрещено решать догадкой. Отдельно укажите действия, требующие подтверждения.
Сравните агентный и обычный сценарий
Для нескольких одинаковых задач сравните время, объем ручной работы, число исправлений, прозрачность результата и риски. Используйте критерии собственного процесса. Универсальные бенчмарки не заменяют проверку на ваших данных и в вашем окружении.
Обновляйте контекст как часть инженерной работы
Версионируйте инструкции, удаляйте устаревшие правила, фиксируйте исключения и пересматривайте сценарий после изменений в данных, коде, окружении или метриках. Расширяйте автономность после оценки качества и стоимости ошибок.
- Выберите одну повторяемую задачу.
- Соберите минимальный контекст проекта.
- Разделите процесс на навыки и этапы.
- Задайте артефакт и проверку для каждого этапа.
- Ограничьте доступы и добавьте подтверждение опасных действий.
- Сравните агентный сценарий с обычным запросом.
- Зафиксируйте результат и изменения в журнале.
Итоги: главная новая компетенция data scientist
В 2026 году context engineering делает data scientist проектировщиком рабочей среды для LLM. Специалисту нужно уметь описывать данные, формализовать правила, разделять процесс на модульные навыки, управлять памятью и доступами, задавать критерии качества и проверять артефакты.
Prompt остается инструментом для отдельных действий. Агентный режим оправдан там, где есть многошаговый процесс, доступные проверки и контролируемая цена ошибки. В остальных случаях обычный запрос дает более прозрачный и экономный путь.
Качество результата определяется связкой модели с данными, документацией, инструментами и человеческой проверкой. Правильный контекст снижает количество неоднозначностей, но не отменяет аналитическое мышление, MLOps и ответственность за решение.