Gorilla: Как обучението с отчитане на извличането намалява халюцинациите в LLM API от 78% на 11%

Чета статията за Gorilla (Patil et al., 2023, arXiv:2305.15334, NeurIPS 2024), защото тя се намира в пресечната точка на два проблема, с които се сблъсквам постоянно: как да накараме LLM агент да извика правилния инструмент с правилните аргументи и как да поддържаме тази способност жива, докато API-тата се променят? Отговорите тук са практически, а цифрите са изненадващо убедителни — но предположенията, залегнали в оценката, заслужават по-внимателно разглеждане, отколкото обикновено получават.

Статията

Gorilla, разработена от Shishir G. Patil, Tianjun Zhang, Xin Wang и Joseph E. Gonzalez в UC Berkeley, разглежда един конкретен режим на отказ: съвременните LLM халюцинират API извиквания. Когато бъдат помолени да напишат код, който извиква специфична библиотечна функция, GPT-4 (към средата на 2023 г.) често генерира изглеждащи правдоподобно, но грешни функционални сигнатури, несъществуващи модели или остарели имена на аргументи. Gorilla е базиран на LLaMA модел със 7 милиарда параметри, фино настроен специално за генериране на точни API извиквания, обучен чрез техника, която авторите наричат Retriever-Aware Training (RAT). Идеята е проста: по време на обучението на модела се показва извлечена API документация заедно с потребителската заявка, форматирана като „Използвайте тази API документация за справка: <retrieved_API_doc_JSON>“. Това учи модела както да чете документация, така и да се доверява на извлечения контекст пред своята параметрична памет — свойство, което носи дивиденти по време на инференция, когато документацията се е променила.

Наборът от данни за оценка, APIBench, обхваща 925 API-та на HuggingFace Model Hub, 95 API-та на TorchHub и 696 API-та на TensorFlow Hub, с десет синтетични заявки за следване на инструкции, генерирани за всяко API чрез self-instruct. Метриката за оценка е съпоставяне на поддърво на AST (абстрактно синтактично дърво) — генерираното API извикване се анализира и се проверява за функционална коректност — което също така позволява за първи път в тази среда принципно измерване на процента на халюцинации.

Ключови идеи

• RAT прави документацията четима по време на инференция. Чрез обучение върху подкани (prompts), които включват извлечена документация, Gorilla се научава да се позовава на извлечения текст, вместо да извиква API детайли от теглата си. Това означава, че моделът остава актуален при развитието на API-тата без необходимост от повторно обучение.
• Точност при zero-shot: Gorilla 59–84%, GPT-4 18–39%. В TorchHub Gorilla постига 59,13% срещу 38,70% за GPT-4. В HuggingFace резултатът е 71,68% срещу 19,80%. В TensorFlow Hub – 83,79% срещу 18,20%. Разликата е най-голяма там, където API пространството е най-разнообразно.
• Намаляването на халюцинациите е водещата новина. Процентът на халюцинации на Gorilla е 6,98% в TorchHub, 10,95% в HuggingFace и 5,40% в TensorFlow Hub. Процентите на GPT-4 варират от 36,55% до 78,65% в същите набори от данни.
• Оракулният ретривър (oracle retriever) е таванът. С извлечен документ от „златния стандарт“ (режим оракул), точността достига 67–94%. Това е теоретично най-добрият случай за всяка RAG-базирана система, а разликата между Gorilla в режим zero-shot и този таван е полето за подобрение на ретривъра.
• Реалните ретривъри не достигат очакванията. Преминаването от оракул към GPT-Index по време на оценка влошава точността с 29,20%; BM25 я влошава с 52,27%. Устойчивостта на модела към шума при извличане е реална, но не и неограничена.
• AST оценката се обобщава успешно. Подходът за съпоставяне на поддървета измерва дали генерираното извикване е функционално коректно, а не просто синтактично подобно. Това е правилната метрика за всяка задача, при която изходът е код, който действително ще се изпълнява.

Какво се потвърждава — и какво не

