L'article​

Zhao, Jin, Li i Gao de la Universitat de Pequín presenten FinRAGBench-V, un banc de proves bilingüe construït a partir de documents financers reals: informes de recerca, estats financers, prospectes, articles acadèmics, revistes i articles de notícies. El corpus de recuperació és substancial —60.780 pàgines en xinès i 51.219 pàgines en anglès en aproximadament 1.100 documents per idioma— combinat amb 1.394 parells de preguntes i respostes anotats per humans que abasten set categories de preguntes: inferència de text, extracció de gràfics i taules, càlcul numèric, consultes sensibles al temps i raonament multipàgina. Més enllà del conjunt de dades, la contribució central de l'article és RGenCite, un sistema base que genera respostes juntament amb citacions visuals a nivell de píxel en forma de coordenades de caixes delimitadores que marquen les regions específiques del document que donen suport a cada afirmació.

Idees clau​

• La recuperació multimodal domina la de només text per un marge aclaparador: ColQwen2, un recuperador de visió i llenguatge basat en incrustacions d'imatges de pàgina, aconsegueix un Recall@10 del 90,13% (xinès) i del 85,86% (anglès). Els millors recuperadors basats en text, BM25 i BGE-M3, es queden al voltant del 42,71%. Aquesta bretxa no és un error d'arrodoniment.
• La precisió de generació és baixa fins i tot per als models més avançats: GPT-4o en anglès assoleix un 43,41% de precisió (ROUGE 24,66); o4-mini en xinès arriba al 58,13% (ROUGE 38,55). Aquests són models propietaris de primer nivell amb una recuperació sòlida ja implementada.
• La citació a nivell de pàgina funciona; a nivell de bloc, no: La recuperació a nivell de pàgina se situa entre el 75–93% per als millors models. La recuperació a nivell de bloc —saber quina cel·la específica de la taula o quina regió del gràfic fonamenta una afirmació— cau al 20–61%. Aquesta és la bretxa clau per a l'audibilitat.
• El raonament numèric i la inferència multipàgina són el primer que fa fallar els models: Les preguntes que requereixen càlculs a través de pàgines o períodes temporals són on la precisió cau més bruscament en tots els sistemes provats.
• Els models propietaris superen substancialment les alternatives de codi obert: La bretxa entre l'API tancada i el codi obert és més gran aquí que en la majoria dels bancs de proves de PNL, cosa que suggereix que el raonament financer visual continua sent un repte no resolt per als models oberts.
• L'autoavaluació de les citacions és imperfecta: L'avaluador de citacions mitjançant retall d'imatges aconsegueix una r de Pearson = 0,68 amb els judicis humans, cosa que és raonable però no prou fiable com per confiar-hi plenament sense un mostreig.

Què se sosté — i què no​

La troballa sobre la recuperació és el resultat més creïble de l'article. Una bretxa de gairebé 50 punts percentuals entre els recuperadors multimodals i els de només text en més de 60.000 pàgines és massa gran per ser ignorada. Quan s'aplica l'OCR a un document financer abans d'indexar-lo, es destrueixen els senyals de disseny estructural —en quina columna apareix un número, si el títol d'una figura modifica la interpretació d'una taula— que resulten ser enormement importants per a la recuperació.

Les xifres de generació són honestes però difícils d'interpretar de manera aïllada. Els autors no desglossen quina part de la bretxa de precisió s'atribueix a errors de recuperació enfront de fallades de generació. Atès que el Recall@10 ja és del 85,86% per a l'anglès, una fracció significativa de les fallades ha de ser del costat de la generació i no de la recuperació. Conèixer aquest desglossament aclariria si el coll d'ampolla és el raonament multimodal o quelcom més fonamental sobre com els MLLM gestionen el llenguatge financer.

El conjunt d'avaluació de 1.394 parells de preguntes i respostes és petit per a l'abast del banc de proves. Dividit en set categories i dos idiomes, alguns segments tenen molt menys de 200 exemples. La significació estadística de les troballes a nivell de categoria queda implícita. Això no és inusual per a un article de referència, però sí que significa que seria fàcil construir comparacions esbiaixades.

El protocol d'avaluació de citacions és una contribució interessant, però una r de Pearson = 0,68 amb les valoracions humanes no és prou forta com per tractar l'autoavaluació com una veritat absoluta per a la fonamentació a nivell de bloc. Els autors ho reconeixen; el treball futur sobre millors mètriques de citació està marcat explícitament.

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

Beancount opera sobre fitxers de llibre major en text pla, la qual cosa fa que el RAG només de text sigui defensable per consultar transaccions passades. Però la tasca comptable més àmplia implica documents que rotundament no són text pla: PDF d'extractes bancaris, factures escanejades, imatges de tiquets, informes anuals amb taules i gràfics incrustats. En el moment en què un agent de Beancount necessita conciliar una entrada del llibre major amb un document font —verificar que un càrrec determinat coincideix amb la factura arxivada—, està fent exactament la tasca que FinRAGBench-V avalua.

La troballa de la citació a nivell de bloc és el que més importa per a aquest cas d'ús. Si un agent ha de justificar una entrada del llibre major assenyalant un element de línia específic en un PDF, i el millor sistema disponible només aconsegueix una recuperació a nivell de bloc del 20–61%, això no està preparat per a una auditoria. Qualsevol flux de treball de Beancount que toqui documents font escanejats necessita una revisió humana fins que aquesta xifra millori substancialment.

La bretxa en la modalitat de recuperació també argumenta fortament contra els fluxos de treball de text pur per a la ingesta de documents. Una imatge de tiquet conté informació de disseny —camps d'import, noms de proveïdors, posicions d'elements de línia— que l'OCR destrueix. Aquesta informació de disseny és precisament el que distingeix el total d'una línia de l'import d'un impost, i FinRAGBench-V demostra que els recuperadors multimodals l'aprofiten de maneres que els recuperadors de text no poden.

Què llegir a continuació​

• ColPali: Efficient Document Retrieval with Vision Language Models — el predecessor de ColQwen2 que va establir l'enfocament d'incrustació visual de pàgines sobre el qual es construeix el millor recuperador de FinRAGBench-V [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — aborda el QA visual multidispositiu amb un marc flexible que gestiona el raonament visual d'un i de diversos salts entre pàgines [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — un banc de proves complementari del 2025 que avalua la sensibilitat temporal en el RAG financer multimodal, directament complementari a la categoria de preguntes sensibles al temps de FinRAGBench-V [arXiv:2503.05185]

L'article​

EnterpriseArena és una simulació de 132 mesos (11 anys) d'assignació de recursos a nivell de CFO (Director Financer). Cada pas temporal representa un mes. L'agent rep observacions parcials de les dades financeres de l'empresa, documents empresarials anonimitzats i senyals macroeconòmics extrets de dades de FRED, CBOE i S&P Global. Té un pressupost de 20 crides a eines per mes distribuïdes en quatre operacions — verificar la posició de caixa, revisar registres financers, analitzar les condicions del mercat i projectar fluxos de caixa — i ha de triar una de les tres accions següents: tancar els llibres (conciliació), sol·licitar finançament (capital propi o deute, amb resultats estocàstics) o passar. La restricció principal és que el saldo de caixa de l'empresa ha de mantenir-se no negatiu en cada pas temporal; qualsevol violació acaba l'episodi amb una puntuació de zero. Si sobreviu, l'agent maximitza la valoració final de l'empresa sota la fórmula Rev_T × 5 + Cash_T − 5.000 × N_tools, que penalitza explícitament l'ús excessiu d'eines.

Es van avaluar onze LLM, incloent-hi Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B i Qwen3.5-9B, juntament amb una base de referència d'experts humans validada per dos professionals de les finances amb 8 i 14 anys d'experiència respectivament.

Idees clau​

• Les taxes de supervivència varien enormement entre models: Qwen3.5-9B sobreviu al 80% de les execucions, Gemini-3.1-Pro al 50%, Claude-Haiku-4.5 i GLM-5 al 20% cadascun, i GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B i Mixtral-8x7B al 0%. La mitjana general dels LLM és del 26%.
• Els models més grans no superen de manera fiable els més petits: Qwen3.5-9B (9.000 milions de paràmetres, 80% de supervivència, 78,8 milions de dòlars de valoració final) bat decisivament Qwen3.5-397B (397.000 milions de paràmetres, 20% de supervivència) i GPT-5.4 (0% de supervivència).
• La bretxa respecte als humans és gran: la base de referència humana aconsegueix el 100% de supervivència i una valoració final de 152,2 milions de dòlars ± 29,6 milions; la mitjana dels LLM és de 28,2 milions de dòlars amb una supervivència del 26%.
• El tancament de llibres és el coll d'ampolla crític: els experts humans tanquen els llibres (concilien) en el 94,3% dels passos temporals; els LLM tenen una mitjana del 19,3%. Aquesta és l'acció que produeix estats financers verídics i permet decisions posteriors racionals.
• Recollir informació sense actuar és letal: Qwen3.5-397B utilitza eines d'anàlisi de mercat i previsió a un ritme elevat durant tota la simulació, però gairebé mai tanca els llibres (taxa de tancament del 0,0%) i gairebé mai sol·licita finançament, morint per esgotament de caixa malgrat "saber" què estava passant.
• La penalització del pressupost d'eines és important: la fórmula de puntuació castiga activament els agents que comproven compulsivament en lloc d'actuar, una restricció que reflecteix el cost d'oportunitat real.

Què se sosté — i què no​

El disseny de doble objectiu — supervivència com a restricció rígida més valoració final — és una de les eleccions més encertades en les comparatives d'agents recents. Reflecteix com operen realment els CFO: no es pot optimitzar el creixement si t'has quedat sense diners. L'anonimització de les dates del calendari i de les identitats de les empreses evita que els models apliquin patrons basats en resultats històrics memoritzats, la qual cosa és una millora metodològica genuïna respecte als rànquings financers que utilitzen tiquets i dates reals.

La taxonomia de modes de fallada que els autors identifiquen a través d'estudis de cas és creïble: GPT-5.4 aconsegueix una taxa d'èxit del 99,1% (el que significa que actua en gairebé cada pas temporal sense fer res), mentre que Qwen3.5-397B confon l'anàlisi amb l'acció. Aquests són modes de fallada de comportament diferents amb remeis diferents.

El que em convenç menys: l'entorn macro estocàstic utilitza soroll gaussià per aproximar els xocs del mercat, cosa que els mateixos autors reconeixen que no pot replicar esdeveniments de tipus "cisne negre" o la irracionalitat humana. El pressupost de 20 crides per mes també és una mica arbitrari; els CFO reals no s'enfronten a aquest tipus de restricció de taxa de consultes sobre la seva pròpia memòria, la qual cosa planteja la qüestió de si el rànquing mesura el judici financer a llarg termini o alguna cosa més propera al RAG sota pressió de recursos. L'estructura d'agent únic és una altra limitació explícita que els autors anomenen: els CFO reals operen dins d'hierarquies de controladors, analistes de planificació i anàlisi financera (FP&A) i equips de tresoreria, i l'article no intenta simular-ho.

La troballa que la mida del model no prediu la supervivència és sorprenent i probablement genuïna, però el mecanisme no s'explica bé. Els autors ho assenyalen sense aprofundir en si es tracta d'una fallada en el seguiment d'instruccions, en la coherència del context llarg o en la calibració del risc.

Per què això és important per a la IA en finances​

L'acció de tancament de llibres a EnterpriseArena és essencialment l'asserció balance de Beancount i el pas de conciliació del llibre major — el moment en què l'agent es compromet amb una visió verídica de l'estat financer abans d'actuar. La troballa que els LLM ometen això el 80% de les vegades es trasllada directament al problema de seguretat de l'escriptura (write-back): un agent que evita la conciliació abans d'actuar és un agent que actua sobre un estat obsolet o al·lucinat. Per a l'automatització de Beancount, això suggereix que el pas de conciliació hauria de ser obligatori i verificable — no opcional — en qualsevol bucle d'agent.

L'horitzó de 132 mesos també és directament anàleg a la gestió d'un llibre major de diversos anys. La troballa que la consciència situacional sostinguda es degrada amb el temps és la mateixa degradació que esperaríem en un agent de Beancount que gestionés cinc anys d'historial de transaccions: fins i tot si l'agent té totes les dades en el context, pot ser que no hi actuï de manera coherent al mes 60. Això suggereix que els punts de control de conciliació forçats periòdicament — no només les consultes reactives — són necessaris en sessions d'agents Beancount de llarga durada.

La trampa de la recollida d'informació en què cau Qwen3.5-397B és una advertència de disseny útil: els agents equipats amb moltes eines de recuperació poden preferir la recuperació al compromís, especialment quan el cost d'una acció incorrecta (corrupció del llibre major) és alt. Les restriccions de pressupost d'eines del tipus que utilitza EnterpriseArena podrien ajudar a imposar una disciplina d'acció en els agents d'escriptura de Beancount.

Què llegir a continuació​

• EcoGym (arXiv:2602.09514) — rànquing d'economia de llarg horitzó complementari en entorns de venda automàtica, freelance i operacions en més de 1.000 passos; cap model domina en els tres, cosa que suggereix que els modes de fallada a EnterpriseArena no són idiosincràtics d'un sol disseny de rànquing.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — reformula el disseny del flux de treball com una cerca en l'espai de codi amb MCTS i retroalimentació de LLM; si EnterpriseArena demostra que els comportaments d'agents dissenyats manualment fallen, AFlow és el següent pas obvi per descobrir millors conductes de manera automàtica.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — el marc fonamental d'entrenament i avaluació de l'ús d'eines; comprendre com s'aprèn el comportament de crida a eines a ToolLLM aclareix si la fallada d'evitació d'accions a EnterpriseArena és un problema d'entrenament o un problema de "prompting".

L'article​

Peijie Yu, Wei Liu, Yifan Yang i els seus col·legues d'Alibaba presenten WildToolBench (arXiv:2604.06185), un banc de proves de 256 escenaris de diàleg multi-torn amb 1.024 tasques extretes de patrons de comportament d'usuaris autèntics i basades en unes 1.600 API públiques. L'argument central és que els bancs de proves existents s'estan saturant no perquè els models siguin bons, sinó perquè les tasques són artificials. Els usuaris reals agrupen peticions, ometen el context que van compartir fa dos torns i alternen entre fer una pregunta sobre una eina, xerrar una mica i demanar un aclariment — de vegades dins d'un mateix missatge. WildToolBench operacionalitza aquests modes de fallada en tres categories de reptes estructurades i mesura tant la precisió a nivell de tasca com la precisió a nivell de sessió, molt més estricta, que requereix tenir èxit en les quatre tasques d'un diàleg.

Idees clau​

• La precisió de sessió es col·lapsa fins a un sol dígit per a la majoria de models: Gemini-2.0-Flash-Thinking lidera amb un 14,45% de precisió de sessió, Claude-4-Sonnet amb un 12,50%, GPT-4o amb un 11,72%. Superar totes les tasques en una sessió de quatre torns és prou difícil perquè fins i tot una precisió de tasca del 60% es tradueixi en menys del 15% de precisió de sessió — un impost de probabilitat composta en cada interacció.
• L'orquestració compositiva és el precipici més pronunciat: Les topologies d'eines mixtes seqüencials i paral·leles limiten els millors models al 25% de precisió de tasca, enfront del 54–62% per a cadenes purament paral·leles o seqüencials. Quan una tasca requereix un desplegament paral·lel seguit d'una fusió seqüencial, el problema de coordinació supera el que qualsevol model actual gestiona de manera fiable.
• La intenció oculta és una bretxa més gran del que ningú havia mesurat abans: WildToolBench garanteix que el 100% de les tasques impliquen informació implícita o entre torns; el BFCL v3 només en gestiona el 15,7%. Les tasques de dependència de llarg abast —on la informació que falta es troba a més de dos torns enrere— són el subtipus més difícil, sense que cap model superi el 50% ni tan sols a nivell de tasca.
• Les transicions d'instruccions acumulen errors a un ritme lineal: Cada canvi de política addicional (tasca d'eina → xat → aclariment → tasca d'eina) redueix la precisió en aproximadament 5-15 punts percentuals. Amb tres transicions, els models més afectats perden 30 punts. Els autors anomenen això "autocondicionament": les respostes prèvies esbiaixen la interpretació del model de les instruccions posteriors de maneres difícils de corregir a meitat de la sessió.
• La Taxa de Camí Òptim es manté per sota del 43%: Fins i tot quan els models completen les tasques correctament, consumeixen crides d'API en excés. Claude-4-Sonnet aconsegueix la millor Taxa de Camí Òptim amb un 42,74%, el que significa que la majoria de les finalitzacions correctes requereixen més passos dels necessaris — un cost directe en latència i tokens per a qualsevol sistema de producció.
• Els models especialitzats en l'ús d'eines tenen un rendiment inferior als models fronterers generals: xLAM-2-70B i ToolACE2-8B presenten taxes d'error de nom de funció incorrecte superiors al 30%, pitjor que GPT-4o o Claude-4-Sonnet. L'ajustament fi en corpus d'ús d'eines reduïts sembla crear fragilitat en lloc de robustesa davant el canvi de distribució cap al comportament real dels usuaris.

Què s'aguanta i què no​

El disseny del banc de proves és sòlid on més importa. La distinció entre precisió de tasca i precisió de sessió és exactament correcta: l'acumulació de modes de fallada és el que mata els desplegaments reals, i la majoria dels treballs anteriors informen de xifres a nivell de tasca que emmascaren això. La taxonomia de tres reptes (orquestració compositiva, intenció oculta, transicions d'instruccions) està ben motivada i fonamentada empíricament — les corbes de degradació del rendiment en els diferents tipus de reptes són reals i sorprenents.

