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-тестов из промптов и начните прогонять их в разных сценариях контекста.

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

• GitHub: 12-Factor Agents — Principles for building reliable LLM applications
• Context Engineering: A Guide With Examples
• GitHub: OpenWork
• GitHub: Data Formulator: AI-powered Data Visualization

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

• skills.sh
• skillhub.club
• skillsmp.com
• GitHub: Awesome Agent Skills

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

• GitHub: Microsoft AI Agents for Beginners — A Course
• GitHub: AI Agents From Scratch
• GitHub: Codes/Notebooks for AI Projects
• RAG Zero to Hero Guide
• Advanced RAG Techniques: Elevating Your Retrieval-Augmented Generation Systems
• RAG From Scratch
• GitHub: Skills, MCP servers, Custom Agents, Agents.md for SDKs to ground Coding Agents
• Model Context Protocol (MCP) Curriculum for Beginners
• 63 Must-Know LLMs Interview Questions in 2026

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 появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

• https://github.com/DataExpert-io/llm-driven-data-engineering
• Data Engineer 2.0. Part I: Large Language Models
• Data Engineer 2.0. Part II: Retrieval Augmented Generation
• What are LLM Agents?
• LLM Data Engineering 3——Data Collection Magic: Acquiring Top Training Data
• A Guide to AI Agents for Data Engineers

Мне очень симпатична идея работы с LLM. При правильном подходе ты не застреваешь на каких-то деталях и сильно ускоряешь рутину.

А пока представим, какой могла бы быть структура статьи.

Prompt Engineering Guide

Промпт инжиниринг — это относительно новая дисциплина, связанная с разработкой и оптимизацией промптов для эффективного использования языковых моделей (Language Models, LMs) в самых разных приложениях и исследовательских задачах. Навыки инженерии промптов помогают лучше понять возможности и ограничения больших языковых моделей (Large Language Models, LLMs).

Исследователи используют инженерию промптов для улучшения способностей LLM в решении широкого спектра задач, как простых, так и сложных, включая ответы на вопросы и арифметические рассуждения. Разработчики применяют инженерию промптов для создания надежных и эффективных методов взаимодействия с LLM и другими инструментами.

Промпт инжиниринг не ограничивается только разработкой и созданием промптов. Она включает в себя широкий спектр навыков и техник, которые полезны для взаимодействия и разработки с использованием LLM. Это важный навык для взаимодействия, создания и понимания возможностей LLM. С помощью инженерии промптов можно повысить безопасность LLM и создать новые функции, такие как расширение возможностей LLM за счет доменных знаний и внешних инструментов.

1. Введение в LLM для Data Engineer

Алгоритмы машинного обучения

Обучение с учителем (Supervised Learning) — Модель учится по размеченным данным (есть «вход» и «правильный ответ»).

• Линейная регрессия — Прогнозирует численные значения на основе линейной зависимости. Пример: предсказание цены дома.
• Логистическая регрессия — Классификация (да/нет), основанная на логистической функции. Пример: будет ли клиент платить кредит.
• k-ближайших соседей (k-NN) — Классификация/регрессия по ближайшим точкам из обучающей выборки. Пример: распознавание рукописных цифр.
• Деревья решений (Decision Trees) — Принятие решений по условиям в виде дерева. Пример: диагностика болезней.
• Случайный лес (Random Forest) — Комбинация многих деревьев решений для устойчивости. Пример: прогноз оттока клиентов.
• Метод опорных векторов (SVM) — Строит оптимальную границу между классами. Пример: классификация текста.
• Наивный Байес (Naive Bayes) — Вероятностная классификация на основе теоремы Байеса. Пример: фильтрация спама.
• Градиентный бустинг (XGBoost, LightGBM и др.) — Сильные ансамбли слабых моделей, обучающихся последовательно. Пример: соревнования Kaggle.

Обучение без учителя (Unsupervised Learning) — Модель ищет структуры в неразмеченных данных.

• Кластеризация k-средних (k-means) — Делит данные на k групп по схожести. Пример: сегментация клиентов.
• Иерархическая кластеризация — Создаёт дерево вложенных кластеров. Пример: таксономия документов.
• Метод главных компонент (PCA) — Снижает размерность данных с сохранением важной информации. Пример: визуализация данных.
• Автоэнкодеры — Нейросети для сжатия и восстановления входных данных. Пример: обнаружение аномалий.

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

• Q-обучение (Q-learning) — Табличный метод — выбирает действия с максимальной ожидаемой наградой. Пример: игры, маршруты.
• Deep Q-Network (DQN) — Использует нейросети вместо таблицы. Пример: игра в Atari.
• Policy Gradient / Actor-Critic — Оптимизация поведения агента напрямую. Пример: робототехника, управление.

