How should similarity search be designed for mechanical parts and industrial products?

Decide what similar means before choosing a model

The most important design decision is the result type. A user who needs a replacement bearing is making a very different decision from a visitor browsing for parts that look alike. If the interface returns both without clear labels, it encourages an unsafe inference that every related result is interchangeable.

These meanings can share storage and retrieval infrastructure, but they should have separate endpoints or an explicit intent parameter. For example, intent=visual_discovery may use image similarity broadly. intent=interchangeable_replacement should call the compatibility rules first and return no recommendation when the evidence is incomplete. A taxonomy such as UNSPSC or GS1 Global Product Classification can organize catalog families, but it does not prove that two items mate, fit, or satisfy a design requirement.

For safety, regulated, load-bearing, pressure, electrical, medical, aerospace, or customer-controlled parts, do not let search results authorize a substitution. A qualified engineer, the manufacturer's approved cross-reference, the controlled drawing, or the applicable quality process remains the authority. Search can produce a reviewable candidate set and its evidence.

Build a canonical product record before building embeddings

Most industrial catalogs are not ready for ranking as-is. The same item can appear under a distributor number, a manufacturer part number, a legacy code, an abbreviated description, and several formatted variants. A score cannot repair an ambiguous identity or a dimension stored without its unit.

Create a canonical record for each physical or sellable part, while retaining each supplier listing as a source record. The canonical record should point back to every input and capture when the data was obtained. ISO 8000 addresses the characteristics and measurement of information and data quality, which is a useful framing for this work. ISO 8000-8 overview

Store a quantity as more than a number. A useful representation for a nominal outside diameter is quantity=outside_diameter, value=52, unit=mm, lower_limit=51.98, upper_limit=52.02, condition=at 20 C, and source=drawing revision C, if those facts are available. Retain the source value as well as the normalized value. NIST describes a quantity value as a number multiplied by a unit, and its SI guidance provides a sound basis for normalizing values without discarding their meaning. NIST Guide to SI values of quantities

Tolerances, datum references, and geometric requirements are not decoration around a nominal dimension. ASME Y14.5 describes the rules for stating and interpreting GD&T and relates them to form, fit, function, and interchangeability. Treat controlled drawings and revisions as primary evidence when they exist. ASME Y14.5 Dimensioning and Tolerancing

For CAD exchange, preserve the original model and its revision, then derive descriptors separately. The ISO 10303 family, commonly called STEP, is intended for computer-interpretable product information and product-data exchange. A geometry embedding or shape signature can help find near shapes, but it must be linked back to the source CAD or drawing so a reviewer can inspect what it represents. ISO 10303-1 overview

Put mandatory compatibility checks before ranking

The retrieval pipeline should have an eligibility stage and a ranking stage. Eligibility answers, “May this candidate be considered for this intent?” Ranking answers, “Among the eligible candidates, which evidence is strongest?” Combining both into one opaque score makes it too easy for a close text or image match to outweigh a disqualifying engineering condition.

For an interchangeable replacement, typical hard filters include:

1. Correct product family and intended function.
2. Required interfaces and mating standard, such as thread system, pitch, connector keying, mounting pattern, shaft and housing fit, flange, or port type.
3. Critical dimensions and their permitted ranges or tolerance scheme.
4. Required material, surface treatment, environmental rating, load, speed, pressure, electrical, temperature, cleanliness, certification, and customer restrictions.
5. Approved manufacturer, lifecycle, geographic, contract, or regulatory constraints where the business process requires them.
6. No explicit conflict, obsolete restriction, or application-specific exclusion.

Some of these conditions may be conditional rather than universal. A seal material might be mandatory only for a particular chemical environment. Model this as a rule with a declared context, not a universal attribute weight. Keep the result of each rule as pass, fail, or unknown, with its evidence and rule version. For a high-risk intent, unknown should block the automatic recommendation. For lower-risk discovery, it can be shown as an information gap.

This is why a pure embedding system is dangerous as a substitute engine. Dense-vector similarity is a mathematical closeness measure, not an engineering compatibility proof. Vector indexes can efficiently retrieve nearest neighbors, but their own documentation describes the operation as distance or similarity among vectors and notes explicit accuracy, speed, and memory trade-offs. Faiss documentation The semantic signal can be useful after hard filters, but it cannot decide whether an M10 x 1.5 fastener is a replacement for an M10 x 1.25 fastener, or whether a bearing with the same envelope dimensions has the necessary clearance, sealing, load, and approval.

Use several retrieval signals for different kinds of evidence