El punt feble és l'escala. 1.024 tasques de 256 escenaris és un artefacte de recerca creïble, però escàs per a una taula de classificació destinada a fer el seguiment de 57 models al llarg del temps. Els autors ho reconeixen directament i esmenten un pipeline d'escalat automatitzat en treballs futurs. L'altre problema és que "basat en registres d'usuaris reals" comporta molta feina: les tasques finals són parcialment sintètiques, construïdes per un sistema multi-agent a partir de patrons llavor i després verificades per anotadors humans. L'afirmació està fonamentada, però les dades no són textualment salvatges: estan inspirades en el món real. Això és important per a la literalitat amb què s'interpreta el sostre del 15%; una fracció de la bretxa podria tancar-se si el pipeline de generació introdueix una dificultat artificial que els usuaris reals no mostren realment.

També sóc escèptic respecte a l'anàlisi de la transició d'instruccions com una afirmació arquitectònica. L'article ho atribueix a una limitació fonamental, però el desajust de la distribució d'entrenament entre els objectius d'ajustament fi per RLHF i les sessions d'usuari multimodals és l'explicació més senzilla. Això és abordable, no estructural.

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

Els tres modes de fallada s'ajusten gairebé perfectament a com els usuaris reals interactuen amb un agent d'escriptura de Beancount. Un usuari pregunta "quant vaig gastar en queviures el mes passat, i ja que hi ets, afegeix el tiquet d'avui de Whole Foods" — aquesta és una tasca compositiva agrupada en un sol torn. Després continua amb "en realitat posa 47,23 € i no 42 €, ho he buscat" — aquesta és una correcció de paràmetres que requereix que l'agent faci un seguiment de l'estat de la sessió. Després pregunten "és correcta aquesta categoria?" — aquesta és una sol·licitud d'aclariment, i l'agent ha de no tornar a executar l'operació d'escriptura que acaba de finalitzar. El límit del 25% en l'orquestració mixta seqüencial i paral·lela i la caiguda de 30 punts per les transicions d'instruccions són exactament els modes de fallada que es manifestarien en un agent de llibre major que gestionés sessions d'usuaris reals.

La troballa que els models especialitzats en l'ús d'eines tenen un rendiment inferior als models fronterers generals és particularment rellevant. Si estiguéssim considerant l'ajustament fi d'un model obert més petit en exemples de crides d'eines específics de Beancount —la jugada òbvia per reduir costos—, WildToolBench és un advertiment directe que l'especialització pot sacrificar la robustesa davant la distribució del comportament real dels usuaris. La troballa de la Taxa de Camí Òptim també importa: un agent que utilitza el doble de crides d'API per completar una tasca no és només ineficient; per a les operacions d'escriptura, les crides intermèdies redundants poden deixar el llibre major en estats intermedis inconsistents.

Què llegir a continuació​

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024) — el marc d'entrenament fonamental contra el qual WildToolBench es posiciona explícitament; entendre el seu disseny d'avaluació sintètica aclareix exactament què aporta l'execució en viu.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045) — el treball anterior més proper sobre l'ús d'eines multi-torn realista; comparar els dominis de comerç al detall/línies aèries de τ-bench amb la cobertura d'API públiques de WildToolBench mostra fins a quin punt es generalitza el repte.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral) — si el problema de la transició d'instruccions es pot abordar mitjançant el descobriment automàtic de millors fluxos de treball d'agents en lloc d'escalar les dades d'entrenament, AFlow és el mecanisme més creïble per fer-ho.

L'article​

Geng, Cai, Wang, Koeppl, Nakov i Gurevych analitzen la literatura emergent sobre l'estimació de la confiança i el calibratge dels LLM en tasques que van des de preguntes de resposta múltiple fins a la generació oberta i la traducció automàtica. El problema central: els LLM poden ser alhora altament precisos i completament poc fiables de maneres difícils de distingir des de l'exterior. L'enquesta organitza l'espai de solucions en dues branques principals: mètodes de caixa blanca que aprofiten l'accés als estats interns del model, i mètodes de caixa negra que tracten el model com a opac; i dins de cada branca, distingeix entre l'estimació de la confiança i el seu calibratge post hoc.

L'article es va publicar a NAACL 2024 (pàgines 6577–6595), revisat el març de 2024 a partir d'una presentació de novembre de 2023 per un equip format per membres de la TU Darmstadt, MBZUAI i la Universitat d'IA Mohamed bin Zayed.

Idees clau​

• Confiança de caixa blanca mitjançant logits: L'enfocament més senzill utilitza les probabilitats a nivell de token o la log-versemblança normalitzada per longitud com a senyal de confiança. Aquests mètodes funcionen però s'enfronten a una ambigüitat fonamental: una probabilitat de token baixa pot reflectir una confiança fàctica baixa o simplement una redacció inusual; el model pot estar insegur sobre l'elecció de les paraules mentre està segur del fet subjacent.

• Confiança de caixa negra basada en la consistència (SelfCheckGPT): Manakul et al. (EMNLP 2023) mostregen múltiples finalitzacions i puntuen la seva consistència mútua mitjançant BERTScore, NLI o superposició de n-grames. No cal accés als logits. La idea clau: per als fets que l'LLM coneix bé, les mostres repetides convergeixen; per als fets al·lucinats, divergeixen.

• Entropia semàntica: Farquhar et al. (Nature, 2024) agrupen respostes semànticament equivalents abans de calcular l'entropia. Un LLM podria redactar "París" i "la capital francesa" de manera diferent; l'entropia de tokens bruta tracta aquestes respostes com a divergents, però l'entropia semàntica no. Aquest és un pas endavant qualitatiu sobre la consistència a nivell de token que l'enquesta contextualitza.

• La confiança verbalitzada no funciona: Quan se'ls demana que emetin un percentatge de confiança, els models col·lapsen en l'excés de confiança. El treball empíric (Groot et al., TrustNLP a ACL 2024) troba que el GPT-3, el GPT-3.5 i el Vicuna mostren un Error de Calibratge Esperat (ECE) mitjà superior a 0,377 per a la confiança verbalitzada, amb prediccions que s'agrupen en el rang del 90–100% independentment de la precisió real. Fins i tot el GPT-4 —el model millor calibrat avaluat— assoleix un AUROC de només ~62,7% quan utilitza la confiança verbalitzada per discriminar les respostes correctes de les incorrectes, tot just per sobre de l'atzar.

• Les tècniques de calibratge varien segons la tasca: Per a la classificació, el calibratge contextual (restant el biaix previ de classe estimat amb un prompt "[N/A]" buit) i la desbiatització de la posició (PriDE) aborden biaixos sistemàtics coneguts. Per a la generació, el Calibratge de Versemblança de Seqüència (SLiC) ajusta els models en finalitzacions classificades. L'escalat de temperatura —la correcció post-hoc més senzilla— continua sent competitiu en molts entorns.

• No existeix cap benchmark unificat: L'observació estructural més demolidora de l'enquesta: no hi ha cap benchmark únic que abasti els mètodes d'estimació de la confiança en totes les tasques i dominis. Això fa que sigui gairebé impossible comparar els mètodes de manera rigorosa. El camp està comparant pomes amb peres.

Què se sosté — i què no​

La taxonomia és sòlida. La distinció entre caixa blanca i caixa negra és realment útil per al disseny de sistemes, i el tractament dels mètodes basats en logits és honest sobre els seus límits; els autors assenyalen directament que la probabilitat del token barreja la confiança fàctica amb la incertesa lèxica. Els professionals solen subestimar aquesta confusió.

On l'enquesta em frustra: és principalment descriptiva. Gairebé no hi ha benchmarks experimentals que comparin mètodes cara a cara, i els autors ho reconeixen explícitament com una limitació. Puc marxar amb un mapa clar de l'espai de disseny però sense cap orientació sobre quin mètode utilitzar per a una tasca nova.

Els resultats de la confiança verbalitzada —l'AUROC del ~62,7% del GPT-4 sobre la seva pròpia confiança declarada— haurien de ser coneixements canònics per a qualsevol persona que desplegui LLM en producció. No ho són. La gent encara envia prompts que pregunten "en una escala de l'1 al 10, quina confiança tens?" i tracten la resposta com a significativa. No ho és.

L'enquesta també és escassa en la qüestió del calibratge per RLHF: l'entrenament posterior amb retroalimentació humana fa que els models estiguin millor o pitjor calibrats? Hi ha proves en ambdós sentits, i l'enquesta ho esquiva en gran mesura.

Per què això importa per a la IA en finances​

ReDAct basa la seva seguretat en tenir un senyal d'incertesa calibrat del model barat. L'enquesta deixa clar com de difícil és realment això. Els senyals basats en logits estan disponibles en entorns de caixa blanca però barregen la incertesa lèxica i la fàctica. Els mètodes basats en la consistència funcionen en entorns de caixa negra però requereixen múltiples mostres per decisió, la qual cosa és costosa per a un agent d'escriptura de Beancount d'alt rendiment que processa un lot d'assentaments de transaccions.

La troballa més executable per a Bean Labs: l'entropia semàntica agrupa respostes semànticament equivalents abans de puntuar la consistència, que és precisament el que importa per als assentaments del llibre diari on un model podria expressar la mateixa relació de dèbit/crèdit en múltiples formes sintàcticament diferents. Un agent de Beancount hauria d'utilitzar l'agrupament semàntic sobre les finalitzacions d'assentaments mostrejades —i no la variància bruta a nivell de tokens— per detectar quan està al·lucinant un nom de compte o un import.

El fracàs del calibratge de la confiança verbalitzada és un avís directe per a qualsevol interfície d'usuari que mostri "quina confiança té l'IA?" a l'usuari: no us fieu del número que produeix el model. Utilitzeu un calibrador extern o un mètode basat en la consistència, o no el mostreu en absolut.

Què llegir a continuació​

• Farquhar et al., "Detecting hallucinations in large language models using semantic entropy," Nature, 2024 — el mètode més rigorós que surt d'aquest marc d'enquesta; val la pena llegir-lo sencer en lloc de fer-ho a través del resum de l'enquesta.
• Manakul et al., "SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models," EMNLP 2023 (arXiv:2303.08896) — el mètode canònic basat en la consistència; essencial d'entendre abans de desplegar qualsevol senyal de confiança de caixa negra.
• Groot et al., "Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models," TrustNLP a ACL 2024 (arXiv:2405.02917) — l'auditoria empírica més exhaustiva de com es trenca la confiança verbalitzada en diferents models i tasques.

L'article​

Saibo Geng, Hudson Cooper, Michał Moskal i col·legues de Microsoft Research presenten JSONSchemaBench, una referència de 9.558 esquemes extrets de fonts de producció reals: signatures de crides a funcions de GlaiveAI, repositoris de GitHub estratificats per complexitat des de trivial fins a ultra, configuracions d'API de Kubernetes, esquemes d'anàlisi d'esdeveniments de Snowplow i la col·lecció JSONSchemaStore. Avaluen sis entorns de descodificació restringida —Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs i Gemini— en tres eixos: cobertura (quina fracció d'esquemes pot gestionar l'entorn), eficiència (sobrecost de tokens per segon en comparació amb la generació no restringida) i qualitat (precisió en tasques posteriors). La matriu d'avaluació també inclou la JSON Schema Test Suite oficial, que documenta 45 categories de funcions que qualsevol motor conforme hauria de suportar.

L'afirmació central és que la complexitat de l'esquema és la variable decisiva que separa els entorns capaços dels fràgils, i que cap entorn domina en els tres eixos.

Idees clau​

• La cobertura s'enfonsa sota la complexitat de l'esquema. En esquemes simples de GlaiveAI, tots els entorns puntuen per sobre del 86%. Però en els esquemes GitHub-Hard —amb anidament de diversos nivells, definicions recursives i restriccions de patrons complexes— Guidance cau al 41%, Llamacpp al 39%, XGrammar al 28% i Outlines a un catastròfic 3%. OpenAI arriba només al 9% a GitHub-Hard, i Gemini no produeix cap sortida vàlida en esquemes de complexitat mitjana o superior.
• Kubernetes exposa una debilitat específica a XGrammar. Malgrat les promeses de velocitat de XGrammar, només aconsegueix una cobertura del 7% en esquemes de Kubernetes, probablement perquè aquests esquemes depenen de patrons dependents del context que la precomputació independent del context de XGrammar no pot gestionar. La cobertura en una referència que inclou configuracions de Kubernetes no és opcional per als agents de producció.
• Una restricció insuficient és més perillosa que un error de compilació. XGrammar presenta 38 fallades per restricció insuficient en la JSON Schema Test Suite, el que significa que emet JSON que viola l'esquema declarat mentre informa silenciosament d'èxit. Guidance només té una fallada d'aquest tipus. Per a un agent d'escriptura, un error de compilació es detecta en el moment del disseny; una fallada per restricció insuficient corromp les dades en temps d'execució sense cap senyal.
• L'avanç ràpid de Guidance ofereix una acceleració real del 50%. Quan hi ha seqüències deterministes llargues (per exemple, noms de camps en una estructura d'objecte fixa), Guidance pot avançar diversos tokens per cada pas de descodificació. En un Llama-3.1-8B sobre una A100, Guidance funciona a 6–9 ms per token de sortida, mentre que la generació no restringida funciona a 15–16 ms. Outlines és més lent que la generació no restringida, a 30–46 ms, principalment a causa de la compilació prèvia de l'autòmat que triga entre 3 i 8 segons per esquema.
• La descodificació restringida millora modestament la precisió del raonament. A GSM8K (matemàtiques), Guidance eleva la precisió del 80,1% (no restringida) al 83,8%. A Last Letter i Shuffle Objects, els guanys se situen entre 1 i 3 punts. Això contradiu la preocupació sovint citada que forçar el format JSON degrada la qualitat de la resposta, però la magnitud de l'efecte és prou petita com perquè l'elecció del format no hagi de determinar la selecció de l'entorn.
• Cap entorn cobreix les 45 categories de funcions de JSON Schema. Guidance en cobreix 13, Llamacpp i XGrammar en cobreixen 1 cadascun, i Outlines en cobreix 0. La implicació pràctica és que qualsevol esquema que utilitzi if/then/else, unevaluatedProperties o definicions recursives $ref es comportarà de manera impredictible depenent del motor que hi hagi sota el capó.

Què se sosté — i què no​

La contribució més forta de la referència és l'obtenció dels esquemes. Les avaluacions anteriors utilitzaven esquemes de joguina o col·leccions d'una sola font. Incloure configuracions de Kubernetes juntament amb signatures de crides a funcions és el tipus correcte de diversitat adversària. L'estratificació de la complexitat (de trivial a ultra) també ofereix als professionals una corba de calibratge: si els teus esquemes s'assemblen a les crides de funcions de GlaiveAI, tant XGrammar com Guidance estan bé; si s'assemblen a manifests de Kubernetes, les teves opcions es redueixen ràpidament.

La debilitat principal és l'avaluació cobdiciosa (greedy) d'una sola mostra. Mesurar la cobertura amb una sola generació per esquema infravalora la capacitat real: un entorn podria fallar el 20% de les vegades però tenir èxit en un reintent. L'article ho reconeix però no informa de les xifres de pass@k amb mostreig per temperatura, que serien importants per als sistemes de producció que reintenten en cas de fallada.

La comparació també barreja models incomparables. Els entorns de codi obert (Guidance, Outlines, Llamacpp, XGrammar) es proven amb Llama-3.2-1B, mentre que OpenAI i Gemini utilitzen els seus propis models no revelats. La cobertura del 9% d'OpenAI a GitHub-Hard podria reflectir tant la capacitat del model com l'arquitectura de descodificació restringida. Una comparació justa requeriria un accés controlat al model, cosa que els autors, òbviament, no poden imposar als proveïdors propietaris.

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

Cada agent d'escriptura de Beancount genera una sortida estructurada. Si l'agent emet directives de Beancount com a JSON abans de convertir-les a la sintaxi de .beancount, o si crida eines mitjançant esquemes JSON, la fiabilitat d'aquesta generació JSON no és un detall: és tot el joc. L'article FinTrace va demostrar que els models de frontera fallen en el raonament sobre les sortides de les eines; JSONSchemaBench revela un problema ortogonal: fins i tot abans del raonament, la capa de format pot emetre silenciosament una sortida no conforme.

El resultat de Kubernetes és especialment revelador per a Beancount. Els esquemes de llibres majors no són llistes planes de clau-valor. Les jerarquies de comptes, les metadades de les transaccions i les estructures d'etiquetes creen patrons recursius niats similars als objectes de l'API de Kubernetes. Un entorn que puntua un 7% a Kubernetes no està preparat per a esquemes de llibres majors complexos, independentment de la velocitat del seu sobrecost per token.

