Maintenir les agents d'IA au sol : Stratégies d'ingénierie contextuelle qui empêchent le pourrissement du contexte à l'aide de Milvus

Si vous avez travaillé sur des conversations LLM de longue durée, vous avez probablement connu ce moment de frustration : à mi-chemin d'un long fil de discussion, le modèle commence à dériver. Les réponses deviennent vagues, le raisonnement s'affaiblit et des détails clés disparaissent mystérieusement. Mais si vous lancez exactement la même question dans une nouvelle discussion, le modèle se comporte soudain de manière ciblée, précise et ancrée.

Ce n'est pas le modèle qui se fatigue, c'est le contexte qui change. Au fur et à mesure qu'une conversation se développe, le modèle doit jongler avec davantage d'informations et sa capacité à établir des priorités diminue lentement. Des études antropiques montrent que lorsque les fenêtres contextuelles s'étendent d'environ 8K tokens à 128K, la précision de la recherche peut chuter de 15 à 30 %. Le modèle a encore de la place, mais il ne sait plus ce qui est important. Des fenêtres contextuelles plus grandes permettent de retarder le problème, mais ne l'éliminent pas.

C'est là que l'ingénierie contextuelle entre en jeu. Au lieu de donner tout au modèle en une seule fois, nous façonnons ce qu'il voit : nous ne récupérons que les éléments importants, nous compressons ce qui n'a plus besoin d'être verbeux et nous gardons les messages-guides et les outils suffisamment propres pour que le modèle puisse raisonner. L'objectif est simple : rendre les informations importantes disponibles au bon moment et ignorer le reste.

La récupération joue un rôle central à cet égard, en particulier pour les agents à long terme. Les bases de données vectorielles telles que Milvus fournissent la base pour ramener efficacement les connaissances pertinentes dans leur contexte, ce qui permet au système de garder les pieds sur terre même si les tâches gagnent en profondeur et en complexité.

Dans ce blog, nous verrons comment la rotation du contexte se produit, les stratégies utilisées par les équipes pour la gérer et les modèles architecturaux - de la récupération à la conception de l'invite - qui permettent aux agents d'IA de rester performants sur des flux de travail longs et à plusieurs étapes.

Pourquoi le pourrissement du contexte se produit-il ?

Les gens supposent souvent qu'en donnant plus de contexte à un modèle d'IA, on obtient naturellement de meilleures réponses. Mais ce n'est pas vrai. Les humains ont également du mal à gérer les longues entrées : les sciences cognitives suggèrent que notre mémoire de travail contient environ 7±2 morceaux d' information. Au-delà, nous commençons à oublier, à brouiller ou à mal interpréter les détails.

Les LLM présentent un comportement similaire, mais à une échelle beaucoup plus grande et avec des modes de défaillance plus dramatiques.

Le problème de fond vient de l'architecture Transformer elle-même. Chaque jeton doit se comparer à tous les autres jetons, formant une attention par paire sur l'ensemble de la séquence. Cela signifie que le calcul croît en O(n²) avec la longueur du contexte. Si vous passez de 1 000 à 100 000 jetons, le modèle ne travaille pas plus dur : il multiplie le nombre d'interactions entre les jetons par 10 000×.

Il y a ensuite le problème des données d'apprentissage. Les modèles voient beaucoup plus de séquences courtes que de séquences longues. Ainsi, lorsque vous demandez à un LLM d'opérer dans des contextes extrêmement larges, vous le poussez dans un régime pour lequel il n'a pas été formé. Dans la pratique, le raisonnement sur des contextes très longs est souvent hors de portée de la plupart des modèles.

Malgré ces limites, les contextes longs sont désormais inévitables. Les premières applications LLM étaient principalement des tâches à tour unique - classification, résumé ou génération simple. Aujourd'hui, plus de 70 % des systèmes d'IA d'entreprise reposent sur des agents qui restent actifs pendant de nombreux cycles d'interaction, souvent pendant des heures, en gérant des flux de travail ramifiés et à plusieurs étapes. Les sessions de longue durée sont passées du statut d'exception à celui de défaut.

La question qui se pose alors est la suivante : comment maintenir l'attention du modèle sans le submerger ?

Approches de récupération du contexte pour résoudre le problème de la rotation du contexte

La récupération est l'un des leviers les plus efficaces dont nous disposons pour lutter contre le pourrissement du contexte et, dans la pratique, elle tend à se manifester dans des modèles complémentaires qui abordent le pourrissement du contexte sous différents angles.

