Comment Regenesis a mis en place la boucle d'auto-correction de MedShift grâce à VectorAI DB

Cette création avait initialement été soumise au hackathon « Self-Evolving Agents »

Un agent qui se souvient de la manière dont il a corrigé cette règle hier transforme la façon dont s'effectue la récupération.

C'est le problème auquel Regenesis a été confrontée avec MedShift, une application de planification hospitalière conçue autour d'un effectif clinique de 26 personnes. Le système doit respecter les délais de certification, les exigences en matière de repos, les limites d'heures supplémentaires et les règles de couverture. Lorsqu'une de ces règles n'est pas respectée, l'agent doit identifier le problème, le résoudre et s'assurer que la correction a bien été appliquée.

Sans mémoire, l'agent n'avait aucun moyen de savoir s'il avait déjà rencontré la même défaillance auparavant. Chaque nouvelle violation impliquait de recommencer le diagnostic depuis le début. Une même cause première pouvait se manifester par un point d'entrée différent et paraître néanmoins nouvelle. Le système pouvait se rétablir, mais ce rétablissement ne suffisait pas à le rendre opérationnel. Chaque rencontre repartait de zéro.

L'Chinois Lai, le créateur de Regenesis, explique en quoi cela change la donne : « Actian est la mémoire de l'agent ; c'est ce qui permet une véritable évolution plutôt qu'une simple nouvelle tentative. »

TL;DR

• MedShift est une solution SaaS de gestion des plannings hospitaliers qui détecte les infractions aux règles de sécurité, corrige la règle à l'origine de ces infractions et vérifie chaque correction avant sa mise en production.
• Actian VectorAI DBconstitue la couche mémoire. L'agent intègre chaque défaillance sous forme de vecteur, l'interroge avant chaque correctif et récupère les solutions déjà validées plutôt que de procéder à un nouveau diagnostic à partir de zéro.
• Lors de la première détection, VectorAI DB renvoie un cosinus de 0,00 et l'agent effectue un cycle de diagnostic complet. Lors de la deuxième détection de la même défaillance, il renvoie un cosinus de 1,00 et résout le problème en une seule étape.
• Les corrections qui échouent ne sont jamais considérées comme des solutions. Le filtre de rappel fonctionne sur la base de « outcome=»success« », et aucune correction n’est enregistrée en mémoire tant que le contrôle qualité de la boucle de relecture n’a pas confirmé que la réparation a tenu.
• Trois principes s'appliquent à tout agent d'auto-réparation : les défaillances d'index doivent être identifiées en fonction de la structure et non du vocabulaire ; la mémoire doit être filtrée lors de la récupération et non lors de l'écriture ; et aucune correction ne doit être stockée avant qu'un vérificateur indépendant n'ait confirmé sa validité.

Ce que Regenesis a changé

Pour tester la boucle, Regenesis a désactivé le mécanisme de protection de certification de MedShift. L’oracle a mis en évidence 14 violations réelles de planification, chacune calculée à partir du planning en temps réel. L’agent Guild a interrogé la base de données Actian VectorAI, a obtenu une valeur cosinus = 0,00 sans qu’aucune « enregistrement » n’ait été enregistrée en mémoire, puis a diagnostiqué la défaillance en remontant à sa cause première, a corrigé le mécanisme de protection défaillant, a vérifié la réparation et a enregistré la correction.

Lorsque le même défaut est réapparu, VectorAI DB a renvoyé une valeur de cosinus égale à 1,00, a récupéré la correction précédente et a résolu les 14 violations en une seule étape.

C'est ce que permet la mémoire persistante, et Lai a décrit Medshift comme « un SaaS de planification qui détecte, diagnostique et corrige ses propres failles de sécurité, et qui gagne en rapidité à chaque fois qu'il en identifie une ».

C'est là qu'intervient la base de données Actian VectorAI

VectorAI DB est la couche mémoire qui permet de faire la distinction entre la réessai et l'évolution.

L'agent intègre chaque profil de défaillance sous forme de vecteur et interroge la base de données VectorAI avant chaque application de correctif. Lorsque l'requête e renvoie warm=true, l'agent récupère le correctif validé et l'applique immédiatement. Lorsqu'il revient warm=false, l'agent considère la panne comme un cas nouveau, en identifie la cause première et n'enregistre la solution qu'après confirmation par le service externe d'assurance qualité que la réparation est durable.

