Tutorial sullo strumento Google File Search: crea applicazioni RAG con l'API Gemini

In questo tutorial ti guiderò nella creazione di un assistente per la documentazione medica con Google File Search. Vedrai come configurarlo, implementare le query e usare funzionalità avanzate come il chunking personalizzato e il filtraggio per metadati. Alla fine, saprai quando ha senso usare un RAG gestito rispetto a costruire il tuo stack.

Che cos'è lo strumento Google File Search?

Creare applicazioni RAG di solito significa gestire database vettoriali, pipeline di embedding e molta infrastruttura. Lo strumento File Search di Google, rilasciato a novembre 2025, elimina questa complessità con un sistema RAG completamente gestito integrato direttamente nell'API Gemini.

Lo strumento gestisce per te le parti complesse: suddivide i documenti in chunk, genera gli embedding e gestisce la ricerca semantica senza richiedere strumenti esterni come Pinecone o ChromaDB. Il flusso di lavoro è lineare: carichi i file, crei uno store e inizi a fare query. Ottieni anche citazioni integrate che ti permettono di verificare da dove provengono le risposte.

Capire il RAG e perché Google lo semplifica

Gemini File Search si propone come un sistema RAG gestito. Capire il RAG ti aiuta a usare bene lo strumento e a decidere quando si adatta al tuo caso d'uso.

Alla base, la retrieval-augmented generation (RAG) collega i modelli linguistici a conoscenze esterne. Prima di generare una risposta, il modello recupera informazioni rilevanti dai tuoi documenti, ancorando le risposte ai tuoi dati reali invece di fare affidamento solo sui dati di training.

La sfida del RAG fai-da-te

Sebbene il RAG sia semplice in teoria, costruire una pipeline RAG in autonomia significa gestire diversi componenti:

• Database vettoriali: Configurare e mantenere servizi come Pinecone, ChromaDB o Weaviate per archiviare gli embedding
• Pipeline di embedding: Convertire i documenti in vettori numerici e gestire gli aggiornamenti quando i contenuti cambiano
• Strategie di chunking: Suddividere i documenti in parti che bilancino contesto e precisione del recupero
• Infrastruttura: Monitorare le prestazioni, regolare i parametri e gestire lo scaling man mano che i dati crescono

Ogni componente richiede competenze e manutenzione continua. Che tu stia costruendo un sistema di produzione che richiede affidabilità o un prototipo che richiede velocità, l'overhead infrastrutturale resta lo stesso collo di bottiglia.

Perché il RAG gestito è importante

Servizi gestiti come Google File Search eliminano questo collo di bottiglia. Invece di ottimizzare i sistemi di retrieval, scrivi query. Invece di fare debug delle pipeline di embedding, convalidi i risultati. L'infrastruttura gira in background mentre tu ti concentri sulla logica applicativa.

Gemini File Search gestisce la complessità tecnica mentre tu controlli ciò che conta: quali documenti indicizzare, come interrogarli e come usare i risultati. Questo equilibrio funziona bene quando ti serve qualità di produzione senza carico operativo. Per un approfondimento sui fondamenti di RAG, ti consiglio di dare un'occhiata al tutorial di DataCamp su agentic RAG.

Il modo migliore per capire Google File Search è usarlo. Nella prossima sezione, costruirai un assistente completo per la documentazione medica che mostra l'intero workflow dal caricamento dei documenti a risposte ancorate con citazioni.

Creare un assistente per la documentazione medica con Google File Search

Disclaimer: Questo tutorial mostra le funzionalità di File Search usando etichette dei farmaci FDA a solo scopo didattico. L'assistente che costruirai non è destinato all'uso clinico, a decisioni di cura del paziente o a diagnosi mediche. Per consigli medici, consulta sempre professionisti sanitari qualificati. I sistemi di IA possono generare informazioni errate anche se ancorati a documenti di origine.

Questa sezione ti guida nella creazione di un assistente completo per la documentazione medica usando File Search. Lavorerai con etichette di farmaci approvati dalla FDA per tre medicinali comuni, creando un sistema che risponde a domande su interazioni, effetti collaterali e controindicazioni. L'assistente fornisce risposte verificabili citando passaggi specifici dai documenti di origine.