El mode de fallada per restricció insuficient és el que realment em preocuparia. Un agent de Beancount que utilitzi XGrammar podria emetre una transacció que superi la verificació de validació interna de l'entorn però que violi l'esquema real, i l'agent no tindria cap motiu per reintentar-ho. La corrupció silenciosa és pitjor que una fallada visible.

Què llegir a continuació​

• XGrammar (arXiv:2411.15100, Dong et al.): l'article tècnic darrere d'un dels entorns més ràpids provats, que explica la divisió de tokens independent/dependent del context i per què els esquemes de Kubernetes el posen a prova.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024): mostra que emmascarar tokens en la descodificació restringida pot distorsionar la distribució de probabilitat del model i proposa un algorisme de mostreig corregit; el fonament teòric per a les preocupacions de qualitat que la referència mesura només indirectament.
• XGrammar-2 (arXiv:2601.04426): una continuació que amplia XGrammar a esquemes dinàmics en entorns d'agents on l'esquema mateix canvia durant una sessió de diversos torns, directament rellevant per als agents de Beancount que adapten el seu format de sortida segons quins tipus de comptes estiguin actius.

L'article​

Jie Zhu, Yimin Tian i els seus col·legues de l'equip Alibaba Cloud Qwen DianJin, YINGMI Wealth Management i la Universitat de Soochow presenten FinMCP-Bench, una suite d'avaluació de 613 mostres que cobreix 10 categories d'escenaris financers i 33 subescenaris. Les eines no són simulades: 65 servidors d'eines financeres reals compatibles amb MCP donen suport al benchmark, extrets dels registres de producció reals de l'assistent financer Qieman APP. Els autors categoritzen les mostres en tres tipus: 145 d'eina única, 249 multi-eina i 219 de múltiples torns. Proven sis models: la família Qwen3 en recomptes de paràmetres de 4B, 30B i 235B (tots amb pensament estès), a més de DeepSeek-R1, GPT-OSS-20B i Seed-OSS-36B. Les mètriques principals d'avaluació són la Precisió de l'eina, l'Exhaustivitat de l'eina (Recall), l'F1 de l'eina i una Taxa de Coincidència Exacta (EMR) que requereix que cada crida d'eina en una seqüència sigui exactament correcta.

Idees clau​

• L'MCP com a substrat d'avaluació: l'ús de definicions reals de servidors MCP en lloc d'esquemes d'API sintètics tanca una bretxa important entre l'avaluació del benchmark i el que els agents realment afronten en sistemes financers desplegats.
• Divisió de dificultat en tres vies: les mostres d'eina única, multi-eina i de múltiples torns no són només diferències de quantitat; exposen modes de fallada qualitativament diferents.
• Col·lapse en els múltiples torns: el millor model (Qwen3-235B) aconsegueix un 60% d'EMR en eina única, un 10,62% d'EMR en multi-eina i un 3,08% d'EMR en múltiples torns. La caiguda d'un sol torn a múltiples torns és de 20 vegades.
• L'F1 de l'eina és més permissiu: el mateix model puntua un 66,85%, 69,42% i 41,56% de TF1 en els tres escenaris, cosa que demostra que els models sovint trien les eines adequades però fallen en l'ordre, la parametrització o el seguiment de la conversa.
• L'exhaustivitat supera la precisió en l'eina única: els models tendeixen a cridar eines en excés quan no estan segurs en lloc de cridar-ne de menys, que és el mode de fallada més segur per a tasques financeres, però que encara implica crides d'API malbaratades i soroll en la traça de raonament.
• Escalat de mida no monotònic: Qwen3-30B no supera consistentment Qwen3-4B en tots els subescenaris, trencant l'assumpció que el model més gran sempre guanya per a l'ús d'eines en múltiples passos.

Què es manté i què no​

L'ús de registres de producció reals com a font per als exemples d'eina única és l'elecció metodològica més sòlida aquí. Fonamenta el benchmark en el comportament real de l'usuari en lloc d'escenaris inventats pels investigadors, cosa que és rara en la literatura d'IA per a finances. Les mostres multi-eina i de múltiples torns s'extenen sintèticament utilitzant grafs de dependències i prompts de joc de rol, la qual cosa és raonable donat el cost de l'etiquetatge, però introdueix un risc: el procés de síntesi tendeix a produir consultes més netes i telegrafiades que les que escriuen els usuaris reals. El 3,08% d'EMR en múltiples torns és alarmant, però s'ha d'interpretar amb cura: l'EMR requereix que la seqüència completa sigui exactament correcta, per la qual cosa una sola crida d'eina intermèdia incorrecta fa fallar tota la tasca. Aquest és un estàndard de producció estricte i potser poc realista; les mètriques de crèdit parcial com TF1 expliquen una història més matisada.

El que l'article no aborda: no hi ha cap anàlisi de si la bretxa de rendiment és principalment un problema de comprensió de l'entrada (el model interpreta malament el que l'usuari vol), un problema de format de sortida (intenció correcta però crida d'eina mal formada) o un problema de raonament (conclusions intermèdies errònies). Sense aquesta descomposició, és difícil saber on invertir l'esforç d'enginyeria. L'article també avalua els models de forma aïllada; no hi ha cap prova de si l'addició d'un pas de verificació o reflexió canvia el panorama dels múltiples torns.

El benchmark també està profundament lligat a les 65 eines específiques de Qieman, cosa que limita com es transfereixen els resultats a altres plataformes financeres amb inventaris d'eines diferents.

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

FinMCP-Bench és l'avaluació publicada més propera al que faria realment un agent d'escriptura (write-back) de Beancount: rebre una sol·licitud de l'usuari, identificar quina eina (o cadena d'eines) s'aplica, invocar-les en ordre i gestionar els torns de seguiment. L'EMR de múltiples torns del 3,08% és un bany de realitat. Un agent de Beancount que gestiona una correcció del llibre major en diversos passos —per exemple, reclassificar un conjunt de transaccions entre comptes en un interval de dates, després conciliar i després generar un informe— és exactament el tipus de tasca de múltiples torns i multi-eina en què els models actuals fallen gairebé universalment segons els estàndards de coincidència exacta.

L'enfocament MCP és directament rellevant: l'API de Python de Beancount, la interfície beanquery i la capa REST de Fava podrien estar totes embolicades com a servidors MCP. FinMCP-Bench ens diu que el protocol no és el coll d'ampolla, sinó que ho és el raonament sobre les seqüències de crides d'eines.

La troballa que l'exhaustivitat de l'eina supera la precisió (els models fan crides en excés) també és important per a la seguretat de l'escriptura: un agent que crida l'eina de mutació del llibre major quan només calia una lectura podria corrompre el llibre major silenciosament. Les mètriques d'avaluació esbiaixades cap a la precisió, no cap a l'exhaustivitat, haurien de ser el senyal de seguretat principal per als agents d'escriptura.

Què llegir a continuació​

• JSONSchemaBench (arXiv:2501.10868) — avalua la fiabilitat de la sortida estructurada en 10.000 esquemes JSON; aborda directament si els fallos de format de crida d'eines a FinMCP-Bench són un problema de descodificació restringida.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — el marc de formació fonamental per a l'ús d'eines respecte al qual es posiciona FinMCP-Bench; entendre la seva exploració d'arbres de cerca primer en profunditat clarifica què aporta la metodologia de registres de producció de FinMCP-Bench.
• WildToolBench (arXiv:2604.06185) — avalua l'ús d'eines en consultes d'usuaris reals en llibertat; la seva troballa que cap model supera el 15% de precisió en el comportament de l'usuari real complementa l'enfocament de registres de producció de FinMCP-Bench.

L'article​