Chaque point de mémoire est associé à un état qui, au départ, est pending. Le filtre de rappel fonctionne sur outcome: "success", de sorte que les corrections qui ont échoué sont définitivement exclues des résultats. Sans cette mémoire persistante et consultable, chaque échec apparaît comme un cas nouveau, quel que soit le nombre de fois où L'agent l'a déjà réparé.

Comment fonctionne la boucle d'auto-guérison ?

Regenesis a mis en place une boucle en quatre étapes : détection, « memory- requête », correction et vérification externe. L’oracle signale la violation. L’agent Guild interroge la base de données VectorAI pour rechercher un correctif existant ; s’il en trouve un, il récupère la solution vérifiée ; dans le cas contraire, il signale la défaillance comme inédite. Le correctif rétablit la protection défaillante, puis le système « Replay Loop QA » — le contrôle qualité autonome de Guild qui valide le correctif avant toute mise en production — intervient. Chaque étape étant indépendante, le remplacement de l’oracle, la substitution du contrôle qualité ou la modification de l’infrastructure de l’agent ne nécessitent pas la reconstruction des autres éléments.

La boucle d'auto-réparation MedShift. Oracle, Guild Agent, VectorAI DB, Rules Config (Genome) et Replay Loop QA constituent la passerelle externe. Les flèches indiquent le cycle complet, y compris l'écriture en mémoire une fois la correction confirmée.

L'Oracle

L'oracle est déterministe : il effectue des vérifications basées sur des règles plutôt que sur des inférences. Il compare le planning en temps réel à un cahier des charges immuable couvrant les périodes de certification, les exigences en matière de repos, les limites d'heures supplémentaires et les seuils minimaux de couverture. Le cahier des charges est validé une seule fois, et l'agent n'y touche jamais. Seule la configuration des règles est modifiable.

C’est précisément cette séparation qui garantit la fiabilité de la boucle. Si l’on sabote la configuration des règles, l’oracle met en évidence de véritables violations issues de la planification en temps réel, calculées à partir des données. Comme l’indique le fichier README : « Chaque bug est véritablement calculé, jamais simulé par un script. » La démo désactive le mécanisme de protection de la certification et génère 14 violations, chacune correspondant à un véritable conflit de planification issu de la planification en temps réel, calculé par rapport aux spécifications fixes.

La mémoire requête

Avant d'appliquer une correction, l'agent intègre la forme de l'erreur et interroge regenesis_memory, un ensemble de cosinus à 96 dimensions issu de la base de données VectorAI. L'requête e applique des filtres sur outcome: "success", en excluant des résultats les corrections qui ont échoué. La base de données VectorAI propose une recherche par similarité vectorielle plutôt qu’une recherche hybride ; Regenesis a donc développé sa propre couche de « Reciprocal Rank Fusion ». Plusieurs requêtes ANN sont exécutées pour chaque vue de défaut, et la couche fusionne leurs classements avant de renvoyer le meilleur résultat.

// lib/sponsors/actian.ts — LiveActianClient
// The agent calls search() with must: { outcome: "success" }
// so failed fixes are never surfaced as solutions.
async search(
  vector: number[],
  opts: { topK?: number; filter?: VectorFilter } = {},
): Promise<VectorHit[]> {
  const { hits } = await this.post<{ hits: VectorHit[] }>("/api/memory/search", {
    vector,
    topK: opts.topK ?? 5,
    filter: opts.filter,
  });
  return hits;
}

function fuse(rankings: VectorHit[][], topK: number): VectorHit[] {
  const fused = new Map<string, { hit: VectorHit; score: number }>();
  for (const ranked of rankings) {
    ranked.forEach((hit, rank) => {
      const prev = fused.get(hit.id);
      const contribution = 1 / (RRF_K + rank + 1);
      if (prev) prev.score += contribution;
      else fused.set(hit.id, { hit, score: contribution });
    });
  }
  return [...fused.values()]
    .sort((a, b) => b.score - a.score)
    .slice(0, topK)
    .map(({ hit, score }) => ({ ...hit, score }));
}

search() rendements VectorHit[] triés par similarité cosinus, par ordre décroissant. cosine=0.00 est un échec inédit. cosine=1.00 correspond exactement. L'agent prend une décision en fonction de la gravité : appliquer immédiatement la correction préalable ou diagnostiquer la cause première. Le profil de défaillance indique quelle règle de sécurité a été enfreinte et dans quel contexte, ce qui permet d'effectuer la recherche en fonction du modèle plutôt que du vocabulaire.