File Search opera in due fasi: indicizzi i documenti una volta, poi li interroghi ripetutamente. Prima configurerai l'infrastruttura di indicizzazione, poi ti concentrerai interamente sul porre domande e interpretare risposte ancorate.

Passaggio 1: Installa l'API e configura l'autenticazione

Ti serve Python 3.9 o successivo. Installa l'SDK Google Generative AI e le dipendenze:

pip install google-genai python-dotenvOfferto da

Ottieni la tua chiave API da Google AI Studio. Salvala in un file .env nella directory del progetto:

GOOGLE_API_KEY=your_api_key_hereOfferto da

Configura gli import e inizializza il client:

from google import genai
from google.genai import types
import time
from dotenv import load_dotenv

load_dotenv()
client = genai.Client()Offerto da

Il genai.Client() gestisce automaticamente l'autenticazione usando la variabile d'ambiente. Userai questo oggetto client per tutte le operazioni di File Search.

Passaggio 2: Crea uno store File Search

Crea uno store per contenere i tuoi documenti indicizzati:

file_search_store = client.file_search_stores.create(
    config={"display_name": "fda-drug-labels"}
)
print(f"Created store: {file_search_store.name}")Offerto da

Uno store File Search funge da contenitore per i tuoi documenti indicizzati. A differenza dei caricamenti temporanei che scadono dopo 48 ore, gli store persistono a tempo indeterminato. Questo significa che indicizzi i documenti una volta e li interroghi migliaia di volte senza ricaricare o rielaborare.

Il file_search_store.name contiene un identificatore univoco che userai nelle query. Ha un aspetto simile a fileSearchStores/fdadruglabels-abc123. Salva questo valore se devi interrogare lo store da una sessione diversa.

Passaggio 3: Carica e indicizza documenti PDF

Per questo tutorial, lavorerai con tre etichette di farmaci approvate dalla FDA. Scarica questi PDF dal sito della FDA:

• Metformin (Glucophage) - Farmaco per il diabete
• Atorvastatin (Lipitor) - Farmaco per il colesterolo
• Lisinopril (Zestril) - Farmaco per la pressione arteriosa

Salvali nella directory del progetto, poi caricali nel tuo File Search store:

pdf_files = ["metformin.pdf", "atorvastatin.pdf", "lisinopril.pdf"]

for pdf_file in pdf_files:
    operation = client.file_search_stores.upload_to_file_search_store(
        file=pdf_file,
        file_search_store_name=file_search_store.name,
        config={"display_name": pdf_file.replace(".pdf", "")},
    )

    # Wait for indexing to complete
    while not operation.done:
        time.sleep(3)
        operation = client.operations.get(operation)

    print(f"{pdf_file} indexed")Offerto da

Durante il caricamento, File Search suddivide ogni PDF in chunk e converte i segmenti in embedding usando il modello gemini-embedding-001. Questi embedding sono rappresentazioni numeriche che catturano il significato semantico, permettendo al sistema di trovare passaggi pertinenti anche quando la tua domanda non corrisponde esattamente alla formulazione nel documento.

Il pattern di polling (while not operation.done) gestisce la natura asincrona dell'indicizzazione. I documenti grandi richiedono più tempo per essere elaborati, quindi l'API restituisce subito e controlli periodicamente lo stato di completamento. In produzione, valuta di aggiungere una logica di timeout per evitare loop infiniti.

Ogni chunk conserva metadati che lo collegano al suo documento di origine e alla posizione. Questi metadati diventano importanti quando accedi alle citazioni più avanti.

Passaggio 4: Esegui query su un singolo documento

Ora interroga i tuoi documenti indicizzati:

query1 = "What are the contraindications for metformin?"

response1 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query1,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response1.text)Offerto da

Questo stampa la risposta generata:

Metformin is contraindicated in several conditions:

* Severe renal impairment (eGFR below 30 mL/min/1.73 m2)
* Acute or chronic metabolic acidosis
* Hypersensitivity to metforminOfferto da

File Search recupera i chunk più semanticamente simili nei tuoi documenti e li fornisce come contesto a gemini-2.5-flash, che genera la risposta. La configurazione dell'array tools indica al modello di usare File Search durante la generazione. Puoi combinare File Search con altri strumenti, come l'esecuzione di codice o Google Search, nella stessa richiesta.

