AI 编程狂飙的时代，程序员的价值在哪里？该走向何方？

最近新上了 Opus 4.6 ，它又给我们这帮老程序员上了一课。

在一个近一年没有迭代（指没有被封）的程序员群里，有大佬分享了如下的案例：

团队有个复杂遗留系统，典型「多线程 + 历史包袱 + 不敢动」组合。模型先给了一个方案：加锁、等待、条件变量、再加一层保护，几百行代码，逻辑像一团湿毛线。能跑，理论上也对，但你让我把这玩意儿上线？我不敢。

我让它「再想想，能不能避免这些锁和等待」。它又跑了很久，最后给了一个极简方案：之前那些锁啊等待啊都删了，思路干净到让我怀疑它刚才在干嘛。

那一刻我脑子里冒出来的不是「AI 真强」，而是一个更别扭的问题：

我到底起了什么价值？

背景上下文？它从代码库里能 infer 掉绝大多数。设计约束？很多也能从调用关系、线程模型、运行时指标推出来。所谓「design taste」？我甚至可以写成 Markdown 规则让它照做。

过去资深开发的硬价值之一是 reasoning 的过程：拆问题、找不变量、选折中、落地细节。现在模型也能做，还能做得很快。

我绕了一圈，最后落在一个很不体面的结论上：人的价值被压缩到极小概率的「否决权」里。

99% 的时候，我是在给 AI 的解「盖萝卜章」：嗯，看起来没错。
剩下那 1% 的时候，我得站出来说：不行，这条路走不通，换解空间里的另一个点。

这个角色像保险。你买的时候就知道大概率用不上，但真出事的时候要能扛住。更像现在的 L2-L4 自动驾驶：人坐在方向盘前，99.9% 的时间无事可做，为了那 0.1% 的「可能发生也可能不发生」。

问题来了：这 1% 会不会也被另一个 agent 替掉？再给一个「专职 reviewer」去 challenge 写代码的 agent，让它把那 1% 找出来。

那人还剩什么？

以及这会把程序员的岗位推向哪里。

很多讨论卡在「AI 写代码快，所以程序员要失业」这种口号里。工程上更真实的变化是两条曲线的剪刀差：

  • 代码生成成本下降得很快：写一段能跑的实现、补齐样板、迁移接口、写单元测试骨架，这些都接近「文本补全」。
  • 承担后果的成本上升：上线事故、性能回退、并发死锁、数据一致性破坏、合规风险、供应链安全。AI 让改动频率变高，系统的「变更面」变大，出事概率跟着涨。

我现在看 AI 产出的 patch，经常有一种荒诞感：
改动本身很漂亮，解释也很漂亮，真正要命的点藏在「系统级不变量」里，而那部分恰好最难被 prompt 描述清楚，也最难被静态检查覆盖。

所以讨论「程序员价值」别从「写代码」切入，从「为系统负责」切入。写代码只是责任链条里最便宜的一环。

聊回到前面大佬分享的案例。

为什么模型会先给「复杂加锁方案」，再给「极简方案」

这不是模型「变聪明了」，更像搜索策略切换。

我自己复盘过很多次类似现象，模型第一次给复杂方案，常见原因有几类：

  • 目标函数不清：模型默认把「不出错」权重大幅拉高，并发问题里，模型的默认倾向是「保守」：能锁就锁，能等就等。因为它无法确认你的系统允不允许重构线程模型，也不知道你能承受多少延迟和吞吐损失。一句「能不能避免」其实是在改目标函数：把「简单性」和「可维护性」的权重抬起来，把「局部可证明正确」的偏好压下去。

  • 它没拿到关键不变量：并发优化的核心不是技巧，是不变量。例如：哪些数据必须线性一致，哪些允许最终一致；哪些操作必须串行化，哪些可以交换；线程间共享状态的「所有权」到底属于谁；是否存在天然的「单 writer」路径。模型第一次通常拿不到这些，它会用锁把未知包起来。你追问一次，相当于逼它去反推不变量，或者提出重构以创造不变量。

  • 在「局部最优」里打转：遗留系统经常有局部约束：你动不了某个模块，改不了调用方，不能引入新队列，不能改变线程亲和性。

