Beyond Manual RFQ Data Extraction: Practical Alternatives (and Why Generic LLMs Still Fall Short on Technical Drawings)

· Written by Jochen Mattes

Available in:

RFQ workflows still break in the same place: someone opens a technical drawing, squints at callouts, guesses the units, interprets shorthand, and manually types structured data into a quote sheet, ERP, or costing tool. It’s slow, inconsistent, and hard to scale—especially when drawings come from different suppliers, countries, and disciplines.

The good news: there are real alternatives to manual extraction. The bad news: many “AI” approaches fail for predictable reasons—especially when they rely on generic OCR and general-purpose LLMs.

This article outlines the main approaches you can use today, what they’re good at, where they break, and how to choose an extraction strategy that actually survives real-world drawings.

The alternatives to manual extraction (and their trade-offs)

1) Keep it manual, but standardize the process

What it is: Human extraction with checklists, templates, and training.

Why teams do it: It’s flexible and handles edge cases.

Where it breaks:

  • Doesn’t scale with RFQ volume
  • Expensive and hard to staff
  • Quality depends on individuals
  • No consistent traceability across reviewers

Manual work can be “optimized,” but it rarely becomes a competitive advantage.

2) Generic OCR + rules/regex + spreadsheets

What it is: Run OCR on the PDF/TIFF, then parse the resulting text with rules (regex, keyword dictionaries, heuristics).

Where it works:

  • Clean title blocks
  • Consistent fonts/orientation
  • Narrow drawing families with strict conventions

Where it breaks in production:

  • Rotation and orientation issues: rotated notes, angled callouts, mirrored scans, mixed orientations across viewports
  • Symbols and engineering notation: diameter symbols, surface finish, GD&T frames, stacked tolerances
  • Brittleness: one supplier changes layout, and your rule set collapses
  • Ambiguity: rules struggle to “decide” meaning when the same token can mean different things

This approach can deliver quick wins, but it tends to become a growing pile of exceptions.

3) CAD/PLM-driven extraction (BOM, PMI, model-based definition)

What it is: Avoid drawings and extract from native CAD, PMI, BOMs, and structured PLM objects.

Where it works:

  • Internal manufacturing with modern CAD governance
  • Closed-loop engineering environments
  • Organizations that actually have the authoritative source files

Where it breaks:

  • RFQs often come as PDF/TIFF only
  • Suppliers and customers don’t share native CAD consistently
  • Legacy drawings and scanned archives won’t be covered
  • MBD adoption is uneven across industries

If you can move upstream to structured CAD/PLM—great. But most RFQ reality still runs on drawings.

4) Multimodal LLMs for drawing extraction

What it is: Feed the drawing image/PDF to a vision-capable LLM and ask for structured output.

Why it looks attractive:

  • Minimal setup
  • Handles many formats
  • “Understands” context better than pure regex—sometimes

The two big problems (in practice):

Problem A: OCR is still the bottleneck (especially with rotation)

Most LLM-based extraction pipelines still depend on OCR under the hood. In real drawings, you have:

  • rotated annotations (90° title blocks, angled notes, rotated view labels)
  • mixed orientations on the same sheet
  • stamps, scan skew, faint text, low DPI
  • cramped callouts near geometry

When OCR misses or corrupts the text, the LLM can’t recover reliably. You end up with silent omissions (“it didn’t extract half the title block”) or confident but wrong guesses.

Problem B: Domain ambiguity is not a “language problem”—it’s a context problem

Technical drawing shorthand isn’t universal. The same token can mean different things depending on domain, region, and drawing conventions.

Examples:

  • “C45”: commonly interpreted as a steel grade by many engineers, but in other contexts it can denote a chamfer (length + angle), depending on notation style and local practice.
  • “SM2”: in an optical/mechanical optics context it can denote a thread standard (e.g., SM-series lens tube threads). In other contexts (and in some regional shorthand) the same pattern can be interpreted as a chamfer definition (length, angle).
  • Surface roughness (Ra) and units: US vs EU drawings can present roughness expectations differently, and title blocks often don’t make units explicit. If the drawing doesn’t clearly define units, your system must infer or at least flag ambiguity.