Passaggio 5: Accedi a citazioni e metadati di grounding

Estrai quali documenti hanno informato la risposta:

print("Sources used:")
for i, chunk in enumerate(response1.candidates[0].grounding_metadata.grounding_chunks, 1):
    source_name = chunk.retrieved_context.title
    print(f"  [{i}] {source_name}")Offerto da

Output:

Sources used:
  [1] metformin
  [2] atorvastatinOfferto da

Ogni chunk nei metadati di grounding include il titolo del documento sorgente e il passaggio testuale specifico che ha informato la risposta. Questo crea un percorso di verifica dalla risposta generata ai tuoi documenti originali — necessario in ambito medico, legale o finanziario, dove l'accuratezza conta.

L'array grounding_chunks contiene tutti i passaggi recuperati, ordinati per rilevanza. Anche se la query chiede specificamente della metformina, File Search ha recuperato anche contenuti dal documento su atorvastatina, probabilmente perché contiene informazioni correlate sulle controindicazioni. Questo dimostra l'approccio di retrieval semantico: il sistema trova contenuti concettualmente correlati, non solo corrispondenze di parole chiave.

Passaggio 6: Esegui query su più documenti

Prova una domanda su interazioni tra farmaci che coinvolge più documenti:

query2 = "Can a patient take both atorvastatin and metformin together? Are there any drug interactions?"

response2 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query2,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response2.text)Offerto da

Lo stesso pattern di API ora attinge da più documenti e sintetizza le informazioni. Accedi agli estratti di testo recuperati:

print("Sources used:")

for i, chunk in enumerate(response2.candidates[0].grounding_metadata.grounding_chunks, 1):
    source_name = chunk.retrieved_context.title
    source_text = chunk.retrieved_context.text[:100] + "..."
    print(f"  [{i}] {source_name}")
    print(f"      {source_text}")Offerto da

L'output mostra estratti da entrambe le etichette dei farmaci:

Sources used:
  [1] atorvastatin
      Concomitant use with diabetes medications is generally safe but monitor glucose levels...
  [2] metformin
      Carbonic anhydrase inhibitors may increase the risk of lactic acidosis...Offerto da

File Search recupera sezioni pertinenti da entrambi i documenti e il modello le sintetizza in una risposta coerente. L'attributo retrieved_context.text ti dà il passaggio esatto usato, permettendoti di verificare che il modello non abbia allucinato informazioni.

Passaggio 7: Esegui confronti tra documenti

Poni una domanda analitica che richiede di confrontare tutti e tre i documenti:

query3 = "Which medications have muscle-related side effects?"

response3 = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query3,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name]
                )
            )
        ]
    ),
)

print(response3.text)

# Check which documents were consulted
metadata = response3.candidates[0].grounding_metadata
for i, chunk in enumerate(metadata.grounding_chunks, 1):
    print(f"  [{i}] {chunk.retrieved_context.title}")Offerto da

L'output identifica l'atorvastatina come avente effetti collaterali a carico dei muscoli (mialgia, miopatia, rabdomiolisi) e conferma che gli altri farmaci non riportano tali effetti. I metadati di grounding mostrano che File Search ha consultato tutti e tre i documenti per rispondere alla domanda di confronto.

Ora hai costruito un assistente funzionante per la documentazione medica. Il workflow principale resta coerente: configura lo strumento File Search nella chiamata generate_content(), ottieni il testo della risposta e accedi ai metadati di grounding per la verifica. Lo store persiste sui server di Google, quindi puoi interrogarlo in sessioni future senza reindicizzare.

Poi esplorerai funzionalità avanzate come configurazioni di chunking personalizzate e filtri di metadati che ti danno un controllo più fine sul comportamento di retrieval.

Funzionalità avanzate e personalizzazione di Google File Search

Il workflow base di File Search copre la maggior parte dei casi d'uso, ma i sistemi di produzione spesso richiedono un controllo più fine sul comportamento di retrieval. Questa sezione mostra come personalizzare le strategie di chunking, filtrare i documenti con metadati, ottimizzare le prestazioni e gestire store multipli per casi d'uso diversi.

Configurazione di chunking personalizzato

File Search suddivide automaticamente i documenti in chunk durante l'indicizzazione. Per impostazione predefinita usa una strategia ottimizzata per documenti generali, ma puoi personalizzare questo comportamento quando tipi di documento specifici richiedono un trattamento diverso.

