跳转至

P1-3.1 规则式系统的优势与限制

Section ID: P1-3.1 Version: v2026.07.20

2.1 已经从历史位置上介绍了符号主义 AI(symbolic AI) 与规则式方法(rule-based approach)。2.3 又说明:即使在同一条业务流程里,也会出现 像政策条件那样容易显式写成规则的部分,以及 像意图分类那样需要从数据中学习关系的部分。这一节把问题再缩小一步,整理真正的规则式系统(rule-based system)究竟有哪些优势,又会在什么地方暴露出限制。

这里要做的,不是把规则式 AI 断定成过去失败的方法,而是把三件事分开:为什么规则式系统曾经有用,为什么后来关注点会转向机器学习(machine learning),以及今天仍有哪些部分必须依赖规则。

在 Part 1 中,rule-based system 的优势、限制与现代运行角色,以这一节为基准。symbolic AIrule-based approachknowledge representation 的基本含义已经在 2.1 先固定,这里只在评价真实系统为什么在某些地方有用、在某些地方困难时,按需要重新连接。

这一节整理以下问题:

  • 规则式系统由哪些组成部分构成?
  • 这种方法的优势和限制分别出现在哪里?
  • 为什么现代系统里规则仍然必要?

这一节先固定 规则式系统在哪里强,又在哪里变得困难。从数据中学习模式的脉络,会在 P1-3.2 继续展开;和表征学习的差异,会在 P1-3.3 更具体地展开;规则与模型一起使用的运行结构,会在 Part 6 与 Part 7 继续连接。

评估规则式系统的基准

  • 理解规则式系统的基本组成部分。
  • 看清规则式系统为什么在可解释性与可控性上很强。
  • 区分专家系统历史展示出的可能性与限制。
  • 理解为什么写规则、获取知识与管理例外会变得困难。
  • 先固定一个现代服务里规则与模型如何共存的简化图景。

先连起来的概念

这一节是把规则式系统读成真实运行结构的代表位置。下面这些概念先按角色固定;如果需要更完整定义,再直接回到对应术语条目。

概念 这里先固定的意思 为什么现在需要
rule-based system 把当前事实与规则相对照,从而决定结论或行动的系统 为了先把评价对象本身说清楚
fact 在当前情境中被当作真的状态信息 为了看清规则究竟作用在什么之上
knowledge base 汇集事实、规则与领域知识的结构 为了看清规则集合存放在哪里
inference engine 找出并应用与当前事实匹配规则的机制 为了看清结论究竟是怎样产生的
explanation facility 展示某个结果是由哪些规则导致的功能 为了固定规则式系统的重要优势之一:可解释性

三个基准

这一节是在评价规则式系统。下面三个基准是评价的底线。

基准 为什么重要 这一节需要达到的理解程度
规则式系统通过连接 current factsrules 来产出结论 这样能先固定基本结构。 区分输入、规则与结果三者的位置。
它的强项是 explainabilitycontrollability 这样才能理解为什么规则至今仍留在政策与运营层。 理解为什么系统处理原因更容易被追踪。
它的主要限制是 例外和变化会让规则管理变难 这样会自然连到为什么后来转向机器学习。 理解它为什么适合窄域问题,而更难覆盖复杂现实。

规则式系统的基本结构

规则式系统会把当前事实(fact) 或输入(input) 与规则(rule) 相匹配,然后决定结论(conclusion)、分类(classification)、行动(action) 或处理流程。

它的基本结构可以先这样来读。

current facts + rule set -> inference engine -> conclusion or action

再展开一点,就会需要下面这些要素。

组成部分 英文表达 作用
facts facts 当前输入、观测值、用户状态或业务数据
rules rules 说明在什么条件下应得出什么结论或行动的知识
knowledge base knowledge base 存放事实、规则与领域知识的结构
inference engine inference engine 找到并应用与当前事实匹配规则的机制
explanation facility explanation facility 展示哪些规则导致了结论的功能

