Агенти пояснено: інструменти, запити системи та цикл мислення-дії

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

Що таке агент

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

Ваш додаток для чату забуває все

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

Уявіть собі такий обмін:

conversation = [
    {"role": "user", "content": "I need help with my order"},
    {"role": "assistant", "content": "Could you provide your order number?"},
    {"role": "user", "content": "It's ORDER-123"},
]

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

Не існує жодного спеціального кроку „запам’ятати це“. Коли здається, що модель згадує ваш номер замовлення, це не є результатом пам’яті. Цей номер просто все ще знаходиться у тексті, який вона читає в той момент.

Інструменти

Інструмент — це функція, ідеально з однією чітко визначеною метою, яку передають ШІ. Типові приклади включають:

• пошук у Інтернеті
• створення зображень
• отримання документів
• запит до API

Хороший інструмент розширює можливості моделі. Він має містити наступні елементи:

• текстовий опис того, що робить функція

функція, яку можна викликати, тобто код, що виконує дію

аргументи з типизацією

за бажанням — результат із типизацією

Як насправді викликається інструмент

Ключовий момент полягає у тому, що ШІ не може безпосередньо працювати з будь-яким зовнішнім інструментом. Текст надходить та виходить, більше нічого. Коли кажуть, що модель „має доступ до інструментів“, це насправді означає, що вона навчилася записувати вихідний код виклику інструменту у текстовому форматі. Якщо запитати про погоду в Парижі, модель не отримує прогнозу; вона формує структуроване повідомлення з проханням запустити інструмент для отримання погодних даних.

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

Невеликий приклад

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

def multiply(a:int, b:int):
  "Multiply two integers"
  return a * b

Перетворення функції на інструмент

Бібліотека Hugging Face transformers пропонує декоратор @tool, який обгортає звичайну функцію Python, щоб агент міг її зрозуміти. Спочатку потрібно виконати імпорт:

from transformers import tool

Потім функція з декоратором:

@tool
def multiply(a: int, b: int):
    """Multiply two integers."""
    return a * b

У закритому режимі декоратор збирає метадані:

• назву функції
• її опис
• назви аргументів
• типи аргументів
• тип значення, яке повертається

Ці метадані згодом включаються до інструкції, яка пояснює моделі, як правильно використовувати інструмент.

Огляд інструменту

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

print(multiply.to_string())

Роздрукований результат містить деталі приблизно такого змісту:

Tool Name: multiply

Description:
Multiply two integers.Arguments:
- a (int)
- b (int)

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

Робочий процес агента

Агент працює у циклі, що повторюється: він думає (Thought), діє (Action), а потім спостерігає (Observation).

1. Thought. Частина агента у вигляді штучного інтелекту вирішує, що робити далі.
2. Action. Агент викликає інструменти з обраними аргументами.
3. Observation. Модель розглядає те, що повернув інструмент.

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

Системний запит

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

Коли користувач щось пише, модель бачить не лише цей текст. Зазвичай вона отримує щось на кшталт цього:

<System Prompt>

You are a helpful programming assistant.
Always explain concepts before showing code.
If the user asks for unsafe code, refuse politely.

<User>

Explain binary search.

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

Системний запит агента йде ще далі та описує інструменти та сам цикл:

You are an AI assistant that can answer user questions.

You have access to the following tools:

Tool: search_web
Description:
Searches the web for up-to-date information.

Arguments:
- query (string)

Tool: calculator
Description:
Evaluates mathematical expressions.

Arguments:
- expression (string)

If a user's question requires current information, use search_web.
If a calculation is required, use calculator.
Otherwise, answer directly.

У тому повідомленні системи визначені три аспекти:

• як повинен поводитися агент
• які інструменти він може використовувати, описані так, як показано у попередньому розділі
• цикл „Мислення – Дія – Спостереження“, вбудований у інструкції моделі

Кожен з цих трьох етапів заслуговує на більш детальний розгляд.

Мислення

Мислення відображає внутрішню логіку та планування агента під час виконання завдання. Існують два поширені підходи:

1. chain-of-thought (CoT)
2. ReAct (логічне мислення плюс дія)

Chain-of-thought – це метод формулювання запитів, який спонукає модель поступово розв’язувати проблему, перш ніж дати остаточну відповідь. Логічні міркування залишаються внутрішніми, що підходить для логічних та математичних задач, які не потребують зовнішніх інструментів.

ReAct — це метод, який також вимагає поетапного мислення, але поєднує дії, такі як виклики інструментів, між кроками обґрунтування.

Обидва підходи дозволяють ШІ поступово розбиратися з проблемами. Різниця полягає у тому, що CoT залежить лише від того, що модель вже знає, тоді як ReAct поєднує мислення з діями. Це дає моделі можливість використовувати зовнішні інструменти, збирати свіжу інформацію та продовжувати мислити на основі отриманих результатів, що краще підходить для динамічної роботи у реальному світі, яка взаємодіє з зовнішніми системами.

Дії: від мислення до дії

Дії — це кроки, які виконує агент для взаємодії зі своїм середовищем. Агент служби підтримки клієнтів може отримати дані про клієнта, запропонувати статті з підтримкою або передати справу людині.

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

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

Історично дії виражалися у вигляді викликів функцій або об’єктів JSON, які містили назву інструменту та його аргументи. Цей підхід працює, але стає незручним, коли у робочому процесі потрібно багато викликів інструментів. Кодові агенти обирають інший шлях: замість опису дій у форматі JSON модель створює виконуваний код на Python. Таким чином цикли, умови, змінні та кілька викликів інструментів можуть бути об’єднані в один блок коду, що робить його більш виразним та ефективним для складних завдань.

Традиційний формат JSON виглядає так:

{
  "tool": "get_weather",
  "arguments": {"location": "Tokyo"}
}

Агент з коду пише натомість виконуваний фрагмент:

# The agent writes actual Python code as its action
cities = ["Tokyo", "Paris", "New York", "London", "Sydney"]
temps = [get_weather(city) for city in cities]
avg_temp = sum(temps) / len(temps)
print(f"Average temperature: {avg_temp}")

Спостереження: зворотний зв’язок від кожної дії

Міркування та виконання дій — це лише половина справи. Після виконання дії агент мусить зрозуміти її результат, і саме для цього існують спостереження: зворотний зв’язок, отриманий після виконання дії. Це може бути результат пошуку в Інтернеті, відповідь API, результат виконання програми на Python або навіть повідомлення про помилку. Що б це не було, це стає новою інформацією для вибору наступного кроку.

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

Спостереження не обов’язково мають бути успішними. Коли виклик зазнає невдачі — через повідомлення 404 Not Found від кінцевої точки або помилку TypeError у Python у згенерованому коді — ця невдача все одно є корисною. Повідомлення про помилку показує агенту, що пішло не так, щоб його наступні дії могли виправити ситуацію замість того, щоб повторити помилку.

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

Об’єднання елементів

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

Розуміння цих основних елементів та усвідомлення того, наскільки мало „магії“ кожен з них містить, є першим кроком до створення власних агентів. Асистенти для програмування, допоміжні інструменти для досліджень та автономні робочі процеси всі базуються на одному й тому ж циклі „Мислення – Дія – Спостереження“. Наступним логічним кроком є створення першого агента за допомогою екосистеми Hugging Face.