人的价值最终会被压到 1%

这事已经发生了。

如果把「写实现」交给模型，人还剩什么？

我现在更愿意把角色拆成四层，分别看哪些会被自动化吃掉：

  1. 执行层：写 CRUD、搬接口、补样板、按规范改文件结构
    这层基本被吃穿。
  2. 局部推理层：读一段代码、定位 bug、做局部重构
    这层大幅被压缩，速度优势在模型。
  3. 系统推理层：跨模块不变量、性能上界、故障模式、发布策略、回滚路径
    这层短期很难完全自动化，原因是信息不完备且目标冲突。
  4. 责任层：线上事故谁背、合规谁签、业务损失谁扛
    这层本质是组织结构问题，不是智能问题。

很多资深工程师过去主要靠第 2 层吃饭：你会拆、会想、会写出「更优雅」的实现。现在模型把这层的边际价值压得很薄，于是人的价值看起来就剩「在模型犯错时否决」。

这就引出一个很工程的问题：能不能用另一个 agent 把「否决」也自动化？

答案是：能覆盖很大一部分，但永远留洞。洞的大小取决于你怎么搭系统。

那 1% 到底是什么：哪些场景必须有人类 override

我现在把「必须 override」的场景分成几类，每一类都对应一套工程信号。我们可以用这些信号去训练 reviewer agent，也可以用来提醒自己别当「只会点 approve 的人」。

  • 需求语义存在空洞，代码再正确也没意义：常见现象： PR 描述是「修复偶现 bug」，但没有可复现条件，没有失败判据；业务方说「按之前逻辑」，但「之前逻辑」存在灰度分支、历史例外。这类问题 AI 很难凭空补齐。它会把空洞当成「默认值」，然后写出一份自洽的实现。你看起来也挑不出毛病，直到线上行为偏了。override 的动作往往不是改代码，而是卡住合并，逼需求补齐验收条件和反例。
  • 系统级不变量被破坏，局部看不出，全局会炸：典型不变量：

    • 计费、库存、资金流的幂等与去重
    • 订单状态机的单向性
    • 写路径单 writer，读路径可并发
    • 缓存一致性策略：写穿、失效、双写窗口
    • SLA 约束下的超时与重试预算

模型能理解这些词，但它很难知道「你们公司真实的不变量是什么」。很多不变量写在事故复盘里，写在某个老同事的脑子里，写在那段「不要动」的注释里。

override 的动作通常是把不变量显式化：写进 ADR（架构决策记录）、写进测试、写进发布 checklist。写完再让模型改。

  • 代价函数冲突：延迟、吞吐、成本、可维护性互相打架这些对尾延迟很要命。你让它「简单化」以后，它可能会走向另一个极端：过度重构，侵入面太大，风险高得离谱。这类冲突靠 prompt 很难一次调对，得靠基准测试 + 真实流量回放。人类 override 的价值在于：你知道线上哪条曲线最敏感，知道预算是多少，知道哪里可以牺牲。

  • 生产环境的「脏现实」：测试覆盖不到 包括但不限于：

  • 时钟漂移、时区、闰秒
  • 依赖服务的抖动、限流、半开连接
  • 数据脏写、历史脏数据格式
  • 热点 key、倾斜分片、长尾用户行为
  • 灰度期间的双版本共存

AI 可以写出很干净的逻辑，干净得像从未上过线。

人类 override 的价值在于：你知道哪些脏东西真实存在，知道一旦触发会损失多少钱。

  • 安全与合规：模型会「帮你越线」

安全问题里最阴的是「看起来像优化」：

  • 为了排查问题把敏感字段打进日志
  • 为了方便把权限校验挪到上层，结果漏掉某些调用路径
  • 为了提高命中率调整缓存 key，结果造成跨租户数据串读

这类问题 reviewer agent 能抓一部分，靠规则匹配和数据流分析。但组织里真正要命的合规约束往往来自外部：合同、监管、审计口径。模型很难内建你们的合同条款。

只留了 1%，那么大公司删人游戏才刚开始，接下来组织会怎么变？有前司裁员了一半。