Buchanan 与 Shortliffe 关于 MYCIN 的书,把 MYCIN 视为规则式专家系统的代表实验。在那份材料里,知识库、规则、推理过程、解释功能以及不确定性处理,都被当成不同组成部分来讨论。也就是说,专家系统不只是一个堆满 IF-THEN 语句的程序,而是一个研究“如何表示、应用并解释领域知识”的系统。

这些术语在一开始会显得彼此相似。用非常短的词典式方式,可以再固定成这样。

术语 极简含义 在本节例子里对应什么
fact 当前输入进来的现状 请求金额、预算余额、申请人与审批人的关系
rule 条件匹配时要遵循的判断标准 类似 如果超过 100 万韩元,就需要部门负责人审批 的句子
knowledge base 汇集事实与规则的地方 审批标准、例外规定、角色信息
inference engine 选择并应用匹配规则的部分 计算该送到哪个审批阶段的过程
explanation facility 展示结果为什么出现的部分 例如 预算充足 + 金额超阈值 -> 部门负责人审批 这样的解释

这一节首先应留下的区分是:fact 是当前状态rule 是判断标准knowledge base 是汇集它们的地方inference engine 是应用机制explanation facility 是展示理由的机制

flowchart TD
  Input[当前输入]
  事实[事实]
  KB[知识库]
  Engine[推理引擎]
  Output[结论或动作]
  Explain[解释]

  Input --> 事实
  事实 --> Engine
  KB --> Engine
  Engine --> Output
  Engine --> Explain

这个图帮助我们把规则式系统读成 当前输入 -> 整理事实 -> 与知识库对照 -> 结论 -> 解释 的流程。关键点是:系统不仅能给出结果,还经常能把“为什么会得到这个结果”一起展示出来。

例子:把审批工作写成规则

理解规则式系统最容易的例子之一,就是审批工作。审批条件相对明确,处理过程必须留痕,而且在相同条件下通常应该得到相同结果。

例如,如果把公司的采购申请处理规则简化,可以写成下面这样。

当前事实 要应用的规则 结果
请求金额不超过 10 万韩元且预算余额充足 无需组长审批,自动批准 已批准
请求金额超过 10 万韩元且不超过 100 万韩元 需要组长审批 等待组长
请求金额超过 100 万韩元 需要部门负责人审批 等待部门负责人
预算余额不足 无论金额多少都驳回 因预算不足而驳回
申请人与审批人是同一人 禁止自我审批 重新指定审批人

如果把它读成流程,大致如下。

flowchart TD
  Start[采购申请]
  Budget{预算足够吗?}
  Self{申请人与审批人相同吗?}
  Amount{申请金额}
  Reject[因预算不足而拒绝]
  Reassign[重新指定审批人]
  Auto[自动批准]
  Team[等待组长审批]
  Dept[等待部门负责人审批]

  Start --> Budget
  Budget -- No --> Reject
  Budget -- Yes --> Self
  Self -- Yes --> Reassign
  Self -- No --> Amount
  Amount -- 低于 10 万韩元 --> Auto
  Amount -- 低于 100 万韩元 --> Team
  Amount -- 高于 100 万韩元 --> Dept

这个例子很简单,但很好地展示了规则式系统的性格。规则可以被人阅读,结论可以被解释,而且如果业务政策变化,也可以修改某条具体规则。

但同一个例子一进入实际工作,很快就会复杂起来。紧急采购、公司卡例外、项目专属预算、审批人休假、审计目标品类、供应商限制等条件都会开始加入。后面讨论到的规则式系统限制,正是从这种复杂性增长中出现的。

优势 1:人能够阅读并复核

规则式系统最大的优势之一,是判断标准是显式写出来的。因为规则直接出现在文档、代码、配置或知识库中,所以人可以阅读并复核。

例如,下面这样的规则相对容易被解释为系统的判断标准。

