Il modello rifiuta di leggere documenti: test su tre provider
Test del contesto: zero risposte corrette. Non era un problema di memoria, ma content_filter per ogni documento oltre ~2000 token su AWS, API dirette e Google.
👁 115 letture
Ho preparato un test del contesto dei modelli: un documento con informazioni nascoste, domande su di esse, verifica di quante il modello ne trovasse. Il risultato è stato zero, quindi per un momento ho pensato che il modello avesse una memoria debole. Dopo aver esaminato la risposta grezza dell’API, si è scoperto che il modello non aveva letto nemmeno una parola - l’input era stato rifiutato dalla moderazione ed era tornato con content_filter e native_finish_reason: refusal.
Conclusione in un paragrafo
Zero risposte corrette in un test di memoria non è sempre prova di un contesto breve. Nel mio test il modello restituiva content_filter e native_finish_reason: refusal per OGNI documento oltre circa 2000 token, e questo su tre provider indipendenti - AWS, API del produttore e Google. Il rifiuto riguardava anche un testo sulle piante, in cui non c’erano contenuti tecnici, nomi di strumenti o nulla che potesse essere considerato sensibile. Quando ho sostituito con un modello alternativo sullo stesso materiale e con le stesse domande, ha trovato 6 su 6 informazioni nascoste in 2,3-4,9 s. Quindi il compito era fattibile, e il risultato precedente misurava la moderazione, non la memoria.
Come era strutturato il test del contesto
Lo schema era semplice e volutamente noioso. Prendevo un documento, inserivo sei informazioni specifiche in punti diversi - all’inizio, al centro, verso la fine - e poi facevo sei domande, una per ogni informazione nascosta. Contavo le risposte corrette e il tempo di risposta. Nient’altro.
Il materiale di test partiva da una versione breve e scalavo verso l’alto. Questo è importante, perché proprio questa procedura ha permesso di vedere dove si trova il limite. Sotto circa 2000 token le risposte arrivavano normalmente. Sopra - content_filter, ogni volta, senza eccezioni.
Per escludere il contenuto come causa, ho sostituito il documento con un testo sulle piante. Zero terminologia tecnica, zero codice, zero qualsiasi cosa controversa. Rifiuto identico.
Tre provider, stesso limite di contesto AI
Il primo pensiero quando si riceve un rifiuto è di solito: qualcosa nella configurazione di questo specifico endpoint. Per questo ho ripetuto il test su tre percorsi di accesso indipendenti - AWS, direttamente dal produttore del modello e Google. Sono infrastrutture separate, pannelli separati, impostazioni di sicurezza separate. Il comportamento era lo stesso.
Questo per me è l’elemento più forte dell’intera misurazione. Se il problema fosse stato nel mio codice o in una soglia di moderazione configurata male, non si sarebbe ripetuto su tre piattaforme contemporaneamente.
| Elemento | Prima della diagnosi (modello che rifiuta) | Dopo la sostituzione (modello alternativo) |
|---|---|---|
| Risposte corrette su informazioni nascoste | 0 - nessuna risposta nel merito | 6 su 6 |
| Tempo di risposta | non applicabile - rifiuto | 2,3-4,9 s |
| Status restituito | content_filter, native_finish_reason: refusal |
completamento normale |
| Soglie di rifiuto | ogni documento oltre ~2000 token | nessuna |
| Testo sulle piante | rifiuto | elaborato |
| Numero di provider con questo comportamento | 3 su 3 (AWS, produttore, Google) | 0 |
Perché “il modello rifiuta di rispondere” si confonde facilmente con memoria debole
La maggior parte delle librerie client e dei wrapper mostra un contenuto di risposta vuoto o un breve messaggio sostitutivo. Il codice del motivo di completamento è spesso nascosto un campo più in profondità e nessuno lo guarda, se lo script di test si limita a contare le risposte corrette. In questa configurazione una stringa vuota appare esattamente come “il modello non ha trovato l’informazione”.
L’effetto è insidioso, perché un risultato zero si adatta all’ipotesi intuitiva. Ci aspettiamo che un documento lungo sovraccarichi la memoria, quindi un fallimento su un documento lungo sembra una conferma. E stiamo misurando qualcosa di completamente diverso: se il materiale è passato attraverso il filtro di input.
Questa è la mia opinione, ma penso che parte dei confronti pubblicati sul “limite di contesto AI” misurino proprio la moderazione. Non ho dati su questo oltre alla mia misurazione, quindi lo tratto esclusivamente come ipotesi, non come fatto accertato.
Cosa è cambiato concretamente dopo la sostituzione del modello
Dopo il cambio a un altro modello non ho toccato nient’altro. Stesso documento, stesse sei domande, stesso ordine, stessa infrastruttura. Risposte corrette: 6 su 6. Tempi: da 2,3 a 4,9 s, a seconda di quanto in profondità nel documento si trovasse l’informazione cercata.
Anche la variazione 2,3-4,9 s è un’informazione. Mostra che il modello passa effettivamente attraverso il materiale, e non risponde dalla memoria di un pattern. Se rispondesse con generalità, i tempi sarebbero più uniformi.
La cosa più importante: dato che il secondo modello ha completato il compito interamente, il compito era fattibile. Lo zero precedente non era una valutazione della difficoltà del test.
Quando sospettare la moderazione e non il contesto
Dalla mia misurazione emergono diversi segnali di allarme. Primo: il risultato non si degrada gradualmente, ma cade bruscamente. Un vero problema di memoria di solito dà una transizione morbida - prima si perde un’informazione, poi un’altra. Il filtro di input si attiva in modo binario.
Secondo segnale: il limite cade a un valore tondo e basso. Circa 2000 token è decisamente troppo poco per parlare di esaurimento della finestra di contesto di qualsiasi modello contemporaneo. Se il risultato crolla così presto, quasi certamente non è il contesto il colpevole.
Terzo: rifiuto per contenuti sicuri. Il testo sulle piante è un buon materiale di controllo proprio perché non c’è nulla da bloccare. Se anche questo torna con un rifiuto, la causa sta nel volume o nella configurazione, non nel tema.
Come verificarlo tu stesso
- Registra le risposte grezze complete dell’API, non solo il campo con il contenuto. Ti interessano i codici del motivo di completamento - nel mio caso erano
content_filterenative_finish_reason: refusal. - Prepara un documento con sei informazioni nascoste distribuite dall’inizio alla fine del testo. Annota dove esattamente si trova ciascuna.
- Esegui il test su una versione breve, decisamente sotto i 2000 token. Questo è il tuo punto di riferimento - se non funziona qui, il problema è nel prompt, non nella lunghezza.
- Aumenta il volume del documento a salti e annota a quale valore appare il primo rifiuto. Se il limite cade nettamente, e non gradualmente, pensa a un filtro.
- Sostituisci con materiale tematicamente neutro - nel mio caso era un testo sulle piante. Se anche questo torna con un rifiuto, il contenuto non è la causa.
- Ripeti su un secondo e terzo provider. Io ho verificato AWS, API del produttore e Google. La concordanza del comportamento su tre piattaforme esclude un errore di configurazione locale.
- Sostituisci il modello con un altro, senza cambiare nient’altro. Se trova tutte e sei le informazioni, hai la prova che il test era fattibile, e lo zero precedente misurava qualcos’altro.
- Registra i tempi di risposta separatamente per ogni domanda. La variazione - nel mio caso 2,3-4,9 s - conferma che il modello effettivamente cerca nel materiale.
Da dove vengono questi numeri
Tutti i valori provengono dalla mia misurazione eseguita prima del 21.09.2026. Ho testato un modello attraverso tre percorsi di accesso indipendenti: AWS, API dirette del produttore e Google. Materiale di test: documento con sei informazioni nascoste, scalato per volume, più una versione di controllo sulle piante senza contenuti tecnici. I rifiuti con codici content_filter e native_finish_reason: refusal si sono verificati per ogni documento oltre circa 2000 token su tutti e tre i provider. Il modello alternativo sullo stesso set di compiti ha trovato 6 su 6 informazioni nascoste in 2,3-4,9 s. Non fornisco i nomi dei modelli né le soglie esatte di moderazione, perché non ho conferma che le impostazioni lato provider siano rimaste invariate dopo la data della misurazione. I frammenti contrassegnati come opinione sono le mie conclusioni, non risultati della misurazione.
More on this from NITIDO
magazine·PNG trasparenti con Qwen-Image-2.1: test del canale alfa22,7% di pixel completamente trasparenti e gamma alfa 0-255. Come richiedere la trasparenza e cosa controllare nelle immagini normali.