4.3 Design-reuse retrieval¶

This page is part of the study AI for DFM Engineering. It is one of the two buildable projects: a design-services vendor building an offline design-reuse retrieval system over its own CATIA part library.

The first proposal answers one everyday question: have we designed a part like this before? A designer points at a part (or describes it) and receives, in seconds, the closest past designs from the firm's own library, each with its metadata and its linked records attached. Behind it sits a pretrained vision model that has learned to place similar shapes near each other, so the search needs no labels and no training on the firm's data. A later phase lets the same request be typed in plain language and have the matches explained. The tool finds and shows; a person still decides what to reuse.

4.3.1 The work it replaces¶

For the design-services vendor, reusing a past design today depends on who remembers it. There is no way to search the library by shape, so a designer who does not recall a similar past part simply starts again.

In short: with no shape search, finding a past design relies on memory, so good work is redesigned instead of reused.

The knowledge of what the firm has already built sits in senior engineers' memory. When they are busy or gone, the library is effectively invisible: thousands of solved problems that no one can find. A shape-based search turns that unused archive into something an engineer, or an estimator pricing a new enquiry, can actually query.

4.3.2 What retrieval covers, and where the AI is¶

Design-reuse retrieval answers one question (which past parts look most like this one?) and is careful about which part of it is actually AI. Three layers do the work, and only the first one learns:

Layer	Role	Learns from data?
Shape match (K)	rank past parts by geometric similarity	Yes: a pretrained vision model, the only AI in Phase 1
Metadata filter	narrow by material, customer, family, size	No: a plain database query
Language (L)	take a typed request, run the search, explain the matches	Yes: a local LLM, added in Phase 2

The key insight: the similarity itself is learned, but everything around it is an ordinary database. The vision model turns each part into a point in space so that similar shapes land close together. That is genuine deep learning, and it is Opportunity K, the Knowledge layer. It is also unsupervised: the model is already trained, needs no labels, and is never trained on the firm's parts. That is what makes retrieval the easy, immediate win, ahead of any predictive model, which does need labels and is deliberately deferred.

4.3.3 The proposal: a learned similarity model on a plain database¶

The exchange the opening described works because a learned similarity model sits on top of an ordinary database. The model provides one thing only: which shapes resemble which. The database does the rest.

In short: a learned model ranks by shape, a plain database narrows and fetches the rest, and in Phase 2 an LLM reads the request and explains the results.

K: Knowledge (retrieval) layer; L: Language layer; LLM: large language model; DB: database.

The division of labour is the core design principle, and it keeps the AI honest and small:

Component	Role	Intelligence?
Shape model	sees that two parts resemble each other	yes, but only similarity; it reads pictures, not meaning
Metadata DB	filters and fetches the records	none; an exact, testable database query
LLM (Phase 2)	turns a request into a search and explains the results	yes, but only language; it never judges geometry

This mirrors §4.4's design of a thinking part driving simple tools. Here the thinking part is the similarity model, and the tools are a plain database rather than geometry scripts. The two proposals are closely related builds on the same offline stack.

4.3.4 How it finds similar parts: render, embed, index¶

The system does not compare CAD files directly. It renders each part to a few screenshots, converts each screenshot to an embedding (a list of numbers that captures its shape), and stores those in a vector database. Two parts are "similar" when their embeddings are close.

In short: every part is turned into shape-numbers once and indexed; a query part is turned into the same numbers and matched against the index.

CATPart: CATIA's native part file; STEP: neutral CAD exchange format (ISO 10303).

Why rendered views, and not the more accurate 3D encoders? The open-source survey (§4.2) found the highest measured accuracy in encoders that read a point cloud or B-rep directly — but their weights are either not cleanly licensed for commercial use (point cloud) or always need a STEP conversion (B-rep). Rendered views trade a little shape fidelity for a cleanly licensed model (DINOv2, Apache-2.0), no training, and no conversion. That is why Phase 1 renders; the exact B-rep path, which brings the STEP conversion back, is held to the optional Phase 3.

