CASE STUDY · 02 / 03

An AI agent system built to understand complex technical engineering drawings in depth — combining LLM/VLM reasoning with specialized detection and segmentation tools that ground the agent in the drawing's structure and details.

Role
AI Engineer
Team
10 members
Domain
Technical / engineering drawings
Model
RT-DETR, ResNet-101 backbone
DrawMind reading and classifying View, Note, and Table regions on a technical engineering drawing

01The problem

The task: build a system that automatically detects and classifies elements on technical drawings into three types — View, Note, and Table — so downstream tooling can understand a drawing's layout without a human marking it up by hand.

Two things made this genuinely hard. First, View, Note, and Table regions often look alike — dense text, thin lines, repeated symbols on a plain white background — so the model wasn't just missing objects, it was confusing one class for another. Second, the client's quality bar was strict on top of that: high mAP, and a near-zero false-negative rate. A missed detection was much more costly to them than a false alarm, which shaped every decision downstream.

A real technical engineering drawing — multiple views, a detail callout, section cuts, and a parts table

02Domain gap: a real-world model, meeting a line drawing

RT-DETR-ResNet101 was pretrained on normal photos — people, cars, everyday objects. Its low-level features and initialization were still useful, but the higher-level representations didn't transfer cleanly to a technical drawing's mostly thin black lines, small text, and repeated symbols on a plain white background. Our initial fine-tuning baseline converged, but recall — especially on small and visually ambiguous regions — stayed below the client's acceptance threshold.

Part of that gap wasn't really about pretraining at all: these drawings are high-resolution, and resizing a full sheet down to the model's input size can erase the very thing that makes a Note a Note — small text shrinks to a handful of illegible pixels, thin lines vanish, and a large Table can end up looking like a small Note block. Tiling and higher-resolution inference mattered here as much as the domain gap itself.

More diverse, accurately labeled training data — especially hard examples and underrepresented layouts — would likely have improved generalization further, but the client could only provide a limited amount, and we had a limited GPU budget too, so scaling up to a much bigger model wasn't an option either. That left three constraints at once: data that didn't cover every case, limited VRAM/compute, and pretrained representations that weren't a great fit for the domain to begin with.

A collage of everyday natural photos — people, cars, a dog, furniture, food, landscapes

What the model already knew

Natural photos — continuous color, texture, lighting, real-world object shapes. Millions of pretraining examples, none of them a line drawing.

A collage of technical engineering drawings — thin black lines, small text, and repeated symbols on a plain white background

What it actually had to read

Sparse black-and-white geometry, dense repeated symbols, and three classes whose visual patterns partially overlap — telling them apart reliably takes both local structure and surrounding layout context.

03The approach: work around the constraints, not against them

Instead of chasing "more data, bigger model," the team looked closely at exactly which errors kept showing up, grouped them by cause, and fixed each group directly.

Error-cause analysis
Grouped failures by root cause — genuinely ambiguous cases (needs more data), cases the model couldn't fit given VRAM limits, cases exposing the pretrained backbone's weak domain fit, and misclassifications that count against both classes at once (a Table read as a Note is a false negative for Table and a false positive for Note).
Training strategy & data allocation
Prioritized labeling and training budget toward the error groups that mattered most for the near-zero-FN requirement, rather than spreading effort evenly.
Targeted image processing
Pre-processing tuned for the failure modes the error analysis surfaced — tiling and higher-resolution crops so small text and thin lines survive resizing, not just cues to separate View/Note/Table boundaries.
Post-processing
Per-class confidence thresholds tuned around the recall the client needed, plus a custom stage that catches near-miss detections — the main lever for pushing false negatives down without a data or compute budget to match.
Object DetectionRT-DETRResNet-101Domain AdaptationCVATError AnalysisPost-processing

04System in action

Automatic detection and pixel-level segmentation of every View, Note, and Table region on a drawing — accurate and reliable end-to-end, driven by RT-DETR together with the targeted image-processing and classification strategy from the section above.

automatic detection & segmentation, running live on a real drawing

An AI agent that reads a drawing deeply enough to answer questions about it — an LLM and a VLM behind an orchestration layer that calls the right tool for the job, including custom tools built specifically for this workflow.

an AI agent reading a drawing closely enough to answer questions about it

05Impact

Detecting and segmenting a complex drawing by hand took an engineer around 30 minutes; the same task now takes under 15 seconds.
mAP above 0.95, well ahead of the ~0.7 typical of general-purpose detection systems on this kind of drawing.
The AI agent lets engineers pull information out of a drawing conversationally, instead of hunting through it by hand.