Comment créer un RAG avec Gemini API File Search ?

On crée un RAG avec Gemini API File Search en laissant Gemini gérer l’indexation, les embeddings, la recherche sémantique et le contexte injecté au modèle. Le vrai sujet, c’est de comprendre ce que l’API fait pour vous, où garder la main, et comment éviter une usine à gaz.

À quoi sert File Search ?

File Search sert à connecter Gemini à des données privées pour produire des réponses mieux ancrées dans vos documents.

Dans un système RAG, pour Retrieval Augmented Generation, on donne au modèle le bon contexte avant qu’il réponde. Dit simplement, Gemini ne répond pas seulement avec ce qu’il “sait” déjà, il va chercher dans vos fichiers les passages utiles, puis il s’en sert pour formuler une réponse plus fiable.

Ce que j’aime avec Gemini API File Search, c’est qu’il enlève une grosse partie du bricolage technique. Normalement, il faut découper les documents en petits morceaux, qu’on appelle des chunks, générer des embeddings, c’est-à-dire des représentations numériques du sens du texte, stocker tout ça, indexer les contenus, puis faire une recherche sémantique au moment de la question. File Search prend en charge cette plomberie.

Les sources peuvent être très classiques : rapports, PDF, documentation technique, code, base de connaissances, procédures internes, comptes rendus, documents métier. C’est souvent là que se trouve la vraie valeur. Pas dans un prompt magique, mais dans les bons documents, bien récupérés au bon moment.

Découvrez égalementRAG vs fine-tuning quel choix pour vos LLM ?

La différence avec une recherche par mots-clés est importante. Une recherche par mots-clés cherche les mêmes termes. Une recherche sémantique cherche un sens proche. Par exemple, si un utilisateur demande “Comment annuler un abonnement avant la prochaine facture ?”, le document peut contenir “Résiliation du plan avant renouvellement automatique”. Les mots ne sont pas les mêmes, mais l’intention est la même. File Search peut retrouver le bon passage parce qu’il travaille sur le sens, pas seulement sur les mots exacts.

Sur le terrain, je vois souvent la même chose. Le problème d’un projet RAG n’est pas toujours le modèle. C’est plutôt la préparation des documents et la récupération du bon contexte. Si Gemini reçoit un mauvais passage, il répondra mal, même avec un très bon modèle. File Search réduit cette complexité, et ça laisse plus de temps pour travailler les cas d’usage, les règles métier, les tests et la qualité réelle des réponses.

Comment fonctionne le RAG avec Gemini ?

Gemini transforme les fichiers et les questions en représentations vectorielles pour retrouver les chunks les plus pertinents, puis les ajoute au contexte de génération.

L’idée est simple. Ce n’est pas juste “stocker un PDF quelque part”. L’intérêt, comme on l’a vu juste avant, c’est de récupérer le bon contexte au bon moment, sans envoyer tout le document au modèle à chaque question.

Le flux ressemble à ça :

• Vous uploadez un fichier dans Gemini File Search.
• Gemini découpe ce fichier en chunks, c’est-à-dire en petits morceaux de texte plus faciles à chercher.
• Chaque chunk est transformé en embedding, une représentation numérique qui capture son sens.
• Ces embeddings sont stockés dans un File Search Store.
• Quand vous posez une question, Gemini transforme aussi cette question en embedding.
• L’API cherche les chunks dont le sens est le plus proche de la question.
• Les chunks récupérés sont ajoutés au contexte du prompt.
• Le modèle génère une réponse avec une base plus solide, parce qu’il s’appuie sur les bons extraits.

Découvrez égalementRAG ou fine-tuning pour un LLM en production ?

Un File Search Store, c’est simplement un espace où vos données indexées sont conservées. Une fois le fichier traité, vous pouvez réutiliser ce store dans vos prochaines requêtes. Les données restent disponibles jusqu’à ce que vous les supprimiez manuellement. C’est pratique, parce que vous n’avez pas à réindexer vos fichiers à chaque conversation.

Ce qui change beaucoup de choses, c’est que toute l’infrastructure de recherche est gérée par l’API Gemini. Je n’ai pas besoin d’assembler moi-même une base vectorielle, un pipeline d’embedding, une couche de retrieval, puis de maintenir tout ça. Sur un projet client, c’est souvent là que le temps part. Pas dans la démo. Dans les petits détails de synchronisation, de stockage, de qualité de recherche.

File Search peut aussi travailler en multimodal. Ça veut dire qu’il peut indexer du texte et des images, avec des modèles d’embeddings adaptés. Pour un store multimodal, on utilise models/gemini-embedding-2. Pour du texte uniquement, gemini-embedding-001 reste le modèle à utiliser.

