Extra Cookies
By Dong ZHENG

用 LLM 做策略，最后做成了专家系统

The Expert System Trap, on LLMs

过去两年，很多数据和业务团队都在做同一件事：用 LLM 重做策略。一开始只是辅助，后来越用越深，红利也越拿越多。

最开始很简单，让 LLM 帮拆 KPI、出业务方向、写方案初稿，效率立刻可见。然后是用户分群运营，每个群一套话术、一套权益、一套节奏，比”一套方案打天下”准多了。再走一步就是千人千面：每个用户每次访问，模型现场算出适合他的内容、定价、推送动作，这是过去十几年互联网行业一直想做但做不到的事。

每细一步，业务都拿到正反馈。AI 看起来无所不能，过去做不到的精细化今天都能做到，连复杂多场景的决策好像都可以慢慢交给模型。

我自己也是这条路上的乐观者，直到最近被参与一组新方向的讨论。开了几轮会我一直有种”哪里不对”的感觉，但说不出来。直到有天我看着白板上密密麻麻的规则节点和状态迁移线，突然反应过来：

我们试图在用 LLM 重做一遍专家系统。

专家系统这个词现在没什么人提了。但在 60 到 80 年代，它就是 AI 的代名词。MYCIN 帮医生开抗生素剂量，DENDRAL 推断分子结构，XCON 给 DEC 的客户配 VAX 服务器，每年给 DEC 省几千万美元。那时候 AI 的故事就是规则加推理引擎。

这些系统几乎全是用 Lisp 写的。McCarthy 1958 年发明 Lisp 就是为了 AI，那时候 AI 基本等同于符号计算。Lisp 的几个特性放在专家系统这个场景里特别合身：

  • homoiconic，代码本身就是数据。一条规则可以被另一条规则读、改、合成。推理引擎不是在”运行代码”，是在”操作数据”，而那些数据恰好是代码。
  • macro 系统让你能写贴近业务语言的 DSL，编译时再展开成执行逻辑。每个专家系统本质上都是个领域 DSL。
  • REPL，知识工程师可以在跑着的系统里加一条规则、改一条规则、立刻看推理结果，不用重启，不用重新编译。

后来连铲子（硬件）都有了，Symbolics、LMI 这些 Lisp Machine 公司，是一整条产业链。

然后崩了。

“崩”在哪里？

第一，规则爆炸。规则到几百条还能管，到上千条之后，规则之间的相互作用没人能完全预测。新加一条不知道会触发哪些旧规则的连锁反应；改一条不知道会让哪个早就跑得好好的场景突然报错。维护成本超线性上涨。MYCIN 600 条规则，规则两两之间潜在冲突就有 18 万对。

第二，业务规则本身在变。新疾病、新产品、新法规、新例外。每次变化都要把规则集重新校准，知识工程师的吞吐永远赶不上业务的迭代速度。

第三，慢。从领域专家那里把规则一条条挖出来、写成形式化规则，从 0 到能用常常要两三年。

XCON 在 DEC 跑了 10 年，每年给公司省 4000 万美元，维护团队最后涨到 55 人专职维护规则库。最后被废弃，因为维护成本超过了它节省的钱。

AI Winter 来的时候没人觉得意外。

40 年后，LLM 的进展解决掉了一些问题。

知识获取不再是手工活。模型已经把人类的大部分领域知识吃进去，不需要知识工程师再把规则一条条挖出来形式化。

模糊匹配也不是问题。以前专家系统要写 “if 病人 age > 60 and 体温 > 38.5 then…”，LLM 直接读自然语言描述就能召回相关规则，或者直接生成规则执行代码。

这两件事是进步，还存在两个问题。

规则爆炸还在。给 LLM 挂一套结构化的规则图谱和状态机，规则之间的相互作用不会因为底层换了 Transformer 就自动变可控。规则数量过了某个门槛，调试和回归测试照样会变成噩梦。

业务规则在变，LLM 也解不了。模型再大也不知道你下个季度会上什么新产品、新策略对老规则有什么连带影响。这只能靠人维护，工作量和 30 年前没本质区别。