If the payment amount exceeds the approval limit, send it to the administrator approval step.
If the user's privilege is lower than administrator, block the settings change.
If the temperature-sensor value exceeds the standard range, send an inspection alert.

这些规则未必完美,但至少当有人问 为什么系统会这样处理? 时,它们比较容易被追踪。领域专家、运营人员、审计人员与开发者也可以围绕同一条规则展开讨论。

这种优势在下面这些情境里尤其重要。

情境 为什么规则式系统有优势
法律、政策、权限 标准必须显式写清,而且变更历史很重要
审批流程 必须能解释在什么条件下该由谁审批
安全过滤 需要由人检查禁止条件与允许条件
运营自动化 必须以可预测方式反复执行条件处理
教育与诊断辅助 不仅结论重要,理由也重要

例如,当采购审批系统被问到 为什么这个请求正在等待部门负责人审批? 时,系统可以这样回答。

请求金额超过了 100 万韩元,
预算余额充足,
并且申请人与审批人不是同一人,
因此适用了部门负责人审批规则。

这种解释不是在解释隐藏的模型权重,而是在追踪哪些事实与哪些规则连接在一起。这就是为什么规则式系统非常适合审计、政策复核与运营日志。

优势 2:更容易让相同输入得到相同输出

规则式系统通常更容易做成确定性的(deterministic)。只要事实相同、规则相同,构造出相同结论就比较容易。

这一点和现代生成式 AI 构成对比。生成式 AI 即使面对同一个请求,也可能因为设置、上下文、模型状态与采样方式不同而输出不同内容。规则式系统则是在显式条件匹配时执行固定处理。

所以,规则式系统适合那些 必须遵守 的程序。

  • 没有权限就阻止访问
  • 必填值缺失就不允许进入下一步
  • 禁止的文件类型不允许上传
  • 没同意条款就不能完成注册
  • 没有运营审批就不能自动执行

在这些场景里,比起模型“差不多合理地判断”,更重要的是规则能够明确阻止或允许某个动作。

运营系统中的告警规则也是一个好例子。

当前状态 规则 结果
CPU 使用率连续 5 分钟超过 90% 发送警告告警 运营人员检查
磁盘使用率超过 95% 发送紧急告警 立即处理
支付失败率突然高于平时 标记为潜在故障 加强监控
部署后错误率超过阈值 发送回滚复核告警 部署负责人确认

这些规则即使没有预测模型,也足够有用。重要的是 在不遗漏显式条件的前提下,反复执行固定处理

但这里还要再分清一点。相同输入得到相同输出 的意思是 判断具有可复现性,不是 判断一定正确。如果规则本身写错了,或者漏掉了重要例外,那么系统也会非常稳定地重复错误结果。

区分 它表示什么 在规则式系统里的含义
reproducibility 相同条件下能再次得到相同结果 有利于审计、追踪与测试
correctness 结果是否符合真实政策或现实判断 仍需要单独复查规则本身是否正确

例如,假设某条审批规则错误地写成 所有海外法人采购都必须由总部部门负责人审批。那么在相同情境下,系统每次都会稳定地产出同样结果。但如果这个结果与公司的实际政策不一致,可复现性就高而正确性却低。也正因此,在规则式系统里,要分别检查 结果是否重复一致规则本身是否正确

优势 3:在窄域里可以很快变得有用

当问题范围较窄、标准较明确时,规则式系统可以很快产生实际价值。如果领域专家能够清楚说明判断标准,输入数据形式相对稳定,例外又不太多,那么规则就会成为强有力的工具。

专家系统很好地展示了这种可能性。DENDRAL 以利用化学知识搜索分子结构候选而闻名,MYCIN 则作为把规则与不确定性处理结合起来的感染性疾病医疗咨询系统被研究。这些案例展示出这样一种可能性:如果把领域知识表示得足够好,就能在特定问题上获得很强的效果

但不能把这些案例直接推广成现代医疗服务。MYCIN 是研究系统,临床部署与责任问题都需要单独审查。在这一节里,专家系统只被当作 展示规则式系统可能性与限制的历史案例

