Инженерия контекста ИИ заключается в проектировании всей совокупности информации, ограничений и инструкций, окружающих агента, чтобы он понимал, что может видеть, что должен делать и как ему вести себя при столкновении с новой ситуацией или неполными данными. Согласно объяснению Doug Whitley, директора по инженерии в Stack Overflow, и Ash Zade, директора по продуктам, цель состоит не в том, чтобы перегрузить агента всеми доступными данными, а в том, чтобы предоставить ему определённый контекст, необходимый для выполнения задачи с предсказуемым результатом.
Об этом говорилось в интервью, опубликованном в Stack Overflow Blog в рамках серии “No Dumb Questions”. В нём обсуждались различия между инженерией контекста, инфраструктурой контекста и инженерией контекста, а также связь этих понятий с технологиями RAG и MCP и причины, по которым компании предпочитают покупать готовые решения, а не создавать всё самостоятельно.
От инфраструктуры к инженерии
Whitley различает инфраструктуру контекста, связанную со способом хранения, отображения и передачи контекста агенту, и инженерию контекста, сосредоточенную на проектировании системы и причинах, по которым её компоненты организуются определённым образом. Инженерия контекста в исполнительном смысле связана с фактическим созданием системы, например с выбором алгоритмов, языков программирования и используемых инструментов.
Он помещает RAG в область, объединяющую все три уровня. Индексы, хранилища контекста и методы поиска относятся к инфраструктурной стороне, тогда как создание системы на таком языке, как .NET, Python или Rust, относится к инженерии. В свою очередь, архитектура определяет общую форму системы и правила, регулирующие её работу. MCP Whitley считает протоколом с определёнными требованиями, однако решение о его интеграции в систему, используемых языках и поддерживаемых функциях относится к проектированию.
Сокращение пространства решений, принимаемых агентом
Zade объясняет эту идею на примере поиска автомобильных шин. Если отправить агента в библиотеку на поиски «шин», он может найти сведения о шинах для самолётов, велосипедов и тачек, поскольку все они соответствуют запрошенному слову. Однако грамотно спроектированная система с самого начала определяет, что задача связана с автомобильными шинами или конкретно со спортивными автомобильными шинами, и ограничивает доступную информацию этими рамками.
Zade считает, что размещение таких инструкций только в текстовом запросе не гарантирует их соблюдения агентом. Поэтому инженерия контекста требует контролировать данные, к которым агент может получить доступ, а также определять его действия при столкновении с неполной или неверной информацией. Благодаря этому некоторые переменные исключаются из решений агента, вместо того чтобы оставлять ему возможность самостоятельно решать, заслуживает ли информация доверия или следует ли расширить область поиска.
Система также включает память агента, позволяющую ему сохранять сведения о том, что он сделал, чему научился, о чём общался и что создал к настоящему моменту. Значение этой памяти возрастает, когда работают несколько агентов или когда задача приостанавливается, а затем возобновляется.
Доверие, разрешения и участие человека
По словам выступающих, Stack Internal представляет собой пример связи контекста с системой доверия и процессом проверки экспертами. Знания классифицируются по уровням — высокому, среднему или низкому. Если уровень средний или низкий, пользователя можно направить к эксперту по соответствующей теме для проверки информации или восполнения пробелов, вместо того чтобы агент принимал решение на основе неподтверждённых знаний.
Защита данных выходит за рамки вопроса о том, может ли агент видеть определённую информацию. Сведения могут быть доступны пользователю, но неподходящими для задачи, которую выполняет агент. Поэтому выступающие описывают два уровня контроля:
- Разрешения источника: агент наследует разрешения пользователя в системах, по которым он выполняет поиск, таких как Slack, MS Teams, Google Drive или SharePoint.
- Области: пользователь может сузить диапазон данных, доступных агенту, даже если сам имеет разрешение на доступ к более широкому набору информации.
- Новые данные: можно ограничить то, что агент создаёт или возвращает в систему, чтобы сначала отправлять это пользователю и не добавлять автоматически в общую базу знаний или не делиться этим с командой.
Это различие показывает, что управление контекстом связано не только с поиском, но также с контролем памяти и знаний, создаваемых агентом.
Почему компания может купить решение, а не создавать его?
Whitley говорит, что создать инженерию контекста возможно, но задача не ограничивается написанием кода. Когда компания собирает данные из Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub и Jira, ей необходимо определить, как выполнять индексацию, сортировку и повторное ранжирование, а также как работать с противоречивой, неполной или неверной информацией.
Zade считает, что значительная часть работы связана с определением самого понятия доверия. Опытный пользователь может доверять результатам ИИ, когда они соответствуют его ожиданиям и предыдущему опыту, однако такой подход в равной степени недоступен людям, не обладающим опытом в области, в которой они поручают ИИ работать. Поэтому система требует обсуждения того, что делает информацию заслуживающей доверия, а не только технических решений для её сбора.
Whitley добавляет, что покупка готового решения может предоставить компании накопленный опыт решения проблем, с которыми сталкивались другие клиенты, включая крайние случаи и повседневные проблемы, которые его команда, по его словам, классифицирует примерно по 20 категориям. При этом выступающие не исключают внутреннюю разработку: она может быть уместна, если сценарий использования новый или компании необходимы собственные проектные решения.
Для Whitley и Zade качество инженерии контекста измеряется гибкостью системы и её способностью выдавать согласованные и предсказуемые результаты, а не простым ограничением системы одной задачей. Раннее фильтрование информации также может сократить количество токенов, обрабатываемых агентом: поиск в книгах об автомобилях дешевле поиска во всей библиотеке, а поиск по страницам о шинах дешевле просмотра всех книг. Конечной целью остаётся дать агенту возможность выполнить ожидаемую задачу, остановиться или запросить помощь человека, когда он достигает границ, которые не должен пересекать.