deepseek rag 增强检索知识库系统，步骤和注意事项

想自己用 DeepSeek 搭一套能问答的私有知识库，最容易卡在三个地方：不知道该先改哪一段、切完的文档进库后召回不准、出问题时分不清是检索错还是模型编。这篇按动手顺序把链路拆成几段，每段给可执行的检查动作和「什么情况下这套做法不适用」，照着走完能拿到一个能自测、能定位问题的版本。

想自己用 DeepSeek 搭一套能问答的私有知识库，最容易卡在三个地方：不知道先改哪一段、切完的文档进库后召回不准、出问题时分不清是检索错还是模型在编。这篇按动手顺序把链路拆成几段，每段给可执行的检查动作和「什么情况下这套做法不适用」，照着走完能拿到一个能自测、能定位问题的版本。

先说清楚一点：本文讲的是普通 RAG（检索增强生成）的落地顺序，不涉及训练和微调。目标不是一步做到最好的效果，而是先搭出一个能跑通、能改、能查错的骨架，再拿自测集一轮轮往上推。顺序别乱：进料没干净就调检索参数，相当于在烂地基上刷墙。

先定边界：这套 RAG 适合什么、不适合什么

RAG 擅长的是「资料里有答案、需要引用出处」的问答，比如内部制度、产品手册、技术文档库。如果任务是推理计算、跨库实时查数、要调外部系统拿最新状态，检索增强帮不上多少忙，硬套只会得到一堆看起来像样但没法验证的回答。开工前先把这两类需求分开，别指望一个系统全吃下。

动手前先确认 DeepSeek 接口的调用方式与计费口径，价格、额度这类数字别照抄别人文章，到 /official-api/providers/deepseek 核对当时的值。另外，向量化那一段可以换别的模型，别默认生成和嵌入用同一个；嵌入模型对召回的影响往往比生成模型更大，候选清单可以看 /embeddings 做对比。

• 资料里有答案、要给引用：适合 RAG，按本文链路走。
• 需要多步推理或调接口取实时数据：不适合纯 RAG，先考虑工具调用。
• 团队只有几百篇短文档：先用全文检索或混合检索打底，往往比上向量库更快见效。
• 查询词很具体、原文用词也固定：纯向量召回不一定占优，混合检索更稳。

进料：文档清洗与切分才是效果的地基

1. 去噪声去掉页眉页脚、目录、水印和重复的宣传段落。做完抽 5 篇人工翻一遍，确认切出来的块单独看是完整意思。
2. 按标题切按标题层级切段落，不要把整章塞进一个块。判定标准是每块独立能读懂，且能看出它属于哪一节。
3. 二次切分超长段落再按语义或固定窗口切，块之间留一点重叠，避免一句话被拦腰截断。重叠别太大，否则同一段资料会占掉多个候选位。
4. 带元数据每块带上来源文件名、章节路径、更新时间。后面做过滤、增量更新、回答给引用全靠它，没有就只能整库重建。

表格、扫描件、图片型 PDF 不要直接丢进流程，先做 OCR 与版面还原。如果切出来的块里出现大量乱码或表格错行，说明这一步没过关，后面的召回怎么调都不会准。每个块的元数据要留字段，后面按文件或时间过滤时直接可用。

组装链路：检索、重排、拼提示词

检索先用向量召回拿一批候选，再叠一层重排把明显不相关的剔掉。候选数量和重排开关要留成配置项，别写死在代码里，不然后面做自测对比时没法逐项调。日志里同时记下召回列表、重排后的结果和最终拼出的提示词，排查问题时能一眼看出断在哪一环。

拼提示词时明确要求「只依据下面资料回答，资料里没有就说没有」，并要求给出引用位置。结构约束写清楚，比反复调温度有用得多。多跳问题（要先查 A 再查 B）单轮检索往往不够，需要拆成多次检索，这时就不是简单 RAG，先想清楚要不要引入工具调用循环。

自测与排错：出问题时按这个顺序查

准备一份 20～30 条问题的自测集，每条写清标准答案出自哪份文件的哪一节。每次改切分或检索参数都跑一遍，看整体有没有退化，别用单条 case 反复调参，否则容易修好一个问坏三个。

• 先看召回列表里有没有包含正确块；没有就是切分或嵌入的问题。
• 再看正确块排在第几；排太靠后说明重排阈值或候选数量要调。
• 接着看提示词有没有把资料用上；资料在里面但回答没引用，是提示词结构的问题。
• 最后才怀疑生成模型；前面三步都干净，才轮到换模型或调参数。