穿透复杂的表象，当前 LLM 的底层运行逻辑其实非常单一：它本质上是一个自回归的序列生成器，根据已有的上下文，计算词表中每一个 token 出现的概率分布，然后从中采样出下一个 token。

但这里的「概率」绝非毫无逻辑的随机掷骰子。 这种概率分布，是模型在海量预训练数据中内化的语言规律、世界知识以及逻辑推理能力的数学投影。通过多层 Transformer 网络与注意力机制（Attention），模型在极高的维度上完成了对上下文语义的深度解析与特征关联，从而将符合人类逻辑、契合当前语境的 token 赋予极高的概率权重。它是在用统计学的方式，重现人类的逻辑推理过程。

然而，无论其内部的概率计算多么精密，从软件工程的宏观视角来看，我们本质上依然是在传统的确定性系统中，强行引入了一个基于概率采样的非确定性组件。

传统软件工程建立在严格的确定性之上。输入特定的参数，经过固定的业务逻辑，必然得到预期的输出。现在我们将核心逻辑交由概率模型处理，相同的输入在不同的时间点，可能会产生完全不同的输出路径。

幻觉无法被根除。它是自回归模型的内生特性，是概率采样的必然产物。我们在进行系统架构设计时，必须将幻觉视为系统的常态。试图通过修改 Prompt 来彻底消除幻觉，在工程上徒劳无功。我们需要在系统边界处建立起拦截机制，用确定性的规则去兜底概率模型的不确定性。

容错度决定落地

当前商业化落地最顺畅、ROI 最高的场景，全部集中在高容错度领域。写行业报告、生成营销文案、文生图、视频生成、游戏 NPC 对话。这类场景的核心特征在于缺乏绝对的客观标准。

在内容创作领域，模型偶尔的逻辑发散会被用户视为创造力。工程团队不需要在接口的绝对可用性和输出的绝对准确性上死磕，只需要保证底线的内容安全和合理的响应延迟。系统可用性达到 95% 就能让用户产生极强的获得感。

一旦进入低容错度场景，工程实现的复杂度会呈指数级上升。医疗诊断、工业控制、核心交易链路。在这些领域，0.1% 的幻觉率都会导致灾难性的业务后果。我们在评估一个 AI 项目是否立项时，首要考量指标就是业务场景的容错底线。容错度越低，外围需要的确定性校验代码就越厚重，最终会导致系统的维护成本远超 AI 带来的效率提升。

知识外挂 RAG

RAG 的出现是为了解决模型内部知识更新滞后和私有数据隔离的问题。其核心原理是将外部文档切片、向量化，在用户提问时检索相关切片，拼接到 Prompt 中作为上下文喂给大模型。

在实际的工程环境里，RAG 的核心瓶颈在检索链路。切片策略直接决定了召回质量。按固定 token 长度切分会破坏语义完整性，导致关键信息被腰斩。按标点符号或段落切分会导致切片长度方差过大，影响向量化模型的表达能力。我们在生产环境中通常需要针对不同格式的文档编写定制化的解析器，将 PDF 或 Word 还原为结构化的文档树，再基于文档树的层级进行语义切片。

单一的向量检索在面对专有名词和长尾词汇时表现极差。我们必须采用混合检索架构：稠密向量检索加上稀疏词表检索。向量检索负责语义泛化，处理同义词和模糊表达。词表检索负责精准匹配产品型号、人名和内部项目代号。混合检索引入了多路召回合并的问题，通常需要引入倒数秩融合算法来重排结果。系统复杂度和查询延迟会成倍增加。

数据清洗占据了 RAG 项目 80% 的研发精力。直接将企业内部的原始文档灌入向量数据库，最终的问答准确率通常不到 40%。文档中存在大量的废话、过期的流程规范以及相互冲突的条款。垃圾进，垃圾出。我们在构建知识库之前，必须通过脚本和人工介入，对语料进行严格的去重、降噪和结构化提取。

工具调用确定性

为了弥补概率模型的缺陷，我们需要引入确定性的工具。Function Calling 机制本质上是给 LLM 接上双手。模型负责理解自然语言意图并提取结构化参数，具体的业务逻辑交由传统的确定性脚本执行。

工具调用的工程难点在于参数提取的稳定性。当注册的工具数量超过十个，或者参数结构嵌套层级过深时，模型的输出格式极易崩溃。我们在中间层必须加入严格的 Schema 校验机制。一旦校验失败，需要截断错误信息并触发重试。重试次数上限通常设定为 3 次，继续增加会耗尽上下文窗口并导致请求超时。

多轮工具调用会带来严重的延迟问题。模型每决定调用一次工具，都需要经历一次完整的网络请求和推理过程。如果一个复杂任务需要串行调用三个工具，用户的等待时间会轻易突破 10 秒。我们在架构设计时，需要尽可能将细粒度的 API 聚合成粗粒度的宏接口，减少模型与业务系统的交互频次。

Agent 架构的脆弱性与状态管理

多智能体（Multi-Agent）架构在技术社区被过度神话。多个大模型相互协作、自主规划任务的 Demo 看起来非常惊艳。在真实的工业场景中，完全由 LLM 自主驱动的 Agent 链路极其脆弱。

误差会在多步推理中被迅速放大。假设单个 Agent 节点的输出准确率为 90%，一个包含五个节点的串行任务，最终的成功率会暴跌至 59%。任何一个节点的幻觉都会导致后续链路彻底跑偏。

我们在生产环境中构建复杂任务流时，坚决摒弃由 LLM 自主决定执行路径的黑盒模式。控制流必须由传统的有向无环图（DAG）或状态机来接管。LLM 仅仅作为状态机中的一个计算节点，负责处理非结构化数据的理解和生成。节点与节点之间的状态流转、条件判断、异常重试，全部由确定性的代码实现。这种设计牺牲了系统的灵活性，换取了业务系统必须具备的稳定性和可观测性。

非确定性系统的测试与监控

非确定性系统的测试与监控，是传统软件工程团队转型 AI 开发时遇到的最大痛点。传统的单元测试基于断言，期望输出是固定的字符串或数值。面对 LLM 每次都不一样的回答，基于精确匹配的 CI/CD 流水线会全线崩溃。

我们重构了整个测试评估体系。引入 LLM-as-a-Judge 机制，使用一个能力更强、参数规模更大的模型来评估业务模型的输出质量。评估维度被拆解为相关性、事实一致性、格式合规性等具体指标。在每次模型版本迭代或 Prompt 修改后，必须在包含上千个真实业务 Case 的黄金数据集上运行自动化评估。只有各项指标的波动在可控范围内，才能进行灰度发布。

在监控层面，传统的 APM 工具无法满足需求。我们需要采集每一个请求的 Prompt 模板版本、输入变量、输出结果、Token 消耗量以及推理延迟。这些数据是后续进行 Bad Case 分析和模型微调的唯一原料。针对 Token 消耗的监控直接与业务成本挂钩。我们会在网关层设置严格的并发限制和预算熔断机制，防止恶意请求或死循环调用导致账单失控。

两种范式的碰撞

AI First 与 AI 辅助是完全不同的架构逻辑。

