Costruire un sistema RAG (Retrieval Augmented Generation) - un’AI che risponde sulla base dei tuoi documenti - è sempre stato un lavoro tecnico impegnativo: chunking, embeddings, database vettoriale, retrieval. Gemini File Search promette di eliminare tutta questa complessità. Carichi un documento, Google fa tutto il resto.
Ma dopo averlo testato su casi d’uso reali e costruito un agente RAG su n8n, il quadro è più sfumato: perfetto per prototipi veloci, problematico per la produzione.
Come funziona Gemini File Search
Il concetto è semplice: un sistema RAG completamente gestito da Google. Il flusso è lineare:
- Upload - Carichi documenti (PDF, TXT, DOC). Google estrae il testo, esegue OCR se necessario
- Chunking + embeddings - Google spezzetta automaticamente i documenti e li trasforma in vettori
- Database vettoriale - Tutto viene salvato in un vector store gestito da Google
- Retrieval - Quando l’utente fa una domanda, Gemini cerca per similarità nei documenti e risponde con citazioni precise
Nel RAG tradizionale ogni singolo passaggio è a carico dello sviluppatore. Con File Search si passa da settimane di configurazione a pochi minuti. È un salto enorme in termini di accessibilità.
Se la domanda dell’utente non trova risposta nei documenti caricati, il sistema risponde onestamente che non ha informazioni - senza inventare nulla. Questo comportamento è fondamentale per evitare le allucinazioni, lo stesso principio alla base di strumenti come NotebookLM.
Caso d’uso reale: agente RAG su n8n
Per testare File Search in un contesto pratico, il workflow costruito su n8n funziona così:
- Un form permette l’upload di un documento (nel test: un PDF di 7 pagine con le informazioni di un sito web)
- Tre chiamate API in sequenza: creazione del file search store, upload del documento nel database vettoriale, import con metadati (data di caricamento)
- Un agente AI che usa File Search come tool per rispondere alle domande degli utenti
Un dettaglio tecnico interessante: il “cervello” dell’agente può essere qualsiasi modello (nel test, GPT-4.1 mini), ma la fase di retrieval passa obbligatoriamente da Gemini. In pratica, la chiamata API a File Search chiama internamente Gemini 2.5 Flash per l’embedding della query e il retrieval dei chunk rilevanti.
Il setup è veloce - il chunking e l’embedding di un documento di 7 pagine richiedono pochi secondi. Per chi lavora con automazioni AI, la semplicità di integrazione via API è il punto di forza principale.
Le limitazioni critiche per la produzione
Qui il discorso si fa serio. Gemini File Search ha limiti concreti che rendono problematico il passaggio alla produzione:
Chunking black box
Non puoi controllare come Google spezzetta i documenti. Nel RAG tradizionale scegli tu: chunking per paragrafo, per sezione, con overlap. Con File Search è tutto automatico. Per documenti con struttura complessa - contratti, manuali tecnici, report finanziari - i risultati diventano imprevedibili.
Zero controllo sui parametri di retrieval
Non puoi decidere quanti chunk recuperare (top-k), non puoi impostare una soglia di similarità, non puoi applicare algoritmi di reranking o ricerca ibrida. Sono parametri fondamentali per ottimizzare la precisione delle risposte in produzione.
Privacy: i tuoi dati vanno a Google
Ogni documento caricato finisce sui server di Google. Non sai dove sono salvati fisicamente, non hai garanzie GDPR complete. Per contratti riservati, dati medici, strategie aziendali o informazioni dei clienti, è un rischio concreto. Con un database vettoriale self-hosted (Supabase, Qdrant) mantieni il pieno controllo.
Vendor lock-in: solo modelli Google
Il retrieval funziona esclusivamente con modelli Gemini. Se per il tuo caso d’uso servisse Claude o GPT per la fase di ricerca, non è un’opzione. Sei legato all’ecosistema Google.
I costi: il vantaggio schiacciante
Se i limiti tecnici sono reali, il vantaggio economico è altrettanto concreto. Un confronto su un carico di 1.000 documenti al mese (20-30 pagine ciascuno) con 10.000 query mensili:
- Gemini File Search - 0,80 dollari/mese (query e storage gratuiti, solo 0,15 dollari per milione di token)
- Supabase pgvector - 25-50 dollari/mese
- Pinecone - 83-85 dollari/mese
Un risparmio del 93-98%. Per un prototipo o un progetto in fase di validazione, è un argomento difficile da ignorare.
Quando usare File Search e quando il RAG tradizionale
La scelta non è binaria - dipende dalla fase del progetto e dai requisiti:
- File Search - Prototipi rapidi, validazione di idee, progetti interni senza dati sensibili, MVP con budget limitato. Zero infrastruttura, costi minimi, risultati in minuti
- RAG tradizionale - Produzione su larga scala, dati sensibili o regolamentati, necessità di precisione elevata, controllo su chunking e retrieval, indipendenza dal vendor
L’approccio pragmatico è iniziare con File Search per validare il concetto, poi migrare a un RAG tradizionale quando le esigenze di precisione, privacy o scala lo richiedono. La formazione AI del team tecnico diventa cruciale in questa transizione - passare da un sistema gestito a uno custom richiede competenze specifiche su embeddings, database vettoriali e strategie di chunking.