Die architektonischen Wurzeln von Halluzinationen

Wenn ein LLM einen Datenpunkt, eine Entität oder eine Unternehmensrichtlinie erfindet, die in Wirklichkeit gar nicht existiert, liegt das fast immer daran, dass die Abruf-Pipeline, aus der die Eingabebefehle bezogen wurden, ungenau, veraltet oder unvollständig war. Es gibt einen präzisen Begriff für die Lücke zwischen einem System, das nur grundlegende Antworten liefert, und einem System, dessen Antworten in der Produktion zuverlässig umgesetzt werden können: die Vertrauenslücke.

Ein Agent, der auf der Grundlage eines Customer Snapshot von gestern Schlussfolgerungen zieht, oder ein Einbettungsmodell, das ohne erneute Verarbeitung der zugrunde liegenden Datensätze ausgetauscht wurde, stellt ein erhebliches betriebliches Risiko dar. Dabei wird kein offensichtlich falsches Ergebnis geliefert, sondern eine mit hoher Sicherheit vorgetäuschte Erkenntnis. Eine Halluzination in einer einzelnen Sandbox-Demo ist eine Kuriosität, doch derselbe Fehler, der sich auf Tausende von Live-Interaktionen pro Minute auswirkt, ist bereits ein Vorfall.

Einführung kontextueller Integrität

Genauigkeit ist eine grundlegende architektonische Eigenschaft, die am besten als kontextuelle Integrität definiert werden kann: Die Disziplin, Live-Betriebsdaten, Vektor-Embeddings, Suchindizes und den Agentenstatus automatisch konsistent zu halten, anstatt sie nachträglich manuell abzugleichen.

Wenn diese vier Variablen im selben zugrunde liegenden Datensatz enthalten sind, der über genau denselben Abfragepfad bereitgestellt wird, gibt es keinen Synchronisationsschritt, bei dem Genauigkeitsverluste auftreten könnten. Die vom Agenten empfangenen Daten basieren zuverlässig auf dem tatsächlichen Stand genau in der Millisekunde, in der sie ausgegeben wurden.

Die Modelle von Voyage AI führen den Retrieval Embedding Benchmark (RTEB) an und schneiden bei den RAG-Aufgaben, die Agenten in Unternehmen tatsächlich ausführen, besser ab als vergleichbare Modelle von Gemini, Cohere und OpenAI.

MongoDB hat die Bausteine bereitgestellt, die erforderlich sind, um die Vertrauenslücke nativ innerhalb der Datenschicht zu schließen:

• Interoperabilität der Voyage-4-Serie: Eine Familie von Modellen mit gemeinsamem Einbettungsraum (voyage-4-large, voyage-4, voyage-4-lite, voyage-4-nano), die vollständig kompatible Einbettungen erzeugen. Das Flaggschiff „voyage-4-large“ ist das erste serienreife Embedding-Modell, das auf einer „Mixture-of-Experts“-Architektur (MoE) basiert und modernste Genauigkeit bei etwa 40 % geringeren Betriebskosten als vergleichbare dichte Modelle bietet. Dadurch entfällt die Notwendigkeit, ganze Datensätze neu zu verarbeiten, wenn sich Kosten- oder Latenzprofile ändern.
• Asymmetrische Abfrage: Eine Branchenneuheit, bei der Dokumente einmalig mit „voyage-4-large“ eingebettet werden, um eine maximale Basisgenauigkeit zu erzielen, während fortlaufende Abfragen mit „voyage-4-lite“ eingebettet werden, um die Latenz und die Token-Kosten niedrig zu halten.

Fähigkeiten erlernen: Voyage AI mit MongoDB

Lösung erkunden

Die Reise des Entwicklers: die wichtigsten Filterregeln

Für Ingenieurteams, die über konzeptionelle Gespräche hinausgehen möchten, erfordert die praktische Umsetzung die Untersuchung echter Filterlogik unter Last. Ein typisches Beispiel ist die gefilterte Vektorsuche.

