从产品落地到技术实现，RAG 知识库的核心模块设计直接影响检索质量与用户体验。本文围绕文档切分、向量生成、向量库选型、检索策略、重排序、Prompt 拼接及失败处理七大关键环节，系统拆解实现要点与避坑指南，帮助你在实际项目中构建稳定、精准的知识库系统。
1. 文档切分策略（切得好，才能召回准）
目标
将长文档合理切割为语义完整的片段，既要确保上下文连贯性，又不能超出模型 token 长度限制。
常见策略
| 策略 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| 固定窗口 + 重叠 | 按固定词数或句数切分，相邻片段保留部分重叠 | 实现简单、信息不易遗漏 | 语义可能断裂、冗余较多 |
| 基于分隔符 | 按照段落、标题、换行等结构标记切分 | 保留文档结构，适合规整内容 | 对无格式文本适应性差 |
| 智能语义切分 | 利用句向量计算相似度，自动判定切分位置 | 保证每段语义相对完整 | 计算成本高、依赖模型性能 |
| 百炼等 SaaS 的“智能切分” | 借助大模型判断最佳分段位置 | 效果通常较为理想 | 不透明、稳定性与可控性有限 |
推荐做法
使用 langchain.text_splitter 中的 RecursiveCharacterTextSplitter（递归+分隔符组合）：
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=500, chunk_overlap=100,
separators=["\n\n", "\n", ".", " ", ""]
)
chunks = splitter.split_text(your_text)
坑点
- chunk 过短 → 语义表达不完整
- chunk 过长 → embedding 被稀释，token 易溢出
- overlap 需合理控制，100 左右通常比较稳妥
小提示：如果你的文档格式相对固定（如 PDF 中带有清晰标题结构），建议优先采用“基于分隔符”策略，再叠加递归切分；若为无结构文本（如聊天记录或自由正文），推荐使用智能语义切分或百炼等 SaaS 接口。
常见问题
Q：chunk_size 设置为多少比较合适？
A：通常设为 500 或 1000，具体取决于 embedding 模型的最大输入长度（例如 bge-base-zh 支持 512 token）。建议先做小规模测试：若召回片段语义缺失则适当调大，若 token 溢出则相应调小。
Q：重叠（overlap）对检索效果有什么影响？
A：重叠能够避免关键信息落在两段边界而被遗漏，但过度重叠会增加冗余和存储开销。一般建议重叠设为 chunk_size 的 10%~20%（如 500 字时取 50~100）。
2. 向量生成（embedding）
目标
将文本片段转化为模型可理解的向量表示（embedding），从而进入语义空间进行相似度计算。
常见 embedding 模型
| 模型名 | 维度 | 语言 | 优势 |
|---|---|---|---|
text-embedding-ada-002（OpenAI） | 1536 | 英文/中英混合 | 商用级稳定性 |
bge-base-zh / bge-large-zh | 768/1024 | 中文优化 | 免费、可本地部署 |
text2vec 系列（阿里） | 768 | 中文为主 | 多任务表现均衡 |
e5-mistral（英文/多语） | 1024 | 多语种 | 零样本检索效果出色 |
示例代码
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("bge-base-zh")
emb = model.encode("鼠标断连怎么解决")
小提示：使用 BGE 模型时，建议在文本前添加前缀："为这个句子生成表示以用于检索相关文档：xxxx"，可显著提升检索效果。
常见问题
Q：中文场景下哪个模型表现最好？
A：推荐 bge-large-zh（1024 维）或 bge-base-zh（768 维），效果接近商用模型且免费开源。如果追求极致性能且预算充足，可搭配 OpenAI ada-002 使用。
Q：向量维度越高效果越好吗？
A：不一定。高维度能表达更丰富的语义信息，但存储和计算成本也更高。768 维已能满足大多数应用场景，1024 维适合对精度要求极高的任务。
3. 向量库选择（存储+召回）
目标
将 embedding 存入支持快速近似搜索的数据库中，便于后续查询与召回。
常见库
| 库名 | 特点 | 本地部署 | 检索速度 |
|---|---|---|---|
| FAISS | 最轻量级，Python 接口高效 | ✅ | 快速 |
| Milvus | 企业级方案，支持高并发 | ✅ | 分布式性能优秀 |
| Chroma | 与 Langchain 生态深度集成 | ✅ | 简单易用 |
| Wea viate / Qdrant | 支持多种索引类型 | ✅ | 灵活可扩展 |
示例：FAISS 本地构建
import faiss
import numpy as np
index = faiss.IndexFlatIP(768) # 余弦相似度
index.add(np.array([vec1, vec2, vec3])) # vec 为 np.array 格式的向量
D, I = index.search(np.array([query_vec]), top_k)
小提示：若数据量在百万级以内且追求部署简便，FAISS 足够胜任；若需要多机分布式或实时写入能力，建议选择 Milvus 或 Qdrant。
常见问题
Q：向量库如何支持实时更新？
A：FAISS 重建索引相对繁琐，Milvus、Qdrant 原生支持动态插入和删除。如果业务中数据变动频繁，推荐选用后两者。
Q：检索速度与精度如何平衡？
A：使用 IVF（倒排文件）或 HNSW 索引可加速检索，但会损失一定精度。通常先用 IndexFlatIP 保证精度，数据量大时再切换到 IndexIVFFlat 并调参优化。
4. 检索策略：向量、关键词、混合召回
目标
提升召回的准确率与覆盖率，兼顾精度与召回广度。
召回方式对比
| 策略 | 原理 | 优点 | 风险 |
|---|---|---|---|
| Dense 向量检索 | 通过 embedding 比对语义相似度 | 抗表达差异能力强 | 可能召回无关内容 |
| Keyword（BM25） | 基于关键词精准匹配 | 准确度高 | 不支持同义或变形表达 |
| Hybrid（混合检索） | 两者结合 + 融合评分 | 精度与召回均衡 | 实现复杂度较高 |
小提示：混合召回的核心思路是“关键词召回不够全面 → 靠语义来补充；语义召回过于宽泛 → 靠关键词来兜底”。
常用组合
关键词召回 top30 + 向量召回 top30 → 合并 → rerank top10
常见问题
Q：如何融合 BM25 和向量检索的分数？
A：可采用加权求和（如 0.5×BM25_score + 0.5×cosine_sim），或使用 Reciprocal Rank Fusion（RRF）方法：score = 1/(k + rank)，k 通常取 60。
Q：混合检索的 top_k 如何设置？
A：建议向量和关键词各自取 top30~50，合并后交由 reranker 排序，最终输出 top5~10。
5. Rerank 排序（二次排序）
目标
提升最终召回片段的相关性排序，有效降低误召回风险。
推荐模型
| 名称 | 原理 | 优势 |
|---|---|---|
bge-reranker-base | 双句相似度评分 | 中文支持好，性能稳定 |
Cohere Rerank | 商用 API | 效果强劲 |
cross-encoder/ms-marco | 多语言 | 开源可用 |
示例伪代码
score = reranker(query, [chunk1, chunk2, chunk3])
ranked = sorted(zip(score, chunks), reverse=True)
小提示：Rerank 阶段通常只处理 top20~30 的候选片段，以免计算量过大。若硬件资源有限，可使用 bge-reranker-base 在 CPU 上运行。
常见问题
Q：必须使用 reranker 吗？
A：不强制，但强烈推荐。混合检索后直接取 topN 仍可能混入不相关片段，reranker 能显著提升最终答案质量。
Q：reranker 模型如何量化性能？
A：可使用 NDCG@k 或 MRR 指标衡量，实际效果也可通过人工评估 top5 中相关段落占比来定性判断。
6. Prompt 拼接策略（上下文注入）
目标
将检索到的知识片段与用户问题有效组织成 Prompt，交付给 LLM 生成回答。
模板示例
你是某品牌客服助手，以下是产品说明文档内容：
【知识片段】
1. 鼠标若断连，请检查电量或更换接收器
2. 鼠标灯不亮通常为电池电量低
用户提问：
鼠标今天怎么又断连了？
请基于上方知识内容回答。
控制点
- 控制 token 长度：过多片段会导致 LLM 截断
- 使用
CONTEXT_WINDOW = 3500限制拼接字数 - 多段知识片段建议用编号或分隔符
---，降低混淆风险
常见问题
Q：prompt 中知识片段的数量和顺序如何安排？
A：按 reranker 得分降序排列，数量控制在 3~5 段，总 token 不超过模型上下文窗口的 60%（留出答案生成空间）。
Q：拼接时如何避免模型忽略某些片段？
A：使用清晰编号和分隔符，并在 system prompt 中强调“请按知识片段顺序依次考虑”。也可在每个片段前添加“片段1：”等标记。
7. 检索失败处理机制（没命中咋办）
目标
确保系统在未命中知识时，不答错、不编造、不误导用户。
建议处理方式
| 情况 | 策略 |
|---|---|
| 没有任何召回 | 给 LLM 明确提示：“未检索到相关知识，直接回答‘暂未收录该问题’” |
| 命中不确定内容 | 引入置信度判断逻辑（低于阈值则不展示） |
| 用户可能询问不支持的功能 | 在知识库中预先加入“该设备不支持XX”的明确表述，防止模型误答 |
小提示：置信度阈值可通过实验确定，例如将 reranker 得分低于 0.3 的片段直接丢弃。同时建议在 prompt 中设定固定的 fallback 回答，避免模型自行编造。
常见问题
Q：如何定义“不确定内容”？
A：可设定双阈值策略：高阈值（如 0.7）以上直接使用，低阈值区间（如 0.3~0.7）时在 prompt 中标注“以下片段可能相关，请谨慎参考”，低于 0.3 则直接丢弃。
Q：如果知识库确实没有答案，但模型坚持回答怎么办？
A：在 system prompt 中明确约束：“若知识库中无相关信息，必须回答‘抱歉，这个问题我暂时无法回答’”，并配合 logits 拦截或后处理规则进行兜底。
掌握以上七大模块，你就能构建一个兼具召回精度与回答可靠性的 RAG 知识库系统。从文档切分策略到失败兜底机制，每一步都留有优化空间，建议先在少量数据上验证效果，再逐步扩展至生产环境。