AI 辅助是在现有系统中打补丁。主干流程依然是传统的表单和按钮，AI 作为一个侧边栏或悬浮窗存在，提供总结、翻译、润色功能。开发成本极低，对原有系统无侵入。用户在遇到问题时，可以选择性地向 AI 求助。

AI First 要求重构整个交互形态和底层流转逻辑。系统不再依赖预设的菜单树，由 LLM 充当中央路由。用户的自然语言输入直接驱动底层状态机流转。这要求所有内部 API 具备极高的自描述能力，业务逻辑必须高度解耦。我们在推进 AI First 架构时，面临的最大阻力通常来自老旧系统的技术债。历史遗留的紧耦合代码根本无法被封装成独立的工具供模型调用。

财务场景的拆解

财务场景是典型的低容错度、高确定性要求的领域。将概率模型直接应用于财务核心链路会引发严重的合规风险。可落地的切入点集中在外围的非结构化数据处理和信息流转环节。

发票与报销单据的信息抽取是一个高价值场景。传统 OCR 结合正则匹配在面对版式多变的票据时维护成本极高。引入大模型进行多模态信息抽取，将非结构化的图片或 PDF 转换为结构化的 JSON 数据。抽取后的数据必须经过传统规则引擎的二次校验，例如金额试算平衡验证、税号合规性检查。模型在这里承担的是「粗加工」角色，最终的业务落库动作依然由确定性代码把控。

财务制度问答可以大幅降低沟通成本。基于企业内部报销规范构建 RAG 系统。员工在提单前通过自然语言查询报销标准。这里的 RAG 必须严格限制模型的发散，Prompt 中需强制要求「仅根据检索到的内容回答，未提及的内容直接回复不知道」。为了防止模型编造财务政策，我们会在输出层增加一层文本相似度校验，确保模型的回答与检索到的原文保持高度一致。

财务分析报告初稿生成也是一个可行的方向。将结构化的财务报表数据通过代码转换为文本描述，作为上下文喂给模型，让其生成趋势分析和异常波动提示。模型在这里仅作为「翻译官」和「排版员」，不参与任何数值计算。所有的同比、环比计算必须在传统代码层完成，将计算结果以明确的数值形式提供给模型。让 LLM 去做算术题是工程上的反模式。

数据隐私在财务场景中是不可逾越的红线。公有云 API 无法满足审计要求。我们通常需要采用本地私有化部署的开源模型。7B 到 14B 参数规模的模型经过量化处理后，可以在单张消费级显卡上流畅运行。通过针对财务语料的微调，这些小模型在特定信息抽取任务上的表现可以持平甚至超越千亿参数的通用大模型。私有化部署带来了硬件采购和模型运维的额外成本，需要在项目初期进行严格的 ROI 测算。

以上

长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体：

1. 让 Agent 在跨天、跨周的任务里保持一致性（用户偏好、项目背景、关键决策不丢）。
2. 让上下文成本可控（Token、TTFT、吞吐量别炸）。
3. 让错误可被纠正、记忆可被编辑、可被遗忘（不然就是事故制造机）。

三个主要逻辑——记忆捕获、AI 压缩、智能检索。

说人话就是：数据结构怎么定、写入怎么做、分层怎么做、检索怎么做、什么时候该忘。

1. 先把「长期记忆」拆成三类

在很多团队里，长期记忆失败不是模型问题，是定义问题：同一个「memory」里混了用户画像、任务状态、项目知识、工具日志，最后检索噪声大到不可用。

我更愿意按「用途」拆，而不是按「存储介质」拆：

1.1 用户长期记忆

用户长期记忆每次都要注入的「稳定事实」。

长期记忆的定义：长期、可编辑的核心记忆，记录稳定属性（姓名、目标、经历、偏好等），并且「每次对话都会强制注入」。

这里我会很强硬地加两条工程规则：

• 必须可审计：能回答「这条记忆从哪轮对话来的」「谁写入的」「什么时候写入的」。
• 必须可逆：用户一句「从记忆中删除」要能删干净；内部也要支持 GDPR/合规那种 purge。

更新方式有两种，但优先级不同：

• 显式更新：用户说「记住这个」「删掉这个」这种，优先级最高，直接写。
• 隐式更新：模型检测到符合标准的事实（如 OpenAI 的标准），默认同意自动添加。
  对于隐式更新，我的态度偏保守：宁可少记，不要乱记。乱记比不记更致命，后面纠错成本很高。

1.2 任务记忆

任务记忆是会过期的「状态」

它属于长期记忆系统，但不属于「永久」。例如：

• 一个多天的排障进度（已验证什么、下一步计划）
• 某个 PR 的讨论结论（直到 merge 前都重要，merge 后可降温）

这类记忆如果不做 TTL，很快就把检索污染掉。任务记忆一定要有生命周期。

1.3 事件/操作记忆

这也可以叫做过程记忆，这是为检索服务的「轨迹」。

这类通常来自工具调用、文件读写、运行日志。它的价值是：当用户问「你刚才改了哪几个文件」「上周我们为什么选了 A」时，Agent 能把证据拿出来。

它的问题也最大：写入频率极高、噪声极多。这类我默认做分层：热层保最近、冷层做压缩归档，别全塞进同一个向量索引里。

2. 记忆系统的三段式管道

捕获 → 压缩 → 检索（注入）

2.1 记忆捕获

简单来说就是谁来写、写什么、写到哪。

捕获层我建议按「事件源」拆：

• 对话事件：用户输入、模型输出（或关键片段）、会话元信息（时间、会话 ID、主题）。
• 工具事件：工具名、参数、返回、影响面（写了哪些文件、改了哪些配置、跑了哪些命令）。
• 用户显式指令：强制写/删/改的指令，这条要走单独通道，避免被摘要吞掉。

以 Claude-Mem「五大生命周期钩子」为例，是一个比较实用的策略，原因是它把捕获点固化在生命周期上，不靠「模型想起来了」这种玄学。

我自己的经验：save-hook 和 summary-hook 之间一定要有边界。
save-hook 捕获「事实与证据」（做过什么、改过什么）。summary-hook 产出「压缩后的可读结论」（为什么这么做、后续计划）。混在一起，后面做检索融合会很痛。

2.2 AI 压缩

简单来说就是压什么、怎么压、压到什么粒度

压缩不是「把 10 轮对话变 200 字」这么简单。压缩的核心目标只有两个：

• 降低注入成本：上下文窗口里留给推理的空间要足够。
• 提高检索可控性：检索返回的 chunk 必须信息密度高、噪声低。

比较典型的做法：每隔 10 轮触发 summary agent，把前 10 轮压成 200 字摘要并替换历史。这里可能会有一个坑：摘要如果不带结构，后面无法做检索约束。

我更偏好把摘要拆成固定字段（即使最终还是自然语言）：

• 「目标/约束」
• 「关键决策 + 理由」
• 「未决问题」
• 「下一步」
• 「证据索引」（指向原始事件/日志的 ID）

这样检索返回摘要时，Agent 能快速判断「这段能不能用」，也能在需要时回溯证据。

2.3 智能检索

别把「能搜到」当成「能用」，这是两回事。

很多记忆系统上线后表现很差，根因是：检索返回了一堆「看似相关」但没有操作价值的片段。工程上我会把检索拆成三段：