Cao et al. presenten FinTrace, un benchmark de 800 trajectòries anotades per experts que abasten 34 categories de tasques financeres del món real a través de nivells de dificultat fàcil, mitjà i difícil. Els autors construeixen la seva avaluació al voltant d'una rúbrica de nou mètriques organitzades en quatre eixos: correcció de l'acció (F1 de crida d'eines, rellevància de la tasca), eficiència d'execució (eficiència de passos, puntuació de redundància), qualitat del procés (progressió lògica, utilització de la informació, puntuació de progrés) i qualitat del resultat (taxa d'èxit de la tasca, qualitat de la resposta final). Avaluen 13 LLM i també publiquen FinTrace-Training, un conjunt de dades de 8.196 trajectòries de preferència seleccionades per a l'ajustament fi (fine-tuning).

L'afirmació central és que els models de frontera han dominat la selecció d'eines, però fallen sistemàticament en el pas més difícil: utilitzar el que les eines retornen. El benchmark ho posa a prova amb una escala de 5 punts per a la utilització de la informació, la progressió lògica i la puntuació de progrés, a més de mètriques algorítmiques per a l'F1 d'eines i l'eficiència de passos.

Idees clau​

• El model amb millor rendiment, Claude-Opus-4.6, aconsegueix un F1 de crida d'eines de 0,896 —una selecció forta—, però només obté un 3,23/5 en Utilització de la Informació, la més feble de les quatre mètriques orientades al resultat.
• La taxa d'èxit de la tasca de Claude-Opus-4.6 és de 2,65/5, i la Qualitat de la Resposta Final és de 3,34/5; fins i tot el millor model no produeix respostes correctes i completes de manera consistent.
• Qwen-3.5-9B mostra un patró degenerat: una eficiència de passos (1,000) i una redundància (1,000) gairebé perfectes perquè amb prou feines crida cap eina, reflectit en un F1 de crida d'eines de 0,109. Eficient però inútil.
• L'entrenament amb FinTrace-Training millora les mètriques del procés intermedi (la Progressió Lògica puja de 2,29 a 2,56 amb DPO; la Puntuació de Progrés de 2,00 a 2,30), però la Qualitat de la Resposta Final es manté estancada —cap variant supera significativament l'1,21 de mitjana en l'escala d'1 a 5 per als models petits.
• El DPO supera l'SFT a l'hora de suprimir modes de fallada catastròfics: la proporció de puntuacions d'1 en Progressió Lògica cau de l'11,9% (SFT) al 9,5% (DPO).
• La subcategoria universalment pitjor en els 13 models és el QA de Raonament, on Claude-Opus-4.6 aconsegueix només un 0,62 global —un sostre difícil compartit fins i tot pel model de frontera més fort.

Què se sosté — i què no​

La troballa principal —que la selecció d'eines i el raonament sobre les eines són dissociables— està ben motivada i la rúbrica de quatre eixos és una contribució genuïna. Els benchmarks anteriors com FinToolBench s'aturen en les traces d'execució; FinTrace afegeix mètriques de qualitat del procés jutjades per LLM que exposen el que passa entremig. El κ de Cohen inter-avaluador de 0,89 en la validació de 100 mostres és encoratjador per a un benchmark construït en part sobre jutges LLM.

Dit això, diverses eleccions metodològiques limiten el que puc extreure de les xifres literalment. Les 34 categories de tasques no s'enumeren al cos principal de l'article —es remeten a l'Apèndix B—, així que no puc dir com són de representatives de la pràctica financera del món real. Els nivells de dificultat es defineixen per rangs percentils dins del propi conjunt de consultes del benchmark, la qual cosa és una mesura circular: "difícil" només significa inusual en relació amb les altres 800 trajectòries, no difícil en cap sentit absolut.

L'anàlisi de l'ajustament fi és frustrant. Entrenar un model de 9B amb FinTrace-Training millora el raonament intermedi, però la qualitat de la resposta final continua sent deficient. L'article ho atribueix a una "desconnexió" entre el procés i el resultat, però no explica per què. L'explicació més plausible —que un model de 9B no té la memòria factual i la capacitat aritmètica necessàries per a les tasques financeres independentment de la qualitat de la trajectòria— no s'aborda. Mostrar els resultats del DPO només per a Qwen-3.5-9B també fa que sigui impossible saber si els models més grans se'n beneficien més.

També sóc escèptic respecte a l'agregació de la puntuació global. Combinar mètriques algorítmiques (F1 ∈ [0,1]) amb puntuacions jutjades per LLM en escales Likert d'1 a 5 mitjançant la normalització a [0,1] i la mitjana barreja tipus de fallades molt diferents. Un model que crida les eines equivocades per complet no és el mateix tipus d'error que un model que crida les eines correctes i després ignora el resultat.

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

La troballa central es trasllada directament al problema d'escriptura (write-back) de Beancount. Un agent que crida de manera fiable les eines adequades de la CLI de Beancount però que després malinterpreta el resultat —per exemple, analitzant una resposta de balanç de situació i publicant al compte equivocat— és pitjor que cap automatització: produeix entrades de llibre major errònies amb seguretat que semblen correctes per a un revisor casual.

La mètrica d'Utilització de la Informació és la que vigilaria amb més cura per a qualsevol agent de Beancount. El fet que el millor model disponible tregui un 3,23/5 en això en un benchmark financer controlat hauria de ser una restricció obligatòria en qualsevol desplegament en producció. Això a favor de la revisió humana obligatòria de qualsevol operació d'escriptura, almenys fins que vegem aquesta puntuació consistentment per sobre del 4,0.

FinTrace també confirma el que ReDAct suggeria la setmana passada: l'arquitectura adequada no és el raonament LLM d'extrem a extrem, sinó un pipeline que externalitza la verificació. Un agent que selecciona bé les eines (Tool F1 ~0,9) i després passa els resultats a un pas de validació independent abans d'actuar és més defensable que un que intenta raonar sobre el resultat brut de l'eina en una sola passada.

Què llegir a continuació​

• FinMCP-Bench (arXiv:2603.24943): l'article complementari que utilitza MCP com a estàndard d'interfície d'eines, el següent a la llista de lectura; directament comparable a FinTrace però construït sobre una capa de protocol diferent.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): aparegut simultàniament, avalua la crida d'eines fora de les finances; aclariria si la bretxa d'utilització de la informació és específica del domini o general.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): s'adreça als mateixos modes de fallada de crida d'eines des d'una perspectiva de dades d'entrenament i podria explicar què li falta al DPO de FinTrace-Training.

L'article​

Jiaxuan Lu i els seus col·legues presenten FinToolBench (arXiv:2603.08262, març de 2026) com el que afirmen que és la primera comparativa executable en el món real per avaluar agents d'aprenentatge d'eines financeres. El plantejament és directe: les avaluacions actuals d'IA financera se centren en preguntes i respostes estàtiques sobre documents, mentre que les comparatives generals d'ús d'eines com ToolLLM tracten les finances com una altra categoria d'API sense restriccions de compliment específiques del domini. FinToolBench intenta omplir l'espai entre aquests dos modes de fallada.

La comparativa combina 760 eines financeres executables (261 punts finals en viu de RapidAPI i 499 interfícies d'AkShare) amb 295 consultes d'avaluació curades rigorosament, dividides en 166 casos d'una sola eina i 129 casos multieina. Les eines abasten els dominis d'accions, bons, fons, divises, derivats, macro i cripto. Crucialment, aquestes són API reals que es poden cridar, no simulacions (stubs). Els autors també presenten FATR (Finance-Aware Tool Routing), un agent de referència que utilitza la recuperació BGE-M3 (els 20 millors candidats), targetes d'eines anotades amb atributs financers i un planificador ReAct conscient de les restriccions limitat a cinc passos.

Idees clau​

• L'execució no és el coll d'ampolla; el raonament sobre els resultats ho és. GPT-4o té la puntuació més alta de Conditional Soft Score (CSS = 0,670), la qual cosa significa que dóna respostes correctes quan crida amb èxit una eina, però només invoca eines el 22,7% del temps (TIR = 0,227). Qwen3-8B crida eines el 87,1% del temps, però obté la resposta correcta només el 40,4% del temps quan té èxit.
• El desajust d'intencions és la fallada de compliment dominant. L'IMR (Intent Mismatch Rate) supera el 50% en la majoria dels models, cosa que significa que els agents emeten habitualment crides d'intenció transaccional quan la consulta només demana una cerca informativa. Això és un problema greu en contextos financers regulats.
• La injecció d'atributs financers ajuda al compliment sense perjudicar la capacitat. Les targetes d'eines del referent FATR —anotant cada eina amb la puntualitat, el tipus d'intenció i el domini regulador— redueixen les crides de dades obsoletes (TMR) i les violacions de domini (DMR) sense degradar significativament la taxa d'invocació.
• Les consultes multieina exposen la bretxa de fiabilitat. Les 129 consultes multieina requereixen encadenar crides i passar resultats entre passos; el rendiment cau substancialment en comparació amb els casos d'una sola eina, en línia amb les troballes de FinTrace i TheAgentCompany.
• Els models petits poden superar en invocacions els grans, però no en raonament. El TIR de 0,871 de Qwen3-8B enfront del 0,227 de GPT-4o mostra que els models més petits són més "de gallet fàcil", però el CER (taxa d'execució condicional, és a dir, TESR/TIR) de 0,339 per a Qwen3-8B enfront de 0,618 per a GPT-4o revela que GPT-4o és molt més precís quan decideix cridar una eina.

Què s'aguanta i què no​

La decisió de la comparativa d'utilitzar API realment en viu i executables és la seva contribució principal, i és una de real. Les API simulades han estat el secret brut de les comparatives d'ús d'eines: les 16.000 API de ToolLLM semblen impressionants fins que t'adones que l'avaluació utilitza un LLM com a jutge de si una crida "hauria funcionat". FinToolBench ho evita.

Les mètriques de compliment (TMR, IMR, DMR) són conceptualment correctes —els agents de finances han de conèixer la diferència entre obtenir el preu de tancament d'ahir i iniciar una operació—, però la descripció de l'article sobre com s'apliquen aquestes classificacions és escassa. No està clar si les etiquetes de referència per al tipus d'intenció (informativa vs. transaccional) van ser verificades per experts legals o de compliment, o simplement assignades pels autors del conjunt de dades. Això importa molt a la pràctica.

La llista de models també és estranyament estreta: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash i GPT-4o. Ni Claude Sonnet ni Gemini 2.5, que haurien estat comparacions naturals. La taula de resultats mostra que GPT-4o és un cas atípic de precisió però baixa cobertura; m'agradaria saber si el comportament d'ús d'eines de Claude s'acosta més al patró conservador de GPT-4o o a l'agressiu de Qwen3-8B.

El conjunt d'avaluació de 295 consultes és petit per als estàndards de les comparatives modernes. Amb 760 eines, una taxa de cobertura de 295 consultes significa que la majoria de les eines no es proven mai. L'article no informa d'estadístiques de cobertura per domini, cosa que significa que les xifres principals podrien estar impulsades per un subconjunt de dominis ben coberts com les accions i la macroeconomia.

Per què això és important per a la IA en finances​

Els agents d'escriptura (write-back) de Beancount —qualsevol agent que cridi bean-add, apliqui un pegat a un fitxer de llibre major o consulti beanquery— s'enfronten exactament als mateixos modes de fallada que revela FinToolBench. El problema del desajust d'intencions es tradueix directament: un agent de Beancount que emet una crida d'escriptura quan l'usuari ha fet una pregunta de lectura té la mateixa signatura de fallada que una violació de l'IMR. La dimensió de la puntualitat s'assigna al problema de cridar un estat del llibre major emmagatzemat a la memòria cau quan l'usuari espera el saldo actual.

La tensió entre precisió i cobertura (GPT-4o vs Qwen3-8B) també és directament rellevant. Per a l'escriptura de Beancount, m'estimaria més tenir el comportament de crida conservador de GPT-4o —baixa TIR però alt CER i CSS— que un model d'alta invocació que sovint executa l'eina incorrecta. Les escriptures falses són molt més costoses que les operacions nul·les (no-ops).

L'enfocament FATR d'anotar eines amb atributs de compliment en lloc de confiar en el model per inferir-los és un patró de disseny que val la pena adoptar. Envoltar les eines de la CLI de Beancount amb metadades explícites sobre si una crida és de només lectura o de modificació, i si afecta l'estat actual o l'arxivat del llibre major, és la mateixa idea aplicada a un abast més petit.

Què llegir a continuació​

• FinTrace (arXiv:2604.10015) — avaluació a nivell de trajectòria en 34 categories de tasques financeres amb 9 mètriques; estén directament l'avaluació d'una sola crida de FinToolBench a seqüències de diversos passos, i ajusta Qwen-3.5-9B amb DPO per millorar el raonament intermedi.
• FinMCP-Bench (arXiv:2603.24943) — 613 mostres sobre 65 eines financeres basades en MCP provant la invocació d'una sola eina, multieina i de diversos torns; el plantejament MCP és directament rellevant per a les interfícies d'eines de Beancount.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — l'article de ToolBench contra el qual FinToolBench es posiciona explícitament; entendre què pot i què no pot mesurar el referent d'API simulades aclareix quant aporta realment l'executabilitat de FinToolBench.

L'article​

OmniEval construeix una graella d'avaluació bidimensional: cinc classes de tasques (QA extractiva, raonament multihop, QA de contrast, QA de format llarg i QA conversacional) creuades amb 16 temes financers (mercats de valors, banca d'inversió, fons, assegurances de propietat i altres). El resultat és un banc de proves estructurat amb 11,4 mil exemples de prova generats automàticament, 1,7 mil exemples anotats per humans i un corpus de recuperació de 362 mil documents reunit a partir de sis fonts de dades financeres xineses (BSCF-DB amb 193 mil documents, FinGLM amb 55 mil, BAAI-Fin amb 48 mil, rastrejos web oficials, PDF i contingut financer de la Viquipèdia). El banc de proves també inclou un avaluador LLM ajustat (fine-tuned) —Qwen2.5-7B-Instruct entrenat en 910 instàncies etiquetades per humans— que puntua la qualitat de la generació segons la precisió, l'al·lucinació, la completesa, la utilització i la precisió numèrica. L'article es va publicar a l'EMNLP 2025.

Idees clau​

• Els casos de prova generats automàticament van passar una comprovació d'acceptació humana del 87,47%, cosa que significa que aproximadament 1 de cada 8 instàncies generades va ser descartada; no és una taxa de soroll trivial per a un banc de proves.
• El millor recuperador (GTE-Qwen2-1.5B) va aconseguir un MAP de 0,4370 i un MRR de 0,4491 en el conjunt generat automàticament, la qual cosa significa que el fragment millor classificat és correcte menys de la meitat de les vegades, fins i tot amb el recuperador més potent provat.
• La precisió de la generació (ACC) en totes les combinacions de recuperador-LLM va oscil·lar entre 0,3238 i 0,4476: la millor configuració encerta menys de la meitat de les preguntes.
• La precisió numèrica (NAC) és la troballa més punyent: de 0,0659 a 0,3595. El millor sistema encerta els números financers aproximadament el 36% de les vegades; el pitjor està prop de zero.
• L'avaluador ajustat va assolir un 74,4% de concordança amb l'anotació humana (κ = 0,6486), superant substancialment les línies de base només amb indicacions (prompting) del 55–71%, però deixant tot i així una de cada quatre avaluacions desalineada amb el judici humà.
• El raonament multihop i les consultes conversacionals van ser constantment les classes de tasques més difícils.

Què se sosté — i què no​

El disseny d'avaluació matricial és realment útil. Els bancs de proves financers anteriors (FinanceBench, FinQA, DocFinQA) tracten l'avaluació com un sol eix —normalment la precisió de la resposta— i passen per alt la variació estructural de com falla el RAG. Saber que un sistema puntua bé en QA extractiva però malament en raonament multihop és accionable; saber que té una puntuació mitjana general no ho és. La graella d'OmniEval fa visible aquesta variació, i la troballa que el rendiment és inconsistent segons els temes és exactament el tipus de resultat que els professionals necessiten veure abans d'implementar.

Dit això, hi ha límits reals que vull assenyalar directament. El corpus és aclaparadorament xinès: cinc de les sis fonts de dades són dades financeres xineses (BSCF, FinGLM, BAAI-Fin), i la sisena és la Viquipèdia en xinès. L'article no informa de resultats desglossats per idioma; només informa de xifres agregades. Això fa que cada puntuació de l'article sigui sospitosa com a afirmació sobre el RAG financer en general, en contrast amb el RAG financer sobre text xinès amb recuperadors i LLM especialitzats en xinès (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Els usuaris financers en altres idiomes no poden utilitzar directament aquestes xifres.

L'avaluador LLM està entrenat en 910 instàncies etiquetades. Això és poc. La concordança humana del 74,4% amb κ = 0,6486 és defensable com a punt de partida, però significa que el marc d'avaluació en si mateix introdueix un soroll substancial. Si s'utilitza el banc de proves per comparar sistemes que difereixen en pocs punts percentuals, la variància de l'avaluador taparà el senyal.

El flux de generació automàtica —el GPT-4 produeix les preguntes de prova i els humans filtren amb una acceptació del 87,47%— també planteja una qüestió de contaminació que l'article no aborda: les preguntes generades pel GPT-4 poden afavorir els punts forts dels models de la classe GPT-4 de manera que perjudiquin sistemàticament els models més antics o més petits.

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

Les puntuacions de precisió numèrica són la xifra a la qual torno constantment: 0,0659–0,3595. Si el millor sistema RAG provat només encerta els números financers el 36% de les vegades en una avaluació de referència, qualsevol agent d'escriptura de Beancount construït sobre un flux RAG ingenu corromprà les dades del llibre comptable. El format de Beancount és implacable: un import, una data o un nom de compte incorrecte produeix o bé un error d'anàlisi o bé un error comptable silenciós que es pot propagar a través dels exercicis fiscals. Aquest banc de proves ens dóna proves concretes que la recuperació RAG i la generació LLM encara no són prou fiables per a l'escriptura directa en el llibre comptable sense una capa de validació.

L'estructura de classes de tasques també es maparia clarament als casos d'ús de Beancount. La QA extractiva correspon a consultes de saldo senzilles. El raonament multihop correspon a preguntes com "quin és el meu ingrés net després d'impostos entre el primer i el tercer trimestre?". La QA conversacional correspon a un usuari que refina iterativament una sol·licitud de conciliació al llarg d'una sessió. La troballa d'OmniEval que les tasques multihop i conversacionals són les més difícils és exactament la mala notícia per al disseny de l'agent Beancount: els casos fàcils estan gairebé bé; els casos realistes és on el sistema s'enfonsa.

Què llegir a continuació​

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — l'anàleg de domini general més proper a l'enfocament d'ajust de l'avaluador d'OmniEval; comparar la metodologia d'ARES amb la d'OmniEval aclariria si les opcions de disseny de l'avaluador LLM són basades en principis o ad hoc.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — generació automàtica d'escenaris per a l'avaluació RAG; amplia la metodologia d'auto-generació que utilitza OmniEval i pot abordar la preocupació per la contaminació.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — amplia l'avaluació RAG a documents financers multimodals (taules, gràfics); rellevant ja que els usuaris de Beancount tenen cada cop més imatges de rebuts i extractes en PDF juntament amb llibres comptables en text pla.

L'article​

L'enquesta de Xu i Ding (arXiv:2409.01980) proposa organitzar la detecció d'anomalies i de dades fora de la distribució (OOD) basada en LLM en dues classes d'alt nivell: LLM per a la detecció, on el model identifica directament les anomalies, i LLM per a la generació, on el model augmenta les dades d'entrenament o produeix explicacions en llenguatge natural que alimenten un detector posterior. Cada classe se subdivideix encara més. La detecció es divideix en mètodes basats en prompts (LLM congelats o ajustats consultats amb prompts en llenguatge natural) i mètodes basats en el contrast (models de la família CLIP que puntuen el caràcter anòmal comparant pegats d'imatge amb descripcions de text). La generació es divideix en mètodes centrats en l'augment (generació d'etiquetes pseudo-OOD o mostres sintètiques minoritàries) i mètodes centrats en l'explicació (producció de raonaments en llenguatge natural per als esdeveniments marcats).

La llista de lectura de GitHub que l'acompanya cobreix aproximadament 39 articles: 24 de detecció, 10 d'augment i 5 d'explicació.

Idees clau​

• Els mètodes basats en el contrast dominen la detecció d'anomalies en imatges. WinCLIP assoleix un 91,8% i un 85,1% d'AUROC en la classificació d'anomalies zero-shot i la segmentació a MVTec-AD sense cap ajust específic per al conjunt de dades, cosa que és competitiva amb els mètodes supervisats entrenats en aquest conjunt de dades.
• Els LLM congelats topen amb una bretxa de modalitat per a dades que no són text. L'enquesta assenyala explícitament que "l'ús directe de prompts en LLM congelats per a resultats de detecció d'anomalies o OOD en diversos tipus de dades sovint dóna un rendiment subòptim a causa de la bretxa de modalitat inherent entre el text i altres modalitats de dades".
• L'ajust amb LoRA i adaptadors recupera gran part d'aquesta bretxa. Mètodes com AnomalyGPT i AnomalyCLIP fan un ajust fi amb tècniques eficients en paràmetres i superen substancialment els seus homòlegs congelats.
• La generació com a augment està poc utilitzada. Les etiquetes pseudo-OOD a nivell de subtítol generades per BLIP-2 superen les alternatives a nivell de paraula i de descripció en la detecció OOD, la qual cosa suggereix que una supervisió de text més rica és important fins i tot per a tasques visuals.
• La generació centrada en l'explicació és la subcategoria més recent. Sistemes com Holmes-VAD i VAD-LLaMA van més enllà de les marques binàries per generar raonaments en llenguatge natural per als esdeveniments anòmals, principalment en vídeos de vigilància.
• Les dades tabulars són gairebé absents. L'enquesta cita un mètode — "Tabular" de Li et al. (2024) — que converteix files tabulars en prompts de text i fa un ajust fi amb LoRA, però no proporciona xifres comparatives.

El que es manté — i el que no​

La taxonomia de dues classes és realment neta i probablement la faré servir per organitzar el meu propi pensament. La distinció detecció-vs-generació capta una bifurcació arquitectònica real: o demanes a l'LLM que classifiqui directament o l'utilitzes per construir un millor senyal d'entrenament per a un detector tradicional.

El que no puc acceptar és l'enfocament de l'article com una enquesta sobre la detecció d'anomalies en general. La cobertura es concentra aclaparadorament en imatges de defectes industrials (MVTec-AD, VisA) i vídeos de vigilància (UCF-Crime, XD-Violence). Dels aproximadament 39 articles catalogats, gairebé cap aborda dades tabulars o financeres. Les sèries temporals reben unes quantes citacions. El format tabular rep una sola frase. Això no és un mapa del panorama per a Bean Labs — és un mapa per a investigadors de visió per computador que volen utilitzar CLIP per a la detecció de defectes.

Els autors reconeixen que "les restriccions d'espai impedeixen resums mètrics detallats", que és una manera educada de dir que no hi ha taules comparatives. Per a un article d'enquesta, l'absència de síntesi quantitativa és una llacuna significativa. Els lectors no poden utilitzar aquest article per decidir quin paradigma és millor per al seu cas d'ús sense rastrejar individualment cada article citat.

El repte de les al·lucinacions apareix com un problema obert, però el tractament és superficial — esmenta el risc sense analitzar quins paradigmes de detecció són més o menys susceptibles, o com la generació centrada en l'explicació podria fer que les al·lucinacions fossin més detectables mitjançant la revisió humana.

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

Dues subcategories són rellevants malgrat la cobertura centrada en la imatge. Primer, la subcategoria de generació centrada en l'explicació és exactament el que necessiten els agents d'auditoria de Beancount: no només una marca que indiqui que un assentament del diari és anòmal, sinó una frase en llenguatge natural que expliqui per què. Els auditors financers no poden actuar sobre un resultat binari. Segon, el silenci gairebé total de l'enquesta sobre la detecció d'anomalies tabulars és informatiu per si mateix — confirma que el fil d'AnoLLM, CausalTAD i AD-LLM que he estat seguint és una àrea de frontera i no una de ben trepitjada, i que el disseny d'eines d'auditoria basades en LLM per als llibres majors de Beancount requereix sintetitzar coneixements de la detecció d'anomalies en visió que encara no s'han portat als entorns tabulars.

L'equilibri entre prompts i ajust és la troballa més aplicable: els prompts zero-shot funcionen com una primera aproximació però pateixen la bretxa de modalitat; l'ajust fi basat en LoRA sobre exemples etiquetats representatius tanca la bretxa. Per a un desplegament de Beancount amb exemples d'anomalies etiquetats de llibres històrics, la via de l'ajust fi sembla més fiable que el simple ús de prompts.

Què llegir a continuació​

• "Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614) — utilitza incrustacions de sentence-transformers d'LLM en assentaments reals del llibre diari; un pont directe des del marc d'aquesta enquesta cap al cas d'ús tabular de Beancount.
• "Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735) — canalització multi-agent per a la detecció d'anomalies en dades de mercat; el patró de coordinació multi-agent es podria traslladar a l'auditoria de llibres majors.
• AnomalyGPT (arXiv:2308.15366) — LVLM ajustat per a la detecció d'anomalies industrials amb localització a nivell de píxel; llegir això clarifica què significa realment arquitectònicament "l'ajust d'LLM per a la detecció", que l'enquesta descriu però no explica.

L'article​

Hsieh et al. parteixen d'una observació diagnòstica: els LLM —fins i tot els entrenats en contextos llargs— presenten un patró d'atenció persistent en forma d'U. Els tokens al principi i al final de l'entrada reben una atenció desproporcionadament alta independentment de si són rellevants, mentre que els tokens del mig són sistemàticament infraponderats. Els autors connecten això empíricament amb la caiguda de precisió de "perduts al mig" en lloc de tractar-ho com un fenomen separat.

La seva solució és elegant en concepte. Descomponen l'atenció en dos components additius: rellevància (el que volem) i biaix posicional (el que no volem). Per aïllar el terme del biaix, passen un document "fictici" (dummy) —contingut de farciment no informatiu— pel mateix context a cada posició i registren la distribució d'atenció resultant. Aquesta atenció del document fictici aproxima el prior posicional pur. Restar-lo de les puntuacions d'atenció reals deixa un residu que reflecteix millor la rellevància real:

Atenció calibrada = Attn(document, k) − Attn(dummy, k)

Les puntuacions reescalades s'utilitzen llavors per tornar a classificar o ponderar els documents recuperats abans del pas final de generació de la resposta. De manera crucial, no es requereix cap entrenament. El calibratge s'aplica en el moment de la inferència a les darreres 16 capes del descodificador i a tots els capçals d'atenció. El cost és d'O(K) passades endavant addicionals, on K és el nombre de documents recuperats —no és trivial, però és predictible.

Idees clau​

• El biaix d'atenció en forma d'U és intrínsec a l'arquitectura del model i persisteix fins i tot en models entrenats explícitament amb objectius de context llarg.
• Passar un document fictici (buit o amb soroll) pel mateix context de recuperació aïlla el prior posicional; restar-lo elimina el biaix sense cap ajustament fi (finetuning).
• El Recall@3 a NaturalQuestion (K=20, document clau col·locat al mig) puja del 20,52% al 68,32% amb el calibratge; amb K=10, del 36,38% al 74,27%.
• La precisió de QA d'extrem a extrem millora entre 6 i 15 punts percentuals quan el document clau està al mig del context; les millores es mantenen en 22 de les 24 configuracions experimentals.
• El mètode supera sis línies base de comparació: atenció estàndard, classificació per generació de consultes, indicació de generació de rellevància, ordenació per atenció (Peysakhovich & Lerer 2023), reordenació de la indicació (prompt) i LongLLMLingua-rk.
• El mètode es va avaluar amb NaturalQuestion (2.655 consultes reals sobre Wikipedia) i SynthWiki (990 entrades sintètiques generades per GPT-4).

Què se sosté — i què no​

El resultat principal és sorprenent i me'l crec. Una diferència de Recall@3 del 20,52% → 68,32% per a documents clau al mig del context no és el tipus de xifra que s'evapora sota escrutini; està mesurant quelcom real sobre com es distribueix l'atenció. El disseny sense entrenament és un avantatge pràctic genuí: pots aplicar-ho sobre qualsevol flux de treball de RAG existent sense tocar els pesos del model.

Dit això, tinc algunes reserves. Primer, l'enfocament del "document fictici" assumeix que el biaix posicional és aproximadament separable per posició i additiu —una descomposició lineal que els mateixos autors assenyalen que podria ser una simplificació excessiva. El biaix d'atenció real pot interactuar amb el contingut de maneres no lineals. Segon, les O(K) passades endavant addicionals es descriuen com a "acceptables", però mai es comparen pel que fa a latència o cost. En un sistema de producció amb K=20 recuperacions, estàs executant 21 passades endavant en lloc d'una per consulta. Per a un agent de Beancount que tria centenars de transaccions, aquest multiplicador importa.

Tercer —i aquesta és la limitació més interessant—, els autors assenyalen que el biaix posicional podria ser realment útil per a certes tasques. El biaix de recència, per exemple, podria ser el que fa que un model ponderi correctament les entrades de llibre recents per sobre de les més antigues. Eliminar el biaix indiscriminadament podria perjudicar tasques on la posició és un senyal vàlid. Això es reconeix però no s'estudia.

Finalment, els experiments utilitzen NaturalQuestion i un conjunt de dades sintètic. Els documents específics de finances —taules denses, informes de diversos anys, entrades de llibre diari amb estructura repetitiva— són molt diferents dels passatges de domini obert de la Wikipedia. El calibratge s'hauria de validar en aquestes distribucions abans d'afirmar que funcionarà per al RAG financer.

Per què això importa per a la IA financera​

La connexió directa és clara: cada registre des de DocFinQA ha estat voltant el mateix problema. Quan un agent de Beancount recupera 20 entrades de llibre diari rellevants per respondre a una pregunta com "concilia el març amb l'extracte bancari", les entrades del mig de la finestra recuperada rebran sistemàticament menys atenció en relació amb les entrades de la part superior i inferior del context. Això no és un error de recuperació, és un error de generació que cap millora en la classificació de recuperació arreglarà.

El calibratge de "trobat al mig" és una mitigació plausible que no requereix reentrenar el model subjacent i podria aplicar-se directament dins del pas de generació de qualsevol flux de treball de QA sobre llibres comptables. La preocupació pel cost O(K) és real però gestionable; una finestra de recuperació de 20 documents amb un model de mida moderada encara està dins dels límits pràctics. El que voldria veure abans de desplegar-ho és una validació específica sobre dades estructurades de Beancount: la correcció posicional ajuda uniformement o suprimeix sense voler el senyal de recència que fa que les transaccions recents siguin més fiables que les antigues?

El principi més ampli —que els mecanismes d'atenció codifiquen priors posicionals independentment de la rellevància del contingut, i que aquests priors es poden calibrar sense reentrenament— val la pena tenir-lo en compte. Obre la porta a calibratges similars per a altres biaixos: biaix de freqüència de tokens, normalització de la longitud de l'entrada, biaix de verbositat en la generació.

Què llegir a continuació​

• "Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel" (arXiv:2406.02536, ACL Findings 2025) — proposa escalar una sola dimensió d'estat ocult en lloc de restar puntuacions d'atenció; val la pena comparar-ho directament amb l'enfocament de "trobat al mig".
• "Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey" (arXiv:2409.01980, NAACL 2025) — el següent a la llista de lectura; uneix els fils d'AnoLLM, CausalTAD i AD-LLM en una taxonomia unificada.
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172, TACL 2023) — el diagnòstic original al qual respon "trobat al mig"; lectura de base essencial.

L'article​

ReDAct (Reason-Defer-Act) es basa en el paradigma d'instruccions ReAct i introdueix una arquitectura d'agent de dos models. Un model petit i barat — Qwen3-80B, Llama3.3-70B o Llama4-Maverick — gestiona cada pas per defecte. En cada pas, genera una traça de raonament i després genera una acció. El sistema mesura la incertesa a nivell de tòquens només en el pas de generació de l'acció i la compara amb un llindar calibrat. Si la incertesa supera aquest llindar, el model gran i car (GPT-5.2, Qwen3-235B o Qwen3-480B) torna a executar el pas; en cas contrari, s'executa l'acció del model petit.

Les mesures d'incertesa es basen en la teoria de la informació i només requereixen log-probabilitats a nivell de tòquens: Probabilitat de Seqüència (suma de log-probabilitats negatives), Perplexitat (normalitzada per longitud) i Entropia Mitjana de Tòquens (entropia mitjana en les posicions dels tòquens). El llindar es calibra a partir d'un conjunt reservat d'execucions del model petit triant el valor que produeix un nombre objectiu K de crides al model gran per episodi.

Idees clau​

• Mesurar la incertesa en el pas de l'acció, no en el de raonament. Un experiment auxiliars sobre 2.411 passos d'ALFWorld va trobar que la incertesa en el raonament té un poder discriminatiu pobre entre passos correctes i incorrectes; la perplexitat en l'acció té un ROC-AUC i un PRR mesurablement més alts com a predictor de correcció.
• La transferència per perplexitat amb Qwen3-80B + GPT-5.2 aconsegueix un 80,8% ± 1,1% a ALFWorld, superant el 78,3% ± 1,9% de GPT-5.2 sol, amb un cost de 16,25 $ en comptes de 45,21 $, aproximadament un 64% més barat.
• Es transfereixen un ~15% dels passos a la pràctica per coincidir amb un objectiu de calibratge d'aproximadament el 10%; la diferència sorgeix perquè les trajectòries fallides (més curtes) contribueixen de manera desproporcionada al pressupost de transferència.
• La transferència aleatòria a la mateixa taxa puntua un 77,0% — millor que només el model petit (68,3%), però pitjor que la transferència guiada per la quantificació de la incertesa (UQ). El senyal d'incertesa realment importa, no només el fet de cridar més al model gran.
• MiniGrid mostra menys marge de millora. Qwen3-80B + GPT-5.2 amb transferència per perplexitat arriba al 95,0% enfront del 99,0% de GPT-5.2 sol. El vocabulari de tasques més petit crea un sostre més difícil per a l'enfocament de transferència quan el model petit és estructuralment inadequat.
• La distribució de la transferència depèn de la tasca. ALFWorld transfereix més en els passos finals (historial d'instruccions més llarg), mentre que MiniGrid mostra un patró bimodal lligat a la posició inicial de l'agent. Això significa que el calibratge del llindar fix generalitza millor dins d'una família de tasques que entre diferents famílies.

Què se sosté — i què no​

La troballa empírica central és creïble: la perplexitat sobre la cadena d'acció és un substitut raonable per saber si un pas determinat està a punt d'anar malament. La descomposició raonament/acció de ReAct proporciona naturalment un punt net per adjuntar un senyal d'incertesa, i l'experiment auxiliar de predicció de correcció ofereix una justificació mecànica genuïna per a la decisió de disseny.

El que no em convenç tant: el resultat de "supera el model gran sol" a ALFWorld. El 80,8% ± 1,1% i el 78,3% ± 1,9% se solapen en una desviació estàndard. Els autors ho atribueixen a fortaleses complementàries —el model petit gestiona els passos rutinaris sense l'asumpció de riscos ocasional del model gran—, però no hi ha cap ablació per pas que verifiqui aquesta narrativa. Podria ser simplement soroll.

L'elecció del banc de proves també és limitadora. ALFWorld i MiniGrid són simulacions domèstiques basades en text i navegació per graelles: entorns estrets que no posen a prova les crides a eines, l'execució de codi o la recuperació de múltiples documents. No s'ha respost si la transferència calibrada per la incertesa se sosté en aquests entorns més rics (els rellevants per a Beancount). I l'elecció de GPT-5.2 com a model gran fa que les xifres de costos siguin difícils de reproduir.

El procediment de calibratge té una circularitat no resolta: el llindar se selecciona sobre la mateixa distribució en què s'ha calibrat, sense una validació independent. Els autors reconeixen el desplaçament de la distribució entre el calibratge (execucions del model petit) i l'avaluació (execucions híbrides), però deixen la robustesa del llindar per a treballs futurs.

Per què això és important per a la IA en finances​

Los agents d'escriptura de Beancount s'enfronten exactament a la mateixa pregunta de transferència en cada transacció. Una compra rutinària de queviures necessita categorització; un swap de divises inusual de diverses potes amb un memo parcialment coincident necessita un humà. La pràctica actual és o bé l'automatització total (arriscada) o bé la revisió humana total (cara). El marc de ReDAct suggereix un terme mitjà viable: executar el model barat i escalar quan la perplexitat sobre la proposta d'apunt comptable superi un llindar calibrat.

El context financer afegeix dues consideracions que l'article no aborda. Primer, la transferència aquí sovint hauria de significar aturar-se i preguntar a l'usuari, no cridar a un LLM més gran; l'estàndard de correcció del llibre major és la intenció de l'usuari, no una puntuació en un banc de proves. Segon, la irreversibilitat d'una entrada de Beancount consolidada és més alta que la d'un objecte mal col·locat a ALFWorld. L'objectiu de calibratge K probablement s'hauria d'ajustar de manera conservadora cap a una menor precisió en el model petit abans de transferir, i no al revés.

El senyal de reducció de costos del 64% val la pena ser pres seriosament fins i tot amb aquestes advertències. Si un agent de Beancount processa un mes de transaccions i només el 15% de les decisions de categorització necessiten el model car, l'economia d'executar un agent d'escriptura capaç sembla molt millor.

Què llegir a continuació​

• KnowNo (Ren et al., 2023, CoRL): "Robots that ask for help: uncertainty alignment for large language model planners" — utilitza la predicció conformada per calibrar una garantia de cobertura sobre quan demanar ajuda. ReDAct no es compara amb ell; entendre el compromís entre les garanties conformades i el calibratge del llindar és clau abans de triar un enfocament de producció. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. actualitzat, NAACL 2024) — taxonomia sistemàtica de mètodes de confiança verbalitzada, basats en mostreig i de calibratge post-hoc; el rerefons teòric per decidir si la perplexitat és el substitut d'incertesa adequat o si un escalat de logit calibrat funcionaria millor. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) — aplica un llindar d'incertesa estructuralment similar a la decisió d'invocació d'eines (cridar a una eina en comptes de confiar en el coneixement del model), reduint les crides a eines en més d'un 50%; el complement directe de ReDAct per a l'eix de l'ús d'eines de la incertesa de l'agent. [https://uala-agent.github.io/]

L'article​

OpenHands (Wang et al., 2024; ICLR 2025) és una plataforma de codi obert per construir i avaluar agents LLM que actuen com a desenvolupadors de programari generalistes. Liderat per Xingyao Wang i Graham Neubig amb un equip de 24 autors, l'afirmació central de l'article és que la majoria de marcs d'agents existents són o bé massa limitats per a la recerca (bucles de tasques codificats rígidament) o massa tancats per a la producció (codi tancat o d'un sol propòsit) per servir com a base compartida per a la comunitat de recerca. OpenHands intenta solucionar-ho proporcionant un entorn d'execució estandarditzat, una abstracció d'agent neta i 15 bancs de proves d'avaluació integrats sota un sol repositori amb llicència MIT.

L'entorn d'execució és un entorn aïllat en Docker que conté un intèrpret d'ordres bash, un servidor Jupyter IPython i un navegador Chromium controlat per Playwright. Els agents interactuen mitjançant tres tipus d'accions principals: IPythonRunCellAction per a Python, CmdRunAction per a ordres de l'intèrpret d'ordres i BrowserInteractiveAction per a la navegació web. Una primitiva de coordinació multi-agent, AgentDelegateAction, permet que un agent principal generi sub-agents especialitzats. L'eix vertebrador per defecte és CodeAct — publicat originalment com un article independent que argumentava que el codi és l'espai d'accions unificat ideal per als agents LLM — i la plataforma inclou diverses implementacions d'agents, com ara un CodeActAgent general i un BrowsingAgent especialitzat.

Idees clau​

• El codi com a espai d'accions universal: CodeAct consolida totes les accions de l'agent (edicions de fitxers, crides a l'API, transformacions de dades) en Python o bash, permetent que l'LLM raoni en el mateix mitjà en què ha estat entrenat més intensivament. Això evita la fragilitat dels esquemes JSON que afecta els agents basats en crides a funcions.
• Entorn d'execució Docker aïllat: cada agent s'executa en un contenidor aïllat, de manera que els agents poden executar codi arbitrari lliurement sense comprometre la màquina amfitriona — un requisit previ per a qualsevol agent de finances en producció al qual se li puguin lliurar credencials reals.
• 15 bancs de proves en un sol lloc: SWE-Bench Lite (reparació de codi), HumanEvalFix (correcció d'errors), WebArena (navegació web), GPQA (raonament de nivell de postgrau), GAIA (resolució de tasques generals) i deu més. Tenir-los col·locats evita l'avaluació esbiaixada.
• CodeActAgent + claude-3.5-sonnet assoleix un 26% a SWE-Bench Lite i un 79,3% a HumanEvalFix; BrowsingAgent arriba al 15,5% a WebArena — resultats competitius sense cap entrenament específic per a la tasca.
• Rendiment a GAIA: 32,1% amb GPTSwarm, molt per sota del 92% de la línia base humana — consistent amb tots els altres bancs de proves d'agents generals que mostren una bretxa de 60–70 punts entre humans i agents.
• Escala comunitària: 71,4K estrelles a GitHub i més de 188 col·laboradors en el moment de la presentació a l'ICLR; TheAgentCompany va adoptar OpenHands com el seu entorn d'avaluació, atorgant-li l'estatus d'infraestructura de referència de facto.

Què se sosté — i què no​

El disseny de l'entorn d'execució aïllat és una enginyeria sòlida. Isolar l'execució de l'agent en Docker és l'opció correcta per defecte per a qualsevol sistema que més endavant pugui rebre accés d'escriptura a llibres majors financers reals, i és realment útil que els bancs de proves estiguin col·locats en lloc de dispersos en repositoris incompatibles.

La cobertura dels bancs de proves, però, és més aspiracional que sistemàtica. Els 15 bancs de proves abasten tipus de tasques i nivells de dificultat extremadament diferents sense un marc clar de com s'haurien d'agregar o comparar els resultats. Informar d'un 26% a SWE-Bench Lite juntament amb un 79,3% a HumanEvalFix en el mateix article corre el risc de crear la impressió que el mateix agent és simultàniament mediocre i excel·lent — les tasques simplement no són comparables. Els autors no proporcionen una metodologia d'agregació multi-referència basada en principis.

La hipòtesi de CodeAct — que el codi és el format d'acció universal correcte — és discutible. Funciona bé per a tasques de desenvolupament, però imposa una capa de mediació Python/bash a cada acció, cosa que afegeix latència i falla quan la semàntica de l'acció no es mapeja netament al codi (instruccions d'usuari ambigües, APIs només de llenguatge natural). L'article no fa proves comparatives amb espais d'accions que no siguin de codi per demostrar que l'avantatge és real i no una confusió causada pel model LLM subjacent.

Potser la bretxa més important és la divisió entre avaluació i desplegament. La xifra del 26% a SWE-Bench prové d'un banc de proves relativament net i ben especificat. Els informes de la comunitat i els fils de problemes de GitHub descriuen constantment una fiabilitat molt menor en tasques del món real ambígües o de llarg horitzó — el mateix mode d'error que TheAgentCompany va documentar. L'article no aborda com mesurar o millorar la robustesa sota un soroll d'especificació de tasques realista.

Per què això importa per a la IA en finances​

OpenHands és el més semblant que té la comunitat a un substrat d'agents compartit. Si Bean Labs construeix una infraestructura d'avaluació per als agents de Beancount, l'arquitectura de l'entorn d'execució aquí — sandbox Docker, accions Python/bash, backends d'LLM connectables — val la pena adoptar-la en lloc de reconstruir-la. La primitiva AgentDelegateAction es mapeja naturalment a una canonada d'agents financers on un orquestrador de nivell superior delega en sub-agents especialitzats: un per a lectures del llibre major, un per a la detecció d'anomalies, un per a una proposta d'escriptura que un humà revisa.

Les xifres de SWE-Bench i TheAgentCompany, llegides conjuntament, estableixen una premissa aclaparadora: fins i tot els millors agents disponibles completen aproximadament el 26–30% de les tasques de programari realistes i no ambígües. L'automatització dels llibres de comptes financers és més difícil — les transaccions solen ser ambígües, l'impacte dels errors és real i la intenció de l'usuari sovint està infraespecificada. La inferència correcta no és que els agents no estiguin preparats, sinó que els primers desplegaments productius seran fluxos de treball d'escriptura única de poc abast (suggeriments de categorització, marcatge de conciliació) en lloc d'edicions autònomes de llibres de comptes en múltiples passos.

Què llegir a continuació​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — combina un model barat amb un de car i delega al model car només quan la incertesa és alta; aborda directament com un agent a l'estil OpenHands hauria de decidir quan escalar una escriptura de Beancount a la revisió humana.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 seqüències de tasques anotades per experts a través de 34 escenaris financers; la metodologia d'avaluació que OpenHands troba a faltar per a l'ús d'eines de llarg horitzó específiques de finances.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 mostres a través de 65 eines financeres MCP reals, directament rellevant per a com s'avaluaria un agent de Beancount construït sobre l'entorn d'execució d'OpenHands en un desplegament MCP real.

L'article​

Fin-RATE, publicat al febrer de 2026 per Yidong Jiang, Junrong Chen i col·legues de Yale i institucions col·laboradores, presenta un benchmark construït a partir de 2.472 documents de la SEC de 43 empreses i 36 sectors que abasten el període 2020–2025. El benchmark organitza 7.500 parells de preguntes i respostes seleccionades per experts en tres tipus de tasques que reflecteixen els fluxos de treball dels analistes professionals: DR-QA (detall i raonament dins d'un sol document), EC-QA (comparació entre entitats de dues empreses sota un tema compartit) i LT-QA (seguiment longitudinal de la mateixa empresa al llarg dels períodes d'informes). Cada tipus de tasca conté 2.500 preguntes. L'avaluació abasta 17 LLM: models de codi tancat incloent GPT-4.1 i GPT-5, models de codi obert generals com DeepSeek-V3 i Llama-3.3-70B, i models especialitzats en finances com Fin-R1, Fino1-14B, FinanceConnect-13B i TouchstoneGPT-7B. La puntuació utilitza un marc unificat d'LLM-com-a-jutge amb tres jutges independents (GPT-5, DeepSeek-V3.2, Qwen3-235B) que puntuen cada resposta segons la correcció i cinc dimensions analítiques.

Idees clau​

• El rendiment es col·lapsa a mesura que augmenta la complexitat de la tasca: la precisió cau un 18,60% des del DR-QA d'un sol document fins al LT-QA longitudinal i un 14,35% des del DR-QA fins a l'EC-QA entre entitats, de mitjana en els 17 models.
• GPT-5 amb cerca web és el que millor rendiment té, però la seva precisió màxima se situa només entre el 43 i el 44% en els tres tipus de tasques, una xifra pèssima per a un benchmark que pretén reflectir els fluxos de treball reals dels analistes.
• Fin-R1, el model de raonament especialitzat en finances, arriba al 57,48% en DR-QA però es col·lapsa fins al 3,32% en EC-QA: una caiguda de 54 punts que supera amb escreix la degradació de qualsevol model general.
• En configuracions RAG, el rendiment en tots els models cau molt per sota del 27%, en comparació amb el rendiment amb context d'or (gold-context) de fins al 57,48%; el pipeline de recuperació, i no l'LLM, és el coll d'ampolla principal.
• L'article introdueix una taxonomia d'errors de 13 tipus en quatre categories: al·lucinacions i contradiccions, errors numèrics i semàntics específics de finances, errors de comprensió de la consulta o context i fallades a nivell de recuperació. La manca de proves (Missing Evidence) representa el 75,44% dels errors en la tasca EC-QA sota RAG.
• Els models especialitzats en finances mostren taxes d'al·lucinació sistemàticament més altes que els models generals en tasques complexes, malgrat una millor terminologia financera.

Què se sosté — i què no​

L'estructura de tres vies està realment ben dissenyada. La majoria dels benchmarks financers (FinQA, TAT-QA, FinanceBench) tracten les preguntes i respostes com una tasca d'un sol document. Fin-RATE és un dels primers a modelar explícitament la comparació entre entitats i el seguiment longitudinal com a tasques de primer nivell, i els resultats exposen una bretxa fonamental: els LLM actuals gestionen les preguntes sobre informes aïllats de manera tolerable, però es desmoronen en el moment que necessiten sintetitzar informació entre documents, entitats o períodes de temps.

El col·lapse de Fin-R1 és la troballa més sorprenent de l'article i crec que està infravalorada. Un model ajustat a les finances que destaca en l'extracció d'un sol document aparentment es va entrenar en un carreró sense sortida: va aprendre plantilles per respondre dins d'un document, no estratègies de raonament per relacionar entitats i períodes de temps. Aquesta és una advertència concreta contra l'ajust fi (fine-tuning) de dominis estrets sense una supervisió explícita del raonament multidocument. Probablement el model s'ajusta excessivament al patró superficial de "trobar el número al document" i no té cap via de generalització per a "comparar aquest número amb el número equivalent en un altre document d'una altra empresa".

Dit això, hi ha preocupacions metodològiques que val la pena assenyalar. El GPT-5 és simultàniament un dels models avaluats i un dels tres jutges que puntuen les respostes. Els autors utilitzen tres jutges per reduir el biaix individual, cosa que ajuda, però el solapament entre jutge i model amb el model més fort avaluat és incòmode. L'article informa d'un alt acord entre jutges, però no quantifica per separat quina fracció de les respostes de GPT-5 va puntuar el mateix GPT-5, ni si les puntuacions autoavaluades de GPT-5 difereixen sistemàticament dels altres dos jutges. Qualsevol biaix d'autoavaluació inflaria el resultat final per al model amb millor rendiment de l'estudi.

La mostra de 43 empreses també és escassa. La cobertura del tipus de document és lloablement àmplia (10-K, 10-Q, 8-K, 6-K, DEF 14A i diverses sèries S i SC), però les mateixes 43 empreses apareixen en totes les tasques. Els models que han vist els informes d'aquestes empreses en el preentrenament tenen un avantatge no quantificat, i l'article no inclou cap anàlisi de contaminació.

La troballa sobre la recuperació és important però incompleta. L'article identifica que el rendiment de RAG es col·lapsa en aproximadament 30 punts en comparació amb el context d'or perquè la recuperació falla. Però només avalua una única configuració de recuperació: tracta la fallada de recuperació com un diagnòstic en lloc de com una cosa per variar sistemàticament. Un article posterior que explorés les arquitectures de recuperació a Fin-RATE seria molt més útil.

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

L'auditoria de llibres majors de Beancount necessita exactament les dues capacitats que Fin-RATE revela que estan trencades: el seguiment longitudinal (com ha evolucionat aquest compte al llarg dels exercicis fiscals?) i la comparació entre entitats (es concilia el balanç d'aquesta filial amb l'estat consolidat?). La caiguda de precisió del 18,60% sota el seguiment temporal és una xifra concreta que hauria de calibrar les expectatives per a qualsevol agent de Beancount que raoni a través de diversos períodes d'informes. Si els models d'última generació fallen al 43% sota el context d'or en preguntes longitudinals de la SEC, un agent de Beancount que navegui per historials de llibres majors de diversos anys s'hauria de dissenyar amb recuperació explícita, fonamentació temporal i escalada humana, no amb inferència LLM d'extrem a extrem.

La troballa sobre la dominància de la recuperació és el que més importa per a la prioritat del disseny del sistema. Si el rendiment amb context d'or és gairebé el doble que el rendiment amb RAG, la inversió correcta és en una millor fragmentació (chunking), selecció de passatges i recuperació, no en un model LLM base més capaç. Això reflecteix el que DocFinQA va trobar per als documents de la SEC de context llarg: el pipeline al voltant del model és el coll d'ampolla.

L'advertència sobre Fin-R1 també s'aplica directament al cas d'ús de Beancount. L'ajust fi en la sintaxi DSL de Beancount i els patrons de transaccions pot produir un model que gestioni bé la generació d'entrades simples, però que falli sota la conciliació multicompte i multiperíode que fa que l'auditoria sigui útil. L'especialització sense entrenament en raonament multidocument és fràgil precisament de la manera com mesura Fin-RATE.

Què llegir a continuació​

• Fin-R1 (arXiv:2503.16252) — per entendre quina configuració d'entrenament va produir un rendiment tan fràgil entre documents, i si el raonament multidocument va estar mai previst.
• FinTrace (arXiv:2604.10015) — avaluació a nivell de trajectòria de la crida d'eines d'LLM a través de 34 categories de tasques financeres; complementa la visió de QA estàtica de Fin-RATE amb un diagnòstic a nivell de procés d'on els models invoquen les eines adequades però no aconsegueixen raonar sobre els resultats.
• OpenHands (arXiv:2407.16741) — la plataforma d'agents oberta que hi ha darrere de les avaluacions de TheAgentCompany; entendre la seva arquitectura aclareix quines capacitats bàsiques de l'agent estaven disponibles i quines llacunes són atribuïbles a la dificultat de la tasca més que a les limitacions de la plataforma.

L'article​

Chanyeol Choi, Jihoon Kwon i els seus col·legues d'una empresa d'IA financera presenten un conjunt de dades de 5.703 triplets de consulta–evidència–resposta anotats per experts, obtinguts d'un servei real de preguntes i respostes per a analistes de fons de cobertura. Els documents són informes del model 10-K de 490 empreses de l'S&P 500, recollits de l'SEC EDGAR. El que distingeix FinDER dels bancs de proves anteriors és la part de la consulta: el 89,86% de les consultes contenen tres o més abreviatures o acrònims específics del domini. En lloc de "Quins són els ingressos totals de l'empresa X per a l'exercici fiscal 2023?", un analista real podria escriure "GOOGL 10-K FY23 revs breakdown by segment". El conjunt de dades es va publicar al Taller de l'ICLR 2025 sobre Avanços en IA Financera i més tard va aparèixer a l'ICAIF 2025.

Idees clau​

• La recuperació de context és sorprenentment baixa en tots els aspectes: E5-Mistral (el millor recuperador dens) només aconsegueix un 25,95% de recuperació de context global; BM25 n'aconsegueix un 11,68%. La categoria "Financials" —la més directament rellevant per a la comptabilitat— és la més difícil: un 15,84% i un 6,42% respectivament.
• L'ambigüitat de la consulta per si sola costa 8,2 punts de precisió: Provant l'E5-Mistral en 500 consultes, els autors comparen paràfrasis ben formades (33,9 de precisió) amb les consultes reals abreujades (25,7 de precisió). La bretxa és totalment atribuïble al maneig d'abreviatures/acrònims, no a la complexitat del document.
• La qualitat de la recuperació és el coll d'ampolla dominant per a la generació: Els LLM sense context puntuen gairebé zero (9–10% d'encerts); amb els 10 millors fragments recuperats arriben al 29–34%; amb un context d'oracle perfecte salten al 60–68%. Aquesta bretxa de 35 punts entre les condicions reals i les d'oracle és més gran que la bretxa entre els models de codi obert i els d'última generació.
• L'aritmètica compositiva falla fins i tot amb una bona recuperació: Les tasques de càlcul de diversos passos (consultes compositives) només assoleixen un ~20% d'encerts en els quatre models —Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill i Qwen-QWQ— fins i tot amb els 10 millors fragments recuperats. GPT-o1 lidera les tasques de multiplicació amb un 42,90%, però cau al 27,78% en la divisió.
• El reranking per LLM afegeix una millora modesta però constant: Permetent que els models tornin a classificar els 10 millors resultats de l'E5-Mistral abans de respondre, Claude-3.7-Sonnet aconsegueix un F1 de 63,05 i GPT-o1 arriba a 62,90. Deepseek-R1-Distill es queda enrere amb 60,01, malgrat el seu fort rendiment en el raonament estructurat en altres llocs.
• La dificultat de les categories és desigual: Les consultes sobre riscos són les més fàcils de recuperar (E5-Mistral: 33,07 de recuperació); les finances continuen sent les més difícils (15,84). Això es correlaciona amb l'estructura de la consulta: les revelacions de riscos utilitzen prosa en llenguatge natural, les taules financeres utilitzen una notació numèrica densa.

Què se sosté — i què no​

La contribució principal és sòlida: es tracta d'una distribució de consultes real d'analistes en actiu, i el problema de les abreviatures és genuí. Qualsevol banc de proves construït a partir de la Viquipèdia o del crowdsourcing tipus FinQA passa això per alt. L'estructura d'avaluació de tres nivells —sense context, recuperació realista, context d'oracle— és el disseny correcte; separa clarament la qualitat de la recuperació de la qualitat del raonament i mostra la bretxa de generació residual (encara un ~32–34% de fracàs fins i tot amb un context perfecte en preguntes qualitatives).

On l'article és més feble és en la reproductibilitat. En el moment de la publicació, el conjunt de dades no estava disponible públicament; els autors afirmen que "tenen previst publicar-lo més endavant". Això és un problema significatiu per a un article de taller que es presenta com un estàndard d'avaluació. Els bancs de proves que no es publiquen no són bancs de proves; són estudis de cas. Des de llavors ha aparegut a l'ICAIF 2025, de manera que és possible que s'hagi publicat posteriorment, però la versió d'arXiv no ho confirma.

L'avaluació de la recuperació també utilitza només quatre models d'una sola etapa (BM25, GTE, mE5, E5-Mistral). No hi ha recuperació híbrida, ni expansió de consultes, ni HyDE, ni cap pas de reescriptura orientat específicament al problema de les abreviatures. Atès que els autors han caracteritzat amb precisió la bretxa de les abreviatures, sorprèn que no provin la solució òbvia: expandir la consulta ("GOOGL" → "Alphabet Inc.") abans de la recuperació. Aquest experiment està absent.

Els resultats de generació mereixen una lectura més detinguda. El rendiment de ~9–10% sense context no és un límit inferior útil —és essencialment zero—, però el sostre de l'oracle del 60–68% és més informatiu del que sembla. Fins i tot amb el fragment correcte a la mà, els millors models fallen en aproximadament un terç de les preguntes qualitatives i en quatre cinquenes parts de l'aritmètica compositiva. Aquest sostre és important: significa que la recuperació per si sola no pot resoldre el problema.

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

La distribució de consultes a FinDER s'ajusta bé a com els usuaris de Beancount interactuen realment amb un agent de llibre major. Un usuari que hagi mantingut els seus comptes durant anys escriurà consultes contextuals i abreujades: "AMZN card Q3 reemb?" en lloc de "Quins són els reemborsaments de la targeta Amazon al tercer trimestre?". Els models d'embedding estàndard no aconseguiran recuperar les entrades correctes perquè es van entrenar amb text net en llenguatge natural. La caiguda de precisió de 8,2 punts de les consultes netes a les reals és probablement conservadora per a un domini de llibre major personal, on les abreviatures idiosincràtiques ("quota gest. prop." per "quota de gestió de la propietat") estan encara més lluny de les dades d'entrenament que les abreviatures estàndard de la SEC.

El sostre de recuperació de context del 25,95% a l'E5-Mistral és una força impulsora: qualsevol pipeline de RAG per a Beancount ha de preveure una gran fracció d'evidència perduda. Una implicació és que la re-recuperació d'alta recuperació (múltiples passades, formulacions de consulta diversificades) importa més que augmentar l'F1 en una sola passada. Una altra és que la normalització de la consulta —mapejar les abreviatures de l'usuari als noms de compte canònics abans de la recuperació— hauria de ser un pas de preprocessament explícit, no deixar-ho en mans del model d'embedding.

La precisió del 20% en l'aritmètica compositiva fins i tot amb context d'oracle és un senyal independent: per a les tasques de càlcul de Beancount, el coll d'ampolla de la generació és el raonament, no la recuperació. La descàrrega tipus PAL (generar aritmètica de Python en lloc de càlculs de text lliure) continua sent la resposta correcta per a les tasques numèriques independentment de com de bona sigui la recuperació.

Què llegir a continuació​

• Fin-RATE (arXiv:2602.07294) — el banc de proves complementari per al seguiment de diversos períodes en presentacions de la SEC; la precisió cau un 18,60% en tasques temporals, que és el problema del llibre major de Beancount de diversos anys plantejat directament.
• IRCoT (arXiv:2212.10509, ACL 2023) — entrellaçant la recuperació amb el raonament de cadena de pensament; l'estructura de recuperació de múltiples passades aborda directament la baixa recuperació d'una sola passada que exposa FinDER.
• Expansió de consultes amb LLM per a la recuperació específica del domini — cap article de banc de proves ho cobreix bé encara, però la bretxa d'abreviatures de FinDER el converteix en una prioritat de recerca de primer ordre; buscar "HyDE financial domain" i "query expansion SEC filings 2025" és el punt de partida correcte.

L'article​

"Lost in the Middle: How Language Models Use Long Contexts" de Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni i Percy Liang realitza dos experiments dirigits: resposta a preguntes multidocument sobre NaturalQuestions-Open (amb 10, 20 i 30 documents recuperats) i recuperació sintètica de clau-valor (amb 75, 140 i 300 parells). En cada experiment, varien sistemàticament on se situa el document rellevant o el parell clau-valor dins del context d'entrada —al principi, al mig o al final— mentre mantenen la resta fixa. La troballa és clara: el rendiment segueix una corba en forma de U amb el punt més baix al mig del context, i la corba apareix en cada model provat.

Idees clau​

• La forma de U és real i constant. En l'escenari de QA amb 20 documents, el rendiment a la primera posició era aproximadament del 75% i es degradava fins al voltant del 55% a la posició 10, abans de recuperar-se fins a prop del 72% a la posició 20 —una diferència de ~20 punts entre els extrems i el centre.
• Tots els models segueixen el mateix patró. Els models provats inclouen tancats i oberts, petits i grans: GPT-3.5-Turbo (4K i 16K), GPT-4, Claude-1.3 (8K i 100K), MPT-30B-Instruct i LongChat-13B. La corba en U va aparèixer en cadascun d'ells, inclosos els models comercialitzats explícitament per a finestres de context ampli.
• Ni tan sols Claude-1.3-100K n'és immune. La variant de context de 100K es va comportar com les altres. Una finestra de context llarga no vol dir que el model realment hi pari atenció de manera uniforme.
• La base de referència "closed-book" estableix un mínim preocupant. El GPT-3.5-Turbo sense cap document va respondre correctament el 56,1% de les NaturalQuestions; amb accés directe a l'únic document rellevant va arribar al 88,3%. Però en les pitjors posicions intermèdies de l'escenari de 20 documents, el rendiment va caure per sota de la base de referència "closed-book", cosa que significa que afegir més context va ser activament perjudicial.
• Els models encoder-decoder (Flan-T5-XXL, Flan-UL2) són més robustos dins de la seva longitud d'entrenament, però recauen quan els contextos la superen. La diferència arquitectònica és important, però ambdós es degraden a escala.
• La causa principal és l'emmascarament d'atenció causal. Cada token només pot atendre els tokens precedents, de manera que les posicions del principi acumulen més pes d'atenció total a través del model que les posicions del mig. Els efectes de recència també eleven el rendiment al final del context.

Què es manté ferm — i què no​

El disseny experimental aquí és admirablement net: la posició és l'única variable que es manipula, les tasques són punts de referència estàndard i la troballa es replica en una àmplia gamma de famílies de models. No tinc res a objectar al resultat principal.

El que em sembla menys convincent és l'enfocament de la tasca de recuperació de clau-valor com a substitut significatiu de l'ús real. Les cerques d'UUID a UUID proven si un model pot repetir com un lloro una cadena memoritzada, no si pot fer res que requereixi raonament. La corba en U també apareix aquí, cosa que reforça l'afirmació del biaix de posició, però també significa que l'article combina dos fenòmens diferents: la precisió de la recuperació en tasques de coincidència exacta i la qualitat del raonament sobre fragments rellevants. M'agradaria saber si la forma de U empitjora o millora quan el document rellevant requereix una inferència en diversos passos abans de la resposta final, i no només una repetició textual.

També hi ha una llacuna que els autors reconeixen majoritàriament però no tanquen: mai no proven si l'ajust d'instruccions o l'RLHF canvia la sensibilitat a la posició, només si ho fa una finestra de context més gran. Atès que la causa principal és arquitectònica (emmascarament causal), sospito que l'ajust d'instruccions no ho solucionarà, però l'article no ho confirma.

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

Aquest article proporciona l'explicació mecànica per a un patró empíric que em trobo contínuament. DocFinQA es va col·lapsar amb documents llargs de la SEC. IRCoT i FLARE recuperen múltiples fragments i els concatenen abans de raonar. Cada canalització RAG que he analitzat en un context financer aboca els fragments recuperats seqüencialment al prompt i espera que el model s'atengui al correcte.

La implicació per als agents de Beancount és concreta. Si un agent recupera deu entrades del llibre diari com a context, les entrades a les posicions 3–7 tenen el risc més alt de ser ignorades o de generar al·lucinacions al seu voltant. Això no és un problema de recuperació, és un problema de presentació. D'aquest article se'n deriven dues respostes: o bé posar les entrades més rellevants per al diagnòstic al principi (i al final), o bé no concatenar gens i raonar sobre un fragment cada vegada.

La troballa també complica la narrativa dels LLM de context llarg. Cada trimestre, un nou model anuncia una finestra de context més gran. Aquest article diu que el fet que la finestra sigui llarga no significa el que penses si estàs distribuint l'evidència uniformement per tota ella. Un model de context de 128K que enterra la transacció rellevant a la posició 60K és pitjor que un model de context de 4K que recupera exactament el fragment correcte.

Per a la seguretat en l'escriptura (write-back), les implicacions són incòmodes: si es demana al model que resumeixi una sessió del llibre diari i la regla de política pertinent de "no publiquis aquesta transacció" apareix al mig d'un system prompt llarg, el model pot actuar com si mai no hagués llegit aquesta regla.

Què llegir a continuació​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797) — proposa la codificació posicional multiescala (Ms-PoE) com una solució sense entrenament mitjançant l'escalat de RoPE; afirma una millora de fins a 3,8 punts en Zero-SCROLLS, abordant directament la corba en U.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198) — adopta l'enfocament oposat i entrena el model per ser explícitament agnòstic a la posició; la comparació amb Ms-PoE aclareix si l'ajust fi o els trucs en temps d'inferència són la millor palanca.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536) — identifica la dimensió específica dels estats ocults posicionals responsable del biaix i l'escala sense reentrenament; la solució més quirúrgica proposada fins ara, rellevant per al desplegament de models existents sense reentrenament.

L'article​

Tiankai Yang, Yi Nian i els seus col·legues de la USC i Texas A&M presenten AD-LLM (arXiv:2412.11142, ACL Findings 2025), el primer benchmark per avaluar sistemàticament els LLM en tres paradigmes de detecció d'anomalies en conjunts de dades de PNL. L'entorn és la classificació d'una sola classe (one-class classification): les dades d'entrenament només contenen mostres normals, i el model ha de marcar les anomalies en el moment de la prova. Els cinc conjunts de dades —AG News, BBC News, IMDB Reviews, N24 News i SMS Spam— deriven tots de tasques de classificació de text amb una categoria designada com a anòmala. L'article posa a prova dos LLM, GPT-4o i Llama 3.1 8B Instruct, contra 18 referències (baselines) no supervisades tradicionals que inclouen mètodes extrem a extrem (CVDD, DATE) i combinacions de dos passos d'incrustació més detector (incrustacions d'OpenAI + LUNAR, LOF, Isolation Forest, etc.).

Idees clau​

• La detecció zero-shot funciona bé per al text. GPT-4o obté un AUROC d'entre 0,9293 i 0,9919 en els cinc conjunts de dades en la configuració Normal+Anomalia; Llama 3.1 arriba a 0,8612–0,9487. La millor referència tradicional, OpenAI + LUNAR, obté uns 0,92 a AG News; GPT-4o l'iguala o el supera sense cap entrenament.
• L'augment sintètic ajuda, de manera constant però modesta. Les mostres sintètiques generades per LLM milloren el flux de treball OpenAI + LUNAR en els cinc conjunts de dades. L'augment de la descripció de les categories també millora la majoria de les referències, tot i que els guanys són desiguals: Llama 3.1 millora l'AUROC en +0,07 a IMDB Reviews, però els resultats en altres llocs són més petits.
• La selecció de models és el punt feble. GPT-o1-preview recomana models que superen el rendiment mitjà de les referències en la majoria de conjunts de dades i, ocasionalment, s'apropa al millor mètodes (p. ex., a IMDB Reviews i SMS Spam). Però mai identifica amb fiabilitat el millor mètode, i els autors reconeixen que les recomanacions es basen en entrades simplistes que no tenen estadístiques específiques del conjunt de dades.
• La bretxa entre codi obert i propietari és real. L'avantatge d'AUROC de GPT-4o sobre Llama 3.1 8B és d'entre 4 i 13 punts depenent del conjunt de dades, una bretxa consistent amb el patró vist en articles de detecció d'anomalies tabulars zero-shot.
• La detecció d'anomalies en PNL encara no té un benchmark definitiu. Cinc conjunts de dades, tots derivats de corpus de classificació, és poc. L'article complementari NLP-ADBench (EMNLP Findings 2025) amplia a vuit conjunts de dades i 19 algorismes, però continua utilitzant la mateixa construcció de categoria semàntica com a anomalia que fa que aquestes tasques siguin una mica artificials.

Què se sosté — i què no​

Les troballes sobre zero-shot són creïbles. Utilitzar els LLM com a avaluadors sense ajustar-los amb dades d'anomalies etiquetades és realment útil quan la classe anòmala és semànticament coherent: un missatge de correu brossa (spam) difereix d'un missatge legítim (ham) de maneres que un model de llenguatge ben entrenat entén. Les xifres d'AUROC són altes, i la comparació amb referències sòlides basades en incrustacions d'OpenAI és justa.

L'abast, però, és limitat d'una manera que l'article no destaca prou. Els cinc conjunts de dades codifiquen les anomalies com una categoria temàtica diferent —spam contra SMS legítim, notícies d'un editor exclòs contra mitjans dins de la distribució. Això significa que el LLM està fent essencialment una classificació de temes, una tasca per a la qual ha estat explícitament pre-entrenat. El benchmark no inclou anomalies semàntiques dins d'una mateixa categoria (p. ex., transaccions inusuals dins del mateix tipus de compte), que és precisament el tipus d'anomalia que importa per a l'auditoria financera.

Les tasques d'augment de dades i selecció de models s'avaluen en els mateixos cinc conjunts de dades, de manera que l'article acaba avaluant si els LLM poden millorar marginalment diferents variants del mateix problema estret. Els autors llisten obertament sis limitacions —incloent-hi que només proven un subconjunt de LLM, exclouen els règims de pocs exemples (few-shot) i d'ajustament, i confien en entrades simplistes per a la selecció de models—, la qual cosa és intel·lectualment honesta però també assenyala com de preliminar és aquest benchmark.

Un resultat que val la pena destacar per als escèptics: les puntuacions AUPRC són substancialment més baixes que l'AUROC per a ambdós models. Llama 3.1 a BBC News arriba a un AUROC de 0,8612 però només a un AUPRC de 0,3960, reflectint el desequilibri de classes en la configuració d'una sola classe. En contextos d'auditoria d'alta precisió, l'AUPRC és la mètrica més significativa, i aquí la imatge és menys favorable.

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

L'agenda de Bean Labs inclou dos casos d'ús de detecció d'anomalies: detectar assentaments inusuals al llibre major en temps real (tabular, estructurat) i marcar text narratiu sospitós en factures, notes o tiquets de suport (PNL no estructurat). AD-LLM parla directament del segon cas i ens dóna un sostre realista: GPT-4o pot detectar anomalies a nivell de tema en text en mode zero-shot amb un AUROC superior a 0,93 en conjunts de dades nets i equilibrats. Aquesta és una referència útil, però les anomalies en les descripcions del llibre major són més subtils: una nota de factura que descriu un servei rutinari però que pertany a un proveïdor marcat per patrons sospitosos no és un problema de classificació de temes. El benchmark proporciona un punt de partida, no una resposta.

La troballa sobre la selecció de models és interessant per si mateixa per al disseny de sistemes. El somni de preguntar a un LLM "quin detector d'anomalies hauria d'utilitzar en aquest conjunt de dades?" i obtenir una resposta fiable encara no s'ha complert. Això significa que triar entre l'ajustament estil AnoLLM, la inducció causal estil CausalTAD o un mètode d'incrustació clàssic encara requereix el judici humà o una avaluació empírica sistemàtica; no es pot delegar a un assessor LLM.

Què llegir a continuació​

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025) — el benchmark complementari del mateix grup, que cobreix vuit conjunts de dades i 19 algorismes; proporciona el context de referència clàssic més ampli que l'abast de cinc conjunts de dades d'AD-LLM no pot oferir.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025) — analitza tot el panorama dels enfocaments de detecció d'anomalies basats en LLM en modalitats de text, imatge i tabulars; situa AD-LLM en relació amb els treballs previs.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — l'equivalent tabular; comparar el seu enfocament basat en la versemblança amb l'estratègia zero-shot basada en instruccions d'AD-LLM aclareix quin paradigma és més adequat per als assentaments del llibre major de Beancount.

El document​

Wang et al. proposen CausalTAD, un mètode que se situa per sobre dels detectors d'anomalies LLM a l'estil AnoLLM i realitza un canvi específic: en lloc de serialitzar les files tabulars en un ordre de columnes aleatori o arbitrari, descobreix les dependències causals entre les columnes i les reordena per respectar aquestes dependències abans que l'LLM llegeixi la fila.

El document té dues parts mòbils. Primer, un mòdul d'ordenació de columnes impulsat per la causalitat. Els autors adapten el marc d'extracció de factors COAT: un LLM llegeix les metadades de les columnes i les mostres per extreure factors semàntics d'alt nivell (per a transaccions de targetes de crèdit, un factor com "Compensació" podria abastar les columnes d'import i de comerciant). A partir d'aquests factors, tres algorismes de descobriment causal — PC, LiNGAM i FCI — construeixen cadascun un graf causal dirigit sobre els factors. El problema de reordenació de columnes es converteix llavors en un Problema d'Ordenació Lineal: trobar la permutació π que maximitzi la suma dels pesos de les arestes dirigides, de manera que les columnes causa apareguin abans que les columnes efecte en el text serialitzat. Com que el problema de programació lineal (LP) té moltes solucions gairebé òptimes, mostregen K ≈ 10 ordenacions dins del 90% de l'òptim i fan la mitjana entre elles.

Segon, un mòdul de reponderació conscient de la causalitat. No totes les columnes són igualment rellevants. Una columna que influeix en molts factors rep un pes més alt αj = |M⁻¹(cj)|, el recompte de factors als quals contribueix. La puntuació final d'anomalia és la mitjana ponderada de les versemblances logarítmiques negatives per columna a través de les K ordenacions.

Idees clau​

• L'ordenació de les columnes és un biaix inductiu no trivial per als LLM autoregressius: col·locar una columna causa abans de la seva columna efecte permet que el model es condicioni al context correcte en assignar la probabilitat a l'efecte.
• El descobriment causal a nivell de factor (en lloc de a nivell de columna bruta) permet al mètode gestionar taules de tipus mixt on el descobriment causal directe entre columnes heterogènies genera soroll.
• En 6 conjunts de dades de referència de tipus mixt, CausalTAD amb SmolLM-135M arriba a un AUC-ROC mitjà de 0,834 enfront del 0,803 d'AnoLLM — una millora absoluta de 3,1 punts amb el mateix model de base.
• Específicament en el conjunt de dades Fake Job Posts, CausalTAD obté una puntuació de 0,873 enfront del 0,800 d'AnoLLM — un guany relatiu del 9,1%, que és prou gran com per ser rellevant en un sistema de triatge real.
• En 30 conjunts de dades de referència ODDS numèrics, CausalTAD aconsegueix el millor AUC-ROC mitjà, superant constantment les línies de base clàssiques (Isolation Forest, ECOD, KNN) i els mètodes profunds (DeepSVDD, SLAD).
• Els tres algorismes de descobriment causal superen l'ordenació aleatòria en l'ablació; LiNGAM supera lleugerament PC i FCI en els conjunts de dades mixts.

Què s'aguanta — i què no​

L'afirmació central — que l'ordre causal de les columnes ajuda — està ben fonamentada. L'ablació és clara: canviar l'ordenació aleatòria per qualsevol dels tres mètodes de descobriment causal millora els resultats en el banc de proves Fake Job Posts (de 0,832 a 0,870–0,873), i la reponderació per recompte de factors ajuda encara més en cada configuració. És una història creïble.

El que trobo menys convincent és la hipòtesi d'arrencada (bootstrapping). El graf causal es construeix utilitzant un LLM per extreure factors semàntics de les mateixes dades que el sistema ha d'analitzar. Si l'LLM malinterpreta el domini — per exemple, per a un sistema comptable personalitzat amb noms de columnes no estàndard — l'extracció de factors serà errònia, i un graf causal dolent és possiblement pitjor que l'ordenació aleatòria perquè introdueix un biaix sistemàtic. Els autors reconeixen aquest risc ("depèn de la capacitat dels LLM per a l'extracció de factors") però no avaluen l'exactitud de l'extracció de factors de manera independent.

També hi ha un problema de sobrecàrrega computacional que és més greu del que suggereix el document. Executar tres algorismes de descobriment causal, resoldre un LP, mostrejar K ordenacions i després executar la inferència en K versions serialitzades de cada punt de prova multiplica el cost d'inferència per K. Per a un llibre comptable amb milions d'entrades, això importa. El document assenyala que "el treball futur es podria centrar a millorar l'eficiència" però no ofereix cap anàlisi de rendiment concret.

Finalment, els 30 conjunts de dades ODDS numèrics estan molt estudiats i podria dir-se que estan saturats per a mètodes com aquest. El senyal més significatiu es troba en els 6 conjunts de dades de tipus mixt — que són els realistes per a les finances — i les millores allà, tot i ser reals, són una mica modestes en termes absoluts.

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

Les transaccions de Beancount tenen una estructura causal genuïna: l'import de l'apunt impulsa causalment la selecció del compte, el compte impulsa l'expectativa de la contrapart, i el text de la nota es troba causalment aigües avall de tots tres. La serialització aleatòria de columnes ignora això, el que significa que un model de l'estil AnoLLM veu "memo: compres | compte: Despeses:Menjar | import: 4200 €" tan lliurement com la versió correctament ordenada.

CausalTAD ofereix una manera basada en principis per codificar que "l'import i el compte van primer" sense programar-ho rígidament com una regla. Per als agents d'auditoria de Bean Labs, això suggereix una opció arquitectònica pràctica: abans de puntuar un lot de transaccions per detectar anomalies, fer una passada per descobrir el graf causal sobre l'esquema de columnes del llibre comptable, i després utilitzar aquesta ordenació fixa per a tota la inferència posterior. La sobrecàrrega es paga un cop a nivell d'esquema, no per transacció.

L'exemple de detecció de frau amb targetes de crèdit del document té essencialment la mateixa estructura de tasca que la detecció d'anomalies en llibres comptables: característiques heterogènies, etiquetes rares i un ordre causal que els experts del domini coneixen intuïtivament però que, d'altra manera, els LLM ignorarien.

Què llegir a continuació​

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — el banc de proves sistemàtic a través de tres paradigmes de detecció d'anomalies LLM en els quals s'enquadra CausalTAD; llegir-lo ofereix el panorama complet en lloc de la comparació única entre AnoLLM i CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — el marc d'extracció de factors que CausalTAD adapta; entendre com funciona aclareix on pot fallar la qualitat del graf causal.
• Causal discovery in heterogeneous data: a survey — per entendre els mèrits relatius de PC vs LiNGAM vs FCI en dades tabulars de tipus mixt, ja que el document els tracta tots tres com a intercanviables però assumeixen diferents hipòtesis d'independència.

L'article​

AnoLLM reformula la detecció d'anomalies tabulars com una estimació de densitat del model de llenguatge en lloc d'una classificació mitjançant prompts. En lloc de demanar a l'LLM que identifiqui quines files semblen sospitoses, els autors realitzen un ajust finit (fine-tuning) d'un model de llenguatge preentrenat amb files d'entrenament serialitzades de la distribució normal, i després puntuen cada fila de prova mitjançant la seva log-versemblança negativa (NLL) sota la distribució apresa. Una fila que no s'assembla en res a la distribució d'entrenament obté una NLL alta — aquesta és la puntuació d'anomalia. Sense formats d'índexs, sense anàlisi de sortida, sense extraccions fràgils per regex.

La serialització converteix cada fila de la taula en una cadena de llenguatge natural amb noms de característiques i valors. Per a les columnes amb valors de text, la NLL es normalitza per columna per evitar el biaix de longitud, on les descripcions més llargues acumularien altrament costos de probabilitat més elevats de manera mecànica. Per a les columnes numèriques i categòriques, la NLL bruta a nivell de tòquen se suma a tot el camp. El model s'ajusta en un entorn semisupervisat —només les files etiquetades com a normals entren en l'entrenament— durant un màxim de 2.000 passos utilitzant entrenament GPU distribuït.

Idees clau​

• El problema del format de sortida: els enfocaments previs de predicció d'índexs requereixen que els LLM basin la seva sortida en índexs de files anòmales d'un lot de manera fiable. Els models de la família Llama sovint emparellen índexs incorrectes amb valors, generen índexs més enllà de la mida del lot o simplement llisten tot com a anòmal. La NLL evita això completament.
• AnoLLM aconsegueix el millor rendiment en sis conjunts de dades de referència amb tipus de característiques mixtes, incloent-hi la detecció de frau en assegurances de vehicles i conjunts de dades de frau en comerç electrònic de Kaggle.
• En els 30 conjunts de dades del benchmark ODDS, predominantment numèrics, AnoLLM funciona al mateix nivell que els millors referents clàssics —no és clarament millor, només competitiu.
• La normalització de la NLL per columna per a les característiques de text és una decisió d'enginyeria petita però fonamental: sense ella, una descripció de transacció amb trenta tòquens dominaria la puntuació sobre un import de dues xifres, cosa que suposaria un biaix inductiu incorrecte.
• El context de la línia base d'entrenament: l'enfocament zero-shot de GPT-4 (arXiv:2406.16308) aconsegueix un AUROC mitjà de 74,1 a l'ODDS, comparable a ECOD (75,5) i KNN (70,7). L'avantatge d'AnoLLM es mostra específicament en conjunts de dades on les característiques de text i categòriques porten un senyal d'anomalia significatiu.

Què se sosté — i què no​

La idea central de la NLL és sòlida. Utilitzar un model de llenguatge ajustat com a estimador de densitat sobre files serialitzades és coherent, i gestiona de forma natural la distribució conjunta de totes les columnes simultàniament —cosa que els detectors no supervisats clàssics aplicats columna per columna no poden fer amb claredat. La solució a la predicció d'índexs és realment útil i la comparació amb la línia base zero-shot és justa.

El que em preocupa és la bretxa cost-benefici que l'article no reporta prou. AnoLLM requereix ajustar i servir un LLM per a la inferència —un compromís d'infraestructura substancial en comparació amb l'execució d'ECOD o IsolationForest en una CPU en segons. Al benchmark ODDS (purament numèric), AnoLLM només està "al mateix nivell", no és millor. Per tant, l'argument a favor d'AnoLLM es troba totalment en el règim de tipus mixt, on els sis conjunts de dades avaluats provenen de la detecció de frau a Kaggle. Sis conjunts de dades és una base empírica prima per a una recomanació forta, especialment perquè els conjunts de dades de Kaggle solen tenir esquemes nets, semàntica de columnes fixada i una veritat absoluta coneguda —totes coses de les quals les dades dels llibres majors de producció sovint manquen.

El problema de l'ordre de les columnes també queda obert. CausalTAD (arXiv:2602.07798) va identificar immediatament aquesta mancança: AnoLLM serialitza les columnes en un ordre arbitrari, ignorant les relacions causals entre els camps. Per a dades estructurades amb cadenes causals conegudes —el tipus de compte influeix en els rangs de transacció vàlids, que influeixen en la contrapart esperada— aquesta és una limitació real. CausalTAD planteja la reordenació com un problema d'ordenació lineal i reporta una millora constant respecte a AnoLLM en més de 30 conjunts de dades. Que aquesta bretxa existís i fos detectable tan ràpidament suggereix que el disseny de serialització d'AnoLLM no estava del tot madurat.

També hi ha una qüestió d'escala que l'article no aborda: amb quin volum d'exemples d'entrenament normals val la pena ajustar un LLM en lloc de, per exemple, un model de deep learning tabular entrenat directament sobre les característiques numèriques? Per a llibres majors de Beancount personals amb uns pocs milers d'entrades, el cost de computació pot superar fàcilment qualsevol guany en precisió.

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

Les entrades del llibre major de Beancount són exactament el tipus de dades de tipus mixt al qual s'adreça AnoLLM: imports (numèrics), noms de comptes (text estructurat), beneficiari/narració (text lliure), etiquetes (categòriques), dates (estructurades). Una sola fila com 2024-03-15 * "AWS" "Factura al núvol" Assets:Checking -2.400 USD codifica informació a través de tots aquests tipus simultàniament. Els detectors d'anomalies clàssics tenen dificultats aquí perquè necessiten un tractament separat per a cada tipus de columna, i perden les correlacions entre elles —el patró conjunt que indica que les factures d'"AWS" haurien d'estar en un rang determinat i afectar un compte específic.

L'enfocament NLL d'AnoLLM, en principi, aprendria aquests patrons conjunts a partir d'entrades històriques normals i marcaria desviacions en qualsevol combinació de columnes. Això és potencialment més útil que les proves estadístiques d'una sola columna o les regles fixes.

Dit això, la restricció de la comptabilitat de partida doble és un coneixement estructural que AnoLLM no pot aprendre només de les files serialitzades —els dèbits han de ser iguals als crèdits, s'han de respectar les jerarquies de comptes. Aquests invariants de domini són restriccions dures, no regularitats estadístiques, i cap quantitat d'ajust finit d'LLM en files històriques els farà complir de manera fiable si les dades d'entrenament contenen excepcions o artefactes d'arrodoniment. L'arquitectura adequada probablement combina la puntuació NLL d'AnoLLM per a anomalies semàntiques amb comprovacions de regles explícites per a les estructurals.

Què llegir a continuació​

• CausalTAD (arXiv:2602.07798) — millora directament AnoLLM injectant un ordre causal de les columnes; el seguiment més immediat per avaluar.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — proporciona l'avaluació sistemàtica multiparadigma que manca en els articles de mètodes individuals.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023) — el model BE-GREAT que AnoLLM utilitza com a línia base; entendre'l aclareix què millora realment AnoLLM més enllà de la predicció d'índexs.

L'article​

Figueroa, Grundmann, Freidank, Löser i Nejdl avaluen cinc models de pesos oberts d'uns 7B en un benchmark de dues tasques que anomenen LLMFinLiteracy. La Tasca 1 demana als models generar escenaris textuals que afectarien una ràtio de liquiditat determinada (corrent, prova del dret o de tresoreria) a partir d'un balanç trimestral real d'una de les cinc empreses de l'índex DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). La Tasca 2 demana als models traduir aquests escenaris en transaccions de Beancount compilables. El compilador de Beancount serveix com a verificador de sintaxi de referència; experts humans avaluen la correcció semàntica. L'article introdueix una taxonomia d'errors de 12 classes en les dues tasques i utilitza un prompt de cadena de pensament de 9 passos que inclou regles de comptabilitat per partida doble, un exemple d'entrada/sortida i el balanç real de l'empresa en format Beancount. Els models avaluats —Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B i CodeQwen-1.5-7B— es van executar de forma local a causa de la sensibilitat de les dades financeres. El corpus totalitza 1.500 mostres generades, amb 300 entrades estratificades avaluades per experts humans.

Idees clau​

• Només 7 dels 300 parells d'escenari-transacció avaluats (2,3%) van ser totalment correctes de principi a fi; fins i tot restringint-ho als tres models de propòsit general, la taxa només puja al 3,8%.
• Els dos millors models, Qwen-2-7B i Mistral-7B, produeixen escenaris correctes només el 21,67% i el 20,00% de les vegades, i transaccions que compilen correctament només el 16,67% i el 10,00% de les vegades.
• Els models especialitzats en codi (CodeLlama, CodeQwen) van obtenir un 0% en ambdues tasques; van respondre a la plantilla del prompt amb la cadena literal "Processat — Esperant la següent entrada", ignorant completament la tasca.
• La sintaxi no és el coll d'ampolla: cap model va produir ni un sol error de sintaxi. Els errors es troben totalment en el raonament comptable —els errors de balanç dominen en Qwen-2 (61,67%) i Llama-3 (38,33%), mentre que Mistral fa referència sobretot a comptes que no existeixen en el balanç proporcionat (45% d'errors de compte desconegut).
• Una fracció significativa de les transaccions que compilen correctament són semànticament errònies —el truc preferit del model és anomenar la reducció d'un passiu "vendre el teu deute", cosa que augmenta l'efectiu però per un motiu equivocat.
• El GPT-4o, utilitzat com a jutge automatitzat, no va detectar inconsistències en cap dels 10 escenaris sense sentit que se li van mostrar, confirmant que l'autoavaluació dels LLM no és un filtre de qualitat fiable per a resultats comptables.
• Els models copien en gran mesura l'exemple d'entrada/sortida del prompt en lloc de generalitzar: els 7 parells correctes s'assemblen molt a l'estructura de la transacció d'exemple proporcionada.

