Die Retrieval-Augmented-Generation-(RAG-)Pipeline von Salesforce übertraf in Standard-Benchmarks zur Textsuche eine Genauigkeit von 90 %, fiel jedoch auf etwa 46 % zurück, als sie mit komplexen, für Kunden repräsentativen Unternehmensdokumenten getestet wurde, etwa Versicherungspolicen mit mehrseitigen Tabellen und verbundenen Zellen. Die Diskrepanz zeigte sich erst nach zwei Quartalen mit Kundeneskalationen, und der offensichtliche Verdächtige war das LLM selbst.
Statt das Modell zu ersetzen oder Prompts umzuschreiben, arbeitete das Engineering-Team von jeder falschen Antwort rückwärts: War der abgerufene Kontext vollständig? Wenn nicht, hatte das Retrieval den falschen Chunk ausgewählt, hatte das Chunking zusammengehörige Informationen getrennt, oder hatte das Parsing sie zuvor verloren? Tests zeigten, dass Tabellenüberschriften über Seitenumbrüche hinweg von ihren Daten getrennt wurden und dass Chunking mit fester Größe Verfahren an willkürlichen Token-Grenzen zerschnitt und dabei die Überschriften und Diagramme entfernte, die ihnen Bedeutung verliehen.
Das Team änderte dann jeweils eine Pipeline-Stufe und führte denselben gestuften Benchmark erneut aus, um jeden Gewinn zuzuordnen. Die Hinzufügung von „Intelligent Parsing“ auf Seitenebene, das komplexe Tabellen und Diagramme an modellbasierte Verarbeitung weiterleitet, hob eine gestufte Baseline von 65,1 % auf 84,4 %. Die Anreicherung jedes Chunks mit Metadaten und Frage-Repräsentationen, kombiniert mit einem Embedding-Modell, das die Kontextkapazität von 512 auf 8.000 Token erweiterte, fügte weitere 2,4 Punkte bis 86,8 % hinzu. Über die gesamte Änderungssammlung stieg die Genauigkeit im breiteren Benchmark für Unternehmensdokumente von etwa 46 % auf mehr als 90 %.
Die Pipeline rückwärts debuggen, jeweils eine isolierte Stufe, statt das Modell verantwortlich zu machen
Das Testen der Pipeline rückwärts, Stufe für Stufe, isolierte, welche von Parsing, Chunking, Anreicherung, Embedding oder Retrieval tatsächlich jede falsche Antwort verursachte, statt zu raten.
Die Änderung genau einer Stufe vor dem erneuten Ausführen desselben Benchmarks machte jeden Gewinn zuordenbar – 65,1 % auf 84,4 % auf 86,8 % – statt eines undurchsichtigen kombinierten Werts.
Das Weiterleiten von Seiten nach struktureller Komplexität (einfacher Text vs. Tabellen/Diagramme/Schaubilder) vermied es, jedes Dokument durch teures modellbasiertes Parsing zu schicken.
Die Korrektur zielte darauf, wo Bedeutung verloren ging – Überschriften von Daten getrennt, Verfahren an Token-Grenzen geteilt –, statt ein klügeres Modell zu bitten, fehlenden Kontext auszugleichen.
Wenn ein KI-System in der Produktion versagt, obwohl es Benchmarks besteht, sollte jede Pipeline-Stufe separat isoliert und erneut getestet werden, bevor das Modell angefasst wird – das Versagen liegt meist vorgelagert.
Salesforce verlagerte außerdem die Indexierung kleinerer Dokumente von einer Spark-basierten Batch-Architektur auf eine servicebasierte Just-in-Time-Architektur, wodurch die Indexierungszeit um das Drei- bis Vierfache sank, von über 30 Minuten auf etwa sieben bis zehn Minuten. Das Team positionierte GraphRAG, das einen Wissensgraphen über Dokumente hinweg für Multi-Hop-Fragen durchläuft, für die allgemeine Verfügbarkeit im November 2026.
DEN BELEGEN FOLGEN
Die Quellen
- Enterprise AI Accuracy: Building a More Trustworthy RAG Application Salesforce Engineering · engineering.salesforce.com ·