Define the relation before choosing the model
The request was to improve search with AI, but “related skill” covered different cases: synonyms and spelling variants, closely or loosely related concepts, directional parent-child relations, and multilingual equivalents. Treating all of them as one undifferentiated similarity problem would produce the wrong expansions.
The existing co-occurrence approach made that concrete: Python and Java often appear together but are not interchangeable, while MongoDB can reasonably imply NoSQL without making the inverse expansion equally valid. The work therefore moved toward explicit relation semantics and proximity bands rather than a single nearest-neighbour rule.
Separate search and indexing defects from representation quality
Analyzer and tokenizer behavior
Elasticsearch investigation exposed a tokenizer problem around slashes and backslashes, which affected how some skills were indexed and matched. That problem belonged in the search configuration, not in the embedding model.
Index and relation quality
Repeated related-skill entries and stale or incomplete relation data also affected search behavior. These issues had to be separated from representation quality before model comparisons were useful.
Cleanup versus expansion
Typos and synonyms could be merged or normalized, while broader semantic relations needed explicit proximity bands. This kept cleanup, close semantic relations, and looser expansion behavior from collapsing into one raw similarity score.
Compare models on the product's own vocabulary
Nine embedding variants were compared for related-skill ranking. The recorded evaluation covered 28,400 comparison samples and tracked where the first irrelevant result appeared in the ranked list, along with its similarity or proximity.
The selection was based on the multilingual skill vocabulary and relation behavior needed by the product rather than a generic public benchmark. MPNet-family representations won that comparison.
Two production retrieval paths
The selected representation was used in two different ways. Related-skill generation materialized semantic relations into the existing search data, while job-title search used the model during the live query path.
Related skills
Live job-title search
Fit the semantic component into the existing product
For related skills, the work moved from model selection into the NLP service, API design, Ruby integration, relation-table generation, proximity assignment, reindexing, and search comparison. For job-title search, title embeddings were precalculated and stored with the search data, while the user's query was embedded at request time for semantic comparison and ranking.
Neither path replaced the surrounding search system. Semantic signals were added to the existing application and Elasticsearch workflow so lexical matching, filters, indexing rules, and other established search behavior could continue to operate alongside them.
Scope
Company and product identifiers are omitted for confidentiality. The surviving artifacts support the model-comparison and integration evidence above, but not a trustworthy public business-impact metric, so none is claimed.