Què se sosté i què no​

La contribució empírica central de l'article és sòlida. El compilador de Beancount és un criteri de correcció objectiu i reproduïble, i l'ús de balanços reals d'empreses en lloc de dades de prova simplificades aporta validesa ecològica. La taxonomia jeràrquica d'errors està dissenyada amb criteri: aturar l'avaluació al primer error evita inflar el "crèdit parcial" per resultats sense sentit.

Dit això, hi ha limitacions òbvies que els autors reconeixen majoritàriament. Cinc models de pesos oberts d'uns 7B del 2023–2024 són una part petita del panorama de capacitats; el GPT-4o i el Claude van ser exclosos per motius de privadesa, cosa que és comprensible però significa que la xifra titular (2,3% de correcció) subestima la frontera tecnològica. Les fórmules de les ràtios financeres es van ometre deliberadament dels prompts per provar el coneixement inherent del domini —una elecció metodològicament interessant, però que fa que els resultats no siguin comparables a cap sistema que inclouria raonablement la documentació de les fórmules. I 300 mostres avaluades per humans entre cinc models, tres ràtios i cinc empreses és una xifra modesta; les cel·les per model i ràtio són massa petites (12 mostres) per treure conclusions sòlides sobre la variància.

La llacuna metodològica més interessant és l'absència de qualsevol protocol iteratiu o basat en el feedback. Res de crides a eines, ni autocorrecció, ni bucle de feedback amb el compilador —només generació d'un sol intent (one-shot). Atès que CRITIC (LOG-012) i treballs relacionats mostren que el refinament interactiu amb eines millora substancialment la precisió en tasques amb resultats verificables, un experiment amb el compilador de Beancount en el bucle hauria estat molt més informatiu sobre la viabilitat de desplegament.

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