1. 候选召回：向量相似度 / 关键词 / 结构化过滤（用户、项目、时间窗、标签）。
2. 重排（rerank）：结合时间衰减、来源可信度、记忆类型优先级。
3. 注入策略：怎么塞进 prompt，塞多少，塞哪一层。

「渐进式披露策略」是当前比较流行的注入策略，这比「Top-k 全塞」靠谱太多了：

Level 1: 最近 3 条会话摘要（约 500 tokens）
Level 2: 相关观察记录（用户主动查询）
Level 3: 完整历史检索（mem-search 技能）

Level 1 覆盖 80% 的连续对话场景；Level 2 把「更多细节」交给用户意图；Level 3 才动用重检索，避免每轮都把成本打满。

3. 存储介质怎么选

文件、知识库、数据库都是可以选的。

3.1 文件

最强的可控性，最差的并发与检索体验

文件的优势是「简单到不会出错」：

• 人可以直接打开改
• Git 可以审计、回滚
• 灾备简单

缺点也有：

• 并发写很麻烦（锁、冲突、合并）
• 检索靠你自己做索引，否则就是 grep
• 很难做多租户隔离、权限控制（你当然可以做，但成本会涨）

如 OpenClaw 的设计：每日日志 + MEMORY.md 精选长期存储。它这个方案我很喜欢，原因是它把「噪声」和「精选事实」隔离开了。

一个「看起来保守，但极其工程」的方案：

• 第一层：每日日志，按日期整理，记录会话发生的事情、决策结果、未来可能相关的信息。
• 第二层：**MEMORY.md 本身**，作为精选长期存储库，保存应永久保留的信息；也记录对代理错误的修正。

如果捕捉对话每个细节，代理每次加载上下文会消耗更多 Token，杂音会降低响应质量。

MEMORY.md 这种「精选」必须有准入机制。靠人手维护能跑，但团队一大就维护不过来。可以整一个「重要性评分系统」，先打分，再决定进不进精选层。

3.2 知识库

适合「稳定知识」，不适合「高频写入」

知识库适合 SOP、产品手册、FAQ、架构决策记录这种相对稳定的内容。它的问题是写入链路通常偏离线：采集、清洗、切分、建索引。你要它承接「每次工具调用写一条」这种场景，很快会把 ingestion 管道压垮。

KB 承接 semantic memory（语义知识），别拿它硬扛 episodic/event memory。

3.3 数据库

能抗并发、能做权限、能做检索，但我们要付出工程代价

数据库我会再分两类：

• 结构化数据库（关系型/文档型）：适合 user memory（key-value、可编辑、可审计）、任务状态、权限控制。
• 向量数据库：适合 episodic memory 的语义检索，但会带来你参考内容里提到的三个工程问题。

user memory 这种「必须可控」的内容，优先放结构化 DB；event/episode 的检索层再用向量 DB 或混合检索。把所有东西都向量化，后面治理成本会很高。

4. 向量数据库的使用逻辑

向量数据库把记忆从只读变可写后，需要考虑三个具体的工程问题。

4.1 问题一：需要记住什么？

这里最容易走偏。很多团队一开始恨不得「全量记录」，结果两周后发现：

• 索引膨胀
• 检索噪声上升
• 成本上涨
• 用户抱怨「你记错了」的次数增加

我的判断维度是：时间、频率、类型，这三者会冲突。我会在应用层做一个更硬的分层打分：

• 硬规则拦截：明显不该记的直接丢
  例如临时文件、一次性下载缓存、明显含敏感信息的内容（看合规策略）。
• 重要性打分：符合候选条件的打分
  分数来自：任务相关性、用户显式标记、重复出现次数、工具影响面（改了配置文件通常比分割日志重要）。
• 落层策略：分数决定写入热/冷、决定是否进入精选层（例如 MEMORY.md）。

Milvus 的 TTL 和时间衰减，可以用用，不是核心策略。原因很简单：TTL 只能删时间，删不了噪声。噪声是「内容不该进来」，不是「该不该过期」。

4.2 问题二：怎么分层存储？

按时间切、按访问频率、按用户标注来降冷。「分层」可以，但是：分层的单位别用「向量库的 collection」随便拍脑袋，要用有我们自己的「记忆类型」。

我通常会至少拆三层：

• 热层：最近 N 天的事件 + 最近几条摘要
  目标是低延迟、写入快、检索稳定。热层可以索引轻一些，宁可召回多一点，再靠重排过滤。
• 温层：近期项目周期内的关键摘要、关键决策、纠错记录
  读多写少，索引可以更重，提升精度。
• 冷层：长历史归档
  主要用于追溯，默认不参与每轮检索，只在用户明确追问或系统置信度不足时启用。

这个结构配合「渐进式披露」很顺：默认只碰热层，必要时升级到温层/冷层。成本曲线能压得住。

4.3 问题三：写入频率与速度怎么定？

关键矛盾：agent memory 要实时写入，但向量索引构建需要时间；每条写都重建索引太贵，批量建索引又导致新数据搜不到。

在工程上解这个矛盾的思路：

• 把「可立即检索」和「可长期高精检索」拆开
  新写入先进入一个轻量的「增量区」（delta store），可以是：

  • 内存缓存 + 简单向量结构（甚至先不建复杂索引）
  • 或者一个专门的「实时 collection」，索引参数偏向写入吞吐
• 后台异步合并（Compaction）
  到一定量再合并进主索引（main store），这时构建更重的索引结构。
• 检索时双查
  先查 delta，再查 main，最后融合去重。这样用户刚执行的操作，下一轮一定能搜到，不靠运气。

如果只用一个 collection 硬扛实时写入 + 高精检索，基本会卡在「要么写不动，要么搜不准」之间来回摆。

5. 非向量数据库怎么做长期记忆

我倾向于「结构化事实 + 混合检索」

user memory 和一部分 task memory，用结构化存储更稳，理由：

• 可编辑（update/delete）是常态操作
• 需要强一致（至少单用户维度）
• 需要权限、审计、脱敏、导出、合规删除

向量化适合「相似性召回」，不适合「事实的最终真相」。

这样拆：

5.1 User Memory

KV + 版本 + 来源，每条 user memory 至少需要：

• key（例如 coding_lang）
• value（例如 Python）
• source（显式指令 / 隐式提取 / 管理后台）
• updated_at
• version（解决「多次修改」与「回滚」）
• confidence / policy tag（是否允许自动注入、是否敏感）

然后注入策略是：每轮只注入白名单 key。别把整个用户画像 dump 进 prompt。

5.2 Event/Log

文档型存证 + 可选向量索引

工具调用日志、文件变更记录，我更愿意先当「证据」存好（文档型或日志系统），向量索引只是加速检索的手段。这样即使向量库挂了，还有可追溯的事实来源。

5.3 混合检索

先过滤，再相似度，再重排

非向量方案想要「像向量检索一样好用」，别上来就全文检索硬搜。最有效的顺序通常是：

1. 结构化过滤（用户、项目、时间窗、标签、来源可信度）
2. 再做相似度/全文检索召回
3. 最后重排（时间衰减 + 类型权重 + 去重）

这套顺序能把噪声压下去，查询也更可解释。

6. 长期记忆的「可用性」核心

注入策略比检索算法更重要

