I need advice on whether to use embeddings, full-text search, or both for a support knowledge base with multilingual content and strict latency goals

For a support knowledge base with multilingual content and strict latency goals, the best default is usually both:

• Full-text search for precision, speed, exact term matching, and operational simplicity
• Embeddings / vector search for semantic matching, paraphrases, and cross-lingual retrieval

If you have to choose one first, start with full-text search unless your queries are mostly fuzzy, conversational, or cross-language. If your content and users span multiple languages, a hybrid approach is typically best.

Quick recommendation

Use full-text search when:

• Users search for product names, error codes, IDs, feature names
• Queries are short and keyword-like
• You need very low latency
• You want deterministic ranking and easy debugging
• Your corpus is already well structured and contains lots of exact terminology

Use embeddings when:

• Users ask questions in natural language
• They paraphrase heavily
• They search across languages
• Exact keywords are unreliable or inconsistent
• You want to capture semantic similarity, not just lexical overlap

Use both when:

• You need the best recall and reasonable precision
• Queries are multilingual and varied
• You want a safe fallback if one method misses
• You can afford a slightly more complex retrieval stack

---

What matters most for your use case

1) Strict latency goals

This is the biggest constraint.

• Full-text search is usually faster and easier to keep predictable.
• Embeddings can be fast too, but vector retrieval often adds:
  • embedding generation for the query
  • ANN vector search
  • optional reranking

If latency is extremely tight, a good pattern is:

1. Run full-text search first
2. If results are weak, fall back to vector search
3. Optionally rerank top candidates

Or, if you use hybrid retrieval:

• retrieve from both in parallel
• merge results
• keep candidate set small to stay within latency budget

2) Multilingual content

Multilingual support changes the picture a lot.

• Traditional full-text search works well within a language
• Cross-lingual search is harder unless you:
  • index per language
  • use language-specific analyzers/stemmers
  • translate queries/content
  • or rely on multilingual embeddings

Multilingual embeddings can help users search in one language and find content in another, which is a major advantage for support KBs.

3) Support knowledge base structure

Support KBs often contain:

• titles
• symptoms
• steps
• error codes
• product/version references
• troubleshooting procedures

This is a strong case for full-text search plus semantic search:

• full-text to catch exact product/version/error references
• embeddings to catch conceptual matches like “app won’t sync” → “syncing fails after login”

---

Practical architecture options

Option A: Full-text only

Best if:

• most queries are exact or near-exact
• you need simple, fast, explainable retrieval
• multilingual needs are limited and you can segment by language

Pros:

• fast
• cheap
• easy to debug
• good for exact matches

Cons:

• poor semantic recall
• weaker cross-lingual retrieval
• misses paraphrases

Option B: Embeddings only

Best if:

• queries are conversational and semantic
• cross-lingual search is important
• exact term matching is less important

Pros:

• strong semantic matching
• good for multilingual intent matching

Cons:

• can miss exact terms and IDs
• harder to explain/debug
• more operational overhead
• may be slower or more expensive at scale

Option C: Hybrid search

Best for your case in most situations.

Typical approach:

• full-text search for lexical recall
• vector search for semantic recall
• combine scores or merge top-k results
• rerank with a lightweight model or rules

Pros:

• best coverage
• handles exact and semantic queries
• better multilingual robustness

Cons:

• more engineering complexity
• tuning required
• slightly higher latency if not carefully designed

---

Recommended strategy for your case

If latency is very strict

Use a tiered retrieval pipeline:

1. Language detect the query
2. Run full-text search with language-specific analyzer
3. In parallel or as fallback, run multilingual vector search
4. Merge the top results
5. Optionally rerank only the top 10–20 candidates

This keeps latency manageable while improving recall.

If you need the lowest possible latency

Use full-text as primary, embeddings as fallback for:

• low-confidence queries
• no-result queries
• highly ambiguous queries
• cross-language mismatches

This often gives you the best latency/quality tradeoff.

---

How to think about ranking

For support KBs, ranking is often improved by combining:

• exact title match
• keyword match
• semantic similarity
• freshness
• article popularity or resolution rate
• language match
• product/version match

A good hybrid ranker can heavily favor:

1. exact title / error code hits
2. strong lexical matches
3. semantic matches
4. metadata boosts

---

Pitfalls to avoid

Don’t rely on embeddings alone for:

• error codes
• SKUs
• version strings
• precise feature names
• legal or compliance-sensitive KBs where exactness matters

Don’t rely on full-text alone for:

• paraphrased user questions
• multilingual equivalence
• vague issue descriptions

Don’t vectorize everything blindly

For support KBs, embeddings work best when:

• chunking is well designed
• metadata is preserved
• language is handled explicitly
• you test retrieval quality by query type

---

A good rule of thumb

• If users search like:
  “How do I reset MFA on iPhone?”
  → embeddings help a lot

• If users search like:
  “ERR-5042 login timeout”
  → full-text is crucial

• If users search in one language and content is in another
  → embeddings are very valuable

So for a multilingual support KB with low latency constraints, hybrid retrieval is the strongest default.

---

My practical recommendation

If you’re designing this today:

1. Implement full-text search first
2. Add multilingual embeddings for semantic recall
3. Use a hybrid retrieval pipeline
4. Keep candidate sets small to protect latency
5. Measure:
   • recall@k
   • success rate
   • P95 latency
   • no-result rate
   • click-through / resolution rate

If you want, I can also help you with:

• a decision matrix for embeddings vs full-text vs hybrid
• a reference architecture for low-latency multilingual search
• or a stack-specific recommendation for Elasticsearch, OpenSearch, Postgres, Pinecone, Weaviate, etc.