Источник статьи: Data teams should become context teams

Table of Contents

Data-команды должны стать командами контекста

Context engineering = управление данными + инженерия данных + наука о данных.

Помните, как ваша компания подключила BI-инструмент напрямую к продакшен-базе данных? Цифры постоянно были неверными. Никто не доверял дашбордам — поэтому мы построили data-стэки, чтобы это исправить.

AI-агенты сегодня — это эквивалент BI-инструментов, подключённых к продакшен-БД. Теперь у каждой компании есть внутренние AI-агенты, подключённые к сырым источникам контекста: дискам, Notion, почте. Это вроде бы работает, но полностью доверять ответам нельзя.

Context engineering — это создание источников истины для всех знаний компании надёжным и эффективным способом. И именно этим data-команды занимались с данными на протяжении многих лет.

Context engineering требует ключевых навыков, которыми обладают data-команды:

Context Engineering = управление данными + инженерия данных + наука о данных
Context engineering требует управления для определения источников истины контекста
Context engineering требует инженерии для их загрузки и консолидации
Context engineering требует науки для измерения и повышения надёжности AI

Что такое context engineering?

Context engineering направлен на создание оптимального контекста для AI-агентов.

Что такое оптимальный контекст для агента?

Доля ответов: процент вопросов, на которые агент действительно может ответить
Точность: процент ответов, которые являются корректными
Стоимость: расходы на LLM, которые несёт агент
Скорость: насколько быстро агент отвечает

Какие компромиссы нужно оптимизировать?

Слишком мало контекста → неправильные ответы или их отсутствие.
Агент знает недостаточно. Он галлюцинирует, упускает нюансы или полностью сдаётся.

Слишком много контекста → дорого и запутанно.

Входные токены могут очень быстро увеличить счёт за LLM (1 миллион токенов в Claude Opus 4.5 стоит $5). Вызов с большим объёмом контекста легко может отправлять 50–100 тыс. токенов на один запрос, что будет стоить ~50 центов. И помимо стоимости, нерелевантный контекст размывает сигнал — модель путается в шуме.

Как можно спроектировать контекст?

Выбирайте, какие источники включать, а какие исключать.

Определяйте, какой контент является источником истины по конкретной теме (правильное определение, самый свежий источник). Иногда вы можете обнаружить, что сами изначально не были в этом уверены.

Создавайте новый контекст там, где его ещё нет.

Форматируйте контекст так, чтобы модель могла эффективно его парсить: делайте его более модульным, хорошо структурированным.

Коротко говоря, context engineering следует тем же принципам, что и data engineering: измерять, итерировать, оптимизировать. Отслеживайте производительность вашего агента. Определяйте причины сбоев. Добавляйте недостающий контекст. Тестируйте улучшения. Повторяйте.

Управление контекстом: источник истины контекста — это новый источник истины данных

Нам нужно управление контекстом так же, как раньше нам было нужно управление данными.

Нам было нужно управление данными, потому что без него «выручка» означала три разных вещи в зависимости от того, кого вы спрашивали. Команда маркетинга считала валовые бронирования. Финансы считали чистый ARR. Продуктовая команда считала активные подписки. Нет метрического слоя, нет канонического определения — поэтому каждый дашборд рассказывал свою историю.

Сегодня нам нужно управление контекстом, потому что знания компании имеют ту же самую проблему. Спросите «какова наша политика возвратов?» — и ответ будет зависеть от того, какой документ агент найдёт первым: устаревший Notion, последний ответ в Zendesk или сообщение от юридического отдела в Slack за прошлый квартал. А иногда никто на самом деле и не задумывался, каким должен быть правильный ответ.

Многие специалисты по данным помнят тревожные времена, когда приходили в компанию, где BI был подключён напрямую к продакшен-базе данных. Все данные были на месте, но ни одна цифра не совпадала с другой, всё работало медленно и болезненно. Сегодня мы делаем ровно то же самое, подключая AI ко всем знаниям нашей компании.

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

Нам нужен контекстный слой: единый, управляемый, версионируемый источник истины для знаний компании. Чёткий ответ на каждый вопрос, с которым может столкнуться агент. И нам нужна инфраструктура, чтобы его строить и поддерживать.

Context engineering: контекстный стек — это data-стек