Considera l'esempio dell'assistente medico. Le etichette dei farmaci contengono informazioni tecniche dense in tabelle e paragrafi brevi. Chunk più piccoli ti permettono di recuperare informazioni precise come dosaggi specifici o controindicazioni senza trascinare contesto irrilevante. Chunk più grandi funzionano meglio per sezioni narrative che richiedono più contesto per essere comprese correttamente.

Configura i parametri di chunking quando carichi i documenti:

operation = client.file_search_stores.upload_to_file_search_store(
    file="metformin.pdf",
    file_search_store_name=file_search_store.name,
    config={
        "display_name": "metformin",
        "chunking_config": {
            "white_space_config": {
                "max_tokens_per_chunk": 200,
                "max_overlap_tokens": 20
            }
        }
    }
)Offerto da

Il parametro chunking_config controlla come File Search suddivide i documenti. max_tokens_per_chunk imposta la dimensione massima di ciascun chunk, mentre max_overlap_tokens determina quanto contenuto si sovrappone tra chunk consecutivi. Questa sovrapposizione assicura che le informazioni che attraversano i confini dei chunk non vadano perse durante il retrieval.

Il compromesso è importante: chunk più brevi offrono un recupero più preciso ma possono perdere il contesto più ampio, mentre chunk più grandi mantengono più significato ma possono includere informazioni irrilevanti. 

Per la documentazione tecnica con confini di sezione chiari, usa chunk più piccoli (150-250 token). Per documenti narrativi come articoli di ricerca o report, chunk più grandi (400-600 token) preservano il filo logico e il contesto. La documentazione ufficiale di File Search offre ulteriori indicazioni sulla scelta delle dimensioni dei chunk per diversi tipi di documenti.

Filtraggio per metadati

Quando il tuo store contiene decine o centinaia di documenti, il filtraggio per metadati restringe l'ambito del recupero prima che avvenga la ricerca semantica. Questo migliora la precisione e riduce i tempi di elaborazione.

Aggiungi metadati durante il caricamento dei documenti per abilitare il filtraggio in seguito:

operation = client.file_search_stores.upload_to_file_search_store(
    file="metformin.pdf",
    file_search_store_name=file_search_store.name,
    config={
        "display_name": "metformin",
        "custom_metadata": [
            {"key": "category", "string_value": "diabetes"},
            {"key": "year", "numeric_value": 2017},
            {"key": "drug_class", "string_value": "biguanide"}
        ]
    }
)Offerto da

Il parametro custom_metadata accetta un array di coppie chiave-valore. Usa string_value per metadati testuali come categorie o classi di farmaci e numeric_value per anni, versioni o altri dati numerici.

Interroga con filtri sui metadati per cercare solo documenti rilevanti:

query = "What are the common side effects?"

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=query,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[file_search_store.name],
                    metadata_filter="category=diabetes"
                )
            )
        ]
    )
)Offerto da

Il parametro metadata_filter limita il recupero ai documenti che corrispondono ai criteri specificati. In questo esempio, File Search considera solo i documenti con category=diabetes, ignorando i farmaci per la pressione e il colesterolo, pur essendo nello stesso store.

Questo diventa cruciale quando gli store contengono documenti eterogenei. Una base di conoscenze mediche può includere etichette di farmaci, articoli di ricerca e linee guida cliniche. Filtrare per tipo di documento assicura di ottenere informazioni sui dosaggi dalle etichette, non da abstract di ricerca.

Puoi combinare il filtraggio per metadati con la piena capacità di ricerca semantica. Il filtro viene eseguito per primo per selezionare i documenti candidati, poi la ricerca semantica trova i passaggi più rilevanti all'interno di quei documenti.

Ottimizzazione delle prestazioni

Le prestazioni di File Search dipendono dalla dimensione dello store, dalla complessità della query e dalla scelta del modello. Seguendo queste linee guida mantieni il recupero veloce e i costi gestibili.

Limiti di dimensione dello store: Mantieni i singoli store sotto i 20 GB per una latenza di retrieval ottimale. File Search archivia gli embedding insieme ai tuoi documenti e gli embedding richiedono circa tre volte la dimensione dei file originali. Una raccolta di PDF da 7 GB genera circa 21 GB di dati archiviati una volta indicizzata, superando il limite raccomandato.