No one method is sufficient. The right design is usually a hybrid pipeline that generates candidates with multiple methods, applies intent-specific eligibility rules, then reranks with explainable features. At a catalog size of roughly 10,000 pages, an exhaustive baseline and clear data work often deliver more value than an early move to a complex graph-retrieval stack.

Hybrid retrieval is a normal engineering choice, not a vendor requirement. For example, Elastic's documentation describes hybrid search as combining full-text and vector search and recommends reciprocal rank fusion to merge ranked lists. Elastic hybrid search documentation You can implement the same pattern with other search infrastructure or a simple service at this scale. The essential point is that each contributing list is traceable and that filtering is enforced before a result can be labeled as a substitute.

A graph database is useful when the relationship itself is the answer. supersedes, fits_equipment, requires_accessory, and approved_for_application are more valuable as typed, versioned edges than as prose inferred anew at query time. ISO 10303 includes a product-relationship application module, which illustrates that relationships are part of product data rather than merely an LLM output. ISO 10303 product relationship module

Do not make GraphRAG the first compatibility system. It can retrieve documents or graph neighborhoods that help an engineer understand a result, but generative synthesis can omit a qualifier or blur the distinction between an approved relation and a plausible association. Use an LLM, if one is approved, for bounded extraction, normalization suggestions, query expansion, or explanation drafts. Require schemas, source spans or document references, validation rules, and review for critical fields. Use deterministic parsers for known part-number formats, units, thread notation, standard designations, and controlled attribute values wherever possible.

A bearing example with eligibility, ranking, and explanation

Example

This is an illustrative example, not an approved bearing-selection rule. A user views an internal part BRG-2505215-C3. Its controlled record says it is a single-row deep-groove bearing with a 25 mm bore, 52 mm outside diameter, 15 mm width, a specified radial-clearance class, sealed construction, minimum dynamic-load requirement, maximum operating speed, and an approved application list. The user chooses “find interchangeable replacement,” not “find visually similar.”

The service first resolves aliases and manufacturer part numbers. It creates a candidate pool from exact identifiers, same-family structured search, manufacturer-approved supersession links, lexical search over datasheets, and a low-weight vector search over descriptions. It then rejects candidates whose bore, outside diameter, width, bearing type, clearance, seal, load, speed, approval, or application rule fails. It also rejects records with unknown values for any attribute declared mandatory by the application. A candidate with nearly identical title text but a different clearance class is not allowed through merely because its description embedding is close.

The eligible candidates are reranked with an intentionally inspectable score. One possible initial formula is 0.40 approved-substitution evidence + 0.25 required-attribute agreement + 0.15 manufacturer and identifier evidence + 0.10 drawing or CAD agreement + 0.10 description agreement. The numeric weights are an illustration, not a universal recipe. Display the factors, the source documents, any inferred fields, and every satisfied rule. The top result can say “Approved replacement for this application, drawing revision C, 10 of 10 required conditions verified.” A lower result can say “Same envelope dimensions, clearance unknown, do not substitute automatically.” The takeaway is that ranking chooses among eligible evidence, while the rules engine protects against a believable but unsuitable neighbor.

For a fastener query, the corresponding hard fields could include thread designation, pitch, diameter, length, head style, drive, material, property class, coating, standard, washer or nut requirements, and the joint's environmental or corrosion conditions. Image similarity may help a user find an unfamiliar head style. It should not decide equivalence between similar-looking threads or strength classes.

Handle gaps, duplicates, aliases, and new products explicitly

Cold start is normal for a new part or a catalog with no click history. Start from content and records: normalized attributes, taxonomic family, identifiers, description, CAD or images, and approved relationships. Do not wait for behavioral data to build an initial system. Behavioral signals, if available, should be a later feature and should be separated by meaning. Co-purchase is evidence for an association, not proof of substitution.

Missing attributes deserve their own state. Do not convert missing diameter to zero, an absent tolerance to an exact nominal, or an unknown material to a generic material class. Track whether a value was supplied by the manufacturer, parsed from a controlled document, inferred by a model, estimated from an image, or entered by a user. For high-risk intents, only verified values should satisfy a hard rule.

Duplicate resolution should be conservative. Begin with exact manufacturer-part-number and authorized supplier cross-reference matches. Add normalized variants that remove harmless punctuation, spacing, and casing only after preserving the original identifier. Use a review queue for near matches, especially where a short suffix encodes a material, tolerance, coating, revision, connector, or package variant. Keep manufacturer names in an alias table with a canonical ID, evidence, effective dates, and owner. Never silently merge two records because their titles, images, or embeddings are similar.

