Їх обіцяли нам агентів, але всі, що ми отримали, – статичні ланцюги

Весною 2023 року світ зазнал збудження через появу агентів, заснованих на LLM. Потужні демонстрації, такі як AutoGPT і BabyAGI, продемонстрували потенціал LLM, що працюють у циклі, вибирають наступну дію, спостерігають за результатами та вибирають наступну дію, крок за кроком (також відомий як框 ReACT). Цей новий метод мав забезпечити агентів, які автономно та універсально виконують багатокрокові завдання. Дайте їм мету та набір інструментів, і вони займуться рештою. До кінця 2024 року ландшафт буде повний агентів та фреймворків для побудови агентів. Але як вони вимірюються проти обіцянки?

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

Так як агенти будуються сьогодні в корпоративному секторі? Для випадків використання, які вимагають більше ніж кілька інструментів і кілька кроків (наприклад, розмовний RAG), сьогодні будівельники агентів у великому ступені відмовилися від динамічного та автономного обіцянки ReACT заради методів, які сильно залежать від статичної ланцюгів – створення попередньо визначених ланцюгів, призначених для вирішення конкретного випадку використання. Цій підхід нагадує традиційний інженерний підхід до програмного забезпечення і далеко від агентської обіцянки ReACT. Він досягає вищого рівня контролю та надійності, але не має автономності та гнучкості. Рішення тому розробницько-інтенсивні, вузькі за застосуванням та надто жорсткі, щоб звернутися до високого рівня варіації у вхідному просторі та середовищі.

Щоб бути певним, практики статичної ланцюгів можуть варіюватися в тому, наскільки “статичними” вони є. Деякі ланцюги використовують LLM лише для виконання атомарних кроків (наприклад, для витягування інформації, підсумовування тексту або складання повідомлення), тоді як інші також використовують LLM для прийняття деяких рішень динамічно під час виконання (наприклад, LLM маршрутизації між альтернативними потоками у ланцюзі або LLM валідатори результату кроку для визначення того, чи потрібно його виконувати знову). У будь-якому випадку, поки LLM відповідають за будь-яке динамічне прийняття рішень у рішенні – ми невідворотно потрапляємо у компроміс між надійністю та автономією. Чим більше рішення статичне, тим воно надійніше та передбачуваніше, але також менше автономне та вузьке за застосуванням та розробницько-інтенсивніше. Чим більше рішення динамічне та автономне, тим воно універсальніше та простіше для побудови, але також менше надійне та передбачуване.

Цей компроміс можна представити у наступній графіці:

Це викликає питання, чому ми ще не бачимо агентського фреймворка, який можна розмістити у верхньому правому квадранті? Чи ми засуджені назавжди торгувати надійністю за автономію? Чи не можемо ми отримати фреймворк, який забезпечує простий інтерфейс ReACT-агента (взяти мету та набір інструментів і розібратися з рештою) без жертвування надійністю?

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

Але спочатку, що таке “планування”? Під “плануванням” ми розуміємо можливість явно моделювати альтернативні курси дій, які ведуть до бажаного результату, і ефективно досліджувати та використовувати ці альтернативи під бюджетними обмеженнями. Планування повинно здійснюватися на макро- та мікро-рівнях. Макро-план розбиває завдання на залежні та незалежні кроки, які повинні бути виконані для досягнення бажаного результату. Що часто залишається поза увагою, це необхідність мікро-планування, спрямованого на гарантії бажаних результатів на рівні кроку. Є багато доступних стратегій для підвищення надійності та досягнення гарантій на рівні окремого кроку за допомогою більшої кількості обчислювальних ресурсів під час виконання. Наприклад, ви можете перефразувати семантичні запити пошуку кілька разів, можете витягнути більше контексту за певний запит, можете використовувати більшу модель, і можете отримати більше висновків з LLM – все це призводить до більш вимогливих результатів, з яких можна вибрати найкращий. Гарний мікро-планувальник може ефективно використовувати обчислювальні ресурси під час виконання для досягнення найкращих результатів під заданим бюджетом обчислень та затримки. Таким чином, планомірні системи штучного інтелекту можуть пом’якшити ймовірнісну природу LLM для досягнення гарантованих результатів на рівні кроку. Без таких гарантій ми повертаємося до проблеми компаундової помилки, яка підірве навіть найкращий макро-рівневий план.

Але чому LLM не можуть служити планувальниками? Адже вони здатні перекладати високорівневі інструкції у розумні ланцюги думок або плани, визначені природною мовою або кодом. Причина полягає в тому, що планування вимагає більшого. Планування вимагає можливості моделювати альтернативні курси дій, які можуть розумно привести до бажаного результату І reason about очікуваної корисності та очікуваних витрат (у обчислювальних ресурсах та/або затримці) кожної альтернативи. Хоча LLM можуть потенційно генерувати представлення доступних курсів дій, вони не можуть передбачити їхню відповідну очікувану корисність та витрати. Наприклад, які очікувана корисність та витрати використання моделі X проти моделі Y для генерації відповіді за певний контекст? Яка очікувана корисність пошуку певної інформації у корпусі документів проти API-дзвінка до CRM? Ваш LLM навіть не починає здогадуватися. І з хорошої причини – історичні сліди цих ймовірнісних ознак рідко зустрічаються у дикій природі та не включаються до навчальних даних LLM. Вони також схильні бути специфічними для конкретного інструменту та середовища даних, у якому система штучного інтелекту буде працювати, на відміну від загальних знань, які можуть отримати LLM. І навіть якщо LLM могли б передбачити очікувану корисність та витрати, розуміння про них для вибору найбільш ефективного курсу дій є логічним рішення-теоретичним висновком, який не можна вважати надійно виконаним прогнозами наступного токену LLM.

Такі ж інгредієнти відсутні для технології штучного інтелекту планування? Нам потрібні моделі планувальників, які можуть навчатися з досвіду та симуляції для явного моделювання альтернативних курсів дій та відповідної корисності та ймовірності витрат за певним завданням у певному інструменті та середовищі даних. Нам потрібна мова визначення плану (PDL), яка може бути використана для представлення та розуміння курсів дій та ймовірностей. Нам потрібен виконавчий двигун, який може детермінативно та ефективно виконувати заданий план, визначений у PDL.

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