ai-agents-for-beginners

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

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

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

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

Вступ

Урок охоплює:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Види контексту, які AI-агенту може знадобитися керувати:

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

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

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

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

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

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

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

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

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

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

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

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

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

Пробний запис агента Це дозволяє AI-агенту робити нотатки про релевантну інформацію щодо поточних завдань та взаємодій із користувачем під час однієї сесії. Це має існувати поза межами вікна контексту у файлі або об’єкті часу виконання, який агент може пізніше отримати під час цієї сесії, якщо потрібно.
Спогади Пробні записи добре підходять для керування інформацією поза межами вікна контексту однієї сесії. Спогади дають змогу агентам зберігати та отримувати релевантну інформацію між кількома сесіями. Це може включати резюме, вподобання користувача і відгуки для покращень у майбутньому.
Стиснення контексту Коли вікно контексту зростає і наближається до свого ліміту, можна застосовувати техніки, такі як узагальнення й обрізання. Це включає або збереження лише найбільш релевантної інформації, або видалення старіших повідомлень.
Системи з кількома агентами Розробка систем з кількома агентами є видом контекстного інженерства, оскільки кожен агент має своє вікно контексту. Як цей контекст розподіляється та передається між різними агентами — це ще одна річ, яку потрібно планувати при створенні таких систем.
Пісочниці Якщо агенту потрібно виконати певний код або обробити велику кількість інформації у документі, це може потребувати багато токенів для обробки результатів. Замість того, щоб зберігати все це у вікні контексту, агент може використовувати пісочницю для запуску цього коду й читати лише результати та іншу релевантну інформацію.
Об’єкти стану часу виконання Це робиться шляхом створення контейнерів інформації для керування ситуаціями, коли агенту потрібно мати доступ до певної інформації. Для складного завдання це дозволяє агенту послідовно зберігати результати кожного підзавдання, дозволяючи контексту залишатися пов’язаним лише з відповідним підзавданням.

Приклад контекстного інженерства

Припустимо, ми хочемо, щоб 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-агентів.

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

This site is open source. Improve this page.