Custom AI models for spare part identification

When one description fits two variants

Say a customer writes: “I'm looking for a service coupling for the pump, the standard one”. In this fictional example the catalogue holds two items with similar descriptions. The first has variant A and one connector type recorded, the second variant B and a different connector type. The message gives no part number and no information about which variant or connector type is needed. That is all the system can take into account: the customer's text and the catalogue fields.

A useful result shows both matching items together with the fields that tell them apart. Instead of choosing one, the system points out the missing information, for example the connector type or the variant code, and suggests a short question for the customer. Finding a candidate from a similar description does not confirm that the parts are interchangeable. The system has no grounds to fill in the missing parameter from its own knowledge.

The salesperson should see which data comes from the message and which from specific catalogue records. If the customer gives the missing value and it matches one item's description, the salesperson can confirm the proposal in their process. When the answer still does not settle the difference, or needs a product assessment, the case should go to the named specialist. This split tells the buyer who accepts the result and what happens with an unresolved case.

Check simpler search for spare part identification first

Some of the difficulty comes from vocabulary. Customers may use an abbreviation, a local term or a typo, while the catalogue records the formal name. Elastic's documentation on synonyms in search describes rules that cover industry jargon and common typos, and distinguishes equivalent terms from one-way mappings. So before you order model adaptation, check a maintained alias list or search rules. A rule helps find records from words; on its own it does not settle which physical variant fits the use.

If customers' names are stable and the company knows their catalogue equivalents, an alias dictionary may be enough. With freer wording, compare a general model that searches the current records with such a rule-based solution. You move to a model adaptation test only when both approaches leave a recurring problem and its source turns out to be the mapping of descriptions. If the data that tells variants apart is missing, the model will not remove that ambiguity through training alone.

How to assess the model's proposals

Before the test, the catalogue owner and a person from sales support should agree the correct answers for the examples. The set should include approved descriptions, cases with more than one candidate, and cases where the catalogue gives no basis for an answer. Some descriptions from separate customers should stay out of the examples used for adaptation, to check how the system handles unfamiliar wording. The details of data preparation depend on the agreed scope.

The number of correct hits alone does not show the whole risk of the purchase. The process owner should separately judge how often the system confidently points to the wrong item, whether the list helps the salesperson and how many clarifications a person still makes. The team also decides which mistakes cost most and when the result should stop with a question about the missing feature. Count the results separately for easy matches, ambiguous descriptions and cases with no answer in the catalogue.

Each part of the assessment is checked by a person who knows that stage of work. The catalogue owner checks the fields of the item shown, the salesperson judges how useful the list and the customer questions are, and the specialist reviews the unclear cases passed to them. If the roles disagree on the correct result, the criterion has to be made more precise before you buy adaptation. Similar questions about labels and assessment in another task are covered in the article on fine-tuning service ticket classification.

If an alias dictionary reaches a similar result with a smaller scope of change, the test speaks for staying with it. When, after checking the labels, the catalogue and the hand-over, a general model still confidently picks the wrong items in approved descriptions, it is worth assessing adaptation. The buyer should get a comparison of the methods on the same cases, a description of the errors and a decision on whether to go to the next stage. The option to fine-tune does not, by itself, settle the benefit.

You also need to agree who approves new aliases and catalogue corrections. Variants, names and fields can change. If a catalogue change needs a manual correction, assign it to a specific role, and keep a trace of the record and the data used in the search result. The model can help find candidates; the current state of the product range should come from the source the company maintains.

What to agree before choosing a supplier

At Syntalith you can agree a scope that covers custom AI apps and models, a comparison of catalogue search with a model, and the hand-over of unresolved cases to the salesperson. This combination helps establish whether the difficulty comes from the words customers use, missing data or the later handling of the proposal. The scope can include a report comparing both methods on the same descriptions, with errors and the cases that need a check. Such material makes it easier to decide whether model adaptation is worth testing separately.

If the main difficulty is collecting the gaps across a whole request for quotation, the write-up of an AI agent for clarifying RFQs in a wholesaler will also help, as it covers the wider process of handling messages.

For the first call, prepare a few anonymised customer descriptions, a part of the catalogue with the variant and connector fields, and examples of how the team settles similar cases today. The descriptions will show the customers' real language, the records will reveal the distinguishing data available, and the employees' decisions will help set reliable acceptance criteria. We price a private model after a call about the data and the hardware, and an app on it starts from €3,000 net (pricing).

What a spare part identification model costs and what it saves

Where to start

In the free process review we choose one process and 20 to 100 cases the team has already handled. We compare the simpler change with the adapted model on cases the model has not seen, and within 2 working days you get a written summary with a price. We adapt models as part of private LLMs, and build the app as an AI app.