Краткий обзор LLM (Large Language Models) и их эволюции

LLM (Large Language Models) — это нейросетевые модели, обученные на больших объемах текстовых данных для обработки и генерации естественного языка. Основа — трансформер-архитектура (Transformer), предложенная Google в 2017 году.

Видео «Введение в LLM» (YouTube)

Large Language Model (LLM, Большая языковая модель) — это нейросетевая система, способная генерировать, анализировать и «‎понимать» текст, а также выполнять различные задачи, связанные с обработкой естественного языка (Natural Language Processing, NLP). Такие модели обучаются на огромных объемах текстовых данных (книги, статьи, веб-страницы и т.д.), что позволяет им «понимать» контекст и семантику естественного языка.

А «большими» эти модели называются потому, что содержат огромное количество параметров (нейронной сети) — от 1 миллиарда и больше. Именно это и обеспечивает их высокую способность к обобщению и адаптации под разные задачи.

С точки зрения бизнеса, LLM это мощный инструмент, который имеет весьма обширное применение:

• Чат-боты и виртуальные ассистенты.
• Вопросно-ответные системы.
• Написание кода/Ассистенты кода.
• Генерация контента.
• Анализ и обработка текстовых данных.
• Классификация текста.
• Написание Summary по тексту.
• Машинный перевод.

Этапы эволюции:

2018–2019:

• OpenAI GPT, GPT-2 – первые масштабные языковые модели; GPT-2 (1.5B параметров) показал способность к генерации связного текста.
• BERT (Google) – ввел bidirectional обучение, стал стандартом для задач NLP.

2020:

• GPT-3 (175B) – качественный скачок в возможностях генерации текста, кодирования, логики.
• T5 (Google) – унификация NLP-задач под формат “текст-в-текст”.

2022:

• ChatGPT (на базе GPT-3.5) – адаптирован под диалог через RLHF (обучение с подкреплением с участием человека).
• PaLM (Google), Gopher (DeepMind) – рост параметров до 500B+.

2023–2024:

• GPT-4 (мультимодальность, улучшенное рассуждение).
• Claude (Anthropic), LLaMA (Meta), Mistral, DeepSeek, Gemini (Google) – открытые и проприетарные LLM, оптимизированные под конкретные задачи.
• Появление специализированных моделей для кода: Codex, DeepSeek-Coder, StarCoder, CodeLLaMA.

2024+:

• Сдвиг к мультимодальным моделям, интеграции инструментов, он-девелопмент LLM (Copilot-подходы), оптимизация под локальное использование (Quantization, MoE).

LLM стали основой ИИ-продуктов — от чат-ботов и ассистентов до кода, анализа данных и научных открытий.

Таблица с компаниями и их LLM:

Почему Data Engineers должны обращать внимание на LLM

Давайте попробуем описать, какую работу можно поручить LLM:

LLM = ускорение, автоматизация, понимание и взаимодействие с данными на новом уровне.

Data Engineers, внедряя LLM, становятся не просто «интеграторами пайплайнов», а архитекторами умных, адаптивных систем данных.

Примеры задач, которые можно поручить LLM

Генерация кода и скриптов

Анализ и интерпретация данных

Оптимизация и ревью

Документация и стандарты

Data Discovery & Q&A

Интеграции и автоматизация

Как LLM и мультиагентные системы могут упростить работу с данными

Агент — это самостоятельный программный компонент, управляемый LLM, способный выполнять конкретную задачу: писать код, вызывать API, читать файлы, управлять пайплайнами и т.д. Он действует по инструкции, часто формулируемой на естественном языке, и может взаимодействовать с внешними системами.

Мультиагентная система (Multi-Agent System, MAS) — это набор таких агентов, которые работают совместно, передают задачи друг другу, координируются через LLM и вместе решают более сложные задачи, чем один агент в одиночку.

Пример:

1. Ты пишешь «построй отчёт по продажам».
2. Агент 1 интерпретирует запрос и формирует SQL.
3. Агент 2 выполняет SQL и получает данные.
4. Агент 3 визуализирует результат.
5. Агент 4 генерирует текстовую интерпретацию и оформляет в PDF.

LLM в центре координирует эту работу — как «мозг» системы. Это делает MAS мощным инструментом для автоматизации аналитики, ETL и поддержки принятия решений.

LLM и мультиагентные системы радикально упрощают работу с данными, превращая сложные, многоэтапные процессы в интерактивные и автоматизированные сценарии.

Во-первых, LLM позволяют обращаться к данным на естественном языке. Специалисту не нужно знать точный синтаксис SQL, структуру схемы или внутренности хранилища — достаточно сформулировать вопрос, и модель сама построит нужный запрос или пайплайн.

