collection Qdrant
Il problema non è aggiungere documenti. È aggiungerli nel posto sbagliato
Quando si costruisce un sistema RAG, cioè un’applicazione in cui una LLM risponde usando documenti recuperati da un database vettoriale, la tentazione iniziale è quasi sempre la stessa: creare una collection Qdrant, caricare tutto lì dentro e lasciare che il modello trovi la risposta migliore.
All’inizio funziona.
La knowledge base è piccola, i documenti sono coerenti tra loro, il dominio è limitato. Poi arriva il momento in cui bisogna aggiungere nuova documentazione: guide operative, protocolli, esempi, manuali secondari, prassi, allegati, checklist, procedure interne, note applicative.
Ed è lì che nasce il problema.
Non perché Qdrant non funzioni. Qdrant funziona benissimo. Il problema è architetturale: una sola collection può trasformarsi in uno spazio semantico troppo sporco, dove documenti con ruoli diversi competono tra loro nel retrieval.
Il risultato è sottile ma pericoloso: la LLM continua a rispondere, ma le fonti recuperate diventano meno pulite. Una risposta può essere formalmente coerente, ma costruita su documenti non perfettamente adatti alla domanda.
La soluzione, in molti casi, non è cambiare modello. Non è aumentare il prompt. Non è fare fine-tuning.
La soluzione è più semplice: separare la conoscenza in due collection Qdrant diverse.
Cos’è una collection Qdrant, spiegata semplice
Qdrant è un database vettoriale. Serve a cercare documenti non solo per parole chiave, ma anche per significato.
Una collection Qdrant è uno spazio in cui vengono salvati i chunk dei documenti, cioè frammenti testuali trasformati in vettori. Quando l’utente fa una domanda, il sistema cerca i chunk più vicini semanticamente e li passa alla LLM come contesto.
In un sistema RAG classico il flusso è questo:
Domanda utente
↓
Embedding / ricerca semantica
↓
Qdrant recupera i chunk più rilevanti
↓
La LLM legge domanda + fonti recuperate
↓
Risposta finale
Il punto critico è il recupero.
Se Qdrant recupera fonti giuste, la LLM parte bene. Se recupera fonti rumorose, la LLM deve arrangiarsi. E più il contesto è ambiguo, più aumenta il rischio di risposte deboli, confuse o troppo generiche.
Perché una sola collection diventa un limite
Una sola collection funziona bene quando tutti i documenti hanno la stessa natura.
Per esempio:
- solo manuali tecnici;
- solo documentazione prodotto;
- solo policy aziendali;
- solo FAQ;
- solo normative;
- solo guide operative.
Il problema nasce quando nella stessa collection finiscono documenti con ruoli diversi.
Immaginiamo una knowledge base principale composta da manuali e fonti autorevoli. A un certo punto vogliamo aggiungere documentazione operativa: procedure, codici, allegati, esempi, prassi, checklist.
Sono documenti utili, ma non hanno lo stesso ruolo.
La knowledge base principale risponde alla domanda:
Qual è la regola?
La documentazione operativa risponde invece alla domanda:
Come applico quella regola nella pratica?
Sono due domande diverse.
Se mettiamo tutto nello stesso spazio semantico, il retriever può confondere i piani. Può recuperare una checklist quando servirebbe una fonte principale. Può recuperare un esempio quando servirebbe una regola. Può recuperare un protocollo operativo quando la domanda richiede una spiegazione concettuale.
La LLM magari riesce comunque a produrre una risposta leggibile. Ma il sistema diventa meno controllabile.
Il concetto chiave: non tutti i documenti devono competere tra loro
Questo è il punto più importante.
In una RAG matura, non tutti i documenti devono stare nello stesso campionato.
Una fonte autorevole, un manuale, una procedura interna, un esempio pratico e una checklist possono contenere parole simili, ma non devono avere lo stesso peso nella risposta.
La ricerca vettoriale misura vicinanza semantica. Ma la vicinanza semantica non basta.
Due documenti possono parlare dello stesso argomento e avere funzioni completamente diverse.
Esempio generico:
| Documento | Argomento | Ruolo corretto |
|---|---|---|
| Manuale principale | Spiega la regola | Fonte di base |
| Procedura operativa | Spiega il flusso da seguire | Supporto pratico |
| Checklist | Elenca controlli | Verifica finale |
| Esempio compilato | Mostra un caso | Riferimento non vincolante |
| Protocollo tecnico | Descrive formato o deposito | Forma e adempimento |
Se questi documenti finiscono tutti nella stessa collection, la LLM deve capire da sola quale ruolo dare a ciascuno. Se invece li separiamo, il sistema glielo dice già a monte.
La soluzione: due collection Qdrant, una sola risposta LLM
Il pattern più pulito è usare due collection distinte.
La prima collection contiene la knowledge base principale:
main_knowledge_base
La seconda collection contiene la documentazione operativa o specialistica:
operational_documents
La LLM non riceve due risposte separate. Riceve un contesto composto da due blocchi diversi, ciascuno con un ruolo chiaro.
FONTI PRINCIPALI
- manuali
- norme
- documentazione autorevole
- concetti di base
FONTI OPERATIVE
- procedure
- prassi
- checklist
- codici
- allegati
- istruzioni applicative
Poi genera una risposta unica.
La differenza è che il contesto non è più un ammasso indistinto di frammenti, ma una struttura leggibile.
Perché due collection funzionano meglio di una sola
Usare due collection migliora il sistema per cinque motivi.
1. Riduce il rumore nel retrieval
La collection principale resta pulita. Quando la domanda richiede una spiegazione di base, il sistema cerca prima tra le fonti principali.
La documentazione operativa non compete con i manuali. Viene recuperata quando serve, con una query dedicata.
Questo riduce il rischio di recuperare documenti corretti ma fuori ruolo.
2. Mantiene separato il ruolo delle fonti
Una LLM risponde meglio quando sa cosa sta leggendo.
Dire al modello “questi sono manuali” e “queste sono procedure” è molto diverso dal passargli dieci chunk senza gerarchia.
La separazione aiuta il modello a usare le fonti nel modo giusto.
3. Migliora l’audit della risposta
In applicazioni professionali è importante sapere da dove arriva una risposta.
Con due collection, l’audit può mostrare:
- fonti recuperate dalla knowledge base principale;
- fonti recuperate dalla documentazione operativa.
Questo rende la risposta più trasparente e più facilmente verificabile.
4. Permette aggiornamenti indipendenti
La knowledge base principale e la documentazione operativa non hanno sempre lo stesso ciclo di vita.
I manuali possono essere aggiornati raramente. Le procedure possono cambiare più spesso. Le checklist possono evolvere in base all’esperienza. I codici o gli allegati possono essere sostituiti periodicamente.
Con due collection, si può aggiornare una parte senza rischiare di alterare l’altra.
5. Evita di usare il prompt come unica barriera
Molti provano a risolvere il problema scrivendo nel prompt:
Usa i manuali come fonti principali e le procedure solo come supporto.
È una buona istruzione, ma non basta.
Se il retrieval recupera male, il prompt arriva tardi. È meglio organizzare bene la memoria prima ancora di chiamare la LLM.
Architettura consigliata per una RAG a due collection
Un’architettura semplice può essere questa:
Domanda utente
↓
Classificazione della domanda
↓
Query verso collection principale
↓
Query verso collection operativa
↓
Reranking separato
↓
Costruzione del prompt con blocchi etichettati
↓
LLM
↓
Validazione e risposta finale
In pseudocodice:
mainSources = retrieve("main_knowledge_base", query)
operationalSources = retrieve("operational_documents", operationalQuery)
prompt = buildPrompt({
question,
mainSources,
operationalSources,
rules: {
mainSources: "usale per spiegare il contenuto principale",
operationalSources: "usale solo per aspetti applicativi e procedurali"
}
})
answer = llm.generate(prompt)
La parte importante non è il numero di righe di codice. È il contratto informativo:
ogni collection ha un ruolo preciso
Il prompt deve dichiarare il ruolo delle fonti
Separare le collection è utile, ma non basta se poi nel prompt i risultati vengono mescolati.
Il prompt dovrebbe mantenere sezioni distinte:
CONTESTO PRINCIPALE
[fonti dalla collection principale]
CONTESTO OPERATIVO
[fonti dalla seconda collection]
ISTRUZIONI
- usa il contesto principale per la spiegazione concettuale;
- usa il contesto operativo solo per dettagli pratici;
- non trasformare esempi o checklist in regole generali;
- se una fonte operativa non è pertinente, ignorala;
- segnala quando manca una fonte principale.
Questa struttura rende la LLM più disciplinata.
Non perché il modello diventi magicamente perfetto, ma perché riceve un contesto meno ambiguo.
Il ruolo del reranking
Quando si usano due collection, anche il reranking può diventare più intelligente.
Invece di fare una classifica unica tra tutti i documenti, si possono avere due classifiche:
- reranking delle fonti principali;
- reranking delle fonti operative.
Poi si selezionano pochi risultati da ciascun gruppo.
Per esempio:
4 fonti principali
3 fonti operative
Questo evita che una collection domini l’altra solo perché contiene chunk semanticamente più vicini alla query.
Il reranking non deve solo chiedersi “quanto è simile questo documento?”. Deve chiedersi anche:
questo documento è utile per il ruolo che gli sto assegnando?
Ricerca semantica, BM25 e hybrid search
In Qdrant è possibile usare diverse strategie di recupero:
- ricerca vettoriale densa;
- ricerca sparse, tipo BM25;
- ricerca ibrida;
- filtri sul payload;
- reranking applicativo.
Nel caso di documenti professionali, la ricerca ibrida è spesso preferibile.
La ricerca semantica capisce il significato. BM25 intercetta parole precise, codici, sigle, articoli, numeri, nomi di procedure. In molti domini, entrambe servono.
Con due collection, la strategia può anche cambiare per ciascuna base.
Esempio:
| Collection | Strategia utile |
|---|---|
| Knowledge base principale | semantic search + reranking |
| Documentazione operativa | BM25 / hybrid search su codici, allegati, termini precisi |
Questa flessibilità è uno dei vantaggi della separazione.
Il rischio della contaminazione semantica
La contaminazione semantica avviene quando la RAG recupera documenti pertinenti per argomento ma sbagliati per funzione.
È diversa dall’errore classico in cui il sistema recupera un documento completamente fuori tema.
Qui il documento sembra giusto. Contiene le parole corrette. Parla dello stesso dominio. Ma non dovrebbe guidare quella parte della risposta.
Esempio:
- la domanda chiede una spiegazione generale;
- il sistema recupera una checklist operativa;
- la LLM risponde come se la checklist fosse una regola generale.
Oppure:
- la domanda chiede un dettaglio procedurale;
- il sistema recupera un manuale teorico;
- la risposta è corretta ma poco utilizzabile.
Due collection riducono questo rischio perché impediscono ai documenti di competere nello stesso spazio.
Quando creare una seconda collection Qdrant
Una seconda collection ha senso quando la nuova documentazione è utile ma diversa dalla base principale.
Conviene crearla quando:
- la nuova documentazione ha un ruolo diverso;
- contiene esempi, procedure, checklist o prassi;
- deve essere aggiornata con frequenza diversa;
- non deve influenzare tutte le risposte;
- può creare rumore nella knowledge base principale;
- richiede filtri o ranking specifici;
- deve comparire separatamente nell’audit;
- deve essere usata solo in alcune sezioni della risposta.
La domanda pratica è questa:
Se questi documenti vengono recuperati al posto delle fonti principali, la risposta peggiora?
Se la risposta è sì, probabilmente serve una collection separata.
Quando una sola collection è sufficiente
Una sola collection è ancora una scelta valida quando la base è omogenea.
Per esempio:
- documentazione prodotto tutta dello stesso tipo;
- FAQ aziendali semplici;
- manuale tecnico unico;
- archivio di policy con struttura uniforme;
- knowledge base interna senza livelli di autorità diversi.
In questi casi separare troppo può aggiungere complessità inutile.
Il punto non è usare sempre più collection. Il punto è creare confini quando quei confini esistono già nei documenti.
Due collection non significano più complessità per l’utente
L’utente finale non deve sapere che il sistema sta interrogando due collection.
Dal suo punto di vista, fa una domanda e riceve una risposta.
La complessità resta nell’architettura:
- il sistema decide dove cercare;
- recupera le fonti corrette;
- le organizza;
- le passa alla LLM;
- produce una risposta unica.
Questa è una buona architettura AI: più ordine interno, meno complessità percepita.
Il pattern “main + operational”
Un modo semplice per progettare la separazione è usare il pattern:
main + operational
La collection principale contiene la conoscenza stabile:
- norme;
- manuali;
- documentazione ufficiale;
- principi;
- spiegazioni di base;
- fonti autorevoli.
La collection operativa contiene la conoscenza applicativa:
- prassi;
- procedure;
- checklist;
- codici;
- allegati;
- template;
- note di deposito;
- istruzioni interne.
La LLM può usare entrambe, ma non allo stesso modo.
La prima risponde al “perché” e al “che cosa”.
La seconda risponde al “come”.
Il vantaggio vero: risposte più stabili nel tempo
Il beneficio più importante delle due collection non si vede solo nella singola risposta. Si vede nella manutenzione.
Quando la documentazione cresce, una collection unica tende a diventare fragile. Ogni nuovo caricamento può cambiare i risultati del retrieval. Una fonte appena inserita può iniziare a superare fonti più importanti solo perché contiene parole più vicine alla domanda.
Con due collection, il sistema è più stabile.
La base principale resta pulita. La base operativa può crescere senza alterare il cuore della RAG. Il prompt mantiene ruoli chiari. L’audit resta leggibile.
È una forma di igiene architetturale.
Checklist tecnica per progettare le collection
Prima di caricare nuovi documenti in Qdrant, conviene rispondere a queste domande:
- Questi documenti hanno lo stesso ruolo della collection esistente?
- Devono essere cercati con la stessa query?
- Devono competere con le fonti principali?
- Hanno lo stesso livello di autorevolezza?
- Hanno lo stesso ciclo di aggiornamento?
- Devono essere mostrati nello stesso audit?
- Richiedono filtri specifici?
- Possono generare rumore se recuperati al momento sbagliato?
- La LLM potrebbe usarli nel modo sbagliato?
- Sono fonti di regola, di esempio o di procedura?
Se le risposte mostrano differenze strutturali, meglio creare una seconda collection.
Schema consigliato del payload
Anche con due collection, conviene arricchire il payload dei chunk.
Campi utili:
{
"source": "nome_documento.pdf",
"chunk_index": 12,
"document_type": "manuale | procedura | checklist | esempio",
"authority": "alta | media | bassa",
"domain": "dominio",
"updated_at": "2026-01-01",
"use_role": "principale | operativo | esempio"
}
Questi metadati aiutano nel filtro, nel reranking e nell’audit.
Separare le collection non elimina il bisogno di metadata buoni. Lo rende ancora più efficace.
L’errore da evitare: creare collection senza governance
Naturalmente, non bisogna passare da un estremo all’altro.
Una sola collection troppo piena è un problema. Ma anche dieci collection senza logica possono diventare ingestibili.
Ogni collection deve avere:
- uno scopo chiaro;
- una regola di ingestione;
- una strategia di retrieval;
- un ruolo nel prompt;
- una policy di aggiornamento;
- una sezione di audit.
Se non sappiamo spiegare perché una collection esiste, probabilmente non serve.
Conclusione: una RAG professionale non mette tutto nello stesso contenitore
Il passaggio da una collection Qdrant unica a due collection separate è uno di quei miglioramenti che sembrano piccoli, ma cambiano molto la qualità del sistema.
Non si tratta di una complicazione tecnica. Si tratta di riconoscere che la conoscenza non è tutta uguale.
Ci sono documenti che spiegano le regole.
Ci sono documenti che spiegano come applicarle.
Ci sono documenti che servono solo come esempi.
Ci sono fonti che devono guidare la risposta.
E ci sono fonti che devono solo completarla.
Se tutto finisce nella stessa collection, questa distinzione viene lasciata alla LLM. Se invece separiamo le basi documentali, la distinzione diventa parte dell’architettura.
La lezione è semplice:
una RAG non migliora solo aggiungendo documenti. Migliora organizzando meglio la memoria.
Due collection Qdrant permettono alla LLM di parlare con più basi informative, ma senza confonderle. La risposta resta unica, il contesto diventa più pulito e il sistema diventa più governabile.
Nel 2026, questa è una delle differenze fondamentali tra una demo RAG e una RAG pronta per applicazioni professionali.
FAQ SEO
Perché usare due collection Qdrant in una RAG?
Per separare documenti con ruoli diversi. Una collection può contenere la knowledge base principale, l’altra documentazione operativa, procedure, checklist o prassi. Questo riduce rumore e contaminazione semantica.
Una sola collection Qdrant è sempre sbagliata?
No. È corretta quando i documenti sono omogenei. Diventa un limite quando nella stessa collection finiscono fonti con funzioni diverse.
La LLM può usare due collection contemporaneamente?
Sì. Il sistema recupera risultati da entrambe, li organizza in blocchi separati e passa tutto alla LLM con istruzioni chiare sul ruolo delle fonti.
Due collection migliorano davvero la qualità delle risposte?
Sì, soprattutto quando la base documentale cresce. La separazione riduce il rumore, migliora l’audit e impedisce che documenti operativi competano con fonti principali.
Meglio due collection o una collection con metadata e filtri?
Dipende. I metadata sono sempre utili, ma quando i documenti hanno ruoli molto diversi, due collection rendono il confine più chiaro e meno fragile.
Questo pattern vale solo per documentazione legale?
No. Vale per qualunque sistema RAG professionale: compliance, sanità, assicurazioni, banche, supporto tecnico, knowledge base aziendali, documentazione software e assistenti AI verticali.