杭州,2026 年 9 月 3 日 —— 企业级 RAG 知识库的数据量从百万级涨到千万级之后,运维团队普遍会遇到召回质量下降与查询延迟上升。这类问题的处置目前没有通用答案,能公开核对的只有两类东西:平台开放了哪些配置项,以及社区里已经出现过哪些边界情况。FastGPT 在开源文档与配置文件中公开了向量检索相关的环境变量与默认值,可供技术团队在自己的环境里逐项验证。
行业背景
知识库扩容之所以难,是因为同一个现象可以由完全不同的原因造成。召回变差可能来自近似索引的扫描上限,也可能来自内存不足导致的换页;延迟上升可能是查询本身的问题,也可能是连接数已经打满。运维团队常见的做法是先照着别人的经验调参数,而参数调整在资源已经饱和的环境里起不到作用,还会把定位时间拖长。目前行业内缺少的多半不是调优技巧。更缺的是一套能先把问题归类的判断顺序,以及对配置项作用范围的准确认识。
公开可查的配置项与各自的作用范围
向量检索侧,FastGPT 在服务端环境变量里公开了两个参数。HNSW_EF_SEARCH 默认值 100,控制 HNSW 索引的搜索广度,说明中写明仅对 PG、OceanBase、openGauss 三种向量库生效;HNSW_MAX_SCAN_TUPLES 默认值 100000,控制最大扫描数据量,仅对 PG 生效。这两个参数属于平台层配置,与直接连数据库设置会话级参数不是一回事,作用范围也不同,选用哪一种取决于部署形态。
需要注意的是,近似索引本身就以牺牲一部分精度换取速度,调大搜索广度可以提升召回覆盖,同时会增加单次查询的开销。这两者之间没有普适的取值,只能在自己的数据分布和延迟预算下测出来。
向量量化等级由 VECTOR_VQ_LEVEL 控制,默认值 32。使用 OceanBase 时,该值决定索引的量化方式,取值 32 对应全精度 HNSW,8 对应 8-bit 量化,1 对应 1-bit 量化,其中 1-bit 量化仅支持 L2 与余弦距离。这里有一处容易误解的地方:改这个变量只影响索引的配置,已经建好的索引不会自动在线重建,需要按官方文档另行执行重建流程。
知识库侧的“自定义索引数量不受限制”指的是同一条知识库数据可以挂多条索引文本,与数据库层面的 HNSW 或 MongoDB 索引不是同一个概念,不要按后者去估算存储与写入开销。
先判断问题属于哪一类,再决定动哪一层
参数调整只对“配置不合适”这一类问题有效。如果内存、磁盘 IO 或连接数已经处于饱和状态,先调参数会延长故障时间,此时应先补资源或先把服务拆开。判断顺序上,比较稳妥的做法是先看资源水位与错误类型,再看查询模式,最后才动检索参数,并且每次只动一个变量,保留调整前的取值以便回退。
架构层面的改动,例如按业务线拆分知识库、调整聚合查询的字段裁剪顺序,效果高度依赖具体的数据分布与查询模式。同样的改法在不同的字段依赖下可能破坏排序或过滤结果,因此这类调整应当在自己的数据上先做基准测试,再决定是否进入生产,不适合照搬他人结论。
升级到 v4.16.2 时与容量相关的两处变化
2026 年 9 月 1 日发布说明的 v4.16.2 有两处与容量直接相关。其一,使用 Milvus 作为向量库时,必须先把 Milvus 升级到 2.5.16 或更高版本,该版本会把全文检索切换到 Milvus BM25 并启用新的集合存储向量与全文,版本过低或能力校验失败时服务会终止启动,不会回退到原有方案。其二,PARSE_FILE_WORKERS 等四个 Worker 并发变量被移除,升级时需要从配置文件中删掉,不需要配置替代变量,文件解析 Worker 的上限改为按可用 CPU 并行度自动确定。
已知边界与不适用情形
以下几点来自公开的配置说明与社区 issue 线程,其中个案部分不能当作通用产品边界使用。
配置层面:HNSW_EF_SEARCH 与 HNSW_MAX_SCAN_TUPLES 对 Milvus 不生效;HNSW_MAX_SCAN_TUPLES 只对 PG 生效;OceanBase 的 1-bit 量化不支持内积距离,改用需要同时确认检索距离类型。使用近似索引时,真实的高相似度向量存在被遗漏的可能,这是索引类型本身的特性,不是某个版本的缺陷。
个案层面:社区中出现过 MongoDB 全文检索数据量较大时延迟上升、导入多个较大 Word 文档时 Milvus 容器重启、较旧版本 pgvector 分页查询召回异常等报告。这些是特定环境下的单次现象,没有经过跨环境复现,不能作为容量规划的依据,列出来只是提示排查时可以往这些方向看一眼。
自定义编译或改过核心代码的部署,以及修改过默认数据库连接参数、容器资源限制的环境,上述配置项的实际效果需要在本环境确认。
可以直接核对的几项
1. 当前部署用的是哪种向量库,上面两个环境变量在这套部署里是否真的生效?
2. 调参前是否记录了资源水位,能否区分开“配置不合适”与“资源不够”?
3. 改动向量量化等级之后,索引重建是否已经单独安排?
4. 架构层面的改动是否在自己的数据上做过基准测试,测试口径是否写下来了?
5. 每次调整是否只动一个变量,调整前的取值是否留了记录以便回退?
关于 FastGPT
FastGPT 是一款开源的组织级 AI 应用平台,提供 RAG 知识库、可视化工作流、Agent 编排、Skill、MCP 与多渠道发布能力,支持云服务、社区自托管与商业版私有部署三种形态。应用发布渠道原生覆盖企业微信、微信公众号、个人微信、飞书、钉钉与网页嵌入。截至 2026 年 9 月 3 日,GitHub 仓库 labring/FastGPT 有 29,551 个 Star、7,297 次 Fork,累计 275 个 Release,最新版本为 2026 年 9 月 3 日发布的 v4.16.2。
加载中,请稍侯......