←新闻详情

腾讯云开发者社区更新于 10月28日 15:31

轻型AI中台:如何配置规则配置中心

AI 导读

轻型AI中台的规则配置中心围绕消除重复录入、消减对账困难、及时发现问题、支撑经营分析四类场景,管理规则目录、参数取值、执行调用与版本记录。规则库与参数库分库存放,参数调整不牵动规则版本;验收要求单规则实时调用响应不超过2秒、十万条单据批量对账不高于30分钟,规则扩至1000条后性能劣化不超过20%。

正文

规则配置中心在轻型AI中台中的定位,是业务规则治理中枢与规则执行配置入口。它管理四类场景——消除重复录入、消减对账困难、及时发现问题、支撑经营分析——下的规则目录、参数取值、执行调用与版本记录。

一、规则配置中心的功能

功能分六项。前五项解决"配得进去、跑得起来",第六项解决"改得回来、查得清楚"。

(一)规则目录与分类管理

以四类业务场景为主轴建目录,场景下挂规则类型,避免规则按系统归属堆成散沙,对应关系见表一。

客户名称与税号组合查重;供应商编码跨系统对照;物料基础信息一次维护、多系统复用

消减对账困难

勾稽关系、匹配规则、差异分类、财务自动拼表

应收与收款勾稽;订单与出库单匹配;差异按时间性与实质性分类;拼表取数口径统一

及时发现问题

完整性、一致性、规范性、跨系统一致性校验,智能清查

必录字段缺失;金额合计与明细不符;日期格式越界;两系统同一单据状态不一致

支撑经营分析

指标定义、取数口径、计算规则、维度规则

收入指标口径与换算;客户数去重口径;毛利率计算;组织与产品维度层级

每条规则登记八项要素:规则编码、名称、业务含义、适用范围、责任部门、生效时间、关联参数、优先级。规则编码是唯一标识,避免同名规则难以追溯;优先级是冲突处理时的执行顺序依据;责任部门决定出了问题找谁,关联参数决定有几个可调取值。

(二)规则定义与业务表达

规则定义以业务语言表达判定条件与结果动作,业务人员能读懂判定含义,例如客户名称与税号组合已存在且状态有效,则拦截并提示关联已有客户。业务确认记录随规则留存,作为争议处理与验收的依据。

(三)规则执行与场景调用

执行支持两种方式:接口调用,供智能体和业务系统在保存、提交、审批节点实时使用;任务调度,供对账、清查、指标计算等批量场景按周期使用。同一规则可被多个场景引用,执行带幂等标识,重复调用不产生重复差异记录;每次执行同时记录规则版本号与参数版本号,可还原判定当时的状态。

同一数据命中多条规则时,按登记的优先级执行;互斥规则不允许同时生效;多条规则同时命中时,按优先级合并输出提示、拦截、转人工、记差异等动作,冲突由业务归口部门裁决。

(四)结果反馈与差异定位

差异记录固定四项内容:哪条数据(源系统加单据号)、哪个字段、命中哪条规则、建议动作。差异按类型分流:业务类推前台,接口与抽取类推IT,跨系统口径冲突推业务分管负责人。

(五)参数与阈值管理

参数集中登记,按判定类(相似度、匹配权重)、容差类(金额、时间、比例容差)、通知类(预警阈值、推送频次、推送对象)、动作类(提示方式、拦截级别、转人工)归类,与规则分库存放。每个参数记录编码、当前值、适用规则、适用场景、生效范围、责任人、变更与回退记录、校准记录,可按版本回退。参数调整不牵动规则版本,规则结构与参数取值各归其位。

(六)版本留痕与权限控制

新增、修改、停用、发布、回退五个动作全部留痕,记录操作人、时间、原因与影响范围;影响范围按规则、场景、报表、参数之间的引用关系自动列出。权限分查看、编辑、发布、执行四类,按岗位与数据范围授予,发布权单独设置,不随编辑权自动获得。

二、规则配置中心的选型与架构

(一)选型依据