为了学习理解,可以把专家系统的规则简化成下面这种结构。

如果观察到的症状或检查结果满足某些条件,
就提高或降低某个可能原因候选。

如果设备振动超出标准范围,
并且距离上次维护已经很久,
就提高检查优先级。

这些并不是可以直接拿去做真实医疗诊断或设备维护的完成规则。重要的是结构本身。专家系统试图把专家拥有的判断线索放进知识库,再通过和当前观测值对照来缩小结论候选。

案例:手工设计特征与流程的限制

规则式系统的优势与限制并不只出现在专家系统中。在人曾经手工设计大量特征和流程的领域里,例如人脸识别、车道线追踪、语音合成,也能看到类似脉络。

例如,早期人脸识别方法经常依赖人脸构件的位置与距离、手工特征与模板;车道线追踪原型则经常使用 ROI(region of interest)、Canny 边缘检测与 Hough transform 等图像处理步骤。这类方法在结构简单、环境受控时容易解释,也能很快产生实际价值。

但当输入条件变得多样,限制就很快显现。光照、表情、姿态、背景、天气、噪声与例外发音等变量不断增加,人就不得不继续手工增加更多特征与步骤。另一方面,在像 TTS 这样拼写与发音规则相对结构化的领域,规则式过程又可以长时间维持实用性。

从这种比较里得到的结论很简单。

规则与手工特征,是把人已经理解的结构放进系统中的强力方法。只是当输入世界变得过于多样、例外不断增加时,人把所有特征与规则都直接设计出来的方式就会撞到极限。

应该怎样表达这条历史脉络

如果只是把规则式系统、符号主义 AI、机器学习与神经网络理解成纯粹时间顺序,就很容易产生混乱。AI 的历史更像是:随着问题类型与计算环境变化,某些方法的重要性会变强,而不是“前一种方法彻底被下一种方法替换”的单线历史。

在较早阶段,用显式表示知识并通过规则进行推理的方法尤其重要。后来,真实问题中的例外与不确定性、大规模数据、计算资源的提高以及学习算法的进步叠加在一起,使得从数据中学习模式与表征的方法变得越来越重要。在这个变化过程中,神经网络从较早存在的研究传统中再次走到中心,形成今天所说的深度学习。

因此,更合适的理解是:研究与实务的中心发生了移动,各种方法的角色也发生了变化。规则式系统并没有简单消失,更不是被神经网络一次性替换。变化的是问题种类与工程条件,因此“更常被强力使用的方法”也跟着变化。规则式系统继续在显式政策、权限、流程与验证中保持优势;机器学习与深度学习则在许多案例里,因为能从数据中学习人难以直接写出的模式与表征,而变得更中心。

物理性能的变化在这里也很关键。规则式系统往往可以在较少数据与计算资源下构造出有用系统;深度学习则需要大量数据、反复训练与并行处理能力。随着存储更便宜、数据持续积累,CPU、GPU、分布式处理环境与开源训练工具不断发展,曾经更像研究想法的神经网络方法,逐渐成为可以真正跑出性能的工程选择。在这一节,只需要先抓住:规则式系统的优势仍然保留,但复杂模式识别的中心逐渐转向学习式方法

变化 对 AI 方法的影响
数据积累与存储成本下降 增加了学习那些难以直接写成规则的模式所需的材料
并行处理与计算资源进步 改善了反复训练和比较大型学习模型的条件
工具与评估生态扩大 提高了复现、比较和改进研究结果的速度

这种关系可以总结成下面一句话。

符号主义 AI 是一个更宽的脉络,它试图显式表示知识与规则并在其上推理;规则式系统是这条脉络在真实系统中的一个代表性实现。神经网络方法并不是单纯地排在它之后的后续阶段,而是一条很早就并行存在、并在数据、计算资源与学习算法进步下重要性被大幅强化的研究流。