Generic LLMs tend to “solve everything at once,” but without deep, explicit domain models they can’t consistently remove the drawer’s freedom (the creative shorthand and local conventions) and turn it into deterministic, auditable structure.

What a production-grade approach looks like: extraction + normalization + interpretation

If you want RFQ extraction to work at scale, you typically need a pipeline that does three things well:

  1. Read the drawing reliably Robust OCR and symbol handling across rotations, scan artifacts, and multi-orientation sheets.

  2. Normalize the drawer’s freedom Map many notations into one canonical representation (the same way humans do, but consistently).

  3. Interpret in context Decide what a token means based on the drawing’s domain, origin, standards, and surrounding cues—and flag when the system cannot be sure.

This is exactly where domain-specific systems outperform general-purpose LLM approaches.

How Werk24 positions differently from “LLM-only extraction”

Werk24 has been focused on technical drawing understanding for years, specifically to remove the two biggest failure modes above.

1) Rotation is not a special case

Werk24’s extraction pipeline is built to handle rotation and mixed-orientation content as a first-class requirement. Rotated text, angled callouts, and common scan realities are treated as normal input—not exceptions.

Result: you don’t lose half the title block because it’s rotated, and you don’t need a “perfect PDF” policy to get consistent output.

2) Domain knowledge is built into the interpretation layer

Werk24 is designed to de-ambiguate drawing notation by applying domain-aware context—because the same string can legitimately mean different things.

In practice this includes:

  • recognizing whether a drawing is optical vs mechanical (and which conventions follow)
  • interpreting shorthand differently based on that classification
  • handling regional conventions (e.g., US vs EU habits, standards influence)
  • inferring or flagging missing units (instead of silently guessing)
  • producing structured outputs that remain consistent across suppliers

The goal is not merely “extract text,” but to deliver usable RFQ data: dimensions, tolerances, materials, surface requirements, threads, and metadata—interpreted the way an experienced reviewer would interpret them, but with repeatability and traceability.

A pragmatic checklist for choosing an extraction approach

When evaluating alternatives (OCR+rules, LLMs, domain platforms), ask these questions:

  • Rotation & orientation: Does it handle rotated/mixed text reliably, or do you need “clean PDFs”?
  • Symbol & notation support: Diameter, GD&T frames, stacked tolerances, surface finish, threads—handled natively?
  • Ambiguity handling: Does it decide and explain, or silently guess?
  • Context classification: Does it recognize drawing domain and standards influence (ISO/ASME, optical/mechanical)?
  • Units & missing title block info: Does it infer/flag missing units and regional differences?
  • Auditability: Can you trace extracted fields back to drawing regions and confidence?
  • Human-in-the-loop: Can reviewers verify/override efficiently when needed?
  • Integration: API-first? Export formats? Fits into RFQ/costing/ERP workflows?
  • Consistency at scale: Does performance degrade when suppliers vary?

Where LLMs still help (when used correctly)

LLMs can be valuable around the edges:

  • summarizing RFQ packages
  • drafting supplier questions (“please confirm surface finish units”)
  • matching similar historical parts after you have trustworthy structured data
  • translating notes (with careful validation)

But the core extraction step—especially from messy drawings—needs reliability, normalization, and domain interpretation. That’s not where generic LLMs shine today.

Bottom line

If your RFQ process depends on technical drawings, the biggest unlock is not “AI that can read images.” It’s a system that can:

  • read drawings robustly (including rotation),
  • remove notation variability,
  • and interpret meaning in context—consistently.

That combination is what turns drawings into structured RFQ inputs you can trust, automate, and scale. Werk24 is built specifically for that.