RAGFlow 里“变慢”至少有两种：一种是文档上传后长时间停在解析中，另一种是提问后回答迟迟不出来。两条路径共用同一台机器的资源，但堵点位置完全不同——前者卡在文档入库任务，后者卡在召回与生成。判断顺序建议是先看解析任务有没有堆积，再看单次问答的耗时落在哪一段，最后才考虑调参数和拆库。下面这些观察点都能在页面状态、任务列表、容器日志和命令行里看到，不需要额外工具。

文档量上来后变慢，通常先怀疑解析任务排队，而不是先改检索参数。可以先看知识库文档列表里“解析中”的任务数量和持续时间，再在问答侧分别记录召回耗时与生成耗时。如果解析任务清空后问答仍然慢，瓶颈在检索或生成；如果停掉上传后问答立刻恢复，更像是资源争抢或队列挤压。参数调整和拆库都放在确认瓶颈位置之后做。

先分清是上传解析慢还是提问变慢，两者不是一回事

把两条路径的延迟混在一起判断，很容易得出错误结论：既改了解析配置，又动了召回条数，最后不知道是哪一项起了作用。先分别建立两个观察点。

• 解析任务：知识库详情页的文档列表，每行会显示解析状态（待解析 / 解析中 / 已完成 / 失败）和进度；如果部署里跑着任务执行器容器，日志中会有对应文档的分片处理记录。
• 问答响应：聊天页面上回答出现的总时间，配合后端日志里“召回 / 检索”与“生成 / LLM 调用”两段的时间戳。

判断解析高峰是否影响问答：先对同一个问题连续问两三次，记下大致耗时区间；然后把新的上传暂停一段时间（不删任务，只是不再投喂新文档），等已经排队的任务跑完，再用同一个问题问一次。停掉上传后问答明显恢复，说明是资源争抢或队列挤压；恢复不明显，瓶颈更可能在检索或生成侧。注意向量库和数据库在解析期间也有写入，停掉上传后不会立刻安静，通常要等一段时间才稳定。

看解析任务是不是在排队，一次只放一批文档进去

解析慢的一个常见表现不是单个文档处理久，而是任务在排队。观察方式是看文档列表里同时处于“解析中”的行数，以及最早一条任务的开始时间到当前时间的间隔。如果长期有大量文档停在等待状态，说明并发能力已经被打满，此时再加文档只会让等待更长。

分批上传的耗时对比做法：每批上传前记录起始时间，整批变为“已完成”后再记录一次，算出本批的总耗时和单文档平均耗时。

# 上传前记录起点
date
# 本批文档全部变为“已完成”后记录终点
date

建议把一次投放量从“全部一起传”改成每次几个到十几个，具体数量按机器规格定，并记录每批的文档数、总耗时、失败数量。两批之间的单文档平均耗时如果差距明显，排队就是主因之一。

解析相关可调项通常在知识库的解析设置里，包括分块方法（chunk method）、chunk token 大小、分隔符，以及是否启用 OCR 或版面分析；任务并发、执行器数量的配置一般在 docker 环境变量或服务配置文件里，具体位置需要结合你的部署版本确认。单纯压低并发不是性能方案，但可以避免解析把机器占满、连带把问答一起拖慢。

在检索阶段记录命中条数与耗时，区分召回慢还是生成慢

知识库里一般有检索测试入口，输入一个问题就能看到命中的分块、相似度分数和命中条数，这里能观察到召回一侧的行为。问答页面或接口日志里通常还能看到检索耗时与模型生成耗时两段，先确认这个拆分是否在你的部署里存在，再往下判断。

命中条数与耗时的关系比较直接：命中条数从几条涨到几十条，召回时间通常会上升，因为向量比对和重排的计算量变大了。如果命中条数不多、召回也短，但整体还是很慢，问题多半在生成侧——模型本身响应慢、输出很长、或者上下文塞得太满。

生成阶段耗时偏长的判断方式，是从日志里找模型调用的开始与结束时间戳，或者从回答首字出现的时间推算：

# 按时间查看某个服务最近的日志
docker logs `--timestamps` <服务名> 2>&1 | tail -n 200

还要区分“首字慢”和“输出慢”。首字慢通常是上下文过长或模型排队；输出慢多是生成长度大、模型吞吐有限。两者对应的调整方向不同，前者调召回和上下文，后者调提示词与输出约束。

减少召回条数和分块数量，观察响应时间的变化

可动的参数大致在这几处：知识库解析设置里的 chunk token 大小（直接影响分块数量）、助理或检索设置里的召回条数（top N）与相似度阈值、以及是否启用重排模型。不同版本界面位置略有差异，通常在知识库设置与助理设置的检索部分。

每次只改一项，并留下记录，否则无法归因。可以用一张简单的表：

日期    改动项      旧值   新值   同问题耗时(连问3次)   命中条数
----    --------    ----   ----   ------------------   --------
        top N       10     5      __ / __ / __         __
        chunk size  默认   增大   __ / __ / __         -
        rerank      开     关     __ / __ / __         -

判断调整是否有效，用同一个问题、相近的时间段、连续多次提问比较耗时区间，不要拿前后两次的单点数字下结论。缩小召回条数后耗时区间没有变化，说明瓶颈不在召回；耗时变短但回答质量下降明显，说明砍掉了必要上下文，可以退回原值，改用重排来筛选，而不是一味减少条数。

机器资源到顶时，先看内存和磁盘，再看要不要拆库

资源排查从容器和主机两头看：

docker stats `--no-stream`
docker compose ps
free -h
df -h
du -sh /path/to/ragflow-data/* | sort -h

内存不足时，解析和检索都会被拖慢，典型表现是容器被反复重启、进程被系统杀掉，或者交换分区被大量使用。磁盘方面，增长主要来自原始文档、解析后的分块文本、向量索引，以及各组件自身的存储（关系数据库、对象存储、日志文件）。先确认是哪一类在涨，再决定清理、扩容还是迁移存储。

按主题拆库适用的场景：单个库里文档数量很大；检索时经常跨多个主题命中、需要拉高召回条数才能找到答案；或者一个库的解析排队明显拖住另一个业务的问答。拆完之后每个库的检索范围变小，召回条数可以调低，解析任务也更细粒度，一个库排队不至于影响另一个库的在线问答。代价是跨库提问要分别检索再合并，管理和维护成本上升，所以建议先确认瓶颈来自检索范围和任务相互影响，而不是机器本身已经到顶。