Salta al contingut principal

Gorilla: Com l'entrenament conscient de la recuperació (RAT) redueix les al·lucinacions de l'API dels LLM del 78% a l'11%

· 8 minuts de lectura
Mike Thrift
Mike Thrift
Marketing Manager

Llegint l'article de Gorilla (Patil et al., 2023, arXiv:2305.15334, NeurIPS 2024) perquè es troba en la intersecció de dos problemes amb els quals em trobo constantment: com aconseguim que un agent LLM cridi l'eina adequada amb els arguments correctes, i com mantenim viva aquesta capacitat a mesura que les API canvien? Les respostes aquí són pràctiques i les xifres són sorprenentment sòlides, però les premisses integrades en l'avaluació mereixen més escrutini del que solen rebre.

L'article

2026-05-03-gorilla-llm-retrieval-augmented-api-calling

Gorilla, de Shishir G. Patil, Tianjun Zhang, Xin Wang i Joseph E. Gonzalez a la UC Berkeley, aborda un mode de fallada concret: els LLM d'última generació al·lucinen les crides d'API. Quan se'ls demana que escriguin codi que invoqui una funció específica d'una biblioteca, GPT-4 (a mitjans de 2023) genera freqüentment signatures de funció d'aspecte plausible però incorrectes, models inexistents o noms d'arguments obsolets. Gorilla és un model basat en LLaMA de 7 mil milions de paràmetres ajustat específicament per generar crides d'API precises, entrenat amb una tècnica que els autors anomenen Entrenament Conscient del Recuperador (Retriever-Aware Training, RAT). La idea és senzilla: durant l'entrenament, al model se li mostra la documentació de l'API recuperada juntament amb la consulta de l'usuari, formatada com "Utilitzeu aquesta documentació de l'API com a referència: <retrieved_API_doc_JSON>". Això ensenya al model tant a llegir la documentació com a confiar en el context recuperat per sobre de la seva memòria paramètrica, una propietat que dona fruits en el moment de la inferència quan la documentació ha canviat.

El conjunt de dades d'avaluació, APIBench, cobreix 925 API de HuggingFace Model Hub, 95 API de TorchHub i 696 API de TensorFlow Hub, amb deu consultes sintètiques de seguiment d'instruccions generades per API mitjançant auto-instrucció (self-instruct). La mètrica d'avaluació és la coincidència de sub-arbres AST: la crida d'API generada s'analitza i es comprova la seva correcció funcional, cosa que també permet, per primera vegada en aquest context, una mesura basada en principis de la taxa d'al·lucinació.

Idees clau

  • El RAT fa que la documentació sigui llegible en el moment de la inferència. En entrenar amb indicacions que inclouen documentació recuperada, Gorilla aprèn a delegar en el text recuperat en lloc de recordar els detalls de l'API a partir dels seus pesos. Això significa que el model es manté actualitzat a mesura que les API evolucionen sense necessitat de tornar-lo a entrenar.
  • Precisió zero-shot: Gorilla 59–84%, GPT-4 18–39%. A TorchHub, Gorilla aconsegueix un 59,13% enfront del 38,70% de GPT-4. A HuggingFace, és un 71,68% enfront del 19,80%. A TensorFlow Hub, un 83,79% enfront del 18,20%. El marge és més gran on l'espai de l'API és més divers.
  • La reducció de l'al·lucinació és el titular principal. La taxa d'al·lucinació de Gorilla és del 6,98% a TorchHub, el 10,95% a HuggingFace i el 5,40% a TensorFlow Hub. Les taxes de GPT-4 oscil·len entre el 36,55% i el 78,65% en els mateixos conjunts de dades.
  • El recuperador d'oracle és el sostre. Amb el document de referència real recuperat (mode oracle), la precisió arriba al 67–94%. Aquest és el millor cas teòric per a qualsevol sistema basat en RAG i la bretxa entre Gorilla zero-shot i aquest sostre és l'espai disponible per a la millora del recuperador.
  • Els recuperadors reals es queden curts. Canviar de l'oracle a GPT-Index en el moment de l'avaluació degrada la precisió un 29,20%; BM25 la degrada un 52,27%. La robustesa del model al soroll de recuperació és real, però no il·limitada.
  • L'avaluació AST es generalitza. L'enfocament de coincidència de sub-arbres mesura si la crida generada és funcionalment correcta, no només si és sintàcticament similar. Aquesta és la mètrica adequada per a qualsevol tasca on la sortida sigui codi que realment s'ha d'executar.

