AgentBench: Оценяване на LLM като агенти — уроци за надеждността на ИИ във финансите

Когато се питам какво всъщност трябва да прави надеждно един Beancount агент за запис (write-back), отговорът не е „генериране на текст“ — той е „извършване на поредица от действия в структурирана среда, без да излиза от релси“. AgentBench (Liu et al., Tsinghua, ICLR 2024) е един от първите сериозни опити за измерване на тази способност в голям мащаб и данните от моментната снимка през 2023 г. все още съдържат уроци, които си струва да бъдат извлечени.

Статията

AgentBench, дело на Сяо Лиу и 21 съавтори от университета Цинхуа, дефинира осем среди, предназначени да тестват под стрес LLM като интерактивни агенти, а не като пасивни генератори на текст. Пет среди са оригинални: OS (bash взаимодействие), Database (генериране на SQL и възстановяване от грешки), Knowledge Graph (структурирани заявки, базирани на инструменти), Digital Card Game (многоходова стратегическа конкуренция) и Lateral Thinking Puzzles (дедуктивен диалог). Три са адаптирани от предишни масиви от данни: House-Holding от ALFWorld, Web Shopping от WebShop и Web Browsing от Mind2Web. Статията оценява 27 модела — търговски API модели и модели с отворен код до 70B — чрез приблизително 4 000 dev-split и 13 000 test-split генерации и отчита както нивата на успеваемост за всяка среда, така и съставен общ резултат.

Ключови идеи

• GPT-4 води с общ резултат от 4.01. Claude-2 постига 2.49, GPT-3.5-turbo 2.32. CodeLlama-34B, най-силният модел с отворен код към момента на изпращане, постига само 0.96. Моделите, базирани на API, имат средно 2.24 общо срещу 0.42 за тези с отворен код.
• GPT-4 постига 42.4% в OS, 32.0% в Database и 78.0% в House-Holding — диапазонът разкрива кои среди възнаграждават следването на инструкции спрямо структурираното разсъждение.
• „Превишаване на лимита на задачите“ (Task Limit Exceeded) е доминиращият режим на отказ: 67.9% от отказите в Knowledge Graph достигат лимита от стъпки преди решаването на задачата. Това е провал в разсъждението за дълъг хоризонт, а не провал в знанията.
• Грешките в съответствието на формата представляват 53.3% от отказите на задачи в Database — агентът генерира синтактично грешен SQL или обгръща заявките в проза, която оценителят не може да анализира.
• Изборът на невалидно действие е причина за 64.1% от отказите в House-Holding — агентът посочва действие, което не е налично в текущото състояние.
• Обучението върху код има „амбивалентно въздействие върху задачите“: помага в среди, следващи процедури, но може да навреди на общото разсъждение в такива с интензивен диалог.

Какво остава актуално — и какво не

Основният избор на дизайн — мулти-среда, многоходова, интерактивна оценка — е правилен и остава недостатъчно използван. Повечето LLM бенчмаркове все още измерват качеството на генерация в един ход; AgentBench правилно настоява, че агентите трябва да продължат да вземат решения, докато задачата не бъде изпълнена или бюджетът не се изчерпи.

Въпреки това, моментната снимка е остаряла по начин, който има значение. Пропастта между GPT-4 (4.01) и най-добрия модел с отворен код (0.96) изглеждаше тревожна в средата на 2023 г., но до голяма степен се затвори до 2025 г. Модели като Llama 3.1 70B или Qwen 2.5 72B сега преминават бариерите за следване на инструкции и съответствие на формата, които бяха нови препятствия преди две години. Четенето на статията като доказателство, че „отвореният код не може да изпълнява агентски задачи“, би било грешка; четенето ѝ като доказателство, че „съответствието на формата и последователността в дълъг хоризонт са трудните проблеми“, все още е валидно.

Съществува и напрежение между ширина и дълбочина. Осем среди звучат всеобхватно, но всяка от тях е сравнително плитка. WebArena (Zhou et al., 2024) обхваща само сърфирането в мрежата с 812 шаблонни задачи с дълъг хоризонт; OSWorld (Xie et al., 2024) оценява 369 реални десктоп задачи на Ubuntu и Windows. AgentBench може да ви даде сигнал за различните среди, но няма да замени специфичен за даден домейн бенчмарк, след като сте идентифицирали средата, която ви интересува.

Таксономията на режимите на отказ в Таблица 4 е вероятно най-трайният принос. Авторите разделят отказите на: Превишен лимит на задачите, Грешка във формата, Невалидно действие и няколко други. Това не са грешки в имплементацията — те са структурни слабости в начина, по който LLM поддържат състояние, проследяват наличните действия и произвеждат анализируем изход под напрежението на няколко хода. Всяка сериозна агентска система трябва да ги адресира.

Защо това е важно за финансовия ИИ

Трите доминиращи режима на отказ се съпоставят почти директно с това, което бих очаквал да провали един Beancount агент за запис.

Превишен лимит на задачите (Task Limit Exceeded) е режимът на отказ при равняване на сметки. Равняването на приключването на период за няколко сметки изисква проверка на началните салда, напасване на дебити и кредити, идентифициране на несъответствия и предлагане на корекции — верига, която лесно може да достигне 10–20 стъпки. Агент, който изчерпи своя контекст или лимит от стъпки в средата на веригата и се откаже, не просто се проваля грациозно; той може да остави главната книга в частично променено състояние.

Грешка във формата (Format Error) е режимът на отказ при въвеждане на трансакции. Beancount има строг синтаксис: неправилно оформен запис (липсваща валута, грешна индентация, невалиден флаг) е грешка при парсване, която поврежда файла. Агент, който генерира проза около своя Beancount изход или произвежда изглеждащ правилно синтаксис в грешен формат, е безполезен. Това е основният проблем на статията CRITIC, приложен към по-строг домейн.

Невалидно действие (Invalid Action) е проблемът с безопасността на записа. Агент на Beancount, работещ върху реална главна книга, има ограничен набор от безопасни операции: добавяне на трансакция, коригиране на флаг, преместване на запис. Халюцинирането на действие извън този набор — например изтриване на сметка, която все още има отворени позиции — е провал в коректността, който може да не бъде уловен до извършването на одит.

Констатацията, че „обучението върху код има амбивалентно въздействие“, също е уместна. Записът в Beancount е по-близо до генерирането на код, отколкото до извличането на знания, така че модел, предварително обучен върху код, би трябвало да е естествен избор. Но ако обучението върху код влошава следването на диалог в многоходови настройки, е необходима хибридна оценка (като тази на AgentBench), за да излязат наяве тези компромиси преди внедряването.

Какво да прочетете след това

• WebArena (Zhou et al., 2024; arXiv:2307.13854) — 812 задачи за сърфиране в реална браузърна среда; задълбоченото продължение на уеб нивото на AgentBench.
• OSWorld (Xie et al., 2024; NeurIPS 2024) — бенчмарк за пълна десктоп среда, включително задачи за файлова система и GUI; OS средата на OSWorld е директен и по-дълбок наследник на OS нивото на AgentBench.
• TAU-bench (Yao et al., 2024) — оценява агенти в среди на API за търговия на дребно и авиолинии с реално използване на инструменти и симулация на потребители; най-близкият публикуван бенчмарк до настройка на Beancount главна книга като среда.