Google a tué la fenêtre de contexte.

Les fenêtres contextuelles de million de tokens étaient censées être le code secret pour les grands modèles de langage. Les fournisseurs se sont précipités pour annoncer des invites de 128K, 200K, voire 1M de tokens comme si la simple capacité suffisait à débloquer des copilotes de codage fiables, des agents autonomes et des bases de connaissances entièrement consultables. La réalité a été moins cinématographique : plus de tokens signifie souvent simplement des modèles plus lents, plus chers et toujours confus.

La dernière recherche de Google sur l'ingénierie du contexte révèle la supercherie. L'entreprise soutient que "lancer plus de jetons sur le problème ne fait que prolonger le temps, mais cela ne change pas la forme de la courbe" en ce qui concerne le coût, la latence et la fiabilité. Vous pouvez échapper brièvement à la complexité avec une fenêtre de 1 million de jetons, mais les charges de travail réelles—résultats RAG, journaux multi-agents, sorties d'outils et historique des utilisateurs—rattraperont rapidement.

Trois limites strictes font échouer la stratégie du « juste faire le stuffing de l'invite ». La première est la spirale des coûts et de la latence : chaque tranche supplémentaire de 100K tokens augmente le temps d'inférence et les factures cloud, souvent de 2 à 3 fois dans des applications à grande échelle. La deuxième est « perdu au milieu », un effet documenté où les modèles ignorent les instructions cruciales enfouies dans des invites surchargées. La troisième est la physique : même les fenêtres d'un million de tokens débordent dès que vous commencez à enchaîner des outils et des agents sur des heures ou des jours.

La réponse de Google n'est pas « 2 millions de jetons », mais un pivot architectural. Au lieu de considérer le contexte comme un gigantesque journal de discussion modifiable, l'entreprise le présente comme une vue compilée sur un système plus riche et avec état. Les données brutes - sessions, souvenirs, artefacts - agissent comme du code source ; un pipeline de processeurs compile un contexte de travail minimal et spécifique à la tâche pour chaque appel de modèle.

Ce changement transforme le contexte d'un problème de mise en tampon brutale en un problème de conception de systèmes. Le Kit de développement d'agent (ADK) de Google intègre cela dans une pile à quatre couches : contexte de travail, session, mémoire et artefacts, chacun ayant des responsabilités et des cycles de vie clairs. Le contexte cesse d'être « tout ce qui rentre dans la fenêtre » et devient un produit explicite de code, de politiques et de portées.

Cet article explique comment ce cadre fonctionne réellement en production. En utilisant le Google Agent Development Kit (ADK), nous allons décomposer l'architecture contextuelle, les différents objets contextuels et autorisations, ainsi qu'un véritable agent de recherche documentaire qui montre pourquoi l'ère du million de tokens est déjà révolue.

Des fenêtres contextuelles plus grandes promettent l’omniscience mais entraînent surtout un choc tarifaire. Chaque 100 000 tokens supplémentaires ajoutent des coûts réels et des secondes, et les équipes de production ressentent les deux. Le blog sur l’ingénierie contextuelle de Google décrit une spirale coût/latence : plus de tokens par appel, multipliés par des milliers d'utilisateurs simultanés, transforme une “belle démo” en un “budget explosé” rapidement.

La latence se développe tout aussi brutalement. Ce prompt d'un million de tokens signifie un décodage plus lent, des chaînes d'outils plus longues, et une expérience utilisateur qui dérive de "assistant" vers "système de billetterie". Dans des configurations multi-agents, chaque appel d'agent entraîne davantage d'appels au modèle, de sorte qu'un contexte encombré infecte l'ensemble d'un pipeline.

Ensuite vient Perdus au Milieu. Les LLM n’accordent pas une attention uniforme aux longues invites ; ils ont souvent tendance à privilégier le début et la fin, tout en ignorant silencieusement le centre. Le blog de Google et le travail qui a suivi montrent que la précision diminue lorsque des faits clés se trouvent enfouis au milieu d'une longue séquence, même lorsque le modèle "voit" techniquement tout.