1. Récupération juste à temps : Réduction du contexte inutile

L'une des principales causes du pourrissement du contexte est la surcharge du modèle avec des informations dont il n'a pas encore besoin. Claude Code - l'assistant de codage d'Anthropic - résout ce problème grâce à la récupération juste à temps (JIT), une stratégie dans laquelle le modèle ne récupère les informations que lorsqu'elles deviennent pertinentes.

Au lieu d'intégrer des bases de code ou des ensembles de données entiers dans son contexte (ce qui augmente considérablement les risques de dérive et d'oubli), Claude Code maintient un petit index : chemins d'accès aux fichiers, commandes et liens de documentation. Lorsque le modèle a besoin d'un élément d'information, il récupère cet élément spécifique et l'insère dans le contexte au moment où il est important, pasavant.

Par exemple, si vous demandez à Claude Code d'analyser une base de données de 10 Go, il n'essaiera jamais de la charger entièrement. Il travaille plutôt comme un ingénieur :

1. Il exécute une requête SQL pour obtenir des résumés de haut niveau de l'ensemble des données.

2. Il utilise des commandes telles que head et tail pour visualiser des échantillons de données et comprendre leur structure.

3. Ne conserve que les informations les plus importantes, telles que les statistiques clés ou les lignes d'échantillons, dans le contexte.

En minimisant ce qui est conservé dans le contexte, la récupération JIT empêche l'accumulation de jetons non pertinents qui provoquent la pourriture. Le modèle reste concentré car il ne voit jamais que les informations nécessaires à l'étape de raisonnement en cours.

2. Pré-recueil (recherche vectorielle) : Prévenir la dérive du contexte avant qu'elle ne commence

Parfois, le modèle ne peut pas "demander" des informations de manière dynamique - l'assistance à la clientèle, les systèmes de questions-réponses et les flux de travail des agents ont souvent besoin des bonnes connaissances avant que la génération ne commence. C'est là que la pré-récupération devient essentielle.

Le pourrissement du contexte est souvent dû au fait que le modèle se voit remettre un gros tas de texte brut et qu'il est censé trier ce qui est important. La pré-instruction inverse cette situation : une base de données vectorielle (comme Milvus et Zilliz Cloud) identifie les éléments les plus pertinents avant l' inférence, garantissant ainsi que seul le contexte de grande valeur parvient au modèle.

Dans une configuration RAG typique :

• Les documents sont intégrés et stockés dans une base de données vectorielle, telle que Milvus.

• Au moment de l'interrogation, le système récupère un petit ensemble de morceaux très pertinents par le biais de recherches de similarité.

• Seuls ces morceaux sont intégrés dans le contexte du modèle.

Cela permet d'éviter le pourrissement de deux manières :

• Réduction du bruit : les textes non pertinents ou faiblement liés n'entrent jamais dans le contexte.

• Efficacité : les modèles traitent beaucoup moins de jetons, ce qui réduit le risque de perdre la trace de détails essentiels.

Milvus peut rechercher des millions de documents en quelques millisecondes, ce qui rend cette approche idéale pour les systèmes en direct où le temps de latence est important.

3. Recherche hybride JIT et vectorielle

La pré-recouvrement basé sur la recherche vectorielle aborde une partie importante du pourrissement du contexte en s'assurant que le modèle commence avec des informations à haut signal plutôt qu'avec du texte brut et surdimensionné. Mais Anthropic met en évidence deux défis réels que les équipes négligent souvent :

• La rapidité d'exécution : Si la base de connaissances est mise à jour plus rapidement que l'index vectoriel n'est reconstruit, le modèle peut s'appuyer sur des informations périmées.

• Précision : avant le début d'une tâche, il est difficile de prédire avec précision ce dont le modèle aura besoin, en particulier pour les flux de travail à plusieurs étapes ou exploratoires.

Dans les charges de travail réelles, une approche hybride est donc la solution optimale.

• Recherche vectorielle de connaissances stables et fiables

• Exploration JIT pilotée par des agents pour les informations qui évoluent ou qui ne deviennent pertinentes qu'en milieu de tâche.

En combinant ces deux approches, vous bénéficiez de la rapidité et de l'efficacité de la recherche vectorielle pour les informations connues, et de la flexibilité du modèle pour découvrir et charger de nouvelles données chaque fois qu'elles deviennent pertinentes.

