AI Overview / AI Mode - Deepdive

The integration of generative AI into Google Search follows a precise three-phase trajectory, each phase expanding the role of the LLM while narrowing the user's ability to opt out.

L'intégration de l'IA générative dans Google Search suit une trajectoire en trois phases, chacune élargissant le rôle du LLM tout en réduisant la possibilité pour l'utilisateur de ne pas y être exposé.

AIO and AIM share the same Gemini model family and the same grounding logic, but they differ on nearly every other technical dimension. The table below reflects what we observe from parsed SERP data and confirmed public sources.

AIO et AIM partagent la même famille de modèles Gemini et la même logique de grounding, mais ils diffèrent sur presque toutes les autres dimensions techniques. Le tableau ci-dessous reflète ce que nous observons à partir des données parsées de la SERP et des sources publiques confirmées.

Both AIO and AIM follow a RAG pattern: the model searches first, then generates a response anchored in the retrieved results. Google Cloud defines grounding as "the ability to connect model output to verifiable sources of information," which "reduces the chances of inventing content." The Firebase documentation states explicitly: "Grounding with Google Search solves this problem by allowing Gemini to perform a real-time search before it generates an answer."

The patent US11769017B1 ("Generative Summaries for Search Results," filed March 2023, granted September 2023) describes this pipeline: the system receives a query, selects Search Result Documents (SRDs), extracts content snippets, and processes them via an LLM to generate a natural-language summary. A notable detail: the system has multiple candidate generative models and dynamically selects one based on query classification and result types.

Dan Petrovic's analysis of this accidental leak (May 2025) provided deep insights into Gemini's internal grounding process, confirming and expanding earlier findings from his series on Gemini's grounding decision process. During a test scenario, Gemini inadvertently disclosed its internal indexing mechanism: responses included marks like [6.2], where the first digit identifies which search query was executed (e.g., the 6th) and the second identifies which result from that query is referenced (e.g., the 2nd). This maps directly to Gemini's internal GoogleSearch.PerQueryResult(index='6.2', ...) function calls.

This proves the model maintains an ordered cache of retrieval results, not just raw text blobs, but a granular, structured index with a precise mapping between each claim and its source. The leak also revealed Gemini's core operational loop: a Thinking stage (analyzing the query, planning tool calls) followed by an Action stage (executing Google Search or Conversation Retrieval tools, then synthesizing the response). Every fact must be externally verified via built-in tools before being served to the user. Gemini is explicitly instructed to never rely on its internal knowledge alone.

This aligns with what our plugin captures at the HTML level: the grounding URLs, the position fields in citation data, and the text fragment directives all reflect this same structured retrieval-then-verify pipeline that Dan Petrovic exposed from the model's internal perspective.

The grounding URLs are not all visible to users. Our parsed data reveals three distinct layers:

• Layer 1: Visible sidebar ("19 sites" / "Show all"). The sources users see when they expand the sidebar panel.
• Layer 2: In-text citations (text fragments). Small superscript numbers in the AI text, linking to specific passages on source pages.
• Layer 3: Hidden grounding URLs. URLs the model consulted but Google chose not to display. Only present in inline scripts, never in the visible page.

Real numbers from our captures illustrate the gap between visible and hidden sources:

For AIO specifically, the Grounding → Pool → Displayed pipeline is the observable manifestation of this RAG architecture. Each transition involves filtering and reranking. Some citations end up "rejected": the model generated text that couldn't be properly attributed back to those sources.

Google Search Central confirms the eligibility criteria: "To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet. There are no additional technical requirements."

AIO comme AIM suivent un pattern RAG : le modèle cherche d'abord, puis génère une réponse ancrée dans les résultats récupérés. Google Cloud définit le grounding comme « la capacité de relier la sortie du modèle à des sources d'information vérifiables », ce qui « réduit les risques d'inventer du contenu ». La documentation Firebase indique explicitement : « Le grounding avec Google Search résout ce problème en permettant à Gemini d'effectuer une recherche en temps réel avant de générer une réponse. »

Le brevet US11769017B1 (« Generative Summaries for Search Results », déposé mars 2023, accordé septembre 2023) décrit ce pipeline : le système reçoit une requête, sélectionne des Search Result Documents (SRDs), en extrait des snippets, puis les traite via un LLM pour produire un résumé. Un détail notable : le système dispose de plusieurs modèles génératifs candidats et sélectionne dynamiquement le plus adapté selon la classification de la requête.