Ça, cosine=1.00 C'est lors de la deuxième itération que la boucle montre qu'elle apprend : un pas au lieu d'un cycle complet.

Le Patch et la Porte

L'application d'un correctif rétablit la condition de sécurité concernée conformément à la politique. La fonction de réparation associe un résultat à la condition de sécurité qui l'a généré et rétablit la valeur spécifiée de cette condition, en gérant tout type d'échec relevant du champ d'application de l'oracle.

Une fois la mise à jour effectuée, l'agent effectue une nouvelle détection. Une détection sans erreur déclenche memory_remember, qui exprime l'immersion de l'échec sous la forme d'un vecteur et {guard, outcome: "success", generation, timesReinforced} en tant que charge utile vers la base de données VectorAI.

await client.upsert([{
  id: pointIdFor(failureHash),
  vector: embed(failureShape),
  payload: {
    guard,
    outcome: "success",
    generation,
    timesReinforced: 1,
  },
}]);

Un test qui échoue génère un exemple négatif avec outcome: "failure", que le filtre de rappel exclut définitivement. Le contrôle qualité de la boucle de relecture (Replay Loop QA) filtre ensuite déploiement, et la correction n’est pas diffusée tant que Replay n’a pas confirmé qu’elle est exempte d’erreurs. Selon la formulation de Lai : « Le génome est une configuration de règles modifiable ; la mémoire est une collection de vecteurs ; la sélection naturelle est un contrôle qualité évalué de manière externe. »

C'est une défaillance combinée qui est la plus révélatrice. Une seule opération a permis de détecter deux protections différentes et de recenser 27 violations. L'agent a rappelé ces deux constatations, appliqué les deux correctifs, effectué une vérification, puis enregistré les deux corrections. Il a analysé la situation, tiré des conclusions à partir de ses constatations et poursuivi son travail jusqu'à ce que le planning soit en règle.

Ce que vous pouvez en retenir pour l'appliquer à votre propre système

Les agents peuvent générer des solutions. Ce que montre Regenesis, c'est ce qui se passe une fois qu'une solution a été mise en œuvre. Le système enregistre la défaillance, stocke la solution validée et la reconnaît dès qu'elle se reproduit. C'est là toute la différence entre se remettre d'un incident et en tirer des enseignements.

Trois modèles de cette version sont directement réutilisables.

Le troisième schéma est celui que la plupart des systèmes ignorent. Enregistrer une correction en mémoire avant de l’avoir vérifiée signifie que la prochaine réactivation pourrait faire ressortir une solution non vérifiée. Dans MedShift, cela signifie que l’agent applique une correction dont il n’a jamais confirmé le bon fonctionnement, l’enregistre comme réussie et reproduit l’erreur lors de la prochaine occurrence. C’est la porte externe qui garantit la fiabilité de la mémoire.

Dans Regenesis, VectorAI DB fournit la couche de mémoire persistante qui rend cette boucle possible. Vous pouvez l'exécuter localement avec Docker en quelques minutes.

docker run -d --name vectorai -p 6573-6575:6573-6575 \
  -e ACTIAN_VECTORAI_ACCEPT_EULA=YES \
  -v vectorai_data:/var/lib/actian-vectorai actian/vectorai:latest

Inscrivez-vous à VectorAI DB Community Edition pour commencer. Rejoignez la communauté Actian sur Discord pour poser des questions et découvrir les projets des autres utilisateurs.

Cette version a été initialement soumise dans le cadre du hackathon « Self-Evolving Agents ». Vous pouvez consulter le projet Regenesis sur GitHub.

À propos de l'auteur

À propos de Alex Novotny

Alex Novotny est responsable de la croissance des développeurs chez Actian, où il dirige la stratégie visant à impliquer les développeurs et à accélérer l’adoption des technologies de données et d’IA d’Actian, notamment VectorAI DB. Fort de plus de dix ans d’expérience dans le secteur technologique et de plus de cinq ans dans les relations avec les développeurs, Alex allie contenu technique, promotion auprès des développeurs, communauté et croissance afin de rendre les technologies complexes plus faciles à découvrir, à comprendre et à mettre en œuvre. Ancien responsable senior de la promotion auprès des développeurs chez Box, il a développé des applications d’IA et de RAG, des intégrations MCP, des outils pour développeurs et du contenu technique en partenariat avec des plateformes s technologiques de premier plan. Il se passionne pour la création d’expériences développeurs qui transforment la curiosité en adoption et les prototypes en production.