Gescannte Handbücher und Tickets mit Fotos: Wie ein Wissensgraph der 22-minütigen Support-Suche ein Ende setzt

Kernpunkte

• 70% einer 12.000-Dokument-Unterstützungsbibliothek haben keine Textebene — für einen Pumpenhersteller mit 460 Mitarbeitern sind rund 126.000 Seiten gleichermaßen unsichtbar für die Schlüsselwortsuche und für einen rein-Text-Vektorindex.
• Perplexitys pplx-embed-v2-late erreichte 92,4 % Antwortgenauigkeit auf MADQA — ein Agent beantwortete 500 Fragen über 800 reale PDFs mit mehr als 18.000 Seiten, indem er gerenderte Seiten direkt durchsuchte, ohne OCR-Pipeline, veröffentlicht am 7. Oktober 2026.
• Der 0.6B-Abfrageencoder kann einen Index abfragen, der mit dem 9B-Modell gebaut wurde — der geteilte Embedding-Raum paart teures Offline-Seitenindexieren mit billigen Live-Abfragen, und das 0.6B-Modell hat 594M Parameter unter MIT-Lizenz.
• LinkedIn GraphRAG Produktionsbereitstellung verbesserte die Retrieval-Genauigkeit um 77,6 % — die strukturellen Kanten eines Wissensgraphen sind das, was ein Vektorindex nicht sehen kann.
• Eine Seitenzitierregel verändert den Fehlermodus — keine Antwort verlässt den Agenten ohne ihre Dokumentseite, Teilenummer und Serienbereich; alles Unverifizierbare eskaliert an einen Menschen, statt an einen Kunden zu gehen.

Dreihundert der 950 Tickets, die ein Mittelstands-Hersteller von Pumpen und Wasserversorgungsanlagen jede Woche erhält, sind keine Produktbeschwerden. Es sind Dokumentfragen: welches Laufrad zu einer SP-200 von 1998 mit der Seriennummer 43-11092 passt, welches Servicebulletin die Drehtable des O&M-Handbuchs ersetzt, welche Dichtmasse die Überarbeitung von 2014 vorschreibt — jedes mit einem Foto des Typenschilds oder einem Scan einer Handbuchseite im Anhang. Die technische Bibliothek hinter diesen Fragen hält 12.000 Dokumente und rund 180.000 Seiten. Etwa 70% davon sind eingescanntes Papier ohne Textebene, stammend aus den 1970er Jahren, und die Suche von Zendesk liest nichts davon.

Die Kosten zeigen sich in zwei Warteschlangen. Intern bewältigen sechs technische Support-Kräfte im Durchschnitt eine 22-minütige manuelle Suche pro Dokumentfrage — PDF für PDF aufklappend, ein Handyfoto per Augenmaß mit einer Pumpenkurve abgleichend. Extern schreiben Händler und Wiederverkäufer ins Support-Postfach und warten median 14 Stunden auf eine Antwort. Zwei Senior-Techniker bearbeiten 55% der eskalierten Dokumentfragen und schlucken damit rund 19 Stunden pro Woche der Sucharbeit anderer. Und der schlimmste Fehler ist nicht der langsame: Ein missgelesener Schaltplan versendet die falsche Kartusche, verursacht einen Nachbeschaffungszyklus plus einen zweiten Vor-Ort-Termin und kostete dieses Unternehmen im letzten Jahr rund 38.000 $ an Frachtkosten und Retourenabwicklung.

Dieser Artikel zeichnet die dreischichtige Lösung nach — einen Wissensgraphen auf Seitenebene über der Dokumentbibliothek, Late-Interaction-Embeddings, die gerenderte PDF-Seiten direkt ohne OCR-Schritt durchsuchen, und einen Agentenfluss, der mit der exakten Seite im Anhang antwortet — jede Schicht verankert in ihrer Primärquelle: Perplexitys Veröffentlichung vom 7. Oktober 2026 und LinkedIn GraphRAG Produktionsbereitstellung.

Das Problem: die Bibliothek, in der alle aufgehört haben zu suchen

Jeder Hersteller mit Papiervergangenheit besitzt diese Bibliothek. Die Handbücher der letzten fünf Jahre wurden digital geboren. Alles Ältere kam per Scanner: Pumpenkennlinien, Verdrahtungspläne, Explosionszeichnungen, Maßtabellen. Manche Seiten haben lesbaren Text; viele sind degradierte Scans mit Heftlochungen, Faltkanten und handschriftlichen Anmerkungen am Rand. Die durchsuchbaren 30% sind der leichte Teil; die anderen 70% sind eine Wand aus Bildern, nur mit dem Dateinamen etikettiert — deshalb scheitern Schlüsselwortsuche und ein rein-Text-Vektorindex gleichermaßen: Beide brauchen einen Text, der nicht existiert.

