# Chunk-RAG optimiert Ähnlichkeit. Atomizer optimiert Belegbarkeit.

**Autor:** Oliver Welling, DoWell UG (haftungsbeschränkt)  
**Kanonische URL:** https://brunosan.de/ki-praxis/standpunkt/rag-gegen-atomizer/  

> Belegarten: ✓ verifiziert · › berichtet · ○ Einordnung · — Leerstelle

Standpunkt: Chunk-RAG optimiert Ähnlichkeit, Atomizer Belegbarkeit. Warum bei Entscheidungen, für die ein Unternehmen haftet, die Fundstelle zählt — und wo klassisches RAG genügt. Mit offengelegtem Interessenkonflikt.

Standpunkt · Dokumenten-KI und Belegbarkeit

Das ist keine graduelle Verbesserung, sondern ein anderes Architekturprinzip. Sobald ein Unternehmen auf Dokumenten haftet, zahlt oder entscheidet, zählt zu jeder Antwort die Fundstelle — nicht der ähnlichste Textausschnitt.

Objekttyp

Standpunkt

Das ist ein Argument, keine Messung. Das Beispiel stammt aus einem einzelnen eigenen Lauf, die technischen Aussagen sind Einordnungen mit genannter Regel — und Atomizer ist mein Produkt (Abschnitt 07).

**Oliver Welling** · KI-Berater, DoWell UG 2. Oktober 2026 Beleglage: 2 Forschungsarbeiten · 1 eigener Lauf · keine Messreihe

Worum es geht

## „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.

**Was ich mit „RAG“ meine**

Klassisches, chunk-basiertes Vektor-RAG — ohne strukturierte IDs, Relationen und Evidence-Gate. Systeme mit Metadatenfiltern, Hybrid-Suche oder Reranking sind besser. Warum sie den Kernunterschied aus meiner Sicht nicht auflösen, steht in Abschnitt 01; die Gegenrede in Abschnitt 05.

**Interessenkonflikt vorab**

Atomizer ist ein Produkt der DoWell UG, die ich führe. Dieser Standpunkt ist entsprechend interessengeleitet. Abschnitt 07 legt das offen, Abschnitt 05 enthält die stärksten Einwände gegen meine These.

#### Belegarten · auch in einem Standpunkt

✓

VerifiziertAus unseren Daten exakt ableitbar oder in einer Primärquelle belegt.

›

BerichtetJemand berichtet es. Wer, steht im Satz. Nicht selbst geprüft.

○

EinordnungMeine Ableitung. Die zugrunde liegende Regel steht dabei.

—

LeerstelleWeiß ich nicht. Wird angezeigt statt gefüllt.

01 · Die Grundeinheit

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

Worum es geht

Die Grundeinheit bestimmt, was ein System überhaupt beantworten kann. Beim Chunk-RAG ist es ein Textausschnitt. Bei Atomizer ein typisiertes Objekt mit eigener ID.

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

| Dimension | Klassisches Chunk-RAG | Atomizer (Herstellerangabe) |
| --- | --- | --- |

| **Grundeinheit** | Text-Chunk — je nach Konfiguration einige hundert Tokens | Typisiertes Wissensatom (Betrag, Anbieter, Frist, Klausel …) |

| **Identität** | Position im Vektorraum, keine feste ID | Eigene, referenzierbare ID pro Atom |

| **Beziehungen** | Nicht modelliert — Chunks kennen sich nicht | Objekt ↔ Quelle ↔ Originalstelle ↔ andere Objekte |

| **Abruf** | Ähnlichkeitsranking, Top-k-Auswahl | Gezielte Objektabfrage plus Volltextsuche |

| **Aggregation** | Nicht möglich — Vektoren repräsentieren Bedeutung, keine Werte | SUM, COUNT, AVG über strukturierte Felder |

| **Widersprüche** | Werden beim Zusammenfassen oft geglättet | Werden sichtbar gemacht, nicht heimlich aufgelöst |

| **Antwort ohne Beleg** | Meist trotzdem eine — mehr oder weniger vage | „Nicht aus Ihren Daten belegbar“ als vollwertige Antwort |

### 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](/atomizer/technik/).

02 · Das Beispiel

## Eine Rechnung, zwei Sichtweisen.

Der Anlass

In einem eigenen Atomizer-Lauf mit einer OpenRouter-Rechnung wurde der Betrag **63,03 USD** als Objekt erfasst. Das ist ein einzelner Lauf mit einem einzelnen Dokument ›

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

| Chunk-RAG-Ansatz | Atomizer-Ansatz (eigener Lauf) |
| --- | --- |

| „OpenRouter“ steht irgendwo im Textausschnitt | Objekt „Anbieter“ = OpenRouter, Inc., mit ID |

| „63,03“ steht irgendwo, womöglich ohne Währung im selben Ausschnitt | Objekt „Betrag“ = 63,03 USD, mit Quelle verknüpft |

| Fundstelle: „irgendwo im Dokument“ | Fundstelle: Seite 1 von 1, Originalkontext sichtbar |

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: —

03 · Woher die Atome kommen