选型只看四条产品维度。规则类型与变更频次,优先考虑,规则多、变更频繁的优先选目录清晰、支持批量发布的产品;语义表达与复用能力,决定业务人员能否真正参与,表达弱的业务确认流于形式;集成成本与工期,是项目按期上线的主要风险点,需评估接口改造量与上线周期;轻量化与可运维,配置中心不应成为新的重资产。数据资产基础与安全审计要求归入第三节配置依据。

(二)功能架构

功能架构分五层:定义层负责规则录入与参数设定;规则库与参数库分库记版本;执行引擎按场景调用规则、读取参数;反馈层输出差异与报告;版本与权限层负责审批、发布、回退和权限控制。总体结构见图一。

图一 规则配置中心结构

分库存储的必要性在于:两类内容改动频率相差一个量级,审批强度也不同。合库存放时,每次调整阈值都要连带走规则版本审批,易导致参数长期不更新,规则配置中心难以发挥实效。

(三)数据与部署架构

三个接口边界,与开篇职责分工呼应:向下,只读引用数据资产目录与业务系统数据;向上,向智能体与业务系统提供规则调用接口;向内,执行记录与差异记录独立存储,规则变更不影响历史记录可读性。数据搬运、接口连通、系统集成由中台集成层承担,规则配置中心不重复建设。部署与中台同域集成,参数库单独备份、单独演练恢复,防止参数丢失后规则无法输出正确结果。

三、规则配置中心的配置依据

(一)数据与对照依据

以数据资产目录为准,取字段含义、值域、跨系统对照关系,据此配置主体映射、字段映射、编码转换与一致性校验。目录未覆盖的字段,先补目录再配规则,顺序不能倒,否则取数来源说不清。

(二)制度与标准依据

录入要求、对账口径、差异分类、指标定义、变更流程,逐条对应到业务制度、数据标准、《财务自动拼表三模式与规则治理方案》与《轻型AI中台的IT系统管控体制与机制》。数据资产基础与安全审计也落在这里:规则引用哪些数据资产、参数修改需哪些权限、日志保留多久,按管控机制执行并注明出处。每条规则记录所依据的制度条款,制度修订时按条款反查受影响的规则,防止系统仍按老口径拦截。

(三)场景与问题依据

把四类场景中的高频问题排出顺序,明确每条规则要解决的问题、适用对象和预期效果。排序依据两个数:发生频次、单次处理工时,频次高、工时长的先配。没有这两个数,规则清单就会变成各部门诉求的集合。

(四)管理与反馈依据

明确规则优先级、适用范围、责任主体与变更流程,区分业务确认事项与IT维护事项;业务使用反馈是调整规则与校准参数的主要来源,渠道要固定:提示看得懂吗、差异处理得掉吗、有没有误拦。

(五)实测依据

容差、阈值、相似度这三类数值从制度和目录推不出来,只能在试运行中跑出来。按参数分组记录每组下的误报数、漏报数、业务采纳情况,形成参数基线表,作为正式配置的起点和后续校准的比较基准。实践表明:试运行数据量应接近真实日量,一百条数据测出来的阈值放到一万条上通常偏松。

四、规则配置中心的配置与验收

(一)配置步骤

五步推进,每步有产出。规则梳理:业务部门按四类场景出规则清单,写清名称、含义、责任主体;口径确认:业务与IT确认数据来源、计算方式、匹配条件、差异处理方式;配置建模:建规则目录与参数台账,配置条件与输出格式;测试验证:真实或脱敏数据跑场景测试,并按参数分组试运行采集基线;发布上线:按权限审批发布,记版本号与生效时间,留回退点。

动作类:提示方式、拦截级别(提示、软拦截、硬拦截)

完整性、一致性、规范性、跨系统一致性校验,智能清查

配置项(非参数):统计周期、取数期间、维度层级深度、指标精度

按主题自助取数、口径一致

(三)验收标准

验收判据要能被第三方复验。六项判据与验证方法见表三。

按四类场景随机分层抽取20条差异记录,业务人员能说明判定依据的比例不低于90%

现场抽查复述,复述记录归档留存

差异可定位

差异记录定位到源系统、单据号、字段的比例不低于95%

随机抽20条核对

过程可追溯

