原文链接Dify 知识库 RAG 实战把 100 页手册变成会回答的 AI上一篇《30 分钟跑通 DifyDocker 一键部署5步上线首个AI应用》把环境搭起来之后紧接着的问题很实际公司那本一百来页的产品手册怎么让它自己回答问题把整本手册塞进 Prompt 不现实——上下文装不下装得下也贵。Dify 知识库的思路是不让模型死记而是把文档切成小段提问时只把最相关的几段递给它。这篇是我在本地 Dify 上完整走一遍的记录建库、传文档、分段、召回、问答附上有无知识库的对比以及关键词、向量、重排三套召回策略的实测数据。一、RAG 到底改了哪一步RAG 不是一步操作是三件事串起来的流水线索引 → 召回 → 生成。索引把 PDF、Word、Markdown 切成段建成可检索的库召回按问题捞最相关的几段生成则把这几段塞进 Prompt让模型照着原文答。三段里最容易出问题的是召回。遇到“知识库答非所问”第一反应往往是模型不行但多数时候那轮根本没把对的段落捞出来。微软研究院在《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》里做过对照同一个模型喂对上下文之后准确率能提升 20% 以上。所以排优先级先确认“正确的那段话能不能被找到”再考虑换模型。二、先建一个能被检验的知识库测试文档我用的是《星火会议纪要系统》手册五节支持的音频格式、处理时长、方言支持、私有化显存、说话人区分。它短但事实点密集每个问题都有唯一正确答案方便判断召回对不对。上传后 Dify 给出通用分块预览分隔符\n\n、最大长度 1024、重叠 50切成 6 段。重叠 50 的作用是防止一句话刚好被切断导致召回时丢上下文。分段方式 Dify 提供三种通用分块、父子分段Parent-Child、QA 分段。手册、制度这类连续叙述的文档用通用分块就够只有原始材料本身就是问答对时才值得切 QA。本次操作只新增自己的测试文档、数据集和应用没动别人已有的任何配置。三、召回测试先回答“找得到吗”文档索引完成先单独验检索别急着开聊天窗口。四个问题跑下来命中的段落都对得上问题命中间片关键证据星火系统支持哪些音频格式Chunk-02支持 wav、mp3、m4a单个文件上限 500MB处理 1 小时音频大约需要多久Chunk-03端到端约需 8–12 分钟这套系统支持粤语吗Chunk-04内置普通话与粤语两种识别引擎私有化部署最低需要多少显存Chunk-05显存不低于 16GB推荐 24GB第一个问题命中 Chunk-02wav、m4a、mp3、500MB 几个关键词被高亮标出这一步只回答“找不找得到”。排得准不准第五节用数据说。四、有没有知识库答案差多少对照用的是两个配置完全一样的聊天助手唯一区别是一个关联了上面那个知识库。同样问“星火系统支持哪些音频格式”关联知识库的那个答 wav、mp3、m4a末尾挂着引用点开就是 manual.md 里的原文。没关联的那个直接把“星火系统”认成了科大讯飞星火洋洋洒洒列了一堆 PCM、WAV、MP3、M4A、AMR、OPUS甚至开始怀疑你说的是不是 Apache Spark。字数不少但没有一个字跟这本手册有关。四个问题放一起看问题带知识库不带知识库音频格式wav / mp3 / m4a带引用误指科大讯飞星火列出一堆通用格式1 小时音频耗时8–12 分钟带引用模型泛化无稳定答案粤语支持支持需选粤语模型带引用模型泛化无稳定答案私有化显存最低 16GB带引用模型泛化无稳定答案显存那道也一样带知识库时边界给得很干脆两组答案的差距不在模型聪不聪明而在它有没有被圈在那几段原文里。五、关键词、向量、重排三套召回差多少到第四节为止检索靠的是关键词倒排索引一个模型都不用装。这条路能跑通但它有个没被检验的前提用户的问法得跟原文用词对得上。于是换个做法重跑一遍把 bge-m3 向量模型和 bge-reranker-v2-m3 重排模型接进 Dify。两个模型都跑在本机 127.0.0.1:8501走 OpenAI 兼容端点。同一份手册再建一个高质量知识库索引方式选 High QualityEmbedding 指定 bge-m3还是那四个问题三套召回策略的结果召回策略依赖Top1 命中Top1 得分经济关键词倒排无模型1/4无得分高质量·向量bge-m3Embedding4/4余弦 0.61–0.82混合检索重排向量关键词Rerank4/4相关性 0.95–1.00真正的差别在第三题。关键词模式下正确段落被排在第 3 位排第一的是标题段落——找得到但排不对。换成 bge-m3 向量检索它以 0.71 的余弦相似度直接站到第一再叠上 bge-reranker-v2-m3 重排相关性 0.95混进来的音频格式段落被压到 0.03把高质量知识库接进聊天助手四个问题同样全对且都带引用有个小插曲值得记显存那道题第一次答的是“未在文档中提及”重试一次就对了。召回层很稳生成层仍有随机性业务上要留兜底。怎么选看文档和问法场景推荐模式原因问法多变、语义相近高质量向量Embedding 能理解同义改写手册/制度、关键词明确经济倒排零模型依赖、启动快追求排序精度混合检索重排Rerank 把最相关片段顶到最前六、能跑通不等于能上生产链路跑通之后还有三件事值得补重排调参本次用的是 bge-reranker-v2-m3Top1 相关性从 0.61–0.82 提到 0.95 以上。TopK 和阈值得按自己的文档调别照抄。分段调优最大长度、重叠、分隔符都跟着文档类型走代码文档和制度文档的最优值不一样。评估集固定 20–50 条真实问题做回归每次改分段、换模型都跑一遍否则很容易“越改越差”自己还没察觉。提示词这块我用的模板很短请根据以下上下文回答用户问题。如果上下文中没有相关信息请回答“未在文档中提及”。上下文{{#context#}}用户问题{{#query#}}回答时请保持简洁并引用上下文中的关键信息。它只做一件事把模型限定在给定上下文里上下文里没有就直说没有。要不要这么严取决于场景制度问答、客服这类事实型场景越紧越好开放创作就得留空间。写在最后一本手册能不能被问住跟文档厚度关系不大跟模型贵不贵关系也不大。三段式跑通、每一层都拿数据验过答案才有底召回决定找不找得到重排决定排得准不准生成层还得留容错。留个问题你手里的哪类文档最先该被做成 RAG 知识库欢迎在评论区写出来。如果这篇对你有用建议收藏起来当实操手册顺手点个「在看」转发给正在折腾 Dify 的同事。 Dify 知识库 RAG 实战：把 100 页手册变成会回答的 AI
原文链接Dify 知识库 RAG 实战把 100 页手册变成会回答的 AI上一篇《30 分钟跑通 DifyDocker 一键部署5步上线首个AI应用》把环境搭起来之后紧接着的问题很实际公司那本一百来页的产品手册怎么让它自己回答问题把整本手册塞进 Prompt 不现实——上下文装不下装得下也贵。Dify 知识库的思路是不让模型死记而是把文档切成小段提问时只把最相关的几段递给它。这篇是我在本地 Dify 上完整走一遍的记录建库、传文档、分段、召回、问答附上有无知识库的对比以及关键词、向量、重排三套召回策略的实测数据。一、RAG 到底改了哪一步RAG 不是一步操作是三件事串起来的流水线索引 → 召回 → 生成。索引把 PDF、Word、Markdown 切成段建成可检索的库召回按问题捞最相关的几段生成则把这几段塞进 Prompt让模型照着原文答。三段里最容易出问题的是召回。遇到“知识库答非所问”第一反应往往是模型不行但多数时候那轮根本没把对的段落捞出来。微软研究院在《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》里做过对照同一个模型喂对上下文之后准确率能提升 20% 以上。所以排优先级先确认“正确的那段话能不能被找到”再考虑换模型。二、先建一个能被检验的知识库测试文档我用的是《星火会议纪要系统》手册五节支持的音频格式、处理时长、方言支持、私有化显存、说话人区分。它短但事实点密集每个问题都有唯一正确答案方便判断召回对不对。上传后 Dify 给出通用分块预览分隔符\n\n、最大长度 1024、重叠 50切成 6 段。重叠 50 的作用是防止一句话刚好被切断导致召回时丢上下文。分段方式 Dify 提供三种通用分块、父子分段Parent-Child、QA 分段。手册、制度这类连续叙述的文档用通用分块就够只有原始材料本身就是问答对时才值得切 QA。本次操作只新增自己的测试文档、数据集和应用没动别人已有的任何配置。三、召回测试先回答“找得到吗”文档索引完成先单独验检索别急着开聊天窗口。四个问题跑下来命中的段落都对得上问题命中间片关键证据星火系统支持哪些音频格式Chunk-02支持 wav、mp3、m4a单个文件上限 500MB处理 1 小时音频大约需要多久Chunk-03端到端约需 8–12 分钟这套系统支持粤语吗Chunk-04内置普通话与粤语两种识别引擎私有化部署最低需要多少显存Chunk-05显存不低于 16GB推荐 24GB第一个问题命中 Chunk-02wav、m4a、mp3、500MB 几个关键词被高亮标出这一步只回答“找不找得到”。排得准不准第五节用数据说。四、有没有知识库答案差多少对照用的是两个配置完全一样的聊天助手唯一区别是一个关联了上面那个知识库。同样问“星火系统支持哪些音频格式”关联知识库的那个答 wav、mp3、m4a末尾挂着引用点开就是 manual.md 里的原文。没关联的那个直接把“星火系统”认成了科大讯飞星火洋洋洒洒列了一堆 PCM、WAV、MP3、M4A、AMR、OPUS甚至开始怀疑你说的是不是 Apache Spark。字数不少但没有一个字跟这本手册有关。四个问题放一起看问题带知识库不带知识库音频格式wav / mp3 / m4a带引用误指科大讯飞星火列出一堆通用格式1 小时音频耗时8–12 分钟带引用模型泛化无稳定答案粤语支持支持需选粤语模型带引用模型泛化无稳定答案私有化显存最低 16GB带引用模型泛化无稳定答案显存那道也一样带知识库时边界给得很干脆两组答案的差距不在模型聪不聪明而在它有没有被圈在那几段原文里。五、关键词、向量、重排三套召回差多少到第四节为止检索靠的是关键词倒排索引一个模型都不用装。这条路能跑通但它有个没被检验的前提用户的问法得跟原文用词对得上。于是换个做法重跑一遍把 bge-m3 向量模型和 bge-reranker-v2-m3 重排模型接进 Dify。两个模型都跑在本机 127.0.0.1:8501走 OpenAI 兼容端点。同一份手册再建一个高质量知识库索引方式选 High QualityEmbedding 指定 bge-m3还是那四个问题三套召回策略的结果召回策略依赖Top1 命中Top1 得分经济关键词倒排无模型1/4无得分高质量·向量bge-m3Embedding4/4余弦 0.61–0.82混合检索重排向量关键词Rerank4/4相关性 0.95–1.00真正的差别在第三题。关键词模式下正确段落被排在第 3 位排第一的是标题段落——找得到但排不对。换成 bge-m3 向量检索它以 0.71 的余弦相似度直接站到第一再叠上 bge-reranker-v2-m3 重排相关性 0.95混进来的音频格式段落被压到 0.03把高质量知识库接进聊天助手四个问题同样全对且都带引用有个小插曲值得记显存那道题第一次答的是“未在文档中提及”重试一次就对了。召回层很稳生成层仍有随机性业务上要留兜底。怎么选看文档和问法场景推荐模式原因问法多变、语义相近高质量向量Embedding 能理解同义改写手册/制度、关键词明确经济倒排零模型依赖、启动快追求排序精度混合检索重排Rerank 把最相关片段顶到最前六、能跑通不等于能上生产链路跑通之后还有三件事值得补重排调参本次用的是 bge-reranker-v2-m3Top1 相关性从 0.61–0.82 提到 0.95 以上。TopK 和阈值得按自己的文档调别照抄。分段调优最大长度、重叠、分隔符都跟着文档类型走代码文档和制度文档的最优值不一样。评估集固定 20–50 条真实问题做回归每次改分段、换模型都跑一遍否则很容易“越改越差”自己还没察觉。提示词这块我用的模板很短请根据以下上下文回答用户问题。如果上下文中没有相关信息请回答“未在文档中提及”。上下文{{#context#}}用户问题{{#query#}}回答时请保持简洁并引用上下文中的关键信息。它只做一件事把模型限定在给定上下文里上下文里没有就直说没有。要不要这么严取决于场景制度问答、客服这类事实型场景越紧越好开放创作就得留空间。写在最后一本手册能不能被问住跟文档厚度关系不大跟模型贵不贵关系也不大。三段式跑通、每一层都拿数据验过答案才有底召回决定找不找得到重排决定排得准不准生成层还得留容错。留个问题你手里的哪类文档最先该被做成 RAG 知识库欢迎在评论区写出来。如果这篇对你有用建议收藏起来当实操手册顺手点个「在看」转发给正在折腾 Dify 的同事。