如果画成图,大致是这样。

flowchart TD
  Symbolic[符号 AI]
  Rule[基于规则的系统]
  Search[搜索与知识表示]
  Prob[概率推理]
  ML[机器学习]
  NN[神经网络与深度学习]
  Compute[算力与并行处理]

  Symbolic --> Rule
  Symbolic --> Search
  Search --> Prob
  Prob --> ML
  ML --> NN
  Rule -. 局限与互补 .-> ML
  Compute -. 加速 .-> ML
  Compute -. 加速 .-> NN

这张图并不表示“前一阶段消失,后一阶段完全取代它”。真实历史比这更重叠。规则式系统、搜索、概率推理、机器学习与神经网络在不同时期重要性不同,而且在现代系统中也仍然会被一起使用。

所以,更安全的读法不是把它理解成 规则式方法一下子被数据学习取代 的历史,而是理解成 随着问题与计算条件变化,说明中心发生了移动 的历史。对这一节来说,最重要的是看出:这次移动,正是因为规则式系统的优势与限制都逐渐被看得更清楚。

如果把常见误解压缩成对照,会像下面这样。

容易混淆的表达 更准确的表达
规则式方法流向了符号主义 AI 符号主义 AI 是更宽的脉络,规则式系统只是它的代表实现之一
符号主义 AI 之后才有神经网络 随着符号主义方法的限制暴露、数据式学习需求增加,早就存在的神经网络研究在深度学习中重新变强
时代变化只由想法变化解释 研究与实务中心之所以移动,是因为数据规模、物理计算性能、并行处理与工具生态一起变化
规则式方法只属于过去 规则式方法曾经是中心方法,但在现代 AI 服务里仍然被用于政策、权限、安全与验证
神经网络取代了规则 在一些识别、预测与生成问题里,神经网络大幅减少了手工规则和手工特征,但并没有消除所有规则

限制 1:获取好规则本身就很困难

规则式系统要求把知识显式写出来。所以它首先遇到的问题就是:好规则到底从哪里来?

专家确实会做很多判断,但他们不一定总能把这些判断说成简短句子。经验、例外、默会知识(tacit knowledge) 与情境判断常常混在一起。即使专家口头说出一条规则,放到真实案例中,也可能暴露出遗漏条件、与其他规则冲突,或者范围写得太窄的问题。

这个过程可以理解成知识获取(knowledge acquisition) 或知识工程(knowledge engineering)。在 MYCIN 相关研究里,把专家知识搬进系统知识库、录入规则、修改规则、解释规则以及调试规则,都是非常重要的问题。

初学者尤其容易忽略的一点是:专家判断得好这种判断很容易写成规则 并不是同一句话。举例来说,一个熟练的客服人员在看到同样的 refund 这个词时,还会同时注意:客户到底是否真的想退款、是不是在为物流延迟生气、或者是否已经在上一轮对话中得到过部分退款。但这样的判断,并不能被一条 如果出现 refund 这个词,就当成退款请求 的规则充分表达出来。这个差距,正是默会知识难以规则化的原因。

规则式系统的困难,不只是 代码要写很多。更准确地说,它会出现在下面这些方面。

困难 说明
知识获取 必须把专家判断抽出来并写成规则
表达方式选择 必须决定事实、条件、例外与结论该用什么形式表示
验证 必须检查规则在真实案例里是否成立
冲突管理 不同规则可能导出不同结论
保持新鲜度 一旦业务、政策或环境变化,规则也必须跟着变

例如,假设你想建立一条 阻止高风险交易 的规则。一开始它可能写成这样。

如果登录发生在与平时不同的国家,
并且产生了大额支付,
就要求额外认证。

但真实运行很快会带来更多问题。

问题 为什么规则会变难写
与平时不同的国家 应该怎样定义? 必须区分出差、VPN 和海外常住用户
多大金额才算 大额 不同用户的消费规模不同
额外认证失败意味着诈骗还是失误? 仅靠行为很难直接判断意图
新用户没有“平时模式”,该怎么办? 比较基准本身缺失
如果攻击者知道规则,如何避免被绕过? 固定规则会诱发规避策略