很多人把精力都花在「embedding 模型选哪个」「Top-k 设多少」，上线后发现效果波动很大。

实际可能是：注入策略决定了下限。

「渐进式披露」已经是很好的骨架。我补两条我认为必须做的工程约束：

6.1 注入预算必须固定

每轮对话给记忆注入多少 token，要有硬预算。例如：

• 用户长期记忆：固定 100～300 tokens（只放稳定事实）
• 最近摘要：固定 300～800 tokens
• 检索片段：固定 500～1500 tokens（按任务重要性动态）

预算不固定，线上成本就不可控；更糟的是上下文挤压推理空间，模型会「看起来记住了」，实际输出质量下降。

6.2 记忆冲突处理

宁可不注入，也别注入矛盾

最常见的事故是：用户改了偏好（比如语言、格式、技术栈），旧记忆还在注入，Agent 开始精神分裂。

工程上必须有冲突策略：

• 同一 key 的多版本：只注入最新版
• 多来源冲突：显式指令 > 管理后台 > 隐式提取
• 低置信度记忆：默认不注入，只在用户问到时提供候选并求确认

7. 小结

AI Agent 的长期记忆不是「把历史对话都存起来」，而是一套以可控、可维护、可纠错为目标的数据管道与检索系统——先明确记忆类型（用户稳定事实、任务状态、事件证据）并分层治理，再用“捕获 → AI 压缩 → 智能检索/注入”三段式把信息从高频噪声提炼成可用上下文；存储上用结构化数据库承载可编辑的用户/任务事实，用日志/文档留存证据，并按需用向量索引做语义召回与冷热分层，避免写入与索引、噪声与成本之间的失控；

效果上不要迷信 Top‑k，把注入预算、渐进式披露、冲突处理当作系统下限；

运维上把缓存、摘要、显式记忆工具、TTL/衰减与合规删除做成一等能力，并用成本、质量与安全指标持续观测迭代。

最终目标不是「记得更多」，而是让 Agent 在长期任务中更一致、更便宜、更可靠。

以上。

做 RAG 经常会效果不行，就算是把模型换了更大的，回答依然飘；把向量库换了更贵的，召回还是不稳；把 Prompt 改了很多版，效果依然起起落落。

RAG 的瓶颈大多不在「生成」，而在「检索」。检索做不好，生成只能在不完整的输入上硬编；检索做得稳定，模型反而没那么挑。

今天我们聊讲 5 个在工程中里最常用、ROI 比较高的策略：

1. 多向量检索
2. 人工切分打标
3. 标量增强
4. 上下文增强
5. 增加多类型向量

0. 优化什么

RAG 的检索链路，拆开看就两件事：

• 召回：把“可能相关”的材料尽量找全
• 排序：把“真正相关”的材料尽量排前

这两件事对应的常见失败模式也很固定：

• 同义相似但不相关：语义像，但不是答案需要的证据
• 关键词命中但语义不近：专有名词、编号、表格字段，向量不敏感
• 被切碎：答案跨段、跨页，chunk 切断了前后依赖
• 证据形态不对：表格、图片、公式、目录结构，直接 embed 很容易失真
• 同一问题在不同时间答案不同：版本、日期、渠道不清，检索到旧材料

下面的 5 个策略，分别解决这些问题中的一个或多个。

1. 多向量检索

给同一份内容提供多种“检索入口”

1.1 核心思路

多向量检索的关键点不是「存更多向量」这么简单，而是把用于检索的表示和用于回答的原文解耦：

• 检索阶段：用更适合相似度搜索的表示去匹配（比如摘要、问题式描述、表格的自然语言总结、图片的文字说明）
• 生成阶段：把原始内容（全文、原表格、原图片引用）交给模型做答案合成，避免摘要丢细节

这种逻辑可以用把 RAG 从「只适合纯文本」扩展到表格、图片等半结构化/多模态内容：
用总结去检索，用原始材料去回答（尤其表格场景很典型：总结容易被召回，但回答必须看原表格字段和数值）。 这种

1.2 什么时候最值

多向量检索在三类数据上收益很稳定：

• 半结构化文档：表格 + 段落混在一起（财报、年报、审计报告、制度文件）
• 多模态文档：图片、图表、扫描件（说明书、投标文件、报告 PDF）
• 长文档：同一个主题分散在多个章节，单一 chunk embedding 容易错过

1.3 工程落地

落地要解决三件事：

1. 拆分元素类型：把文档切成“文本块 / 表格 / 图片”等元素
   用 Unstructured 这类工具做 partition：先抽取图片块，再用布局模型拿到表格边界、标题候选，再把标题下面的文本聚合成块。

2. 为每类元素生成可检索的文本表示

   • 文本块：可以生成更短的摘要、关键词式描述、可能的问题集合
   • 表格：生成“表格讲了什么”的自然语言摘要（用来检索）
   • 图片：常见的是「先用多模态模型把图片转成文字摘要，再当文本检索」
3. docstore 里保留原件
   检索命中的是 summary，但最后喂给 LLM 的是原文/原表格/原图引用。

1.3 常见坑

• 摘要写得太像原文：检索没变强，只是多存了一份噪声
  摘要应该更「检索友好」：更短、更结构化、包含实体名、指标名、时间范围。
• 一个元素生成太多向量：向量数暴涨，召回变慢、成本变高
  做到「足够覆盖检索入口」即可，别追求花样。
• docstore 的映射不稳定：summary 与原件的 id 对不上，线上会出现“召回到 A，返回了 B”的事故
  id 设计要从第一天就稳定，元素级别的主键要可复现。

2. 人工切分打标

用最便宜的方式把「结构」和「业务语义」补回来

2.1 为什么需要人工介入

很多团队一开始会追求「全自动 ingest」，但现实是：

• 同一套自动切分规则，放到不同类型文档上效果差异很大
• 文档里真正有用的结构信息，往往不在文本里，而在排版、目录、章节层级、表格布局里
• 业务里最关键的“可用性信息”（版本、适用范围、地区、产品线、口径）不一定在正文可直接抽出来

人工切分打标解决的是：把检索需要的结构和语义先做扎实，后面的向量、排序、重写才有发挥空间。

2.2 切分的三个规则

1. 按语义边界切，不按长度切
   章节、小节、条款、定义、流程步骤、FAQ 一问一答，是天然边界。
   “为了 token 均匀”硬切，很容易切断定义与约束条件。

2. 切分粒度为「可引用证据」服务
   能够被引用、被追溯、被定位的最小单元更重要：

   • 条款编号
   • 表格标题 + 表格整体
   • 小节标题 + 小节正文
   • 定义段落（不要拆）
3. 保留层级关系
   只存平铺 chunks，后面很难做「向上取整段/向下补上下文」。
   最少保留：文档 → 章节 → 小节 → 段落/表格。

2.3 优先打「可过滤、可路由」的标签

别一上来就做很细的本体论，先打最值钱的：

• 文档类型：制度 / 产品手册 / 合同模板 / 会议纪要 / 财报
• 业务范围：地区 / 产品线 / 客户类型 / 适用系统
• 时效性：生效日期 / 版本号 / 是否废止
• 可靠性：来源系统 / 审批状态 / 是否正式发布
• 访问控制：部门、角色、密级

