К концу 2025 года стало окончательно ясно: RAG без инженерии контекста — это гадание на кофейной гуще. Просто напихать в промпт куски документов и надеяться, что LLM выдаст адекватный ответ — путь к катастрофе. Особенно когда на кону аудит SOC2 (мы об этом писали) или цена ошибки — миллионы.
Андрей Карпати в своих лекциях 2025 года ввел термин Context Engineering — не просто подбор промптов, а проектирование всего конвейера подачи контекста LLM. Тобиас Лютке (CEO Shopify) подхватил идею и накидал четыре жестких принципа типизации входов. LangChain, не будь дураками, выложил четыре референсных Jupyter-ноутбука с открытым кодом на GitHub. Сегодня посмотрим, что это за звери, и почему без них ваш RAG-пайплайн — просто дорогой генератор бреда.
О чем речь? На GitHub у LangChain появились четыре ноутбука, каждый из которых реализует определенный «типизированный вход» — четко структурированный кусок контекста, который подается в LLM. Не просто «нарезали документы», а разделили контекст на роли: системный, динамический, инструментальный и диалоговый. Это и есть Context Engineering в действии.
Четыре входа — четыре судьбы
Представьте, что раньше вы кидали в LLM все подряд как в мясорубку. Теперь у вас четыре отдельных канала. Каждый — со своим форматом, своей ответственностью и своими правилами фильтрации.
| Тип входа | Назначение | Проблема без него |
|---|---|---|
| System Context | Роль, глобальные правила, форматы ответа | LLM забывает кто она и отвечает в стихах |
| Dynamic Context | Фактические извлеченные куски из базы знаний | Галлюцинации, ссылки на несуществующие документы |
| Tool Context | Описание доступных функций и их аргументов | LLM пытается вызвать несуществующий API, крашит пайплайн |
| Dialog Context | История предыдущих сообщений, строго усеченная | Потеря нити диалога, дублирующие вопросы |
Каждый из этих входов — не просто концепция, а готовый ноутбук с кодом. Открываешь, меняешь пару параметров, запускаешь — и видишь, как точность ответов взлетает. Именно такие референсные имплементации критически не хватало сообществу: RAG Doctor молча кивает — диагностика проблем без эталонов была гаданием.
Почему это не очередная модная фишка
Звучит как банальная типизация, которую любой инженер и сам применит. Но дьявол в деталях: в ноутбуках LangChain не просто разделили контекст, а внедрили стриктные схемы валидации для каждого куска. Например, Dynamic Context проверяет, что релевантные чанки не превышают лимит токенов модели, причем с запасом на ответ. Tool Context сериализует функции в OpenAPI-подобную схему и дает LLM только те инструменты, которые реально доступны. Это предотвращает 90% галлюцинаций, связанных с вызовом несуществующих методов.
Где живут звери: репозитории и реальный код
Все четыре ноутбука лежат в открытом доступе в репозитории langchain-ai/context-engineering. Каждый — отдельный .ipynb с примерами на Python 3.12+. Никакого ада зависимостей — только LangChain 0.3+, OpenAI или локальная LLM через Ollama. Карпати настойчиво рекомендует запускать именно через LangGraph, потому что там можно наглядно отследить, какой вход в какой момент активируется.
Пример из ноутбука Dynamic Context: вы загружаете PDF с регламентом, система разбивает его на чанки по 512 токенов, для каждого чанка считает эмбеддинг (используется text-embedding-3-large), потом по запросу извлекает топ-5 чанков. Но! Прежде чем отправить их в LLM, проходится по каждому чанку специальным проверяющим промптом, который отбрасывает чанки, не содержащие ответа на вопрос. Это фильтрация релевантности — ментальная модель, о которой мы подробно писали.
1 System Context: жесткие рамки личности
Этот ноутбук — первый, с которого стоит начать. Он учит LLM не выходить за пределы своей роли: системное сообщение прогоняется через валидатор намерений. Если пользователь пытается выведать секретный пароль или сделать промпт-инъекцию — System Context перехватывает запрос и возвращает шаблонный отказ, не задействуя остальные контексты. Без этого вся защита RAG летит к чертям, особенно под атаками, описанными в статье про отравление базы знаний.
2 Dynamic Context: живые данные без галлюцинаций
Самый объемный ноутбук. Тут и гибридный поиск (BM25 + векторный), и реранжировщик от Cohere, и, что важно, инжекция источника: каждый чанк приходит с тегом [source: document.pdf, page 14]. LLM обязана вернуть этот тег в ответе. Если она придумала факт — можно отследить, из какого чанка он взялся. Это спасает от ситуаций, когда RAG выдает правдоподобную чушь.
3 Tool Context: API без ошибок
Здесь находится референсная реализация того, как описывать инструменты для LLM. Вместо расплывчатых текстовых описаний — строгая JSON-схема параметров. Ноутбук показывает, как с помощью Pydantic конвертировать сигнатуры Python-функций в OpenAPI-совместимый формат, а потом подавать их в ChatML с пометкой role="tool". Попутно реализован автоматический retry при неудачных вызовах — LLM получает обратно сообщение об ошибке и корректирует запрос.
4 Dialog Context: память без переполнения
Вечная боль — окно контекста. Ноутбук предлагает алгоритм скользящего окна с приоритетом: последние 3 сообщения, плюс любое сообщение, где модель упомянула, что запомнила факт. Этот алгоритм используют в продакшене Shopify — не зря Лютке подписался под концепцией. Без Dialog Context ваш RAG-бот будет забывать, что пользователь в предыдущем вопросе указал дату, и предлагать варианты из прошлого века.
Кому это спасет проект (а кому не нужно)
Если вы собираете RAG для поддержки клиентов или внутреннего базы знаний — четыре входа станут вашим спасением. Тесты в ноутбуках показывают снижение галлюцинаций на 40-60% по сравнению с обычным пайплайном LangChain из документации. Особенно это важно, когда документация меняется каждый месяц: Dynamic Context с проверкой релевантности автоматом подхватывает новые версии.
Но есть и обратная сторона: если у вас простой чат-бот без поиска по документам, где LLM просто болтает — типизация входов только замедлит разработку. Для холодильников и погодных ботов это оверкилл.
Еще один нюанс: ноутбуки написаны под LangChain 0.3. Если вы используете устаревшую цепочку LLMChain, придется мигрировать на LangGraph. А это не всегда тривиально — проверено на горьком опыте авторов Ragex.
Альтернативы: кто еще пропагандирует Context Engineering?
Помимо LangChain, похожий подход продвигает Anthropic в своих шаблонах для Claude 5 (сборка 2026 года) — они явно разделяют system prompt, context documents и toolkit. Но их реализация проприетарна. Еще есть KodaCode, но их сравнение с Context7 показало, что без типизации входов они дают 30% ложных ответов.
Фреймворк Haystack 3.0 (июнь 2026) ввел понятие «контекстных pipeline-сегментов», но у них нет готовых ноутбуков под четыре входа — только документация. LangChain выигрывает за счет доступности «как есть».
Тренд на 2026: не просто RAG, а контекстная архитектура
Мы стоим на пороге, когда инженерия контекста станет такой же обязательной дисциплиной, как инженерия данных. Четыре входа от Карпати и LangChain — это только начало. Уже сейчас заметно, как сообщество начинает обсуждать пятый тип (контекст безопасности) и шестой (контекст пользовательских предпочтений). Если вы строите RAG-систему в 2026 году — не игнорируйте эти ноутбуки.
Мой прогноз: к концу года каждая вторая статья про RAG будет ссылаться на этот репозиторий. А те, кто продолжат пихать все в один промпт, будут удивляться, почему их LLM-боты так тупят на фоне конкурентов. Не будьте теми, кто удивляется.
