Votre analyste IA a besoin d'un cerveau, pas d'un vector store

Demandez à une nouvelle analyste ce qui la ralentit vraiment ses premiers mois : elle ne dira pas SQL - elle dira les conventions. Quel indice de référence s'applique à quel mandat, et les deux mandats où la réponse évidente est la mauvaise. Pourquoi les comparaisons antérieures à 2024 doivent passer par les tables _hist, parce que la migration de cette année-là a changé la clé des positions. Le fait que le fournisseur ESG travaille en SEDOL quand l'entrepôt travaille en ISIN - et que quatorze noms disparaissent en silence de toute jointure qui oublie la table de correspondance.

Rien de tout cela n'est écrit à un endroit utile. Cela vit dans la tête des deux personnes les plus anciennes du desk, dans des fils de discussion introuvables, et dans les marges de présentations déjà remplacées deux fois. C'est le savoir qui rend l'analyse correcte - et dès qu'un agent IA se met à analyser, la question de savoir s'il détient ce savoir cesse d'être un plus : c'est la différence entre une réponse et un incident.

La réponse par défaut du secteur est la génération augmentée par récupération : plonger les documents dans des embeddings, chercher par similarité, injecter les fragments les plus proches dans le contexte. Nous avons construit autre chose, et cet article en est l'argumentaire. En bref : le savoir institutionnel est structurel, et la recherche par similarité est aveugle à la structure.

Pourquoi la recherche par similarité perd le savoir structuré

Voici une forme réelle de savoir, tirée du monde de nos scénarios de démonstration - la jointure canonique pour les prix as-of, et la réserve qui la rend correcte :

1SELECT h.*, p.close2FROM holdings h3ASOF JOIN prices p4ON p.isin = h.isin AND p.ts <= h.ts5-- never p.ts = h.ts: look-ahead bias.6-- promoted to house standard after the Q1 incident.

Le SQL est la moitié facile. La moitié porteuse, c'est tout ce qui y est attaché : ce motif s'applique aux backtests et à toute analyse joignant prix et positions ; il a été validé par le responsable du desk après un incident ; il contraint une classe précise de requêtes ; et le <= n'est pas un choix de style mais tout l'enjeu. Déroulez maintenant le cas d'échec : une mémoire à embeddings, interrogée sur la jointure des prix, récupère volontiers le SQL - il ressemble beaucoup à la question - et omet tout aussi volontiers la réserve, parce qu'elle vit dans un autre fragment avec un autre embedding, et que rien de structurel ne dit ces deux pièces sont inséparables. L'agent écrit une jointure propre avec = au lieu de <=, le backtest regarde discrètement l'avenir, et l'erreur est invisible précisément parce que tout ce qui a été récupéré était « pertinent ».

La similarité vous dit ce qui sonne proche. Elle ne peut pas dire ce qui s'applique, ce qui vient attaché, ni ce qui a été remplacé - parce que ce sont des arêtes, pas des distances.

Un graphe de connaissances, pas une pile de documents

La mémoire de DataQube est un graphe. Définitions, requêtes d'exemple, réserves, décisions et savoir-faire sont des nœuds typés, reliés aux espaces de travail où ils s'appliquent, aux sources de données qu'ils décrivent et aux outils qu'ils contraignent. Les arêtes aussi sont typées - s'applique-à, réserve, dérivé-de, remplace - et une même paire de nœuds peut en porter plusieurs à la fois : la réserve anti-look-ahead ci-dessus porte à la fois sur la source de prix et contraint le motif de jointure - c'est exactement pour cela qu'aucun rappel du motif ne peut arriver sans elle.

Le rappel est alors un parcours de graphe, pas une recherche du plus proche voisin. Quand un agent commence à travailler dans un espace, il tire le voisinage : les définitions qui y ont cours, les réserves attachées à chaque source et outil qu'il s'apprête à toucher, les savoir-faire promus depuis des travaux validés. La réserve sur les prix n'est pas rappelée parce qu'elle ressemble à la question - elle est rappelée parce qu'elle est attachée à la chose utilisée. La ressemblance est optionnelle ; l'attache ne l'est pas.