Voyons comment cela fonctionne dans un système réel. Prenons l'exemple d'un assistant de documentation de production. La plupart des équipes finissent par opter pour un pipeline en deux étapes : Recherche vectorielle alimentée par Milvus + Recherche JIT basée sur des agents.

1. Recherche vectorielle alimentée par Milvus (pré-recueil)

• Convertissez votre documentation, vos références API, vos changelogs et vos problèmes connus en embeddings.

• Stockez-les dans la base de données vectorielle Milvus avec des métadonnées telles que le domaine du produit, la version et l'heure de mise à jour.

• Lorsqu'un utilisateur pose une question, exécutez une recherche sémantique pour récupérer les K segments les plus pertinents.

Cette méthode permet de résoudre environ 80 % des requêtes courantes en moins de 500 ms, ce qui donne au modèle un point de départ solide et résistant à la dégradation du contexte.

2. Exploration basée sur des agents

Lorsque la recherche initiale n'est pas suffisante, par exemple lorsque l'utilisateur demande quelque chose de très spécifique ou de très urgent, l'agent peut faire appel à des outils pour obtenir de nouvelles informations :

• Utiliser search_code pour localiser des fonctions ou des fichiers spécifiques dans la base de code.

• Utiliser run_query pour extraire des données en temps réel de la base de données.

• Utiliser fetch_api pour obtenir l'état le plus récent du système

Ces appels prennent généralement de 3 à 5 secondes, mais ils garantissent que le modèle fonctionne toujours avec des données fraîches, précises et pertinentes, même pour les questions que le système ne pouvait pas anticiper à l'avance.

Cette structure hybride garantit que le contexte reste opportun, correct et spécifique à la tâche, ce qui réduit considérablement le risque de pourrissement du contexte dans les flux de travail de longue durée des agents.

Milvus est particulièrement efficace dans ces scénarios hybrides car il prend en charge :

• la recherche vectorielle + le filtrage scalaire, combinant la pertinence sémantique avec des contraintes structurées

• lesmises à jour incrémentielles, qui permettent d'actualiser les données intégrées sans temps d'arrêt.

Milvus constitue donc une épine dorsale idéale pour les systèmes qui nécessitent à la fois une compréhension sémantique et un contrôle précis de ce qui est récupéré.

Par exemple, vous pouvez exécuter une requête du type :

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

Comment choisir la bonne approche pour traiter la rotation contextuelle ?

La recherche vectorielle préalable, la recherche juste à temps et la recherche hybride étant toutes disponibles, la question qui se pose naturellement est la suivante : laquelle devez-vous utiliser ?

Voici une méthode simple mais pratique pour choisir, en fonction de la stabilité de vos connaissances et de la prévisibilité des besoins d'information du modèle.

1. La recherche vectorielle → la meilleure pour les domaines stables

Si le domaine évolue lentement mais exige de la précision (finance, travail juridique, conformité, documentation médicale), une base de connaissances alimentée par Milvus et dotée d'une fonction de pré-récupération est généralement la solution idéale.

Les informations sont bien définies, les mises à jour sont peu fréquentes et il est possible de répondre à la plupart des questions en récupérant d'emblée les documents sémantiquement pertinents.

Tâches prévisibles + connaissances stables → Pré-recueil.

2. Récupération juste à temps → Meilleure solution pour les flux de travail dynamiques et exploratoires

Les domaines tels que le génie logiciel, le débogage, l'analytique et la science des données impliquent des environnements en évolution rapide : nouveaux fichiers, nouvelles données, nouveaux états de déploiement. Le modèle ne peut pas prédire ce dont il aura besoin avant le début de la tâche.

Tâches imprévisibles + connaissances en évolution rapide → récupération juste à temps.

3. Approche hybride → lorsque les deux conditions sont réunies

De nombreux systèmes réels ne sont ni purement stables ni purement dynamiques. Par exemple, la documentation destinée aux développeurs évolue lentement, alors que l'état d'un environnement de production change minute par minute. Une approche hybride vous permet de

• charger des connaissances connues et stables à l'aide d'une recherche vectorielle (rapide, faible latence)

• d'obtenir à la demande des informations dynamiques à l'aide d'outils d'agent (précises et actualisées).

Connaissances mixtes + structure de tâches mixtes → approche de recherche hybride.

