Quando un sistema RAG dà una risposta sbagliata o solo parzialmente corretta, il modello di solito non è la causa. È il chunking. Se il passaggio che contiene la risposta non finisce mai nel contesto recuperato, nessun modello può rispondere partendo da esso, e nessuna quantità di prompt tuning cambia questo fatto. Il chunking decide cosa può essere recuperato in assoluto, il che lo rende la prima cosa da ispezionare e l'ultima che la maggior parte dei team guarda.

Amazon Bedrock Knowledge Bases ti permette di scegliere una strategia di chunking quando crei una data source. Quella singola scelta imposta silenziosamente il tetto della tua qualità di retrieval. Sbagliala e passerai settimane a incolpare il modello di embedding, il reranker o l'LLM per un problema che vive nel modo in cui tagli i documenti.

Perché il chunking è la decisione portante

Il retrieval lavora su chunk, non su documenti. Ogni chunk viene incorporato in un vettore, e al momento della query recuperi i top-k chunk più vicini alla domanda. Due modalità di fallimento derivano direttamente dalla dimensione dei chunk.

I chunk troppo grandi diluiscono l'embedding. Un chunk da 2000 token che copre quattro sottotemi produce un vettore che è la media di tutti e quattro, quindi corrisponde a tutto debolmente e a niente fortemente. Il chunk giusto viene sepolto sotto quasi-corrispondenze. I chunk troppo piccoli spezzano il contesto. Una definizione separata dal suo esempio, o un passaggio separato dal suo avviso, viene recuperata in modo pulito ma arriva senza il testo circostante che la rendeva utile. La risposta è tecnicamente presente e praticamente incompleta.

Il compito di una strategia di chunking è tagliare su confini significativi in modo che ogni chunk sia un'idea coerente, sufficientemente autonoma da poter rispondere e sufficientemente specifica da poter essere classificata.

Le tre strategie che Bedrock ti offre

Chunking a dimensione fissa

Divide ogni N token con una certa sovrapposizione. È il default e il più economico, ed è adatto per contenuti uniformi e ricchi di prosa dove i cambi di argomento sono graduali. È attivamente negativo per documenti strutturati, perché taglia ovunque atterri il contatore di token: a metà tabella, a metà lista, tra un titolo e il paragrafo che introduce. La sovrapposizione attenua il danno ma non lo elimina. Usa il fisso quando il tuo corpus è omogeneo e vuoi una baseline, non perché è il default.

Chunking semantico

Divide per significato. Il chunking semantico misura la similarità di embedding tra frasi adiacenti e avvia un nuovo chunk dove l'argomento cambia, quindi i confini cadono tra le idee invece che a un conteggio fisso di token. Questo è il default giusto per contenuti misti: FAQ, articoli della knowledge base, prosa mista dove ogni risposta o concetto vuole rimanere intero. Costa di più costruire l'indice perché incorpora mentre suddivide, ma la differenza di qualità del retrieval su corpus eterogenei è il motivo per cui vale la pena pagarlo.

Chunking gerarchico

Costruisce chunk genitore e figlio. I piccoli chunk figlio vengono incorporati e abbinati per un retrieval preciso, ma il chunk genitore più grande è quello che viene restituito al modello, quindi classifichi in base alla specificità e rispondi con il contesto. Questo si adatta a documenti con struttura reale, manuali tecnici, contratti legali, qualsiasi cosa con sezioni e sottosezioni, dove una query colpisce una clausola ristretta ma il modello ha bisogno della sezione circostante per usarla correttamente. È il più complesso da ragionare e la scelta migliore quando i tuoi documenti hanno una gerarchia genuina da sfruttare.

Valuta il retrieval prima di incolpare il modello

L'abitudine più utile in assoluto è separare la domanda sul retrieval dalla domanda sulla generazione. Prima di toccare il prompt o cambiare il modello, chiediti una cosa sola: per un insieme di domande reali, il chunk che contiene la risposta è comparso nel contesto recuperato?

  • Costruisci un piccolo set di valutazione: da 30 a 50 domande reali, ciascuna con il passaggio sorgente che vi risponde.
  • Esegui solo il retrieval. Per ogni domanda, controlla se il passaggio corretto appare nei top-k risultati. Quel tasso di successo è il tuo tetto di retrieval.
  • Se il passaggio corretto non viene recuperato, la qualità della generazione è irrilevante. La correzione è il chunking, gli embedding o il top-k, non il modello.
  • Solo una volta che il retrieval fa emergere in modo affidabile il passaggio giusto ha senso lavorare su come il modello lo usa.

La maggior parte dei team salta questo passaggio e va dritta al prompt engineering, motivo per cui passano tanto tempo su un problema che una misurazione del tasso di successo del retrieval avrebbe localizzato in un pomeriggio. Se il retrieval manca la risposta metà delle volte, hai un problema di chunking travestito da modello.

Un punto di partenza pratico

Inizia con il chunking semantico per contenuti di conoscenza generale, passa al gerarchico quando i tuoi documenti hanno una struttura chiara a sezioni e le risposte dipendono dal contesto circostante, e mantieni il fisso solo per prosa uniforme e voluminosa dove vuoi velocità e semplicità. Poi misura il tasso di successo del retrieval, cambia una variabile e misura di nuovo. Il chunking non è un valore di configurazione da impostare e dimenticare. È la manopola con più influenza su se il tuo sistema RAG sia buono o no.

Il punto chiave

La qualità del RAG si decide prima ancora che il modello venga eseguito, nel momento in cui tagli i tuoi documenti in chunk. Il fisso è una baseline, il semantico è il default sensato per contenuti misti, e il gerarchico vince quando la struttura conta. Misura il tasso di successo del retrieval su un set di domande reali per primo, perché se la risposta non entra mai nel contesto, il modello non è mai stato il problema.

Leggi questo dopo

Per il lato storage e infrastruttura di eseguire la ricerca vettoriale su larga scala, le field notes cloud sono su ercan.cloud, e l'hub è su ercanermis.com.