Un savoir qui sait quand il a tort

Le stockage n'a jamais été la partie difficile. La partie difficile - et, dirions-nous, le vrai produit - c'est l'invalidation. Le savoir institutionnel périme sans calendrier : une définition change après un incident, une source est reclavée, une convention est renversée par un comité qui n'a prévenu personne.

Voici comment cela se joue dans DataQube, avec l'incident sur lequel repose notre scénario de démonstration. Un problème de snapshot de prix force le desk à changer sa définition du rendement actif. À l'instant où la nouvelle définition est validée, l'ancienne est remplacée : elle cesse d'être rappelée immédiatement, partout, sans cache à faire expirer. Mais elle n'est pas supprimée - elle reste dans le graphe, liée à son remplaçant, estampillée du moment où elle a cessé d'être vraie. C'est cette dernière propriété qui rend le système auditable et pas seulement à jour : quand on examine une analyse d'avant le changement, le registre montre qu'elle a été produite sous la définition valable à l'époque - la différence entre « l'analyse était fausse » et « la définition a changé ensuite », une distinction à laquelle les auditeurs tiennent beaucoup.

La porte d'entrée compte autant que la sortie. Les candidats extraits des conversations - « l'agent a remarqué que le desk exclut toujours les parts d'amorçage » - entrent en quarantaine : visibles, attribuables et jamais rappelés tant qu'une personne ne les a pas validés. Rien de ce que l'agent a inféré ne peut devenir en silence quelque chose sur quoi l'agent s'appuie. La validation elle-même est un événement au registre : qui a approuvé cette pièce de savoir, quand, de quelle conversation elle vient. Les standards maison portent leur chaîne entière.

L'alternative rejetée est la plus séduisante : laisser le système apprendre en continu, en pariant que le bon savoir évince le mauvais. Dans un produit grand public, c'est un pari raisonnable. Dans un produit régulé, cela signifie que les croyances de votre agent sont une entrée non auditée et automodifiable de chaque nombre qu'il produit - et la première fois qu'une inférence fausse contaminera un trimestre de réponses, vous ne saurez dire ni quand elle est arrivée ni ce qu'elle a touché.

À quoi ressemble le rappel dans une exécution réelle

Voici la boucle complète dans le produit - le savoir validé arrive avant la première requête, et un nouveau candidat part en quarantaine à la fin :

Rejouer l'exécution

D'après de réelles conversations clients — toutes les données sont fictives.

Notez la forme de ce qui est rappelé : pas des documents qui ressemblent à la question, mais les définitions de cet espace et les réserves attachées aux sources que cette exécution va utiliser. Et notez ce qui sort : un candidat, clairement marqué en attente de validation, tenu à l'écart des rappels futurs jusqu'à ce que quelqu'un ayant l'autorité l'approuve.

Le test à une seule question

Si vous évaluez une mémoire d'agent, posez cette question au fournisseur : quand une définition change, montrez-moi ce qui arrive à l'ancienne - et montrez-moi ce que votre système sert pour une analyse datée d'avant le changement. Un magasin de similarité n'a pas de bonne réponse ; anciens et nouveaux fragments coexistent, et la récupération choisit par ressemblance et heuristiques de fraîcheur. Un graphe avec sémantique de remplacement répond précisément : la nouvelle définition partout dès la validation, l'ancienne conservée avec sa fenêtre de validité pour qui audite le passé.

Un système de mémoire sans sémantique de remplacement n'accumule pas du savoir. Il accumule des passifs - fluides, sûrs d'eux et de plus en plus faux. Comment le module mémoire s'insère dans le reste de la plateforme : voir la page produit - et pour voir la quarantaine en direct, réservez une démo, apprenez à l'agent quelque chose de faux, et regardez cela rester sans conséquence.