Die Strategie als Dokument — Das siebte Kapitel

Kapitel 6 — Die Strategie als Dokument, nicht als Code

Wir kommen zu dem Einblick, der bei all jenen, die RAG seit 2023 aufgebaut haben, am häufigsten als "das, was ich am ersten Tag hätte verstehen wollen" auftaucht.

Traditionelle Frameworks behandeln die Suchstrategie wie Python-Code. Möchten Sie für technische Kataloge zuerst nach Produktcode, dann nach Keywords und dann nach semantischen Vektoren suchen und erst im letzten Schritt die Antwort generieren? Schreiben Sie eine Funktion. Möchten Sie für Fotoalben die traditionelle semantische Suche ganz überspringen und sich stattdessen auf einen spezialisierten Reranker für Bilder verlassen? Schreiben Sie eine andere Funktion. Möchten Sie für Unternehmensvideos den Ton von der visuellen Spur trennen, diese separat transkribieren, als separate Quellen behandeln und sie dann in der endgültigen Antwort wieder zusammensetzen? Noch eine Funktion. Jeder Inhaltstyp, jede Domäne, jeder Kunde führt letztendlich zu einem Code-Zweig, der von den anderen abweicht, bis hin zu dem Punkt, an dem die Änderung einer Strategie eine Softwareversionierung, eine Code-Überprüfung, einen Testzyklus und ein Deployment erfordert. Die Zeit zwischen "Ich habe eine Idee, wie man die Suche in technischen Handbüchern verbessern kann" und "Die Idee ist in Produktion" wird in Wochen gemessen. Für jede Idee.

Der alternative Einblick ist leicht zu sagen, aber tiefgreifend in seinen Auswirkungen: Die Suchstrategie ist kein Code. Sie ist ein Dokument. Ein JSON – ein strukturiertes Textformat, das jeder Redakteur mit einer halbstündigen Schulung lesen kann – das sagt: "Zuerst dies versuchen, dann das, wenn das erste fehlschlägt, gehe zum dritten über, ranke es so um, antworte mit diesem Modell." Dieses Dokument lebt in einer Datenbank, nicht in einem Repository. Es wird über eine Benutzeroberfläche geändert, nicht über einen Pull Request. Es wird versioniert, kopiert und für Domänen spezialisiert. Eine Strategie für technische Kataloge, eine für Fotoalben, eine für Installationshandbücher, eine für Videos, eine für Audio, eine für Rechtsverträge, eine für Bilanzen. Alle koexistieren im selben System. Alle in Echtzeit änderbar.

Wer mit diesem Ansatz gearbeitet hat – nennen wir ihn, ohne viel Phantasie, Meta-RAG – berichtet von einer Geschwindigkeitssteigerung, die über die reine Technik hinausgeht. Eine typische Kundenanfrage wie "fügen Sie eine spezifische Suche nach Produktcodes hinzu, die Kürzel wie CMP40M oder RH1M enthalten" ist nicht mehr ein Entwicklungsticket für zwei Wochen. Es ist ein neuer Schritt, der zu einer JSON-Prozedur hinzugefügt wird, der in einer Staging-Umgebung heiß getestet und an einem Nachmittag in die Produktion überführt wird. Die Frage "was ändert sich, wenn wir einen anderen Reranker für Fotos verwenden, während wir den aktuellen für Text beibehalten?" beantwortet man, indem man eine Zeile der Konfiguration ändert. Das Experiment kostet nichts, das Rollback kostet nichts (man stellt einfach die vorherige Version des Dokuments wieder her), und das angesammelte Wissen – was für einen bestimmten Inhaltstyp gut funktioniert – wird zu einem versionierten und übertragbaren Gut, nicht zum stillen Wissen von demjenigen, der diesen speziellen Code-Zweig geschrieben hat und heute im Urlaub ist.

Es gibt auch einen interessanten sozialen Effekt, der in Organisationen auftritt, die diesen Ansatz verfolgen. Bei Strategien als Dokument verschiebt sich die Grenze zwischen "Entwickler" und "erfahrenem Nutzer". Ein Digitalbibliothekar, ein Unternehmensarchivar, ein Domänenexperte – der Leiter des technischen Büros, die Dokumentationsverantwortliche, der Produktmanager, der die wahren Kundenfragen wie kein anderer kennt – kann eine Strategie lesen, verstehen, was sie tut, Änderungen vorschlagen und diese manchmal sogar direkt schreiben. Er muss nicht den Entwicklungsticket-Funnel durchlaufen, er muss einem Entwickler keine Dinge erklären, die dieser nicht wissen sollte (weil es nicht zu seinem Beruf gehört, sie zu wissen). Das RAG hört auf, ein Produkt zu sein, das Sie konsumieren, und wird zu einem Werkzeug, das Sie anhand Ihres organisierten Wissens modellieren. Dies, so die Erfahrung derjenigen, die es ausprobiert haben, verändert die Moral des Projekts noch bevor die Zahlen der Metriken sich ändern.