Et si la fenêtre contextuelle ne suffit toujours pas ?

L'ingénierie contextuelle permet de réduire la surcharge, mais le problème est parfois plus fondamental : la tâche n'est tout simplement pas adaptée, même avec un découpage minutieux.

Certains flux de travail, comme la migration d'une base de code volumineuse, l'examen d'architectures multiréférentiels ou la production de rapports de recherche approfondis, peuvent dépasser les 200 000 fenêtres de contexte avant que le modèle n'atteigne la fin de la tâche. Même si la recherche vectorielle fait le gros du travail, certaines tâches nécessitent une mémoire plus persistante et structurée.

Anthropic a récemment proposé trois stratégies pratiques.

1. La compression : Préserver le signal, supprimer le bruit

Lorsque la fenêtre contextuelle approche de sa limite, le modèle peut compresser les interactions antérieures en résumés concis. Une bonne compression permet de conserver

• les décisions clés

• les contraintes et les exigences

• les questions en suspens

• Les échantillons ou exemples pertinents

et supprime :

• les sorties d'outils verbeuses

• les journaux non pertinents

• les étapes redondantes.

Le défi consiste à trouver un équilibre. Si la compression est trop agressive, le modèle perd des informations essentielles ; si elle est trop légère, vous gagnez peu d'espace. Une compression efficace permet de conserver le "pourquoi" et le "quoi", mais pas le "comment nous en sommes arrivés là".

2. La prise de notes structurée : Déplacer les informations stables hors du contexte

Au lieu de tout conserver dans la fenêtre du modèle, le système peut stocker les faits importants dans une mémoire externe - unebase de données séparée ou un magasin structuré que l'agent peut interroger en cas de besoin.

Par exemple, le prototype d'agent Pokémon de Claude stocke des faits durables tels que :

• Pikachu leveled up to 8

• Trained 1234 steps on Route 1

• Goal: reach level 10

Pendant ce temps, les détails transitoires - journaux de combat, sorties d'outils longues - restent en dehors du contexte actif. Cela reflète la manière dont les humains utilisent les carnets de notes : nous ne conservons pas chaque détail dans notre mémoire de travail ; nous stockons des points de référence à l'extérieur et les consultons en cas de besoin.

La prise de notes structurée permet d'éviter le pourrissement du contexte dû à la répétition de détails inutiles, tout en donnant au modèle une source de vérité fiable.

3. Architecture des sous-agents : Diviser et conquérir les grandes tâches

Pour les tâches complexes, il est possible de concevoir une architecture multi-agents dans laquelle un agent principal supervise l'ensemble du travail, tandis que plusieurs sous-agents spécialisés s'occupent d'aspects spécifiques de la tâche. Ces sous-agents plongent dans de grandes quantités de données liées à leurs sous-tâches, mais ne renvoient que les résultats concis et essentiels. Cette approche est couramment utilisée dans des scénarios tels que les rapports de recherche ou l'analyse de données.

En pratique, il est préférable de commencer par utiliser un seul agent combiné à la compression pour gérer la tâche. Le stockage externe ne devrait être introduit que lorsqu'il est nécessaire de conserver la mémoire au fil des sessions. L'architecture multi-agents doit être réservée aux tâches qui nécessitent réellement un traitement parallèle de sous-tâches complexes et spécialisées.

Chaque approche étend la "mémoire de travail" effective du système sans faire exploser la fenêtre contextuelle et sans déclencher de pourrissement du contexte.

Meilleures pratiques pour concevoir un contexte qui fonctionne réellement

Après avoir géré le débordement du contexte, il y a un autre élément tout aussi important : la manière dont le contexte est construit en premier lieu. Même avec la compression, les notes externes et les sous-agents, le système aura du mal à fonctionner si l'invite et les outils eux-mêmes ne sont pas conçus pour supporter des raisonnements longs et complexes.

Anthropic propose une façon utile de penser à cela - moins comme un exercice unique de rédaction d'un message-guide, et plus comme la construction d'un contexte à travers trois couches.

Invitations au système : Trouver la zone Boucles d'or

La plupart des messages-guides systémiques échouent aux extrêmes. Trop de détails - listes de règles, conditions imbriquées, exceptions codées en dur - rendent l'invite fragile et difficile à maintenir. Trop peu de structure laisse le modèle deviner ce qu'il doit faire.

