AI for technical documentation: from PDF piles to answerable questions

AI for technical documentation means something quite specific in practice: preparing manuals, datasheets, test records and maintenance reports so that a system answers a concrete question from maintenance with document, revision and page - or states plainly that it found no evidence. Whether that succeeds is decided long before the language model runs: in the inventory of what you actually hold, in the parsing of the PDFs, and in how the text is cut into passages. This article describes exactly that preparatory stage, the one product descriptions tend to skip.

What does "AI for technical documentation" actually mean?

The term covers three technically distinct levels that vendor offers tend to blur. The first is full-text search: every document is captured as text and indexed, and what is found are exact words and word stems. The second is semantic search: passages are stored as vectors, and what comes back is whatever lies close to the question in meaning, even without a matching word. The third is the generated answer with evidence, usually called Retrieval Augmented Generation (RAG): a language model composes an answer from the retrieved passages and points to where they came from.

In practice many plants want to jump straight to the third level, although the second often solves the real problem: making manuals searchable so that a maintenance technician finds the right page in the right document. A search that returns hits with context and a page number is signed off faster, is easier to audit and costs less to run. The generated answer earns its place when questions regularly combine several documents, or when users ask in everyday language that differs from the manufacturer's terminology.

Embedding

A numeric vector that represents the meaning of a passage of text. Similar content sits close together in the vector space, even when it uses different words.

Chunk

The passage of text that is indexed as the smallest unit and later retrieved. Its boundaries decide whether a piece of information arrives complete or cut in half.

Retrieval

The search for the chunks that best match a question, usually by vector distance. The retriever supplies candidates, not an answer.

Reranking

A second, more precise scoring pass that reorders the candidates. It filters out hits that only match on the surface.

Which document classes can realistically be opened up today?

Documents that were produced digitally and have a linear flow of text are the easiest to open up; those whose information sits in graphics, symbols or handwriting are the hardest. Most of a document base that has grown over decades lies somewhere in between. Sorting by document class is therefore the first step of any AI document analysis in industry, before a single tool is chosen. If you want to evaluate technical documentation with AI, work through Tab. 02 against your own holdings (OCR: optical character recognition, P&ID: piping and instrumentation diagram, CMMS: computerised maintenance management system).

Two classes deserve an extra note. Anyone who wants to read datasheets automatically does not need a question-answering system but clean table extraction: the characteristic value belongs in a field together with its unit, test condition and footnote, not in a running-text chunk. And anyone who wants to research standards with AI hits a non-technical obstacle: standards are copyrighted and licensed. Whether your licence covers full-text indexing in an internal system is something to settle with the licensor before the import; until then, metadata, tables of contents and your own implementation documents are the safe route.

With maintenance reports the value lies less in the individual entry than in the pattern across years - the same fault, the same component, the same shift. Preparing fault histories for that is a task of its own: normalising abbreviations, resolving mixed languages and attaching every entry to an asset before any model sees it.

Where parsing breaks down - and how to notice beforehand

Parsing rarely fails on the text and almost always on the layout. A PDF does not store paragraphs, tables or headings; it stores positioned characters. Everything a human reads as structure has to be reconstructed by a parser - and that is precisely where the errors arise that later surface in every answer. The most common patterns in technical documentation:

• —Multi-column layouts whose columns are read into each other line by line
• —Tables without ruling lines, where column assignment and units are lost
• —Footnotes and marginal notes that appear in the middle of the running text
• —Dimensions, tolerances and warning symbols embedded as graphics with no text layer
• —Headers and footers carrying document number and revision status, which migrate into every chunk and dilute the search
• —Tables that span a page break and arrive as two tables, the second without a header row

Text extraction and layout recognition are two different jobs. Extraction reads out characters; layout recognition decides which characters belong to which block, in what order the blocks are to be read, and whether a block is a table, a heading or a caption. Tools that only extract produce usable results on a single-column operating manual and gibberish on a datasheet.

