Навесні 2023 року світ хвилювався з приводу появи агентів AI на базі LLM. Потужні демонстрації, як Аутогпт і Бебіагі продемонстрував потенціал LLMS, що працює в циклі, вибираючи наступну дію, спостерігаючи за її результатами та вибираючи наступну дію, по одному кроку (також відомий як рамка реагування). Очікувалося, що цей новий метод живлення, які автономно та загалом виконують багатоетапні завдання. Дайте йому мету та набір інструментів, і він подбає про решту. До кінця 2024 року ландшафт буде сповнений агентів AI та рамок будівництва агентів AI. Але як вони вимірюють проти обіцянки?
Можна з упевненістю сказати, що агенти, що працюють на наївності Рамка реагування страждають від важких обмежень. Дайте їм завдання, яке вимагає більше кількох кроків, використовуючи більше кількох інструментів, і вони нещасно провалюються. Крім їх очевидних проблем із затримкою, вони втратять трек, не зможуть дотримуватися інструкцій, зупиняються занадто рано або зупиняться занадто пізно і дадуть дико різні результати в кожній спробі. І це не дивно. Рамка React здійснює обмеження непередбачуваних LLM та сполукає їх кількістю кроків. Однак агентські будівельники, які хочуть вирішити випадки використання реального світу, особливо на підприємстві, не можуть зробити з таким рівнем продуктивності. Вони потребують надійних, передбачуваних та пояснюваних результатів для складних багатоетапних робочих процесів. І їм потрібні системи AI, які пом’якшують, а не посилюють непередбачуваний характер LLM.
То як сьогодні агенти будуються на підприємстві? Для випадків використання, які потребують більш ніж декількох інструментів та декількох кроків (наприклад, розмовна ганчірка), сьогодні будівельники агентів значною мірою відмовилися конкретний випадок використання. Цей підхід нагадує традиційну інженерію програмного забезпечення і далеко не агентна обіцянка реагування. Він досягає більш високого рівня контролю та надійності, але не вистачає автономії та гнучкості. Таким чином, рішення є інтенсивними, вузькими в застосуванні та занадто жорсткими для вирішення високих рівнів варіації вхідного простору та навколишнього середовища.
Безумовно, статичні практики ланцюга можуть відрізнятися тим, наскільки вони “статичні”. Деякі ланцюги використовують LLMS лише для виконання атомних кроків (наприклад, для вилучення інформації, узагальнення тексту або складання повідомлення), а інші також використовують LLMS, щоб приймати деякі рішення динамічно під час виконання (наприклад, маршрутизацію LLM між альтернативними потоками в ланцюзі або LLM, що підтверджує результат кроку, щоб визначити, чи слід його запустити знову). У будь-якому випадку, поки LLM несе відповідальність за будь-яке динамічне прийняття рішень у рішеннях-ми неминуче спіймані у компромісі між надійністю та самостійністю. Чим більше рішення є статичним, є більш надійним і передбачуваним, але також менш автономним, а отже, більш вузьким у застосуванні та більш інтенсивному розвитку. Чим більше рішення є динамічним і автономним, є більш загальним і простим у побудові, але також менш надійним і передбачуваним.
Цей компроміс може бути представлений у наступній графіці:
Це ставить питання, чому ми ще не побачили агентського рамки, які можна розмістити у верхньому правому квадранті? Чи приречені ми назавжди торгувати надійністю для самостійності? Чи не можемо ми отримати рамку, яка забезпечує простий інтерфейс агента React (візьміть мету та набір інструментів та розібратися), не жертвуючи надійністю?
Відповідь – ми можемо, і ми будемо! Але для цього нам потрібно усвідомити, що ми робимо це все неправильно. Усі поточні рамки будівництва агентів мають загальну недолік: вони покладаються на LLMS як на динамічний, автономний компонент. Однак важливий елемент, який нам не вистачає – те, що нам потрібно створювати агенти, які є як автономними, так і надійними – є технологіями планування. І LLMS – це не великі планувальники.
Але по -перше, що таке “планування”? Під «плануванням» ми маємо на увазі здатність чітко моделювати альтернативні курси дій, що призводять до бажаного результату, та ефективно досліджувати та використовувати ці альтернативи в бюджетних обмеженнях. Планування слід проводити як на макро, так і на мікрорівні. Макроплан розбиває завдання на залежні та незалежні кроки, які повинні бути виконані для досягнення бажаного результату. Часто не помічається потреба в мікроплануванні, спрямованому на гарантування бажаних результатів на рівні кроку. Існує багато доступних стратегій підвищення надійності та досягнення гарантій на одноетапному рівні, використовуючи більше обчислень часу. Наприклад, ви можете перефразувати семантичні пошукові запити кілька разів, ви можете отримати більше контексту за заданий запит, можете використовувати більшу модель, і ви можете отримати більше висновків від LLM-все це призвело до більшої відповідальності результатів, з яких можна вибрати найкращий. Хороший мікропланер може ефективно використовувати обчислення часу для виводу для досягнення найкращих результатів за даним бюджетом обчислення та затримки. Щоб масштабувати інвестиції ресурсів, як це потрібно, конкретне завдання. Таким чином, планові системи AI можуть пом’якшити ймовірнісну природу LLM для досягнення гарантованих результатів на рівні кроку. Без таких гарантій ми повернулися до проблеми помилок ускладнення, яка підірве навіть найкращий план на макрорівні.
Але чому LLMS не може служити планувальниками? Зрештою, вони здатні перетворити інструкції високого рівня в розумні ланцюги думки або плани, визначені природною мовою чи кодом. Причина полягає в тому, що планування вимагає більше цього. Планування вимагає можливості моделювати альтернативні курси дій, які можуть обґрунтовано призвести до бажаного результату та міркувати про очікувану корисність та очікувані витрати (в обчислювальній та/або затримці) кожної альтернативи. Незважаючи на те, що LLM можуть потенційно генерувати уявлення про наявні курси дій, вони не можуть передбачити відповідну очікувану корисність та витрати. Наприклад, які очікувані корисність та витрати на використання Model X проти моделі Y для створення відповіді за певним контекстом? Яка очікувана корисність шукати певну інформацію в індексованих документах Corpus проти виклику API до CRM? Ваш LLM не починає мати підказку. І з поважних причин – історичні сліди цих ймовірнісних ознак рідко зустрічаються в дикій природі і не включаються до даних про навчання LLM. Вони також, як правило, є специфічними для конкретного інструменту та середовища даних, в якому буде працювати система AI, на відміну від загальних знань, які LLM можуть здобути. І навіть якщо LLMS може передбачити очікувану корисність та витрати, міркування про них на вибір найефективнішого курсу дій-це логічне теоретичне рішення, яке не може вважатися надійно виконаним за допомогою прогнозів LLMS поруч.
То які пропущені інгредієнти для технології планування AI? Нам потрібні моделі планувальників, які можуть навчитися досвіду та моделюванню, щоб явно моделювати альтернативні курси дій та відповідні ймовірності корисності та витрат на певне завдання в певному інструменті та середовищі даних. Нам потрібна мова визначення плану (PDL), яка може бути використана для представлення та міркування щодо зазначених курсів дій та ймовірностей. Нам потрібен двигун виконання, який може детермінально та ефективно виконувати заданий план, визначений у PDL.
Деякі люди вже наполегливо працюють над виконанням цієї обіцянки. До цього часу продовжуйте будувати статичні ланцюги. Просто, будь ласка, не називайте їх “агентами”.
