Управление контекстом

При ИИ-разработке управление контекстом становится отдельной инженерной задачей. Агенту недостаточно просто дать доступ ко всему проекту: нужно определить, какие файлы, требования, архитектурные решения, документацию и историю изменений действительно нужны для конкретной задачи. Лишний контекст перегружает модель, а недостаток контекста приводит к ошибочным решениям и несогласованному коду.

От качества контекста напрямую зависит эффективность работы LLM

Структурирование корпоративной информации еще на этапе хранения упрощает последующее формирование контекста для LLM

В AI IDE и harness контекст можно формировать динамически: под конкретную задачу агент получает только релевантные части проекта и необходимые инструменты. Например, при изменении API ему нужны спецификация интерфейса, связанные сервисы, модели данных и тесты, но не весь репозиторий. Такой подход позволяет экономить контекстное окно, повышать точность работы агентов и сохранять согласованность разработки.

Основные задачи управления контекстом

Управление контекстом включает несколько ключевых задач, которые позволяют передавать ИИ-агенту именно ту информацию, которая необходима для корректного выполнения конкретной работы.

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

В итоге harness выступает своего рода диспетчером контекста: он решает, что именно должен «знать» каждый ИИ-агент на каждом этапе разработки.

Контекст — это не только промпт

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

Например, при разработке ПО агенту недостаточно инструкции «создай API для заказов». Для качественного результата ему могут потребоваться архитектура проекта, стандарты разработки компании, описание существующих API, модели данных, связанный код и результаты предыдущих действий.

Поэтому контекст становится самостоятельным объектом управления. Задача AI-системы заключается не просто в том, чтобы передать LLM как можно больше информации, а в том, чтобы сформировать правильный набор сведений именно для текущей задачи.

Как выбрать, что передать LLM

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

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

Для отбора контекста используются поиск по документам и коду, индексация, RAG, метаданные, правила доступа и другие механизмы. В более сложных системах AI-агент самостоятельно определяет, какую дополнительную информацию ему необходимо получить.

Таким образом, хороший AI-контур работает не по принципу «дать модели всё», а по принципу «дать модели именно то, что необходимо для выполнения задачи».

Актуальность контекста

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

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

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

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

Слишком много контекста — тоже проблема

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

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

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

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

Контекст для разных агентов разный

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

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

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

Постоянный и временный контекст

Контекст удобно разделять на постоянный и временный. Постоянный контекст содержит сведения, которые применимы к большому числу задач: корпоративные правила, архитектурные принципы, стандарты разработки, требования к безопасности, стиль документации.

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

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

Для AI-разработки это особенно полезно: общие правила проекта остаются постоянными, а контекст конкретной задачи меняется от запроса к запросу.

Контекст между агентами

В мультиагентной разработке появляется еще одна задача — передача результатов между агентами. Например, аналитик формирует требования, архитектор разрабатывает архитектурное решение, разработчик пишет код, а тестировщик проверяет результат.

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

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

Так формируется своеобразная цепочка контекстов, в которой каждый этап получает информацию от предыдущего и добавляет собственный результат. Это особенно важно для AI-native SDLC, где разработка постепенно превращается в последовательность взаимодействующих ИИ-агентов.

Контекст как конкурентное преимущество

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

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

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

Поэтому ценность AI-продукта определяется не только выбором LLM. Важными компонентами становятся качество контекста, система памяти, интеграции, инструменты, оркестрация и harness. В ряде случаев именно этот слой становится главным технологическим отличием одного AI-продукта от другого.

Контекст как часть архитектуры AI-приложения

В простом чат-боте контекст может формироваться практически автоматически из сообщения пользователя и нескольких предыдущих реплик. В корпоративном AI-приложении ситуация значительно сложнее: информация распределена между десятками источников.

Например, ответ сотруднику может потребовать данных из базы знаний, CRM, ERP, DWH и системы управления документами. AI-приложение должно определить, какие источники использовать, получить необходимые данные, проверить права доступа и сформировать из них контекст для LLM.

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

Поэтому в зрелых AI-системах контекст уже нельзя считать просто частью промпта. Это полноценный объект архитектуры, от которого напрямую зависит качество работы модели.

Что делать с огромным проектом

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

На практике AI IDE и AI-агенты используют поиск по коду и документации, индексацию, семантический поиск, RAG и выбор релевантных фрагментов. Агент получает не весь проект, а только ту его часть, которая связана с текущей задачей.

Еще один механизм — сжатие истории. Вместо передачи всей предыдущей переписки система может сформировать краткое резюме: что было сделано, какие решения приняты, какие проблемы остались.

Это позволяет работать с большими проектами даже при ограниченном контекстном окне модели. По сути, AI-система создает виртуальное представление проекта, из которого динамически выбирается необходимая информация.

Безопасность контекста

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

Например, агент, работающий с заявками клиентов, не обязательно должен иметь доступ к финансовым данным компании. Разработческий агент может видеть исходный код проекта, но не иметь доступа к production-базе данных.

Права доступа должны применяться не только к пользователю, но и к AI-агенту и его инструментам. Перед передачей информации в LLM система должна понимать, имеет ли конкретный агент право видеть эти данные и действительно ли они нужны для выполнения задачи.

Популярные вопросы

Нужно ли обучать отдельную LLM под новый контекст?

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

Для этого используются механизмы управления контекстом и RAG (Retrieval-Augmented Generation), при котором система находит релевантную информацию и добавляет ее в запрос к модели. Сама LLM при этом остается неизменной, а ее знания дополняются актуальными данными непосредственно во время работы.

Дообучение (fine-tuning) требуется в других случаях — когда необходимо изменить устойчивое поведение модели: например, научить ее определенному стилю, формату ответов или специфическому способу решения задач. Если же меняются корпоративные документы, требования или кодовая база, обычно достаточно обновить источник контекста.

Для AI-разработки это особенно важно: проект постоянно меняется, поэтому переобучать LLM после каждого изменения нецелесообразно. Гораздо практичнее использовать harness, который динамически формирует актуальный контекст для каждого ИИ-агента.

Можно ли попросить LLM не выдумывать контекст?

Да, это можно и нужно явно задавать в промпте. Модели можно указать, что при отсутствии достоверной информации она должна прямо сообщить, что данных недостаточно или ответ ей неизвестен, а не дополнять информацию предположениями.

Например, в инструкции можно задать правило: «Не выдумывай факты. Если в предоставленном контексте нет ответа на вопрос, напиши, что информации недостаточно». Это снижает вероятность галлюцинаций, особенно если модель работает с заранее определенным набором документов или корпоративных данных.

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

Память AI-системы и контекст — это одно и то же?

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

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

Для корпоративных AI-систем это принципиальное различие. Если сохранять абсолютно всю историю, система быстро накапливает огромный объем информации. Гораздо эффективнее хранить долговременные знания отдельно и извлекать их в контекст по мере необходимости.