Imaginez le message d'un agent de production après quelques minutes d'utilisation. En haut : une question d'utilisateur fraîche. En bas : une erreur d'outil récente et une instruction de réessai. Coincé au milieu : la contrainte de politique réelle ou l'instruction critique du système. Le modèle optimise joyeusement autour des contours et hallucine au-delà de ce qui importe réellement.

Des charges de travail réelles aggravent cela. Un seul tour peut inclure : - 20 à 50 passages RAG - 5 à 10 journaux d'appels d'outils - Des dizaines de messages de chat précédents

Mettez tout cela dans un modèle prêt pour 1 million de tokens et la fenêtre de contexte se bloque toujours après quelques interactions riches. Même les démonstrations du Google Agent Development Kit (ADK) montrent à quel point les artefacts, la mémoire et l'état de session exploseraient rapidement si vous introduisiez naïvement tout dans l'invite.

Les limites physiques strictes achèvent le travail. La longueur du contexte évolue de manière sublinéaire avec le calcul et la mémoire ; passer de 128K à 1M de tokens nécessite déjà une infrastructure exotique. Allez beaucoup plus haut et vous devrez lutter contre la RAM des GPU, la bande passante et la stabilité de l'entraînement, et pas seulement contre une conception astucieuse des invites.

Ce ne sont pas des curiosités de laboratoire. Ce sont les raisons pour lesquelles les équipes de production limitent discrètement l'histoire, tronquent les résultats RAG et résument de manière agressive. Tant que le contexte ne cessera pas d'être un flux brut et ne deviendra pas une vue compilée, les grands agents continueront à s'étouffer dans leurs propres données.

La nouvelle idée de compilateur de contexte de Google rejette l'ancien modèle mental d'une fenêtre de contexte en tant que journal de discussion sans fond. Au lieu d'un tampon de flux mutable, le contexte devient une vue compilée sur un état beaucoup plus riche : des sessions, des souvenirs et des artefacts qui existent en dehors de tout prompt unique. Chaque appel au modèle ne voit qu'une tranche soigneusement construite, et non la totalité de la botte de foin.

Pensez comme un ingénieur de compilateur, pas comme un ajusteur de prompt. Les données d'interaction brutes deviennent le code source ; un pipeline de processeurs agit comme le compilateur ; le prompt final envoyé à Gemini est l'exécutable optimisé. Le blog de Google, Architecting efficient context-aware multi-agent framework for production, précise cela comme une exigence stricte pour les agents à l'échelle de production, et non comme une abstraction supplémentaire.

Dans ce modèle, le rôle du développeur passe de « comment formuler cette demande ? » à « comment concevoir le pipeline qui construit le contexte ? » Vous concevez comment les sessions stockent des événements structurés, comment les souvenirs codent des connaissances à long terme, et comment des artefacts tels que des PDFs ou des CSV sont référencés par ID au lieu d'être simplement affichés dans la fenêtre. Vous cessez de créer manuellement des méga-demandes et commencez à définir des flux, des processeurs et des portées.

Le Kit de Développement d'Agents Google (ADK) intègre cela dans ses API. Il expose des couches de contexte distinctes—contexte de travail, session, mémoire, artéfacts—et vous oblige à les connecter à travers des processeurs explicites et des préfixes d'état comme `app`, `user` et `temp`. Cette séparation du stockage et de la présentation signifie que vous pouvez enregistrer des milliers d'événements tout en émettant une invite concise et ciblée de moins de 5 000 tokens.

La puissance provient de l'étendue par défaut. Chaque invocation de modèle reçoit uniquement le contexte minimal nécessaire à sa tâche, assemblé juste à temps par la chaîne de compilation. Si un agent a besoin de plus d'informations, il appelle des outils pour récupérer des artefacts ou interroger la mémoire, au lieu de tout précharger « au cas où ».

Cette approche de contexte compilé touche aux trois points de douleur simultanément. Le nombre de tokens diminue, et par conséquent, les coûts et la latence diminuent également. La situation de "perdu au milieu" se réduit car le milieu disparaît presque entièrement : un historique non pertinent n'entre jamais dans le contexte de travail. Les limites de contexte physique cessent d'être un plafond rigide et deviennent un budget d'optimisation que vous contrôlez par le biais du code.