倒查三个月前任意20条执行记录,规则版本、参数版本、处理结果均可查

压测环境与生产环境同构、数据量口径一致;单规则实时调用响应不超过2秒;十万条单据批量对账不超过业务规定时限,业务未规定时不高于30分钟;规则扩至1000条后,以验收压测值为基准、同环境同数据量复测,单规则响应时间与批量对账时间劣化不超过20%

同构环境压测与批量数据试跑

(四)验收方式

业务人员参与场景测试,验规则是否符合业务习惯、提示是否清晰;IT验性能、接口调用、权限控制和日志留痕。两类签字齐全方可验收;缺少任何一类签字,后续易产生返工和争议。

五、规则配置中心的运行维护与参数校准

(一)运行监控

七项指标纳入运行看板:规则执行成功率、异常触发频次、差异处理时长、规则调用量、参数版本变更次数、参数变更后复测完成率、业务反馈闭环率。看板七项为实时或按日监控指标;表四八项指标按各自统计周期计算后推送看板,各项口径统一见表四。看板应按规则逐条列示,仅汇总难以识别具体失效规则。

通过规则自动处理或按提示处理的业务笔数÷同类业务总笔数(同类业务按场景、业务类型和统计周期界定)

三个量化触发条件:时间性差异占比超过15%(指同一笔业务两边入账时点不同形成的差异),启动容差评估;提示采纳率低于50%,评估规则是否过宽或提示方式影响操作;误报率较基线上升超过20%且持续两周,启动阈值复核。触发条件满足即启动,不待人工提出。各指标按表四口径统计与复算,比较基准取试运行参数基线表实测值。

图二 参数校准闭环

校准前后用同一指标复测,记录前值、后值和结果,归入参数台账的校准记录(字段见本节(三))。缺少复测,参数校准就缺乏依据。

(三)版本管理、参数变更与规则退出

规则变更经申请、评估、审批、发布、回退五步,保留原因、影响范围与操作记录。参数变更同样留痕,并按风险分级生效:通知类参数登记即生效;动作类参数登记后经业务知会生效;判定类、容差类参数直接影响判定结果,须经业务确认后方能生效。参数台账登记十二个字段:参数编码、名称、当前值、适用规则、适用场景、生效范围、责任人、变更记录、生效版本、回退版本、回退验证结果、校准记录;校准记录按固定格式填写:校准日期、指标、校准前值、校准后值、复测结果、校准人、验证人。参数回退由登记人发起,验证人由业务归口部门指定、不得由登记人自验,按回退后的参数组复测并填写回退验证结果。规则库会膨胀,退出机制要事先定好:连续六个月零触发、所针对问题已由系统改造根治、制度依据已废止的规则进退役评审,结论三选一:保留、合并、停用,保留的写明理由。停用规则的历史差异记录按管控机制规定的日志期限保留,以备追溯;退役评审每半年由业务归口部门组织、IT维护人员参加,评审记录随规则台账归档。

(四)责任机制

三类角色分工:业务归口部门负责业务含义与口径确认,IT维护人员负责规则配置、参数登记与运行保障,复核人员负责差异处理与销项确认。与《轻型AI中台的IT系统管控体制与机制》的三角色对应:业务归口对应规则定义人,IT维护对应配置执行,复核对应差异确认,审批按该机制分级执行。发布权的制衡:IT握有发布的操作权,业务握有前置确认权,任何一方都不能单方面让一条规则上线。

结语

规则配置中心运行成熟的标志有三个:规则改动只改一处,查一次能追到当时那一版,业务侧指标可统计。第一条靠分库和引用关系;第二条靠规则版本号与参数版本号落进每一条执行记录;第三条看三个数——业务使用率、提示采纳率、差异处理率,有数可查、逐季可比。规则数量再多,若业务人员不使用,也难以产生实际效果。

业务定口径、IT配发布、复核管销项,三权分离;规则改动走审批,参数改动分级生效;每季度按差异数据回看一次规则库。三条做到,规则配置中心才真正成为业务规则治理中枢和规则执行配置入口,把中台能力转化为业务人员少录入、少核对、早发现、好取数的实际便利。

来源

腾讯云开发者社区