Die Tabellen, die es nicht gab

Kapitel 2 — Die Tabellen, die es nicht gab

Ein Techniker einer Maschinenbaufirma aus dem Nordosten erzählte es uns bei einem Espresso, mit jener venezianischen Ruhe, die einem Unglück vorauseilt: "Unser Chatbot wusste alles über den Motor. Nur nicht die Daten des Motors." Dann erklärte er es. Ihr interner KI-Assistent konnte Produktreihen, Anwendungsbereiche, die Markengeschichte und Wettbewerbsvorteile beschreiben. Eine Offenbarung, erzählerisch betrachtet. Aber wenn ein Kunde nach dem Nennmoment des Modells CMP50L fragte – also nach der technischen Angabe, wegen der man einen Katalog aufschlägt, der Zahl, wegen der man einen Motor kauft – antwortete der Chatbot vage, manchmal plausibel, manchmal nicht. Fünf Monate Entwicklung, ein zunehmend verwirrter Betriebsleiter und niemand, der wusste, warum.

Die Diagnose kam zufällig, fast aus Langeweile, bei der manuellen Inspektion der Datenbank nach dem wiederholten, ergebnislosen Meeting. Der PDF-Katalog enthielt 342 technische Tabellen. In der Datenbank waren null angekommen. Nicht eine Handvoll: null. Keine. Der Code, der die Tabellen aus den PDFs extrahierte, speicherte die Daten in Feldern namens columns und data, während der Code, der sie dann indizierte, Felder namens headers und rows erwartete. Ein nicht beachtetes "Synonym". Eine interne Konvention, die bei einem vergessenen Refactoring untergegangen war. Das Ergebnis, für fünf stille Monate: Die gesamte numerische Intelligenz des Katalogs – Paare, Potenzen, Durchmesser, Gewichte, Bestellcodes, Versorgungsspannungen – floss aus dem Wasserhahn, ohne jemals ins Glas gegossen zu werden. Dreihundertzweiundvierzig Tabellen, die einzeln in stiller Andacht verloren gingen.

Dies ist die Art von Fehler, der nicht schreit. Er löst keine Ausnahmen aus, lässt nichts abstürzen und erscheint in keinem Log. Einfach verschwindet ein Teil der Welt für Ihr System, und niemand bemerkt es, bis ein Benutzer – normalerweise ein verärgerter Benutzer – genügend hartnäckige Fragen stellt, um den Abgrund aufzudecken. Und es ist ein Sinnbild für ein viel größeres Problem als die Feldnamen: Generische RAG-Frameworks sind für aktuellen Text optimiert – Artikel, Webseiten, Absatzgeschichten – und behandeln Tabellen, wenn überhaupt, als Bürger zweiter Klasse. Aber italienische Unternehmensdokumente sind oft Tabellen. Technische Kataloge, Preislisten, Produktspezifikationen, Sicherheitsdatenblätter, Bestellungen: Der wertvolle Teil für diejenigen, die diese Dokumente einsehen, ist der tabellarische. Der, der zuerst kaputt geht und den niemand bemerkt.

Die Lektion ist nicht "Achte auf die Feldnamen". Sie ist unbequemer: In einem seriösen RAG benötigt jede Art von Inhalt – Tabellen, Bilder, alphanumerische Codes, Absatzüberschriften, Fußnoten – eine spezielle, entwickelte und getestete Behandlung. Und der Funktionstest ist nicht "Der Chatbot beantwortet banale Fragen" – das tun auch defekte Systeme, weil genügend schwebende Daten vorhanden sind, um etwas Plausibles zu konstruieren. Der wahre Test ist "Der Chatbot beantwortet Fragen, die ihn zwingen, jedes einzelne Teil der Pipeline zu berühren". Spezifische, numerische, überprüfbare Fragen. Fragen, für die es eine richtige und nur eine Antwort gibt, und wenn das System falsch liegt, weißt du es sofort.

Wenn du diesen Test nicht durchführst, weißt du nicht, ob dein RAG funktioniert. Du weißt nur, dass es sich nicht beschwert. Und "es beschwert sich nicht" ist ein sehr niedriges Qualitätskriterium für ein System, das Menschen zur Entscheidungsfindung nutzen werden.