L'ingénierie de contexte commence par une séparation claire entre l'endroit où se trouve l'information et la manière dont le modèle la perçoit. Le Kit de développement d'agent (ADK) de Google intègre cela dans son premier principe : séparer le stockage de la présentation. Cela peut sembler abstrait, mais c'est la différence entre un système que vous pouvez faire évoluer et un autre qui s'effondre sous son propre transcript.

ADK trace une ligne de démarcation claire entre la Session et le Contexte de Travail. La Session fonctionne comme le registre persistant et autoritaire : chaque message utilisateur, invocation d'outil, résultat d'outil et événement système y est enregistré sous forme d'état structuré. Le Contexte de Travail est un instantané jetable créé pour un appel LLM unique, puis abandonné.

Considérez la Session comme votre base de données et le Contexte de Travail comme un résultat de requête SQL. Vous ne modifiez jamais la base de données pour correspondre à chaque requête ; vous changez la requête. La même idée s'applique ici : vous conservez une Session complète, en mode ajout uniquement, et compilez différents Contextes de Travail à partir de celle-ci en fonction de la tâche, du modèle ou du budget de latence.

Cette séparation devient cruciale au moment où votre produit évolue. Vous souhaitez échanger le Gemini 3 Pro contre un modèle plus petit, ou passer d'une invite de type conversationnel à une invite d'exécution concise ? Vous mettez à jour les processeurs qui construisent le Contexte de Travail, et non le schéma de Session ou les données historiques. Les interactions passées restent intactes, même si vous modifiez radicalement la manière dont vous les présentez au modèle.

La documentation du Google Agent Development Kit (ADK) officialise cela avec des objets de contexte distincts et des préfixes d'état. L'état soutenu par la session vit sous des préfixes durables comme `app` et `user`, tandis que les données éphémères, uniquement liées à l'invocation, vivent sous `temp`. Seul le Contexte de Travail lit à travers ces espaces de noms et compile une vue minimale pour l'appel en cours.

L'impact pratique se manifeste rapidement dans les systèmes multi-agents. Un agent peut percevoir un Contexte de Travail avec seulement les 3 derniers échanges de l'utilisateur et un résumé d'outil ; un autre peut obtenir un résumé synthétisé d'une Session de 200 messages, plus les résultats RAG. Les deux proviennent du même enregistrement sous-jacent, mais chaque appel ne paie que pour les jetons réellement nécessaires.

Les fenêtres de contexte utilisées pour croître par concaténation de chaînes : message de l'utilisateur, réponse de l'agent, sortie de l'outil, répétée jusqu'à ce que la facture explose. Le Kit de Développement d'Agents Google (ADK) supprime cela et le remplace par des Transformations Explicites : un pipeline nommé et ordonné qui compile l'état brut en un prompt fonctionnel. Le contexte cesse d'être un amas de texte pour devenir un artefact de construction.

Au lieu de `prompt = history + docs + tools`, vous définissez des processeurs comme `résumer_session`, `sélectionner_artéfacts_relevants`, `injecter_instructions`, et `budgétiser_tokens`. Chaque étape a un nom, un contrat et une place dans le pipeline. Vous pouvez enregistrer chaque étape, comparer les résultats entre les exécutions, et échanger des processeurs sans toucher au reste du système.

Le blog de contexte de Google et les documents ADK décrivent cela comme un flux de processeurs qui transforment quatre couches d'état : session, mémoire, artefacts et contexte de travail. Un agent de recherche documentaire, par exemple, pourrait : - Récupérer des décisions antérieures de la mémoire - Classer les PDF candidats parmi les artefacts - Compresser les citations en un résumé de 2 000 tokens - Émettre une invite minimale pour Gemini 3 Pro

Parce que les processeurs sont explicites, les équipes peuvent les tester unitairement. Vous pouvez affirmer que `select_relevant_artifacts` ne récupère jamais plus de 5 documents, ou que `summarize_session` reste en dessous de 1 000 jetons. Le débogage cesse d'être « pourquoi le modèle a-t-il halluciné ? » et commence à être « quel processeur a injecté les mauvaises données ? »

