В работе с языковыми моделями хороший промпт по-прежнему важен, но в сложных системах он уже не определяет результат сам по себе. Все больше зависит от контекста, который получает модель: какие файлы и документы видит, какие инструменты может использовать, что знает о предыдущих этапах работы и какую информацию сохраняет в памяти. Поэтому разработчику приходится проектировать уже не отдельный запрос, а всю систему передачи данных между этапами работы модели. О значении и принципах контекста для ИИ рассказал эксперт Алексей Могильников. Этот подход называют инженерией контекста (context engineering): вместо идеального промпта разработчик проектирует, какие данные модель получит на каждом шаге. Давайте разбираться.
Утверждение, что промпты перестали быть главным, справедливо не для любой задачи. Если человек просто задает модели вопрос, формулировка по-прежнему имеет значение. Но чем сложнее задача, тем меньше результат зависит от одной инструкции или формулировки запроса к ИИ.
При разработке от исходной идеи до готового продукта всегда есть несколько этапов. На каждом — свои данные, промежуточные результаты и проверки. Система должна уметь контролировать эти этапы, передавать результаты дальше, возвращаться к предыдущему шагу и учитывать обратную связь.
В этой схеме роль играет вся связка целиком. При базово подходящей модели и нормально составленном промпте, качество результата определяется именно тем, насколько правильно организована работа между этапами.
А вот выбор самой модели и ее тонкая настройка остаются важными, но не единственными критическими факторами. Если система плохо управляет исходными данными, историей и результатами промежуточных действий, более сильная модель проблему не решит. Недостаточно просто выбрать нейронку помощнее и надеяться, что уж она-то справится.
Что такое инженерия контекста и чем она отличается от промпт-инжиниринга
Инженерия контекста — более широкое понятие, чем работа с промптами. Промпт — это инструкция для модели: что нужно сделать, какие ограничения соблюсти, какой результат вернуть. Контекст же включает все данные, доступные модели во время работы, в том числе промпт.
Для задач разработки контекстом могут быть файлы с исходным кодом, документация, списки, результаты предыдущих этапов, измененные файлы, дополнительные вводные, состояние тестовых стендов и журналы работы систем.
Если агент занимается исправлением ошибки, ему понадобится информация о том, как ошибка проявлялась, где ее удалось воспроизвести, какие данные с ней связаны и как проверить результат после внесения изменений.
Если работа состоит из нескольких этапов, результат одного шага становится входными данными для следующего. Измененный код, подготовленная документация или другие артефакты тоже попадают в контекст.
Поэтому задача инженерии контекста — понять, что именно модель должна знать в конкретный момент, чтобы выполнить свою часть работы.
Контекстное окно: почему нельзя загрузить в модель все подряд
Самое очевидное решение — собрать всю доступную информацию и передать ее модели одним большим запросом. Но это ошибочный путь, который только приведет к проблемам. Дело в том, что размер контекста всегда конечен. Даже модели с очень большим контекстным окном не могут принимать бесконечный объем данных и корректно его обрабатывать.
Но ограничение по размеру — лишь часть проблемы. Вторая состоит в том, что увеличение контекста не обязательно приводит к лучшему результату.
Если загрузить слишком много материалов, модель может сосредоточиться не на той информации, которая действительно важна для задачи. Когда в одном запросе смешиваются разные данные в больших объемах, то значимые фрагменты начинают конкурировать за внимание модели с тем, что сейчас ей вообще не нужно.
Поэтому задача ИИ-разработчика вообще не в том, чтобы заполнить доступное окно полностью. Модели нужно передавать ровно тот контекст, который необходим для конкретной операции. Даже если контекстное окно вмещает порядка миллиона токенов, это не отменяет проблемы. Возможность технически поместить большой объем текста в запрос еще не означает, что это лучший способ построить систему.
Из чего состоит контекст ИИ-агента: инструменты, история, документы
Особенно показательно эта проблема проявляется у ИИ-агентов — систем, где модель выполняет последовательность действий. Такому агенту мало одной инструкции. Ему нужно знать, с каким проектом он работает, какие правила должен соблюдать, какие инструменты ему доступны и как этими инструментами пользоваться.
В контекст также могут попадать документы, результаты предыдущих этапов и внешние материалы. Если агент работает в цикле, появляется еще один источник данных — история его собственных действий. Агент вызывает инструмент, получает результат, анализирует его, принимает следующее решение и так далее. Так вызовы инструментов и их результаты постепенно становятся частью контекста.
Поэтому при проектировании необходимо заранее определить, что действительно потребуется модели на очередном шаге. Если данные не нужны для текущего действия, нет смысла автоматически отправлять их снова.
То же относится к инструментам. Модели стоит предоставлять набор возможностей, необходимых именно для текущей части работы, вместе с понятным описанием того, как они устроены и когда должны использоваться.
Как это выглядит на практике, можно посмотреть на бесплатном воркшопе 10 сентября: за два часа собираем фронтенд для готового бэкенда мессенджера.
Пример архитектуры ИИ-агента: как он чинит баг по шагам
Рассмотрим эти принципы на примере агента, который помогает исправлять ошибки в программном продукте. Сначала система получает задачу: описание ошибки и сведения о том, как она проявилась. На первом этапе агенту может не понадобиться весь исходный код проекта. Ему достаточно понять проблему и определить, какие данные нужно получить для расследования.
Затем агент переходит к анализу. Теперь в его контекст можно добавить связанные с проблемой файлы, документацию и журналы работы системы. При необходимости он использует доступные инструменты, чтобы получить дополнительные сведения.
После того как предполагаемую причину обнаружили, начинается следующий этап — изменение кода. Здесь модели уже не обязательно снова передавать всю историю расследования. Ей нужны сама задача, вывод предыдущего этапа, подходящие файлы и требования к исправлению.
После внесения изменений агент переходит к проверке. На этом шаге ему могут понадобиться измененный код, состояние тестового стенда и результаты тестов. Если проверка показывает, что проблема сохранилась, система возвращает агента на предыдущий этап и добавляет в контекст новую информацию о том, что именно не сработало.
Получается такая последовательность: описание проблемы → получение нужных данных → анализ → изменение → проверка → возврат к анализу или изменению при необходимости.
Здесь важен именно способ передачи информации между элементами цепочки. Каждый этап получает свой набор данных. Результат предыдущего шага превращается в новый артефакт, который можно использовать в работе дальше.
Такой агент состоит не только из модели и промпта. Вокруг появляются инструменты, данные, история действий, промежуточные результаты и код, который управляет всем этим контекстом. Именно этот управляющий слой и определяет, что именно модель увидит сейчас, а что понадобится позже, и какую часть истории можно больше вообще не передавать. Как такой слой устроен изнутри, мы разбирали в материале Анатомия агентного харнесса.
Зачем ИИ-агенту внешняя память и как ей управлять
В короткой задаче история может целиком помещаться в контекст. Но агенты, автоматизирующие длительные бизнес-процессы, способны работать долго. Они выполняют множество действий, получают новые данные и постепенно накапливают все большую историю. Рано или поздно эта история перестает помещаться в контекст. Тогда часть старой информации приходится сокращать или сжимать. В результате некоторые детали могут теряться.
Чтобы важные сведения не исчезали, агенту можно дать внешнюю память. В простейшем варианте это обычный файл. В инструкциях задается правило: если появляется информация, которая понадобится в будущем, ее нужно в этот файл записать.
После сжатия контекста агент может обнаружить, что ему не хватает какого-то знания. Тогда он обратится к памяти. Но наличие памяти не решает проблему автоматически. Нужно заранее определить правила: что следует сохранять и насколько подробно, а что запоминать не нужно. Управление памятью становится частью управления контекстом. У сложного агента память может быть многоуровневой, храниться в базах данных или использовать графовую структуру связей между данными. Если хочется собрать такого агента руками, есть разбор с рабочим кодом: Как создать ИИ-агента на Python.
Что такое RAG и как он связан с инженерией контекста
Представим модель, которая должна отвечать на вопросы по большому набору документов. В простейшем варианте можно было бы загрузить все документы в контекст. Но если их много, такой подход невозможен.
Другой вариант — дать модели обычный поиск и позволить ей самостоятельно искать нужные сведения. Но результат будет зависеть от того, насколько удачно агент сформулирует запрос и сможет ли найти подходящие материалы. Поэтому для таких задач придумали специализированные механизмы извлечения информации. Один из них — RAG, Retrieval-Augmented Generation, или генерация с дополнением найденной информацией.
Задача RAG в том, чтобы не передавать модели весь корпус документов. Система сначала выбирает информацию, связанную с запросом, и только затем добавляет найденные фрагменты в контекст модели. Так RAG позволяет определить, какую небольшую часть большого внешнего массива данных нужно показать модели в конкретный момент.
Элементарный поиск работает по словам из запроса. Если пользователь ищет документ по определенной формулировке, система находит материалы, где встречаются те же слова. Но подходящий по смыслу текст может быть написан совершенно иначе. Документ может отвечать на вопрос пользователя и при этом не содержать ни одного точного совпадения с его запросом. Поэтому в системах RAG часто используют векторный поиск, который позволяет сравнивать тексты не только по словам, но и по их смысловой близости.
Как работает векторный поиск в RAG: эмбеддинги и косинусная близость
Сначала документы обычно делят на фрагменты. Каждый такой фрагмент преобразуется в векторное представление — одно большое число, описывающее положение текста в многомерном пространстве. Основная идея в том, что близкие по смыслу тексты должны получать близкие векторные представления.
Полученные векторы сохраняются в базе вместе с исходными фрагментами текста. Фактически система хранит соответствие между числовым представлением и фрагментом, из которого оно было получено. Когда приходит запрос пользователя, его преобразуют в вектор тем же способом.
Дальше система сравнивает вектор запроса с сохраненными представлениями и ищет ближайшие. Для оценки сходства может использоваться косинусная близость: чем ближе направления двух векторов, тем выше значение этой меры. После поиска база возвращает связанные с подходящими векторами фрагменты текста. Эти фрагменты добавляются в контекст модели, и уже на их основе она формирует ответ.
В реальной системе между этими этапами могут появляться дополнительные механизмы отбора и обработки. Но базовый принцип остается неизменным: сначала найти наиболее подходящую информацию, затем передать ее модели. Векторные базы, RAG и дообучение подробно разбираются на курсе LLM-разработчик
RAG — часть информационного поиска, а не отдельная технология
Инженерия контекста не сводится только к RAG. Задача поиска подходящей информации появилась задолго до современных языковых моделей. Обычная поисковая система решает очень похожую проблему: пользователь вводит запрос, после чего нужно выбрать из большого набора документов те, которые лучше всего ему соответствуют.
Поэтому работа с RAG находится внутри более широкой области информационного поиска. Векторный поиск — один из подходов. RAG — один из способов передать найденные сведения языковой модели. В зависимости от задачи могут использоваться и другие методы извлечения и отбора документов. Поэтому разработчику таких систем важно разбираться не только в устройстве LLM, но и в том, как вообще строится поиск информации.
Как научиться инженерии контекста: что изучать по порядку
Инженерия контекста складывается из нескольких областей, поэтому одного отдельного курса или навыка здесь недостаточно. Нужно закреплять такие навыки:
Практическая работа с языковыми моделями. Получить базовый опыт и понимать, как модель реагирует на инструкции, какие данные ей действительно помогают и что происходит при увеличении контекста. Для желающих разобраться в ИИ-разработке, мы подготовили специальный курс «ИИ для разработчиков 2.0».
Отслеживание исследований и новых практик. Подходы к работе с контекстом продолжают развиваться, и многие рекомендации появляются именно из экспериментов с моделями.
Если система работает с большим количеством документов, отдельно стоит изучать информационный поиск: как устроены поисковые системы, как выбираются подходящие документы и какими способами можно определить их соответствие запросу. Это уже самостоятельное направление информатики со своими учебниками, исследованиями и обзорными материалами.
Для агентных систем добавляется еще один пласт: управление историей работы, доступными инструментами и памятью. Разработчику приходится решать не только, что модель должна сделать, но и какие данные ей потребуются на каждом отдельном шаге.
Понять, как модель меняет поведение при разном контексте, проще всего на сравнении: ChatGPT и Claude на одной задаче с кодом.
Инженерия контекста зависит от задачи: диалог, агент, поиск по документам
Единой схемы управления контекстом для всех приложений не существует.
При обычном диалоге с моделью основной проблемой может стать сохранение важных сведений между разговорами.
Если агент работает долго и выполняет много действий, требуется код, который управляет его историей: выбирает необходимые данные, сокращает лишнее и сохраняет важную информацию во внешней памяти.
Если задача связана с поиском по большому набору документов, появляются RAG и другие способы извлечения информации.
Причина во всех случаях одна: контекст конечен. Поэтому вместо попытки написать идеальный промпт разработчику приходится решать, какую информацию модель должна получить именно сейчас. В сложной ИИ-системе качество определяется полнотой всей цепочки. Именно управление этой цепочкой и есть та самая инженерия контекста.
Коротко: ответы на частые вопросы
Что такое инженерия контекста простыми словами? Это проектирование того, какие данные модель получает в конкретный момент: файлы, документацию, результаты предыдущих шагов, доступные инструменты и историю действий. Промпт отвечает на вопрос «что сделать», контекст — на вопрос «с чем работать».
Чем инженерия контекста отличается от промпт-инжиниринга? Промпт-инжиниринг — про формулировку одной инструкции. Инженерия контекста — про всю систему передачи данных вокруг модели. В простом вопросе к чат-боту решает промпт, в многошаговой системе — организация работы между этапами.
Что такое контекстное окно и почему нельзя загрузить в него все? Это объем данных, который модель может принять за раз. Размер конечен, но главное не в этом: при избытке материалов значимые фрагменты начинают конкурировать за внимание модели с ненужными, и качество падает. Даже окно на миллион токенов не отменяет проблему.
Что такое RAG простыми словами? Retrieval-Augmented Generation — генерация с дополнением найденной информацией. Вместо того чтобы отдавать модели весь корпус документов, система сначала находит фрагменты, связанные с запросом, и добавляет в контекст только их.
Как работает векторный поиск? Документы делят на фрагменты, каждый переводят в вектор — набор чисел, описывающий положение текста в многомерном пространстве. Близкие по смыслу тексты получают близкие векторы. Запрос переводят в вектор тем же способом и ищут ближайшие, например по косинусной близости.
Зачем ИИ-агенту внешняя память? Длинные процессы накапливают историю, которая перестает помещаться в контекст. Часть приходится сжимать, и детали теряются. Внешняя память — в простейшем виде обычный файл — позволяет сохранить то, что понадобится позже, и обратиться к этому после сжатия.