AI 大模型 RAG 架构：企业知识库生产环境落地

企业想用大模型构建知识库问答系统，但 Demo 跑通后上生产就翻车——检索不准、幻觉严重、多轮对话断裂。根本原因是把 RAG 当成了"向量检索加大模型生成"的简单拼接，忽略了混合检索、分块策略、重排序等关键环节。本文聚焦 2025 至 2026 年 RAG 技术的演进方向，给出从原型到生产的三阶段架构路径，重点拆解混合检索架构和 Agentic RAG 的设计要点。

RAG 技术演进：从 Naive RAG 到上下文引擎

RAG（Retrieval-Augmented Generation）的概念在 2020 年由 Facebook AI Research 提出，但真正大规模落地是 2023 年 ChatGPT 爆发之后。最初的做法很简单：用户提问，用向量数据库检索相关文档片段，拼到 Prompt 里交给大模型生成答案。这就是 Naive RAG。

2023 年至 2024 年，业界发现 Naive RAG 在生产环境中问题很多。检索阶段：文本切分策略不当会把关键信息切断，纯向量检索对精确关键词不敏感。生成阶段：召回内容过多会淹没重要信息，缺乏质量过滤导致大模型"看着参考资料也能编"。于是 Advanced RAG 出现，在检索前（查询改写、查询扩展）、检索中（混合检索、分块优化）、检索后（重排序、上下文压缩）三个环节进行系统性优化。

2024 年出现了 Modular RAG，把每个环节抽象成独立模块，根据查询类型动态组合流程。2025 年起，Agentic RAG 成为最新方向——赋予大模型自主决策检索策略的能力，让模型判断是否需要多轮检索、从哪个数据源检索、生成答案是否可靠。本质上是 Agent 推理能力与 RAG 知识检索能力的结合。

更前沿的讨论是"上下文引擎"的概念：RAG 不再只是一个检索加生成的管道，而是一个持续运转的知识管理循环，包括检索、记忆、学习三个闭环。这代表了 RAG 从工具层向基础设施层的演进。

三阶段架构路径：从原型到生产

第一阶段：快速验证（1-2 周）

目标是跑通端到端流程，验证 RAG 对业务是否有效。技术选型尽量简单：文档解析用 PyMuPDF 或 Unstructured，向量数据库用 Chroma（本地嵌入式，无需独立部署），Embedding 模型用 BGE-M3（中文语义能力强），大模型用 GPT-4o-mini 或同等性价比模型，框架用 LlamaIndex。

这个阶段的关键动作：把企业核心文档（产品手册、制度文件、FAQ）做基础的文本提取和切分，每个切片 300 至 500 Token 并设置 50 至 100 Token 的重叠窗口，向量化后存入向量数据库。验收标准是核心问题的回答率不低于 70%。

常见失败模式是跳过这一步直接追求高级架构。很多团队花了几个月搭建 GraphRAG，结果发现连基础的文本切分都没做好，数据质量才是 80% 问题的根源。

第二阶段：效果优化（2-4 周）

目标是将准确率从 70% 提升到 85% 以上。核心优化手段有四个。

混合检索。 这是提升效果最直接的手段。纯向量检索对"iPhone 15 Pro Max 电池容量"这类精确查询效果差，BM25 关键词检索反而能精确命中。混合检索的做法是：向量检索（语义匹配）和 BM25 检索（关键词匹配）并行执行，各召回 Top-20，然后用 RRF（Reciprocal Rank Fusion）算法融合排序，取 Top-5 至 Top-10 交给大模型。实践中混合检索普遍优于单一检索，初始权重建议向量与 BM25 之比为 7:3。

查询改写。 用户原始提问往往质量差——口语化、指代不明、信息缺失。用大模型先做一次查询改写，把"那个客户上次说的 API 问题怎么解决的"改写为"客户反馈的 API 接口超时问题的解决方案"，检索效果会显著提升。进阶做法是多查询生成：一个问题扩展成 3 至 5 个不同角度的子查询，分别检索后合并去重。

