Perché i LLM aziendali falliscono prima ancora di calcolare, e cosa cambia l’ingegneria del contesto

Perché i LLM aziendali falliscono prima ancora di calcolare, e cosa cambia l’ingegneria del contesto
4 min di lettura

Quando un sistema di IA aziendale fornisce una risposta inaffidabile, la diagnosi abituale punta il dito contro il modello. Tuttavia, secondo l’articolo di riferimento, un fallimento più frequente e più difficile da individuare risiede altrove: un grande modello linguistico (LLM) può ragionare correttamente partendo da un contesto selezionato male.

  • Un LLM può fallire anche quando ragiona correttamente.
  • L’errore nasce spesso da un contesto selezionato male.
  • Una domanda ambigua può produrre una cifra falsa ma plausibile.
  • Il sistema deve chiarire il perimetro e garantire la tracciabilità dei risultati.

I rimedi più comuni sono un modello più potente, un prompt più lungo, più documenti recuperati o una finestra di contesto più ampia, cioè la quantità di informazioni che un modello può elaborare in una volta. Ciascuno può aiutare, ma nessuno risolve direttamente questo problema. Nei sistemi analitici, il calcolo può essere corretto e la spiegazione coerente, e la risposta restare sbagliata: il sistema ha scelto le prove sbagliate, seguito un collegamento errato tra tabelle o dato a un termine aziendale ambiguo una definizione che l’utente non aveva in mente. L’errore interviene prima di qualsiasi calcolo.

Prendiamo una domanda semplice: quante ore lavora Cam in media al giorno? La parola « giorno » non è definita. Può designare ogni giorno di calendario del periodo, un anno di lavoro standardizzato, ogni registrazione di pianificazione o ogni data in cui Cam ha effettivamente lavorato. Dividere il totale delle ore per i giorni di calendario dà una media più bassa che dividerlo per i giorni effettivamente lavorati non appena Cam ha dei giorni di riposo. Un controllo classico, che verifica che i totali si incrocino, non rileva necessariamente questa cattiva scelta del denominatore.

Una domanda aziendale, un programma di analisi

La domanda « Quale marca ha migliorato la fiducia questo trimestre? » sembra una semplice ricerca. Rispondervi presuppone però di risolvere diversi punti: quale domanda del questionario misura la fiducia, quali ondate di indagine formano « questo trimestre », qual è il perimetro dei rispondenti, se i risultati sono ponderati e cosa conta come un miglioramento.

L’articolo prende un caso illustrativo. Due tabelle incrociate sembrano corrispondere alla richiesta, con una descrizione che differisce solo di poche parole. La prima, ponderata, riguarda l’insieme dei rispondenti e mostra un leggero aumento. La seconda, non ponderata, riguarda solo i rispondenti che conoscono la marca e mostra una leggera diminuzione. Uno strumento di ricerca basato sulla similarità le classificherebbe quasi alla pari. Un sistema che sceglie il primo risultato fornisce una risposta documentata e argomentata, che può essere falsa, senza che la scelta effettuata appaia nel risultato finale. Un sistema basato su un percorso, invece, rileva la differenza di popolazione e di ponderazione e chiede all’utente quale perimetro considerare. Il costo di questa domanda di chiarimento è, secondo l’autore, di gran lunga inferiore a quello di una cifra falsa che assomiglia a quella giusta.

Benchmark che misurano sistemi

Le ricerche vanno nella stessa direzione. Spider 2.0, un benchmark aziendale text-to-SQL composto da 632 problemi provenienti da flussi di lavoro reali, è stato pubblicato alla fine del 2024. Il suo sistema più performante, un agente costruito su o1-preview, ha risolto circa il 17% dei compiti, contro circa il 91% per i migliori sistemi sul benchmark originale Spider. La classifica è poi evoluta: la sua traccia Snow mostra un punteggio del 96,7%, inviato da un editore, proveniente da un sistema di agente. I punteggi sono inviati dalle squadre stesse, e l’articolo nota che i migliori risultati si basano su sistemi progettati attorno al modello piuttosto che su modelli da soli.

Allungare il contesto non basta neanche. Uno studio di Chroma, intitolato « Context Rot », rileva che i modelli diventano meno affidabili man mano che la lunghezza dell’input aumenta, anche su compiti semplici, e che dei distrattori di aspetto simile aggravano il problema.

Un percorso piuttosto che un mucchio

Di fronte all’incertezza, il riflesso consiste nel fornire più informazioni al modello. Ma questo può moltiplicare le interpretazioni concorrenti. L’approccio descritto consiste nell’organizzare il contesto in modo sequenziale: prima l’intenzione dello studio, poi la struttura del questionario, le domande e le loro definizioni, i segmenti, i mercati, le ondate e le regole di ponderazione, e infine la tabella incrociata che contiene la prova. Ogni livello eredita i vincoli di quello che lo precede.

Anthropic presenta l’ingegneria del contesto come il seguito naturale dell’ingegneria del prompt, definendola come la gestione dell’intero contesto di un agente, considerato una risorsa finita. L’articolo ritiene questa cornice pertinente, ma la colloca un passo a monte: si tratta di sapere cosa significa la domanda e quali prove possono rispondervi. Per il caso della fiducia nella marca, la procedura segue cinque fasi: risolvere l’intenzione, applicare le regole dello studio, identificare le fonti, convalidare il percorso, poi calcolare con uno strumento autorizzato e presentare il risultato con la sua definizione, la sua base di rispondenti, la sua ponderazione e la sua fonte.

L’autore insiste infine sulla tracciabilità. Ogni risultato deve poter essere collegato alla sua tabella sorgente, alla sua definizione, ai suoi filtri, alla sua ponderazione, al suo periodo e al calcolo utilizzato.

S’abonner
Notification pour
guest

0 Commentaires
Le plus ancien
Le plus récent Le plus populaire
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x