Quando ti avvicini a questo limite, crea store separati organizzati per categoria, periodo di tempo o pattern di accesso. Per l'assistente medico, potresti creare store separati per diverse categorie di farmaci anziché indicizzare tutti i medicinali in un unico store.

Struttura dei costi: File Search addebita 0,15 $ per 1 milione di token per l'indicizzazione. Una volta indicizzati, puoi eseguire migliaia di query senza costi di indicizzazione aggiuntivi. Questo modello di prezzo favorisce carichi di lavoro con molte letture, in cui interroghi ripetutamente gli stessi documenti.

Selezione del modello: Usa gemini-2.5-flash per la maggior parte delle query. Elabora le richieste in 1-2 secondi e costa significativamente meno di gemini-2.5-pro. Riserva gemini-2.5-pro per query che richiedono ragionamenti profondi su più fonti o la gestione di attività di sintesi estremamente complesse. La differenza di costo tra modelli conta più dei costi di indicizzazione per applicazioni ad alto volume.

Monitora la dimensione dello store man mano che aggiungi documenti. Puoi verificarla tramite l'API, anche se il calcolo della dimensione avviene sul backend di Google e potrebbe non riflettersi immediatamente dopo i caricamenti. Per specifiche tecniche e limiti completi, fai riferimento alla documentazione Gemini File API.

Gestione di più store

Ogni progetto Google Cloud supporta fino a 10 store File Search. Store multipli ti permettono di separare i documenti per controllo degli accessi, requisiti di prestazioni o organizzazione logica.

Crea store specializzati per casi d'uso diversi:

# Create separate stores for different document categories
diabetes_store = client.file_search_stores.create(
    config={"display_name": "diabetes-medications"}
)

cardio_store = client.file_search_stores.create(
    config={"display_name": "cardiovascular-medications"}
)Offerto da

Interroga più store in un'unica richiesta:

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="What medications treat both diabetes and heart disease?",
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                file_search=types.FileSearch(
                    file_search_store_names=[
                        diabetes_store.name,
                        cardio_store.name
                    ]
                )
            )
        ]
    )
)Offerto da

File Search recupera da tutti gli store specificati e sintetizza i risultati. I metadati di grounding identificano da quale store proviene ciascuna citazione, mantenendo la piena tracciabilità. 

Gli store persistono a tempo indeterminato e richiedono l'eliminazione manuale quando non più necessari, rendendoli adatti alle applicazioni di produzione in cui i documenti restano interrogabili tra sessioni e deployment.

Ora vedrai come File Search si confronta con altre soluzioni RAG e quando scegliere approcci gestiti rispetto al fai-da-te.

Strumento Google File Search vs altri strumenti di File Search e RAG

File Search non è l'unica opzione per costruire applicazioni RAG. Capire come si posiziona rispetto alle alternative ti aiuta a scegliere lo strumento giusto. Confrontiamo l'approccio di Google con l'offerta di OpenAI e i build personalizzati tradizionali.

Google File Search vs OpenAI File Search

Entrambe le aziende offrono RAG ospitato, ma seguono strade diverse su prezzi e funzionalità.

Prezzi: Google addebita una volta durante l'indicizzazione (2,50 $ per mille query più 0,10 $ per GB al giorno per lo storage). Se esegui molte query ma aggiorni raramente i documenti, il modello di Google fa risparmiare. Se reindicizzi continuamente, la matematica si fa interessante.

Controllo della configurazione: Google mantiene le cose semplici con chunking automatico e configurazione limitata. OpenAI ti dà più controllo. Puoi impostare la dimensione dei chunk (800 token predefiniti) e l'overlap (400 token). OpenAI esegue anche ricerche ibride che combinano vettori e corrispondenza per parole chiave, mentre Google si affida esclusivamente alla ricerca semantica. Questo conta quando le tue query contengono termini tecnici specifici o codici prodotto.

Formati di file: Google gestisce 150+ tipi di file, inclusi file di codice e vari formati di documenti. OpenAI ne supporta sei: TXT, MD, HTML, DOCX, PPTX e PDF. Nessuno dei due gestisce bene dati strutturati come CSV o JSONL. È qui che i build personalizzati brillano.