Во-вторых, мультиагентные системы могут автоматизировать целые цепочки задач. Один агент может сгенерировать SQL, второй — выполнить его, третий — построить визуализацию, а четвертый — оформить результат в отчет. Такая распределённая архитектура снижает нагрузку на одного специалиста и ускоряет процессы.

Также LLM-агенты могут работать асинхронно с внешними источниками — подключаться к API, мониторить данные, запускать пайплайны по событиям. Это делает их идеальными для DataOps и мониторинга.

Наконец, за счёт памяти и контекста, мультиагентные LLM-системы способны обучаться на истории задач и адаптироваться под стиль команды или конкретного проекта, минимизируя повторяющуюся ручную работу.

В результате data engineer становится не просто исполнителем, а оператором интеллектуальной системы, делегирующим задачи ИИ.

Роль Prompt Engineering в работе с LLM: как правильная формулировка запросов влияет на качество результата

Prompt Engineering — это практика составления точных, контекстуальных и целевых запросов (prompts) для получения максимально качественных ответов от LLM.

Правильная формулировка запроса критически влияет на:

• Точность ответа — чётко сформулированный prompt снижает вероятность «галлюцинаций» и ошибок модели.
• Полноту и структурированность — указание формата вывода (таблица, список, JSON) помогает получить пригодный для работы результат.
• Контроль поведения — с помощью system prompt или инструкций можно задать стиль ответа, ограничить тему, указать роль (например: «ты дата-инженер»).
• Стабильность результатов — правильно спроектированный prompt уменьшает вариативность при повторных запросах.

В работе data engineer prompt engineering применяется для:

• генерации SQL/ETL кода по описанию;
• интерпретации данных;
• построения цепочек агентов (в MAS);
• создания шаблонов автодокументации;
• взаимодействия с LLM через API (например, в бэкенде DataOps-инструментов).

Пример составления промпта

Допустим у нас есть задача: Сгенерировать SQL-запрос для аналитики

Prompt:

Ты — опытный Data Engineer. На основе описания задачи сгенерируй оптимальный SQL-запрос. Формат вывода — только SQL-код без пояснений.

Описание задачи:
В таблице orders нужно посчитать среднюю сумму заказов (total_amount) по каждому региону (region) за март 2024 года. Исключи заказы со статусом cancelled.

Результат:

SELECT region, AVG(total_amount) AS avg_order_amount
FROM orders
WHERE status != 'cancelled'
  AND order_date >= '2024-03-01'
  AND order_date < '2024-04-01'
GROUP BY region;

Что мы делаем с помощью prompt:

1. Задает контекст роли (ты — Data Engineer).
2. Уточняет формат вывода (только SQL-код).
3. Дает четкое описание задачи, включая названия колонок, фильтры и агрегации.
4. Подходит для интеграции в пайплайн или автоматизацию (т.к. вывод — чистый код).

2. Основная терминология LLM/RAG и т.п.

Основные термины по группам LLM/Prompt/Token/RAG и т.д.

Large Language Model (LLM)

Большая языковая модель (LLM) — это статистическая языковая модель, обученная на огромном объеме данных, которую можно использовать для генерации и перевода текста и другого контента, а также для выполнения других задач обработки естественного языка (NLP). Если кратко, то это нейросеть, обученная на огромных массивах текстов, способная генерировать, интерпретировать и анализировать естественный язык.

Видео «Краткое объяснение больших языковых моделей» (YouTube):

Примеры моделей: GPT (OpenAI), Claude (Anthropic), Gemini (Google), LLaMA (Meta).

Технология: основаны на архитектуре Transformer, обучаются предсказывать следующий токен в тексте (language modeling).

Prompt / Prompt Engineering

• Prompt — это запрос или инструкция, которую пользователь передаёт LLM.
• Prompt Engineering — это практика формулировки запросов для получения нужного результата.
• Few-shot prompting — запрос с несколькими примерами.
• Zero-shot prompting — запрос без примеров.

Шаблоны помогают стандартизировать взаимодействие с LLM (например: «Ты — SQL-эксперт, напиши запрос по описанию…»).

Token / Контекстное окно

• Токен — минимальная единица текста (обычно слово, часть слова или символ), с которой работает LLM.
• Контекстное окно — максимальное количество токенов, которое модель может “удерживать в памяти” за один запрос.

Важно: лимит токенов влияет на длину входа + выхода, стоимость и точность. Пример: GPT-4-turbo — до 128k токенов.

Контекстное окно LLM — что это и как оно влияет на работу моделей?

Fine-tuning / Instruct-tuning / RLHF

