Le 2 octobre 2026, les mainteneurs d’OGX ont fusionné ma PR #6705. Elle corrige un bug discret du connecteur Weaviate : réindexer un document ne remplaçait pas l’ancienne version, il en ajoutait une nouvelle à côté. Aucune erreur, aucun avertissement. Le RAG renvoyait simplement les deux versions.
Le symptôme
Vous mettez à jour une procédure, vous relancez l’ingestion, et l’agent cite tantôt l’ancienne règle, tantôt la nouvelle. Les deux passages remontent dans la recherche, parfois côte à côte. Pour l’utilisateur, l’agent « hésite ». En réalité, la base contient deux copies du même morceau de document.
La cause
Le connecteur Weaviate laissait Weaviate attribuer un identifiant (UUID) aléatoire à chaque objet. Insérer un chunk dont le chunk_id existait déjà créait donc un second objet au lieu de remplacer le premier.
Les autres bases vectorielles du projet (PGVector, Qdrant, Elasticsearch, Milvus, ChromaDB, SQLite-vec) se comportaient déjà en « upsert » : même identifiant, l’ancienne version est remplacée. Weaviate était l’exception.
La correction
L’identifiant de l’objet est maintenant calculé à partir du chunk_id. Le même chunk produit toujours le même UUID, et l’import par lot de Weaviate écrase l’objet existant. L’insertion devient un upsert, comme sur les autres bases.
Ce que j’ai vérifié avant de proposer la PR :
- trois tests unitaires, dont deux échouent sans le correctif ;
- un test réel sur un serveur Weaviate 1.32.4 : même chunk inséré deux fois avec un contenu différent, 2 objets avant le correctif, 1 seul après.
Ce qu’a ajouté le mainteneur
Ma première version utilisait uuid5, qui repose sur SHA-1. Le mainteneur a ajouté un commit pour dériver l’identifiant avec SHA-256, afin de rester compatible avec la norme de sécurité FIPS. Il a ensuite ouvert une PR de suivi (#6710) pour aligner la suppression des chunks sur ces nouveaux identifiants. C’est la partie que je préfère dans l’open source : un correctif accepté devient une base sur laquelle l’équipe construit.
Une limite à connaître
Les objets écrits avant le correctif gardent leur UUID aléatoire. La première réindexation d’un de ces chunks laisse donc encore l’ancienne copie à côté de la nouvelle ; les suivantes sont propres. Si vous utilisez Weaviate avec OGX, prévoyez une réindexation complète (purge puis ingestion) après la mise à jour.
Le test à ajouter à vos pipelines RAG
Ce bug ne se voit pas à la première ingestion. Il apparaît à la deuxième. Le test qui l’attrape est simple :
- ingérer un document ;
- le modifier, puis l’ingérer à nouveau ;
- compter les objets stockés pour ce document : le nombre doit rester le même ;
- lancer une recherche sur le passage modifié : seule la nouvelle version doit remonter.
C’est le même type de bug que ceux que j’avais trouvés lors de l’audit d’OGX : un filtre qui ne filtre pas, des tokens mal comptés, et maintenant des doublons. Rien ne plante, la qualité baisse en silence. Seul un test sur le comportement réel les attrape.
Ressources
- La PR : github.com/ogx-ai/ogx/pull/6705
- Ma checklist en 8 points avant de mettre un agent IA en production : zakariakhchiche.github.io/agents-ia-production
- Formation IA générative en entreprise (RAG, agents, mise en production), avec Spar-x, organisme certifié Qualiopi, finançable par votre OPCO : zakariakhchiche.github.io/formation-ia-generative
- Formation Copilot Studio : zakariakhchiche.github.io/formation-copilot-studio
Demander un devis ou une date de formation : formulaire Spar-x
Zakaria Khchiche, Tech Lead Data & IA freelance à Paris. Plus de 200 agents IA mis en production chez SUEZ. LinkedIn · Site