Two points make the design precise:

The query part is embedded the same way as the library. To ask "parts like this," the tool renders and embeds the query part, then searches. An in-progress CATPart, or an existing library part, both work.
Metadata is stored beside each vector, not learned. Material, customer, family, dimensions and links to past records ride along as a payload. They power the filter and the returned context, but never the similarity math. The same per-customer metadata filter also enforces confidentiality separation between customers, exactly as in §4.4.

On dimensions, honestly. A screenshot loses scale: a small bracket and a large one that look alike embed to nearly the same point. There are two fixes. The cheap one, in Phase 1, stores simple geometric numbers (bounding-box size, volume) as metadata, so size becomes a filter. The exact one is a later, optional phase covered in the roadmap.

4.3.5 Development effort & buy-vs-build¶

Component	Decision	Effort / cost	Notes
View + metadata extraction	build	main Phase-1 effort: batch-export screenshots and read metadata from the CATPart library	done via CATIA, or from a one-time STEP conversion; the equivalent of §4.4's Tools 1–2
Vision embedding model	install (open-source)	small; run a pretrained encoder locally, no training³	DINOv2 (Apache-2.0), alternate OpenCLIP (MIT); cleanly licensed for commercial use¹²
Vector database	install (open-source)	small; index is GBs at most for a design-office library	FAISS / Qdrant / Chroma, all free and on-prem⁵
Metadata database + query tool	build	moderate; mostly data cleanup, the boring, mandatory part	a plain relational or document store of the in-house library facts
LLM + serving (Phase 2)	install (open-source)	infrastructure setup, days	Ollama / vLLM + open model; the same box §4.4 specifies
Agent loop + prompts (Phase 2)	build	small, days once the tools exist	the LLM drives the search and metadata tools; standard function-calling
B-rep similarity model (Phase 3, optional)	build + train	light R&D: train a B-rep encoder on the firm's own parts	UV-Net (MIT); adds exact, dimension-aware matching; see what this is not and the BOM

Team needed: one CAD-savvy engineer plus one ML/data engineer for a prototype. No model training in Phases 1–2; no labels anywhere.

4.3.6 Phased roadmap & where it sits¶

The build is staged so value ships early and the easy half is learned first, exactly as in §4.4:

In short: start with visual shape search, then add plain-language querying, then optionally add exact geometry-aware matching.

B-rep: boundary representation, the exact face-and-edge form of a CAD solid.

Phase 1 ships first and delivers value immediately: an engineer searches the library by shape instead of relying on memory. This is the K layer, and it needs no LLM. A useful by-product: the same search is not designer-only. During a request for quotation, estimation and sales can ask "have we made something like this customer's part, and what did it involve?" before quoting. Phase 1 is an early, visible win for the business, not just the design office.
Phase 2 adds the L layer: the same local LLM as §4.4 lets the request be typed in plain language and explains why each match is close. This is the true sibling of §4.4's agent, on the same hardware.
Phase 3 is optional and evidence-gated. It adds a B-rep encoder trained on the firm's own parts for exact, dimension-aware matching, used to re-rank the shape hits.⁴ It is adopted only if Phase 1 proves too coarse on real parts. It is the one light R&D step here: it re-imposes the CATPart→STEP conversion and needs self-supervised training (no labels), so it breaks the "no training" ease of Phases 1–2 and is held back deliberately.

This lowers the risk. Even if Phases 2 and 3 are never built, Phase 1 works on its own as a shape search: the ingestion and index still have value, so the geometry work is never wasted.

In the daily workflow the tool serves two audiences on demand:

In short: designers and estimators both ask the same shape search, and a person decides what to do with the matches.

RFQ: request for quotation.

It is augmented AI, not autonomous AI: the tool surfaces candidates; a qualified person decides what to reuse and owns the result. Start with the search, earn trust as the matches prove useful.

4.3.7 Expected outcomes & benefits¶