所以,一条好规则并不只是短短一句话。它往往同时需要领域知识、数据分布、例外处理与运营政策。

限制 2:例外一多,复杂度会迅速上升

规则式系统在开始时往往看起来很简单。但随着例外增加,规则集合会迅速变复杂。

例如,假设你要用规则分类客户支持请求。

如果出现 退款,就分类为退款请求。 如果出现 配送,就分类为物流咨询。

一开始这似乎已经足够,但很快就会出现例外。

“我不想退款,只想确认配送情况。” “货已经送到了,但东西破损了,我想换一件。” “这次是新订单的配送咨询,和上次退款不是同一件事。”

如果想用规则去处理所有这些例外,条件就会不断增加。随着规则变多,就必须检查:哪条规则该先应用、冲突时以什么为优先,以及新规则会不会悄悄破坏旧规则。

这正是机器学习开始有空间进入的地方。在那些人无法现实地写出全部规则的问题里,从大量例子中学习模式可能会更好。

前面的采购审批例子也存在同样的问题。

新需求 需要新增的规则
紧急故障处理采购必须快速审批 若关联故障工单,则允许临时审批
审计目标品类无论金额都必须复核 某些品类应送入审计审批步骤
审批人可能在休假 需要替代审批人规则
项目预算与部门预算可能不同 需要按预算类型规定扣减顺序
对同一供应商的采购可能在短期内集中 需要检查周期累计金额

一开始,看起来三条金额规则就足够。但一旦实际业务条件进来,规则之间就会开始相互缠绕。这时需要做的不再只是“继续加规则”,而是同时管理优先级、冲突与测试用例。

限制 3:对模糊输入和复杂模式较弱

规则式系统在标准明确的问题上很强,但对模糊输入和复杂模式可能较弱。

例如,下列问题就很难让人直接写成规则。

  • 判断照片里的物体到底是狗还是猫
  • 在考虑上下文的情况下判断一句话的情绪或意图
  • 从音频中把语音和噪声区分出来
  • 从大量用户行为中预测流失可能性
  • 生成自然的新句子或新图像

这些问题里的输入变化太多,人很难把所有有用特征都写成规则。因此,数据式学习、统计模型与深度学习之所以变强,并不是因为规则式系统 错了,而是因为问题的性质变了。

如果回到客户咨询分类例子,差异会更明显。

输入句子 简单规则的困难
“退款不用了,我只想改一下配送地址。” 虽然出现了 退款,但实际并不是退款请求
“昨天收到的商品坏了,可以重新给我寄一件吗?” 即使没有 换货 这个词,意图也可能是换货或重发
“请按上次那样处理。” 如果没有上一轮对话上下文,意义不清楚
“配送再晚的话我就取消。” 同时带有物流咨询和取消可能性

对于这样的输入,仅靠“词出现规则”是不够的。因为还要一起看语境、意图、历史记录与表达变化,所以更适合借助学习式分类模型或 LLM。

限制 4:规则本身不会学习

普通规则式系统不会自己从经验中改进规则。只有当人新增、修改或删除规则时,系统才会变化。

当然,也有研究试图自动生成或修改规则,也存在把规则式系统与学习式系统结合起来的方法。但一般规则式系统的中心仍然是显式知识:人制定判断标准,系统负责应用。

而机器学习则是使用数据与评价标准去调整模型的 parameter。这个区别可以分成下面这样。

区分 规则式系统 机器学习系统
判断标准 人写下的规则 从数据中学到的参数
改进方式 增加、修改或删除规则 通过训练数据和损失函数调整参数
复核对象 规则的有效性、冲突与遗漏 数据质量、评估性能、过拟合与偏差
强项领域 显式程序与政策 复杂模式识别与预测
弱项领域 例外很多、模式复杂的输入 需要强可解释性和强控制的程序

