RAG 不是只靠向量库：缓存、关键词、重排序与模型网关怎么组合？

对应短视频主题：RAG 不是只靠向量库：缓存、关键词、重排序与模型网关怎么组合？资料核验与更新：2026-09-13

很多人第一次接触 RAG（检索增强生成）时，会把它理解成“把文档切块，转成向量，再存进向量数据库”。这只是召回链路的一部分。向量检索擅长找语义相近的内容，但产品编号、法规条款、专有名词、权限和版本号往往需要精确匹配与额外治理。下面按视频中的八个画面，先讲清楚每个组件是什么，再说明它们如何组合。

配图说明：本文图片为本课程 AI 辅助绘制的教学插图，不是厂商原始截图或官方图表；图中术语用于解释关系，技术事实以参考资料为准。

向量库不是完整 RAG

“切块入库”解决的是知识如何被保存和召回，并没有自动解决检索准确性、权限隔离、答案缓存、模型路由和来源追溯。向量召回可能找到意思相近的段落，却漏掉一个必须完全一致的编号或条款，因此关键词索引仍然重要。

判断一个 RAG 是否可靠，第一问不是“有没有向量库”，而是答案能否在正确权限下回到可核对的原文。这个判断标准也决定了后续组件不能只看单点性能。

一条更稳妥的请求路径可以记成：权限过滤 → 精确缓存 → 关键词检索与向量检索并行 → 合并候选 → 重排序 → 交给大模型的少量原文 → 带来源的答案。权限过滤要在缓存和检索前就生效，避免把别人的命中结果泄露出来。

模型网关位于调用治理层：它可以统一接入不同模型，负责路由、预算、限流、故障转移和调用记录；它不负责知识切分，也不等同于知识图谱。把职责分开，排错时才知道问题究竟出在数据、检索还是生成。

关键词检索像查字典：输入中出现的字符串、编号和条款号可以被精确命中，适合型号、错误码和法规引用等场景。

它的优点是可解释、可控，但只靠字面重合可能漏掉同义表达。查询换一种说法时，结果未必仍然相关。

向量检索更像理解意思：它把问题和文档映射到向量空间，寻找语义相近的片段，适合自然语言提问和同义改写。

工程上常做混合召回：先把关键词和向量各自找到的候选合并，再交给重排序模型按当前问题重新打分。这样既保留精确匹配，也利用语义理解。

重排序不是再次扫描整个知识库，而是处理已经召回的候选集合。例如先拿到 20 段，再筛成 3 段证据；候选质量和排序模型都会影响最终答案。

缓存要按“可复用的对象”分层，而不是把所有结果混成一层。第一层是精确缓存：同一问题、同一权限和同一知识版本下，已经验证过的答案可以直接复用。

第二层是语义缓存：意思足够接近的问题可以复用结果，但相似度阈值、租户边界和答案时效都要经过验证。

第三层是检索缓存：缓存关键词、向量召回或重排序的候选，文档更新时可以按版本使其失效。

三层缓存的共同边界是：租户、权限、知识版本和失效策略不能因为“命中缓存”就被跳过。缓存主要优化延迟与成本，不能替代访问控制和证据核验。

如果系统已经以 PostgreSQL 为主，并且事务、行级权限过滤和业务数据联查很重要，可以先评估 pgvector。它把向量能力放在熟悉的关系数据库里，迁移和治理路径通常更直接。

当向量规模较大，需要多向量字段、专门的混合检索或更强的向量基础设施时，可以评估 Milvus。

这不是“谁永远更好”的排名：数据量、团队经验、部署复杂度、权限模型和运维预算才是选型约束。知识治理和关系分析又是另一条轴。本课所说的 LLMWiki pattern，更像可持续维护、可版本化、可人工审阅的 Markdown 知识层。

GraphRAG 则适合实体关系、跨文档关联和全局主题分析：先抽取实体与关系，再用图结构帮助回答跨段落、跨文档的问题。

图谱构建、抽取和更新的成本更高；如果问题只是查一个段落，普通混合检索可能更经济。先确认问题是否真的需要关系推理，再决定是否引入图谱。

把缓存、关键词、向量、重排序和模型网关串起来，最终目标是“少量、相关、可追溯”的证据，而不是把更多文本塞给 LLM。来源回链、知识版本和权限上下文，决定了答案能否被复核。

对零基础读者，可以先记住一句话：RAG 的核心不是“有没有向量库”，而是能否让每个组件各司其职，并让答案回到原始来源。

一条可落地的最小心智模型是：

权限 → 精确缓存 → 关键词 + 向量 → 合并候选 → 重排序 → 少量原文 → LLM → 来源

关键词负责精确，向量负责语义，重排序负责筛选，缓存负责复用，模型网关负责调用治理；LLMWiki pattern 和 GraphRAG 分别解决知识维护与关系分析问题。先讲清楚“是什么”，再根据数据规模、权限、更新频率和问题类型“怎么选”。