Benefit	Today (memory-based)	With retrieval
Finding a past design	depends on who remembers it	shape search, seconds, ranked
Reuse rate	low; parts redesigned from scratch	past work found and adapted
Knowledge risk	held by 2–3 senior engineers	captured in a searchable index; juniors query it
Estimation	feasibility guessed	RFQ grounded in similar past jobs
Consistency	varies by person	same library, same search, for everyone
Data control	n/a	fully offline: "your data never leaves our premises"

In summary: a unused archive becomes a searchable asset. Less rework, faster starts, and a knowledge base that outlives any individual engineer.

4.3.8 What this is not¶

The scope boundaries are deliberate, and holding them keeps the project buildable:

No rule-based DFM checks. Draft, wall thickness, ribs and undercuts are the §4.4 assistant's job. This project finds similar parts; it does not judge manufacturability.
No predictive ML. Warpage, fill and sink prediction need outcome labels the design office does not have; that work is deferred.
No B-rep model in Phases 1–2. The learned model reads images, not solids. A B-rep encoder (UV-Net class) is the optional Phase 3, named honestly as the one light-R&D step, not the default.
No design automation. The tool surfaces past designs; a person decides what to reuse.

In short: shape search and metadata filtering are in scope; DFM judgment and physics prediction are not.

In one line: the firm's unused CATPart library becomes a shape-searchable knowledge base: a pretrained vision model ranks past parts by similarity, a plain database filters and fetches their records, and a later language layer lets anyone ask in plain English, all fully offline, with no labels and a person deciding what to reuse.

Hardware & licensing. A spec-only bill of materials for this project (the vision encoder, the CATIA-or-STEP view-extraction pipeline, the vector and metadata databases, the Phase-2 LLM, and the optional Phase-3 B-rep encoder) is in Annexure B · BOM for Project 1.

DINOv2 (Meta AI Research) ships self-supervised image-embedding weights and code under Apache-2.0, cleanly usable commercially; used here to embed rendered views for retrieval. Licence: https://github.com/facebookresearch/dinov2/blob/main/LICENSE (accessed Aug 2026). See also the study's AI-models catalogue. ↩
OpenCLIP (LAION and contributors) is an open reproduction of CLIP that maps images and text into a shared embedding space; alternate image encoder here. The code is MIT; note that individual pretrained checkpoints inherit the data terms of their training set (LAION), a separate consideration from the code licence. https://github.com/mlfoundations/open_clip/blob/main/LICENSE (accessed Aug 2026). See catalogue. ↩
Vision-encoder inference (embedding) is far lighter than serving a 32B-class LLM. DINOv2 model sizes are small: ViT-L/14 ≈ 300M parameters, ViT-g/14 ≈ 1.1B (repo model table, accessed Aug 2026). At half precision the weights alone are well under ~1 GB (ViT-L) to ~2 GB (ViT-g), so batch embedding a design-office library fits in a few GB of VRAM and tolerates CPU if slower runs are acceptable. [Inference] These GB figures are reasoned from parameter count and precision, not a measured benchmark; confirm in the pilot. See the Project 1 BOM. ↩
UV-Net (Autodesk) is the only cleanly-licensed B-rep option: its code is MIT. The most task-aligned choice would be UVStyle-Net, built for style similarity search over a CAD library, but its code is CC BY-NC-SA 4.0 (non-commercial), so it cannot ship in a commercial build; its method can instead be reimplemented on UV-Net's MIT encoder. Neither ships moulding-ready weights, so Phase 3 means training self-supervised on the firm's own parts. See the Project 1 BOM and the AI-models catalogue. ↩
FAISS (Meta, MIT, https://github.com/facebookresearch/faiss/blob/main/LICENSE), Qdrant (Apache-2.0, https://github.com/qdrant/qdrant) and Chroma (Apache-2.0, https://github.com/chroma-core/chroma) are open-source vector-search engines that run fully on-premises with no external calls (all accessed Aug 2026); the same class of tool §4.4 uses. ↩