Treat taxonomies as controlled navigation, not a replacement for a compatibility ontology. A taxonomy gives broad family membership. A compatibility model needs typed predicates and context, such as fits equipment model, requires adapter, approved substitute for, not for food-contact use, or compatible only above temperature X. Each relationship needs direction, source, scope, revision, and expiry or review date where applicable.

Learn ranking only from evidence that matches the intended meaning

Metric learning can be worthwhile after the rule-based baseline reveals where it misses good candidates. Train on labels that carry the desired relation, not on every item a user happened to click.

Good positive pairs include manufacturer-declared supersessions, engineer-approved substitutes in the same application context, controlled duplicate mappings, and verified compatible-mating relations. They must be labeled by relation type. purchased_with is not a positive example for interchangeable_with.

Hard negatives are especially valuable. They are pairs that look tempting to a retrieval system but must not be conflated, such as the same part family with a different thread pitch, a visually identical connector with a different keying, a bearing with the wrong clearance or sealing, a coated and uncoated fastener in a corrosive environment, or items from the same manufacturer description but different approval class. Deep metric-learning research commonly uses difficult negative examples because they expose distinctions that random pairs do not. Hardness-Aware Deep Metric Learning

Keep the label's authority, application context, and date. Split offline evaluation by manufacturer family, part family, and time period where practical, so the model is not rewarded merely for memorizing near-duplicate catalog records. If the model is trained on a supplier's cross-reference table, test it on different suppliers or later revisions. A learned score should be one reranking input after eligibility filters, not a substitute for a qualification rule.

Evaluate retrieval quality and substitution risk separately

Build a held-out evaluation set with expert or controlled-document judgments for each intent. Label a query-candidate pair with a graded outcome such as exact identity, approved replacement, functionally similar but review needed, visually similar only, or incorrect. Preserve the evidence used to judge it. Information-retrieval practice uses measures such as precision, recall, average precision, and nDCG; NIST's TREC documentation defines precision and recall at cutoffs and explains their trade-off. NIST TREC evaluation overview

Do not optimize only click-through rate. A visually attractive but incompatible result can attract clicks. For online evaluation, distinguish browse use from procurement or engineering decisions. Track, with appropriate privacy controls, such outcomes as result opening, evidence inspection, request-for-quote creation, engineer acceptance of a reviewed alternative, correction or rejection reason, return or service incident where relevant, and time to find a verified part. Compare candidates in a limited pilot and do not silently expose unreviewed automatic-substitution labels for critical classes.

Confidence should combine evidence coverage and model behavior, not merely a raw similarity score. A clear approach is to reserve the high-confidence label for candidates with approved relationship evidence and all required attributes verified. For candidates without that evidence, use labels such as “possible functional match” or “needs engineering review,” show the missing fields, and provide an escalation path. Low confidence is a valid output. An empty result is safer than inventing a substitute.

Implement in increments that preserve auditability

1. Define intents and risk classes. List the result types, the user roles, the cost of a false result, and the allowed labels. Start with low-risk discovery and explicit associated-parts use cases if substitution evidence is scarce.

2. Create the canonical schema and provenance contract. Keep raw source records, part identities, aliases, attributes with units and tolerances, document revisions, and typed relationships. Select a small family such as bearings or fasteners for the first data-quality pass.

3. Ship an auditable baseline. Use exact identifier matching, aliases, taxonomy filtering, structured attribute comparisons, and lexical search over titles and documents. Show why each result was retrieved and which information is missing.

4. Add explicit relationships. Ingest manufacturer supersessions, assemblies, accessories, equipment fitment, and approved substitution tables as typed edges with source and date. A graph store is optional at this stage. A relational table can represent the same facts until traversal patterns justify a graph database.

5. Add hybrid retrieval for discovery. Combine lexical and vector candidates, then apply intent-specific filters and an explainable reranker. Test any image or geometry signal as a separate source rather than letting it redefine compatibility.

6. Collect review labels and hard negatives. Give reviewers an efficient way to accept, reject, or classify candidates and state why. Feed corrected aliases, attributes, and relationships back into the canonical store before training a learned ranker.

7. Introduce learned ranking cautiously. Evaluate against the frozen baseline by product family and risk class. Deploy first to a review queue or visually similar results. Promote it to more consequential ranking only when it improves the relevant metrics without increasing constraint violations.

8. Operate the system as product data, not a one-time model. Reprocess changed catalogs, version rules and models, monitor missing critical attributes, review unexpected rejection patterns, and make every result reproducible from its query, candidate set, rule version, features, and source evidence.

Failure modes to avoid