AI 带来了两件具体的事：

  • 单位时间的变更量上升
  • 对稳定性与合规的要求不会下降

组织会自然把资源往两端挤压：

  • 一端是「产出变更」的能力：更少的人能产出更多 patch
  • 另一端是「控制风险」的能力：测试、发布、SRE、安全、平台工程会更吃香

中间那层「靠手写实现体现资深」的位置，会被挤得很难受。我们会看到更多岗位变成：

  • 平台/工具链负责人
  • 质量与发布工程负责人
  • 架构与技术治理（不变量、规范、依赖治理）
  • 领域负责人（把业务语义写成可执行的约束）

如果还把价值押在「我写得快、我写得优雅」，会被模型直接碾过去。

那我们该何去何从？

我更建议把自己训练成「系统负责人」，别训练成「提示词手艺人」

很多人看到 AI 就去卷 prompt。prompt 当然有用，但它属于「表达能力」，不属于「护城河」。

我更建议把成长路线拆成三条，按你自己的背景选一条主线，另外两条补短板。

路线 A：系统与可靠性（适合后端、架构、TL） 要能回答这些问题：

  • 这个系统的核心不变量是什么？写在哪里？谁维护？
  • 出了事故，最可能的故障模式是哪几类？怎么提前打点？
  • 一次改动上线，回滚点在哪里？数据怎么保证不被写坏？

这条路线的硬技能是：可观测性、故障注入、容量规划、发布治理、数据一致性策略。
AI 会让这条路线更值钱，因为改动变多，风险更高。

路线 B：平台与工具链（适合喜欢搞基建的人） 把「盖章」自动化掉。

要能把下面这些做成产品：

  • 代码生成与改动的规范化输入（任务模板、约束模板）
  • 自动化评审（多 agent + 规则 + 静态分析 + 安全扫描）
  • 针对你们域的测试体系（尤其是并发、回归、流量回放）
  • 一键灰度、一键回滚、发布可视化

这条路线的本质是：把工程经验固化成流水线能力。模型越强，平台越重要。

路线 C：领域语义与业务工程（适合对业务理解深的人） AI 最弱的地方之一是「公司特有的业务语义」。能把语义变成约束，价值就会变硬。

要能做的是：

  • 把业务规则写成状态机与不变量
  • 把验收条件变成测试与监控
  • 把历史例外收敛掉，减少「口口相传」

这条路线听上去不像「技术」，但在 AI 时代，它会决定你是不是不可替代的那批人。

我不押「永远需要人」这种安全说法。我更愿意给一个工程化的判断：

  • 在约束清晰、环境封闭、回滚容易的系统里，人类接管的概率会持续下降。很多内部工具、数据管道、非核心链路会率先做到「几乎无人值守」。
  • 在约束隐含、环境开放、后果昂贵的系统里，1% 会长期存在。典型是资金、合规、核心交易链路、跨组织协作系统。这里的问题从来不只是智能，还包括责任与审计。

更关键的一点：就算模型能覆盖 99.99%，组织也未必允许完全无人。原因很现实：责任链条需要一个签字的人。

我写到这里，还是没法给一个让人舒服的答案。AI 把很多我们曾经引以为傲的能力变成了廉价品，这是事实。难受也正常。

但工程世界一向认结果。模型写得再快，只要系统一炸，组织就会把注意力拉回到「谁能把它跑住」。把自己训练成能跑住系统的人，价值就不会跟着 token 价格一起下跌。

以上。

AI Agent 的长期记忆：我在工程落地里踩过的坑、做过的取舍

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

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

钩子名称 触发时机 核心作用
context-hook 会话启动时 注入最近记忆作为上下文
new-hook 用户提问时 创建新会话并保存提示词
save-hook 工具执行后 捕获文件读写等操作记录
summary-hook 会话结束时 生成 AI 摘要并持久化存储
cleanup-hook 停止指令时 清理临时数据

我自己的经验：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 优化常用的 5 种策略

做 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 的位置分布（越靠前越好）
  • 答案层指标：带引用的正确率、引用的可追溯性（页码/条款号/表格位置）
  • 线上指标：无答案率、澄清率、人工升级率、重复追问率

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

以上。