• Fine-tuning — Тонкая настройка: Для того, чтобы большая языковая модель могла выполнять определенную задачу, например, перевод, она должна быть точно настроена на эту конкретную деятельность. Тонкая настройка оптимизирует производительность определенных задач.
  То есть это может быть дообучение модели на специализированных данных (напр., банковские транзакции или медицинские тексты).
• Instruct-tuning — обучение под выполнение инструкций на естественном языке.
• RLHF (Reinforcement Learning with Human Feedback) — улучшение модели с помощью обратной связи от людей, часто для более этичного или полезного поведения.

Видео на русском «Fine-tuning, RAG, Llama, prompt-engineering, LLM-арены | Что происходит в LLM» (YouTube)

RAG vs Fine-Tuning vs Prompt Engineering: Optimizing AI Models

RAG (Retrieval-Augmented Generation)

RAG — подход, при котором LLM использует внешний поиск (по векторной базе или индексу), чтобы дополнить свой контекст перед генерацией ответа.

Пример: при запросе о внутренних бизнес-данных, модель сначала ищет релевантные документы, затем формирует ответ на их основе.
Применяется в чат-ботах, корпоративной аналитике, справочных системах.

Видео «RAG | САМОЕ ПОНЯТНОЕ ОБЪЯСНЕНИЕ» (YouTube)

Embeddings / Векторизация

Embedding — представление текста в виде числового вектора в многомерном пространстве.
Тексты, похожие по смыслу, имеют близкие векторы.

Применяются для:

• семантического поиска
• кластеризации
• построения RAG-систем

Примеры моделей: OpenAI embeddings, BGE (BAAI), Cohere embeddings.

Word embeddings для векторизации текста | Обработка естественного языка

Лекция. Векторные представления слов, Bag of Words. Латентный семантический анализ

Agent / Multi-Agent System (MAS)

• Агент — это LLM-компонент с заданной функцией (например, писать SQL, вызывать API, строить графики).
• Мультиагентная система (MAS) — набор агентов, координируемых между собой, для выполнения сложных задач по шагам.

Пример: один агент парсит задачу, другой запускает запрос, третий — визуализирует.

Видео на английском «AI Agents, Clearly Explained» (YouTube)

Видео на английском «Conceptual Guide: Multi Agent Architectures» (YouTube)

Chain / Workflow / Orchestration

• Chain — последовательность шагов, выполняемых LLM или агентами (пример: сначала SQL, потом интерпретация, потом отчёт).
• Workflow — логика выполнения многозадачного процесса.
• Orchestration — управление выполнением этих процессов, включая условия, повторные попытки, параллелизм.

Инструменты: LangChain, Semantic Kernel, CrewAI.

Hallucination

Галлюцинация — когда LLM уверенно выдаёт недостоверную или вымышленную информацию.
Причины: недостаточный контекст, сжатие токенов, ошибки в данных.

Уменьшение галюцинаций достигается за счет:

• точные prompts
• RAG (подкрепление знаниями)
• валидация через инструменты или постпроцессинг.

Model Types: Open vs Closed

• Open-source модели (например, LLaMA, Mistral, DeepSeek) — доступны для локального запуска и кастомизации.
• Проприетарные модели (например, GPT-4, Claude 3, Gemini) — доступны через API, обычно точнее, но закрыты.
• Выбор зависит от требований к приватности, цене, масштабируемости и контролю над логикой работы.

Архитектура Transformer (фундаментальная нейросетевая модель)

• Для лучшего понимания как работает Transformer рекомендую сайт TRANSFORMER EXPLAINER.
• Еще есть хорошая статья The Evolving Landscape of Large Language Model (LLM) Architectures про архитектуры LLM.

Основная проблема заключается в стратегии, которую используют эти нейронные сети для предсказания пропущенного слова в предложении. До появления transformers современные нейронные сети полагались на архитектуру кодер-декодер, мощный, но требующий много времени и ресурсов механизм, который не подходит для параллельных вычислений, что ограничивает возможности масштабируемости.

Transformers представляют собой альтернативу традиционным нейронным сетям для обработки последовательных данных, а именно текста (хотя transformers также использовались с другими типами данных, такими как изображения и аудио, с не менее успешными результатами).

Transformers основаны на той же архитектуре кодер-декодер, что и рекуррентные и сверточные нейронные сети. Такая нейронная архитектура направлена на обнаружение статистических связей между токенами текста.

Это делается с помощью комбинации методов встраивания. Embedding (Встраивания) — это представления токенов, таких как предложения, абзацы или документы, в многомерном векторном пространстве, где каждое измерение соответствует изученной функции или атрибуту языка.

Процесс embedding происходит в кодере. Из-за огромного размера LLM создание embedding требует обширного обучения и значительных ресурсов. Однако то, что отличает transformers от предыдущих нейронных сетей, заключается в том, что процесс embedding в высокой степени параллелизуем, что обеспечивает более эффективную обработку. Это возможно благодаря механизму внимания (attention mechanism).