这些标签后面都能进入“标量增强”和“路由策略”，直接影响线上稳定性。

2.4 常见坑

• 打标体系不收敛：每个人一套标签名
  解决办法很朴素：拉一张白名单表，允许的 key 固定，value 做枚举或正则。
• 把「主题」当标签：主题不稳定，且和 embedding 重叠
  标签更适合放「硬约束条件」和「业务边界」。

3. 标量增强

让检索从「相似」走向「可控」

这里的「标量」指的是：时间、版本、来源权重、权限、质量分、业务线等可以过滤或打分的字段。它们不靠向量表达，靠规则或数值逻辑表达。

3.1 标量增强解决什么问题

• 同一问题，不同时间答案不同：检索到旧版本会直接翻车
• 同一概念，不同地区/产品线口径不同：向量相似度分不出来
• 噪声文档混进知识库：相似度很高但质量很差
• 需要可解释、可审计：为什么给出这条证据，要说得清

把这些交给向量相似度，基本靠运气；交给标量逻辑，结果更可控。

3.2 两种最常用的做法

做法 A：先过滤，再向量检索
先用 metadata 把候选集缩小到“可能正确的范围”，再做语义召回。
典型过滤条件：

• 生效日期 <= 查询时间
• 版本号 = 当前版本
• 适用产品线包含用户所属产品线
• 权限满足访问控制

做法 B：向量召回后，用标量重打分
向量给你 TopK，标量给「业务优先级」：

• 新版文档加分，旧版扣分
• 官方来源加分，草稿扣分
• 被引用次数高/被人工验真过的内容加分

最后把两类分数合成一个总分再排序。

3.3 标量增强的关键点

• 标量字段要可维护：自动抽取优先，其次半自动，再其次人工
• 默认值要保守：缺字段宁可不加分，也别乱加分
• 线上要留日志：每个命中结果，把过滤条件、加分项写清楚，排障会省很多时间

4. 上下文增强

补回 chunk 被切断的前后依赖

上下文增强不是「塞更多文本」，它指的是：让每个可检索单元在被 embed 或被召回时，带上必要背景，避免「孤句误读」。

4.1 你会在哪些场景明显感到缺上下文

• 规章制度里一条规定引用了前面的定义
• 财报里一个指标只在章节开头定义一次，后面全是缩写
• 表格字段含义在表格上方说明里
• 会议纪要里“同意/不同意”要回看讨论对象是谁

这些内容即便向量召回命中了，模型也很容易误解，因为证据不自洽。

4.2 上下文增强常用的三种实现

实现 1：Embedding 前拼接轻量上下文
把 chunk 的标题路径、章节名、文档名等拼到 chunk 前面，再去做 embedding。
目标是让向量表达里包含“这句话属于哪里”。

实现 2：Parent / Window 思路（召回后扩窗）
先召回一个小块，然后按层级关系取它的父节点（小节/章节）或前后窗口。
这样不会让向量库里每个 chunk 变得巨大，但模型看到的上下文更完整。

实现 3：结构化索引 / 树检索（长文档很常用）
这类方法直接承认“文档是有层级结构的”，检索时先在结构上定位，再下钻到具体段落。

以 PageIndex 为例：它会生成类似「目录」的树结构，然后用 LLM 在树上做推理式检索，强调 No Vector DB、No Chunking、Human-like Retrieval，并且给出可追溯的页码/章节引用。

4.3 常见坑

• 上下文拼太多：embedding 变“平均化”，相似度反而变差
  只拼最有区分度的：标题路径、定义短句、字段解释。
• 扩窗没有边界：一扩就把整章塞给模型，成本和噪声都上来
  扩窗要有上限，优先拿“同小节”而不是“同文档”。

5. 稠密/稀疏两种向量一起用

使用 BM25 集成，把「关键词命中能力」补回来

稠密/稀疏向量是什么。

• 稠密向量检索（Dense / Embedding）：
  适合语义相近的表达，用户措辞变化大也能匹配到。
• 稀疏检索（Sparse / BM25）：
  适合精确词匹配，尤其是专有名词、编号、字段名、错误码、产品型号、合同条款号。

工程上最常见的现象是：
用户问了一个带编号/字段名的问题，向量检索给你一堆语义很像的段落，但就是没有那个编号对应的条款；BM25 往往一搜就中。

BM25 能给我们带来：

• 召回包含关键字的证据，避免向量漏召
• 对“必须精确命中”的问题更稳（例如政策条款号、表格字段、系统接口名）
• 对混合语料更友好（中英混排、代码片段、缩写、符号）

5.1 集成方式

工程里常用两种

方式 A：并行召回 + 合并去重 + 重排

• BM25 TopK 一份
• 向量 TopK 一份
• 合并成候选集，去重
• 用统一的 rerank（或简单规则）排出最终 TopN

这个方式的优点是直观，问题也直观：候选集会变大，要控制 K 和 rerank 成本。

国内阿里云的向量数据库有多维向量的逻辑，可指定权重召回。

方式 B：BM25 做第一阶段召回，向量做第二阶段精排（两段式）
适合语料特别大、向量检索成本高的场景。BM25 先把范围缩小，再在小集合里做语义相似度和重排。

5.2 常见坑

• 把 BM25 当主力：BM25 对同义改写不敏感，用户表达一变就丢召回
• 权重拍脑袋：BM25 和向量的分数尺度不同，直接线性加权经常不稳定
  更稳的做法通常是：先归一化，再做合并；或者交给 rerank 做最终裁决。
• 分词质量不过关：中文 BM25 的效果强依赖分词/词典
  词典里把产品名、缩写、字段名补齐，收益很实在。

6. 小结

以上的策略也不是一定要一起上，可以按阶段实施：

1. 人工切分打标：先把结构、版本、权限、范围做干净
2. BM25 集成：把关键字硬命中能力补齐，减少离谱失败
3. 上下文增强：解决「切碎」和「孤句误读」
4. 标量增强：把线上结果变得可控、可解释、可审计
5. 多向量检索：针对表格/图片/长文档，把跨形态检索打通

这 5 个策略并不冲突，实际生产系统基本是叠加使用：
BM25 兜底精确命中，向量负责语义召回，标量负责边界条件，上下文负责可读证据，多向量负责多形态内容。

在这些策略的基础上，我们可以使用如下的一些评估方式来判断是否优化有效：

• 召回层指标：TopK 是否包含正确证据（有无命中）
• 排序层指标：正确证据在 TopK 的位置分布（越靠前越好）
• 答案层指标：带引用的正确率、引用的可追溯性（页码/条款号/表格位置）
• 线上指标：无答案率、澄清率、人工升级率、重复追问率

尤其建议把「无答案率」和「引用可追溯性」拉出来单独看，它们最能反映检索链路是否健康。

以上。

行业 Agent 是要能解决问题的，而查资料只是其中一步，后面还要做判断、走流程、调用系统、校验结果、留痕、可回放。

RAG 在这里的角色也变了：它不只是给模型喂上下文，而是给 Agent 提供可执行任务所需的依据、约束、参数和证据链。

今天我们聊一下行业 Agent 构建过程中的 RAG 怎么写，从目标、数据，检索以及使用 RAG 等等方面。