一个简短的适用性判断练习

看下面这些案例,先判断 规则式系统是否先天很适合规则单独很快会撞到限制,还是 规则和模型应该一起使用

案例 首先要检查的问题 按本节标准作出的第一判断
在公司内部付款流程里检查不同职级的审批额度 标准是否已经整理成明确句子? 规则式系统先天很适合
自动分类客户咨询句子中的隐藏不满意图 同一含义是否会以许多不同表达出现? 规则单独很快会撞到限制
阻止 LLM 服务检索用户无权访问的文档 允许/阻止标准是否必须被显式固定? 必须有规则式控制
根据工厂传感器数值和作业历史预测故障概率 人能否把所有模式都直接写成规则? 更可能需要模型
在文档助手生成答案前,先遮盖身份证号 这是不是必须无条件执行的安全要求? 很适合规则和模型一起使用

这个练习的关键,不是把规则式系统看成 过时方法,而是把它看成对 必须显式控制的程序 特别强的工具。相反,含义越模糊、模式越复杂,模型的角色就越大。

即使在现代系统里,规则也没有消失

现代 AI 系统并不是只由模型组成。即使是使用 LLM 的服务,也仍然需要显式规则来处理权限检查、输入校验、禁止请求、个人信息遮盖、工具调用条件、部署流程、成本上限与审计日志。

这一节不深入讲服务架构。关键点只是:即使有学到的模型,也仍然会存在必须依赖显式规则的区域。像 RAG、tool use、agent 这样的具体结构,会在 P1-14 与 Part 6 再回来说明。

例如,即使是在构建一个基于 LLM 的文档助手,也仍然需要下面这样的规则。

不检索用户无权访问的文档。
不存储包含个人信息的输入。
没有来源的答案,不得被说成事实。
没有运营审批,不得自动执行。

如果更贴近真实服务来看,可以把角色划分成下面这样。

处理阶段 更适合由规则承担的部分 更适合由模型承担的部分
输入接收 检查文件大小、权限与禁止格式 分类用户意图
检索 只检索有访问权限的文档 找出与问题相关的文档候选
答案生成 阻止无来源断言、遮盖敏感信息 用自然语言总结文档内容
工具调用 只允许执行已批准的工具与参数 提议可能需要什么工具
部署或执行 检查审批状态、运行条件与环境条件 起草变更摘要

这些规则很难交给模型,让它去 大概学着处理,因为它们和服务安全性、责任边界与运营标准直接相关。

所以,要理解现代 AI,不能只把规则式系统与机器学习放在对立面。更现实的看法是下面这句。

规则负责那些必须显式控制的程序与约束,机器学习模型负责那些人难以完全写成规则的模式识别、预测与生成问题。真实 AI 服务是通过组合这两者构建出来的。

检查清单

  • 我可以把规则式系统分解成 facts、rules、knowledge base、inference engine 与 explanation facility 来解释。
  • 我可以解释规则式系统为什么在可解释性与可控性方面很强。
  • 我可以把专家系统解释成一种历史案例:它试图用规则和知识库表示特定领域知识。
  • 我可以解释知识获取与知识工程为什么是规则式系统的重要困难。
  • 我可以解释为什么例外与规则冲突越多,维护就越困难。
  • 我可以把规则式系统与机器学习系统的差异理解成角色差异,而不是简单优劣。
  • 我可以把研究中心的移动与角色变化,连到数据规模、计算性能、并行处理与工具生态变化上去解释。
  • 我可以举出现代系统里仍然必须依赖显式规则的区域。
  • 我可以说明规则式系统是人把知识显式写出、系统再应用规则得出结论或行动的方法,并且它在可解释性、可控性与可复现性上很强。
  • 我可以说明专家的默会知识很难抽成规则,例外越多管理越复杂,而图像、语音、语言等复杂模式很难只靠规则完整处理。

出处与参考资料