把 LLM 套在状态机上，相当于用一台超级跑车的引擎推一辆牛车。引擎确实好。但牛车的车轴和车轮还是 30 年前的。

那专家系统这条路是不是任何场景都不该走？也不是。

规则数量稳定、业务规则极少变化、合规驱动需要可解释和可审计的场景，专家系统其实从来没真死过，只是改了名字。银行风控的规则引擎、医疗诊疗的辅助决策、航空航天的故障树推理，都是这套范式。在这些地方加 LLM 是合理的：用 LLM 解知识获取和模糊匹配，规则集本身保持稳定，规则爆炸的问题被业务边界天然封住。

判断这条路值不值得走，看两个问题就够了：你的业务规则一年改几次，规则总数在两年后会膨胀几倍。

如果一年改十几次、规则两年翻三倍，你就是在重新走一遍 90 年代那批团队踩过的坑。

举个我自己做过的例子。用户刻画 × 用户状态 × 决策动作，构成一张极大的策略表。冷启用户和高频用户、新用户和回流用户、活跃时段和沉默时段，每个组合下推什么内容、给什么权益、走什么策略，如果用规则铺，规则集几千条起步。每加一条新业务，规则之间的相互作用就再没人能完全说清。这就是 90 年代的规则爆炸，换了一套现代的皮肤。

推荐系统的精排十年前就解过这个问题。精排不会让人手写”如果用户 age 在 25-35 且最近 7 天活跃天数 >= 3 且偏好分类是 A 则提权”，精排是把所有这些信号塞进一个模型，让模型从交互数据里把最优排序学出来。规则爆炸被一个模型替代了。

精排的范式是不枚举规则，从数据里学策略。代价是可解释性下降，好处是规则数量没有上限。

精排的范式还在往前走。这十年的精排早就不是”预测点击率、按概率排”，已经是多目标优化：CTR、完播、转化、留存、收入，几个目标同时出，业务按阶段把权重调成 0.3、0.4、0.2、0.1 这种数字。这一季要拉留存，权重往留存倾；下一季冲收入，再调回来。整套机制建立在显式损失函数、可导优化器、日级反馈回灌之上。

那把”用户刻画 × 用户状态”喂给 LLM，让它直接生成决策动作，能不能解决多目标优化？

我的判断是不能，至少不是 LLM 当下的强项。LLM 推理的目标函数是预测下一个 token，“偏好”嵌在 RLHF 训练好的权重里，不是你能在 prompt 里写 0.3、0.4、0.2、0.1 然后 LLM 就照做的。告诉它”平衡点击和留存”，它能说出听起来合理的话，但精度上不会区分 0.3 和 0.35 的差别。更要命的是反馈回灌：精排一晚上能基于昨天的曝光-点击数据重训一遍，LLM 做不到，业务 KPI 的梯度回不到模型里。

LLM 在这个场景能做的是定性的活：解释为什么这个内容适合这个用户、识别要谨慎的边界、补足数据稀疏的长尾。这些是对精排的增强，不是替代。多目标优化仍然是 ML 的主场。

LLM 时代的做法是分三层。排序模型决定”推什么”：组合爆炸的策略空间、多目标优化的权重调度，这是 ML 的主场。LLM 负责”用户是谁、内容是什么”，把开放式语义、跨边界整合、规则穷尽不了的长尾，翻译成排序模型能用的特征。规则引擎守住”不能做什么”：商业许可、合规边界，硬约束不能交给概率模型。状态机如果还要用，只能落在第三层做硬约束。它的位置是约束，不是决策。

把 LLM 喂给一个状态机让它跑规则，既关掉了 LLM 的强项，也绕开了 ML 早就解过的问题。说到底，是范式选错了。

最后说个花絮。当时讨论技术方案，Scala 跃然纸上，觉得它简直就是为这种规则加状态的系统准备的：代码即规则、声明式的转换、函数式第一性等等。

后来我反应过来，这些特性都不是 Scala 的发明，Lisp 40 年前就在用，那一代的专家系统就是用 Lisp 写出来的。我们以为是发现了一门趁手的新工具，其实是问题把我们领回了 40 年前。