Ciblé par Défaut s'attaque à l'autre moitié du problème : qui voit quoi. Au lieu de déverser l'intégralité de la transcription multi-agent dans chaque appel d'outil, ADK achemine un contexte minimal, spécifique au rôle via des objets de contexte typés. Les outils, les rappels et les fournisseurs d'instructions ont chacun une vue restreinte.

Les fonctions des outils reçoivent un ToolContext qui peut lire et écrire l'état de la session, sauvegarder ou charger des artefacts, et rechercher dans la mémoire. Les gestionnaires de rappels obtiennent un CallbackContext avec l'état et les artefacts, mais sans possibilité de recherche dans la mémoire, ce qui évite le chaos des canaux collatéraux. Les fournisseurs d'instructions voient un contexte en lecture seule, de sorte qu'ils ne peuvent pas modifier secrètement l'état tout en générant des invites système.

Le contexte défini transforme les systèmes multi-agents en une ligne de production d'IA. Une étape lit les artefacts et produit un résumé structuré ; une autre étape, ayant un champ d'application plus restreint, transforme ce résumé en prose destinée à l'utilisateur ; une troisième étape enregistre les résultats dans la mémoire. Aucun agent unique ne transporte l'intégralité de l'historique de 50 000 tokens.

Ensemble, les Transformations Explicites et les Portées par Défaut produisent des flux de contexte qui sont prévisibles sous charge. Vous savez exactement quels processeurs s'exécutent, quel état ils peuvent toucher et combien de jetons ils émettent. Cette discipline est ce qui rend un modèle d'un million de jetons optionnel plutôt que obligatoire.

Les agents sensibles au contexte dans le Google Agent Development Kit (ADK) fonctionnent sur une architecture à quatre niveaux qui considère le contexte comme un produit, et non comme un effet secondaire. Chaque niveau répond à une question différente : ce que le modèle perçoit actuellement, ce qui s'est réellement passé, ce qui doit persister et où se trouvent les ressources lourdes.

En haut se trouve le contexte de travail. C'est la charge temporaire et étroite que l'ADK compile et expédie à Gemini pour un seul appel de modèle : messages sélectionnés, résultats d'outils, extraits de mémoire et quelques références à des artefacts. L'ADK le rejette immédiatement après l'invocation, donc rien dans le contexte de travail n'est autoritaire en soi.

Sous cela se trouve la session, le journal canonique et de longue durée d'une interaction. Chaque message de l'utilisateur, réponse du modèle, appel d'outil et résultat d'outil se retrouve ici sous forme d'objet d'événement structuré, et non sous forme de transcription plate. Lorsque l'ADK reconstruit un contexte de travail, il interroge cette chronologie de session et applique des processeurs qui filtrent, résument ou réorganisent les événements pour la tâche en cours.

