夜雨聆风
AI 系统学习笔记 02｜面向初学者、产品经理与工程师
资料校准日期：2026-08-15
上一篇建立 AI、LLM、RAG、Workflow 与 Agent 的全景坐标后，我继续追问了一个更具体的问题：把企业文档放进向量数据库，为什么回答仍然会错？
我一开始也容易把 RAG 理解成三步：文档切块、写入向量库、检索后交给 LLM。这个描述没有完全错，但它只覆盖了中间的一小段。
真正可用的 RAG 系统，还要处理文档解析、版本和权限、查询改写、混合检索、重排、上下文组装、引用、拒答、评估和持续更新。任何一段失效，都可能表现成一句“模型答错了”。
这篇文章不比较向量数据库品牌，也不提供一套放之四海皆准的参数。目标是把从原始文档到可信回答的完整链路画清楚，并建立一套可以定位问题的工程框架。
一、先把定义说清：RAG 是系统方法，不是数据库
RAG 是 Retrieval-Augmented Generation，即检索增强生成。它在模型生成答案之前，从外部知识源检索相关证据，再把证据作为本次请求的上下文交给模型。
这里包含两个相互独立的能力：检索系统负责“找什么”，生成模型负责“如何基于证据表达”。向量数据库只是可能承载向量索引、元数据和近邻检索的一类基础设施，并不等于完整的 RAG。
一个 RAG 系统甚至可以完全不使用向量检索。例如，制度编号、产品型号、错误码和人名可能更适合关键词检索；结构化经营数据可能应直接查询 SQL；文档关系问题可能需要图查询。工程上常见的是多种检索方式组合，而不是把所有知识都塞进一个向量索引。
边界速记：向量数据库解决“怎样存储和查找向量”；RAG 解决“怎样把外部证据可靠地送入生成过程”。前者是可选组件，后者是一条端到端链路。
以企业助手为例，员工问“差旅报销上限是多少”。系统不仅要找出相似段落，还要确认地区、职级、生效日期和员工权限，并引用当前有效制度。如果只返回语义相似的旧制度，向量相似度再高也没有意义。
二、RAG 有两条主流程：离线建知识，在线找证据
理解 RAG 最重要的一步，是把离线知识加工与在线查询分开。
离线流程把原始内容加工成可检索、可过滤、可追溯的知识单元；在线流程接收用户问题，在权限和时效约束下找出证据，再组织回答。离线质量决定“库里有什么”，在线策略决定“这次拿什么”。
两条流程通过稳定的文档 ID、分块 ID、版本、权限、来源地址和更新时间连接。如果这些字段在解析时丢失，后面就很难准确引用、删除旧版本或执行权限过滤。
常见误区是只监控在线问答延迟，却不监控索引是否更新成功。源文档已经修改、索引仍是旧版本时，模型会非常流畅地回答过期内容。此时问题不在 Prompt，而在知识同步链路。
三、离线加工不是“上传 PDF”，而是一条数据管道
企业知识很少以干净纯文本存在。PDF 可能有双栏、页眉、表格和扫描图片；网页有导航和隐藏文本；表格中的数值离开表头后会失去含义；会议纪要还可能缺少时间和责任人。
因此，离线流程通常包括：数据源接入、格式解析或 OCR、版面与结构恢复、清洗去重、敏感信息处理、分块、元数据补全、Embedding、索引写入和版本发布。
每一步都应留下可追踪产物。例如，从回答引用可以回到 chunk，再回到原始页码和源文件版本；从失败 chunk 可以回看解析后的文本，而不是只看到一串向量。
对于企业助手，我会先定义知识源清单和责任人：制度来自哪个系统，谁负责发布，什么状态才允许进入生产索引，撤回后多久必须不可检索。RAG 首先是知识治理问题，其次才是模型问题。
四、分块的目标不是统一长度，而是保持可回答语义
Chunking 决定检索系统看到的最小知识单元。块太大，会混入无关内容并浪费上下文；块太小，会丢失标题、限定条件和前后关系。
固定长度切分适合作为基线，但生产系统通常还会考虑标题层级、段落、列表、表格、代码、问答对和业务对象边界。对于表格，表头应随行保留；对于制度，章节标题、生效范围和例外条件不应被切散。
Overlap 可以缓解边界断裂，却会增加索引体积、重复召回和上下文冗余。Parent-Child 检索则可以用小块定位、再取较大的父级内容补充语境。所谓“最佳 chunk size”必须由真实问题集验证，而不是照抄某个框架默认值。
企业助手例子：用户问“海外出差超过 30 天是否需要二次审批”。真正可回答的单元应同时包含适用地区、天数阈值、审批角色和例外条款，而不是恰好 500 个字符。
五、Embedding 之外，元数据决定能否正确过滤和引用
向量表达语义相似性，但它不会自动理解哪一版制度有效、谁有权限阅读、内容属于哪个地区，也不会替你保存原始页码。
一个可运营的知识单元至少应考虑：document_id、chunk_id、标题路径、来源、页码、生效时间、失效时间、版本、语言、业务域、权限主体、内容哈希和索引批次。
元数据不是“以后再补”的附加字段。权限过滤、时间过滤、去重、引用、删除、增量更新和问题追踪都依赖它。尤其是权限，应该在检索阶段就缩小候选集，而不是检索出机密内容后再让 LLM“不要说”。
六、在线查询先理解问题，再决定怎样检索
用户问题不一定适合原样向量化。代词依赖对话历史，简称可能有多个含义，一个复杂问题也可能同时包含事实查询和比较任务。
在线链路可以先做轻量查询理解：识别意图和实体，补全对话中的指代，规范术语，拆分多跳问题，并提取时间、地区、部门等过滤条件。只有在确有必要时才调用 LLM 改写，避免把简单查询变成昂贵流程。
查询改写也会引入风险：模型可能改变原意，加入用户没有问过的条件。因此应保留原始问题和改写结果，并在评估中检查“改写忠实度”。确定性的编号、日期和过滤条件应由代码解析和校验。
七、混合检索比“只做向量 Top-K”更稳健
向量检索擅长语义相似，关键词检索擅长精确词项。错误码 E1047、制度编号、产品型号和专有名词，往往需要关键词命中；用户换一种说法描述业务问题时，向量检索更有优势。
混合检索通常并行执行全文和向量查询，再合并两个排序列表。Reciprocal Rank Fusion（RRF）是一种常见融合方法，它根据文档在多个结果列表中的名次累加分数，而不是强行比较不可直接对齐的原始分值。
混合不是永远优于单路检索。它增加计算和调参复杂度，仍需使用领域问题集验证。对于强结构化筛选，先应用元数据过滤再检索通常更重要；对于极小、术语稳定的知识库，关键词基线可能已经足够。
八、召回解决“不要漏”，重排解决“谁最相关”
第一阶段检索追求较高召回率，常会得到几十个候选。直接把它们全部塞给 LLM，会增加成本，并让无关或冲突内容干扰生成。
Reranker 会使用更精细的相关性模型，对“问题—候选段落”成对打分，把少量高质量证据送入上下文。工程上常见的是“宽召回、窄重排”：先从大规模索引快速找候选，再用较贵的模型精排。
这里不能只看 Top-1。一个回答可能需要多个互补证据，也可能遇到新旧制度冲突。证据选择还要考虑去重、来源多样性、版本优先级和上下文预算。
九、检索到内容不等于模型会正确使用内容
在线链路的下一步是 Context Assembly，即上下文组装。系统需要为每段证据保留来源标识，按照相关性和逻辑顺序排列，去掉重复内容，并明确告诉模型：只能根据证据回答，证据不足时应拒答。
“有引用”也不等于“引用正确”。链接可能指向相关文档，却没有支撑具体陈述。更严格的做法是把答案拆成可核验 claim，检查每个关键 claim 是否能被某段证据支持，并让引用定位到页码、章节或 chunk，而不是只给文档首页。
企业助手回答报销政策时，可以先给结论，再列适用条件与例外，最后附制度名称、版本和页码。用户应能从答案快速回到原文，而不是被迫相信模型。
十、可信 RAG 必须会说“我不知道”
如果检索不到证据，错误做法是继续让模型依靠参数记忆猜答案。RAG 的价值之一，是让系统能够基于“证据是否充分”决定回答、澄清或拒答。
停止条件可以综合考虑检索分数、重排分数、证据数量、来源一致性、权限结果和问题类型。阈值不能脱离数据拍脑袋设置，应在验证集上观察误答与拒答之间的权衡。
高风险场景还应增加人工确认。例如，助手可以引用制度解释流程，但涉及劳动争议、财务承诺或对外法律意见时，应给出来源并转交专业人员。
十一、权限与安全必须贯穿索引和查询
RAG 把外部内容送进模型上下文，也扩大了攻击面。恶意文档可能包含“忽略系统规则”之类的间接 Prompt Injection；知识库可能被投毒；权限元数据可能过期；日志还可能记录敏感片段。
核心原则是把检索内容视为不可信数据，不能让文档文字拥有系统指令权限。身份和 ACL 应由确定性系统执行；敏感字段在索引前处理；高风险工具调用与 RAG 回答解耦；索引更新需要来源校验、审批和审计。
如果用户没有权限阅读原文，就不应因为内容进入了向量库而被召回。检索后的应用层过滤也不够稳妥，因为机密内容已经进入候选集和后续链路。更可靠的是在查询阶段基于同步的权限元数据执行过滤，并验证权限变更传播延迟。
十二、评估必须拆开：检索、生成、端到端和运行指标
只问“答案看起来好不好”无法定位 RAG 问题。至少要分四层评估。
检索层看相关证据是否进入候选，例如 Recall@K、MRR、nDCG；生成层看答案是否忠实于证据、是否完整和相关；端到端看任务是否完成、引用是否可核验、拒答是否合理；运行层看延迟、成本、索引新鲜度和失败率。
LLM-as-a-Judge 可以提高评估速度，但不是绝对真值。关键样本应有人审，评审标准要明确，评估模型也需要校准。最有价值的评测集往往来自真实失败：查不到、查错版、越权、引用不支撑、该拒答却猜测。
十三、先按失败类型定位，再决定改哪里
RAG 优化不是不断调 Prompt。可以先判断失败发生在哪一段：知识源缺失、解析错误、分块失真、召回遗漏、排序错误、上下文污染、生成不忠实，还是权限与版本问题。
例如，“答案遗漏例外条款”可能是条款被切到另一块，也可能是检索只召回主条款；“引用正确但结论错误”说明检索可能没问题，应检查上下文指令和生成评估；“不同用户看到相同机密答案”则首先是权限设计事故，不是模型效果问题。
建立 Trace 很重要：保存原始问题、改写问题、过滤条件、候选列表、分数、重排结果、最终上下文、模型输出和引用映射。没有这条轨迹，团队只能靠猜。
十四、GraphRAG 与 Agentic RAG 是扩展，不是默认起点
普通 RAG 适合在独立文本块中寻找局部事实。GraphRAG 会从语料中抽取实体、关系和社区摘要，适合跨文档关系、整体主题和需要“连接多个点”的问题，但索引成本、模型消耗和治理复杂度明显更高。
Agentic RAG 则允许模型在约束内多轮改写问题、选择数据源、继续检索或验证证据。它适合开放式研究和复杂多步问题，也带来更高延迟、成本和不可预测性。
我的默认选择仍然是：先用可评估的 Baseline RAG 建立基线，再根据已确认的失败类型增加混合检索、重排或结构化查询。只有当问题确实需要跨实体全局分析或动态多步检索时，再评估 GraphRAG 或 Agentic RAG。
成熟度标记：混合检索、重排、权限过滤和引用属于生产常用；GraphRAG 属于条件采用；开放式 Agentic RAG 更适合受控探索，不应直接作为所有企业问答的默认架构。
十五、企业助手应按能力和风险逐步上线
一个务实的演进顺序是：先确定知识源与权限，再做关键词或向量基线；加入混合检索和重排；补齐引用、拒答与评估；最后才考虑图索引或动态检索 Agent。
每个阶段都要回答一个可验证的问题：相关证据能否召回？当前版本是否优先？用户是否只能看到有权内容？关键结论是否有证据支撑？证据不足时是否会停止？失败能否通过 Trace 定位？
当这些问题没有答案时，换向量数据库、换更大模型或增加 Agent，往往只会把系统变得更贵、更难排查。
写在最后
现在我更愿意把 RAG 理解为一套证据供应链：它从受治理的数据源出发，经过解析、分块、索引、检索、过滤、重排和组装，把可追溯证据送到模型，再通过引用、拒答、评估和监控约束输出。
向量数据库是这条供应链中的一个仓储与检索组件。它很重要，但它不会替你决定知识是否正确、权限是否有效、证据是否充分，也不会自动让模型忠实回答。
下一篇继续沿着“从会回答到会办事”的路线，拆解：《Tool Calling 不等于 Agent：从模型提议到受控执行》。
资料依据
Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks Microsoft Learn, Hybrid search using vectors and full text in Azure AI Search Microsoft Learn, Relevance scoring in hybrid search using Reciprocal Rank Fusion Anthropic, Contextual Retrieval Microsoft Learn, Document-level access control in Azure AI Search OWASP GenAI Security Project, LLM01:2025 Prompt Injection OWASP GenAI Security Project, LLM08:2025 Vector and Embedding Weaknesses Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation Microsoft GraphRAG, Indexing Overview Microsoft GraphRAG, Query Engine Overview
