Multilingual Vector-Retrieval Evidence Architect — Industrial Service

The mandate

Field engineers lose hours searching manuals, bulletins and case histories across product generations, yet the first vector-search pilot sometimes retrieves obsolete procedures or documents outside a customer’s entitlement. Relevance demos use curated English questions and do not show whether an answer remains safe across language, equipment configuration and revision. Leadership needs an architecture governed by service consequence, not semantic similarity alone.

The deliverable is a Multilingual Retrieval Evidence Architecture for three equipment families and six service languages. It must define source authority, chunk and embedding strategy, metadata filters, revision logic, entitlement, hybrid retrieval, citation, abstention, evaluation and feedback. A reference service and product decision book will compare build, managed and mixed options without presuming a particular vector database or model provider.

Milestone one in week three supplies the authoritative-source map, failure taxonomy and evaluation corpus design. Week seven closes milestone two with architecture choices and an instrumented reference pipeline. At week twelve, milestone three delivers blinded field testing across languages and product revisions. Milestone four in week seventeen provides accepted evidence, vendor decision, operating controls and transition backlog.

Acceptance requires field engineers not involved in design to answer forty unseen diagnostic questions with every cited passage resolving to an entitled, effective document; unsafe obsolete retrieval must remain below the agreed zero-tolerance class, and the service must abstain on unsupported cases. Safety and Service jointly approve the test results after reproducing sampled ranking and filter decisions from retained evidence.

The client will provide controlled manuals, bulletins, revision histories, product configurations, entitlement rules, search logs, translated queries and closed service cases. Documentation owners will identify authoritative status; identity teams will implement access tests; field engineers will conduct blind evaluation. The global service sponsor will decide disputed source and abstention policy within two working days.

Why this is external work

Documentation teams favour authoritative sources, search engineers optimise benchmark relevance and field teams prefer fast answers, leaving no neutral owner of the combined safety threshold. Current vendors also benchmark on conditions that advantage their stack. External work can design consequence-led evaluation and portable architecture while avoiding a predetermined database, embedding model or generative layer.

What you will own

• Map authoritative manuals, bulletins, service cases and revision relationships to equipment family, configuration, language, entitlement and effective date.
• Design chunking, embedding, lexical retrieval, metadata filtering, reranking, citation and abstention as one controlled decision path.
• Construct an evaluation corpus spanning multilingual synonyms, sparse fault descriptions, obsolete procedures, conflicting revisions and unsupported questions.
• Define safety-weighted measures that distinguish harmless ranking variation from retrieval capable of causing incorrect field action.
• Test entitlement before and after retrieval, including cached vectors, derived indexes, citations and feedback records across customer boundaries.
• Compare platform options through observed relevance, latency, operability, lock-in, cost and evidence portability rather than vendor headline benchmarks.
• Transfer corpus maintenance, release qualification, source-change monitoring and incident response to named search, documentation and service owners.

Candidate qualifications

• Architected production vector or hybrid retrieval across multilingual technical corpora with version, entitlement or safety constraints.
• Designed relevance evaluations using real practitioner tasks and consequence-weighted failure classes rather than curated demonstration prompts.
• Controlled obsolete and conflicting technical content through metadata, effective dating, source authority and reliable abstention behaviour.
• Governed access across indexes, caches, embeddings, citations and feedback where retrieval could leak customer- or product-restricted material.
• Compared managed and self-operated search stacks without commercial attachment to a vector database, foundation model or systems integrator.
• Left internal teams able to refresh evaluation corpora and qualify releases as documents, languages and product generations changed.

Non-negotiables

• The named architect must lead field observation and blind evaluations in Prague and relevant Central European service locations.
• No reseller, referral or investment relationship may exist with vector database, search, model or knowledge-platform candidates.
• Product-safety owners retain authority over approved procedures; retrieval acceptance does not validate independent service action.
• Restricted manuals and customer cases must remain inside client-controlled environments, including embeddings and evaluation outputs.

1. 49 words maximum. Describe a vector-retrieval result that looked relevant but was unsafe because revision or configuration context was wrong.
2. 49 words maximum. How would you test entitlement leakage through embeddings, caches and citations rather than only source-document access?
3. 49 words maximum. Which blind field metric would you prioritise over generic retrieval precision, and why?