Integrazione: Google si integra con i modelli Gemini e i servizi Google Cloud. OpenAI si collega alla propria famiglia di modelli e ad Azure. Entrambi ti forniscono citazioni e tracciamento delle fonti.

La vera differenza si riduce a semplicità contro controllo. Google impacchetta tutto in una singola chiamata API. OpenAI ti permette di regolare il retrieval al costo di maggiore complessità. Non c'è un vincitore unico. Dipende se per il tuo progetto preferisci velocità o personalizzazione.

Capacità del RAG personalizzato

Costruire un sistema RAG personalizzato con strumenti come LangChain sblocca capacità che i servizi ospitati non offrono. Il corso di DataCamp RAG con LangChain illustra in dettaglio questo approccio.

I build personalizzati abilitano tecniche avanzate:

• Suddivisione semantica che rileva i cambi di argomento invece di tagliare a lunghezze fisse
• Chunking consapevole dei token che rispetta con precisione le finestre di contesto del modello
• Retrieval ibrido che combina la ricerca BM25 per keyword con vettori densi
• Trasformazioni della query come HyDE che generano risposte ipotetiche per migliorare la ricerca
• Graph RAG che rappresenta i documenti come reti di entità e relazioni

Il tutorial di DataCamp su come migliorare le prestazioni di RAG esplora queste tecniche con esempi che mostrano miglioramenti misurabili della qualità. Il compromesso è la complessità operativa: monitori le prestazioni del database, ottimizzi i modelli di embedding e gestisci aggiornamenti su più servizi.

Quando usare ciascun approccio

Scegli strumenti ospitati come File Search quando:

• Costruisci prototipi o proof-of-concept dove la velocità conta
• Il tuo caso d'uso rientra in pattern standard (Q&A su documenti, knowledge base, ricerca nella documentazione)
• Il tuo team non ha profonda esperienza in RAG
• Vuoi costi prevedibili e minimo overhead operativo

Costruisci su misura quando:

• Ti servono chunking avanzato o metodi di retrieval specializzati
• Lavori con dati strutturati o formati di file insoliti
• Stai costruendo sistemi di agentic RAG che combinano più strategie
• Ottimizzare i costi su scala massiva giustifica l'investimento ingegneristico
• La conformità richiede infrastrutture o modelli specifici

La maggior parte dei progetti parte da soluzioni ospitate e passa a build personalizzati solo quando i requisiti lo impongono. Le tecniche del RAG personalizzato (chunking intelligente, ricerca ibrida, ottimizzazione delle query) restano utili per guidare l'uso degli strumenti ospitati. Comprendere il panorama completo ti aiuta a fare scelte migliori man mano che le tue esigenze evolvono.

Conclusione

Hai costruito un sistema RAG completo usando lo strumento Google File Search, dall'indicizzazione delle etichette dei farmaci FDA alle query con citazioni. L'assistente medico dimostra come i servizi gestiti si occupano dell'infrastruttura mentre tu ti concentri sulla logica applicativa.

File Search funziona bene quando ti serve un RAG affidabile senza gestire database vettoriali o pipeline di embedding. Lo storage gratuito e gli embedding per le query rendono i costi prevedibili. Gli store persistenti eliminano l'overhead di reindicizzazione, permettendoti di scalare le query senza scalare la manutenzione dell'infrastruttura.

Prima del deploy in produzione, aggiungi salvaguardie critiche omesse nel tutorial per brevità. Implementa la gestione degli errori con timeout per le operazioni di upload e blocchi try-catch attorno alle chiamate API. Considera le implicazioni sulla privacy dei dati quando carichi documenti sui server di Google, soprattutto con contenuti sensibili. Aggiungi validazioni per verificare che i metadati di grounding esistano prima di accedere alle citazioni. Testa a fondo con esperti di dominio per intercettare casi in cui il modello genera risposte plausibili ma errate nonostante l'ancoraggio.

Per i prossimi passi, prova a estendere il tuo assistente con il filtraggio per metadati per organizzare i documenti per categoria. Sperimenta con le dimensioni dei chunk in base ai tipi di documento. Le tecniche che hai imparato qui si applicano che tu stia costruendo bot di supporto, ricerca nella documentazione o assistenti alla conoscenza.