Die naheliegende Lösung — „setze das Archiv einfach unter OCR" — starb den üblichen Tod. OCR-Fehler kumulieren auf degradierten Scans und landen genau dort, wo der Geschäftswert sitzt: Die Achsen der Pumpenkennlinien werden zum Zeichensalat, Maßtabellen geraten aus der Flucht, Spalten der Teilelisten verschmelzen. Das ist die Parse-then-Search-Pipeline, die das Perplexity-Team „teuer und verlustbehaftet" nennt — sie verwirft „Layout, Tabellenstruktur, Abbildungen und räumliche Beziehungen", bevor das Retrieval die Seite überhaupt sieht. Ein OCR-Wiederaufbau dieser Bibliothek wurde mit sechs Ziffern kalkuliert und nicht ein zweites Mal finanziert.

Ein Vektorsuch-Pilot scheiterte aus einem anderen Grund: Der eingebettete Text lieferte die richtige Form der Pumpenkurve für die falsche Revision, eine Dichtungsspezifikation aus einem Handbuch, das zur Maschine des Kunden nicht passt. Nichts in einem Vektorindex weiß, dass ein Laufrad ein anderes ablöst oder dass eine Drehtable für einen Serienbereich zurückgezogen wurde — plausible Ergebnisse, überzeugt falsch, genau die Antwort, die das falsche Teil versendet. Der Assistent wanderte in die Schublade; die beiden Senior-Techniker blieben das System of Record. Der frühere Support-Wissensgraph-Artikel dieser Seite zeigt denselben Fehlermodus bei Softwaredokumentation; bei gescannten Hardware-Bibliotheken wählt er die falsche Seite statt der falschen Übergangslösung.

Die agentenorchestrierte Lösung: ein Graph unter den Seiten, Embeddings auf den Seiten

Das funktionierende Muster lässt jede Schicht nur das tun, was sie gut kann.

Schicht 1 — ein Wissensgraph auf Seitenebene. Jedes Dokument wird zum Knoten; auch jede Seite darin ist ein Knoten, mit seinem gerenderten Bild nur einmal gespeichert. Teile, Pumpenmodelle, Serienbereiche und Revisionen sind Knoten, und die Kanten sind die Fakten, die Fragen beantworten: Handbuch 4412 dokumentiert Modell SP-200; Seite 118 enthält die Laufradtabelle; Laufrad 88-114 löst 88-114A für Serien oberhalb von 43-0850 ab; Bulletin 91-07 zieht die Drehtable auf Seite 40 zurück; und — aus der NetSuite-Bestellhistorie — die Serie 43-11092 ging 1998 an einen bestimmten Händler, und ihr Besitzer hält einen Servicevertrag. Nichts davon verlangt, dass die Seiten Text sind. Der Graph entsteht aus Katalogen, Bestelldatensätzen und Revisionskarten, die das Unternehmen ohnehin pflegt.

Schicht 2 — Embeddings auf Seitenebene über den gerenderten Seiten. Die gescannten 70% brauchen nie OCR: Perplexitys am 7. Oktober 2026 veröffentlichte pplx-embed-v2-late-Familie „handhabt Text-zu-Bild-Retrieval und erlaubt es, gerenderte PDF-Seiten direkt zu durchsuchen, ohne OCR oder geparsten Text zu benötigen". Beide Größen — 0.6B und 9B, MIT-lizenziert auf Hugging Face — erzeugen einen 128-dimensionalen Vektor pro Token und werten mit MaxSim im ColBERT-Stil aus, was das Detail erhält, das eine Pumpenfrage braucht: „Laufrad", „SP-200" und ein gezeichneter Wellendurchmesser matchen verschiedene Regionen derselben gerenderten Seite. Auf MADQA — 800 heterogene reale PDFs, mehr als 18.000 Seiten, 500 Fragen, so geschrieben, dass sie sich nicht aus Allgemeinwissen beantworten lassen — antwortet das 9B-Modell zu 92,4 % korrekt, das 0.6B-Modell zu 90,1 %; auf dem visuellen Dokument-Benchmark ViDoRe(v3) entspricht das 0.6B-Modell Modellen mit dem Fünffachen seiner aktiven Parameter. Weil beide Modelle sich einen Embedding-Raum teilen, wird die Bibliothek einmal mit dem 9B-Modell indexiert, während die Live-Ticket-Abfragen durch den 0.6B-Encoder laufen — der vollständig auf Hardware laufen kann, die der Hersteller kontrolliert, ein Detail, das zählt, wenn Handbücher die Vertraulichkeit der Kundensite tragen.

