deepseek rag 增强检索知识库系统，从零开始的完整步骤和常见问题

很多人第一次做 RAG，卡在不是不会调模型，而是不知道先做哪一步：文档怎么切、向量存哪、检索结果怎么塞进提示词、答得不好该改哪一段。这篇按搭建顺序拆成几步，每步给出可执行的检查点，最后列几组高频故障和对应动作。文中不写死任何数字，价格和模型规格到站内对应页面按当时数据核对。

很多人第一次做 RAG，卡的不是不会调模型，而是不知道先做哪一步：文档怎么切、向量存哪、检索结果怎么塞进提示词、答得不好该改哪一段。这篇按搭建顺序拆成几步，每步给一个可以停下来检查的点，跑通了再往下走。

文中不写死任何数字，价格和模型规格到站内对应页面按当时数据核对。整套链路建议从小样本开始，别一上来就清洗全量数据，否则很容易在进料阶段耗掉全部精力。

先把环境和密钥跑通，别急着做检索

第一步只做一件事：确认你的程序能向 DeepSeek 发一次最小的对话请求，拿到正常回复。这一步没通就去写切片脚本，后面出了问题分不清是网络、密钥还是检索逻辑。接口地址和参数写法以站内兼容说明为准，同样的调用有时要换 Base URL。

1. 发一次最小请求只发一句固定问题，打印完整返回。能拿到回复说明密钥和网络都没问题，把返回结构记下来，后面解析用得上。
2. 单独选向量模型向量模型和对话模型是两条线，别默认沿用同一个供应商。选型看中文语义效果、调用稳定性和批量入库速度，到站内模型资料库对照。
3. 准备小样本先拿十来份自己熟悉内容的文档跑通全链路，因为你知道正确答案长什么样，召回对不对一眼能看出来。

文档进料与切片：决定后面能不能检到

检索效果的上限在入库时就定了。这一阶段最容易出问题的是脏数据：页眉页脚、断行、表格错位、扫描件没做 OCR。先清洗再切，不要指望模型在检索阶段帮你补。

• 去页眉页脚和重复水印，合并被硬换行打断的句子
• 表格单独抽成结构化文本，别和正文混在一起切
• 扫描件先过 OCR，识别完抽查几页，乱码多的整份丢掉重做
• 按语义边界切，标题、段落、条款各自成片，别按固定字数硬切
• 每片带上来源标题和位置信息，回答才能标出处

入库后先别急着接对话，抽十来个你确定答案在库里的问题做召回自测。看命中的片段里有没有正确内容，命中不了就回头改清洗和切片，不要往下走。这一步的判断标准很直接：正确片段在不在召回结果里。

检索与拼装：把片段变成模型能用的上下文

召回条数和上下文长度是一对取舍。先小后大，条数多了会稀释关键信息，token 成本也跟着涨。判断标准是：加条数之后答对率有没有提升，没提升就退回上一档。

提示词里要明确写「只依据给定资料回答，资料没有就说没有」，这条能明显压住编造。把来源标识一起喂进去，回答里才好标出处。拼装模板可以参考站内提示词相关文章，别自己从零憋。

召回条数

先小后大，用答对率验证每一步增量

上下文长度

受模型窗口限制，超了要截断或分批

来源标识

片段附带的标题和位置，用来标引用和排查

拒答规则

资料里没有就明确说没有，减少编造

系统提示：只依据下面资料回答；资料没有覆盖的内容，直接说明未找到，不要推测。
资料片段：
[来源1] ...
[来源2] ...
用户问题：...

上线前的验证清单

上线前别只看几个demo问题答得漂亮，要跑一批有标准答案的问题，同时记录延迟和 token 用量。检索和生成两段分别计时，哪段慢一目了然，后面调优有据可依。

调优时按排查顺序走：先看召回里有没有正确片段，有就看拼装和提示词，都对再看模型输出。跳着改最容易来回折腾。价格和模型规格到站内页面按当时数据核对，别凭印象选型。