Інженерія контексту для AI-агентів: підбір того, що бачить модель
Чому агенти погіршують свою продуктивність у міру збільшення обсягу контексту, чим інжиніринг контексту відрізняється від формулювання запитів, та простий підхід для вибору того, що бачить кожен виклик моделі.
Штучний інтелект-агент, який добре виконує завдання протягом перших кількох кроків, а потім починає ігнорувати інструкції, повторювати роботу чи покладатися на застарілі дані, зазвичай не має проблем із формулюванням. У нього є проблема з контекстом: модель бачить занадто багато інформації, неправильні дані чи правильні дані у неправильному місці. Інженерія контексту — це галузь, яка допомагає точно визначити, що отримує модель безпосередньо перед тим, як вона має почати міркування; це стосується не лише запиту, а й усього набору інструкцій, історії, отриманих даних та визначень інструментів. У цьому посібнику пояснюється, чому цей набір стає все важливішим у міру розвитку агентів, чотири компоненти, якими ви можете керувати, мінімальний процес складання та моделі збоїв, на які слід звертати увагу.
Основна ідея: невеликий, релевантний фрагмент
Мета полягає не в тому, щоб надати моделі все, що може якимось чином допомогти. Йдеться про те, щоб дати їй лише вузький сегмент інформації, який дозволяє їй правильно відповісти, залишивши решту поза увагою.
Аналогія з людиною пояснює це краще. Якщо попросити нового інженера виправити помилку в кодовій базі з мільйон рядків, сказавши «прочитайте код та знайдіть її», він буде приголомшений — один важливий файл загубиться серед тисяч інших. Якщо ж сказати цьому самому інженеру «проблема, найімовірніше, у модулі оплати, ці три файли змінилися минулого тижня, і ось що намагався зробити попередній користувач», то виправлення може зайняти кілька хвилин. Сам інженер не змінився; змінилася лише інформація, з якою він почав роботу.
Моделі поводяться так само. Інженерія контексту — це процес передачі саме цих трьох файлів замість усього репозиторію.
Чому лише формулювання більше не достатньо
Ранні поради щодо роботи з мовними моделями стосувалися формулювань: як сформулювати інструкції та які формулювання дають кращі відповіді. Це і є інжиніринг запитів, і для окремого запитання це все ще має значення.
Однак агент не відповідає на одне запитання. Він виконує цикл: читає щось, викликає інструмент, отримує результат, обирає наступну дію та повторює цей процес, іноді десятки разів. Кожна ітерація додає ще більше матеріалу до того, що модель має у своєму розпорядженні. Зрештою накопичений контекст стає настільки великим, що важливі деталі залишаються поза увагою, подібно до людини, яка провела цілий день на зустрічах і більше не може пригадати, що було вирішено на першій з них.
Anthropic розглядає інженерію контексту як проблему пошуку найкращого можливого набору інформації для моделі в кожен окремий момент, а не створення однієї хорошої інструкції раз на все. Це відображає зміну підходу: інженерія запитів стосується слів; інженерія контексту — усього того, що є під час відповіді моделі.
Інженерія запитів проти інженерії контексту
Ці два підходи перетинаються, але відрізняються за обсягом, типовим використанням та способами збою:
- Обсяг. Інженерія запитів формує формулювання однієї інструкції. Інженерія контексту керує всім вхідним матеріалом: інструкціями, попередньою розмовою, отриманими фактами та доступними інструментами.
Швидкий діагноз: якщо ваше рішення полягає у зміні слів, ви займаєтесь інжинірингом запитів. Якщо ваше рішення змінює інформацію, яку модель отримує спочатку, ви займаєтесь інжинірингом контексту. Щоб отримати структурований підхід до визначення того, до якого шару належить збій агента, дивіться деталізовану інструкцію з дебаггінгу AI-агентів за шарами.
Чотири компоненти, якими ви керуєте
Контекст кожного агента формується з чотирьох джерел. Кожне з них має свої особливості, через які може виникнути проблема.
Інструкції: опис завдань
Це системний запит, який описує, що має робити агент та як. Якщо він занадто жорсткий, агент не зможе впоратися ні з чим поза межами заданого сценарію. Якщо він занадто свободний, агент буде імпровізувати. Мета — створити настільки конкретні вказівки, щоб сформувати бажану поведінку, не намагаючись заздалегідь описати кожну ситуацію.
Отримання інформації: дослідничий асистент
Отримання інформації полягає у пошуку документів, запитах до бази даних чи читанні файлів для залучення зовнішніх даних. Погане отримання інформації є основною причиною того, чому системи ШІ з впевненістю наводять неправдиву інформацію. Часто модель нічого не вигадує; їй були надані неправильні чи несуттєві факти, і вона обґрунтовано покладалася на них. Покращення якості отримуваної інформації часто приносить більше користі для точності, ніж будь-які зміни у запиті.
Пам’ять: блокнот
Пам’ять охоплює те, що агент зберігає, як під час однієї розмови, так і між сеансами. Без механізму узагальнення та видалення старих даних пам’ять не залишається корисною. Вона постійно зростає, поки більша її частина не стане шумом, який конкурує з інформацією, що має значення зараз.
Інструменти: набір інструментів
Інструменти визначають дії, які може виконувати агент, такі як пошук у Інтернеті, виконання коду чи надсилання електронних листів. Назва та опис кожного інструменту також становлять частину контексту. Набір з десяти перетинаючихся, майже ідентичних інструментів заплутує модель так само, як десять нерозрізнених викруток заплутали б нового працівника. Кілька інструментів з чітко визначеними функціями полегшують вибір та зменшують витрати.
Мінімальний процес формування контексту
Наведений нижче псевдокод демонструє, як ці чотири компоненти поєднуються під час одного виклику моделі. Допоміжні функції є місцями для будь-яких засобів пошуку, ранжування та узагальнення, які ви використовуєте, але структура відображає спосіб, яким реальні системи підходять до вирішення проблеми.
Цей процес відбувається у чотирьох етапах. Спочатку відбувається широкий пошук із допуском певних помилок, при цьому встановлений великий ліміт у 50 кандидатів. Далі ці кандидати ранжуються, і залишаються лише п’ятеро найкращих. Потім історія розмови стискається у резюме об’ємом до 500 одиниць замість повного відтворення. Нарешті елементи розташовуються у певному порядку: спочатку йдуть інструкції, а останньою — поточне запитання, причому результат скорочується відповідно до виділеного бюджету.
def get_context_for_the_model(question, past_conversation, budget):
# Step 1: Cast a wide net — search broadly, don't worry about noise yet
possible_facts = search_everywhere(question, limit=50)
# Step 2: Narrow it down - keep only the genuinely relevant ones
best_facts = keep_most_relevant(possible_facts, top=5)
# Step 3: Summarize old conversation instead of keeping all of it
short_memory = summarize(past_conversation, max_length=500)
# Step 4: Put the most important things first and last, not buried in the middle
final_context = [
job_description, # instructions
short_memory, # memory
*best_facts, # retrieval
question, # what's being asked right now, last
]
return trim_to_fit(final_context, budget)
У цьому прикладі є дві звички, які варто запозичити.
Спочатку шукайте широко, а потім суворо фільтруйте. Широкий пошук зменшує ризик пропустити відповідний документ, а ретельне ранжування зберігає кінцевий контекст компактним. Якщо робити лише перше, модель буде перевантажена, а якщо лише друге — існує ризик так і не знайти потрібний матеріал.
Покладіть те, що має значення, на краї. Розмістіть найважливіший контент на початку або в кінці вхідних даних, а не посередині. Це не стилістична примха. Дослідження довгих вхідних даних неодноразово показували, що моделі менш надійно сприймають інформацію, розташовану посередині довгого контексту — цей ефект часто називають «втрачено в середині». Сила цього ефекту залежить від моделі, тож перевіряйте його у своїх умовах, але правильне розташування завжди є ефективним засобом.
За тією самою логікою випливають кілька практичних удосконалень. Заздалегідь вирішіть, як розподілити бюджет між компонентами, щоб велика кількість результатів пошуку не могла тихо витіснити інструкції. Під час оптимізації спочатку видаліть найменш релевантні знайдені елементи, перш ніж торкатися інструкцій чи поточного запиту. Також фіксуйте остаточний зібраний контекст для кожного виклику; якщо агент поводиться неправильно, цей запис зазвичай показує причину.
Що йде не так, коли контекст не підготовлений ретельно
Включення всього на випадок
Додавання кожного можливо релевантного елемента здається відповідальним кроком, але зазвичай призводить до негативних наслідків. Чим більше несуміжного матеріалу мусить обробляти модель, тим гірше вона справляється з пошуком самого важливого факту. Це еквівалентно читанню сторінкового звіту перед прийняттям рішення, яке триває п’ять хвилин.
Застаріла інформація
Якщо ніхто не перевіряє, чи залишається отриманий контент актуальним, модель створюватиме впевнену відповідь на основі інформації, яка вже кілька місяців не є правдивою. Метадані про свіжість, правила закінчення терміну дії чи повторна перевірка для джерел, чутливих до часу, — усе це допомагає.
Приховування ключового факту
Навіть коли пошук знаходить саме той факт, його розміщення посеред довгого блоку збільшує статистичні шанси на його пропуск. Факт залишається незмінним; змінилась лише його позиція, і результат погіршується.
Занадто багато схожих варіантів
Якщо співробітник вашої команди не може з упевненістю сказати, який інструмент чи документ підходить у конкретній ситуації, модель не покращить ситуацію. Об’єднайте перекриваючіся інструменти та усуньте дублікати майже ідентичних документів ще до того, як вони потраплять у контекст.
Поширені запитання
Чи замінює інженерія контексту інженерію запитів?
Ні. Чіткі інструкції залишаються частиною завдання. Інженерія контексту — це більша задача, яка їх оточує: вирішення питання про те, що ще бачить модель окрім самої інструкції.
Чому більше інформації може погіршити результати?
Увага є обмеженим ресурсом як для моделей, так і для людей. Чим більше матеріалу мусить обробити модель, тим вища ймовірність того, що вона пропустить саме ту деталь, яка мала значення, так само, як людина має труднощі з пошуком одного важливого рядка у довгому документі.
Чи вирішує більший контекстний вікно проблему?
Воно допомагає, забезпечуючи простір, але не усуває основної проблеми. Інформація в середині довгих вхідних даних все одно використовується менш надійно, а зростання об’єму вхідних даних призводить до збільшення затримки та витрат. Вибір того, що потрапляє всередину, залишається важливим навіть при дуже великих вікнах.
Ключові висновки
- Розглядайте вхідні дані моделі як спеціально створений продукт, сформований для кожного запиту, а не як простий журнал записів.
- Ретельно керуйте усіма чотирма компонентами: інструкціями, процесом пошуку, пам’яттю та інструментами — кожен з них може зламатися по-своєму.
- Здійснюйте широкий пошук, ефективно ранжуйте результати, узагальнюйте історію та розміщуйте найважливіший контент на початку чи в кінці.
- Якщо агент починає погіршувати свою роботу протягом багатьох кроків, перевірте, що йому було надано, перш ніж переписувати отримані інструкції.
- Більший обсяг даних дає більше простору, але не гарантує стійкості; ключовим залишається правило передачі лише трьох потрібних файлів, а не всієї бази коду.