ragflow知识库搭建教程

很多人接 RAGFlow 是照着界面点一遍，跑通了 demo，一上真实文档集就发现答非所问、切片切碎、检索召回忽高忽低。问题往往不在模型，而在进料和参数没按工程做法走。这篇按企业落地的顺序，从环境准备到上线后的观察指标给一份可照着执行的大纲，并说明哪些场景下这套做法不适用。

很多人接 RAGFlow 是照着界面点一遍，跑通了 demo，一上真实文档集就发现答非所问、切片切碎、检索召回忽高忽低。问题往往不在模型，而在进料和参数没按工程做法走。这篇按企业落地的顺序，从环境准备到上线后的观察指标给一份可照着执行的大纲。

先说明适用范围：下面这套做法适合文档量中等、有明确业务域、且能安排人做评测的企业场景。如果只是两三个人想拿一堆杂七杂八的文件试水，可以只取其中的清洗和评测两步，其余简化。哪些场景整体不适用，最后一节单独讲。

先定范围：哪些文档该进知识库

开库前最容易犯的错，是把公司所有能找到的文档一股脑传进去。制度、产品介绍、客服聊天记录混在一个库里，检索时它们会互相污染：问产品参数，命中的却是报销规定。建议先只选一个业务域跑通全流程，确认效果后再逐个域往里加。

• 按用途分三类：制度规范、产品资料、客服问答，混在一起会让检索互相污染，建议先只上一个域跑通
• 进料前做一轮清洗：扫描件先走 OCR、表格单独抽、页眉页脚和目录页删掉，脏数据进库后很难靠调参救回来
• 确认权限边界：谁能建库、谁能上传、谁能问答，企业场景里文档本身就是资产，这些规则要在开库前定
• 每份文档留一个来源标记，方便后面评测时判断命中对不对

解析与切片：决定成败的一步

解析方式选错，后面怎么调检索都费劲。说明书、合同这类长结构化文档，不要一刀切成固定字数，优先保留标题层级和表格结构；而聊天记录、短问答这种本来就没有层级的文本，硬套结构反而会切碎。

1. 先取基线切片长度先取一个中间值，把同一批文档按这个配置跑一遍，作为对比起点。
2. 同批问题对比档位拿同一组问题，对比两三个切片档位，重点看「答非所问」和「答一半」两种情况的变化趋势，再定稿。
3. 区分改动代价换嵌入模型只需重跑向量，换切片策略必须重建索引，这两件事成本不一样，排期时要分开看。
4. 锁定配置定稿后把切片长度、重叠量、解析方式记下来，后面每次改动都对照这份记录。

切片和嵌入模型要一起调，不要单独改一个就下结论。另外，向量库重建期间问答请求会变慢，建议安排在低峰时段，或者临时切到只读的旧索引。

检索评测：别靠感觉判断好不好

「感觉答得还行」不能作为上线依据。准备一组真实问题，二十条起步，每条写清期望命中的文档名，跑一遍记录命中情况，这就是你的基线。每次改动配置，都拿同一批问题重跑，结果记成表，不要只记住最后一次表现，否则出问题无法回滚。

• 召回不够就先加大召回条数看趋势，够了但答案乱，再考虑加重排，两件事分开验证
• 同一批问题在不同切片和嵌入配置下各跑一遍，把结果记成表
• 每组问题标注文档类型，方便定位是某类文档拖后腿还是整体不行
• 评测用的问题不要拿写文档的人自己编，找实际用的人提供

上线后的并发、超时与日志

索引构建和问答请求抢资源是常见事故来源。批量灌库要限并发并做失败重投，避免中断后从头再来；索引重建尽量和业务高峰错开排期。问答链路要设超时，并提前约定降级行为：检索超时是返回纯模型回答，还是直接提示重试，不要等生产上出事再拍板。

日志四要素

问题、召回文档 ID、耗时、是否降级，缺一项后续排查只能靠猜

失败重投

灌库任务要能按文档粒度重试，而不是整个批次重来

降级策略

检索不可用时的兜底行为，写在配置里而不是靠人临场决定

延迟基线

上线前先量一遍正常水平，后面才有对比依据

成本与延迟基线可以到 /tools/speed-test 先量一遍，心里有个数再定告警阈值。文档量、模型调用量带来的实际开销，可以到 /price-watch 核对当时的数字，别拿印象估算容量规划。

什么情况下这套流程不适用

• 文档量极小的场景，人工维护一个问答对照表可能比搭 RAG 更快，别为了技术而技术
• 强一致要求的场景，比如合同条款逐字引用，纯检索问答有编造风险，必须配人工确认环节
• 纯图片或视频为主的资料，先解决多模态解析问题，再用本文的切片与评测流程，顺序反了会白折腾
• 如果业务问题随时在变、没有稳定文档可依托，先梳理知识本身，再考虑上知识库

判断标准很简单：如果你的场景里「换个说法问同一件事」很常见，知识库值得做；如果问题基本固定、答案也固定，用结构化查询或人工清单更省事。另外，涉及法务、财务结论的输出，无论检索做得多好，都要保留人工复核这一步。