Рекуррентные и сверточные нейронные сети делают свои предсказания слов исключительно на основе предыдущих слов. В этом смысле их можно считать однонаправленными. Напротив, механизм внимания позволяет transformers предсказывать слова двунаправленно, то есть на основе как предыдущих, так и последующих слов. Целью слоя внимания, который включен как в кодер, так и в декодер, является захват контекстных отношений, существующих между различными словами во входном предложении.

• Embedding Layer / Слой встраивания создает embeddings из входного текста. Эта часть большой языковой модели фиксирует семантическое и синтаксическое значение ввода, чтобы модель могла понимать контекст.
• FeedForward Layer / Слой прямой связи (FFN) большой языковой модели состоит из нескольких полностью связанных слоев, которые преобразуют embeddings входные данные. При этом эти слои позволяют модели собирать абстракции более высокого уровня — то есть понимать намерение пользователя с помощью текстового ввода.
• Recurrent layer / Рекуррентный слой интерпретирует слова входного текста последовательно. Он фиксирует связь между словами в предложении.
• Attention mechanism / Механизм внимания позволяет языковой модели сосредоточиться на отдельных частях входного текста, которые имеют отношение к поставленной задаче. Этот слой позволяет модели генерировать наиболее точные выходные данные.

1. Входное представление (Embedding + Positional Encoding)

Текст разбивается на токены, каждый из которых преобразуется в вектор фиксированной размерности (embedding).
Поскольку Transformer не обладает встроенной последовательной природой (как RNN), к этим векторам добавляются позиционные кодировки (positional encodings), чтобы модель понимала порядок токенов.

2. Encoder и Decoder
Исходная архитектура Transformer включает два блока:

• Encoder — принимает входную последовательность и кодирует её в скрытое представление.
• Decoder — генерирует выходной текст, используя кодировщик и ранее сгенерированные токены.
  

В LLM чаще используют только часть декодера (autoregressive decoder), так как задача — генерировать текст.

3. Механизм внимания (Attention)

Ключевой элемент — Self-Attention, который позволяет каждому токену учитывать все остальные токены в последовательности.
Вычисляется весовая матрица, отражающая важность каждого токена относительно других. Это обеспечивает контекстуальное понимание.

4. Многоголовое внимание (Multi-Head Attention)

Вместо одного внимания используется несколько параллельных «голов», каждая из которых смотрит на данные под своим углом. Это повышает способность модели улавливать разные аспекты контекста.

5. Feed-Forward сети

После внимания идут полносвязные слои с нелинейностями, которые трансформируют представления токенов.

6. Нормализация и резидуальные связи

Чтобы обучение было стабильным и глубоким, применяются Layer Normalization и остаточные (skip) связи между слоями.

Токенизация

Исторически так сложилось, что компьютеры не могут читать текст так же как это делают люди — они могут работать только с числами. И LLM тут не исключение. Чтобы LLM смогла «‎прочитать» текст, его сначала необходимо преобразовать в числа.

Этим и занимается токенизация: она разбивает текст на более мелкие единицы, называемые токенами. Затем токены превращаются в целые числа. И последовательность целых чисел подается в LLM в качестве входных данных.

Программа, которая занимается токенизацией, называется токенизатор (tokenizer). Токенизаторы существуют отдельно от LLM и взаимодействуют с ними по мере необходимости (но могут использоваться и вполне самостоятельно). Так же, как и LLM, токенизатор необходимо сначала обучить. Причем, обучаются они отдельно от LLM и до начала ее обучения.

Уже обученный токенизатор выполняет две функции:

• Энкодинг (encode) — преобразует текст в последовательность целых чисел (токенов).
• Декодинг (decode) — выполняет обратную операцию, преобразует последовательность чисел в текст.

Операция энкодинга вызывается перед подачей данных в LLM (чтобы закодировать текст), а декодинг вызывается после отработки LLM, чтобы превратить последовательность чисел (сгенерированных LLM) в текст.

Процесс преобразования текста в токены

Процесс преобразования текста в токены называется токенизацией. Это ключевой шаг, который позволяет LLM понимать и обрабатывать текст.

Разбиение текста на элементы

Текст разбивается на маленькие части — токены. Токены могут быть целыми словами, их частями (например, приставками, суффиксами), либо отдельными символами, в зависимости от используемой токенизирующей модели.

Есть онлайн инструмент GPT tokenizer, в котором можно поэкспериментировать с текстом и посмотреть на то, как текст разбивается на токены.

Типы токенизации