1. 行业 Agent 的 RAG 要服务什么能力

行业 Agent 常见的工作方式是「多步闭环」：

1. 识别问题类型与业务对象（客户、设备、合同、工单、订单、项目、账号等）
2. 查依据（制度、手册、知识库、历史工单、标准、接口文档）
3. 做动作（查系统、下发指令、开通配置、生成工单、发邮件、写报告、提审批）
4. 校验与回写（确认变更成功、回填字段、留痕、把引用/证据挂到工单）
5. 解释（给用户说明依据、影响范围、回滚方案、下一步建议）

所以行业 Agent 的 RAG 不只是「问答检索」，而是至少要覆盖这些信息类型：

• 规则依据：制度、条款、SOP、合规模板、变更规范
• 操作依据：系统使用手册、接口文档、参数含义、错误码处理
• 对象事实：来自业务系统的实时/准实时数据（用户信息、资源状态、库存、账单、设备状态）
• 历史经验：工单处理记录、故障复盘、已知问题（KEDB）
• 风险边界：禁用操作清单、权限范围、需要人工复核的条件

如果我们只做「文档向量库 + 生成」，Agent 走到第 3 步就会卡：它不知道该调用哪个系统、需要哪些字段、什么情况下要停下来让人确认，也不知道怎么证明自己做对了。

2. 指标

行业 Agent 场景里，最好用三类指标描述：

2.1 任务完成类指标

• 任务成功率（最终动作成功并通过校验）
• 平均完成时长（端到端）
• 人工介入率（需要人确认/补充信息/兜底）
• 回滚率（执行后需要撤销/修正）

2.2 风险类指标（红线不能过）

• 越权率（检索/执行是否越权，目标是 0）
• 误执行率（不该执行却执行）
• 误答导致的错误操作（把“编出来的依据”当成执行依据）
• 引用不可追溯率（给不出来源或来源不支持结论）

2.3 知识与检索类指标（用于驱动迭代）

• 依据命中率（标准依据是否出现在 topK）
• 冲突处理正确率（新旧版本/多来源冲突时是否选对）
• 时效正确率（是否引用过期/废止内容）
• 覆盖率（高频问题是否覆盖）

行业 Agent 的 RAG 设计，最终要对这些指标负责。否则我们会陷入「答得像那么回事，但不敢让它动系统」的状态。

3. 数据层

行业 Agent 的 RAG，数据比模型更重要。

3.1 三类数据

1. 静态权威知识：制度、规范、手册、标准、产品文档
   目标：可追溯、版本可控、可引用
2. 动态业务事实：来自业务系统的数据（CRM、工单、CMDB、监控、计费、IAM 等）
   目标：可校验、可审计、最好可回放（至少保留查询快照）
3. 过程与经验：历史工单、故障复盘、处理记录、FAQ 演进
   目标：可过滤（质量参差）、可分级（权威/经验/猜测）

很多项目失败是因为把第 3 类当第 1 类用，把「经验」当「制度」。Agent 一旦据此去执行动作，风险会放大。

3.2 每个知识片段必须带的元数据

行业 Agent 需要的不只是「能搜到」，还要「能用来做动作」。建议每个 chunk 至少包含：

• doc_id / chunk_id
• source（系统/库）
• source_url（可点击或可定位）
• title_path（标题链）
• doc_type（制度/手册/接口文档/复盘/工单等）
• version、status（草稿/已发布/已废止）
• effective_from / effective_to（能给就给）
• owner（维护人/团队）
• updated_at
• 适用范围标签：产品线/地区/客户/机型/环境（生产/测试）
• 权限标签：RBAC/ABAC 所需字段
• 可执行性标签（建议加）：
  • 是否可作为执行依据（例如制度/已发布 SOP 才能）
  • 是否需要人工复核（高风险操作）
  • 是否仅供参考（复盘/经验）

这些标签对 Agent 比较关键：它能决定「能不能做、要不要停、怎么解释」。

3.3 文档解析与切分

行业 Agent 的 RAG 的切分策略，优先级一般是：

1. 按结构切：章/节/条款/接口字段说明/错误码条目
2. 把“前置条件/限制/例外”跟规则放一起
3. 表格与字段定义要保表头（字段含义脱离表头就没法用）
4. 把可执行步骤单独成块（SOP、Runbook、变更步骤）

注意：不要把「定义」「适用范围」「例外条款」切碎。Agent 执行动作时，最需要的就是边界条件和限制。

4. 索引与检索

行业 Agent 和常规的 Agent 不同，其更依赖于「过滤 + 排序 + 证据链」

4.1 使用混合检索

行业 Agent 的查询里会出现大量「硬信息」：

• 条款号、标准号、型号、错误码、参数名、接口路径、工单号、配置项名

纯向量在这些场景不稳。工程上更常用的是：

• 关键词/BM25：抓编号、术语、字段名、错误码
• 向量召回：抓语义相近、同义表达
• 融合 + 重排：把候选集排序成「最能支持动作/结论」的那几段

4.2 检索要先过滤，再找相似

行业 Agent 的过滤通常是强约束，如下：

• 权限过滤（用户/角色/租户/数据域）
• 状态过滤（废止、草稿默认不进）
• 生效时间过滤（尤其制度、计费、合规）
• 适用范围过滤（产品/地区/环境）
• 数据域隔离（内部/客户侧/合作方）

如果我们把这些留到生成阶段「让模型自己注意」，效果不可控，风险也不可控。

4.3 Agent 专用检索

不止检索答案，还要检索工具与参数

行业 Agent 经常需要两类额外检索：

1. 工具检索（Tool RAG）
   从「工具说明库/接口文档/SOP」里检索：该用哪个工具、需要哪些参数、有哪些限制、失败怎么处理。
2. 参数与字段检索（Schema RAG）
   从「数据字典/字段说明/枚举值」里检索：字段含义、可选值、校验规则、示例格式。

这两类检索的结果不一定直接展示给用户，但会决定 Agent 能不能把动作做对。

5. 固化 Agent 使用 RAG 的逻辑

行业 Agent 的 RAG 关键是要「把 RAG 插进决策点」

行业 Agent 常见的内部循环大致是：

• Plan（决定下一步做什么）
• Act（调用工具/检索/执行）
• Observe（拿到结果）
• Decide（是否继续、是否需要人确认、是否结束）
• Explain（对外输出）

RAG 的插入点建议固定成三处：

5.1 决策前

用 RAG 找「规则边界」

在 Agent 做出关键决策前，先检索：

• 是否允许执行（权限、合规、风险等级）
• 前置条件是什么（必须具备哪些信息、哪些系统状态）
• 需要的审批/确认是什么（是否必须人工确认）

这一步的输出的是「约束」，不是「答案」。它会影响下一步是继续、暂停还是转人工。

5.2 执行前

用 RAG 找「操作步骤与参数」

执行某个动作前，检索：

• SOP / Runbook / 接口文档
• 必填参数、参数来源
• 校验方式（执行后如何确认成功）
• 回滚方式（失败/异常如何撤销）

这一步的输出是「可执行步骤」，不是「解释性段落」。

5.3 执行后

用 RAG 做「结果判定与错误处理」

拿到工具返回值后，检索：