L'analyse de Dan Petrovic de cette fuite accidentelle (mai 2025) a fourni un éclairage profond sur le processus interne de grounding de Gemini, confirmant et élargissant ses découvertes antérieures dans sa série sur le processus de décision de grounding de Gemini. Lors d'un scénario de test, Gemini a involontairement révélé son mécanisme d'indexation interne : les réponses contenaient des marqueurs comme [6.2], où le premier chiffre identifie la requête de recherche exécutée (ex. la 6ème) et le second identifie le résultat référencé dans cette requête (ex. le 2ème). Cela correspond directement aux appels internes GoogleSearch.PerQueryResult(index='6.2', ...) de Gemini.

Cela prouve que le modèle maintient un cache ordonné des résultats de récupération, pas de simples blocs de texte brut, mais un index granulaire et structuré avec un mapping précis entre chaque affirmation et sa source. La fuite a également révélé la boucle opérationnelle de Gemini : une étape de Réflexion (analyse de la requête, planification des appels d'outils) suivie d'une étape d'Action (exécution de Google Search ou Conversation Retrieval, puis synthèse de la réponse). Chaque fait doit être vérifié via les outils intégrés avant d'être présenté à l'utilisateur. Gemini a l'instruction explicite de ne jamais se fier uniquement à ses connaissances internes.

Cela rejoint ce que notre plugin capture au niveau HTML : les URLs de grounding, les champs position dans les données de citations, et les directives de text fragments reflètent tous ce même pipeline structuré de récupération-puis-vérification que Dan Petrovic a exposé depuis la perspective interne du modèle.

Les URLs de grounding ne sont pas toutes visibles pour l'utilisateur. Nos données parsées révèlent trois couches distinctes :

• Couche 1 : Sidebar visible (« 19 sites » / « Tout afficher »). Les sources que l'utilisateur voit quand il déplie le panneau latéral.
• Couche 2 : Citations dans le texte (text fragments). Petits numéros en exposant dans le texte IA, pointant vers des passages spécifiques sur les pages sources.
• Couche 3 : URLs de grounding cachées. URLs consultées par le modèle mais que Google choisit de ne pas afficher. Présentes uniquement dans les scripts inline, jamais dans la page visible.

Des chiffres issus de nos captures illustrent l'écart entre sources visibles et cachées :

Pour AIO en particulier, le pipeline Grounding → Pool → Affiché est la manifestation observable de cette architecture RAG. Chaque transition implique du filtrage et du reranking. Certaines citations finissent « rejetées » : le modèle a produit du texte qui ne pouvait pas être correctement attribué à ces sources.

Google Search Central confirme les critères d'éligibilité : « Pour apparaître comme lien de support dans les AI Overviews ou AI Mode, une page doit être indexée et éligible à l'affichage dans Google Search avec un snippet. Il n'y a pas d'exigences techniques supplémentaires. »

During the DOJ v. Google antitrust remedies trial (April-May 2025), an internal retrieval system called FastSearch was described under sworn testimony. Paragraph 44 of Judge Mehta's Memorandum Opinion states:

RankEmbed is an AI-based deep-learning system trained on click-and-query data and human quality rater scores. The Memorandum Opinion adds that it "has strong natural-language understanding" and "allows the model to more efficiently identify the best documents to retrieve, even if a query lacks certain terms."

Several hypotheses remain open:

• AIO and AIM may use FastSearch as described in the trial.
• Google may have a dedicated, higher-quality retrieval system for its own Search products, while offering the faster/lighter FastSearch to third-party developers via the Vertex AI Grounding with Google Search API.
• AIO sometimes appears to use standard organic results directly as grounding sources (citation overlap with organic results can be high for certain queries).
• The retrieval system may differ between AIO and AIM, or vary by query type.

Our working hypothesis: Google likely uses higher-quality retrieval data than FastSearch for AIO and AIM, sourced from its Mustang index and sent to Superroot after passing through RankEmbed BERT. These results would constitute the information retrieval (IR) phase where the engine selects an initial list of dozens to hundreds of candidate results, before the final reranking by Twiddlers. The grounding URLs visible in our parsed data appear to be already filtered from this initial list: the position field values in citation entries are non-contiguous, confirming that not all candidates are retained.

What the DOJ trial does confirm, regardless of the exact pipeline: the retrieval layer for AI grounding operates independently from traditional web ranking. Our data consistently shows that many grounding URLs don't appear in organic results, and vice versa.

Lors du procès antitrust DOJ v. Google (remedies trial, avril-mai 2025), un système de récupération interne appelé FastSearch a été décrit sous serment. Le paragraphe 44 du Memorandum Opinion du juge Mehta indique :

RankEmbed est un système de deep learning entraîné sur des données de clicks et de requêtes et sur des scores d'évaluateurs humains. Le Memorandum Opinion précise qu'il « possède une forte compréhension du langage naturel » et « permet au modèle d'identifier plus efficacement les documents pertinents, même lorsque la requête ne contient pas certains termes ».

Plusieurs hypothèses restent ouvertes :

• AIO et AIM pourraient utiliser FastSearch tel que décrit lors du procès.
• Google pourrait disposer d'un système de récupération dédié et de meilleure qualité pour ses propres produits Search, tout en offrant FastSearch (plus rapide mais plus léger) aux développeurs tiers via l'API Vertex AI Grounding with Google Search.
• AIO semble parfois utiliser directement les résultats organiques standard comme sources de grounding (le recouvrement avec les résultats organiques peut être élevé pour certaines requêtes).
• Le système de récupération pourrait différer entre AIO et AIM, ou varier selon le type de requête.

Notre hypothèse de travail : Google utilise probablement des données de retrieval de meilleure qualité que FastSearch pour AIO et AIM, issues de son index Mustang et envoyées à Superroot après passage par RankEmbed BERT. Ces résultats constitueraient la phase d'information retrieval (IR) où le moteur sélectionne une liste initiale de quelques dizaines à quelques centaines de résultats candidats, avant le reranking final par les Twiddlers. Les URLs de grounding visibles dans nos données parsées semblent déjà filtrées depuis cette liste initiale : les valeurs du champ position dans les entrées de citation sont non contiguës, confirmant que tous les candidats ne sont pas retenus.

Ce que le procès DOJ confirme, indépendamment du pipeline exact : la couche de récupération pour le grounding IA opère de manière indépendante du ranking web traditionnel. Nos données montrent systématiquement que beaucoup d'URLs de grounding n'apparaissent pas dans les résultats organiques, et inversement.

Query fan-out is the process where Gemini decomposes a user query into multiple parallel sub-queries to broaden retrieval coverage. It is the core architectural differentiator of AI Mode.

Le query fan-out est le processus par lequel Gemini décompose une requête utilisateur en plusieurs sous-requêtes parallèles pour élargir la couverture de récupération. C'est le différenciateur architectural central d'AI Mode.

Liz Reid defined fan-out officially at Google I/O 2025: "Under the hood, Search recognizes when a question needs advanced reasoning. It calls on our custom version of Gemini to break the question into different subtopics, and it issues a multitude of queries simultaneously on your behalf." Robby Stein, VP of Product, added: "The custom version of Gemini 2.0 uses a multistep approach to make a plan, conduct searches to find information and adjust the plan based on what it finds."

Liz Reid a défini le fan-out officiellement lors de Google I/O 2025 : « Sous le capot, Search reconnaît quand une question nécessite un raisonnement avancé. Il fait appel à notre version personnalisée de Gemini pour décomposer la question en sous-thèmes, et lance une multitude de requêtes simultanément pour le compte de l'utilisateur. » Robby Stein, VP of Product, a ajouté : « La version personnalisée de Gemini 2.0 utilise une approche multi-étapes pour établir un plan, effectuer des recherches, et ajuster le plan en fonction de ce qu'elle trouve. »

AI responses are enriched with structured entity data from multiple Google knowledge systems. Our inspector reveals four distinct entity types:

Les réponses IA sont enrichies par des données d'entités structurées provenant de plusieurs systèmes de connaissance Google. Notre inspecteur révèle quatre types distincts :

Entity enrichment varies between the two products. AIO uses primarily the Knowledge Graph. AIM draws from a broader set: Knowledge Graph, Shopping Graph (50+ billion product listings), and Maps/Places entities.

A practical observation from our captures: not all entities mentioned in the generated text receive a KG link. For a culture query on impressionism, Monet, Renoir, and Degas are all mentioned in the response but none receive a KG entity link. The model knows about them from grounding text, not from the Knowledge Graph.

L'enrichissement par entités varie entre les deux produits. AIO utilise principalement le Knowledge Graph. AIM puise dans un ensemble plus large : Knowledge Graph, Shopping Graph (50+ milliards de fiches produits), et entités Maps/Places.

Une observation concrète de nos captures : toutes les entités mentionnées dans le texte généré ne reçoivent pas un lien KG. Pour une requête culturelle sur l'impressionnisme, Monet, Renoir et Degas sont tous mentionnés dans la réponse mais aucun ne reçoit de lien KG. Le modèle les connaît via le texte de grounding, pas via le Knowledge Graph. La couverture entité est inégale et semble dépendre de la verticale de la requête.

Every Gemini version deployed in Search is described by Google as a "custom" variant, fine-tuned for search tasks. The pace of model upgrades has direct consequences on what we observe in parsed data.

Chaque version de Gemini déployée dans Search est décrite par Google comme une variante « custom », fine-tunée pour les tâches de recherche. Le rythme des mises à jour de modèle a des conséquences directes sur ce que nous observons dans les données parsées.

Since November 2025, Google uses intelligent routing: multiple model variants serve different queries simultaneously. Simple factual queries receive Gemini 3 Flash (fast, lightweight). Complex multi-step queries are escalated to Gemini 3 Pro. Google announced: "Search will intelligently route your most challenging questions in AI Mode and AI Overviews to this frontier model, while continuing to use faster models for simpler tasks."

From a parsing perspective, there is no way to detect which model served a given response from the client side. No model name appears in network requests, headers, response data, or CSI timing metrics. The model identifier is entirely server-side.

Depuis novembre 2025, Google utilise le routage intelligent : plusieurs variantes de modèle servent différentes requêtes simultanément. Les requêtes factuelles simples reçoivent Gemini 3 Flash (rapide, léger). Les requêtes complexes multi-étapes sont escaladées vers Gemini 3 Pro. Google a annoncé : « Search routera intelligemment vos questions les plus complexes dans AI Mode et AI Overviews vers ce modèle frontier, tout en continuant à utiliser des modèles plus rapides pour les tâches simples. »

Du point de vue du parsing, il est impossible de détecter quel modèle a servi une réponse donnée côté client. Aucun nom de modèle n'apparaît dans les requêtes réseau, les headers, les données de réponse ou les métriques CSI. L'identifiant de modèle est entièrement côté serveur.

Google's official documentation (May 2025) describes an architecture with multiple overlapping safety layers for AI Overviews. AI Mode adds specific mechanisms tied to its conversational nature.

La documentation officielle de Google (mai 2025) décrit une architecture à couches de sécurité multiples pour les AI Overviews. AI Mode ajoute des mécanismes spécifiques liés à sa nature conversationnelle.

For AI Mode specifically, Google uses agentic reinforcement learning (in collaboration with DeepMind) that rewards the model for generating statements that are more likely to be accurate and backed up by retrieved sources rather than hallucinated.

The Search Quality Rater Guidelines were updated in September 2025 to include evaluation examples for AI Overviews for the first time. Raters now assess the accuracy of the information, the attribution of sources cited, and the overall usefulness of the summary.

Pour AI Mode en particulier, Google utilise l'apprentissage par renforcement agentique (en collaboration avec DeepMind) qui récompense le modèle pour générer des affirmations plus susceptibles d'être exactes et étayées par les sources récupérées, plutôt qu'hallucinées.

Les Search Quality Rater Guidelines ont été mises à jour en septembre 2025 pour inclure pour la première fois des exemples d'évaluation des AI Overviews. Les évaluateurs jugent désormais l'exactitude de l'information, l'attribution des sources citées, et l'utilité globale du résumé.

Patent US12013887B2 (granted June 2024) describes an information gain score: a value between 0 and 1 measuring how much new information a document brings relative to what already exists. The score is session-aware: it evaluates each document's informational potential based on what the user has already consulted during their browsing session.

If implemented in AI search systems, the consequences are direct: the sources cited in AI Overviews and AI Mode could vary and diversify as a user researches a topic across successive queries. A page cited in the first AI Overview might give way to a different source in a follow-up query, if the latter offers higher information gain relative to content already consumed. This session-based logic is particularly aligned with AI Mode's multi-turn conversational architecture.

Whether Information Gain is active in production remains unconfirmed. But the patent's timing (mid-2024, as AI-generated content proliferates) and its focus on detecting semantic redundancy across differently worded but substantively identical content suggest it could serve as a filtering mechanism against the homogenization of search results.

Le brevet US12013887B2 (accordé juin 2024) décrit un score de gain d'information : une valeur entre 0 et 1 mesurant la quantité d'information nouvelle qu'un document apporte par rapport à ce qui existe déjà. Le score est contextuel à la session : il évalue le potentiel informatif de chaque document en fonction de ce que l'utilisateur a déjà consulté pendant sa navigation.

S'il est implémenté dans les systèmes de recherche IA, les conséquences sont directes : les sources citées dans les AI Overviews et AI Mode pourraient varier et se diversifier au fil des requêtes successives d'un utilisateur sur un sujet. Une page citée dans le premier AI Overview pourrait céder la place à une source différente dans une requête suivante, si cette dernière offre un gain d'information supérieur par rapport au contenu déjà consommé. Cette logique de session est particulièrement alignée avec l'architecture conversationnelle multi-tours d'AI Mode.

L'activation effective de l'Information Gain en production n'est pas confirmée. Mais le timing du brevet (mi-2024, en pleine prolifération des contenus générés par IA) et son focus sur la détection de la redondance sémantique entre des contenus formulés différemment mais substantiellement identiques suggèrent qu'il pourrait servir de mécanisme de filtrage contre l'homogénéisation des résultats de recherche.