Les meilleures invites se situent au milieu : suffisamment structurées pour guider le comportement, suffisamment souples pour permettre au modèle de raisonner. En pratique, cela signifie qu'il faut donner au modèle un rôle clair, un flux de travail général et une légère orientation de l'outil - rien de plus, rien de moins.

En voici un exemple :

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

Cette invite donne une direction sans submerger le modèle ni le forcer à jongler avec des informations dynamiques qui n'ont pas leur place ici.

Conception d'outils : Moins, c'est plus

Une fois que l'invite du système définit le comportement de haut niveau, les outils portent la logique opérationnelle réelle. Un mode d'échec étonnamment courant dans les systèmes augmentés d'outils est simplement le fait d'avoir trop d'outils ou d'avoir des outils dont les objectifs se chevauchent.

Une bonne règle de base s'impose :

• Un outil, un objectif

• Paramètres explicites et non ambigus

• Pas de chevauchement des responsabilités

Si un ingénieur humain hésite sur l'outil à utiliser, le modèle le fera aussi. Une conception claire des outils réduit l'ambiguïté, diminue la charge cognitive et empêche le contexte d'être encombré par des tentatives d'utilisation d'outils inutiles.

Les informations dynamiques doivent être extraites, et non codées en dur

La dernière couche est la plus facile à négliger. Les informations dynamiques ou sensibles au temps, telles que les valeurs d'état, les mises à jour récentes ou l'état spécifique de l'utilisateur, ne doivent pas apparaître du tout dans l'invite du système. En les intégrant à l'invite, on s'assure qu'elles deviendront périmées, gonflées ou contradictoires au fil des tâches.

Au lieu de cela, ces informations ne doivent être récupérées qu'en cas de besoin, soit par extraction, soit par l'intermédiaire d'outils d'agent. Le fait d'exclure le contenu dynamique de l'invite du système permet d'éviter le pourrissement du contexte et de maintenir l'espace de raisonnement du modèle propre.

Conclusion

Au fur et à mesure que les agents d'intelligence artificielle s'intègrent dans des environnements de production dans différents secteurs d'activité, ils prennent en charge des flux de travail plus longs et des tâches plus complexes que jamais. Dans ce contexte, la gestion du contexte devient une nécessité pratique.

Cependant, une fenêtre de contexte plus grande ne produit pas automatiquement de meilleurs résultats; dans de nombreux cas, c'est le contraire qui se produit. Lorsqu'un modèle est surchargé, qu'il reçoit des informations périmées ou qu'il est contraint de répondre à des invites massives, la précision dérive tranquillement. Ce déclin lent et subtil est ce que nous appelons aujourd'hui le pourrissement du contexte.

Les techniques telles que la recherche JIT, la pré-recherche, les pipelines hybrides et la recherche sémantique alimentée par des bases de données vectorielles visent toutes le même objectif : s'assurer que le modèle voit les bonnes informations au bon moment - ni plus, ni moins - afin qu'il puisse rester ancré dans la réalité et produire des réponses fiables.

En tant que base de données vectorielles haute performance à code source ouvert, Milvus est au cœur de ce flux de travail. Elle fournit l'infrastructure nécessaire au stockage efficace des connaissances et à la récupération des éléments les plus pertinents avec une faible latence. Associé à la récupération JIT et à d'autres stratégies complémentaires, Milvus aide les agents d'intelligence artificielle à rester précis à mesure que leurs tâches deviennent plus profondes et plus dynamiques.

Mais la récupération n'est qu'une pièce du puzzle. Une bonne conception de l'invite, un ensemble d'outils propres et minimaux et des stratégies de débordement judicieuses - qu'il s'agisse de compression, de notes structurées ou de sous-agents - sont autant d'éléments qui permettent au modèle de rester concentré sur des sessions de longue durée. C'est à cela que ressemble une véritable ingénierie contextuelle : non pas des bidouillages intelligents, mais une architecture réfléchie.

Si vous voulez des agents d'IA qui restent précis pendant des heures, des jours ou des flux de travail entiers, le contexte mérite la même attention que celle que vous accorderiez à n'importe quel autre élément central de votre pile.

Vous avez des questions ou souhaitez approfondir une fonctionnalité ? Rejoignez notre canal Discord ou déposez des questions sur GitHub. Vous pouvez également réserver une session individuelle de 20 minutes pour obtenir des informations, des conseils et des réponses à vos questions dans le cadre des Milvus Office Hours.