假设你现在负责从0搭建一个RAG问答系统，知识库有5000份文档，需要支持多轮对话，你怎么设计

P1 · rag · 🏢 京东

🏷 标签：rag, system-design, multi-turn, knowledge-base

1️⃣ 考察意图

面试官想看你从0到1的系统全局设计能力，而非单个模块的细节背诵。这道题的“刁钻点”在于：5000份文档规模不大，但多轮对话引入了历史依赖，容易让候选人只堆砌RAG组件（如向量检索+LLM），却忽略对话状态管理、检索策略随轮次变化、以及离线与在线模块的联动。答好了能展示：你懂工程取舍（如chunk大小与检索精度的平衡）、能落地（如处理多轮中的指代消解）、有系统思维（如缓存与异步处理）。这是P1进阶题，考察从“会用工具”到“能设计系统”的跃迁。

2️⃣ 标准答

我会从离线处理、在线推理、多轮对话适配三个层面展开，并强调模块间的trade-off。

离线处理：文档解析与索引构建

文档解析：对PDF/Word等格式，用Unstructured库或PyMuPDF提取文本，保留标题、表格等结构信息。坑：5000份文档中可能有扫描件，需加OCR（如Tesseract），但会引入噪音，需后处理（如正则过滤乱码）。
Chunk切分：采用语义分块（Semantic Chunking），基于段落或句子边界，而非固定token数。为什么：固定切分（如256 tokens）会切断逻辑流，导致检索碎片化。具体做法：用LangChain的RecursiveCharacterTextSplitter，chunk_size=512，chunk_overlap=128，平衡上下文完整性与检索粒度。
Embedding与索引：用BGE-M3（多语言、多粒度）或text-embedding-3-large生成向量，存入FAISS（HNSW索引，efConstruction=200, M=32）。Trade-off：HNSW速度快但内存占用高，5000份文档约10万chunks，内存<2GB，可接受。同时建BM25倒排索引（默认k1=1.5, b=0.75）做混合检索，弥补向量对低频术语的遗漏。

在线推理：Query理解与检索

多轮Query理解：用LLM改写（如GPT-4o-mini）将历史对话压缩成独立Query。做法：输入“用户问题+最近3轮对话”，输出改写后的Query。坑：改写可能丢失上下文，需加实体提取（如SpaCy NER）显式保留关键实体（如“那个合同”→“2023年采购合同”）。
混合检索：向量检索（top_k=50）+ BM25（top_k=50），用RRF（Reciprocal Rank Fusion，k=60）合并结果。为什么：向量擅长语义匹配，BM25擅长关键词匹配，RRF比加权平均更鲁棒（无需调权重）。
Rerank精排：用BGE-Reranker-v2（或Cohere Rerank）对top_k=20结果重排，计算与Query的语义相关性。Trade-off：Rerank增加50ms延迟，但能提升10-15%的准确率，对多轮对话中模糊Query尤其关键。

多轮对话适配：上下文管理与缓存

上下文窗口：维护一个滑动窗口，保留最近5轮对话（用户Query+系统回答），用Token计数控制（如<4000 tokens），避免LLM上下文溢出。
缓存策略：对高频Query（如“公司政策是什么”）用LRU缓存（Redis，TTL=1小时），直接返回缓存答案。坑：多轮对话中，同一Query在不同轮次可能不同（如“它”指代变化），缓存需结合Query改写结果做key，而非原始输入。
LLM生成：用GPT-4o或Claude-3.5，Prompt中注入“历史对话+检索结果+当前Query”，并加指令：“如果检索结果不相关，请说‘未找到相关信息’，不要编造”。实际落地的坑：5000份文档中可能有矛盾信息（如版本更新），需在Prompt中加“优先使用最新文档”或文档时间戳过滤。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从离线处理、在线推理、多轮对话适配三个层面回答。离线层面，用语义分块+混合索引（向量+BM25）构建知识库；在线层面，用LLM改写Query、RRF融合检索、Rerank精排；多轮对话层面，维护滑动窗口+LRU缓存。总结一句：核心是平衡检索精度与延迟，通过模块解耦支持迭代优化。”

4️⃣ 高频追问 & 应对

追问 1：如果知识库文档更新频繁（如每天新增100份），你怎么设计增量更新？

应对策略：增量更新需避免全量重建。做法：对新文档走离线管道（解析→分块→Embedding），用FAISS的add_with_ids追加向量，同时更新BM25索引（用Elasticsearch的_update API）。坑：旧文档可能被删除或修改，需维护一个文档版本表（MySQL），记录每个文档的hash和更新时间，检索时过滤过期版本。Trade-off：增量更新快但索引碎片化，每1000次更新后需做一次索引合并（FAISS的merge_from），减少搜索延迟。

追问 2：多轮对话中，用户说“刚才那个方案的具体条款是什么”，你怎么处理“刚才”这种指代？

应对策略：这是指代消解问题。做法：在Query改写阶段，用LLM显式解析指代。例如，Prompt中加“如果用户提到‘刚才’、‘它’等词，请从历史对话中找到对应实体，替换到Query中”。具体实现：维护一个实体追踪器（如用字典存储每轮对话的实体列表），改写时优先匹配。坑：如果历史对话中有多个“方案”，需用时间顺序或用户确认（如“您指的是A方案还是B方案？”）来消歧。

追问 3：如果5000份文档中有大量重复内容（如多个版本的政策文件），你怎么保证回答一致性？

应对策略：引入文档去重和版本优先级。做法：离线阶段，用MinHash（或SimHash）计算文档相似度，合并重复内容（保留最新版本）。在线阶段，在检索结果中加文档时间戳，Prompt中指定“优先使用时间戳最新的文档”。坑：去重可能误删关键差异（如不同部门的政策），需保留文档来源标签（如部门名），在Rerank阶段按相关性排序。

5️⃣ 避坑 · 常见错误答法

❌ 只讲“用LangChain搭一个RAG pipeline，用Chroma存向量，用GPT-4回答” → ✅ 必须讲具体设计取舍：为什么选FAISS而非Chroma（性能与扩展性）、为什么用混合检索而非纯向量（低频术语召回）。
❌ 忽略多轮对话，只讲单轮检索流程 → ✅ 必须包含Query改写、滑动窗口、指代消解等适配机制。
❌ 说“用Rerank一定能提升效果”而不提延迟代价 → ✅ 要给出具体数字（如Rerank增加50ms延迟，但准确率提升10-15%），并说明何时可以跳过（如简单Query）。

6️⃣ 简历呼应

如果你有RAG项目：从“我曾在XX项目中用类似方案处理过2000份文档，但当时没考虑多轮对话，这次我会加Query改写和滑动窗口”切入，展示迭代思维。
如果你只做过传统NLP：用“传统QA系统用规则匹配，RAG用检索+生成，但核心都是Query理解。我会把实体提取（SpaCy）和指代消解（基于规则）迁移过来”类比，突出迁移能力。
如果你是校招无项目：聚焦“我复现过LangChain的RAG demo，但发现多轮对话是问题。我会用LLM改写+缓存来优化，并参考了《RAG Survey》论文中的混合检索方案”展示学习深度。
《Retrieval-Augmented Generation for Large Language Models: A Survey》（Gao et al., 2023）
FAISS官方文档：HNSW索引参数调优指南
LangChain的Multi-Turn RAG示例（官方Cookbook）
BGE-M3论文：多语言、多粒度Embedding模型
《When Not to Trust Your LLM: RAG with Rerankers》博客（Weaviate）

—— 本场面试完 ——