RAG（Retrieval-Augmented Generation，检索增强生成）可以理解为：先从自己的资料库中寻找答案依据，再让大模型根据这些依据回答。
它相当于给大模型外挂了一套可搜索的记忆。知识不需要重新训练进模型参数，而是在每次提问时动态检索。因此，企业可以让模型阅读内部文档、产品手册、代码说明或客服知识库，同时保留资料更新和来源追踪能力。
普通大模型可能不知道企业内部信息，可能使用过期资料，也可能生成听起来合理但并不存在的内容。RAG 会先从指定知识库中找到相关段落，再把问题和这些段落一起交给模型。模型主要负责理解和表达，事实依据则由资料库提供。
一套 RAG 怎样运行？
它分为离线入库和在线问答两个阶段。
离线入库
- 读取 PDF、Word、网页、数据库或代码。
- 解析和清洗内容。
- 把长文档切成较小的文本块（Chunk）。
- 使用 Embedding 模型把每个文本块转换为向量。
- 将向量、原文以及标题、章节、版本、权限等元数据写入搜索系统。
在线问答
- 接收用户问题，并在必要时结合对话历史重写问题。
- 同时执行关键词检索和向量检索。
- 根据租户、部门、文档状态和访问权限过滤结果。
- 用 Reranker 对候选段落进行二次排序。
- 选择最相关的若干段落交给大模型。
- 生成带有文档来源和引用的答案；证据不足时明确拒答。
为什么不能只用向量搜索？
向量检索擅长理解语义相近的表达，例如“令牌失效后怎么办”和“如何刷新过期的 Access Token”。但错误码、产品型号、日期、人名、类名等精确信息，关键词检索往往更可靠。
因此，当前成熟方案通常采用混合检索：BM25 关键词搜索和向量搜索并行召回，再合并两组结果。第一阶段召回几十个候选段落，第二阶段用 Reranker 精排，最后只把最相关的五到十段交给模型。
生产系统最重要的部分
- 结构化切块：按标题、段落、表格、函数或完整问答切分，不要机械地从句子中间截断。
- 权限过滤：ACL 必须在检索层强制执行，不能只在提示词里告诉模型不要泄露。
- 版本管理：文档更新或删除后，关联的文本块和向量必须同步更新。
- 引用追踪：每个文本块保留文档名、章节、版本、URL 和更新时间。
- 拒答机制：资料不足或互相冲突时，不允许模型凭常识补全。
- 离线评测：使用真实问题集测试 Recall@K、排序质量、答案正确率、忠实度和引用准确率。
技术选型
个人项目和中小型系统可以使用 PostgreSQL、pgvector、全文检索和一个 Reranker，业务数据、权限与向量都在同一套数据库中，维护成本较低。已经深度使用 Azure 的企业，可以选择 Azure AI Search 完成关键词、向量、过滤和语义排序。数据规模达到千万或亿级时，再考虑 Milvus、Pinecone、Qdrant、Weaviate 等专用向量系统。
一句话总结
成熟的 RAG，不是“把文档扔进向量库，再把 Top 3 塞给大模型”，而是：结构化切块 + Metadata/ACL + 关键词与向量混合召回 + Reranker 精排 + 带引用生成 + 持续评测。
Graph RAG、Agentic RAG、多模态 RAG 都有自己的适用场景，但大多数企业知识问答，先把这套标准混合 RAG 做扎实，往往比追逐更复杂的名词更有效。
最后更新于 2026年9月17日 by
Post Views: 200