Словесная токенизация: каждый токен — отдельное слово (редко используется в LLM из-за проблем с редкими словами).

Подсловная (subword) токенизация: слова разбиваются на более мелкие части (BPE, WordPiece, SentencePiece). Это позволяет модели эффективно работать с новыми или редкими словами, комбинируя знакомые кусочки.

Преобразование в числовые индексы

Каждому токену сопоставляется уникальный числовой идентификатор из словаря модели. Именно эти числа подаются на вход нейросети.

Пример
Фраза: «Data engineering» может разбиться на токены: [«Data», » engineer», «ing»] — где первые два токена — целые слова или части слова, а третий — суффикс, который помогает модели лучше понимать морфологию.

Зачем это нужно

Токенизация позволяет модели:

• Универсально обрабатывать любые тексты
• Эффективно использовать память (за счёт фиксированной длины токенов)
• Генерировать текст по токенам (по одному за раз)

Описание процесса создания и работы LLM

Сбор и подготовка данных

Для обучения собираются огромные корпуса текстов из интернета, книг, статей, кода и других источников. Тексты очищаются и нормализуются.

Токенизация

Тексты разбиваются на токены — минимальные смысловые единицы, которые модель будет обрабатывать.

Обучение на задаче языкового моделирования

Модель обучается предсказывать следующий токен по предыдущим (autoregressive learning) или восстанавливать пропущенные слова (masked language modeling). При этом нейросеть учится понимать структуру языка, синтаксис и контекст.

Архитектура Transformer

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

Fine-tuning и оптимизация

После базового обучения модель дообучают на специализированных данных или инструкциях (instruct tuning, RLHF), чтобы повысить полезность и безопасность.

Принцип обработки информации

1. Входящий текст преобразуется в токены.
2. Каждый токен проходит через слои Transformer, где механизм внимания взвешивает влияние всех токенов друг на друга.
3. Модель генерирует вероятности для следующего токена, выбирая наиболее подходящий.
4. Так происходит поэтапное формирование ответа или кода.

Принцип поиска и интеграции знаний (например, в RAG)

1. Если запрос выходит за рамки знаний модели или требует точных данных, запускается модуль поиска.
2. Текст запроса переводится в embedding — векторное представление.
3. По векторной базе данных (например, корпоративный документ или база знаний) находится наиболее релевантная информация.
4. Найденный контент добавляется к контексту запроса для LLM.
5. Модель генерирует ответ, опираясь как на собственные знания, так и на найденные данные.

За счет чего LLM так круто работает?

• Архитектура Transformer с механизмом внимания
  Transformer позволяет модели учитывать весь контекст сразу, а не только соседние слова, что обеспечивает глубокое понимание текста и гибкую генерацию.
• Обучение на огромных объемах данных
  LLM тренируются на миллиардах слов из разных источников — книг, сайтов, кода. Это даёт модели обширные знания о языке, фактах и логике.
• Масштаб модели и параметров
  Миллиарды параметров позволяют захватывать сложные закономерности и зависимости, делая ответы более точными и разнообразными.
• Обучение с обратной связью человека (RLHF)
  Финетюнинг с помощью отзывов людей помогает модели лучше понимать задачи, избегать нежелательного поведения и выдавать более полезные ответы.
• Универсальность и адаптивность
  LLM могут решать разные задачи — от генерации кода до творчества — просто меняя prompt, без дополнительного дообучения.
• Использование токенизации и контекстного окна
  Разбиение текста на токены и возможность учитывать тысячи токенов контекста позволяет моделям работать с большими объемами информации и строить сложные ответы.

Почти все современные так или иначе основаны на архитектуре Трансформеров. Но постепенно появляются и другие решения:

• MoE (Mixture of Experts) – все те же трансформеры, но теперь параметры модели делятся между несколькими «‎экспертами», которые могут фокусироваться на разных аспектах данных (например, языки, домены). При использовании такой модели одновременно работает только часть экспертов. Это позволяет создавать более крупные модели, при этом сохраняя высокую скорость генерации текста.
• Mamba – новый тип нейросетей на основе State Space Models (SSM), который отказывается от механизма Внимания (attention) Трансформеров в пользу линейной, последовательной обработки информации. Имеет линейную сложность O(n) в отличие от O(n²) у Трансформеров. В результате Mamba быстрее и лучше работает с длинными последовательностями.
• Diffusion LLM – языковая модель, которая использует диффузионный подход (как в генерации изображений в Stable Diffusion), но применённый для пошагового «восстанавления» текста из шума. Потенциально, такие модели более креативны, чем Трансформеры.

3. MCP (Model Context Protocol)

