Der Motor mit sechs Polen — Der Mythos der zehn Codezeilen

Eine sechsteilige Untersuchung darüber, warum der Dokumenten-Chatbot, der Ihnen verkauft wurde, weiterhin erfindet — und über die andere Richtung, die Anfang 2026 jemand anfangen zu gehen.

Eine sechsteilige Untersuchung darüber, warum der Dokumenten-Chatbot, der Ihnen verkauft wurde, weiterhin erfindet — und über die andere Richtung, die Anfang 2026 jemand anfangen zu gehen.

Einleitung — Der Motor mit acht Polen (aber er hatte sechs)

Mailand, März 2026. Ein Manager öffnet den internen Unternehmens-Chatbot, von denen, die von der IT-Abteilung mit großem Enthusiasmus und geringer Skepsis „in zwei Wochen“ zusammengebaut wurden. Eine ganz einfache Frage: „Wie viele Pole hat der Motor CMP40M?“ Der Chatbot antwortet mit all der Sicherheit, die große Sprachmodelle zeigen können: „Der Motor CMP40M hat acht Pole.“

Falsch. Er hat sechs. Die richtige Antwort befand sich nicht im 422-seitigen Katalog, den jemand Monate zuvor mit vollem Vertrauen in eine Vektordatenbank eingespeist hatte, überzeugt davon, dass das System von da an "alles wissen" würde. Diese Information war in dem Katalog schlichtweg nicht vorhanden. Sie befand sich in einer PDF-Datei, die einer E-Mail der SEW-Techniker beigefügt war und in einem Ordner archiviert wurde, den sich niemand die Mühe gemacht hatte zu indexieren.

Diese Szene wiederholt sich in Hunderten von italienischen Büros, mit Variationen je nach Branche und Dialekt. Das Versprechen war einfach und verlockend: Geben Sie Ihrem KI-Assistenten alle Unternehmensdokumente, und er kann jede Frage dazu beantworten. Die Realität ist jedoch viel profaner: Der Chatbot liest, aber versteht nicht, sucht, aber findet nicht, und wenn er nichts findet – sagt er es nicht, sondern erfindet. Er erfindet fließend, mit perfekter Grammatik und plausiblen Zahlen. Und das ist viel schlimmer, als gar nicht zu antworten.

Zwischen Ende 2024 und Anfang 2026 haben wir Monate damit verbracht, diese Fehlschläge zu sezieren. Nicht um Streit zu schüren, sondern um zu verstehen, warum eine so lineare Idee – "gib ihm die Dokumente und frag ihn dann Dinge" – so schwierig wird, wenn sie die Bühne der Demo verlässt und in den Raum der echten Server eintritt.

Diese sechsteilige Untersuchung erzählt, was wir gefunden haben: stille Fehler, die ganze Kataloge löschten, Cloud-Reranker mit falschen Bewertungen, Halluzinationen, die nicht vom Modell selbst, sondern von kontaminierten Daten aus vergangenen Jahren herrührten, ausgehende Rechnungen, die jede Anfrage teurer machten als sie wert war, und "beliebte" Frameworks, die alles in zehn Codezeilen versprechen, solange man sie nicht zu sehr fordert. Und im letzten Kapitel die andere Richtung, die jemand ab Anfang 2026 leise eingeschlagen hat – eine Architektur, in der die Suchstrategie aufhört, Code zu sein und zu einem Dokument wird, das jeder im Unternehmen lesen und bearbeiten kann.

Jedes Kapitel steht für sich. Wenn Sie mit der Geschichte der 342 verschwundenen Tabellen oder der des lügenden Rerankers beginnen möchten, sind Sie frei, dies zu tun. Aber die Geschichte als Ganzes hat eine Moral, die erst am Ende deutlich wird: Das unternehmenseigene RAG – dieses technische Akronym für Retrieval-Augmented Generation, also "Antworten generieren, basierend auf zuvor abgerufenen Dokumenten" – ist noch kein fertiges Produkt. Es ist eine Grenze. Und wie alle Grenzen wurde sie bisher vor allem von Verkäufern erzählt. Es ist an der Zeit, auch denen zuzuhören, die darin gelebt haben.

Kapitel 1 — Der Mythos der zehn Codezeilen

