deepseek rag 增强检索知识库系统，第一次上手最容易卡在这三件事

搜 deepseek rag 增强检索知识库系统的人，多半已经跑通过一次 chat 接口，真正开工才发现麻烦全在别处：文档切多碎、向量用哪家、检索回来的片段怎么塞进上下文。这篇不铺概念，按你动手的顺序排一遍，每段给一个能自查的标准。

搜 deepseek rag 增强检索知识库系统的人，通常已经跑通过一次 chat 接口。聊几句、调个参数、看着流式吐字，都挺顺。真动手搭知识库才发现，麻烦全在别处：PDF 抽出来是一堆乱码，切完的片段长得离谱，检索回来的东西答非所问。模型本身反倒是最省心的那一段。

这篇按你实际动手的顺序排：进料、检索、拼上下文，最后给你一套跑通后的自查动作。每段只回答两件事——先干什么，卡住先查哪。不铺概念，也不承诺效果，因为你的资料长什么样，决定了这套东西能到什么程度。

先把进料管住，别急着写检索

我见过太多人第一天就写向量检索代码，第二天开始怀疑是模型不行。实际用下来，八成问题在进料这一步，文档进去的时候就已经烂了。扫描版 PDF 抽出来是空白或者乱序，表格被压成一行串在一起的数字，页眉页脚混进正文。这些东西喂给谁都没用。

所以第一件事不是调代码，是抽十份最有代表性的文档，把文本导出来人眼读一遍。读得通顺再入库，读不通就去清洗。站内有一份文档清洗清单，可以照着过一遍，比你自己想漏项快。

• 抽出的文本能不能连续读下来，有没有大段空白或乱码
• 表格里的行列关系有没有保留，还是被压成一串数字
• 页眉页脚、页码、水印有没有被当成正文混进去
• 同一份文档重复导入会不会产生大堆重复片段
• 特殊符号、公式、代码块抽出来还认不认得

切片长度和重叠别一上来就定死。先在十来份文档上试两档：一档切得碎一点，一档切得整一点，然后拿几个问题去召回，人眼读片段。切太碎，一句完整的话被劈成两半，模型拿着半句没法答；切太整，一条片段塞进好几个主题，检索命中率反而掉。

元数据这事儿也别省。每段带上来源文件名、标题、章节路径，后面做引用、排查质量问题全靠它。等出了问题你才发现片段没来源，只能从头再导一遍，那才叫白干。

检索这一段，选型比调参更花时间

有个误解得先说清：DeepSeek 在这套链路里只负责后半段，也就是拿到片段之后生成答案。前面的嵌入模型是另一回事，要单独挑。很多人以为接上 DeepSeek 就齐活了，结果检索那一步根本没东西在跑。

混合检索什么时候值得上？看你的资料里数字和专有名词多不多。纯向量对语义相似很敏感，但问到具体型号、订单号这类东西，它经常给你一堆意思相近、字面完全不对的片段。加一路关键词检索把字面命中的捞回来，再合并排序，能救不少。

召回条数先定个保守值。宁可多召回几条让人工读，也别一上来就压到一两条，压到最后你连问题出在召回还是生成都分不清。等基线稳了再往下减。

拼上下文的时候，最容易被忽略的两格

片段拿到了，怎么塞进提示词，这里有两个格子特别容易填错。第一格是约束语。你得明确写「只根据给定片段回答，片段里找不到就说没有」，不然模型会自己补，补得还挺像那么回事，你一时半会儿看不出来。

第二格是片段的分隔和编号。片段之间加清晰的分隔标记，每段标上序号，再要求模型回答时给出引用编号。这样答案对不对，你能顺着编号回去核对原文；不编号，模型说了一段话你根本不知道它是从哪段抄的。

还有个常见误判：以为上下文塞得越多越准。实际是反的，无关片段一多，模型注意力被稀释，还更容易被带偏。上下文长度直接和成本挂钩，塞多少合适，去站内成本计算器按当时的单价估一遍，别凭感觉。

跑通之后先做这三项自查，再谈优化

系统能跑通、能出答案，不代表能用了。先准备十来个你自己知道答案的问题，三种情况都要覆盖：有明确答案的、资料里根本没有答案的、答案分散在三个不同地方的。这三个场景能把大部分毛病逼出来。

1. 先看有没有答不出来的挑一个资料里肯定没有的问题问它，看它是不是老实说没有。硬编答案就说明提示词约束没写到位。
2. 再给失败样本分类答案错了，去翻召回片段。片段里根本没有正确内容，是召回没拿到；片段里有但排在后面，是排序问题；片段明明在前排，答案还是错，才是生成环节的事。
3. 最后回溯源文让模型给出引用编号，顺着编号找到原文那段，看它对不对得上。对不上说明片段编号或者提示词格式有问题。

答案不准的时候，先别急着换模型。上面分类做完，你会发现大头在切片和元数据上——片段切得不对，换再强的生成模型也是拿错料做菜。真要比对不同模型和渠道的实际表现，去站内模型资料库看当时的资料，别凭印象拍板。