大模型 vs 规则引擎怎么选?
结构化决策任务下大模型的优劣势与适用场景分析
原题：在面对结构化决策任务时，相比传统的规则引擎，大模型有哪些优势和劣势？在什么场景下更适合使用大模型而非规则系统？
项目与经历 · 百度真题
回答与解析
结构化决策中，规则引擎并不只适合短流程。只要条件、状态和转移能明确表达，规则或工作流完全可以执行很长的确定性决策链，并记录每个分支。它的优势是可复现、可审计、延迟稳定；问题是需求频繁变化时规则维护、冲突管理和非结构化输入解析可能很重。
大模型的优势主要在语义层。它可以从邮件、合同、客服对话或自然语言政策中抽取字段，识别意图，生成候选解释，并处理规则难以枚举的表达变化。但它的输出会受prompt和上下文影响，可能遗漏条件或生成不存在的依据，不适合直接承担不可逆的最终决策。
因此我会按职责拆层：大模型负责把非结构化输入转换成带证据的结构化候选，确定性校验检查格式、权限和硬约束，规则或工作流执行可审计决策，高风险边界交给人工。模型建议与最终动作之间要有明确接口，而不是让一段自然语言推理直接调用核心系统。
模型自报置信不能直接当概率使用。即使输出一个分数，也要在代表性验证集上校准，并按类别与分布漂移检查。更稳妥的是结合证据完整性、规则冲突、输入是否分布外和多模型或人工复核，设计拒绝与升级机制。关键交易不能因为模型说很确定就绕过审批。
何时更适合大模型，要看问题主要成本是否来自语义理解。如果输入已经结构化、规则稳定且错误成本高，规则通常更合适；若大量人工时间消耗在理解自然语言和整理候选，大模型可作为前置层。规则频繁变化也不必自动换模型，可能只需更好的决策表和版本管理。
评测会分别测字段抽取、候选召回、规则执行正确率、端到端决策、延迟和高风险错误，并保留每次输入、证据、模型版本和审批记录。这样既利用大模型的灵活性，也让确定性长链留在可验证系统中。
口语版讲法(约4分钟)
- 按输入与决策性质比较
- 纠正规则无法处理长链的误解
- 限定大模型适用环节
- 处理置信校准和拒绝
- 设计可审计混合流程
结构化决策中，规则引擎并不只适合短流程。只要条件、状态和转移能明确表达，规则或工作流完全可以执行很长的确定性决策链，并记录每个分支。它的优势是可复现、可审计、延迟稳定；问题是需求频繁变化时规则维护、冲突管理和非结构化输入解析可能很重。
大模型的优势主要在语义层。它可以从邮件、合同、客服对话或自然语言政策中抽取字段，识别意图，生成候选解释，并处理规则难以枚举的表达变化。但它的输出会受prompt和上下文影响，可能遗漏条件或生成不存在的依据，不适合直接承担不可逆的最终决策。
因此我会按职责拆层：大模型负责把非结构化输入转换成带证据的结构化候选，确定性校验检查格式、权限和硬约束，规则或工作流执行可审计决策，高风险边界交给人工。模型建议与最终动作之间要有明确接口，而不是让一段自然语言推理直接调用核心系统。
模型自报置信不能直接当概率使用。即使输出一个分数，也要在代表性验证集上校准，并按类别与分布漂移检查。更稳妥的是结合证据完整性、规则冲突、输入是否分布外和多模型或人工复核，设计拒绝与升级机制。关键交易不能因为模型说很确定就绕过审批。
何时更适合大模型，要看问题主要成本是否来自语义理解。如果输入已经结构化、规则稳定且错误成本高，规则通常更合适；若大量人工时间消耗在理解自然语言和整理候选，大模型可作为前置层。规则频繁变化也不必自动换模型，可能只需更好的决策表和版本管理。
评测会分别测字段抽取、候选召回、规则执行正确率、端到端决策、延迟和高风险错误，并保留每次输入、证据、模型版本和审批记录。这样既利用大模型的灵活性，也让确定性长链留在可验证系统中。
混合系统还需处理版本变化。模型、prompt、规则表和业务政策任一更新，都可能改变端到端结果，所以要对组合版本做回归，而不是单测某一层。决策日志应能回答模型提取了什么、哪些规则命中、谁批准了动作。可追溯性是结构化决策上线的基本条件。
关键一句:为什么未校准的大模型置信分数不能作为最终结构化决策依据。
核验来源
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做电商的订单审核系统，之前可能用规则引擎判断异常订单，现在客户想试试大模型。你觉得跟规则比，大模型优势和劣势分别在哪？
- 问法 2 · 层层追问
结构化决策任务，比如判断一个订单是否欺诈，传统上怎么做的？……如果换成大模型呢？……那现在让你选，什么场景下你非要用大模型而不是规则系统？
- 问法 3 · 直球架构
聊聊大模型和规则引擎在结构化决策上的对比。优势劣势都说一下，然后告诉我什么场景下该优先选大模型，什么场景下还是规则靠谱。