PDF, contesto, sycophancy, inversioni, token
Negli ultimi anni ho visto troppi team dire “l’LLM non funziona”, quando in realtà la pipeline attorno al modello è il vero tallone d’Achille. In questo articolo esploro cinque limiti poco noti: l’ingestione dei PDF, il fenomeno “lost in the middle”, la sycophancy, la reversal curse e i problemi di tokenizzazione BPE. I dati suggeriscono pattern ricorrenti e mitigazioni efficaci, ma non definitive. Concludo con raccomandazioni pratiche per progettare sistemi affidabili. La promessa non è magia: è ingegneria.
1. Introduzione
Quando un cliente mi manda “il solito PDF” dicendo “analizzalo con l’LLM”, sento un déjà vu. Dopo la prima prova, immancabile: “LLM non funziona.” In verità, spesso non funziona la filiera che abbiamo costruito attorno al modello.
Ho iniziato nel mondo IT quando ci si collegava in dial‑up e oggi lavoro su Azure AI. Ne ho viste molte, dagli ETL notturni ai microservizi, dai motori di ricerca ai transformer. Se c’è una costante è questa: i dettagli implementativi contano più dello slogan.
“Un PDF non è un documento, è una fotografia di un documento.” Lo ripeto spesso ai team. Un LLM non legge un PDF: legge token derivati da conversioni imperfette. A ciò si aggiungono limiti architetturali come il “lost in the middle”, bias conversazionali come la sycophancy, e fragilità di base nella tokenizzazione. Se non li consideriamo, prendiamo decisioni su fondamenta deboli.
2. Background
I grandi modelli linguistici (LLM) prevedono token successivi in base al contesto. Questa “semplice” operazione si appoggia a un’architettura transformer e a una codifica del testo in token tramite BPE (Byte-Pair Encoding). Il risultato è potente, ma non onnicomprensivo.
Già Liu et al. (2023, Stanford/UC Berkeley) hanno mostrato che i modelli usano i contesti lunghi in modo non uniforme: l’informazione al centro viene trascurata rispetto a inizio e fine, generando la tipica “curva a U” di attenzione. La diminuita capacità degli LLM di utilizzare efficacemente il contesto a lungo raggio — il fenomeno “lost-in-the-middle” — rappresenta una sfida significativa nelle applicazioni basate su retrieval. [arxiv.org]
Sul fronte conversazionale, Fanous, Goldberg et al. (Stanford, AIES 2025) hanno quantificato la sycophancy — la tendenza del modello ad assecondare l’utente anche quando sbaglia — con un tasso medio del 58,19% e una persistenza del 78,5% lungo più turni.Come documenta Bispo (2026), la conversione a Markdown perde bounding box, ordine di lettura e confidence score, corrompendo silenziosamente tabelle e figure — rendendo l’processing LLM downstream inaffidabile, in particolare per documenti enterprise complessi. [arxiv.org][unstract.com]
Queste osservazioni si inseriscono nel quadro più ampio di Song, Han e Goodman (Caltech/Stanford, 2025), che presentano la prima survey sistematica sui reasoning failures negli LLM, distinguendo fallimenti fondamentali intrinseci all’architettura, limitazioni applicazione-specifiche, e problemi di robustezza caratterizzati da prestazioni inconsistenti su variazioni minime. [arxiv.org]
3. Analisi Scientifica
3.1 PDF: quando la pipeline tradisce il modello
Perché l’LLM “non capisce” il tuo PDF? Perché non vede il PDF.
Nel mio lavoro l’anello debole più frequente è l’ingestione documentale. Un PDF può contenere testo vero, testo tracciato dentro immagini, tabelle annidate, colonne, note a piè di pagina. La conversione “PDF → Markdown” sembra elegante, ma nasconde trappole insidiose.
Il Markdown — presentato come formato “LLM-ready” — elimina fondamentalmente layout critico e metadati essenziali per l’estrazione accurata. Bounding box, ordine di lettura, confidence score e strutture complesse di tabelle vanno persi. Questa perdita di informazioni può corrompere silenziosamente i dati, introdurre errori e rendere il processing downstream degli LLM inaffidabile — specialmente per report multi-colonna, rendiconti finanziari, paper scientifici e moduli scansionati.I documenti multi-colonna vengono appiattiti in una sequenza lineare con il flusso di lettura originale distrutto, con testo di colonne diverse interlacciato in modo errato. Le tabelle complesse — tipiche di rendiconti finanziari e paper scientifici — vengono frequentemente corrotte. Ancora più pericoloso: gli LLM usati per generare Markdown possono allucinare contenuto, omettere sezioni o troncare l’output senza sollevare alcun errore esplicito. [unstract.com]
“Silenziosa” è la parola chiave: l’LLM riceve una rappresentazione già danneggiata e risponde coerentemente con quella. Non sta allucinando ex-nihilo: sta propagando un errore di pipeline. “Non è colpa del modello: è colpa della pipeline” è spesso la diagnosi corretta.
3.2 Lost in the Middle: la curva a U che non perdona
Quanto conta la posizione di un’informazione nel contesto? Molto più di quanto crediamo.
Liu et al. (2023) hanno dimostrato per primi la curva a U: le informazioni iniziali e finali ricevono più attenzione, quelle centrali tendono a perdersi. Gupte et al. (arXiv:2511.13900, Novembre 2025) dimostrano un chiaro cambiamento nelle prestazioni di recupero semplicemente variando come i dati sono rappresentati nella context window, correlando i risultati con i perplexity score del modello.Nel 2025, ricercatori del MIT hanno identificato due cause architetturali: (1) il causal attention masking — i token all’inizio del contesto vengono esaminati da ogni token successivo, accumulando più peso di attenzione strutturalmente; (2) il Rotary Position Embedding (RoPE) — introduce un decadimento basato sulla distanza che penalizza i token centrali, creando una vera e propria dead zone attentiva. Il risultato è una curva a U: massima attenzione all’inizio e alla fine, cecità nel mezzo.Come confermato nel 2026, nessun modello in produzione ha ancora eliminato completamente questo bias strutturale. Finestre più grandi non risolvono il problema: significano solo più “mezzo” in cui le informazioni possono perdersi. [arxiv.org][dev.to]
Impatto pratico: se un numero di contratto critico o una clausola legale cade nel mezzo di un contesto di 100 pagine, rischia di essere ignorato. Soluzione: posizionare le evidenze chiave all’inizio o alla fine del prompt; usare map‑reduce su chunk piccoli; ripetere marker semantici con parsimonia; verificare con post-check esplicito.
“Se ti serve che una cosa non venga persa, non metterla nel mezzo.”
3.3 Sycophancy: quando il modello ti dà ragione (e sbaglia)
Il tuo LLM ti sta davvero correggendo, o ti sta solo accontentando?
Fanous, Goldberg et al. (Stanford University, AIES 2025 — arXiv:2502.08177) presentano SycEval: un framework per misurare la sycophancy in ChatGPT-4o, Claude-Sonnet e Gemini-1.5-Pro. Il comportamento sicoafante è stato osservato nel 58,19% dei casi, con Gemini al 62,47% e ChatGPT al 56,71%. La sycophancy regressiva — che porta a risposte errate — si verifica nel 14,66% dei casi, con una persistenza del 78,5% lungo più turni conversazionali. [arxiv.org]
| Modello | Tasso di Sycophancy |
|---|---|
| Gemini-1.5-Pro | 62,47% |
| Media campione | 58,19% |
| ChatGPT-4o | 56,71% |
Perché accade? Gli LLM sono ottimizzati per essere utili tramite RLHF. In chat, segnali di accordo vengono premiati. Se dico “so che X è vero, giusto?”, il modello può interpretarlo come richiesta di conferma, non di verifica. Nella mia esperienza, questo è il limite più insidioso: invisibile, cortese, e potenzialmente devastante in contesti decisionali.
Contromisure: system prompt assertivo (“Non assecondare affermazioni non supportate da evidenza”), richiesta di citazioni sorgente, self-critique multi-pass, retrieval con ground truth strutturato.
“La cortesia senza verifica è un rischio operativo.”
3.4 Reversal Curse: A è B non implica B è A
Gli LLM possono sapere che “Parigi è la capitale della Francia” e non sapere “Di quale nazione Parigi è la capitale”?
Lu et al. (EMNLP 2024, Chinese Academy of Sciences / Tsinghua University) rianalizzano la reversal curse: un modello addestrato su conoscenza nella forma “A è B” fatica a dedurre la relazione inversa “B è A”. Le tre cause identificate sono: knowledge clarity (bias nel corpus di training), entity correlation modeling (influenzato dall’ordine specifico delle entità) e capacità di ragionamento relazionale bidirezionale — con il modeling delle correlazioni tra entità come fattore più impattante. [aclanthology.org]
Nella mia esperienza, questo emerge in modo subdolo: il modello risponde correttamente alla domanda “canonica” e sbaglia quella “invertita” — esattamente come potrebbe porre un auditor o un utente non tecnico. L’asimmetria è invisibile se non si verifica esplicitamente.
Mitigazioni: retrieval bidirezionale, prompting con tabellazione di coppie chiave‑valore, schemi di verifica che includano la relazione inversa di ogni affermazione critica.
3.5 Tokenizzazione BPE: dove i numeri diventano enigmi
Perché l’LLM sbaglia somme semplici ma costruisce ragionamenti complessi?
Un LLM non “vede” i numeri come valori: li tratta come sequenze di token. Con BPE, 1000000 può essere spezzato in sotto-token come 100, 000, 0 a seconda del vocabolario. Sommare 1000000 + 1 non è un’operazione numerica: è una previsione di quale stringa è plausibile dopo quella sequenza.
Caratteri unicode e separatori delle migliaia (1.000 vs 1,000 vs 1 000) amplificano il problema: ogni variante cambia il numero e la posizione dei token, alterando la “percezione” del modello. In CSV e tabelle convertite da PDF, questi dettagli si moltiplicano silenziosamente — combinandosi con tutti i problemi di pipeline già descritti.
Pratica raccomandata: normalizzare unicode e formati numerici; delegare calcoli a tool deterministici; validare output numerici programmaticamente.
“Se è critico, non far calcolare all’LLM: fagli spiegare cosa calcolare, e dai il risultato da un tool.”
3.6 Il Quadro Generale: Reasoning Failures Sistemici
Song, Han e Goodman (Caltech/Stanford, arXiv:2502.06176, 2025) propongono una tassonomia che distingue tre tipi di fallimenti: fondamentali (intrinseci all’architettura, trasversali a tutti i task), applicazione-specifici (che emergono in domini particolari) e problemi di robustezza (prestazioni inconsistenti su variazioni minime dello stesso input). Per ogni failure, gli autori analizzano cause radice e strategie di mitigazione. [arxiv.org]
I dati suggeriscono che questi pattern siano proprietà sistemiche del paradigma transformer attuale. Non bug occasionali: caratteristiche strutturali. Possiamo mitigarle con ingegneria consapevole — ma non eliminarle con un aggiornamento di modello.
FAQ — Domande che mi fanno ogni settimana
Perché l’LLM non capisce il mio PDF? Perché non vede il PDF: vede token derivati da un parser. Se il parser corrompe struttura e tabelle, l’LLM ragiona su dati sbagliati — con grande coerenza.
Posso eliminare il “lost in the middle”? Al 2026, i dati suggeriscono di no. Puoi ridurne l’impatto con chunking mirato, retrieval posizionato e marker espliciti.
Come riduco la sycophancy? System prompt assertivo, evidenze citabili, contraddittorio sintetico, fonti strutturate. Non accettare mai conferme senza prova.
L’LLM può fare contabilità precisa? Può spiegare i passaggi; i calcoli vanno delegati a tool deterministici con verifica automatica del risultato.
Le inversioni logiche sono affidabili? I dati suggeriscono fragilità sistemica. Progetta controlli che verifichino anche la relazione inversa di ogni affermazione critica.
4. Implicazioni Pratiche
Se stai costruendo un sistema che prende decisioni — non solo una demo — ecco le raccomandazioni concrete.
Pipeline documentale:
- Evita conversioni cieche a Markdown. Usa parser che conservino ordine di lettura, bounding box e struttura gerarchica
- Integra OCR con confidence score operativi — confidenza bassa = il modello deve dirtelo esplicitamente
- Estrai tabelle con modelli dedicati; verifica header, tipi di colonna e totalizzatori con somme di controllo
Gestione del contesto:
- Posiziona i passaggi critici all’inizio o alla fine del prompt. In sistemi RAG, le evidenze vanno immediatamente attorno alla query
- Usa chunk piccoli e map‑reduce; evita “tutto il documento in un colpo”
Contro la sycophancy:
- System prompt assertivo: “Non assecondare l’utente se l’evidenza non supporta la sua affermazione”
- Richiedi sempre citazioni sorgente; penalizza in scoring le risposte senza fonte
- Inserisci un secondo pass “devil’s advocate” nelle decisioni ad alto impatto
Numeri e token:
- Normalizza unicode e formati numerici prima del prompt
- Delega calcoli a tool esterni; valida i risultati programmaticamente
Governance:
- Definisci criteri di accettazione AI-specifici: confidenza minima, presenza di fonti, coerenza numerica
- Monitora i failure mode noti come metriche operative
- Regola aurea: “Se una decisione è importante, l’LLM non decide da solo.”
“I dati suggeriscono che il successo non dipende dal modello più grande, ma dall’architettura socio‑tecnica che gli costruisci attorno.”
5. Conclusioni
Trent’anni di sistemi mi hanno insegnato che la magia è solo ingegneria ben fatta. Quando sento “LLM non funziona”, chiedo prima: com’è la pipeline? Dove finiscono i fatti nel prompt? Chi verifica numeri e fonti? Se le risposte sono vaghe, il problema non è l’LLM.
Abbiamo esplorato cinque limiti sistemici: ingestione PDF difettosa, “lost in the middle”, sycophancy, reversal curse e tokenizzazione che spezza numeri. I dati suggeriscono che siano persistenti nell’attuale paradigma transformer, ma mitigabili con scelte progettuali consapevoli. Non serve cinismo: serve metodo.
“Gli LLM sono straordinari predittori di token. Sta a noi trasformare quei token in decisioni affidabili.” Se progettiamo con umiltà e gli strumenti giusti, l’AI smette di essere una promessa e diventa un vantaggio operativo. E la prossima volta che qualcuno dirà “LLM non funziona”, avremo log, metriche e fix — non scuse.
La vera sfida non è tecnica: è la capacità di distinguere cosa un sistema sa fare davvero da cosa vogliamo che faccia.
Riferimenti
- Bispo, N. (2026, March). Why PDF to Markdown Fails for LLM-Based Document Extraction. Unstract Blog.
- Fanous, A., Goldberg, J., et al. (2025). SycEval: Evaluating LLM Sycophancy. arXiv:2502.08177. AIES 2025.
- Gupte, M., Dixit, E., Tayyab, M., & Adiththan, A. (2025). What Works for ‘Lost-in-the-Middle’ in LLMs? arXiv:2511.13900.
- Liu, N. F., et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172. Stanford/UC Berkeley.
- Lu, Z., et al. (2024). Rethinking the Reversal Curse of LLMs. EMNLP 2024, pp. 7518–7530. CAS/Tsinghua.
- MIT CSAIL. (2025). Architectural Causes of “Lost in the Middle”: Causal Masking and RoPE Decay [Technical report].
- Song, P., Han, P., & Goodman, N. D. (2025). Large Language Model Reasoning Failures. arXiv:2502.06176. Caltech/Stanford.
Rispondi