• 错误码含义与处理建议
• 常见失败原因
• 是否需要升级/转人工
• 是否需要二次校验（比如跨系统一致性）

这一步的输出是「下一步动作建议 + 证据」。

6. 生成与输出

行业 Agent 的输出要分层，不要把所有东西都写给用户

行业 Agent 的输出建议拆成三层，分别服务不同目标：

1. 用户层：结论/进展、需要用户补充什么、下一步怎么走
2. 证据层：引用依据（链接、页码、版本、生效日期）
3. 执行层（留痕层）：本次调用了什么工具、参数摘要、返回结果摘要、校验结果、回滚点

用户不一定要看到执行层细节，但系统必须存储这些内容。只有出了问题能回放，才敢放权。

同时，行业 Agent 的生成要有硬规则：

• 没有命中权威依据：不输出肯定结论
• 有冲突：必须把冲突来源、版本、生效时间写清楚
• 涉及高风险动作：必须停下来请求确认（并把依据与影响范围给出来）
• 引用必须来自检索上下文：不允许来虚的，「凭印象补一句」

7. 权限、审计、隔离

**行业 Agent 的 RAG 必须「检索前隔离」。

行业 Agent 一旦能调用系统，风险比问答高一个量级。权限要分两层：

7.1 知识权限

能不能看的问题

• 文档/知识片段按 ABAC/RBAC 做过滤
• 按租户隔离（多客户必做）
• 按数据域隔离（内部策略、客户信息、合作方信息）

7.2 行为权限

能不能做的问题

• 工具级权限：这个角色能调用哪些工具
• 动作级权限：同一工具下哪些操作允许（例如只读查询 vs 修改/下发）
• 参数级权限：同一动作下哪些资源范围允许（例如仅能操作自己负责的项目/客户）

很多团队只做了「知识权限」，没做「行为权限」。

这会导致不放心，即使 Agent 能查到 SOP，也能学会「怎么做」，但你又不敢让它真的做。

7.3 审计要能回答四个问题

• 为什么这么做（依据是什么）
• 做了什么（调用了哪些工具、关键参数是什么）
• 得到了什么（返回结果与校验结果）
• 谁批准的（如果需要人工确认）

没有这四个问题的答案，行业 Agent 很难通过安全审查，也很难在出事后定位责任与修复点。

8. 灰度上线策略

先控制风险，再谈覆盖率

行业 Agent 的上线节奏建议按权限逐步放开：

1. 只读 Agent：只检索、只解释、只给建议，不执行任何写操作
2. 半自动 Agent：可以生成“执行计划/工单草稿/变更单草稿”，必须人工确认后执行
3. 受限自动 Agent：只允许低风险、可回滚、可校验的动作自动执行（例如查询、对账、生成报表、创建工单、补全字段）
4. 高风险动作：默认保留人工确认，除非你能做到严格的权限、校验、回滚、审计，并且有明确的责任边界

上线必须准备三套兜底：

• 超时与降级：检索失败/重排失败/模型失败时怎么退化
• 失败回滚：执行失败怎么撤销，撤销失败怎么升级
• 人工接管：在关键节点能一键转人工，并把证据与执行轨迹带过去

9. 常见坑

1. 把「经验工单」当「标准答案」：Agent 会把偶发处理当成通用规则。必须分级与降权。
2. 只做知识库，不做数据字典与工具库：Agent 会不知道参数怎么填、字段是什么意思、错误码怎么解。
3. 只做检索，不做执行前校验与执行后校验：敢执行的前提是可校验、可回滚。
4. 权限只管文档，不管工具：最容易在这里翻车。
5. 没有回放评测：你不知道一次小改动会不会让 Agent 在某个分支上开始乱走。
6. 把「多轮对话」当「任务编排」：行业 Agent 的关键是状态机与决策点，不是聊得多。

最后，行业 Agent 的 RAG 如果要构建，不仅仅是算法的事情，需要更多的业务专家，业务 Owner 来直接参与，他们才是最懂行业的人。需要他们来定义「什么算答对/答错」、哪些文档权威、版本如何取舍、哪些内容不能答。

以上。

当用户勾选 联网搜索 功能时，可以将其视为一个 能够理解任何自然语言问题的智能搜索引擎，相比传统搜索引擎仅支持关键词匹配，LLM 结合联网搜索可以更智能地解析问题，并返回更精准的结果。特别是在 R1 的推理加持下，整个过程显得更为丝滑。

联网搜索不仅能够提升模型的实时信息获取能力，还能与 RAG 技术结合，使模型在回答问题时参考最新的搜索结果，提高准确性和可靠性。

之所以要增加联网搜索，增加 RAG 的逻辑，这些都是由大模型本身的问题造成的。

1. 大模型的问题

大语言模型（LLM）的知识来源于海量的离线数据训练，因此其信息具有时效性滞后问题。

一般来讲，主流 LLM 的训练数据通常滞后于其发布时间半年到一年以上。例如，GPT-4o-latest 的训练数据截止于 2024 年 6 月，而 DeepSeek-R1 的最新数据截止于 2024 年 7 月（问 DeepSeek-R1，它自己回答的）。这意味着 LLM 无法直接获取训练完成后发生的最新事件、科技进展或行业动态。

1.1 知识局限性

由于 LLM 依赖于静态数据集进行训练，其知识范围受到以下限制：

• 无法获取最新信息：模型的知识仅限于训练数据中的内容，因此对于训练完成后发生的事件，它无法直接回答或提供准确的分析。
• 缺乏实时数据支持：LLM 无法访问最新的网络信息，如新闻报道、财务数据、政策变动等。
• 受限于训练数据的覆盖范围：即便是训练数据范围内的知识，LLM 也可能因为数据筛选、公开性限制等原因而无法掌握某些领域的最新进展。

为了解决这一问题，许多 LLM 引入了 联网搜索 机制，使得模型能够动态检索最新的网络信息，从而提供更具时效性的回答。

联网只解决了部分大模型的信息实时性的问题，除此之外， LLM 还面临 幻觉问题、私有数据匮乏、内容不可追溯、长文本处理能力受限以及数据安全性 等挑战。

1.2 模型幻觉

由于 LLM 的底层原理是基于 数学概率 进行文本生成，其回答并不是基于事实推理，而是对最可能的词序列进行预测。因此，LLM 可能会在自身知识缺乏或不擅长的领域 一本正经地胡说八道，即产生 幻觉。这种现象在 事实性要求较高的业务应用（如法律、医疗、金融等）中尤其需要被关注，因为错误信息可能导致严重后果。同时，区分 LLM 生成的正确与错误信息 需要使用者具备相应领域的知识，这也提高了使用门槛。

1.3 私有数据匮乏

LLM 主要依赖 互联网公开数据 进行训练，而在 垂直行业、企业内部 等场景中，很多专属知识并未包含在模型的训练集中。这意味着 LLM 无法直接回答涉及 企业内部文档、行业专属知识库 或其他非公开信息的问题，导致其在 专业化应用场景 中的表现受限。

1.4 内容不可追溯

LLM 生成的内容通常 缺乏明确的信息来源，用户难以验证其答案的准确性和可靠性。这种不可追溯性影响了 内容的可信度，尤其是在需要引用权威信息的场景（如学术研究、法律咨询等）。

1.5 长文本处理能力较弱

