ai-agents-for-beginners

Інженерія контексту для AI-агентів

(Клікніть на зображення вище, щоб переглянути відео цього уроку)

Розуміння складності застосунку, для якого ви створюєте AI-агента, важливе для створення надійного агента. Нам потрібно створювати AI-агентів, які ефективно управляють інформацією для вирішення складних потреб за межами простого створення підказок.

У цьому уроці ми розглянемо, що таке інженерія контексту і яку роль вона відіграє у створенні AI-агентів.

Вступ

У цьому уроці ми охопимо:

• Що таке інженерія контексту і чим вона відрізняється від інженерії підказок.

• Стратегії ефективної інженерії контексту, включно з тим, як писати, обирати, стискати та ізолювати інформацію.

• Поширені помилки з контекстом, які можуть зруйнувати ваш AI-агент, і як їх виправити.

Цілі навчання

Після завершення цього уроку ви будете розуміти, як:

• Визначити інженерію контексту та відрізняти її від інженерії підказок.

• Визначити ключові компоненти контексту у застосунках з великими мовними моделями (LLM).

• Застосовувати стратегії написання, вибору, стиснення та ізоляції контексту для покращення роботи агента.

• Визнавати поширені збої з контекстом, такі як отруєння, відволікання, плутанина та конфлікти, та впроваджувати заходи з їх усунення.

Що таке інженерія контексту?

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

Інженерія підказок проти інженерії контексту

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

Види контексту

Важливо пам’ятати, що контекст — це не просто одна річ. Інформація, яка потрібна AI-агенту, може надходити з різних джерел, і наше завдання — забезпечити доступ агента до цих джерел:

Види контексту, які AI-агент може потребувати для керування, включають:

• Інструкції: Це ніби “правила” агента – підказки, системні повідомлення, приклади Few-shot (щоб показати AI, як щось робити), і описи інструментів, якими агент може користуватися. Тут поєднуються інженерія підказок і інженерія контексту.

• Знання: Охоплює факти, інформацію, отриману з баз даних, або довготривалі спогади агента. Це включає інтеграцію системи Retrieval Augmented Generation (RAG), якщо агенту потрібен доступ до різних сховищ знань і баз даних.

• Інструменти: Це визначення зовнішніх функцій, API і MCP-серверів, які агент може викликати, разом із зворотним зв’язком (результатами) від їх використання.

• Історія розмови: Поточний діалог із користувачем. З часом ці розмови стають довшими та складнішими, що займає місце у вікні контексту.

• Переваги користувача: Інформація про вподобання користувача, накопичена з часом. Її можна зберігати та використовувати під час прийняття важливих рішень на користь користувача.

Стратегії ефективної інженерії контексту

Стратегії планування

Хороша інженерія контексту починається з гарного планування. Ось підхід, який допоможе вам почати розмірковувати над тим, як застосувати концепцію інженерії контексту:

Визначте чіткі результати — результати завдань, які буде виконувати AI-агент, мають бути чітко визначені. Відповідайте на питання: “Яким буде світ, коли AI-агент виконає своє завдання?”. Іншими словами, яку зміну, інформацію чи відповідь повинен отримати користувач після взаємодії з агентом.
Картуйте контекст — після визначення результатів AI-агента, потрібно відповісти на питання “Яку інформацію AI-агент потребує, щоб виконати це завдання?”. Таким чином можна почати картографувати контекст, де ця інформація може бути розташована.
Створіть конвеєри контексту — тепер, коли ви знаєте, де знаходиться інформація, потрібно відповісти на питання “Як агент отримає цю інформацію?”. Це можна зробити різними способами, включно з RAG, використанням MCP-серверів і іншими інструментами.

Практичні стратегії

Планування важливе, але як тільки інформація починає надходити у вікно контексту нашого агента, нам потрібні практичні стратегії для її керування:

Керування контекстом

Хоча частина інформації додаватиметься у вікно контексту автоматично, інженерія контексту означає більш активну позицію щодо цієї інформації, що можна робити за допомогою кількох стратегій:

Нотатник агента (Agent Scratchpad) Це дає змогу AI-агенту робити нотатки про релевантну інформацію щодо поточних завдань і взаємодії з користувачем під час однієї сесії. Він має існувати поза вікном контексту у файлі або об’єкті під час виконання, який агент може пізніше отримати протягом цієї сесії, якщо потрібно.
Спогади (Memories) Нотатники гарні для керування інформацією поза вікном контексту однієї сесії. Спогади дозволяють агентам зберігати та отримувати релевантну інформацію між кількома сесіями. Це може включати резюме, вподобання користувачів і відгуки для майбутніх покращень.
Стиснення контексту Коли вікно контексту зростає і наближається до свого ліміту, можна використовувати такі техніки як узагальнення (резюме) та обрізання. Це означає або зберігання лише найрелевантнішої інформації, або видалення старіших повідомлень.
Багатоагентні системи Розробка багатоагентних систем — це форма інженерії контексту, тому що в кожного агента є своє вікно контексту. Як цей контекст передається й ділиться між агентами — це ще один аспект для планування при створенні цих систем.
Пісочниці (Sandbox Environments) Якщо агенту потрібно виконати якийсь код або обробити великий обсяг інформації в документі, це може займати багато токенів для обробки результатів. Замість того, щоб зберігати це все у вікні контексту, агент може використовувати пісочницю, яка виконуватиме код і лише зчитуватиме результати і іншу релевантну інформацію.
Обʼєкти стану під час виконання (Runtime State Objects) Це робиться шляхом створення контейнерів інформації для керування ситуаціями, коли агенту потрібен доступ до певної інформації. Для складного завдання це дасть змогу агенту зберігати результати кожного підзавдання покроково, дозволяючи контексту залишатися пов’язаним лише з цим конкретним підзавданням.

Інспекція контексту

Після застосування однієї з цих стратегій варто перевірити, що саме отримав наступний виклик моделі. Корисне питання для відладки:

Чи завантажив агент забагато контексту, неправильний контекст, чи пропустив потрібний контекст?

Вам не потрібно логувати сирі підказки, виводи інструментів чи вміст пам’яті для відповіді на це питання. У виробництві краще робити невеликі записи перевірки контексту, які включають підрахунки, ідентифікатори, хеші та етикетки політик:

Відбір: Відстежуйте, скільки кандидатських блоків, інструментів або спогадів було розглянуто, скільки вибрано, і яке правило або оцінка призвели до фільтрації інших.
Стиснення: Записуйте діапазон джерела або ідентифікатор трасування, ідентифікатор резюме, приблизну кількість токенів до і після стиснення, а також чи було сирий вміст вилучено з наступного виклику.
Ізоляція: Занотовуйте, яке підзавдання виконувалося в окремому агенті, сесії або пісочниці, який обмежений підсумок повернуто і чи великий вивід інструментів залишився поза контекстом головного агента.
Пам’ять і RAG: Зберігайте ідентифікатори документів для витягу, ідентифікатори пам’яті, оцінки, вибрані ідентифікатори та статус редагування замість повного тексту, що був витягнутий.
Безпека і конфіденційність: Віддавайте перевагу хешам, ідентифікаторам, токен-бакетам та етикеткам політик замість чутливого тексту підказок, аргументів інструментів, результатів інструментів або тіл пам’яті користувача.

Мета не у зберіганні більшого контексту. Мета — залишити достатньо свідчень, щоб розробник міг визначити, яка стратегія контексту працювала і чи вона змінила наступний виклик моделі бажаним чином.

Приклад інженерії контексту

Припустимо, ми хочемо, щоб AI-агент “Забронював мені подорож до Парижа.”

• Простий агент, що використовує лише інженерію підказок, міг би просто відповісти: “Добре, коли ви хочете поїхати до Парижа?”. Він обробив лише безпосереднє питання користувача у момент запиту.

• Агент, що використовує стратегії інженерії контексту, зробить набагато більше. Перед тим як відповісти, його система може:

◦ Перевірити ваш календар на вільні дати (отримання даних у реальному часі).

◦ Пригадати попередні вподобання у подорожах (з довготривалої пам’яті), такі як улюблена авіакомпанія, бюджет чи перевага прямих рейсів.

◦ Визначити доступні інструменти для бронювання квитків та готелів.

А потім приклад відповіді може бути: “Привіт, [Ваше імʼя]! Бачу, ви вільні в перший тиждень жовтня. Пошукати прямі рейси до Парижа на [Улюблена авіакомпанія] у межах вашого звичайного бюджету [Бюджет]?”. Ця багатша, контекстно-обізнана відповідь демонструє силу інженерії контексту.

Поширені збої з контекстом

Отруєння контексту

Що це: Коли галюцинація (хибна інформація, згенерована LLM) або помилка потрапляє в контекст і багаторазово посилається, що змушує агента прагнути неможливих цілей або розробляти абсурдні стратегії.

