From string matching to related concepts
One concrete product problem was job-title matching. A basic lexical implementation could compare exact or near-exact strings, but it could not naturally express that two different titles may describe closely related roles.
The development plan therefore separated two questions: first, establish a lexical baseline and compare old versus new ranking behavior on more than 30 searches; second, extend matching to related job titles using embedding similarity scores. That made semantic retrieval an evaluated extension of an existing search path, not a replacement chosen on intuition.
Retrieval path
Evaluation was part of the feature definition
Lexical baseline first
The roadmap explicitly called for a basic string-matching proof of concept and an old-versus-new ranking comparison over more than 30 searches before extending the feature.
Semantic extension second
The next step was to create relationships between related job titles through embeddings and similarity scores, with an interactive notebook planned as part of the proof of concept.
No invented aggregate metric
The surviving material supports the comparison design and implementation direction, but not a trustworthy public aggregate relevance score. The page therefore does not manufacture a precision, recall, or conversion uplift.
Representation choices
Sentence-transformer models made it possible to compare full text units in a shared vector space rather than relying only on token overlap. MPNet-family representations were used for multilingual semantic matching, while Elasticsearch remained the operational retrieval layer.
That separation mattered because model inference, representation refresh, indexing, query execution, filtering, and product-facing response behavior have different failure modes and deployment concerns.
Integration mattered as much as model quality
Existing search semantics
Semantic similarity had to coexist with filters, exact terms, index mappings, and established product expectations instead of becoming an isolated nearest-neighbour demo.
Multilingual edge cases
Language variation changes both lexical overlap and embedding behavior. Search quality therefore had to be inspected on the text users actually produced rather than inferred only from model benchmark results.
Operational boundaries
Representation generation and index updates had to fit the surrounding application and data flows. A model change that created unacceptable latency, stale representations, or incompatible responses would not be a production improvement.
Engineering questions behind the implementation
- Which text should be embedded as one semantic unit, and when should representations be regenerated?
- How should semantic similarity coexist with exact lexical requirements and structured filters?
- How should a lexical baseline be compared with embedding-based related-title ranking?
- Where should model work stop and Elasticsearch/application responsibility begin?
- How should multilingual failure cases be examined when one relevance rule does not behave uniformly across languages?
Scope
Internal customer data, company identity, business metrics, and proprietary implementation details are intentionally omitted. The evidence shown here is limited to architecture, model/retrieval choices, and non-sensitive development records that establish how the feature was evaluated and integrated.