Le RAG avec Gemini, au fond, c’est ça. Vous donnez vos sources, Gemini les rend recherchables, puis il récupère les passages utiles au moment exact où le modèle en a besoin.

De quoi avez-vous besoin ?

Pour démarrer proprement, je garde la stack volontairement simple. Il vous faut Python 3.9 ou plus, le client Python google-genai à jour, une clé API Gemini, et un modèle compatible avec File Search, comme gemini-2.5-pro ou gemini-2.5-flash.

Découvrez égalementQuelle mémoire LLM choisir pour un agent IA fiable ?

Le client google-genai, c’est la librairie Python officielle qui permet d’appeler l’API Gemini depuis votre code. Dans notre cas, elle sert aussi à créer et gérer les File Search Stores. Un File Search Store, c’est l’espace où Gemini va stocker, indexer et rechercher dans vos documents pour construire une réponse augmentée par vos propres données.

L’installation se fait avec pip. Rien de spécial ici, je mets juste à jour le package pour éviter les comportements bizarres liés à une vieille version.

pip install google-genai -U

GOOGLE_API_KEY="votre_cle_api_gemini"

La clé API doit être disponible dans la variable d’environnement GOOGLE_API_KEY. Comme ça, votre code peut l’utiliser sans la mettre en dur dans un fichier Python. C’est plus propre, et ça évite de pousser une clé par accident dans un dépôt Git. Ça arrive plus souvent qu’on ne le pense.

Un point que je recommande vraiment avant d’uploader toute une base documentaire : je teste toujours avec quelques documents représentatifs. Pas 200 fichiers d’un coup. Trois ou quatre bons exemples suffisent souvent à voir si le découpage des documents, le retrieval, c’est-à-dire la récupération des bons passages, et les réponses tiennent la route. Chez un client, on a gagné deux jours juste en faisant ça avant l’import massif.

Comment créer un File Search Store ?

On crée un File Search Store avec le client Gemini, puis on choisit le modèle d’embedding adapté au type de contenu à indexer. C’est vraiment le point à ne pas rater. Si votre base contient uniquement du texte, gemini-embedding-001 peut suffire. Si vos documents mélangent texte et images, je pars sur models/gemini-embedding-2, parce qu’on est sur un store multimodal.

Un embedding, pour le dire simplement, c’est une représentation numérique du contenu. Le modèle transforme vos fichiers en vecteurs, et Gemini s’en sert ensuite pour retrouver les bons passages au moment de répondre. Si le modèle d’embedding ne comprend pas bien le type de contenu, votre RAG part avec un handicap dès le départ.

from google import genai

client = genai.Client()

store = client.file_search_stores.create(
    config={
        "display_name": "kb_produits_multimodal",
        "embedding_model": "models/gemini-embedding-2",
    }
)

print(store.name)

Le client, c’est votre point d’entrée vers l’API Gemini. Dans la plupart des projets, je le configure avec la clé API dans l’environnement, puis je garde le code simple. Le store, lui, c’est le conteneur qui va recevoir vos fichiers indexés. Vous pouvez le voir comme une base de connaissances dédiée à un usage précis.

Le display_name mérite un vrai nom, pas un truc du genre “test_12”. J’ai déjà vu des équipes se retrouver avec quinze stores impossibles à distinguer deux semaines plus tard. Un nom clair comme kb_produits_multimodal évite pas mal de confusion.

Le champ embedding_model fixe le modèle utilisé pour indexer les contenus. Ici, je choisis models/gemini-embedding-2 parce que je prépare un store capable de gérer des documents avec du texte et des images. Pour une base composée uniquement de PDF textuels, de pages HTML ou de fichiers texte, gemini-embedding-001 peut être le choix le plus direct.

Les données indexées restent disponibles jusqu’à suppression manuelle du store. C’est pratique pour construire une base de connaissances durable, surtout si vous ne voulez pas réindexer vos fichiers à chaque requête. Mais ça veut aussi dire qu’il faut nettoyer les stores obsolètes. Sinon, vous accumulez des bases inutiles, parfois avec des données qui ne devraient plus être là.

Avant de passer à l’upload des fichiers, je vérifie toujours ces points :

• Nommer clairement le store selon son usage réel.
• Choisir le bon modèle d’embedding selon les fichiers à traiter.
• Commencer petit avec quelques documents représentatifs.
• Prévoir une règle simple pour supprimer les stores obsolètes.