Model Context Protocol (MCP) — это открытый протокол (анонсированный Anthropic), который стандартизирует, как приложения предоставляют контекст LLM. Думайте о MCP как о порте USB-C для приложений ИИ. Так же, как USB-C предоставляет стандартизированный способ подключения ваших устройств к различным периферийным устройствам и аксессуарам, MCP предоставляет стандартизированный способ подключения моделей ИИ к различным источникам данных и инструментам.

• Сайт: https://modelcontextprotocol.io/introduction
• GitHub: https://github.com/modelcontextprotocol

MCP помогает вам создавать агентов и сложные рабочие процессы поверх LLM. LLM часто нуждаются в интеграции с данными и инструментами, и MCP обеспечивает:

• Растущий список готовых интеграций, к которым ваш LLM может напрямую подключиться
• Гибкость переключения между поставщиками и вендорами LLM
• Лучшие практики по защите данных в вашей инфраструктуре

Чтобы понять MCP, сначала нужно понять LLM и Agent.

LLM (Large Language Model) в основном отвечает на вопросы посредством знаний, полученных во время обучения. Другими словами, вы не можете отвечать на информацию, которая не была изучена, и вы не можете выполнять дополнительные действия, кроме ответов на вопросы, такие как воспроизведение музыки или поиск файлов на компьютере.

Чтобы преодолеть эти ограничения LLM и расширить функциональность приложений LLM, мы можем позволить LLM взаимодействовать с другими приложениями или источниками данных.

Например, если вам нужна информация о вступительном экзамене в колледж в этом месяце, вы можете найти последние данные через поисковую систему Google и предоставить ответ на основе этих данных, или если вы хотите узнать текущую информацию о ценах акций, вы можете получить информацию об акциях через веб-сайт Yahoo Finance. Внешние приложения или источники данных, которые связаны с LLM таким образом, называются инструментами. Однако, когда есть много инструментов, LLM должен подумать, какой инструмент использовать для данной проблемы, и принять решение.

MCP устанавливает четкие правила того, как ИИ может находить, подключаться и использовать внешние инструменты – будь то запрос к базе данных или запуск команды. Это позволяет моделям выходить за рамки своих обучающих данных, делая их более гибкими и осведомленными об окружающем мире.

Одной из ярких особенностей MCP является динамическое обнаружение — агенты ИИ автоматически обнаруживают доступные серверы MCP и их возможности без жестко запрограммированных интеграций. Например, если вы запускаете новый сервер MCP (например, CRM), агенты могут немедленно распознать и использовать его через стандартизированный API, предлагая гибкость, с которой традиционные подходы не могут сравниться.

По своей сути MCP следует архитектуре клиент-сервер, где хост-приложение может подключаться к нескольким серверам:

Why MCP really is a big deal | Model Context Protocol with Tim Berglund

MCP + LLM: Стандарт, превращающий нейросети в настоящие инструменты

4. Machine learning operations (MLOps)

Machine learning operations (MLOps) — это набор практик, которые автоматизируют и упрощают рабочие процессы и развертывания машинного обучения (ML).

MLOps — это культура и практика ML, которые объединяют разработку приложений ML (Dev) с развертыванием и эксплуатацией систем ML (Ops). Ваша организация может использовать MLOps для автоматизации и стандартизации процессов на протяжении всего жизненного цикла ML. Эти процессы включают разработку модели, тестирование, интеграцию, выпуск и управление инфраструктурой.

Формула:

MLOps = DataOps + DevOps + ModelOps

Сайт где почитать про MLOps: https://ml-ops.org/content/mlops-principles

Методы инструктивного обучения

Эти методы используются после базового предобучения модели, чтобы сделать её полезной, безопасной и соответствующей человеческим ожиданиям. Большинство из них относятся к обучению с подкреплением с обратной связью от человека (RLHF) или его вариациям.

Метод	Основан на	Нужен RM?	RL?	Преимущества
SFT	Размеченные ответы			Просто, быстро
RLHF	Предпочтения человека			Контролируемое поведение
PPO	RM-награда			Точная настройка
DPO	Предпочтения			Простота, эффективность
DRPO	RM-награда			Нет RL, но с наградами
SMPO	Предпочтения + пороги			Лучше с неопределёнными RM
GRPO	Награда (через Gumbel)			Теоретическая строгость

RLHF (Reinforcement Learning from Human Feedback)

обучение модели через человеческую обратную связь.

Этапы:

• Сначала — SFT (см. ниже).
• Собираются предпочтения человека между парами ответов.
• Обучается Reward Model (RM) — предсказывать, какой ответ лучше.
• Затем — обучение через RL (например, PPO) с этим RM как «награда».

Плюсы: качество, безопасность, контроль.
Минусы: сложность и дороговизна.

SFT (Supervised Fine-Tuning)

дообучение модели на парах (инструкция → хороший ответ), написанных или проверенных человеком.

