Bandit

假设你测试三个方案：

A 得分 8.5，B 得分 8.2，C 得分 6.0。

最直接的算法当然是以后永远选 A。

但问题是，C 也许真正的长期水平是 9.5，只是第一次恰好表现不好。

如果以后再也不给 C 机会，系统永远不会知道自己错了。

所以 Bandit 有一个很重要的思想：

一个好的决策系统，不能只利用已经知道的答案，还必须保留探索未知答案的能力。

最简单的做法就是 ε-greedy。

比如 90% 的时候选择目前最好的方案，10% 的时候随机尝试其他方案。

看起来很简单，但它解决了一个非常重要的问题：

如何避免系统因为早期判断错误，永远困在一个局部最优解里。

这套逻辑放进 Router 里就很好理解了。

假设一个 Router 后面有三个模型：

A 最强，但最贵。

B 能力不错，价格适中。

C 很便宜，但能力一般。

传统 Router 可以直接写规则：

复杂任务用 A，普通任务用 B，简单任务用 C。

但问题是，这些规则本质上是人提前猜出来的。

Bandit 的思路不同。

它会让系统在真实请求中不断尝试，然后根据反馈更新自己的判断。

比如某类摘要任务：

A 的质量是 95，但成本很高；

B 的质量是 92，但成本只有 A 的十分之一；

C 的质量是 80，虽然便宜，但明显不够用。

如果 Reward 同时考虑：

质量、成本、延迟、失败率，

那么最后 B 可能才是真正的最优选择。

系统运行得越久，就越知道不同模型到底擅长什么。

于是 Router 开始从：

“按照规则选模型”

逐渐变成：

“根据真实反馈学会选模型”。

这就是 Adaptive Router 和 Bandit 真正连接起来的地方。

普通 Bandit 还在问：

哪个模型最好？

但现实世界里，这个问题本身就不太成立。

一个模型可能最擅长代码，另一个擅长翻译，还有一个做摘要性价比最高。

所以真正有价值的问题应该是：

在当前这个 Context 下，应该选谁？

这就是 Contextual Bandit。

Context 可以包括：

任务类型、Prompt 长度、用户等级、预算要求、延迟要求，甚至是否需要 RAG 或 Tool Calling。

系统真正学习的，不再是：

“哪个模型最好”。

而是：

“什么情况下，什么选择最好。”

这其实已经非常接近一个真正的决策系统了。

Bandit 本身并不知道什么叫“好”。

它只会不断优化你给它的 Reward。

如果 Reward 只看质量，它会倾向于最强模型。

如果 Reward 只看成本，它会疯狂使用便宜模型。

如果 Reward 是：

质量 - 成本 - 延迟 - 失败率

它才会开始寻找真正意义上的性价比。

所以一个 Adaptive Router 最核心的问题，最后可能不是：

用了什么 Bandit 算法？

而是：

你到底把什么定义成“好”？

因为你奖励什么，系统最终就会变成什么。

Rule-based Router 的逻辑是：

人告诉机器怎么选。

Bandit 的逻辑是：

机器根据反馈逐渐学会怎么选。

Contextual Bandit 再进一步：

机器学会在不同情况下做不同选择。

到了这里，Router 做的事情其实已经不只是“路由”。

未来它还可能决定：

要不要用 RAG，要不要调用工具，要不要并行验证，要不要走缓存，要不要为了成本降级。

它真正开始做的，是 Decision。

所以 Bandit 最值得关注的地方，并不只是一个算法。

而是它让系统第一次拥有了一种很重要的能力：

在不知道正确答案的情况下，通过不断试错，越来越会做选择。