Pexon Consulting | 8 Min. Lesezeit | 19.04.2026
TL;DR
Standard RAG scheitert bei technischen Dokumenten an fünf Stellen: Tabellen zerfallen beim Chunking, Zeichnungen werden ignoriert, Querverweise gehen verloren, der einmalige Retrieval-Schritt kompensiert schwache Treffer nicht, und ohne Evidenzprüfung entstehen plausible Halluzinationen. Pexon Consulting baut als Microsoft Partner mit 80 Mitarbeitern aus Deutschland multimodale Agentic-RAG-Systeme die genau diese Lücken schließen.
Das Problem zeigt sich meistens in Woche 6
Ein Piloteinsatz läuft zwei Monate. Der erste Demo-Call ist stark, die Stakeholder sind begeistert. In Woche 6 kommt die erste echte Nutzerfrage aus dem Engineering-Team: „Welche Toleranz gilt für die M8-Bohrung nach ISO 2768 bei Guss?“ — und das System antwortet selbstbewusst mit einer Zahl, die in der Norm nicht steht.
Dieses Szenario sehen wir bei Kunden im Maschinenbau und Automotive immer wieder. Die Architektur ist Standard-RAG: PDF-Loader, Text-Splitter, Embedding in eine Vektordatenbank, OpenAI oder Claude für die Antwort. Funktioniert für FAQ-Bots. Funktioniert nicht für DIN-, ISO- oder VDI-Normen.
Laut Gartner scheitern bis zu 40 Prozent aller agentischen KI-Projekte an Kosten oder Governance-Lücken. Unsere Erfahrung aus 2025 zeigt: Ein großer Teil dieser Fehlschläge beginnt früher — nämlich mit einer RAG-Architektur, die dem Inhalt der Dokumente nicht gewachsen ist.
Tabellen zerfallen beim Chunking
Technische Normen bestehen zu einem großen Teil aus Tabellen. Toleranztabellen, Werkstoffkennwerte, Prüfintervalle, Spannungsklassen. Ein Standard-RAG-Pipeline zerschneidet Dokumente in Text-Chunks von typischerweise 500 bis 1.000 Tokens — und zerstört dabei den Zusammenhang zwischen Zeile und Spalte.
Ein einfaches Beispiel aus einer LangChain-Baseline:
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
loader = PyPDFLoader("ISO_2768_Guss.pdf")
pages = loader.load()
splitter = RecursiveCharacterTextSplitter(
chunk_size=800,
chunk_overlap=100,
)
chunks = splitter.split_documents(pages)
# Problem: Die Toleranztabelle auf Seite 4 wird
# an einer Leerzeile gesplittet. Zeile fuer "M8"
# landet in Chunk A, Header in Chunk B.Im Retrieval matcht die Embedding-Suche auf einen Chunk mit den Zahlen — aber ohne den Header, auf den sich die Zahlen beziehen. Das Modell bekommt „±0,2″ ohne zu wissen, dass es die Spalte „fein“ für die Größenklasse „6-30 mm“ war.
Die Antwort klingt plausibel. Sie ist trotzdem falsch.
Technische Zeichnungen sind der blinde Fleck
Zeichnungen, Schaltpläne, Symboliken und Bemaßungen werden von Text-Pipelines entweder komplett ignoriert oder per OCR in sinnlose Zeichenfolgen überführt. Ein Blechteil mit Kennzeichnung „Ø42 H7″ ist für Standard-RAG ein String aus drei Zeichen — nicht „Durchmesser 42 mm mit Passungsklasse H7″.
Das ist kein Edge Case. In unseren Kundenprojekten bestehen technische Spezifikationen zu 30 bis 50 Prozent aus visuellen Informationen. Wer das ignoriert, lässt die Hälfte des Dokuments liegen.
Unsere klare Empfehlung: Wenn ein Anwendungsfall technische Dokumente mit Zeichnungen betrifft, ist ein textbasiertes RAG-System die falsche Architektur. Hier braucht es Vision Language Models, die Zeichnung, Bemaßung und zugehörige Tabelle gemeinsam erschließen. Wir setzen dafür in der Regel GPT-4.1 Vision, Claude Sonnet oder unser eigenes PexonParse-VLM ein — je nach Domäne und DSGVO-Anforderung.
Querverweise zwischen Normen gehen verloren
Normen leben von Verweisen. „Es gelten die Anforderungen nach DIN EN ISO 3834-2 in Verbindung mit Abschnitt 7.3 dieser Norm.“ Ein Chunk-basiertes RAG findet den Verweis — aber nicht den Zielabschnitt.
Was wir hier in Projekten regelmäßig beobachten:
- Verweise auf andere Normen werden gefunden, aber der referenzierte Text landet nicht im Kontext.
- Innere Querverweise („siehe Abschnitt 7.3″) scheitern, weil die Chunks keine Abschnittsstruktur kennen.
- Wenn mehrere Normen den gleichen Fachbegriff unterschiedlich definieren, mischt das Modell sie in einer Antwort.
Die Lösung ist kein größeres Kontextfenster. Die Lösung ist ein strukturbewusstes Ingest-Verfahren, das Abschnittsnummern, Querverweise und Normen-IDs als Metadaten mitführt — und ein Agent, der bei erkannten Verweisen nachlädt, bevor er antwortet.
Die Einmal-Retrieval-Falle
Standard-RAG macht einen Suchlauf, nimmt die Top-K Treffer und generiert eine Antwort. Das ist ein Schuss — wenn er nicht sitzt, kompensiert das System nichts.
Ein Agentic-RAG-Ansatz prüft dagegen nach dem ersten Retrieval: Reichen die Belege, um die Frage zu beantworten? Falls nicht, wird die Suchstrategie umformuliert und ein zweiter oder dritter Lauf gestartet. Pseudocode für den Kern-Loop:
query = rewrite_for_retrieval(user_question, chat_history)
docs = hybrid_search(query, k=8)
for attempt in range(MAX_ATTEMPTS):
verdict = evidence_agent.evaluate(user_question, docs)
if verdict.sufficient:
break
query = rewrite_query(
user_question,
missing=verdict.missing_facts,
)
docs += hybrid_search(query, k=8)
if not verdict.sufficient:
return uncertainty_response(verdict.missing_facts)
return answer_agent.generate(user_question, docs)Der Unterschied in der Praxis: Bei komplexen Normfragen liefert ein einmaliger Retrieval-Schritt in unseren Messungen 60 bis 70 Prozent Antwortqualität. Mit zwei bis drei selbstkorrigierenden Runden landen wir bei 85 bis 95 Prozent auf definierten Referenzfragen.
Keine Evidenzprüfung — keine Auditierbarkeit
Der fünfte und teuerste Failure-Mode: Standard-RAG antwortet immer. Auch wenn die Treffer fachlich nicht ausreichen, formuliert das Modell eine plausibel klingende Antwort. Für einen Marketing-Chatbot ist das ein Feature. Für technische Normen ist es ein Risiko.
Ein Engineering-Leiter aus dem Automotive-Bereich hat es uns letztes Quartal so formuliert: „Eine plausible falsche Antwort ist schlimmer als gar keine Antwort. Wenn mein Konstrukteur eine erfundene Toleranz in die Zeichnung übernimmt, kostet mich das im Schadensfall mehr als das gesamte RAG-Projekt.“
Agentic RAG mit einem dedizierten Evidenz-Agenten löst das, indem Antworten nur entstehen, wenn die Belege fachlich belastbar sind. Bei Unsicherheit zeigt das System die Lücke — statt zu halluzinieren. Für Audits im QA- und Compliance-Umfeld ist genau diese Transparenz der entscheidende Unterschied.
Laut Gartner benötigen bis 2026 über 70 Prozent aller Enterprise-GenAI-Initiativen strukturierte Retrieval-Pipelines mit Grounding und Evidenz-Kontrolle. Wer heute auf Text-only-RAG ohne Evidenz-Gate setzt, wird die Architektur in spätestens 12 Monaten umbauen.
Wann Standard-RAG trotzdem reicht
Fairerweise: Nicht jeder RAG-Use-Case braucht Agenten und Multimodalität. Wir raten klar zu Standard-RAG, wenn:
- Das Korpus aus reinem Fließtext besteht (Knowledge-Base-Artikel, Wiki, Marketing-Dokumente).
- Die Antwortanforderung niedrig ist und Halluzinationen keinen Schaden anrichten.
- Das Budget einen 6-Wochen-Pilot übersteigt und ein PoC reicht.
- Nutzer bereit sind, jede Antwort selbst zu prüfen.
Sobald technische Zeichnungen, Tabellen, Querverweise oder Audit-Anforderungen dazukommen, reicht Standard-RAG nicht mehr. Wir sehen diesen Kipppunkt fast immer zwischen Pilot und Rollout — also genau dann, wenn das Projekt Geld kosten soll, statt Demos zu liefern.
Der Umbau in der Praxis
Die gute Nachricht: Ein bestehender RAG-Pilot ist keine Fehlinvestition. Die Vektordatenbank, die Prompts und die UI sind wiederverwendbar. Was wir in typischen Projekten ergänzen:
Erstens eine multimodale Ingest-Pipeline, die Tabellen als Tabelle und Zeichnungen als Bild indexiert. Zweitens ein Multi-Agenten-Setup mit Kontext-, Retrieval- und Evidenz-Agenten. Drittens Observability mit Langfuse, um Qualität messbar zu machen und gegen ein Evaluationsset von 30 bis 50 Referenzfragen zu testen.
Typischer Zeitrahmen: 6 bis 8 Wochen für die Umstellung, Kosten zwischen 45.000 und 75.000 Euro je nach Korpusgröße und Komplexität. Details dazu in unserem 6-Wochen-Pilot-Angebot.
Häufig gestellte Fragen
Was kostet der Umbau von Standard-RAG auf Agentic RAG?
Zwischen 45.000 und 75.000 Euro für einen Korpus bis 5.000 Dokumente inklusive multimodaler Pipeline, Evidenzprüfung und Observability. Bestehende Komponenten wie Vektordatenbank oder UI lassen sich in der Regel weiternutzen.
Standard RAG vs Agentic RAG — wann lohnt sich welches?
Standard RAG reicht für Text-only-Korpora mit geringer Fehlerkritikalität. Sobald Tabellen, Zeichnungen, Querverweise oder Audit-Anforderungen dazukommen, ist Agentic RAG die richtige Wahl. Die Antwortqualität steigt auf Referenzfragen um 20 bis 35 Prozent.
Warum halluzinieren RAG-Systeme bei technischen Dokumenten?
Meist, weil der Retrieval-Schritt unvollständige Belege liefert (z.B. Tabellenzelle ohne Header) und das Sprachmodell die Lücke „füllt“. Ein Evidenz-Agent vor der Antwort verhindert das, indem er die Belastbarkeit der Belege prüft und bei Unsicherheit die Lücke transparent anzeigt.
Können bestehende LangChain- oder LlamaIndex-Piloten erweitert werden?
Ja. Wir bauen in unseren Projekten meistens auf LangGraph auf, was sich gut mit bestehenden LangChain-Komponenten kombinieren lässt. LlamaIndex-Piloten lassen sich in der Regel um eine Agenten-Schicht erweitern, ohne das Retrieval komplett neu zu schreiben.
Ist multimodales Agentic RAG DSGVO-konform nutzbar?
Ja. Wir setzen die Lösung wahlweise auf Azure OpenAI EU, AWS Frankfurt oder vollständig On-Premise um. Für regulierte Branchen wie Versicherung und Energie ist On-Premise mit Open-Weight-Modellen oft die sauberere Wahl, weil sensible Normen und Spezifikationen das Unternehmen nicht verlassen.
Nächster Schritt
Wenn Ihr RAG-Pilot an Qualitätsgrenzen stößt: In einem kostenlosen AI Readiness Assessment analysieren wir Ihre Architektur gegen 15 typische Failure-Modes und priorisieren die Umbaumaßnahmen nach Aufwand und Wirkung.
Verwandte Themen
→RAG und KI-Dokumentensuche
→Vision Language Model für technische Dokumente