There is a public yardstick for this. OmniDocBench, presented at CVPR 2025, covered 981 PDF pages from nine document types in the paper; the current release of the dataset (v1.6) contains 1,651 pages from ten types. Scoring is separate for each aspect: text via normalised edit distance, table structure via TEDS (tree-edit-distance-based similarity), formulas via CDM (character detection matching), and reading order again via edit distance. Page attributes such as blurred scan, watermark, coloured background and number of columns are annotated individually.

The authors report a marked loss of accuracy on multi-column and complex layouts, and on blurred scans, watermarks and coloured backgrounds; one of the pipelines tested recognised handwritten notes entirely as a figure. For you that means two things: you can look up how a method performs on pages resembling your own, and you can ask a vendor for a TEDS figure for tables instead of accepting a demo on their own sample documents.

Chunking: the underrated step

Chunking determines which unit of text the system later retrieves and puts in front of the language model - and therefore whether an answer can be complete at all. The simplest approach is equally sized sections with a fixed character count - and for technical documentation it is often the worst choice. Such cuts separate a warning from the instruction it belongs to, a reference to a standard from the requirement it qualifies, and table rows from their header.

Structure-based chunking follows the document instead: a section ends where the next heading of the same or a higher level begins. Tables stay together as a unit and carry their header into every part if they have to be split. Warnings stay attached to the work step they belong to. The guidance issued by the Datenschutzkonferenz (the conference of German federal and state data protection authorities) on RAG systems names the inherent weakness: information that belongs together logically but is not semantically close enough may end up in different chunks. Good chunking is the attempt to prevent exactly that.

The metadata each chunk carries matters just as much. Without it the system can neither filter by machine type nor quote a page number later on. The minimum set:

• —Document ID and title
• —Revision status and date of issue
• —Chapter path, for example "7 > 7.3 > 7.3.2 Fitting the bearing cap"
• —Page number or page range
• —Machine type, series and serial number range
• —Language of the edition
• —Document class (manual, datasheet, test record, report)
• —Validity status (valid, superseded, withdrawn)

{
  "chunk_id": "OM-4711-C_007-003-002",
  "document_id": "OM-4711",
  "title": "Operating manual, rotary transfer machine RT-200",
  "revision": "C",
  "issued": "2024-03-15",
  "status": "valid",
  "language": "en",
  "doc_class": "operating_manual",
  "chapter_path": ["7 Maintenance", "7.3 Spindle unit", "7.3.2 Fitting the bearing cap"],
  "pages": [112, 113],
  "machine_type": "RT-200",
  "serial_range": "RT200-2019-0001..RT200-2023-0450",
  "text": "WARNING - Before starting work, switch off the main disconnect and secure it against being switched back on. ..."
}

Revisions, multiple languages and validity

In a plant that has grown over time, the same manual typically exists in several revisions, and only one of them applies to the machine that is currently down. An answering system that does not know which revision is valid will mix tightening torques from revision B with safety distances from revision D - in an answer that reads fluently and sounds plausible. In maintenance that is not a minor imprecision; it is a safety risk.

Three cases have to be settled before the import. First, the revision reference: which document version applies to which serial number range, and who maintains that mapping? Second, the language editions: German and English editions of the same document are not always identical in content; chapters are missing or were added later. The system should know which edition is the reference. Third, the status: withdrawn documents may be findable, but only with a marker, and never as the basis of an answer without that marker.

You do not have to invent this metadata model. With iiRDS, the Intelligent Information Request and Delivery Standard, tekom (the German professional association for technical communication) maintains an open standard that defines metadata for information requests and a package format for delivering technical information. Version 1.3 was released in November 2025; the specification and the RDF schemas are published under a Creative Commons licence. Even if your suppliers do not yet deliver in iiRDS, the vocabulary works as a template for your own chunk metadata - and as a delivery format you can require in the requirements specification for new machines.

Citation and refusal to answer as acceptance criteria

In technical documentation an answer without document, revision and page is worthless, because nobody can verify it. Citation is not a convenience; it is what turns an answer into information solid enough for someone to take responsibility for. The second half of the same criterion is refusal: if retrieval finds no sufficient evidence, the system has to say so rather than answer from the language model's prior knowledge. The Datenschutzkonferenz describes the target state of a RAG system in its guidance as follows:

