朴素 RAG 上生产，头一个坑就栽在「只认手册」
把大模型接进企业知识库，最省事的办法是朴素 RAG：把手册、规范往向量库一塞，来个问题就检索、生成。可真到了生产环境，这类系统往往头一个跟头就栽在「只认手册、不认历史」上。被报道在生产环境部署的 Uber 红线审查智能体，走的正是这样一条从失败里长出来的路。它最早的版本就是朴素 RAG，直接检索谈判手册来给合同红线提意见，结果不够用。问题不在模型聪不聪明，而在于它手里只有抽象规则，没有「上一次类似情况是怎么处理的」这种具体参照。
第二版的做法务实很多：它去检索大约 20 条相似的历史决策，每条都带着对手方的文本、律师的改动、最终动作和备注，并且给这些案例加了 365 天的半衰期——越久的参考权重越低——同时刻意平衡同意和不同意两类样本，免得模型只学出一种结论。到了第三版，又补了一次「假设它有漏洞」的自检调用，让模型在交稿前先自己挑刺。从朴素 RAG 到带半衰期与平衡样本的相似案例，再到自检，这条路径看着朴素，却是生产环境 RAG 智能体最容易被忽视的进化方向。
为什么是这三步，而不是一招鲜
值得拆开看的是，三代的每一步都在补前一版的某种缺失：相似案例补的是「具体参照」，半衰期补的是「时效性权重」，平衡样本补的是「不被单一口径带偏」，自检调用补的是「交付前自己挑刺」。它们不是叠加花活，而是各自堵一个具体的失效点。对企业来说，真正该学的不是照搬这套配置，而是这个思路——先把失败拆开，再针对每一类失效单独加一道闸，而不是指望一个更聪明的底座解决所有问题。
可复核，比「更聪明」更先落地
这条演进的共性，是用相似案例、半衰期和平衡样本，把朴素 RAG 从黑箱知识变成可复核的流程。平衡样本这一步尤其关键：如果历史里清一色都是某一种处理口径，模型很容易把偏见当成铁律，而掺进不同意样本，等于强行给它留出反驳的空间。自检调用则是最后一道闸，逼着模型在交付前先假设自己错了。
需要说清楚的是，上面这些细节来自工程侧的复盘转述，Uber 官方并没有把完整实现摊开。但即便当作一个方法论样本，它也讲明白了一件事：企业里真正能站住的 RAG 智能体，往往不是靠把底座换得更猛，而是靠把知识组织成「可被复核、可被反驳、可被追溯」的样子。朴素 RAG 是起点，不是终点；从黑箱到可复核，才是生产落地那道真正的门槛。