RAG 架构：在检索增强生成中避免过度工程化

检索增强生成 (RAG) 经常被过度工程化，开发者在更简单的信息检索方法更有效时，往往直接跳向嵌入 (embeddings) 和向量数据库。最佳架构取决于数据的实时性、语料库特征、查询模式和规模，但大多数系统可以通过全文检索结合基于 LLM 的查询重写来成功实现。

RAG 架构的决策框架

选择正确的检索策略需要评估五个关键技术因素，以避免不必要的复杂性：

• 数据实时性： 实时更新更适合易于重新索引；稳定的语料库允许预先嵌入。
• 语料库特征： 高变动率（每日变化超过 10%）使得全文预嵌入变得不切实际。
• 查询模式： 关键词密集的查询需要全文检索，而对话式查询则受益于嵌入。
• 规模与性能： 每天查询量少于 1,000 次的系统通常不需要进行全面优化。
• 团队能力： 没有机器学习 (ML) 专业知识的团队应优先考虑全文检索和查询重写，而不是混合模式或高级嵌入流水线。

RAG 实现方案

检索策略应循序渐进地实施，只有当数据证明较简单的方法不足时，才转向更复杂的架构。

1. 全文检索 (BM25)

使用 Elasticsearch 或 Postgres 等工具进行全文检索，是处理关键词风格查询和精确匹配（例如，“invoice #12345”）最有效率的起点。

• 优点： 零 API 成本，低于 10ms 的延迟，易于调试，且不需要分块策略 (chunking strategies) 或复杂的评估。
• 缺点： 无法捕捉同义词或语义意图（例如，“car” 与 “automobile"）。

2. 全文检索结合查询重写

使用 LLM 将对话式用户查询转换为干净的关键词搜索，通过解决查询构建问题而非检索问题，解决了许多“语义搜索”问题。

• 机制： LLM 会移除停用词，添加同义词，翻译领域特定术语，并将复杂的查询分解。
• 优点： 如果结果不佳，开发者可以调整系统提示词 (system prompt)，而不是重新嵌入整个语料库。这对于通用嵌入模型经常误解的专有术语特别有效。

3. 混合检索 (BM25 + Embedding Reranking)

这种方法使用 BM25 检索出一组广泛的候选集（前 50-100 个），然后使用嵌入进行重排序 (reranking)。

• 权衡： 这会增加 200-500ms 的延迟，但能捕捉到关键词检索所缺失的语义含义。
• 复杂度： 引入了对分块策略（固定大小 vs. 语义分块）和重叠管理的需求。

4. 即时嵌入 (On-the-Fly Embedding)

对于高变动数据（每日更新超过 10%）或实时内容，文档在查询过程中进行嵌入，而不是预先完成。

• 优点： 完美的数据实时性，且模型切换非常简单；更改嵌入模型仅需一行代码的改动，而不需要重新索引数百万文档。
• 缺点： 较高的查询延迟（200-500ms），且仅限于较小的重排序集（K=20-50）。

5. 冷热分层 (Hot/Cold Tiering)

这种架构预先嵌入频繁访问的文档（“热层”），并对很少访问的文档进行即时嵌入（“冷层”）。

• 优点： 优化了访问模式的帕累托分布（即 20% 的文档获取了 80% 的流量），平衡了延迟与灵活性。

6. 全量预嵌入 (Full Pre-Embedding)

预先嵌入整个语料库并将其存储在向量数据库中进行近似最近邻 (ANN) 搜索，仅在规模巨大（每天超过 10k 次查询）且语料库非常稳定时才有意义。

• 风险： 模型过时是一个重大负担。切换模型需要重新嵌入整个语料库，这涉及高昂的计算成本、停机时间以及广泛的回归测试。

Agentic RAG 与查询分解

包含多个意图的复杂用户查询（例如，“读取一个 CSV，清洗数据，并绘制结果”）应当被分解为子查询。Agentic 系统会将查询分解，将每个子查询路由到最佳检索方法（例如，对某些查询使用简单的关键词检索，对其他查询使用嵌入），然后合并结果。

这种分解方式通常比尝试重写单个复杂查询并嵌入大量文档要便宜且准确得多。

社区见解与反方观点

行业从业者强调，向量搜索的运维负担往往被低估了。

"语义相似度并不像你想象的那么好……你不可避免地会发现自己不得不为了适应越来越精确的嵌入搜索而重新嵌入更多或不同的文本块，……然后你转而构建一个带有 500 个关键词的搜索查询，虽然这很痛苦，但它确实有效。"

其他专家建议，对于像编程这样的特定领域，如果检索返回了模型会比实际源代码更信任的误导性分块，检索可能会适得其反。在这种情况下，使用 grep 或 ripgrep 等简单工具结合 LLM agent 可以比基于向量的 RAG 流水线更可靠。

实现路径总结

策略	实时性	复杂度	延迟	最适合
Full-Text + Rewriting	完美	低	<50ms	60% 的用例
On-the-Fly Embedding	完美	低	200-500ms	高变动数据
Hot/Cold Tiers	中等	混合	50-100ms	多样化的访问模式
Full Pre-Embedding	很高	高	<50ms	海量规模，稳定数据