Des connaissances de longue durée passent dans la mémoire. La mémoire conserve les préférences des utilisateurs (ton, langues, habitudes de notification), des faits durables (politiques d'entreprise, spécifications de produits) et des décisions distillées qui devraient survivre à n'importe quel chat individuel. ADK met cela en avant grâce aux API de recherche par mémoire, permettant à un agent d'extraire uniquement les 3 à 10 éléments pertinents au lieu de rejouer 10 000 tokens d'historique.

Les artéfacts résolvent le problème du « fichier géant dans l'invite ». Ce sont de grands objets binaires ou texte—PDF, CSV, images, fichiers audio—stockés une fois et adressés par des noms ou ID stables, et non collés dans l'invite. Les outils lisent et écrivent des artéfacts, et le contexte de travail ne conserve que des références légères ainsi que des extraits lorsque cela est nécessaire.

Ensemble, ces quatre couches forment un pipeline contextuel, et non un monolithe. Un agent de recherche documentaire, par exemple, pourrait : lire la session pour trouver la dernière question de l'utilisateur, rechercher dans la mémoire les décisions antérieures, charger un artefact PDF par ID, puis compiler un contexte de travail avec seulement quelques paragraphes et citations pertinents. Le coût et la latence évoluent en fonction de ce segment compilé, et non du corpus brut.

Les recommandations de Google incitent les équipes à considérer ces couches comme des surfaces de conception de première classe. La Documentation de Contexte ADK précise comment le contexte de travail, la session, la mémoire et les artefacts se traduisent par des types concrets, des permissions et des processeurs, afin que les systèmes multi-agents restent rapides, économiques et ancrés à mesure que les charges de travail augmentent.

L'État rend une intelligence artificielle persistante plutôt que de lui donner l'esprit d'un poisson rouge, et le Google Agent Development Kit (ADK) l'intègre directement dans son API de contexte avec un système de préfixes à première vue simple. Au lieu de fournir aux agents un amas amorphe de « mémoire », l'ADK divise l'état en espaces de noms temp :, user : et app : qui correspondent clairement à la façon dont un véritable logiciel fonctionne réellement.

temp : Commencez par temp :, le carnet de notes. Tout ce que vous écrivez sous `temp:` ne vit que pour une seule invocation et disparaît ensuite. Un outil peut enregistrer un CSV analysé sous `temp:parsed_doc`, un autre outil peut le lire 200 ms plus tard, et une fois que l'agent a répondu, ADK l'efface - aucun risque de polluer l'historique à long terme avec des déchets intermédiaires.

Montez d'un niveau et user : devient la mémoire réelle d'une personne pour l'agent. Des clés comme `user:niveau_de_lecture`, `user:last_projects`, ou `user:sources_bloquées` persistent à travers les sessions tant que vous connectez ADK à un magasin de données. Un assistant de recherche intégré dans la démo peut se souvenir des articles qu'un utilisateur a déjà résumés la semaine dernière et éviter de les refetcher ou de les réexpliquer.

Au sommet se trouve app :, l'état global pour l'ensemble du déploiement. Les fonctionnalités ( `app:enable_vision` ), les limites de taux à l'échelle du système, ou les références d'index d'embeddings partagés résident tous ici. Chaque instance d'agent et chaque utilisateur peuvent lire ces valeurs, vous pourrez donc modifier une configuration en une fois et observer le changement de comportement à travers des centaines de sessions concurrentes.

Ensemble, ces trois préfixes vous offrent une hiérarchie d'état concrète sans inventer un cadre personnalisé. Vous obtenez : - temp : pour le câblage par tour entre les outils - user : pour la mémoire par identité - app : pour la configuration inter-utilisateurs

Cette hiérarchie encode directement les principes de design d'ADK. Séparer le stockage de la présentation : l'état vit sous `temp:`, `user:` ou `app:`, tandis que le contexte de travail est une tranche compilée de ces clés. Transformations explicites : les outils et les processeurs lisent et écrivent des préfixes spécifiques au lieu de muter un prompt géant. Scoped par défaut : `temp:` ne fuit jamais au-delà d'un tour, `user:` ne devient jamais accidentellement global, et `app:` ne se transforme jamais silencieusement en un comportement spécifique à l'utilisateur.

Le Kit de Développement d'Agents Google (ADK) transforme toute cette théorie du contexte en un bot de recherche fonctionnel. La démonstration de Yeyu Lab construit un assistant de documents qui peut rechercher, ouvrir et analyser des fichiers sans jamais intégrer des PDF entiers dans l'invite. Au lieu de cela, il compile juste assez de contexte pour chaque appel Gemini 1.5 ou Gemini 2.0.

Au cœur du design se trouve un modèle de chargement à la demande. L'outil `list_documents` renvoie uniquement des métadonnées légères : identifiants de documents, titres, peut-être tailles en octets et horodatages. Le modèle voit une table compacte d'options, et non 200 pages de texte brut.

Lorsque l'utilisateur choisit quelque chose comme "analyser le rapport trimestriel", l'agent appelle `analyze_document`. Cet outil extrait le fichier complet du stockage des artefacts, effectue un découpage ou un résumé, et ne présente ensuite les résultats distillés au modèle. Le LLM ne reçoit jamais le document original en ligne ; il obtient uniquement les extraits traités qu'il a demandés.

Les outils se coordonnent via l'état `temp:` au lieu de faire glisser les charges utiles à travers le réseau. `list_documents` écrit `temp.current_doc_id = "report_q2_2024"` ; `analyze_document` lit cette même clé et sait exactement quel artefact charger. Pas de blobs en base64, pas de JSON de 50 000 tokens qui rebondissent entre les outils.

Ce champ `temp:` existe pour une seule invocation, ce qui maintient le contexte de travail minimal. Un tour typique peut inclure la demande de l'utilisateur, un court message système, une liste de documents compacte, et une chaîne `current_doc_id`, tout en donnant encore l'impression d'un flux de travail riche en plusieurs étapes. Le Google Agent Development Kit (ADK) gère l'intégration afin que le modèle se concentre sur le raisonnement.

Le comportement à long terme repose sur l'état `utilisateur:`. Lorsque quelqu'un dit : « Je préfère les résumés brefs », un outil ou un rappel écrit `utilisateur.style_de_résumé = "bref"`. Les appels futurs—demain, la semaine prochaine, sur un autre appareil—peuvent lire cette clé et produire automatiquement des résumés de 3 phrases au lieu de décompositions de 3 pages.

Les préférences peuvent s'accumuler sans alourdir les demandes. Vous pourriez suivre : - `user.domain_focus = "finance"` - `user.citation_format = "APA"` - `user.summary_style = "bref"`

Chaque invocation compile uniquement le sous-ensemble pertinent dans le contexte de travail. Personne ne redémarre un chat de 200 tours juste pour se souvenir que l'utilisateur déteste les points de repère.

L'intelligence de cet agent provient de l'utilisation efficace des outils, et non d'une fenêtre contextuelle massive. Le modèle émet des appels d'outils précis, navigue à travers les états `temp:` et `user:`, et interagit avec les artefacts uniquement lorsque c'est nécessaire. Le Google Agent Development Kit (ADK) élimine efficacement l'idée qu'il faut relire toute son histoire à chaque fois juste pour paraître intelligent.

L'ingénierie des prompts signifiait autrefois des incantations intelligentes et des astuces fragiles. L'ingénierie contextuelle, telle que présentée par le blog de contexte de Google et le Google Agent Development Kit (ADK), élève ce rôle vers quelque chose de plus proche de l'architecture de systèmes distribués pour les modèles de langage.

Au lieu de se concentrer sur un seul méga-prompt, les développeurs conçoivent désormais des pipelines : comment les sessions, l'état, la mémoire et les artefacts circulent à travers les processeurs dans un contexte de travail compilé. La pile à quatre couches d'ADK—contexte de travail, journal de session, mémoire à long terme et artefacts externes—transforme « que contient le prompt ? » en « quel système a produit cette vue, et pourquoi ? »

Ce changement marque une maturation claire du développement de l'IA. Vous définissez : - Où résident les données - Quelles transformations s'exécutent à quel moment - Quel agent ou outil a accès à quel domaine

Le résultat : le comportement cesse de sembler magique et commence à sembler débogable.

La fiabilité augmente car chaque tranche de contexte a une recette explicite. Si un agent hallucine, vous examinez les processeurs et les préfixes qui ont construit sa vision, et non un gros bloc de 40 000 tokens. Les préfixes d'état d'ADK (`app`, `user`, `temp`) et les contextes ciblés (outil, rappel, invocation) vous offrent des leviers pour reproduire les bugs, écrire des tests et raisonner sur les modes de défaillance.

La prévisibilité s'améliore car les agents ne sollicitent plus l'intégralité des historiques. Ils demandent des artefacts par ID, recherchent dans la mémoire avec des requêtes contrôlées et écrivent dans des segments d'état restreints. Les coûts diminuent également : vous ne diffusez que le contexte compilé minimal par appel au lieu de rejouer des semaines de journaux dans une fenêtre de millions de tokens.

Pour les équipes visant la production, cela ressemble à un plan pour des backends multi-agents. Un agent orchestre, des agents spécialisés possèdent des outils et des mémoires, et le cadre contextuel d'ADK garantit que chaque appel reçoit juste assez d'informations. Les propres documents de Google, y compris Introduction au contexte conversationnel : session, état et mémoire, se lisent moins comme des conseils pour des invites et plus comme un guide de conception d'API.

Le contexte de l'ingénierie, tel qu'implémenté dans le Google Agent Development Kit (ADK), transforme les applications LLM en systèmes que vous concevez, et non en sorts que vous ajustez. C'est le préalable nécessaire pour des déploiements sérieux, encadrés et à agents multiples.

Prêt à passer à la réalité ? Commencez par installer le Kit de développement d'agents Google (ADK), obtenez une clé API Gemini, et lisez l'explication sur l'ingénierie contextuelle sur le blog des développeurs Google : Architecturer un cadre multi-agent efficace et conscient du contexte pour la production. Cet article définit la pile à quatre couches—contexte de travail, session, mémoire, artefacts—et les trois principes que votre code doit refléter.

Ensuite, allez directement à la documentation officielle du contexte ADK à google.github.io/adk-docs/context. Concentrez-vous sur la manière dont `InvocationContext`, `ToolContext` et `CallbackContext` limitent l'accès à la session, à la mémoire et aux artefacts, ainsi que sur la manière dont les préfixes `app:`, `user:` et `temp:` implémentent un état scoping. Considérez ces API comme la limite de votre système, pas seulement comme des classes d'assistance.

Téléchargez ensuite la démo de Yeyu Lab depuis GitHub : context_demo. Exécutez l'assistant de documents, observez comment les artefacts sont enregistrés et référencés par ID au lieu d'être intégrés dans les invites, et suivez comment les outils lisent/écrivent l'état via des préfixes plutôt que de cacher des données dans un texte libre. C'est votre mise en œuvre de référence pour un workflow multi-agents sensibles au contexte.

Pour un premier projet, refaites une application RAG existante afin de correspondre à ce modèle. Remplacez votre logique de « tout mettre dans l'invite » par :

• 1Un journal de session d'événements structurés
• 2Stockage d'artefacts pour PDFs, CSVs et documents longs
• 3Recherche de mémoire au lieu de renvoyer les mêmes faits.
• 4État `temp:` pour passer des résultats intermédiaires entre les outils.

Vous ne vous contentez plus d'ajuster des prompts ; vous concevez des systèmes distribués qui communiquent en langage naturel. Les développeurs qui intègrent le contexte comme une vue compilée — et qui architecturent autour de l'état, des artefacts et des transformations explicites — seront ceux qui livreront une IA prête pour la production, tandis que les autres continueront à rechercher une fenêtre de contexte plus grande.

Qu'est-ce que l'ingénierie contextuelle ?

L'ingénierie du contexte est un nouveau modèle architectural de Google pour les agents d'IA. Elle ne considère pas le contexte comme un flux unique de texte, mais comme une 'vue compilée' créée à partir de diverses sources de données telles que l'historique de session, la mémoire et des fichiers externes, optimisée pour chaque appel de modèle spécifique.

Pourquoi les grandes fenêtres contextuelles posent-elles problème aux agents d'IA ?

Bien que puissantes en apparence, les larges fenêtres contextuelles entraînent une spirale de coûts élevés et une lenteur de latence. Elles souffrent également du problème du "perdu au milieu", où les modèles ont du mal à trouver des informations pertinentes dans une mer de bruit, limitant ainsi leur évolutivité et leur fiabilité.

Comment le Kit de Développement d'Agent (ADK) de Google met-il en œuvre ces idées ?

ADK fournit un cadre avec des primitives intégrées pour l'ingénierie contextuelle. Il sépare le stockage persistant (Session, Mémoire, Artefacts) du 'Contexte de Travail' temporaire envoyé au LLM, en utilisant des outils et une gestion d'état pour charger uniquement ce qui est nécessaire, au moment où c'est nécessaire.

L'ingénierie contextuelle remplace-t-elle la génération augmentée par récupération (RAG) ?

Cela complète et affine le tout. RAG concerne la récupération de données ; l'Ingénierie Contextuelle porte sur la manière dont ces données récupérées (et tout autre contexte) sont structurées, gérées et présentées au modèle. Cela offre un système plus robuste et évolutif pour des flux de travail de style RAG.