从自然语言规则到 DMN 1.5：伏羲智能决策平台如何落地企业决策自动化

2026-09-05 49 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：9 分钟

企业决策系统真正困难的部分，往往不是执行一条规则，而是让业务人员能写、技术人员能审、测试人员能验，并且在发布后还能追溯每次结果。伏羲智能决策平台第一版尝试把这条链路打通：用户用自然语言描述业务规则，LLM 智能体生成结构化 DSL，系统经过多层校验后编译为标准 DMN 1.5 XML，再进入版本管理、业务验收、发布运行和数据分析流程。

自然语言不是最终规则，而是建模入口

让业务人员直接描述“年龄大于 18 岁且风险等级不高时允许开户”，确实能降低 DMN、FEEL 和内部 DSL 的学习成本。但在企业环境中，自然语言存在歧义，不能直接成为生产执行依据。

更可靠的链路应当分成几个阶段：

  1. 提取业务概念：识别输入字段、输出字段、数据类型和枚举范围。
  2. 生成结构化 DSL：把自然语言转换成可解析、可比较的中间表示。
  3. 执行多层校验：检查语法、类型、规则覆盖、冲突和不可达分支。
  4. 编译为 DMN 1.5 XML：形成可交换、可审计的标准产物。
  5. 由业务人员验收：通过代表性案例确认规则含义，而不是只确认文件能编译。

这里最重要的边界是：LLM 负责提高建模效率，结构化校验和验收流程负责决定规则能否进入生产。模型生成成功，不等于业务规则正确。

为什么要以 DSL 和 DMN 作为双层契约

结构化 DSL 适合平台内部协作。它比 XML 更易阅读，也方便计算差异、做静态检查和生成测试用例。DMN 1.5 XML 则适合作为标准化交付物，可用于系统集成、归档和跨引擎交换。

这两层表示解决的是不同问题：

  • DSL 面向建模、审阅和平台内部演进。
  • DMN 面向标准兼容、部署和外部交换。
  • 自然语言保留业务意图，但不承担精确执行语义。
  • 验收案例连接业务语言与机器执行结果。

全栈 Rust 实现也与这类平台的需求契合。解析、校验、编译和运行时都需要明确的数据结构与错误边界，Rust 的类型系统可以让不少字段缺失、枚举非法和状态迁移错误提前暴露。不过，语言本身并不会自动保证业务语义正确，决策表的重叠规则、空值处理和命中策略仍需要专门验证。

可以这样实践一条最小决策流水线

下面是假设性的 API 示例，用于展示自然语言建模、校验、验收和发布之间应如何衔接；端点名称和响应字段需要按实际部署调整。运行前设置平台地址和访问令牌，并确保本机安装了 curl 与 jq。

export FUXI_URL="http://localhost:8080"
export FUXI_TOKEN="replace-with-your-token"

# 1. 用业务语言创建草稿
DRAFT_ID=$(curl -fsS "$FUXI_URL/api/decisions" \
  -H "Authorization: Bearer $FUXI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "account-opening-eligibility",
    "description": "客户年龄至少为 18 岁，并且风险等级不是 high 时允许开户；其他情况拒绝。"
  }' | jq -r '.id')

# 2. 触发结构化生成和校验
curl -fsS -X POST \
  "$FUXI_URL/api/decisions/$DRAFT_ID/validate" \
  -H "Authorization: Bearer $FUXI_TOKEN" | jq

# 3. 提交业务验收案例
curl -fsS -X POST \
  "$FUXI_URL/api/decisions/$DRAFT_ID/acceptance-tests" \
  -H "Authorization: Bearer $FUXI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "cases": [
      {"input": {"age": 22, "risk": "low"},  "expected": {"eligible": true}},
      {"input": {"age": 17, "risk": "low"},  "expected": {"eligible": false}},
      {"input": {"age": 35, "risk": "high"}, "expected": {"eligible": false}}
    ]
  }' | jq

# 4. 仅在校验和验收通过后发布指定版本
curl -fsS -X POST \
  "$FUXI_URL/api/decisions/$DRAFT_ID/releases" \
  -H "Authorization: Bearer $FUXI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"version": "1.0.0", "format": "dmn-1.5"}' | jq

这段流程体现了一个关键设计：发布操作应引用不可变版本，而不是悄悄使用“最新草稿”。验收案例也应与版本一起保存，否则规则更新后，很难证明某个历史版本当时通过了哪些业务场景。

实际项目还应补充边界案例，例如字段缺失、未知风险等级、年龄为负数，以及年龄恰好等于 18。对于命中策略为 FIRST、UNIQUE 或 COLLECT 的决策表，还要分别检测规则顺序、重复命中和聚合行为。

版本、验收与分析必须形成闭环

决策平台上线后，每次执行至少应记录决策标识、版本号、时间、命中规则和结果。输入数据是否完整留存，则需要根据隐私和合规要求决定。身份证号、收入、医疗信息等敏感字段不应直接进入普通分析日志，可以使用脱敏、哈希或字段白名单。

数据分析的价值不仅是统计调用量，还包括发现规则问题：

  • 某条规则长期从未命中，可能是条件不可达。
  • 拒绝率在新版本发布后突然上升，可能存在规则回归。
  • 大量请求落入默认分支，可能说明输入模型或规则覆盖不足。
  • 相同输入在不同版本得到不同结果，需要能够解释具体差异。

因此，版本管理不能只保存一份 DMN XML。更完整的版本快照应包含原始业务描述、生成后的 DSL、校验结果、验收案例、DMN 产物、审批记录和发布状态。

上线前应守住的边界

引入这类平台时，可以从规则稳定、输入明确、结果容易验证的场景开始，例如资格判断、费率分档或工单路由。涉及授信、医疗和合规处罚等高风险决策时，应增加人工审批、双人复核、回滚和审计要求。

上线检查可以压缩为五项：规则是否消除歧义，类型与命中策略是否明确，边界案例是否通过，发布版本是否不可变，运行日志是否兼顾可解释性与隐私。只有自然语言、结构化规则、标准 DMN、验收证据和运行数据能够相互对应，决策自动化才真正具备企业级可维护性。

# AI # LLM # Rust # 全栈 # 开源 # 开源中国

相关推荐