重排序。 向量检索用 Bi-Encoder，速度快但精度有限；重排序用 Cross-Encoder，把查询和文档拼接输入模型一起打分，精度更高但更慢。最佳实践是 Bi-Encoder 大范围快速召回 Top-20，Cross-Encoder 精确重排后取 Top-5。常用工具包括 BGE-Reranker（中文首选）和 Cohere Rerank。

Prompt 优化。 检索到好内容不等于生成好答案。Prompt 中需要明确指示模型"只基于提供的参考文档回答，若无相关信息请说明，不要编造"，并对复杂问题加入链式思考引导。

第三阶段：生产化（4-8 周）

目标是支撑真实用户并持续迭代。核心工作包括：将向量数据库从 Chroma 迁移到生产级方案（Milvus、Qdrant 或 Elasticsearch 的向量检索能力），建立全链路日志（记录用户查询、改写查询、召回文档、生成答案、延迟、置信度），搭建数据飞轮机制，以及配置监控仪表盘。

数据飞轮是生产级 RAG 区别于 Demo 级的关键特征。当系统判断某个回答的置信度低时，自动触发飞轮：将该问题标记为待优化项，经过人工审核后入库为标准问答对，下次同类问题的置信度就会提升。这是一个越用越聪明的正向循环。

向量数据库选型：按阶段匹配

选型原则是"匹配场景、简单优先"。快速验证用 Chroma 或 FAISS（本地、零运维）；已有 PostgreSQL 基础设施的用 pgvector（无需新技术栈）；中小规模自建用 Qdrant（Rust 编写、高性能）；大规模生产环境用 Milvus（功能最全、企业级）；不想运维用 Pinecone（全托管云服务）。

选型时需要想清楚几个问题：数据量级是百万级以内还是以上？更新频率是静态库还是实时更新？是否需要向量加标量的混合过滤查询？有没有运维能力？

Agentic RAG：让模型自己决定怎么检索

传统 RAG 的流程是固定的：检索一次，生成一次。Agentic RAG 把控制权交给大模型，让它自主决策。基于 ReAct 框架（Reasoning + Acting），大模型在生成答案前会思考：当前召回内容是否足够？是否需要多轮检索？应该从哪个数据源检索？

例如用户问"A 产品和 B 产品的性能对比"，传统 RAG 只会用整个问题做一次检索。Agentic RAG 会先拆解问题：分别检索 A 产品的规格、B 产品的规格，然后判断信息是否充分，不够则继续检索，充分后再综合回答。

Agentic RAG 适合复杂多跳问答、跨数据源查询、分析类问题。但它也带来新的挑战：Agent 的推理链路更长，延迟和成本更高；决策过程的可解释性降低；错误可能在多步推理中累积放大。因此建议从简单场景开始引入 Agentic RAG，逐步扩展到复杂场景。

系统可观测性：生产级 RAG 的底线

"不可观测的系统，无法持续改进。"生产级 RAG 必须记录完整链路：用户原始查询、改写后的查询、召回的文档列表、重排序后的结果、生成的答案、置信度分数、响应延迟。通过这些日志可以回答：用户最常问什么？哪类问题召回差？哪些文档被高频引用？整体时延是否达标？

评估指标方面，推荐使用 RAGAS 框架，核心指标包括 Faithfulness（忠实度，即幻觉程度）、Answer Relevancy（答案相关性）、Context Precision（上下文精确率）和 Context Recall（上下文召回率）。建议从真实用户问题中抽取 100 至 200 条，人工标注标准答案作为固定评估集，定期回归测试。

RAG 的本质是"在需要知识时动态检索，而不是把所有知识固化在模型里"。这个思路不会过时，但落地时 80% 的问题是数据问题而非技术问题。先做好数据工程，再谈架构演进。