Основното твърдение е валидно: фината настройка върху подкани, допълнени с документация, драстично подобрява точността на API извикванията и намалява халюцинациите. Методологията за оценка чрез AST е истински иновативна и очевидно по-добра от сравняването на низове или човешката оценка в голям мащаб. RAT е чиста, възпроизводима идея.

Това, към което съм скептичен, е обхватът на бенчмарка. И трите набора от данни — HuggingFace, TorchHub, TensorFlow Hub — са регистри на ML модели с много правилна API структура: зареждате модел по име, евентуално с няколко ключови аргумента, и извиквате метод от типа predict. Инструкциите са генерирани синтетично, което означава, че тестовото разпределение е тясно свързано с тренировъчното разпределение. Модел, настроен върху документация за ML API, обучен чрез self-instruct и оценяван чрез self-instruct заявки за ML API, не се тества върху трудностите, които се появяват в реална среда: двусмислени заявки, многостепенни работни процеси, принудително задаване на типове аргументи, автентификация, ограничения на скоростта (rate limits) или възстановяване след грешки.

Деградацията при извличане също е по-голяма, отколкото рамката на статията предполага. Спад от 52% в точността при използване на BM25 извличане е катастрофален. Ако ретривърът, който внедрявате в реална среда, прилича повече на BM25, отколкото на оракул, ползите се изпаряват. Авторите признават тази празнина, но не предлагат път за нейното затваряне.

И накрая, самият модел е фино настроен 7B LLaMA. Сравнението с GPT-4 zero-shot е поразително, но не е съвсем справедливо: GPT-4 не е обучаван да използва извлечена документация. Една RAG-допълнена версия на GPT-4 със системна подкана, проектирана да чете API документация, почти сигурно би затворила разликата значително.

Защо това е важно за финансовия изкуствен интелект

Моделът RAT е пряко приложим за Beancount агенти за записване (write-back agents). Един Beancount агент трябва да извиква CLI команди (bean-query, bean-report), Python API-та (beancount.loader, beancount.core) и услугата beancount-ledger FastAPI — всяко със специфична семантика на аргументите, която е документирана, но не е задължително в тренировъчните данни на модела. Подходът на Gorilla казва: извлечете съответния фрагмент от документацията по време на инференция, вмъкнете го в контекста и обучете модела да го чете и следва.

Цифрите за халюцинации са най-полезният сигнал във финансов контекст. 10% халюцинации при имената на ML модели са досадни. 10% халюцинации при извиквания за промяна в счетоводната книга — грешни имена на сметки, грешни валутни кодове, обърнати знаци за дебит/кредит — са проблем с коректността. Изводът е, че дори агент, обучен в стил Gorilla, се нуждае от валидатор по време на изпълнение, преди да бъде потвърден какъвто и да е запис, в съответствие с това, което CRITIC (LOG-012) показа за интерактивната критика с инструменти. Констатацията за деградацията при извличане потвърждава това: ако реалното извличане намалява точността наполовина, защитната мрежа не може да бъде само качеството на самото извличане.

Методологията за оценка чрез AST се пренася по естествен начин. Транзакциите в Beancount имат структура, която може да се анализира, и проверката на генерираните директиви спрямо схема чрез AST съпоставяне е точно този вид лек валидатор, който би могъл да работи в pre-commit hook или в цикъла на агента.

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

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) — разширява проблема с API извикванията до 16 000 реални REST API с многостепенни вериги за използване на инструменти; директно адресира ограничението на Gorilla да оценява само единични извиквания към ML регистри.
• The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, NeurIPS 2024 poster) — пряката еволюция на Gorilla в жива класация, проследяваща как водещите модели подобряват извикването на функции с течение на времето; V3 добавя взаимодействия с множество ходове, V4 добавя агентно уеб търсене.
• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — оценява LLM върху 73 API-та в по-широк спектър от области, включително финанси и уеб услуги, с многостепенно използване на инструменти; полезно допълнение към по-тесния ML фокус на APIBench.