Scanned Manuals and Photo Tickets: How a Knowledge Graph Ends the 22-Minute Support Search

Key takeaways

• 70% of a 12,000-document support library has no text layer — for a 460-employee pump manufacturer, roughly 126,000 pages are invisible to keyword search and to a text-only vector index alike.
• Perplexity's pplx-embed-v2-late reached 92.4% answer accuracy on MADQA — an agent answered 500 questions over 800 real-world PDFs spanning 18,000+ pages by searching rendered pages directly, with no OCR pipeline, released October 7, 2026.
• The 0.6B query encoder can query an index built with the 9B model — the shared embedding space pairs expensive offline page indexing with cheap live queries, and the 0.6B model is 594M parameters under an MIT license.
• LinkedIn's GraphRAG production deployment improved retrieval accuracy by 77.6% — the structural edges of a knowledge graph are what a vector index cannot see.
• A page-citation rule changes the failure mode — no answer leaves the agent without its document page, part number, and serial range; anything unverifiable escalates to a human instead of shipping to a customer.

Three hundred of the 950 tickets a mid-market pump and waterworks manufacturer receives each week are not product complaints. They are document questions: which impeller fits a 1998 SP-200 built on serial 43-11092, which service bulletin supersedes the torque table in the O&M manual, which gasket compound the 2014 revision calls for — each arriving with a photo of a nameplate or a scan of a manual page attached. The technical library behind those questions holds 12,000 documents and roughly 180,000 pages. About 70% of it is scanned paper with no text layer, dating back to the 1970s, and Zendesk's search index reads none of it.

The cost shows up in two queues. In-house, six technical support staff average a 22-minute manual hunt per document question — opening PDF after PDF, matching a phone photo against a pump curve by eye. Outbound, dealers and distributors email the support inbox and wait a median of 14 hours for a reply. Two senior technicians field 55% of escalated document questions, absorbing roughly 19 hours a week of other people's hunts. And the worst failure is not the slow one: a misread schematic ships the wrong cartridge, costs a restock cycle plus a second-visit callback, and cost this company about $38K last year in freight and restock handling.

This article maps the three-layer fix — a page-level knowledge graph over the document library, late-interaction embeddings that search rendered PDF pages directly with no OCR step, and an agent flow that answers with the exact page attached — each layer anchored to its primary source: Perplexity's October 7, 2026 release and LinkedIn's GraphRAG production deployment.

The problem: the library everyone stopped searching

Every manufacturer with a paper past has this library. The manuals from the last five years were born digital. Everything older arrived by scanner: pump curves, wiring schematics, exploded parts drawings, dimension tables. Some pages have legible text; many are degraded scans with punch holes, fold lines, and handwriting in the margins. The searchable 30% is the easy part; the other 70% is a wall of images labeled only by file name, which is why keyword search and a text-only vector index fail the same way: both need text that does not exist.

The obvious fix — "just OCR the archive" — died the usual death. OCR errors compound on degraded scans and land where the business value is: pump-curve axes become stray characters, dimension tables misalign, parts-list columns merge. That is the parse-then-search pipeline the Perplexity team calls "expensive and lossy" — it discards "layout, table structure, figures, and spatial relationships" before retrieval ever sees the page. An OCR rebuild of this library was quoted at six figures and was not funded a second time.

A vector-search pilot failed for a different reason: embedded text returned the right shape of pump curve for the wrong revision, a gasket spec for a manual the customer's machine does not match. Nothing in a vector index knows that one impeller supersedes another or that a torque table was withdrawn for a serial range — plausible results, confidently wrong, exactly the answer that ships the wrong part. The assistant was shelved; the two senior technicians stayed the system of record. The site's earlier support-knowledge-graph article shows the same failure mode on software documentation; on scanned hardware libraries it picks the wrong page instead of the wrong workaround.

The agent-orchestrated solution: a graph under the pages, embeddings on the pages

The working pattern keeps each layer doing only what it is good at.

Layer 1 — a page-level knowledge graph. Every document becomes a node; every page inside it is a node too, with its rendered image stored once. Parts, pump models, serial ranges, and revisions are nodes, and the edges are the facts that answer questions: manual 4412 documents model SP-200; page 118 contains the impeller table; impeller 88-114 supersedes 88-114A for serials above 43-0850; bulletin 91-07 withdraws the torque table on page 40; and — pulled from NetSuite order history — serial 43-11092 shipped to a specific dealer in 1998 and its owner holds a service agreement. Nothing here requires the pages to be text. The graph is built from catalogs, order records, and revision cards the company already maintains.