## Auch Atomizer nutzt ein Sprachmodell.

Der ehrliche Teil

Jedes System, das unstrukturierte Dokumente in strukturierte Objekte verwandelt, tut das irgendwo mit einem Modell — Fehlerrisiko inklusive. Der Unterschied liegt nicht darin, dass das Risiko verschwindet, sondern wo es aufgefangen wird.

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 ○

04 · Meine Schlussfolgerung

## Eine Antwort ist nur so viel wert wie ihre Fundstelle.

Der Kern dieses Standpunkts

Für alles, wofür Unternehmen haften, zahlen oder entscheiden, ist strukturierte Belegbarkeit keine Kür, sondern die Mindestvoraussetzung. RAG findet Ähnlichkeit. Atomizer liefert Belege.

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 ○

| Rolle | Frage | Chunk-RAG typischerweise | Atomizer (Herstellerangabe) |
| --- | --- | --- | --- |

| Geschäftsführung | „Wo liegen unsere Vertragsrisiken?“ | Ähnliche Textstellen, ungeprüft | Typisierte Risiko-Objekte mit Beleg |

| Recht & Einkauf | „Welche Kündigungsfrist gilt?“ | Möglicherweise die falsche Vertragsversion | Versionierte Klausel mit Quellverweis |

| Controlling | „Summe aus 300 PDF-Rechnungen?“ | Fehleranfällig, chunk-abhängig | Objekt „Betrag“ je Rechnung, aggregierbar |

| Vertrieb | „Was wurde 2022 vereinbart?“ | Trifft es vielleicht, vielleicht nicht | Original-Mail plus Sondervereinbarung, belegt |

### 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](/atomizer/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](/atomizer/sicherheit/).

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

05 · Gegenrede

## 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.

#### Einwände

„Ein gutes RAG mit Metadatenfiltern, Hybrid-Suche und Reranking reicht.“

Für viele Chat-Anwendungsfälle ja: Es ist solide und schnell umgesetzt. **Meine Antwort:** Für Fragen, für die ein Unternehmen haftet — Summen, Fristen, Vertragsversionen — fehlen ihm Identität, Relation und Aggregation. Wo die Grenze für Ihre Fragen liegt, kann ich nicht allgemein beantworten: —

„Ein Objektmodell hat einen Preis.“

Berechtigt. Jede Typisierung bedeutet Extraktionsaufwand, ein Schema, das gepflegt werden will, und Mehrdeutigkeit, wenn ein Dokument sich nicht sauber einem Objekttyp zuordnen lässt. Ein Stimmungsbild oder ein loses Brainstorming-Protokoll profitiert von starrer Typisierung nicht. **Meine Antwort:** Genau dort würde ich Atomizer nicht einsetzen.

„Atomizer nutzt selbst ein Sprachmodell — das Risiko ist dasselbe.“

Zum Teil richtig, siehe Abschnitt 03. **Meine Antwort:** Das Risiko verschwindet nicht, es wird zuordenbar und stichprobenfähig. Wie hoch es ist, habe ich nicht gemessen: —

„Für offene Fragen ist ein Chat mit RAG pragmatischer.“

Stimmt. Wer „Erklär mir Quantencomputing“ fragt, braucht keine Objekte mit IDs. **Meine Antwort:** Mein Argument gilt nur für konkrete, belegbare Fakten aus dem eigenen Dokumentenbestand.

„Sie verkaufen Atomizer — Ihr Vergleich ist nicht neutral.“

Richtig, und deshalb gibt es Abschnitt 07. **Meine Antwort:** Prüfen Sie die Behauptungen an Ihren eigenen Dokumenten, nicht an meinem Text. Eine unabhängige Gegenprobe mit offenen Rohdaten liegt nicht vor: —

06 · Für die Praxis

## 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.

Prüfliste ○

- **01** **Fundstelle.** Führt jede Antwort bis zur Seite und Stelle im Original zurück — oder nur zu „irgendwo im Dokument“?

- **02** **Aggregation.** Können Sie eine Summe oder Anzahl über alle Dokumente bilden, ohne dass ein Sprachmodell rechnet?

- **03** **Widerspruch.** Zeigt Ihr System widersprüchliche Angaben an — oder glättet es sie zu einer Antwort?

- **04** **Nichtwissen.** Darf es „nicht aus Ihren Daten belegbar“ antworten, statt etwas Plausibles zu liefern?

- **05** **Austausch.** Könnten Sie das Sprach- oder Einbettungsmodell wechseln, ohne den Wissensbestand neu aufzubauen?

Angewandte Regel

Die Fragen folgen aus dem Argument dieses Textes und sind Betriebserfahrung, keine Ableitung aus der zitierten Literatur.

07 · Offenlegung

## Ich verdiene Geld mit dieser Meinung.

Interessenkonflikt

Atomizer ist ein Produkt der DoWell UG, die ich führe. Wenn Sie meiner These folgen, könnten Sie bei uns landen. Das sollten Sie beim Lesen wissen.

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.

08 · Methodenblatt und Belege

## Was gemessen wurde — und was nicht.