MongoDB löst dieses Problem, indem es zunächst nach Attributen (wie der Benutzer-ID) filtert und anschließend die Vektorsuche ausführt. Im Gegensatz dazu führen alternative relationale Planer oft zuerst die Vektorsuche durch und versuchen erst danach, Filter anzuwenden. Wenn relationale Engines zuerst suchen, fallen hochrelevante Ergebnisse häufig aus der Kandidatenauswahl heraus, bevor sie überhaupt bewertet werden können. Dieser geringfügige Unterschied in der Architektur hat im Produktionsmaßstab von Unternehmen massive Auswirkungen auf die Genauigkeit.

Video: Die Reise des Entwicklers: Entwicklung von KI-Apps mit MongoDB

LG U+ verzeichnet monatlich 3,5 Millionen Beratungsfälle

Konzeptionelle Architekturargumente stoßen an eine ganz klare operative Grenze, wenn ein Unternehmen ein Callcenter betreibt, das monatlich 3,5 Millionen Live-Kundenanfragen bearbeitet. Der koreanische Telekommunikationsriese LG U+ machte sich daran, „Agent Assist“ zu entwickeln: ein intelligentes internes Tool, das 4.000 menschlichen Agenten während Live-Beratungen Echtzeit-Transkriptionen, eine automatisierte Kategorisierung von Anfragen und kontextbezogene Zusammenfassungen bereitstellt.

Ihre veraltete relationale Datenbank war schlichtweg nicht in der Lage, Vektoreinbettungen, Transaktionsdaten und Echtzeit-Abfragetests gleichzeitig innerhalb desselben Anwendungspfads zu verarbeiten Durch die Migration der zentralen Betriebsdaten aus Postgres und deren Konsolidierung in MongoDB Atlas gelang es dem Team, die latenzanfällige Synchronisationsschicht zwischen den unterschiedlichen Systemen vollständig zu beseitigen. $vectorSearch führt semantische Ähnlichkeitsalgorithmen nativ auf genau denselben Datensammlungen aus, die auch von menschlichen Mitarbeitern für die Abfrage von Transaktionsverläufen genutzt werden.

Der Dienst wurde bereits vier Monate nach Beginn der Entwicklung eingeführt und wies selbst während der morgendlichen Spitzenzeiten eine Abfragelatenz von unter einer Sekunde auf. Die Bearbeitungszeit pro Anruf sank um 7 %, und die Ressourceneffizienz verbesserte sich um 30 %. Das System, das ursprünglich für 1.200 Agenten bereitgestellt wurde, verarbeitet mittlerweile über eine Million Anfragen pro Woche und wird derzeit auf 2.300 Agenten skaliert.

Die Produktionscheckliste vor dem Versand

LG U+ zeigt, welche Anforderungen eine Datenschicht unbedingt erfüllen muss, bevor man einem Produktionsagenten vertrauen kann:

1. Gemeinsam gespeicherte Indizes: Der KI-Suchindex und die aktuellen Betriebsdaten müssen sich im exakt selben Datenbankcluster befinden, damit die Agenten niemals Daten aus einer „Version der Wahrheit“ abrufen, während sie auf der Grundlage einer anderen handeln.
2. Latenz unter einer Sekunde: Semantische Abfragen müssen auch unter hoher Auslastung in weniger als einer Sekunde ausgeführt werden, da die Antwort des Agenten sonst zu spät eintrifft, um operativ von Nutzen zu sein.
3. Infrastruktur mit automatischer Skalierung: Die Plattform muss sich automatisch skalieren, um morgendliche Anrufspitzen aufzufangen, ohne dass Techniker die Knoten manuell neu bereitstellen müssen.
4. Flexibilität des Schemas: Das zugrunde liegende Datenmodell muss sich dynamisch an unterschiedliche Gesprächsabläufe anpassen können, ohne dass bei jeder Geschäftsiteration starre Schemamigrationen erforderlich sind.