大多数企业的 RAG（检索增强生成）管道，其实都是“瘸子”。
它们被训练得只会做一种动作——要么擅长简单的查找，要么擅长跨文档总结。一旦遇到那种需要多步推理、还得在乱七八糟的内部数据里翻箱倒柜的复杂任务，它们就会**“隐秘失败”**。
什么叫隐秘失败？就是模型给你吐出一个一本正经的胡说八道，你还得在后面给它擦屁股。
Databricks 觉得这事儿不能再忍了。他们搞了个叫 KARL 的新玩意儿，全称 Knowledge Agents via Reinforcement Learning。这名字听着挺学术，但成绩单确实吓人：
在自建的 KARLBench 基准测试上，它追平了 Claude Opus 4.6 的性能，但查询成本便宜了 33%，延迟降低了 47%。
最离谱的是，这玩意儿完全是用合成数据训练的，没用任何人工标注。
告别“偏科生”，RAG 需要六边形战士
说实话，企业数据哪有那么规整？
Databricks 的首席 AI 科学家 Jonathan Frankle 直接指出了痛点：现在的模型，要么只会做有标准答案的题，要么就是“偏科”。
"我们在 KARL 上做的任务，也就是大多数企业的日常任务，并没有严格的正确答案。"
比如，你要从产品经理那堆碎得不能再碎的会议记录里合成一份情报，或者从支离破碎的客户记录里复盘一笔竞争交易的输赢。这种事儿，根本没有标准答案让系统去自动核对。
为了测试 KARL，Databricks 甚至专门搞了个 KARLBench，涵盖了六种企业搜索行为：约束驱动的实体搜索、跨文档报告合成、长文档遍历、穷举式实体检索……
结果有点意思。
如果你只拿其中一种任务训练模型，再去测其他五种，效果一塌糊涂。但 KARL 这种多任务强化学习训练出来的模型，哪怕只训练了六种任务里的两种，剩下的四种没见过的任务，它照样能扛得住。
这才是真正的泛化能力。
RAG Plus Plus Plus... 也就是 200 次向量调用
老实讲，KARL 这一套有点“暴力美学”的意思。
Frankle 把它称为“接地气推理”。啥意思呢？就是模型在推理的时候，每一步都得死死扣住检索到的事实。
你可以把它理解成 RAG，但它是 RAG ++++++。
有多夸张？有些任务，KARL 能一口气调用 200 次 向量数据库。它得不断细化搜索、核实细节、交叉引用文档，最后才敢给你一个答案。
这时候问题来了，上下文窗口（Context Window）再大也扛不住这么造啊。
Databricks 的做法很绝：让模型自己学会压缩。
他们没去训练额外的摘要模型，而是直接让 KARL 通过强化学习自己悟。上下文太长了？自己压缩，然后继续干活。唯一的信号就是最后的任务奖励。
效果立竿见影。如果把这套“自学成才”的压缩机制拿掉，基准测试准确率直接从 57% 掉到 39%。
Frankle 对此很得意：
"我们就让模型自己琢磨怎么压缩上下文，结果效果出奇的好。"
OAPL：让强化学习不再“娇气”
这背后的功臣是一个叫 OAPL 的新算法。
这名字听着就头大，但你只需要知道一点：它解决了分布式训练里的“不同步”问题。
以前的大模型强化学习，就像强迫症，要求生成数据的模型和正在更新的模型必须同步。但在分布式训练里，这根本做不到。以前的算法用重要性采样去修正，结果搞得方差大、不稳定。
OAPL 倒好，直接拥抱这种“不同步”。哪怕策略滞后了 400 个梯度步，它依然稳得一批。
这带来了什么好处？省钱。
因为能复用以前收集的数据，不用每次更新都重新生成，整个 KARL 的训练只用了几千个 GPU 小时。这跟那些烧钱烧到天际的大模型训练比起来，简直就是“勤俭持家”的典范。
学会“放弃”，也是一种智慧
有意思的是，KARL 还有个反直觉的“缺点”：它会半途而废。
有些查询，模型搜着搜着就不干了，直接停下来不输出答案。
Frankle 倒是很坦诚，说这确实是失败模式之一，但他话锋一转：
"最贵的查询通常就是模型做错的那部分。停下来往往是正确的选择。"
这观点挺犀利。与其硬着头皮编一个错得离谱的答案浪费算力，不如承认“这题太难，我不做了”。
当然，KARL 也不是万能的。它现在还只懂向量搜索，SQL 查询、文件搜索、Python 计算这些技能还在路线图上没实装。而且遇到那种本身就模棱两可、有多个合理答案的问题，它也会犯迷糊。
别只盯着 API 成本，懂业务才是硬道理
看完这篇报告，我觉得企业数据团队得重新审视一下手里的 RAG 架构了。
如果你的 RAG 智能体只针对一种搜索行为做了优化，那它在其他场景下大概率是在“裸奔”。
Databricks 还做了一个对比实验：用监督微调（SFT）从专家模型里蒸馏。结果呢？在见过的任务上表现还行，遇到没见过的任务，几乎零提升。
这说明什么？强化学习（RL）带来的泛化能力，才是企业应对杂乱数据和不可预测查询的护城河。
构建一个懂业务、会搜索、知道什么时候该放弃的专用 Agent，远比把所有请求都扔给通用大模型 API 要靠谱得多。
毕竟，这不仅仅是钱的事儿，更是让模型真正学会“干活”。
【glm-5锐评】：KARL 用 RL 教会了模型“自己动手丰衣足食”，甚至学会了“知难而退”，这比那些只会硬编答案的大模型更像一个成熟的打工人。
参考链接：
https://venturebeat.com/data/databricks-built-a-rag-agent-it-says-can-handle-every-kind-of-enterprise