Der Folieninhalt ist auf jeder Konferenz über KI seit 2023 identisch: "Ihr unternehmensinterner Dokumentenassistent in 10 Zeilen Code." Unter der Überschrift befindet sich ein Block mit Python-Code in Pastelltönen, der eine Open-Source-Bibliothek zeigt – typischerweise eine der berühmten amerikanischen, deren Name an Baumketten oder tibetische Lamas erinnert – die PDFs lädt, diese zerstückelt, in eine Vektordatenbank einfügt und mit einem Sprachmodell abfragt. In fünf Minuten haben Sie einen Chatbot. In fünf Minuten gibt es Applaus. In fünf Minuten ist ein mittelständisches italienisches Unternehmen davon überzeugt, dass das Problem gelöst ist und seine IT-Abteilung es in zwei Wochen schaffen kann.

Das Problem – das die Folie nicht erwähnt – ist, dass die Demo mit drei gut formatierten PDFs, einer Frage, die auf den Inhalt zugeschnitten ist, einer Bühne ohne reale Latenzzeiten und einem Präsentator aufgebaut ist, der alles 27 Mal geübt hat, bevor er auf die Bühne ging. In der Realität sind Unternehmensdokumente ein geologisches Desaster: Scans von Scans, Tabellen, die sich mit Text überlappen, Fußnoten, die sich in Absätze schieben, alphanumerische Codes wie "RH1M", die der Chunker in der Mitte zerschneidet, weil er sie für Wörter hält, Bilder, die siebzig Prozent der nützlichen Informationen enthalten, aber die niemand extrahiert, und Layouts, die einen Archäologen statt eines Parsers erfordern.

RAG – das ist die Idee unter der Haube – ist eine großartige Idee. Nehmen Sie die Frage des Benutzers, suchen Sie in Ihrem Archiv nach den relevantesten Dokumenten, geben Sie diese an das Sprachmodell weiter und lassen Sie sich eine Antwort geben, die auf diesen Dokumenten basiert. In der Theorie löst dies elegant das Problem der Halluzination: Das Modell muss die Antwort nicht mehr "wissen", sondern sie nur in den Teilen "lesen", die Sie ihm zur Verfügung gestellt haben. In der Praxis hat jedes Glied in der Kette – das Chunking, das Embedding, das Retrieval, das Reranking, die endgültige Generierung – seine eigenen Möglichkeiten, zu versagen, und das Versagen manifestiert sich selten als sichtbarer Fehler. Es manifestiert sich als eine leicht falsche Antwort. Dann als eine völlig falsche Antwort. Dann als ein Manager, der sich fragt, warum er für ein System bezahlt, das weniger weiß als der Praktikant.

Die Open-Source-Frameworks, die RAG populär gemacht haben, sind dazu gedacht, zu demonstrieren, nicht zu produzieren. Es handelt sich um eleganteste Verkettungen von Abstraktionen, in denen jede Schicht eine unausgesprochene Annahme verbirgt: dass Ihre PDFs ein ordentliches OCR haben, dass Ihre Fotos bereits beschrieben wurden, dass Ihre Tabellen einer Konvention folgen, dass das Embedding-Modell tatsächlich Ihre Sprache spricht (Spoiler: viele sprechen nur gut Englisch), dass Ihr Archiv bereits von Duplikaten bereinigt wurde. Wenn eine dieser Annahmen fehlschlägt – und mindestens eine schlägt immer fehl, fast immer drei – hört das System nicht auf zu funktionieren. Schlimmer noch: Es hört auf, gut zu funktionieren, liefert aber weiterhin Antworten. Flüssige, sichere und oft von der Wahrheit abgekoppelte Antworten.

Es gibt einen Satz, der sich unter denen verbreitet, die diese Systeme beruflich entwickeln, und den man in Tutorials nie lesen wird: "RAG ist leicht zu machen, aber schwer gut zu machen." Zwischen der ersten Demo und dem Produktionsdienst besteht ein Abgrund, der sich nicht durch Hinzufügen von GPUs oder durch Wechsel des Modells überbrücken lässt. Er wird durch das Verständnis einer unangenehmen Tatsache überwunden: Wenn Sie ein unternehmensinternes RAG erstellen, schreiben Sie keinen Code. Sie entwerfen eine kleine, hartnäckige Suchmaschine, die auf Ihre Dokumente zugeschnitten ist, mit all den redaktionellen Entscheidungen, die dies mit sich bringt – was ist Rauschen, was ist Signal, was muss zweimal indiziert werden, was muss verworfen werden. In den Tutorials mit zehn Zeilen werden diese Entscheidungen jedoch einmalig von jemandem getroffen, der Ihre Dokumente noch nie gesehen hat, und sie sind fast immer die falschen für Ihren Fall.