Пример: «Как сварить рис?» → «Промойте рис…»

Используется как первый этап RLHF.
Быстрое, дешёвое, но ограниченное — модель просто повторяет шаблоны.

DPO (Direct Preference Optimization)

альтернатива RLHF без RL.
Обучает модель напрямую предпочитать более качественные ответы, используя предпочтения.
Метод: максимизация разницы логитов между «хорошим» и «плохим» ответом.

Формула вдохновлена вероятностной интерпретацией политики в RL.

Плюсы: проще, стабильнее, дешевле, чем RL (PPO).
Минусы: не всегда даёт ту же гибкость, что PPO.

DRPO (Direct Reward Policy Optimization)

избегает RL, но оптимизирует политику (ответы модели) не по предпочтениям, а по предсказанной награде от RM.

То есть:

• DPO → использует сравнительные предпочтения.
• DRPO → использует скалярные значения награды от RM.

Промежуточный подход между PPO и DPO.

PPO (Proximal Policy Optimization)

стандартный алгоритм RL (из OpenAI), адаптированный для LLM.

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

Плюсы: мощный, гибкий.
Минусы: сложно настраивать, дорогой в обучении.

SMPO (Softmax Margin Policy Optimization)

гибрид DPO и PPO.

Добавляет margin (порог различия между хорошим и плохим ответом) в обучение, управляя балансом между качеством и стабильностью.

Особенность: лучше справляется с «неуверенными» предпочтениями (когда разница между ответами мала).
Улучшение над DPO в некоторых сценариях.

GRPO (Gumbel Reward Policy Optimization)

более теоретически обоснованный метод для RL с дифференцируемыми наградами.
Использует Gumbel-Softmax для приближённой выборки, позволяя работать с наградами в стиле RL, но обучаясь напрямую как в DPO.

Идея: соединить преимущества DPO (простота) и PPO (награды).

Обзор ключевых LLM-инструментов для Data Engineer

ChatGPT (OpenAI) – генерация SQL, автоматизация ETL, кодогенерация

DeepSeek Copilot – обработка данных, поддержка DataOps

Google Gemini, Claude и другие – ML workflows, работа с API

Сравнение LLMs по критериям

Качество генерации SQL
Возможность интеграции с data-стеком
Поддержка сложных pipeline

Основные кейсы применения LLM в Data Engineering

Автоматическая генерация SQL-запросов и их оптимизация
Prompt Engineering: использование chain-of-thought (CoT) для сложных запросов
Zero-shot vs. Few-shot prompting
Примеры промтов для SQL
Автоматизация ETL/ELT процессов
LLM + Airflow: автоматическая генерация DAG
Применение structured output prompting для формирования JSON
Data Quality & Anomaly Detection
Использование retrieval-augmented generation (RAG)
Аномалии в данных: prompting для поиска закономерностей
Документирование данных и генерация Data Contracts
Применение LLM для автоматической генерации документации
Prompt-техники для интерпретации схем БД
Обогащение и профилирование данных через AI
Prompt-трюки для извлечения скрытых паттернов

Мультиагентные системы в Data Engineering

Что такое мультиагентные системы и как они работают
Архитектура мультиагентных решений: взаимодействие агентов
Применение мультиагентных систем в Data Engineering
Агенты для data ingestion (авто-обнаружение источников)
Агенты для data transformation (AI-контролируемые пайплайны)
Агенты для data governance & compliance (автоматическое DLP)
Агенты для мониторинга и алертов (AI-анализ метрик)
Использование Prompt Engineering в мультиагентных системах
Роль System Prompt в управлении агентами
Интерактивное уточнение запросов через self-reflection prompting

Практический туториал: создание AI-ассистента для Data Engineering

Часть 1: Создаем SQL-генератор с OpenAI + LangChain
Используем Few-shot prompting для обучения модели
Настраиваем embedding-слой для context-aware SQL
Часть 2: AI-агент для ETL-автоматизации (LLM + Airflow)
Применяем RAG для обработки схем данных
Автоматическая генерация ETL-скриптов
Часть 3: Интеграция мультиагентной системы с Apache Airflow
Запускаем несколько агентов для data pipeline
Применяем self-improving prompting

Заключение

Преимущества и ограничения LLM в Data Engineering
Будущее AI-инструментов в обработке данных
Практические рекомендации:
Как настроить промты для production-ready решений
Оптимизация работы LLM в data pipeline
Этичные аспекты применения LLM в Data Engineering

Статья будет полезна не только Data Engineers, но и ML-инженерам, DevOps и архитекторам, работающим с AI и данными.

Сообщение ChatGPT DeepSeek Copilot и другие LLM для Data Engineer появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.