How do you normalize service names before semantic matching?

Hmm. Looking at existing systems, it seems this is often handled by combining several components rather than relying on a single method:

I have not implemented this exact service-matching use case, but the adjacent systems I found seem to converge on roughly the same separation of responsibilities.

My direct answers would be:

A synonym dictionary can help, but I would make it a concept-centered alias registry rather than a collection of pairwise rewrite rules. Light normalization before embedding is useful, but I would preserve the original label and avoid collapsing meaningful modifiers too early. Taxonomy and embedding retrieval are complementary, not competing alternatives: the taxonomy defines the possible concepts, while lexical and embedding methods retrieve candidates from it. Partial overlap should not automatically become synonymy. It is usually safer to retain a relation such as exact, broader, narrower, related, rejected, or unknown.

A practical default pipeline might look like this:

raw service label
+ business category / description / other available context
        ↓
light deterministic cleanup
        ↓
exact-alias, lexical, and dense candidate retrieval
        ↓
task-specific disambiguation or relation decision
        ↓
exact / related / reject / unknown
        ↓
downstream business-matching policy

The most important distinction may be what “match” means downstream:

| Desired result | Reasonable treatment | | Same canonical service | Use conservative exact or close mappings and reject unresolved ambiguity | | Useful search expansion | Broader, narrower, and related services can remain candidates, but should retain their relation labels | | Evidence that a provider can perform the requested work | A service name alone may be insufficient; category, description, scope, location, audience, equipment, or other capability fields may matter |

That distinction determines the labels, evaluation set, and threshold policy more than the embedding model does.

For a first implementation, I would probably start with:

• a small, versioned service registry;
• stable service IDs;
• preferred labels and aliases;
• a short definition or scope note;
• optional parent and related-service links;
• an explicit unknown

or needs_review

result;

• a small evaluation set containing both clear synonyms and deliberately confusing near-neighbors.

Even a modest hand-reviewed set can answer more useful questions than comparing models on undifferentiated examples:

• Does the correct concept appear in the top K

candidates?

• Can the final stage distinguish the same service from a related service?
• How often is a taxonomy-external input forced into a plausible but wrong concept?
• What fraction can be accepted automatically, reviewed, or rejected?

Why I would separate the registry, retrieval, and final decision (click for more details) Alias ambiguity and partial overlap (click for more details) How much normalization to perform before embedding (click for more details) Unknown services and the free-form tail (click for more details) A small evaluation plan before choosing the model (click for more details) A small adjacent-domain sanity check (click for more details) Conditional implementation paths (click for more details) So my default answer would be:

Use a taxonomy or small concept registry as the destination.
Use an alias dictionary for high-confidence known variants.
Use lexical and embedding retrieval to generate candidates.
Use a separate task-specific step to determine the relation.
Preserve unknowns and ambiguous cases instead of forcing a match.
Evaluate retrieval, relation decisions, and rejection separately.

That seems closer to how existing reconciliation and taxonomy systems are structured than searching for one universal service-name normalizer.

The two implementation details that would change the route most are:

• whether “match” means the same canonical service, useful search expansion, or actual provider capability; and
• which contextual fields are available beyond the short service label.

Everything else—model choice, thresholds, relation granularity, and review policy—can be selected downstream of those decisions.