Engineering Copilots and PLM: On-Prem GPU Planning for Design Data

Overview

Every engineering organisation has the same complaint: the answer exists somewhere in thirty years of drawings, change records, test reports and tribal knowledge, and finding it takes a senior engineer a day. Copilots over product lifecycle management data address this, but they are harder than a text RAG deployment for three reasons — the source material is largely non-prose, the relationships between records carry as much meaning as the records themselves, and the data is among the most commercially sensitive an industrial firm holds. This article covers the architecture and what it requires in GPU terms.

Why engineering data resists ordinary RAG

A standard retrieval pipeline splits documents into text chunks, embeds them, and retrieves by semantic similarity. Applied to engineering archives this fails quickly. A mechanical drawing carries its information in geometry, dimensions, tolerances and title-block metadata, none of which survive naive text extraction. A bill of materials is a hierarchical structure whose meaning is destroyed by flattening. A test report’s conclusion depends on which revision of which part it tested.

The result of ignoring this is a system that answers confidently from the wrong revision or misreads a tolerance, which in an engineering context is worse than no system at all. The correction is to treat extraction as a first-class engineering problem: vision-language models to read drawings including title blocks and annotations, structured parsing for BOMs and PLM records, and explicit capture of the identifiers that link them.

Structure beats similarity

The second design change is to stop relying on vector similarity alone. Engineering questions are usually relational: what changed between revision C and D, which assemblies use this fastener, what test evidence supports this tolerance. Those are graph traversals, not nearest-neighbour searches, and a system built only on embeddings will approximate them badly.

The productive architecture is hybrid. A graph layer captures the PLM structure that already exists — parts, revisions, assemblies, change orders, documents — and vector retrieval handles the unstructured content attached to each node. A query first narrows by structure, then searches semantically within that narrowed set. This mirrors the tiering described in adaptive RAG, and in engineering it is not an optimisation but a correctness requirement.

Revision correctness as a hard constraint

Engineering answers have a validity scope: this tolerance applies to this revision of this part for this customer programme. A copilot that returns a correct-sounding answer from a superseded document creates real risk, and unlike a marketing chatbot the consequences reach manufacturing.

Three controls address it. Store revision and effectivity as first-class metadata and filter on it before retrieval rather than hoping the model notices. Require every answer to cite the specific document, revision and date, so the engineer can verify at a glance. And explicitly mark superseded content as such in the index rather than deleting it, since historical questions are legitimate but must be flagged. Without these, adoption collapses the first time a senior engineer catches an answer from an obsolete drawing.

Sizing the GPU tier

The shape here is unusual and worth planning around. Serving a few hundred engineers is a modest inference load — queries are infrequent per user and answers are short. Ingesting a thirty-year drawing archive through a vision-language model is a large batch job. Sizing owned hardware for the ingestion peak wastes capital; the sensible pattern is modest owned serving capacity plus a burst arrangement for ingestion campaigns.

Why this stays on-premises

Design data is the most valuable intellectual property an engineering firm holds, and much of it is not even its own — automotive and aerospace suppliers typically hold customer drawings under contractual restrictions that prohibit disclosure to third parties, including cloud processors, without explicit consent. Those obligations predate and are stricter than any general data protection requirement.

That makes the placement question straightforward: extraction, index and serving all sit inside the firm’s own boundary. It also has a practical benefit, since engineering archives are large and moving terabytes of CAD and scanned drawings to a processor and back is slow and expensive. The one legitimate exception is the ingestion burst, and even there the customer-data restriction usually rules out external processing, which argues for owned or rented in-country capacity rather than a general cloud service. The confidentiality and control patterns generalise from shop-floor copilots for maintenance knowledge.

Sequencing a deployment

Start narrow and structured. Pick one product family and one question type — for example, change history and current effectivity for a single assembly — and build it end to end including citations. This exposes the extraction quality problem immediately, on a scope small enough to fix, and produces something engineers can evaluate honestly.

Expand along two axes afterwards: more document types (test reports, supplier certificates, standards) and more question types (where-used, alternative parts, tolerance rationale). Resist expanding both at once. And measure adoption by whether senior engineers use it unprompted, not by query counts — a system with high query volume and low trust is being tested, not used. The retrieval sizing method is in right-sizing a GPU server for enterprise RAG, and the wider industrial context in AI infrastructure for manufacturing.

Frequently asked questions