Les racines architecturales des hallucinations

Lorsqu'un Large Language Model invente un point de données, une entité ou une politique d'entreprise qui n'existe pas vraiment, c'est presque toujours parce que le pipeline de récupération qui a alimenté le prompt était inexact, obsolète ou incomplet. Il existe une expression précise pour désigner l'écart entre un système qui fournit des réponses élémentaires et un système dont les réponses peuvent être mises en œuvre en toute confiance en environnement de production : c'est le « fossé de confiance ».

Un agent qui se base sur les informations client d'hier, ou un modèle d'intégration qui a été remplacé sans que les enregistrements sous-jacents aient été retraités, représente un risque opérationnel majeur. Il ne produit pas de réponse visiblement erronée, mais une hallucination très convaincante. Une hallucination dans une démo en bac à sable est une curiosité, mais la même erreur appliquée à des milliers d'interactions en direct par minute est un incident.

Introduction à l'intégrité contextuelle

La précision est une propriété architecturale fondamentale mieux définie sous le nom d'intégrité contextuelle : la discipline consistant à faire en sorte que les données opérationnelles en direct, les intégrations vectorielles, les index de recherche et l’état de l’agent soient toujours cohérents automatiquement plutôt que de les rapprocher manuellement après coup.

Lorsque ces quatre variables se trouvent dans le même enregistrement sous-jacent, servi par exactement le même chemin de requête, il n’y a aucune étape de synchronisation donnant lieu à un problème de précision. La récupération qu’un agent reçoit est solidement ancrée dans la vérité opérationnelle à la milliseconde près à laquelle elle a été émise.

Les modèles de Voyage AI sont en tête du classement RTEB (Retrieval Embedding Benchmark) et devancent les modèles comparables de Gemini, Cohere et OpenAI sur les tâches Retrieval-Augmented Generation (RAG) d'entreprise réellement exécutées par les agents.

MongoDB a fourni les éléments nécessaires pour combler l'écart de confiance de manière native au sein de la couche de données :

• Interopérabilité de la série Voyage 4 : une famille de modèles d’espace d'intégration partagés (voyage-4-large, voyage-4, voyage-4-lite, voyage-4-nano) qui produisent des intégrations entièrement compatibles. Le modèle phare « voyage-4-large » est le premier modèle d'intégration de niveau production reposant sur une architecture « mixture-of-experts » (MoE) ; il offre une précision de pointe tout en affichant un coût de service inférieur d’environ 40 % à celui de modèles denses comparables. Cela élimine la nécessité de retraiter des collections de données complètes lors de la modification de profils de coûts ou de latence.
• Récupération asymétrique : une première dans l’industrie où les documents sont intégrés une fois avec voyage-4-large pour une précision maximale de base, tandis que les requêtes continues sont intégrées via voyage-4-lite pour maintenir la latence et les coûts de jetons bas.

Acquérir des compétences : Voyage AI avec MongoDB

Découvrir la solution

Le parcours des concepteurs : les règles de filtrage de base

Pour les équipes d’ingénierie qui cherchent à dépasser le cadre conceptuel, la mise en œuvre pratique nécessite d’examiner la logique de filtrage réelle sous la charge. La recherche vectorielle filtrée en est un exemple clé.

MongoDB traite cela en filtrant d'abord par attributs (tels que l'ID utilisateur), puis en lançant une recherche vectorielle. En revanche, les planificateurs relationnels alternatifs effectuent souvent la recherche vectorielle d'abord, puis tentent d'appliquer des filtres par la suite. Lorsque les moteurs relationnels effectuent une recherche en premier, les résultats très pertinents tombent fréquemment en dehors de l'ensemble d'évaluation des candidats avant même qu'ils ne puissent être évalués. Cette variation architecturale mineure a des conséquences massives sur la précision à l'échelle de la production d'entreprise.

À regarder : Le parcours du développeur : créer des applications d'IA avec MongoDB

LG U+ gère 3,5 millions de consultations mensuelles

Les arguments d'architecture conceptuelle atteignent leur limite opérationnelle lorsqu'une entreprise gère un centre d'appels traitant 3,5 millions de demandes clients en direct par mois. Le géant coréen des télécommunications LG U+ s’est lancé dans la création d’Agent Assist : un outil interne intelligent offrant à 4 000 agents humains la transcription en temps réel, la classification automatisée des requêtes et des résumés contextuels lors d'interactions en direct.

Leur ancienne relational database ne pouvait tout simplement pas traiter les représentations vectorielles, les données transactionnelles et les tests de requête en temps réel simultanément dans le même parcours applicatif. En migrant les données opérationnelles essentielles hors de Postgres et en les regroupant sur MongoDB Atlas, l'équipe a entièrement supprimé la couche de synchronisation, source de latence, entre des systèmes disparates. $vectorSearch exécute nativement des algorithmes de similarité sémantique au sein des mêmes collections de données que celles utilisées par les agents humains pour obtenir l'historique des transactions.

Le service a été lancé seulement quatre mois après le début du développement, maintenant une latence des requêtes inférieure à la seconde même pendant les pics des matinées. Le temps de traitement par appel a diminué de 7 %, et l'efficacité des ressources s'est améliorée de 30 %. Initialement déployé pour 1 200 agents, le système traite désormais plus d'un million de requêtes par semaine et est en cours de mise à l'échelle pour atteindre 2 300 agents.

La liste de contrôle de production avant l’expédition

Ce que LG U+ démontre, c'est la check-list absolue qu'une couche de données doit fournir avant qu'un agent de production puisse être considéré comme fiable :

1. Index co-localisés : l’index de recherche IA et les données opérationnelles en temps réel doivent résider dans le même cluster de base de données, afin que les agents ne se basent jamais sur une version de la vérité différente de celle sur laquelle ils agissent.
2. Latence inférieure à une seconde : les requêtes sémantiques doivent s'exécuter en moins d'une seconde en cas de charge importante, sans quoi la réponse de l'agent arrive trop tard pour être utile sur le plan opérationnel.
3. Infrastructure de mise à l'échelle automatique : la plateforme doit se mettre à l'échelle automatiquement pour absorber les pics d'appels matinaux sans que les ingénieurs aient à réapprovisionner manuellement les nœuds.
4. Flexibilité du schéma : le modèle de données sous-jacent doit s'adapter de manière dynamique à la diversité des structures de conversation, sans imposer de migrations rigides du schéma à chaque itération métier.