Chunk-RAG optimiert Ähnlichkeit.Atomizer optimiert Belegbarkeit.

„Wir haben doch ein RAG.“

Wer Dokumente im Unternehmen mit KI befragen will, landet fast immer bei RAG: Dokumente werden in Textstücke zerlegt, in Vektoren verwandelt, und bei einer Frage werden die ähnlichsten Stücke geholt. Das ist ein guter Anfang. Es beantwortet aber nicht die Frage, auf die es bei Rechnungen, Verträgen und Fristen ankommt: Woher weiß ich, dass das stimmt?

Meine These: Klassisches Chunk-RAG optimiert auf Ähnlichkeit. Atomizer optimiert auf Belegbarkeit. Das ist ein anderes Architekturprinzip — und genau deshalb stößt Chunk-RAG an seine Grenzen, sobald es um belastbare Unternehmensentscheidungen geht.

Ein Chunk ist ein Ausschnitt. Ein Atom ist ein Ding.

So beschreibe ich beide Ansätze. Die mittlere Spalte beschreibt das Grundmuster, nicht ein bestimmtes Produkt ○ Die rechte Spalte ist eine Herstellerangabe zu Atomizer.

Erstens: Alles ist ein Objekt

Eine Rechnungssumme ist für ein reines Chunk-System eine Ziffernfolge irgendwo in einem Ausschnitt, umgeben von Adresse, Zahlungsbedingungen und Fußzeile — alles gemeinsam in einen Vektor gepresst. Atomizer zerlegt dasselbe Dokument in typisierte Objekte: eines vom Typ „Organisation“, eines vom Typ „Betrag“, eines vom Typ „Frist“. Ein Objekt lässt sich gezielt abfragen, ein Chunk nur finden ○

Zweitens: Alles hat eine ID

Ein Einbettungsvektor beschreibt Ähnlichkeit, keine Identität ○ Das System weiß nicht, dass zwei unterschiedlich formulierte Aussagen dasselbe meinen, solange niemand diese Identität festlegt. Zudem kann sich eine Vektor-Nachbarschaft verschieben, wenn neue Daten dazukommen oder ein anderes Einbettungsmodell eingesetzt wird ○ Eine feste ID bleibt bestehen. Das ermöglicht:

• Deduplizierung — ein erkanntes Duplikat wird nicht erneut verarbeitet.
• Nachvollziehbarkeit — jede Antwort führt über die ID zur Originalstelle zurück.
• Stabilität — die ID bleibt, auch wenn neue Dokumente dazukommen.

Drittens: Alles ist verbunden

Verweist ein Vertrag in Abschnitt 3 auf eine Zusatzvereinbarung in Abschnitt 40, kennen die beiden zugehörigen Chunks einander nicht ○ — sie werden gemeinsam gefunden, wenn eine Anfrage beiden ähnlich genug ist. Metadatenfilter und Reranking sortieren Chunks besser vor, geben ihnen aber keine Beziehung zueinander ○ Atomizer verknüpft nach Herstellerangabe Objekt, Quelle, Originalkontext und verwandte Objekte explizit und beantwortet damit Fragen wie „Welche Verträge referenzieren Kunde X?“. Die Technik dahinter beschreibt die Seite Atomizer · Technik.

Eine Rechnung, zwei Sichtweisen.

Links steht, wie sich das einfache Chunk-Muster typischerweise verhält (Einordnung, nicht an einem bestimmten System gemessen ○), rechts das Ergebnis des Laufs.

Bei einem Dokument wirkt das akademisch. Bei 300 Rechnungen oder 500 Verträgen entscheidet es darüber, ob eine Wissensbasis nutzbar ist — so meine Einordnung ○ Gemessen habe ich das nicht: —

Der Punkt, den Vektoren nicht können: Rechnen

Eine Summe über Rechnungsbeträge lässt sich nicht aus Einbettungsvektoren berechnen ○ Die Frage „Wie hoch ist die Gesamtsumme aus 300 PDF-Rechnungen?“ kann ein reines Retrieval-System daher nicht verlässlich beantworten — es findet ähnliche Textstellen, keine Summe.