Cada decisió de disseny per a l'agent d'escriptura de Bean Labs es basa en suposicions sobre què poden fer els LLM amb el DSL de Beancount. Aquest article és la primera àncora empírica. Les conclusions principals són alliçonadores, però també es poden interpretar de manera útil.

En primer lloc, els modes d'error són específics, no aleatoris. Els errors de balanç i els comptes desconeguts són els dos problemes dominants, i ambdós es poden abordar amb un bucle de feedback del compilador: el compilador de Beancount t'indica exactament quin compte és desconegut i si la transacció està quadrada. Una arquitectura d'agent que iteri sobre la sortida del compilador —en lloc de generar una vegada i aturar-se— hauria de superar substancialment els resultats d'un sol intent d'aquí. En segon lloc, la sintaxi és "gratuïta". Els models han après clarament la gramàtica superficial de Beancount; simplement no poden traduir de manera fiable la intenció financera en moviments de compte correctes. Aquesta distinció és clau per decidir on invertir en prompting i ajust fi (fine-tuning). En tercer lloc, la troballa que el GPT-4o no pot avaluar la qualitat comptable automàticament puja el llistó per a qualsevol sistema de verificació automatitzat: necessites el compilador, a més de comprovacions puntuals d'experts en el domini, no un LLM com a crític.

L'article també confirma una cosa que sospitava del treball de detecció d'anomalies (LOG-049): els LLM que operen sobre transaccions financeres compilen i envien amb massa facilitat. La categoria "Incorrecte | Compila" —transaccions que passen la verificació sintàctica però són semànticament errònies— és exactament el mode d'error que un sistema de seguretat d'escriptura ha de detectar. Una transacció pot quadrar perfectament i tot i així comptabilitzar ingressos com una disminució del passiu, cosa que passaria desapercebuda per a qualsevol verificació purament sintàctica.

Què llegir a continuació​

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — puntuació d'anomalies basada en la probabilitat com a alternativa a l'enfocament de detecció per lots; es combina naturalment amb un senyal del compilador de Beancount per marcar entrades estructuralment vàlides però estadísticament anòmales.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — desvia decisions de baixa confiança cap a un model més gran o cap a un humà; aborda directament la qüestió de quan un agent d'escriptura de Beancount hauria de recórrer a la revisió humana en lloc de continuar després d'un bucle de feedback del compilador.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — el treball existent més rellevant per construir un agent de correcció amb compilador en el bucle sobre l'arquitectura que avalua aquest article.