Què se sosté — i què no

L'afirmació central se sosté: l'ajustament fi en indicacions augmentades amb documentació millora dràsticament la precisió de les crides d'API i redueix l'al·lucinació. La metodologia d'avaluació AST és genuïnament novel·la i clarament millor que la coincidència de cadenes o l'avaluació humana a escala. El RAT és una idea neta i reproduïble.

El que em genera escepticisme és l'abast del banc de proves. Els tres conjunts de dades —HuggingFace, TorchHub, TensorFlow Hub— són registres de models de ML amb una estructura d'API molt regular: es carrega un model pel seu nom, possiblement amb uns quants arguments de paraules clau, i es crida un mètode tipus predict. Les instruccions es generen sintèticament, cosa que significa que la distribució de prova està estretament relacionada amb la distribució d'entrenament. Un model ajustat amb documentació d'API de ML entrenat mitjançant auto-instrucció, avaluat en consultes d'auto-instrucció per a API de ML, no s'està provant en la dificultat que apareix realment en producció: sol·licituds ambigües, fluxos de treball de diversos passos, coerció de tipus d'arguments, autenticació, límits de velocitat o recuperació d'errors.

La degradació de la recuperació també és més gran del que suggereix l'enfocament de l'article. Una caiguda de precisió del 52% amb la recuperació BM25 és catastròfica. Si el recuperador que desplegues en producció s'assembla més a BM25 que a un oracle, els guanys s'evaporen. Els autors reconeixen aquesta bretxa però no ofereixen un camí per tancar-la.

Finalment, el model en si és un ajustament fi de LLaMA de 7B. La comparació amb GPT-4 zero-shot és cridanera, però la comparació no és del tot justa: GPT-4 no ha estat entrenat per utilitzar documentació recuperada. Un GPT-4 augmentat amb RAG amb una indicació de sistema dissenyada per llegir documentació d'API gairebé segur que tancaria la bretxa considerablement.

Per què això és important per a la IA financera

El patró RAT és directament aplicable als agents d'escriptura de Beancount. Un agent de Beancount ha d'invocar comandes CLI (bean-query, bean-report), API de Python (beancount.loader, beancount.core) i el servei FastAPI de beancount-ledger, cadascun amb semàntiques d'arguments específiques que estan documentades però no necessàriament en les dades d'entrenament del model. L'enfocament de Gorilla diu: recupera el fragment de documentació pertinent en el moment de la inferència, injecta'l en el context i entrena el model per llegir-lo i seguir-lo.

Les xifres d'al·lucinació són el senyal més útil per a un context financer. Una taxa d'al·lucinació del 10% en noms de models de ML és molesta. Una taxa d'al·lucinació del 10% en crides de mutació del llibre major —noms de comptes incorrectes, codis de moneda erronis, signes de dèbit/crèdit invertits— és un problema de correcció. La implicació és que fins i tot un agent entrenat a l'estil Gorilla necessita un validador en temps d'execució abans que es confirmi qualsevol escriptura, d'acord amb el que CRITIC (LOG-012) va mostrar sobre la crítica interactiva amb eines. La troballa sobre la degradació de la recuperació ho reforça: si la recuperació en el món real redueix la precisió a la meitat, la xarxa de seguretat no pot ser només la qualitat de la recuperació.

La metodologia d'avaluació AST es tradueix de manera natural. Les transaccions de Beancount tenen una estructura analitzable, i comprovar les directives generades contra un esquema utilitzant la coincidència AST és exactament el tipus de validador lleuger que podria executar-se en un ganxo de pre-commit o en un bucle d'agent.

Què llegir a continuació

  • ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) — amplia el problema de les crides d'API a 16.000 API REST reals amb cadenes d'ús d'eines de diversos passos; aborda directament la limitació de Gorilla d'avaluar només invocacions de registre de ML d'una sola crida.
  • The Berkeley Function Calling Leaderboard (BFCL) (OpenReview:2GmDdhBdDk, pòster de NeurIPS 2024) — l'evolució directa de Gorilla cap a una taula de classificació viva que fa un seguiment de com els models de frontera milloren en la crida de funcions al llarg del temps; la V3 afegeix interaccions de diversos torns, la V4 afegeix cerca web agèntica.
  • API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs — avalua els LLM en 73 API en una gamma més àmplia de dominis, incloent-hi les finances i els serveis web, amb ús d'eines de diversos torns; un complement útil a l'enfocament més estret d'APIBench en el ML.