**Methodenblatt**

**Gegenstand:** Vergleich zweier Architekturprinzipien für Dokumenten-KI. **Art der Aussage:** Argument. **Gemessen:** nichts. **Beispiel:** ein Dokument, ein Lauf, Rohdaten nicht veröffentlicht. **Leerstellen:** Fehlerquote der Extraktion · Messreihe über viele Dokumente · Verhalten konkreter RAG-Systeme mit Filtern und Reranking.

| Quelle | Inhalt | Datum | Art | Zit. |
| --- | --- | --- | --- | --- |

| [2005.11401](https://arxiv.org/abs/2005.11401) | Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks | 2020-05-22 | Primär · Forschung | 890 |

| [2404.16130](https://arxiv.org/abs/2404.16130) | From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft) | 2024-04 | Primär · Forschung | — |

| [Atomizer](/atomizer/) | Produktseiten zu Technik, Datenhoheit und Sicherheit | — | Herstellerangabe | — |

| Eigener Lauf | OpenRouter-Rechnung · Betrag 63,03 USD · ein Dokument · Rohdaten nicht veröffentlicht | — | Eigene Erhebung | — |

Zitationszahlen sind Referenzkanten innerhalb des BrunoSan-Bestands (Stand 23.07.2026), keine Google-Scholar-Werte. Angaben zu Atomizer sind Herstellerangaben.

09 · Offene Fragen

## Was Leser dazu meistens fragen.

Was ist der Unterschied zwischen Chunk-RAG und Atomizer?

Chunk-RAG zerlegt Dokumente in Textausschnitte, wandelt sie in Vektoren um und holt bei einer Frage die ähnlichsten Ausschnitte. Atomizer zerlegt Dokumente in typisierte Objekte (zum Beispiel Betrag, Anbieter, Frist) mit eigener ID, Quelle und Originalstelle. Das erste optimiert auf Ähnlichkeit, das zweite auf Belegbarkeit.

Warum kann Chunk-RAG keine Gesamtsumme aus vielen Rechnungen bilden?

Einbettungsvektoren kodieren Bedeutung, keine rechenbaren Zahlenwerte. Ein reines Retrieval findet ähnliche Textstellen, aber keine Summe. Mit typisierten Feldern lässt sich dagegen wie in einer Datenbank summieren, zählen und mitteln. Eine Messreihe dazu habe ich nicht veröffentlicht.

Ersetzt Atomizer klassisches RAG?

Nein. Für offene, explorative Fragen ohne festen Bezug zu eigenen Dokumenten ist ein Chat mit RAG oft der pragmatischere Weg. Atomizer spielt seine Stärke bei konkreten, belegbaren Fakten aus dem eigenen Dokumentenbestand aus.

Nutzt Atomizer nicht auch ein Sprachmodell?

Ja. Jedes System, das unstrukturierte Dokumente in Objekte verwandelt, nutzt irgendwo ein Modell und trägt Fehlerrisiko. Der Unterschied: Die Extraktion läuft einmal pro Dokument mit fester Typisierung, ein Fehler lässt sich über die ID gezielt korrigieren, und die Originalstelle erlaubt Stichproben. Die Fehlerquote habe ich nicht veröffentlicht.

Löst GraphRAG das Problem?

GraphRAG von Microsoft zielt auf thematische Fragen über ein ganzes Korpus und nutzt dafür vorab erzeugte Zusammenfassungen. Für belegbare Einzelwerte wie Beträge und Fristen löst es das Problem aus meiner Sicht nicht, weil es auf Textausschnitten aufsetzt und zusätzlich Zusammenfassungen einführt.

Gibt es bei Atomizer einen Vendor-Lock-in?

Nach Herstellerangabe liegt die Wissensbasis als SQLite-Datenbank vor, Einzelergebnisse zusätzlich als JSON, Markdown oder CSV. Details stehen auf der Seite zur Datenhoheit von Atomizer.

Woher die Zahl kommt

Die einzige gemessene Zahl in diesem Text, 63,03 USD, stammt aus einem eigenen Atomizer-Lauf mit einer Rechnung von OpenRouter. Alles andere ist Argument — und als solches gekennzeichnet.

Für Ihre eigenen Dokumente: [**Atomizer**](https://brunosan.de/atomizer/) macht Verträge, Rechnungen und Protokolle zu abfragbaren Objekten mit ID und Beziehungen. [**BrunoSan Assistant**](https://brunosan.de/assistant/de.html) beantwortet Fragen darauf — mit Quelle zur Originalstelle.

[Ihre Dokumente besprechen](https://dowell-consulting.de/kontakt.html) [Atomizer ansehen](https://brunosan.de/atomizer/)

Weiterlesen

[RAG ist angekommen — jetzt wird es eingebaut →](/ki-praxis/check/rag/) Der Reality-Check zur Technik hinter fast jedem Dokumenten-Assistenten.

[Souveränität ist keine Flaggenfrage →](/ki-praxis/standpunkt/souveraenitaet-architektur/) Der Standpunkt zur Frage, warum Wissen und Zustand außerhalb des Modells liegen sollten.