Diese Serie dreht sich um eine These: Nicht das größte Sprachmodell entscheidet über den Nutzen einer KI im Unternehmen, sondern dein Wissen. In RAG einfach erklärt (Teil 3) hast du gesehen, wie RAG dieses Wissen zur Laufzeit an das Modell liefert, statt es hineinzutrainieren. Was dabei wie eine Blackbox wirkte, öffnen wir jetzt.
Zwischen deiner gescannten Wartungsanleitung und der fertigen Antwort im Chat liegen vier handfeste Stationen: die Texterkennung (OCR), das Zerlegen in Abschnitte (Chunking), die Umwandlung in Vektoren (Embedding) und die Ablage in einer Vektordatenbank. An jeder entscheidet sich, ob dein System später verlässlich antwortet oder plausibel klingenden Unsinn produziert. Ich gehe die Kette durch, mit Blick auf die Stellen, an denen es im Mittelstand hakt.
OCR: Wo die Kette am häufigsten reißt
Bevor eine KI ein Dokument verwerten kann, muss der Inhalt als maschinenlesbarer Text vorliegen. Bei einer sauber exportierten Word-Datei ist das trivial, doch der Mittelstand lebt von anderem Material: eingescannten Verträgen, abfotografierten Typenschildern, technischen Zeichnungen und Prüfprotokollen, auf denen der Meister seinen Vermerk mit dem Kugelschreiber ergänzt hat. Hier kommt OCR ins Spiel, die optische Texterkennung, die aus Pixeln wieder Buchstaben macht. Was sie falsch liest, wird falsch zerlegt, falsch in einen Vektor übersetzt und später falsch gefunden.
Der wunde Punkt im Mittelstand ist die Handschrift, und hier zeigen sich klare Unterschiede. Azure Document Intelligence (Version 4.0) erkennt Deutsch für Druck und Handschrift; die Handschrifterkennung ist auf zwölf Sprachen begrenzt, Deutsch gehört dazu. Google Document AI beherrscht deutschen Drucktext, aber keine deutsche Handschrift. Amazon Textract liest deutschen Druck, Handschrift jedoch ausschließlich auf Englisch. Stehen auf deinen Dokumenten handschriftliche Anmerkungen, in Qualitätssicherung oder Service ist das die Regel, kann diese eine Eigenschaft wichtiger sein als jeder Genauigkeitsvergleich.
Ein zweiter Klassiker sind Tabellen. Eine Stückliste oder ein Prüfplan verliert seinen Sinn, wenn Zeilen und Spalten beim Einlesen zu Textbrei zerfallen. Modernere Dienste rekonstruieren die Struktur explizit: Mistral OCR 3 (seit dem 17. Dezember 2025 verfügbar) baut Tabellen mit HTML-Tags inklusive Spalten- und Zeilenverbünden nach und liefert Markdown, JSON oder reinen Text, zu rund 2 US-Dollar pro 1.000 Seiten, im Batch-Betrieb die Hälfte. Mistral nennt eine Gewinnrate von 74 Prozent, allerdings gegenüber dem eigenen Vorgänger, nicht im unabhängigen Wettbewerbsvergleich. Für eine überprüfbare Einordnung schaust du besser auf einen neutralen Benchmark wie OmniDocBench (CVPR 2025). Und es muss nicht immer die Cloud sein: Docling, ein quelloffenes Projekt der IBM-Forschung in Zürich, rekonstruiert Tabellen lokal, ideal für Dokumente, die dein Haus nicht verlassen sollen. Welchen Weg der richtige ist, klären wir in der KI-Beratung an deinem realen Material, nicht an einer Demo.
Chunking: Warum das Zerlegen über die Antwortqualität entscheidet
Ein 40-seitiges Qualitätshandbuch passt nicht am Stück in einen einzigen Vektor, denn jedes Embedding-Modell — die Software, die Text in einen Zahlenvektor übersetzt — hat ein Eingabelimit. Gemessen wird es in Tokens, den kleinsten Verarbeitungseinheiten eines Modells, also ganzen Wörtern oder Wortbruchstücken. text-embedding-3-large von OpenAI verarbeitet maximal 8.192 Tokens pro Durchlauf, die älteren Cohere-Modelle der v3.0-Reihe sogar nur 512. Alles darüber wird nicht gemittelt, sondern schlicht abgeschnitten und gar nicht kodiert. Deshalb zerlegst du Dokumente vorher in überschaubare Abschnitte, sogenannte Chunks.
In meinen Projekten ist schlechtes Chunking einer der häufigsten Gründe für schwache Antworten. Schneidest du mitten in einem Satz, findet die Suche nur den halben Abschnitt, und die entscheidende Hälfte fehlt. Es gibt drei gängige Strategien:
- Feste Größe: Der Text wird in Blöcke gleicher Länge geschnitten. Einfach, schnell, robust.
- Überlappung: Aufeinanderfolgende Chunks teilen sich einen Rand, damit an der Schnittkante keine Bedeutung verloren geht.
- Strukturbasiert oder semantisch: Getrennt wird entlang von Überschriften und Absätzen oder dort, wo sich das Thema erkennbar ändert.
Intuitiv klingt die semantische Variante am besten, die Forschung ist nüchterner. Eine begutachtete Studie (Findings of NAACL 2025) kommt zu dem Ergebnis, dass semantisches Chunking festes Chunking nicht zuverlässig schlägt. Vorteile zeigten sich vor allem bei künstlich zusammengesetzten Texten; bei realitätsnahen Dokumenten lag festes Chunking oft vorn. Die Autoren empfehlen es als die verlässlichere Wahl; die Embedding-Qualität überlagert den Effekt der Strategie ohnehin oft. In dieselbe Richtung zeigt ein Vergleich von NVIDIA über fünf Datensätze: Seitenweises Chunking erzielte im Mittel die höchste Genauigkeit bei der geringsten Streuung, das beste Ergebnis war aber datensatzabhängig, mal lagen 512, mal 1.024 Tokens vorn. Die Lehre ist unbequem, aber ehrlich: Es gibt keine universell richtige Chunk-Größe. Du startest mit einem soliden Standard und misst an deinen eigenen Dokumenten nach.
Zwei Details werden gern übersehen. Erstens die Einheit: Viele Werkzeuge messen die Chunk-Größe in Zeichen, nicht in Tokens. Der Default Data Loader in n8n etwa arbeitet mit 1.000 Zeichen und 200 Zeichen Überlappung. Zweitens die Sprache: Deutscher Text erzeugt laut einer Messung von Jina AI rund 20 bis 30 Prozent mehr Tokens als Wörter, weil Umlaute und lange Komposita von englisch-zentrierten Tokenizern in mehrere Bruchstücke zerlegt werden. Wer die Chunk-Größe in Zeichen einstellt, während das Limit in Tokens gilt, füllt das Token-Budget auf Deutsch also schneller, als eine Wortzählung vermuten lässt. Zusätzlich lohnt sich Contextual Retrieval, bei dem jedem Chunk vor dem Ablegen eine kurze, vom Modell erzeugte Einordnung in das Gesamtdokument vorangestellt wird. Anthropic beziffert den Effekt: Die Fehlerrate beim Abruf der besten Treffer sinkt um 35 Prozent allein durch kontextangereicherte Embeddings, um 49 Prozent zusammen mit einer klassischen Stichwortsuche.
Vom Chunk zum Vektor: Embeddings und der Dimensions-Hebel
Ist ein Chunk fertig, übersetzt ihn das Embedding-Modell in einen Vektor: eine lange Liste von Zahlen, die die Bedeutung des Textes als Punkt in einem hochdimensionalen Raum beschreibt. text-embedding-3-large erzeugt standardmäßig 3.072 solcher Zahlen, die kleinere Variante 1.536. Wichtig: Eine Dimension ist kein Wort und kein Begriff, sondern eine Koordinatenachse im Bedeutungsraum; erst das Zusammenspiel aller Achsen ergibt die Bedeutung.
Mehr Dimensionen bedeuten mehr Speicherbedarf, höhere Rechenkosten und mehr Latenz. Bringen sie auch bessere Antworten? Innerhalb desselben Modells tendenziell ja, über Modelle hinweg nein. OpenAI belegt das selbst: Ein auf nur 256 Dimensionen gekürztes text-embedding-3-large schlägt im MTEB-Benchmark ein volles text-embedding-ada-002 mit 1.536 Dimensionen. Die Modellqualität schlägt die Dimensionszahl. Wer Kosten sparen will, wählt zuerst das bessere Modell und die Dimensionen danach.
Möglich macht das Matryoshka Representation Learning (NeurIPS 2022), benannt nach den verschachtelten Puppen: Das Modell bündelt die wichtigsten Informationen in den vordersten Dimensionen, sodass ein Vektor sich nachträglich kürzen lässt, ohne alles neu zu berechnen. OpenAIs neue Modelle, Googles gemini-embedding-2 (128 bis 3.072 Dimensionen) und Cohere embed-v4.0 (256, 512, 1.024 oder 1.536) unterstützen das. mistral-embed dagegen liefert fest 1.024 Dimensionen. Vorsicht bei den älteren Cohere-v3.0-Modellen: Deren Dimensionen sind fest, und das Eingabelimit liegt bei nur 512 Tokens, das auf Deutsch noch schneller erschöpft ist.
Die Vektordatenbank: Näherungssuche in Millisekunden
Jetzt liegen deine Chunks als Vektoren vor, oft viele Tausende. Die Vektordatenbank muss zu einem Suchvektor die ähnlichsten gespeicherten Vektoren finden, in Millisekunden. Ein Detail wird gern unterschlagen: Das ist eine Näherungssuche. Verfahren wie HNSW oder IVFFlat erkaufen ihr Tempo damit, dass sie nicht garantiert die tatsächlich ähnlichsten Treffer liefern. Wie genau die Suche sein soll, steuerst du über einen Recall-Regler (bei pgvector etwa ef_search), und genau dieser Regler, nicht die Dimensionszahl, ist in der Praxis der wichtigste Hebel für die Latenz.
Einen Spezialdienst brauchst du dafür meist nicht. Mit der Erweiterung pgvector wird ein normales PostgreSQL zur vollwertigen Vektordatenbank, mit Näherungsindizes und sechs Distanzmaßen, ohne Index sogar mit exakter Suche. Alternativen wie Chroma, Qdrant oder Pinecone sind selten nötig, bevor die Datenmengen wirklich groß werden. Eine harte Grenze musst du bei pgvector kennen: Der Standardtyp fasst bis zu 16.000 Dimensionen, der schnelle HNSW-Index aber nur bis 2.000. Ein 3.072-dimensionaler Vektor von text-embedding-3-large lässt sich damit nicht ohne Weiteres indizieren; du weichst dann auf den Typ halfvec (bis 4.000) aus oder kürzt die Dimensionen. pgvector steht übrigens unter der freien PostgreSQL-Lizenz, Chroma unter Apache 2.0; beide lassen sich ohne Lizenzkosten selbst hosten.
Die Lock-in-Falle: Modell und Datenbank austauschbar halten
Oft hörst du die Warnung, eine Managed-Lösung sperre dich für immer ein, du kämst an deine Vektoren nie wieder heran. Das ist in dieser Pauschalität falsch. Amazon Bedrock Knowledge Bases etwa erlaubt ausdrücklich einen selbst angelegten Vektorspeicher, von Aurora PostgreSQL mit pgvector über Pinecone bis MongoDB Atlas, und die Vektoren liegen dann in deiner eigenen Datenbank. Das echte Lock-in-Risiko sitzt woanders:
- Die proprietäre Chunking- und Ingestion-Konfiguration, die sich nicht mitnehmen lässt. Wie ein Anbieter zerlegt und anreichert, bleibt bei ihm.
- Die Bindung an ein bestimmtes Embedding-Modell. Wechselst du das Modell, musst du sämtliche Vektoren neu berechnen, bei jedem Anbieter, denn Vektoren verschiedener Modelle liegen in unvergleichbaren Räumen.
- Die Tatsache, dass Modell und Dimension beim Anlegen des Index festgelegt und danach nicht mehr geändert werden können.
Daraus folgt eine schlichte, aber eiserne Regel: Beim Suchen musst du exakt dasselbe Embedding-Modell verwenden wie beim Indexieren. Wer sich Freiheit erhalten will, hält zwei Dinge in eigener Hand: die Originaldokumente und die Zerlegungs-Pipeline. Solange du beides kontrollierst und deine Vektoren in einem offenen Speicher wie pgvector liegen, bleiben Modell und Datenbank austauschbar. Genau so bauen wir Wissenssysteme in der Wissens-KI: auf einem Fundament, das dir gehört und sich als Teil der Prozessoptimierung in bestehende Abläufe einfügt.
Häufige Fragen
Brauche ich für deutsche Dokumente ein spezielles OCR-System?
Für reinen Drucktext beherrschen alle großen Dienste Deutsch. Der Unterschied liegt bei der Handschrift: Azure Document Intelligence erkennt deutsche Handschrift, Google Document AI und Amazon Textract nicht (Textract nur englische). Wenn auf deinen Dokumenten handschriftliche Vermerke stehen, ist das oft das ausschlaggebende Kriterium.
Welche Chunk-Größe ist die richtige?
Es gibt keine allgemeingültige Antwort. Seitenweises Chunking ist ein guter Startpunkt; danach vergleichst du Größen von einigen hundert bis rund tausend Tokens an deinen eigenen Dokumenten. Entscheidend ist, dass du auf echten Daten misst, statt eine Faustregel zu übernehmen.
Was passiert, wenn ich später das Embedding-Modell wechsle?
Dann musst du deinen kompletten Bestand neu einbetten, weil Vektoren verschiedener Modelle in unvergleichbaren Räumen liegen. Triff die Modellwahl also bewusst und behalte Originaldokumente sowie Pipeline in eigener Hand.
Brauche ich eine spezielle Vektordatenbank wie Pinecone?
Für die meisten Mittelstands-Datenmengen nicht. Läuft bei dir ohnehin ein PostgreSQL, macht die Erweiterung pgvector daraus eine vollwertige Vektordatenbank, ohne zusätzliches System. Spezialdienste wie Chroma, Qdrant oder das gehostete Pinecone lohnen sich meist erst, wenn die Bestände wirklich groß werden.
Fazit
Der Weg von der PDF zur Antwort ist kein Knopfdruck, sondern eine Kette aus vier Stationen. Die gute Nachricht für den Mittelstand: Keine verlangt einen Konzern-Etat. Sauberes OCR, ein an den eigenen Dokumenten gemessenes Chunking, ein bewusst gewähltes Embedding-Modell und ein offener Vektorspeicher wie pgvector reichen für ein System, das dir gehört.
Doch selbst die beste Vektorsuche hat eine Schwäche: Sie findet, was bedeutungsähnlich ist, und übersieht manchmal genau den Treffer, der eine bestimmte Artikelnummer oder einen exakten Fachbegriff enthält. Warum reine Vektorsuche allein nicht reicht und wie sich diese Lücke schließen lässt, liest du in Hybrid Search und Reranking (Teil 5). Willst du deine Wissensbasis nicht selbst zusammenbauen, sondern gleich richtig aufsetzen, dann sprich mich über die Kontaktseite an.