Layer 2 — page-level embeddings on the rendered pages. The scanned 70% never needs OCR: Perplexity's pplx-embed-v2-late family, released October 7, 2026, "handle[s] text-to-image retrieval, allowing them to directly search rendered PDF pages without requiring OCR or parsed text." Both sizes — 0.6B and 9B, MIT-licensed on Hugging Face — produce one 128-dimensional vector per token and score with ColBERT-style MaxSim, which preserves the detail a pump question needs: "impeller," "SP-200," and a drawn shaft diameter match different regions of the same rendered page. On MADQA — 800 heterogeneous real-world PDFs, 18,000+ pages, 500 questions written so they cannot be answered from general knowledge — the 9B model answers 92.4% correctly and the 0.6B model 90.1%; on the ViDoRe(v3) visual-document benchmark, the 0.6B model matches models with five times its active parameters. Because both models share one embedding space, the library is indexed once with the 9B model while live ticket queries run through the 0.6B encoder — which can run fully on hardware the manufacturer controls, a detail that matters when manuals carry customer-site confidentiality.

Layer 3 — the agent flow that ends in a citation, not a paragraph. Connector modules speaking Model Context Protocol (MCP) wrap Zendesk (ticket, requester, attachments), NetSuite (orders, serial history, warranty status), and the graph query tool. The flow: the agent reads the ticket and its photo attachment, queries the embeddings for candidate rendered pages, then walks the graph to confirm what the candidate page claims — the right revision, the right serial range, the right supersession state — and answers with the actual PDF page attached, the part number in text, and the authority stated ("per bulletin 91-07, page-table on page 40"). The governance rule is one line and it is load-bearing: no page citation, no send — the ticket escalates to a human instead. A yes-buy question hands off to an RFQ engine that holds live availability on the replacement part, closing the resolution with a priced quote; dealer-facing requests delegate through a scoped A2A agent, and every retrieval and graph step logs under the module code standard pattern. The implementation guide covers building the graph itself; this is the operating pattern, not a guarantee for every archive.

The two senior technicians stay in the loop at a different altitude: they approve anything safety-relevant, review the flagged low-confidence queue, and handle what the graph cannot ground. They no longer serve as the library's index.

The outcome

The same ticket, two ways to resolve it — today's manual hunt against the agent-orchestrated flow that answers with the exact page attached:

Representative targets for a deployment of this shape at this company's volume, with the benchmark evidence the pattern rests on:

Metric	Before	Agent-orchestrated target
First response on document questions	14 hours (dealer email median)	Under 2 minutes, page cite + render attached
Median in-house handling time	22 minutes manual hunt	3 minutes — tech verifies the attached page
Escalation load on senior techs	55% of doc questions (~19 hrs/week)	Under 20% of doc questions
Wrong-part shipments	9 in the quarter ($38K/year)	1 in the pilot quarter
Pages searchable	54,000 (the text-layer 30%)	~180,000, rendered pages as-is

The evidence behind the pattern: agentic QA on real-world scanned PDFs at 92.4% accuracy without an OCR pipeline, graph-structured retrieval worth 77.6% measured retrieval-accuracy improvement at LinkedIn, and a profile the support knowledge-graph deployment demonstrated from the software side (28-hour resolution to 7; escalation 45% to 18%). Honest scope marker: MADQA is a benchmark, not a promise for every archive — which is why the citation rule and human review stay in the loop.

The deeper change is that the library stops decaying: which document supersedes which, which part substitutes for which, and which machine got which revision is now recorded in the graph instead of in two heads that will retire.

Related reading

• Customer Support at 7-Hour Resolution: How a Knowledge Graph Cuts Ticket Time by 75% — the sibling use case from the software side
• GraphRAG Implementation Guide: From Text Documents to Production Knowledge Graph Retrieval — the five-stage pipeline that builds the page-level graph
• GraphRAG for Customer Support: How a Knowledge Graph Answers Questions Your Database Cannot — when structured retrieval is worth its cost

---

A pump manufacturer with 12,000 documents, 70% of them scans, loses 22 minutes to every document hunt and ships the occasional wrong part because no system can read a pump curve. A page-level knowledge graph, embeddings that search rendered pages without OCR, and an agent that answers with the exact page attached — gated by no-citation-no-send — make the library answerable again, and the RFQ engine turns "which part fits" into a priced, held quote.

Request a scoped build.

One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.