Чтобы создать источники истины данных, мы построили data-стек.
Чтобы создать источники истины контекста, нам нужен контекстный стек.

Ситуация сегодня такая же, как с данными 10 лет назад: у нас есть источники, у нас есть инструменты потребления. Но у нас нет промежуточного слоя — контекстного ETL-слоя.

Нам нужны:

Инструменты ingestion для автоматического подтягивания источников контекста
Инструменты трансформации для выбора источника истины контекста
Контекстный слой как источник истины знаний компании
Оркестрация для поддержания актуальности контекста

Мониторинг AI для измерения и отслеживания производительности нашего контекста в AI-агентах

Некоторые data-команды уже начали собирать части этого самостоятельно. Я видел, как команды пишут скрипты для выгрузки метаданных схем и статистики профилирования из хранилища, синхронизируют документацию из data-каталога или отбирают проверенные запросы из BI-инструмента в markdown-файлы. Это работает — но это множество скриптов и постоянная поддержка.

С мониторингом всё ещё сложнее. Большинство инструментов для аналитических агентов пока не поддерживают фреймворки оценки, поэтому нет простого способа построить unit-тесты, которые проверяют, что ваш контекст по-прежнему выдаёт правильные ответы после изменений.

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

Context sciences: тонкая настройка контекста как параметров ML-модели

В ML вы определяете метрику успеха (accuracy и т.д.) и имеете train/test-набор размеченных данных. Затем вы настраиваете параметры, признаки, обучающие выборки. После каждого изменения измеряете производительность, пока не найдёте оптимум.

В context engineering должен быть тот же цикл. Вы определяете метрики успеха (надёжность, стоимость и т.д.). Ваши параметры — это источники истины контекста, форматирование контекста, инструменты. Вы можете создать набор unit-тестов из промптов и ожидаемых ответов. Вы меняете контекст, заново прогоняете тестовые промпты, измеряете влияние, оставляете то, что работает.

Дополнительная сложность — как измерять метрики → стоимость и скорость измерить легко, но для оценки надёжности агента нужны более специализированные инструменты: проверять использованные файлы? точное совпадение? LLM как судья?

Чтобы это реализовать, нужно построить собственный evaluation framework. Определить KPI, которые вы будете отслеживать — что такое успех агента, как его измерять, какие ещё параметры важны (стоимость, скорость и т.д.). Затем создать набор unit-тестов и тонко настраивать контекст, измеряя производительность на разных наборах контекста.

Как начать переход уже сейчас

Как вы видите, контекстный стек пока ещё не сформирован. Нам всё ещё не хватает инструментов для открытого курирования и улучшения контекста.

Я думаю, что первым шагом для data-команд может быть демонстрация того, что они владеют context engineering в своей области: можете ли вы действительно заставить контекст для вашего аналитического агента работать?

Как я показывал в своих предыдущих статьях с бенчмарками аналитических агентов, готовые решения «из коробки» не работают и являются чёрными ящиками контекста. Если data-команды инвестируют в context engineering для собственных аналитических агентов, я уверен, они смогут показать, что это работает лучше, чем решения «из коробки».

Два подхода уже сейчас позволяют войти в context engineering:

AI-агенты, работающие с файловой системой (Cursor, Claude Code, Cowork, Codex)
Эти инструменты читают контекст напрямую из файлов, которыми вы управляете. Вы точно видите, что знает агент, можете изменить это, отредактировав файл, и сразу измерить эффект.
Кроме того, можно построить evaluation framework поверх этого, поскольку всё доступно через код.

Собственные (in-house) агенты

Если вы построили собственного агента, вы контролируете весь конвейер контекста: какие элементы контекста добавлять и как оценивать агента. Создайте набор unit-тестов из промптов и начните прогонять их в разных сценариях контекста.

Ссылки на дополнительные статьи / материалы

Сайты со Skills для ai-agents

Обучающие материалы по ai, llm

Data Engineering AI

GitHub Astronomer: AI agent tooling for data engineering workflows — Includes an MCP server for Airflow, a CLI tool (af) for interacting with Airflow from your terminal, and skills that extend AI coding agents with specialized capabilities for working with Airflow and data warehouses.

Context engineering = data governance + data engineering + data science