The same guidance notes in a footnote that this ideal is not always reached technically and that the model's prior knowledge can find its way into the output unintentionally. The BSI (the German Federal Office for Information Security) explains in its publication on generative AI models why that is critical: hallucinations look credible, particularly when references are cited that may themselves be fabricated. The BSI therefore recommends that companies carry out an individual risk analysis before integrating such a system.

For document analysis that means, concretely: mandatory evidence per statement, a quality threshold below which no answer is given, a log of question, chunks used and answer - and access rights inherited from the source system, so that nobody reaches a document through a question that they are not allowed to open. In an assistant built on those documents, each of those four is a component you can point at: a retrieval step, a threshold, a log and a permission filter.

Where the technology still fails today

There are document classes for which even good tools deliver no reliable results today - and it is better to know that before the project than after it. The following cases do not belong in the index of a first pilot; they belong on a list for later:

• —Circuit diagrams and P&ID flow diagrams: the information sits in symbols and connections, not in text
• —Handwritten notes on test records and drawings
• —Tables spanning several pages with repeated or missing header rows
• —Badly scanned legacy holdings: skewed, blurred, covered in stamps and watermarks
• —Symbols without a legend, whose meaning exists only in operational knowledge
• —Dimension chains, tolerances and surface specifications in manufacturing drawings

How far research has come with drawings is shown by a project at the Fraunhofer IPA on automatically recognising manufacturing-relevant information in 2D drawings. Dimensions, tolerances and additional specifications such as a heat treatment are read out by OCR, and symbols are detected with a YOLO network. The institute itself states a recognition rate of around 70 percent. That figure is a third-party statement by Fraunhofer IPA from a research context, not an operational value - and it means that roughly three in ten specifications have to be checked by a human. For finding the right drawing that is enough; as an automatic source of manufacturing parameters it is not.

On technical drawings the limits are sharper still: OCR reads title blocks and tables reliably, but dimension chains, tolerances and hand-written amendments need a manual release step that no confidence score replaces.

The order in which to proceed

The order matters more than the tool. Anyone who starts with tool selection ends up judging offers against the vendor's demo documents instead of their own holdings. These six steps turn that around: understand the base and define success first, then build.

1. 01

   Document inventory

   Record what exists: document class, quantity, format, storage location, owner, revision status, language. Not exhaustively, but representatively - the checklist below walks through the points to cover.

2. 02

   Quality sample

   Send 20 typical pages from across the classes through the intended parsing and count the errors. Result: which classes go into the pilot and which ones wait.

3. 03

   Collect the real questions

   For two weeks, maintenance, shift management and work scheduling note down every question that made them look something up in a document. That is the real requirement.

4. 04

   Build a test question catalogue

   Turn those into 30 to 50 questions with the expected source (document, revision, page) and the expected answer. At least five of them with no evidence in the document base - they test the refusal.

5. 05

   Pilot on one machine type

   Pick one machine type with complete, current documentation. Not the hardest case, but the one where the chain from PDF to cited answer can be measured cleanly end to end.

6. 06

   Acceptance against the catalogue

   Every test question is scored: correct source, correct answer, refusal where refusal belongs. Only when the pass rate holds up do further document classes and machine types follow.

One decision belongs at the start, not at the end: where does the system run? Supplier contracts, test records containing personal names and drawings containing manufacturing know-how are not data you send casually to a service outside the EU. EU hosting or self-hosting is an architectural decision that determines model choice, hardware and running costs. What self-hosting means in practice is set out in LLM on premise in an industrial plant; which technical requirements the data protection authorities place on RAG systems is covered in RAG on your own documents and the DSK guidance.

Conclusion: document work before model work

AI for technical documentation is mostly document work and only at the very end model work. If you inventory the base, measure parsing on your own pages, chunk along the document structure and carry validity as a metadata field, you get a system whose answers can be checked. Skip that preparatory stage and you get a fluent interface on top of an unsorted pile.

The next step is a small one: an inventory using the checklist above, a 20-page sample and 30 test questions with their expected source. That is enough to judge any offer and any pilot against your own document base. If you would like to talk this starting point through with someone who builds the chain from PDF to cited answer, you will find where ralwo fits under AI solutions for technical documents.