Що робити: Впроваджуйте перевірку контексту і карантин. Перевіряйте інформацію перед додаванням у довготривалу пам’ять. Якщо потенційне отруєння виявлено, починайте нові потоки контексту, щоб запобігти поширенню поганої інформації.

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

Рішення: Впровадити крок, який перевіряє існування рейсу і маршрути через API в реальному часі перед додаванням деталей рейсу у робочий контекст агента. Якщо перевірка не проходить, помилкова інформація “карантинується” і більше не використовується.

Відволікання контексту

Що це: Коли контекст стає настільки великим, що модель занадто фокусується на накопиченій історії замість використання того, чому навчилась під час тренування, що призводить до повторюваних або марних дій. Моделі можуть почати робити помилки ще до заповнення вікна контексту.

Що робити: Використовуйте резюме контексту. Періодично стискайте накопичену інформацію у коротші підсумки, зберігаючи важливі деталі, видаляючи надмірну історію. Це допомагає “скинути” фокус.

Приклад бронювання подорожі: Ви довго обговорювали різні мрійливі подорожі, зокрема детально переповідали свій походницький рейс два роки тому. Коли ви нарешті просите “знайди мені дешевий рейс на наступний місяць,” агент застрягає в старих, неактуальних деталях і постійно питає про ваше спорядження або минулі маршрути, ігноруючи ваш поточний запит.

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

Плутанина контексту

Що це: Коли зайвий контекст, часто у вигляді надмірної кількості доступних інструментів, змушує модель генерувати погані відповіді або викликати нерелевантні інструменти. Особливо це притаманно меншим моделям.

Що робити: Впроваджуйте керування набором інструментів за допомогою методів RAG. Зберігайте описи інструментів у векторній базі даних і вибирайте лише найрелевантніші інструменти для кожного конкретного завдання. Дослідження показують, що кількість інструментів має бути обмежена менш ніж 30.

Приклад бронювання подорожі: Ваш агент має доступ до десятків інструментів: book_flight, book_hotel, rent_car, find_tours, currency_converter, weather_forecast, restaurant_reservations тощо. Ви питаєте: “Який найкращий спосіб пересуватися Парижем?” Через велику кількість інструментів агент заплутався і намагається викликати book_flight в межах Парижа або rent_car, хоча ви віддаєте перевагу громадському транспорту, бо описи інструментів можуть перекриватися або він просто не розрізняє найкращий.

Рішення: Використовуйте RAG за описами інструментів. Коли ви питаєте про пересування Парижем, система динамічно витягує лише найрелевантніші інструменти, як-от rent_car чи public_transport_info, базуючись на вашому запиті, надаючи LLM сфокусований набір інструментів.

Конфлікт контексту

Що це: Коли у контексті існує суперечлива інформація, що призводить до непослідовного мислення або поганих кінцевих відповідей. Часто трапляється, коли інформація надходить поетапно, а ранні неправильні припущення залишаються у контексті.

Що робити: Використовуйте обрізку контексту та перенесення. Обрізка означає видалення застарілої або суперечливої інформації по мірі надходження нових деталей. Перенесення дає змогу моделі мати окреме робоче “поле нотаток”, щоб обробляти інформацію, не засмічуючи основний контекст.

Приклад бронювання подорожі: Спочатку ви повідомляєте свого агента: “Я хочу летіти економ-класом.” Пізніше у розмові ви змінюєте думку і кажете: “Насправді, для цієї поїздки давайте оберемо бізнес-клас.” Якщо обидві інструкції залишаються в контексті, агент може отримати суперечливі результати пошуку або заплутатися, яку перевагу слід пріоритетизувати.

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

Маєте більше питань щодо інженерії контексту?

Приєднуйтесь до Microsoft Foundry Discord, щоб зустрітися з іншими учнями, відвідати години консультацій та отримати відповіді на свої питання про AI Агенти.

Попередній урок

Agentic Protocols

Наступний урок

Memory for AI Agents

Відмова від відповідальності: Цей документ було перекладено за допомогою сервісу штучного інтелекту для перекладу Co-op Translator. Хоча ми прагнемо до точності, будь ласка, майте на увазі, що автоматичні переклади можуть містити помилки або неточності. Оригінальний документ рідною мовою слід вважати авторитетним джерелом. Для критично важливої інформації рекомендується професійний людський переклад. Ми не несемо відповідальності за будь-які непорозуміння або неправильні тлумачення, що виникли внаслідок використання цього перекладу.

This site is open source. Improve this page.