Es ist keine Magie, und es hat seine Kosten. Man benötigt eine Engine, die diese Strategien als Dokumente effizient und sicher ausführt. Man benötigt eine Beschreibungsprache, die reichhaltig genug ist, um reale Fälle abzudecken, aber auch arm genug, um nicht ein weiteres getarntes Turing-vollständiges System zu werden. Man benötigt Werkzeuge für die Versionsverwaltung, das Testen und das Rollback. Aber all dies ist das Problem derjenigen, die die Engine bauen – einmalig und für alle Benutzer. Der einzelne Endkunde sieht nur eines: die Möglichkeit, seine Suchstrategie mit der Geschwindigkeit des Denkens zu entwickeln, anstatt mit der Geschwindigkeit des Software-Release-Zyklus. Und das, für diejenigen, die darin involviert sind, ist eine stille Revolution, die ihren Namen noch nicht in Fachzeitschriften gefunden hat.

Abschluss — Das siebte Kapitel, in einigen Monaten

Anfang 2026, unter Berücksichtigung der Lektionen aus den vorherigen Kapiteln – die sich verlierenden Tabellen, die lügenden Reranker, die geerbten Halluzinationen, die Cloud-Rechnungen, die schneller wuchsen als der Wert, die vielversprechenden, aber starren Frameworks – begann jemand in Italien, einen anderen RAG-Server zu bauen. Geschrieben in Python, konzipiert für den Betrieb auf zugänglicher Hardware, in der Lage, mit Cloud-Modellen zu sprechen, wenn es sich lohnt, und mit lokalen Modellen, wenn der Datenschutz dies erfordert oder die Kosten nicht stimmen. Ein Server, in dem Suchstrategien veränderbare Dokumente sind, der Reranker ein lokaler Prozess auf der GPU ist, Tabellen nicht verloren gehen, weil sie wie Bürger erster Klasse behandelt werden, Fotos keine Objekte aus verstaubten Archiven anderer Epochen erben und die Kosten pro Abfrage – sowohl in Geld als auch in an Dritte abgeflossenen Daten – bis zum Cent bekannt und kontrollierbar sind.

Wir werden den Namen des Projekts nicht nennen. Dies ist nicht der richtige Zeitpunkt dafür, und wir wollen keine Untersuchung in Werbung verwandeln. Aber wenn Ihnen die vorherigen Kapitel eine Situation erkennen lassen, die Sie erleben – ein Unternehmens-Chatbot, der selbstbewusst falsche Fragen beantwortet, ein RAG-Projekt, das seit Monaten nicht abhebt, eine Cloud-Rechnung, die schneller wächst als der Nutzen, den sie erbringt, oder ein wachsender Verdacht, dass Ihre vertraulichen Dokumente an unbekannte Orte gelangen –, dann ist es gut zu wissen, dass es einen anderen Weg gibt, der von jemandem in Italien beschritten wurde und der 2026 begann, die ersten Antworten zu liefern, die man sich 2023 erhofft hatte.

Die gute Nachricht ist, dass Unternehmens-KI endlich die Demo-Phase verlässt. Die weniger gute Nachricht ist, dass sie dabei alle Narben der Reise mit sich herumträgt: aufgeblähte Frameworks, Abhängigkeiten von Anbietern, monolithische Architekturen, schmutzige Daten, stille Fehler und eine gewisse Tendenz der Branche, Lösungen zu verkaufen, bevor sie das Problem überhaupt verstanden haben. Wir haben sie in sechs Kapiteln erzählt. Das siebte – die Geschichte davon, was passiert, wenn endlich jemand die Dinge richtig macht, mit Geduld, auf Italienisch und in Open Source – werden wir bald schreiben, mit weniger Vorsicht bei den Namen und mehr Zahlen auf dem Tisch.

In der Zwischenzeit, wenn Sie bis hierher gekommen sind, haben Sie bereits mehr Autopsie durchgeführt als 90 % der Entscheidungsträger, die derzeit einen Vertrag für einen Unternehmens-Chatbot unterzeichnen, ohne eine der Fragen zu stellen, die Sie beim Lesen dieser Kapitel gestellt haben. Das ist ein besserer Ausgangspunkt, als der, von dem sie ausgegangen sind. Und in den kommenden Monaten wird der Unterschied zwischen denen, die sich diese Fragen gestellt haben, und denen, die es nicht getan haben, auf den Rechnungen sehr deutlich sichtbar werden – und auf den Antworten, die Ihre KI Ihren Kunden geben wird.

Diese Untersuchung wurde im April 2026 verfasst und basiert auf der Erfahrung von achtzehn Monaten Design, Konstruktion und Optimierung von RAG-Systemen für Unternehmen zwischen Ende 2024 und Anfang 2026.