LLM 受限于 上下文窗口的长度，在处理长文本时 容易丢失关键信息，并且 输入文本越长，处理速度越慢。这对需要分析 长文档、长对话或复杂背景信息 的应用场景构成了挑战。

1.6 数据安全性

对于企业而言，数据安全至关重要，没有企业愿意将私有数据上传到第三方平台 进行训练或推理，以避免数据泄露的风险。因此，完全依赖 通用大模型 进行知识问答和分析，往往需要在 数据安全性与模型能力之间 做权衡。

2. RAG 的出现

随着大语言模型（LLM）在各类任务中的广泛应用，人们逐渐发现它们的局限性，如时效性滞后、幻觉问题、私有数据匮乏、内容不可追溯、长文本处理能力受限，以及数据安全性等挑战。为了解决这些问题，Retrieval-Augmented Generation, RAG 技术应运而生。

2.1 什么是 RAG？

RAG（检索增强生成）是一种结合信息检索与文本生成的 AI 方案，旨在利用外部知识库或文档存储，实现更准确、实时且可追溯的内容生成。其核心思想是：

1. 检索（Retrieval）：在 LLM 生成答案之前，首先从外部知识库或数据库中检索相关信息。
2. 增强（Augmented）：将检索到的信息与用户的原始问题结合，形成一个更丰富的输入。
3. 生成（Generation）：将增强后的输入提供给 LLM，使其基于最新信息进行回答，而不是仅依赖于模型固有的知识。

2.1.1 RAG 的发展历史

RAG 由 Meta AI 团队于 2020 年提出，最初是为了提高 LLM 在特定任务中的表现。随着 LLM 在各类应用中的扩展，RAG 技术逐渐成为提升模型响应质量的重要手段。

在 RAG 之前，主要有三种方式来提升 LLM 的能力：

• 微调：通过额外训练数据调整 LLM 的参数，使其更适应特定任务。
• 提示工程：通过优化输入提示（Prompt）来影响 LLM 的输出。
• 知识注入：在 LLM 训练阶段直接加入结构化知识，以增强其知识覆盖范围。

然而，这些方案都有各自的局限性，例如微调成本高昂、提示工程 在复杂任务下效果有限，而知识注入无法解决最新信息的获取问题。因此，RAG 逐渐成为一种更灵活、高效的解决方案。

2.2 RAG 解决了哪些问题？

• 解决知识局限性：RAG 通过外部检索，可以动态获取最新的信息，而不像 LLM 仅依赖静态训练数据。例如，在金融、法律、医疗等领域，LLM 需要访问最新法规、市场动态或医学研究，RAG 能够提供这些最新信息，从而提高回答的准确性。

• 缓解模型幻觉：LLM 生成的内容基于概率计算，当其遇到没有见过的内容时，会凭空捏造不存在的信息。RAG 通过提供真实的外部数据作为参考，降低了模型「胡说八道」的风险。例如，在法律咨询场景中，RAG 可以直接引用相关法规，而不是让 LLM 「猜测」答案。

• 访问私有数据：企业通常拥有大量的内部专有数据，如客户档案、财务报表、技术文档等，RAG 可以让 LLM 在不重新训练的情况下，动态查询这些私有数据并提供个性化回答。例如，企业可以使用 RAG 让 LLM 访问内部知识库，实现智能客服或决策支持。

• 提高内容可追溯性：LLM 生成的内容通常无法溯源，而 RAG 允许模型在回答时引用具体的数据来源，例如检索到的网页、论文或数据库记录，使用户可以验证答案的真实性。这在医疗、法律等领域尤为重要。

• 优化长文本处理能力：LLM 的上下文窗口有限，难以处理超长文本，而 RAG 可以分段检索相关信息，并将重要片段提供给 LLM，从而提高长文档的分析能力。例如，在法律案件分析中，RAG 可以从海量判例中检索关键案例，而不是让 LLM 直接处理整个数据库。

• 增强数据安全性：企业往往不愿意将私有数据上传到第三方 LLM 平台，而 RAG 允许模型在本地或私有云环境中访问内部数据，避免数据泄露风险。例如，某些金融机构可以利用 RAG 构建私有化的 AI 助手，而无需担心数据安全问题。

2.3 RAG 与其他方案的对比

从对比可以看出，RAG 结合了信息检索的强大能力，为 LLM 赋能，使其能够访问最新、权威的信息，同时避免了高昂的训练成本。

2.4 RAG 的核心技术

RAG 主要由以下三个模块组成：

1. 增强数据处理

   • 对文本、图片、音频等多模态数据进行预处理。如 OCR 解析 png、jpg、PDF，文本解析 docx、pptx、html、json 等。
   • 进行数据切分、去重、向量化转换，提高检索效率。如文本向量化，多模态支持（clip 等图片 Embedding）

2. 增强语义检索

   • 采用向量搜索（Vector Search）提高检索精准度。
   • 结合混合搜索（Hybrid Search）实现关键词和语义匹配。

3. 增强召回

   • 通过精细排序算法优化检索结果。
   • 结合知识图谱、推理引擎增强答案的准确性。

除此之外，一般 RAG 的服务商还会支持私有化部署、多租户隔离和访问控制等安全控制能力。

以在阿里云 PAI 平台构建 RAG 问答系统为例，有以下 4 种方案：

• Retrieval：直接从向量数据库中检索并返回 Top K 条相似结果。
• LLM：直接使用LLM回答。
• Chat(Web Search)：根据用户提问自动判断是否需要联网搜索，如果联网搜索，将搜索结果和用户问题一并输入大语言模型服务。使用联网搜索需要给EAS配置公网连接。
• Chat(Knowledge Base)：将向量数据库检索返回的结果与用户问题合并填充至已选择的 Prompt 模板中，一并输入大语言模型服务进行处理，从中获取问答结果。

2.5 RAG 的应用场景

RAG 适用于需要高精准度、实时性、可追溯性的 AI 任务，广泛应用于 智能搜索、知识管理、内容生成、教育培训、法律/医疗检索等领域。例如：

• 智能客服：结合企业知识库，实现实时检索 + LLM 生成，提供更精准、动态的客服回复。如银行客服可以基于最新政策，提供个性化贷款咨询，而非仅限于静态文档。
• 内容创作：结合外部数据源，自动生成高质量内容，提升创作效率。如电商平台可利用 RAG 生成符合 SEO 规则的商品描述，提高搜索排名。
• 知识管理：结合全文检索 + 语义搜索，快速查找相关文档，并生成摘要。如律师事务所可基于以往案例库，高效检索相关判例，提高办案效率。
• 教育培训：结合课程内容，自动生成个性化练习题、案例分析、教学材料。如在线教育平台可根据学生的知识点掌握情况，动态调整练习内容。
• 智能搜索引擎：结合 LLM 和 RAG，实现更自然的搜索体验。

3. 小结

RAG 作为 LLM 的重要补充，极大地扩展了大模型的能力边界，使其能够动态获取最新信息、降低幻觉、支持私有数据访问，并增强内容的可追溯性。随着 AI 技术的不断发展，RAG 预计将在搜索、问答、智能助手等领域发挥越来越重要的作用，为 LLM 提供更强的知识支撑和应用落地能力。

以上。