Multi-KB strategy
One assistant can search across multiple knowledge bases at once. Use separate KBs when content has different owners, update cadences, or sensitivity levels.
When to use multiple KBs
Section titled “When to use multiple KBs”| Pattern | Example |
|---|---|
| By topic | Product FAQ + Billing & refunds + API docs |
| By audience | Public help + Internal SOPs (staff-only assistant) |
| By source | Uploaded PDFs + website crawl of marketing site |
| By classification | Public KB for widget; confidential KB for admin assistant only |
Step 1 — Create focused knowledge bases
Section titled “Step 1 — Create focused knowledge bases”Keep each KB cohesive — retrieval works best when chunks in a collection share vocabulary and intent. See Content best practices.
Step 2 — Attach to one assistant
Section titled “Step 2 — Attach to one assistant”- Open the assistant → Knowledge section.
- Enable RAG.
- Select multiple knowledge bases from the list.
- Save.
At query time, the Intent Analyzer routes to knowledge retrieval when needed; hybrid search runs across all attached KB collections in Qdrant, with results merged via RRF before the Response Synthesizer answers.
Step 3 — Align search settings
Section titled “Step 3 — Align search settings”| KB | Tuning |
|---|---|
| Short FAQ KB | Higher similarity_threshold, lower max_results |
| Long manual KB | More max_results — Tune search settings |
Assistant-level caps still apply in RAG settings.
Governance
Section titled “Governance”- Apply classification per KB — do not attach restricted KBs to public widgets
- Limit who can edit KBs with team roles — editors can manage content; viewers read only
- Use Audit feed to track KB attach/detach changes
Anti-patterns
Section titled “Anti-patterns”- One giant KB mixing unrelated departments — hurts precision
- Duplicating the same PDF in multiple KBs — wastes storage and can confuse citations
- Attaching every KB to every assistant — increases noise; curate per use case