A global enterprise deploys a RAG system with Claude across 15 countries. The knowledge base contains documents in 8 languages. Users query in their native language. Current architecture: all documents are stored with their original language embeddings; queries are embedded in the query language; similarity search runs in the query's embedding space. The system performs well for English but significantly underperforms for Japanese and Arabic queries even when relevant documents exist in those languages. What is the architectural root cause and fix?

The root cause is that monolingual or weakly multilingual embedding models create separate embedding spaces per language — a Japanese query embedding is not comparable to an English document embedding because they exist in different geometric spaces. The fix is a multilingual embedding model that creates a single shared cross-lingual embedding space, where semantically equivalent content in different languages occupies nearby positions regardless of language. This directly enables Japanese queries to retrieve English or Arabic documents (and vice versa) if they cover the same topic. Option B (language-specific chunking) addresses tokenization quality (important for Japanese especially) but doesn't fix the cross-lingual embedding space problem — correctly tokenized Japanese documents in separate embedding space still won't be retrieved by Japanese queries. Option C (translate to English) is a valid but architecturally heavyweight workaround that introduces translation latency, translation errors, and requires translation infrastructure for 8 languages. It also loses nuance in translation-sensitive domains. Option D (cross-lingual reranker) improves precision but only helps if the initial retrieval already returns relevant documents — if the embedding space doesn't support cross-lingual similarity, initial retrieval won't return enough relevant non-English documents to rerank.