Compacter le contexte sans amnésie
Toute longue investigation menée par une IA déborde la fenêtre de contexte - la question honnête est ce qui se passe alors. Comment DataQube sépare le contexte de travail du modèle du registre append-only, fait de la compaction un événement visible et garde les fils compactés pleinement auditables.
Tout agent qui fait un vrai travail d'analyse finit par heurter le même mur : l'investigation est plus longue que la fenêtre de contexte. Une réponse au superviseur qui s'étend sur trois semaines, quarante requêtes, une douzaine d'hypothèses révisées et deux détours de comité ne tient dans le contexte d'aucun modèle - ni aujourd'hui, ni l'an prochain, car les investigations grandissent jusqu'à remplir la place qu'on leur donne.
Ce qui distingue les plateformes d'agents, ce n'est pas de heurter ce mur. C'est ce qu'elles y font - et les deux réponses standard du secteur sont l'une comme l'autre discrètement malhonnêtes. La première est la troncature silencieuse : jeter les tours les plus anciens en espérant qu'il n'y avait rien d'important là-bas - une amnésie administrée sans prévenir le patient. La seconde est la prétention au contexte infini : un marketing qui laisse entendre que le problème de la fenêtre est résolu, alors que sous charge il se passe la réponse un, en silence. Si votre travail est régulé, les deux échouent au même examen : pouvez-vous dire, précisément, ce que l'agent ne considérait plus quand il a produit ce chiffre ?
La réponse de DataQube commence par refuser qu'une seule structure de données fasse deux métiers.
Deux mémoires, deux métiers
La confusion sous la plupart des lamentations sur la fenêtre de contexte consiste à traiter « ce que voit le modèle » et « ce qui s'est passé » comme la même chose. Ce sont des objets différents, aux garanties différentes :
Le registre - le journal de conversation du fil - est append-only et complet : chaque tour, chaque appel d'outil avec sa référence d'audit, chaque résultat, chaque décision, pour toujours. C'est l'objet sur lequel vit la piste d'audit, et rien dans la gestion du contexte n'a le droit d'y toucher. Le contexte de travail est une projection construite à partir du registre pour le prochain appel au modèle : les tours récents mot pour mot, le reste représenté par des résumés et des essentiels épinglés. Il est reconstruit, redimensionné, réécrit librement - parce qu'il ne porte aucun poids probatoire. Le registre répond à « que s'est-il passé » ; le contexte de travail répond à « de quoi le modèle a-t-il besoin maintenant ». Dès que ces deux objets sont séparés, la fenêtre de contexte cesse d'être un problème de vérité et devient un budget d'ingénierie.
La compaction est un événement, pas une gomme
Quand le contexte de travail d'un fil approche de la fenêtre, DataQube le compacte : les tours anciens sont repliés dans un résumé structuré, et le contexte est reconstruit autour. La partie qui compte pour la confiance, c'est la visibilité de l'opération.
La compaction est un événement, ajouté au registre comme n'importe quel autre. Il dit quand elle a eu lieu, quelle portion de la conversation elle a résumée, et avec quel résumé le modèle travaillera désormais. Dans le fil lui-même, on la voit comme un marqueur entre les messages - quiconque lit la conversation voit exactement où la mémoire de travail de l'agent a été consolidée, comme on voit où un outil a été appelé. Rien de la cognition de l'agent n'est hors registre : même les moments où il réorganise sa propre mémoire y figurent.
Cette visibilité semble cosmétique jusqu'au jour où on en a besoin. Quand un relecteur demande pourquoi les réponses tardives de l'agent ont cessé de mentionner une réserve précoce, la réponse honnête se trouve : voici l'événement de compaction, voici le résumé produit, et la réserve y est entrée ou non. Le mode de défaillance existe toujours - résumer est par nature avec perte -, mais il est inspectable, ce qui fait la différence entre un bug qu'on peut signaler et un fantôme qu'on ne peut pas attraper.
Ce qui survit mot pour mot, et ce qui se comprime
La compaction n'est pas un mixage uniforme. Certaines choses sont épinglées et survivent à chaque compaction mot pour mot, parce que leur formulation exacte est porteuse : les définitions validées en vigueur, les décisions prises par l'utilisateur, les paramètres de la tâche et les questions ouvertes auxquelles l'agent doit encore répondre. Ce qui se comprime, c'est la masse : les longues sorties d'outils, les tours exploratoires qui ont mené quelque part, les impasses qui n'ont mené nulle part.
Et comprimé ne veut pas dire disparu. Une ligne de résumé comme « portefeuille interrogé sur neuf variantes de segment ; tout rapproché dans la tolérance sauf Bureaux (voir tour 87) » porte un pointeur vers le registre. Si l'agent a besoin plus tard des chiffres réels du tour 87, ils sont à une consultation de distance - dans le registre, où ils n'ont jamais cessé d'exister. Le contexte de travail oublie comme oublie le bureau d'une bonne analyste : le dossier est retourné dans l'armoire, pas dans la déchiqueteuse.
Auditer un fil compacté
Voici la propriété qui rend ce design cohérent avec tout le reste de ce blog : la preuve ne vit jamais dans le contexte de travail. Chaque chiffre produit par l'agent porte sa chaîne - requêtes, documents, exécutions, contrôles - ancrée dans le registre, pas dans ce que le modèle avait dans sa fenêtre à ce moment-là. La compaction ne peut donc pas rendre la preuve orpheline. Un fil compacté cinq fois s'audite exactement comme un fil jamais compacté : remontez la chaîne de n'importe quelle affirmation, et chaque maillon se résout - parce que ce vers quoi pointent les maillons n'a jamais été compacté.
Un relecteur qui examine une longue investigation obtient donc les deux vérités à la fois : l'historique complet (le registre, intact) et un compte rendu honnête de ce sur quoi l'agent travaillait à chaque étape (la suite des événements de compaction et leurs résumés). Rien dans cette phrase n'exige de faire confiance au résumeur - seulement de lire ce qu'il a écrit, quand, au registre.
Un registre que personne ne peut réécrire
La propriété à retenir de tout cela : dans DataQube, le registre ne peut pas être édité - ni par l'agent, ni par la compaction, ni par nous. Certaines plateformes gèrent le contexte en compactant la conversation elle-même, en résumant les vieux tours pour les remplacer ; le jour où une revue arrive, le fil qu'on lit n'est plus le fil qui a produit les chiffres - c'est un récit, écrit par la même classe de modèle dont la revue existe pour contrôler les sorties, et votre artefact probatoire primaire est devenu, en silence, un artefact dérivé.
C'est pourquoi nous payons volontiers le prix du registre append-only et de ses projections jetables : le stockage est bon marché, et une histoire qui aurait pu être éditée ne vaut rien exactement au moment où quelqu'un en a besoin. Quand vous évaluez une plateforme d'agents, une seule question règle tout ce sujet : le fil que j'audite est-il le fil qui a tourné - ou un résumé de celui-ci ?
Le même principe - un registre, plusieurs projections - traverse toute la plateforme ; la page produit le montre comme chat, notebook et présentation. Et pour voir un fil compacté garder ses reçus, réservez une démo et apportez une longue conversation.