Comment interroger vos fichiers ?

Une fois les fichiers indexés, l’utilisateur pose une question, Gemini récupère les chunks pertinents dans le File Search Store et s’en sert pour produire une réponse contextualisée.

Le principe est assez simple. La question est transformée en embedding, c’est-à-dire une représentation numérique du sens de la phrase. Cette représentation est comparée aux embeddings des chunks déjà indexés. Un chunk, c’est juste un morceau de document, découpé pour être plus facile à retrouver et à injecter dans le contexte du modèle.

Gemini va chercher les passages les plus proches sémantiquement, pas juste les passages qui contiennent exactement les mêmes mots. C’est ça qui rend le RAG utile. Vous pouvez poser une question avec vos mots, et retrouver une règle, une clause, une procédure ou une information qui n’utilise pas forcément la même formulation.

Ensuite, le modèle génère sa réponse avec ce contexte récupéré. C’est le grounding. La réponse est “ancrée” dans vos documents, au lieu de s’appuyer uniquement sur les connaissances générales du modèle. Quand des citations ou références sont disponibles, elles servent à vérifier d’où vient l’information. Je reste volontairement prudent sur leur forme exacte, parce que ça dépend de ce que l’API expose dans votre cas, mais l’objectif est clair : rendre la réponse vérifiable.

Quelques questions utiles que je poserais en test dès le départ :

• “Résume ce rapport en 10 lignes, avec les risques principaux.”
• “Quelle est la règle interne sur les remboursements de frais ?”
• “Compare les recommandations du document A avec celles du document B.”
• “Retrouve dans les documents les passages qui parlent de conservation des données.”
• “Que montre cette image indexée, et quelles informations importantes peut-on en extraire ?”

Pour évaluer vite la qualité, je regarde trois choses. Les bons chunks remontent-ils vraiment ? La réponse reste-t-elle fidèle aux documents, sans broder ? Une même question reformulée donne-t-elle une réponse stable ? Chez un client, on avait de bonnes réponses en apparence, mais les passages récupérés étaient trop larges. On a réduit le périmètre de documents au début, puis on a ajusté le découpage. Tout est devenu beaucoup plus net.

Et maintenant, vous le branchez sur quel cas d’usage ?

Gemini API File Search enlève une grosse partie de la complexité d’un RAG : chunking, embeddings, stockage, recherche sémantique et injection du contexte. Je garde quand même un point en tête : l’outil ne remplace pas la qualité des documents ni les tests. Il faut choisir le bon modèle d’embedding, démarrer avec un périmètre propre, vérifier les réponses, puis élargir. C’est souvent comme ça que les projets tiennent en production. Le bénéfice pour vous est clair : vous construisez plus vite une recherche augmentée fiable, avec moins d’infrastructure à maintenir et plus de temps pour traiter le vrai besoin business.

FAQ

• Qu’est-ce que Gemini API File Search ?
  Gemini API File Search est une fonctionnalité qui permet à Gemini d’utiliser des fichiers privés comme contexte. Elle gère le découpage des documents, les embeddings, l’indexation et la recherche sémantique pour construire plus facilement un système RAG.
• Pourquoi utiliser File Search pour faire du RAG ?
  Je l’utiliserais quand je veux éviter de construire moi-même toute la couche technique autour du retrieval. L’API prend en charge l’essentiel de la mécanique : préparer les fichiers, retrouver les passages pertinents et aider Gemini à répondre avec du contexte utile.
• File Search fonctionne-t-il avec des images ?
  Oui, le fonctionnement peut être multimodal. Pour un store qui doit gérer texte et images, le modèle indiqué est models/gemini-embedding-2. Pour un usage texte, gemini-embedding-001 est mentionné comme modèle d’embedding dédié.
• Quels sont les prérequis techniques ?
  Il faut Python 3.9 ou plus, la bibliothèque google-genai installée avec pip install google-genai -U, et une clé API Gemini configurée dans GOOGLE_API_KEY. La clé doit permettre d’accéder à un modèle comme gemini-2.5-pro ou gemini-2.5-flash.
• Les données indexées restent-elles disponibles ?
  Oui, les données indexées dans un File Search Store restent disponibles jusqu’à suppression manuelle. C’est pratique pour une base de connaissances durable, mais ça veut aussi dire qu’il faut gérer proprement les stores qui ne servent plus.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres sur des sujets data, IA et automatisation très concrets. Si vous voulez connecter vos données internes à l’IA sans partir dans une architecture inutilement lourde, contactez-moi, je peux vous aider à cadrer et déployer ça proprement.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.