Typisierte Objekte mit stabilen IDs lassen sich dagegen aggregieren wie Datenbankfelder: SUM, COUNT und AVG über das Feld „Betrag“, wobei jede Zahl in der Summe ID, Quelle und Originalstelle behält. Ein Rechenbeispiel über viele echte Dokumente habe ich nicht: —

Ohne zusätzliche Struktur wird ein Top-k bei wachsender Dokumentenzahl tendenziell unschärfer ○ Auch das ist nicht gemessen: —

Auch Atomizer nutzt ein Sprachmodell.

Bei Atomizer geschieht die Extraktion nach Herstellerangabe einmal pro Dokument mit fester Typisierung, nicht bei jeder Anfrage neu unter Zeitdruck. Weil jedes Atom eine ID hat, lässt sich ein erkannter Fehler gezielt korrigieren, ohne die Wissensbasis neu aufzubauen. Weil es mit seiner Originalstelle verknüpft bleibt, lässt sich jede Extraktion stichprobenartig gegen das Original prüfen. Das macht die Extraktion nicht fehlerfrei, aber kontrollierbar ○ Wie hoch die Fehlerquote ist, habe ich nicht veröffentlicht: —

Und GraphRAG?

Das GraphRAG-Verfahren von Microsoft baut mit einem Sprachmodell einen Wissensgraphen aus den Dokumenten und erzeugt vorab Zusammenfassungen für Gruppen eng verwandter Entitäten ✓ Es zielt dabei auf globale Fragen über ein ganzes Korpus, etwa nach den Hauptthemen ✓.

Für solche thematischen Fragen ist das ein Fortschritt. Für belegbare Einzelwerte wie Beträge und Fristen löst es das Problem nicht ○

Eine Antwort ist nur so viel wert wie ihre Fundstelle.

Das ist keine neue Erkenntnis, sondern ein alter Grundsatz der Buchführung und Revision ○ Er heißt in der KI-Welt gerade nur anders.

Was das für Ihre Rolle heißt

Die Spalte zu Chunk-RAG beschreibt das typische Verhalten des einfachen Musters, die Spalte zu Atomizer ist eine Herstellerangabe ○

Was das für die IT-Architektur heißt

• Kein Vendor-Lock-in: Die Wissensbasis liegt als SQLite-Datenbank vor, Einzelergebnisse zusätzlich als JSON, Markdown oder CSV — Details auf der Seite Datenhoheit.
• Kostenkontrolle: Durch IDs und Deduplizierung werden identische Informationen nicht mehrfach verarbeitet oder abgerechnet.
• Audit-Sicherheit: Jede Information bleibt bis zur Stelle im Originaldokument nachvollziehbar — siehe Sicherheit.

Alles drei sind Herstellerangaben; prüfen Sie sie an den Produktseiten und im Gespräch, nicht an diesem Text.

Wo RAG besser ist — und wo ich falsch liegen könnte.

Ein Standpunkt ohne Gegenrede ist Werbung. Bei einem Produkt, das ich selbst verkaufe, gilt das doppelt. Hier sind die fünf stärksten Einwände gegen meine These.

Fünf Fragen an Ihr eigenes Dokumentensystem.

Nicht an einen Anbieter — an Ihr System. Wer alle fünf beantworten kann, weiß, ob er belegbare Antworten bekommt oder nur ähnliche.

Ich verdiene Geld mit dieser Meinung.

Deshalb steht jede Aussage über beide Ansätze als Einordnung mit Regel da, deshalb ist das Beispiel als einzelner Lauf gekennzeichnet, und deshalb gibt es Abschnitt 05. Eine Gegenprobe mit offenen Rohdaten — dieselben Rechnungen, einmal per Chunk-RAG und einmal per Atomizer, Summe gegen Summe — wäre die logische Folge. Sie liegt nicht vor: —

Was ich nicht behaupten kann: dass ich beide Ansätze ergebnisoffen verglichen hätte ○ Die These stand fest, bevor ich diesen Text geschrieben habe.

Was Leser dazu meistens fragen.