Schicht 3 — der Agentenfluss, der in einem Zitat endet, nicht in einem Absatz. Konnektormodule, die Model Context Protocol (MCP) sprechen, umhüllen Zendesk (Ticket, Anfragende, Anhänge), NetSuite (Bestellungen, Serienhistorie, Garantiestatus) und das Graph-Abfragewerkzeug. Der Fluss: Der Agent liest das Ticket und seinen Fotoanhang, fragt die Embeddings nach Kandidatenseiten in gerendertem Zustand ab und steigt dann in den Graph hinab, um zu bestätigen, was die Kandidatenseite behauptet — die richtige Revision, der richtige Serienbereich, der richtige Nachfolgezustand — und antwortet mit der echten PDF-Seite im Anhang, der Teilenummer im Text und der genannten Autorität („laut Bulletin 91-07, Seitentabelle auf Seite 40"). Die Governance-Regel ist eine Zeile, und sie trägt die Last: kein Seitenzitat, kein Versand — das Ticket eskaliert an einen Menschen. Eine Kauf-Frage reicht an eine RFQ-Engine, die Live-Verfügbarkeit hält für das Ersatzteil über und schließt die Lösung mit einem Preis enthaltenden Angebot ab; Händleranfragen delegieren über einen mit Scope versehenen A2A-Agenten, und jeder Retrieval- und Graph-Schritt wird nach dem Muster des Modulcode-Standards protokolliert. Der Implementierungsleitfaden behandelt den Graphenbau selbst; dies ist das Betriebsmuster, keine Garantie für jedes Archiv.

Die beiden Senior-Techniker bleiben in der Schleife, auf anderer Höhe: Sie genehmigen alles Sicherheitsrelevante, prüfen die markierte Low-Confidence-Warteschlange und handhaben, was der Graph nicht fundieren kann. Sie sind nicht mehr der Index der Bibliothek.

Das Ergebnis

Dasselbe Ticket, zwei Wege, es zu lösen — die manuelle Suche von heute gegen den agentenorchestrierten Fluss, der mit der exakten Seite im Anhang antwortet:

Repräsentative Zielwerte für einen Deployment dieser Form in diesem Unternehmensvolumen, zusammen mit der Benchmark-Evidenz, auf der das Muster ruht:

Metrik	Vorher	Agentenorchestriertes Ziel
Erstantwort auf Dokumentfragen	14 Stunden (Händlermail-Median)	Unter 2 Minuten, Seitenzitat + gerenderte Seite im Anhang
Medianer interner Durchlauf	22 Minuten manuelle Suche	3 Minuten — der Techniker prüft die angehängte Seite
Eskalationslast bei Senior-Technikern	55% der Dokumentfragen (~19 Std./Woche)	Unter 20% der Dokumentfragen
Fehlversendete Teile	9 im Quartal (38.000 $/Jahr)	1 im Pilotquartal
Durchsuchbare Seiten	54.000 (die 30% mit Textebene)	~180.000, gerenderte Seiten wie sie sind

Die Evidenz hinter dem Muster: agentische QA über reale gescannte PDFs mit 92,4 % Genauigkeit ohne OCR-Pipeline, graphstrukturiertes Retrieval im Wert von 77,6 % gemessener Retrieval-Genauigkeitsverbesserung bei LinkedIn, und ein Profil, das die Support-Wissensgraph-Deployment von der Softwareseite demonstriert hat (28 Stunden Lösung zu 7; Eskalation von 45% auf 18%). Ehrlicher Scope-Marker: MADQA ist ein Benchmark, kein Versprechen für jedes Archiv — deshalb bleiben Zitierregel und menschliche Prüfung in der Schleife.

Die tiefere Veränderung ist, dass die Bibliothek aufhört zu verfallen: Welches Dokument welches ablöst, welches Teil woran angeglichen wird und welche Maschine welche Revision bekommen hat, steht nun im Graphen statt in zwei Köpfen, die in Rente gehen werden.

Verwandte Lektüre

• Kundensupport mit 7-Stunden-Lösung: Wie ein Knowledge Graph die Ticket-Bearbeitungszeit um 75 % senkt — der Schwestern-Anwendungsfall aus der Softwareseite
• GraphRAG-Implementierungsleitfaden: Von Textdokumenten zur produktiven Knowledge-Graph-Retrieval — die Fünf-Phasen-Pipeline, die den Graphen auf Seitenebene aufbaut
• GraphRAG für Kundensupport: Wie ein Wissensgraph Fragen beantwortet, die Ihre Datenbank nicht kann — wann strukturiertes Retrieval seine Kosten wert ist

---

Ein Pumpenhersteller mit 12.000 Dokumenten, 70% davon Scans, verliert 22 Minuten auf jede Dokumentsuche und versendet gelegentlich das falsche Teil, weil kein System eine Pumpenkurve lesen kann. Ein Wissensgraph auf Seitenebene, Embeddings, die gerenderte Seiten ohne OCR durchsuchen, und ein Agent, der mit der exakten Seite im Anhang antwortet — begrenzt durch kein-Seitenzitat-kein-Versand — machen die Bibliothek wieder antwortfähig, und die RFQ-Engine macht aus „welches Teil passt" ein mit Preis hinterlegtes, reserviertes Angebot.

Fordere einen fest umrissenen Build an

Entdeckung in einer Woche. Du bekommst ein Systeminventar, eine Workflow-Karte und einen festen Scope — ob du mit uns baust oder nicht.