Skip to content
← Back to blog
AI modelsArticle

Custom AI models for spare part identification

AI can return catalog parts that match a customer's wording as candidates for review. If two variants have different connection types and the description does not say which one is needed, the system should preserve that uncertainty, ask for the missing detail and hand the choice to sales or a product specialist.

Author

Syntalith

Published Updated 6 min read

For an industrial distributor, the buying question is whether a model can help sales find the right catalog entries or simply add more results for someone to review. Start by testing search against the current catalog and approved customer terms.

Fine-tuning means further training an existing model on labeled examples that specify the expected result. Google describes that approach for supervised fine-tuning in its model tuning documentation. In this use case, current product details should still come from the current catalog, and the adapted behavior should be tested on separate cases. Consider tuning only when the simpler search comparison leaves recurring mapping errors and the team can agree on correct answers for approved examples.

When one description matches two variants

Suppose a customer writes, “I need the standard service connector for a pump.” In this fictional example, the catalog contains two entries with similar descriptions. One lists variant A and one connection type; the other lists variant B and a different connection type. The message contains no part number or variant detail. The system can use only the customer’s wording and the fields in those catalog entries.

A useful result shows both candidates and the catalog fields that distinguish them, then asks for the missing detail, such as connection type or variant marking. It leaves the selection open for review. The result supports a text match against two catalog records, while the product-fit decision remains unresolved. The wording alone does not establish that the parts are interchangeable.

The salesperson should be able to see which details came from the customer and which came from a catalog record. If the customer supplies a missing value that matches one entry, the salesperson can confirm the candidate through the company’s process. If the answer still leaves the difference open or requires a product judgment, the case should go to a designated specialist. That gives the buyer a clear view of who accepts the recommendation and how the team handles an unresolved match.

Test search before adapting a model

Some mismatches come from language. Customers may use an abbreviation, a local term or a misspelling while the catalog uses the formal product name. Elastic’s documentation on search synonyms describes rules for expanding search to include domain jargon and common misspellings, and distinguishes equivalent terms from one-way mappings. That supports testing a maintained alias list or search rules before commissioning model adaptation. A synonym rule can help find records from the words used; it cannot settle which physical variant fits a particular application.

If customer terms are stable and the company knows their catalog equivalents, an alias dictionary may be enough. With more varied descriptions, compare it with a general model that retrieves candidates from current catalog records. Consider adapting a model only if the same kinds of incorrect matches keep appearing after simpler approaches have been checked. When the description omits the detail that separates two variants, more training cannot supply information the customer did not provide.

How to evaluate the result

Before a test, the catalog owner and a sales representative should agree on the correct outcomes for the examples. Include descriptions with a single candidate, descriptions that match several entries and cases where the catalog cannot support an answer. Hold out descriptions from other customers so the team can see whether the system handles unfamiliar wording. These are proposed acceptance criteria for comparing approaches; the buyer should agree on them for the task.

A single accuracy rate will not show the full purchase risk. Track how often the system confidently returns the wrong part, whether the candidate list helps sales, and how much clarification work remains with an employee. The team should also decide which errors carry the greatest cost and when a result must stop for a missing detail. Review easy matches, ambiguous requests and no-match cases separately.

Each part of the assessment needs someone who knows that stage of the work. The catalog owner checks the attributes shown for each candidate. Sales assesses whether the list and follow-up question are useful. A product specialist reviews the cases that need further judgment. If these roles disagree on the expected result, clarify the criterion before buying model adaptation. The support-ticket fine-tuning guide discusses similar questions about labels and evaluation in a different task.

If an alias list produces a similar result with less change, the comparison supports keeping it. If confident wrong matches continue after checking the labels, catalog records and handoff, it may be worth evaluating an adapted model. The buyer should receive a comparison of the options on the same cases, an account of the errors and a decision about whether more testing is justified. The value of fine-tuning depends on what the comparison shows.

The company also needs an owner for approved aliases and catalog corrections. Product names, variants and attributes can change. Assign catalog updates to a specific role, and keep the source record visible in a candidate result. The system can help find possible matches; current product information should come from the catalog the company maintains.

What to agree with a provider

At Syntalith, a discussion about custom AI applications and models can be scoped around catalog search, comparison with a model and a handoff to sales when the match remains unclear. Combining those steps helps identify whether the problem lies in customer terminology, missing product information or the way sales handles a candidate. A proposal could include a reviewable report comparing the approaches on the same descriptions, with errors and cases that need human review. Agree on that scope before deciding whether model adaptation merits further testing.

If the larger problem is collecting missing information across an entire request for quotation (RFQ), see the guide to AI agents for wholesale RFQ clarification, which covers the wider message-handling workflow.

For an initial discussion, bring a few sanitized customer descriptions, catalog entries with the variant and connection fields, and examples of how the team resolves similar cases today. The descriptions show the language customers use; the catalog entries show which distinguishing details are available; the current decisions help define an acceptance test. For pricing, see Syntalith’s pricing page.

Match a model to the task you need it to perform

Describe where your current AI falls short. We will compare model customization options, data requirements and the cost of running the resulting system.

Private LLMs and fine-tuning
Discuss a custom model