P2 Foundry

MLOps 模型注册与预测：推理 + 注册

模型不是在这训练出来的，而是"注册进来、管起来、用起来"：上传版本、部署、做预测、留日志，输出还能注册成对象计算属性。rule 规则模型不需要外部服务开箱即用；onnx / pmml 只能注册不能推理——这个边界先讲清楚。看完 4 个故事，你就能自己把模型管起来。（登录 admin / admin1，端口 18081，演示数据源 foundry_demo_warehouse。）

数据工程师风控模型注册规则推理部署预测边界共 4 个故事

能 / 不能速览

✅ 这个主题能做

模型注册（名称 / 类型 / 框架 / 格式 / owner）、版本上传（首版自动设为当前）、部署 / 下线（单活）、回滚
rule 规则推理：Parameters.rules 写 if / then，命中置信度 1.0、未命中 0，无需外部服务
external_api 转发：把 {"input":...} POST 到部署端点，解析 output / confidence
每次预测必落日志（输入 / 输出 / 操作者 / 关联对象），可追溯"谁对哪个对象做过预测"
预测输出注册为对象计算属性（is_calculated=true, formula="ml:<model>"）；按对象实例拉特征推理并可选写回

⛔ 这个主题做不了

不训练模型：训练在外部（Databricks / Jupyter）完成，本平台只做注册 / 版本 / 部署 / 推理 / 日志
onnx / pmml / pickle / docker_image 可以注册、可以传版本，但预测必报"推理引擎暂不支持"
batch-predict、部署列表、模型性能指标、漂移报告四个端点未注册路由（调用 404）
external_api 强依赖第三方服务，15s 超时即报错，无重试 / 熔断 / 降级
模型级 RBAC 未做（仅 JWT 鉴权）；无调用量 / 延迟 / 错误率监控采集

适用角色

本主题面向三个角色：

数据工程师 / 算法工程师：把外部训练好的模型注册进平台，管版本、管部署——是核心使用者。
风控 / 业务分析师：在预测测试页喂特征拿结果，在预测历史页核对每一次推理。
业务决策者：消费"模型输出注册的计算属性"，不直接操作。

能力速览（能做什么）

模型注册与生命周期

rule 规则推理

parameters.rules 里写 if / then，命中输出 then 值（置信度 1.0），未命中 matched=false（置信度 0）。

external_api 转发

把 {"input":...} POST 到模型服务端点，15s 超时，解析 output / confidence，非 JSON 对象包装到 result。

预测日志审计

每次预测必落日志：输入 / 输出 / 置信度 / 操作者 / 关联对象，支撑推理追溯与未来指标聚合。

本体集成

输出注册为对象计算属性（formula="ml:<model>"）；PredictForObject 拉对象属性做特征推理、可选写回。

调整指南（怎么调整）

想改规则：rule 模型在版本 parameters 里改 rules 数组，重传版本并部署（部署新版本自动停旧）。
想接外部模型：external_api + realtime_api 部署填 endpoint_url；预测时也可用 endpoint_url 覆盖。
想回滚：部署目标版本即回滚（切 CurrentVersion 并同步 active 部署 version_id）。
想关联对象：预测请求带 object_type_id / object_id，日志即记录对象关联；register-property 把输出注册成属性。
想下线：undeploy 停全部 active 部署、状态回退 registered；delete 归档（deprecated）。

做得好的场景

规则模型 + 日志审计 + 本体集成，让"轻量推理"快速落地，特别适合以下场景：

规则风控快速上线：金额阈值 / 黑白名单这类规则逻辑，无需任何外部服务，注册即用。
外部模型统一入口：外部评分 API 统一经平台转发、统一记日志，多模型一个入口。
推理可追溯：每次预测留痕（谁、何时、对哪个对象、喂了什么、出了什么），审计与复盘有据。
对象级推理写回：把评分结果写回对象属性，下游对象查询 / 仪表盘直接消费模型输出。

限制与不足

以下是明确的边界，使用前先知道：

只推理不训练：本平台不做训练编排 / 自动调参，模型训练在外部环境完成。
onnx / pmml 可注册不可推理：格式枚举允许注册与传版本，但预测必报"推理引擎暂不支持"——注册与可推理存在落差。
端点缺口：batch-predict、部署列表、模型 metrics、drift-report 未注册路由（404）。
外部 API 强依赖：external_api 无重试 / 熔断 / 降级，第三方不可用即报错。
治理缺口：无模型级 RBAC；PredictForObject 拉取对象属性不经过 RLS / CLS（敏感列需注意）；写回不经 Action 唯一写路径。

场景故事

故事 1 风控老周用 rule 模型 10 分钟上线"客户风险评分"

场景：规则推理角色：风控耗时：约 10 分钟

背景: 风控老周要上线一条"金额超过 1000 元即高风险"的规则，同时还想看看平台 MLOps 怎么用。他注册一个 rule 模型、传版本（规则写在 parameters.rules 里）、部署、预测，10 分钟走通全流程。

传统做法对比: 以前这种规则要么写死在业务代码里发版等上线，要么接一个外部模型服务来回联调。现在规则写在模型版本参数里，注册 → 传版本 → 部署 → 预测，全部页面操作，改规则就是改版本重部署。

角色: 风控（规则提出与验证）、数据工程师（辅助注册与部署）。

操作步骤

"MLOps"→"模型管理"→"注册模型"：name=customer_risk_rule、model_type=classification、framework=rule、format=rule
上传版本 1.0.0，parameters 填 {"rules":[{"if":{"amount_gt":1000},"then":"high_risk"}]}
部署版本（deploy_type=realtime_api，rule 模型无外部端点直接 active）
"预测测试"选模型，输入 {"amount_gt":true} 点预测

系统响应: 注册返回 {"code":0,"data":{"id":"<uuid>"}}；预测命中返回 {"code":0,"data":{"output":{"matched":true,"result":"high_risk"},"confidence":1.0,"log_id":"..."}}；输入 {"amount_gt":false} 则返回 {"matched":false}、confidence 0。

结果洞察: 规则即模型的思路落地：if / then 数组就是"推理逻辑"，命中输出 then 值、置信度 1.0，未命中 matched=false。rule 模型不需要任何外部服务，是演示与快速上线的最短路径；每次预测都落日志，后续核对有据。

调整建议: 规则复杂时用多个 if 分支；规则阈值调整就传新版本再部署（旧部署自动停）；预测输入字段名要与规则 if 键名一致，否则匹配不到。

动手试一试: 登录：admin / admin1。页面路径：MLOps → 模型管理 → 注册 → 上传版本 → 部署 → 预测测试。输入内容：customer_risk_rule、rules=[{"if":{"amount_gt":1000},"then":"high_risk"}]。预期结果：amount_gt=true 命中 high_risk（置信度 1.0），false 未命中（matched=false）。

限制提示: rule 是纯规则匹配，不是机器学习推理；模型注册与预测走 JWT 鉴权，无模型级 RBAC；onnx / pmml 等格式注册后预测会报"推理引擎暂不支持"。

故事 2 张工把评分输出注册成对象计算属性，对象查询直接可见

场景：本体集成角色：数据工程师耗时：约 6 分钟

背景: 张工做完 rule 模型预测后，想让"风险评分"直接出现在订单对象上，这样对象查询、仪表盘都能消费。他使用 register-property 把预测输出注册为 order 对象的计算属性。

传统做法对比: 以前评分结果要么手工导回数据库，要么另起一张表靠主键关联，同步一次麻烦一次。现在以预测日志为入口，把输出注册成对象计算属性（is_calculated=true、formula="ml:<model>"），对象模型自动多一个字段。

角色: 数据工程师（注册属性），业务分析师（消费对象新属性）。

操作步骤

在"预测历史"找一条关联了 order 对象的预测记录（记下 log_id）
点"注册为属性"：property_name=risk_level、object_type_id=order（或复用日志关联值）、model_id 缺省取日志
提交后到"本体工作台"打开 order 对象，确认 risk_level 属性出现

系统响应: 注册返回 {"code":0,"data":{"property_id":N}}；order 对象属性列表新增 risk_level：is_calculated=true、formula="ml:customer_risk_rule"、data_type 缺省 number。属性重名返回冲突错误。

结果洞察: "注册动作"总是绑定在一条真实预测记录上（以日志 id 为入口），审计链完整；对象模型多出的计算属性，让下游对象查询、仪表盘、指标都可以引用模型输出——模型能力长进了本体里。

调整建议: DataType 优先取版本 OutputSchema.type、缺省 number，注册前先确认输出 schema；写回类场景用 PredictForObject 的 write_back 直接落对象属性值；属性名避免与既有属性重名。

动手试一试: 登录：admin / admin1。页面路径：MLOps → 预测历史 → 注册为属性。输入内容：property_name=risk_level、object_type_id=order。预期结果：order 对象出现 risk_level 计算属性（is_calculated=true、formula="ml:customer_risk_rule"）。

限制提示: 计算属性是"静态注册"：只登记属性与 formula 元数据，不绑定实时推理触发；对象属性值需经 PredictForObject 显式写回才有数据，无自动重算机制。

故事 3 接入外部评分 API：external_api 模型统一转发、统一记日志

场景：外部转发角色：数据工程师耗时：约 8 分钟

背景: 张工要把一个外部"客户评分 API"接进平台：平台统一转发、统一记日志，业务方不需要直接接触第三方接口。他注册 external_api 模型，用 realtime_api 部署带 endpoint_url，然后做预测验证转发契约。

传统做法对比: 以前每个业务系统都要对接第三方 API：密钥、超时、异常处理各写一套，出问题还互相甩锅。现在平台统一封装转发契约（{"input":...} → output / confidence），15s 超时，预测日志留痕，一个模型一个入口。

角色: 数据工程师（注册 + 部署 + 验证），第三方服务提供方（提供端点）。

操作步骤

注册模型：name=external_scorer、framework=external_api、format=external_api
上传版本 1.0.0（artifact_url 可填端点说明）
部署：deploy_type=realtime_api、endpoint_url=https://example.com/score
"预测测试"输入特征（如 {"income":8000,"age":35}）点预测

系统响应: 平台 POST {"input":{...}} 到端点；第三方返回 {"output":{"score":0.82},"confidence":0.9} 时，预测返回 {"code":0,"data":{"output":{"score":0.82},"confidence":0.9,"log_id":"..."}}；未部署且未给 endpoint_url 时报"模型未部署 external_api 端点"。

结果洞察: 转发契约清晰：请求统一 {"input":...}、响应优先取 output 字段（其次整个响应体，非 JSON 对象包装到 result）、置信度取 confidence。外部服务接入后，业务方通过平台拿结果，出问题也有日志可查是"平台转发"还是"第三方响应"。

调整建议: 端点建议配在部署上（部署级优先、模型级兜底、预测时 endpoint_url 覆盖）；第三方不稳定时先用 rule 模型过渡；非 200 状态返回 ExternalAPIError，可据日志排查。

动手试一试: 登录：admin / admin1。页面路径：MLOps → 注册 external_api 模型 → 部署带 endpoint_url → 预测测试。输入内容：external_scorer + endpoint_url。预期结果：请求转发 {"input":...}，返回解析的 output / confidence；不给端点预测报"未部署 external_api 端点"。

限制提示: external_api 强依赖第三方：15s 超时即报错，无重试 / 熔断 / 降级；响应契约固定为 output / confidence，第三方不符合需自建包装服务；predictions 端点有模型 id，日志按模型聚合。

故事 4 onnx 模型"注册成功但预测报错"：边界实测与日志核对

场景：边界验证角色：数据工程师 + 业务分析师耗时：约 6 分钟

背景: 张工接到一个 onnx 模型文件，心想"注册了应该就能用"。他按流程注册 format=onnx、上传版本、部署，结果预测时报错。他要实测这个边界，并核对预测历史里有没有这条失败的调用，把"能注册 ≠ 能推理"确认清楚。

传统做法对比: 以前遇到"注册了不能用"只能翻代码猜；现在直接测一次就知道：onnx / pmml / pickle / docker_image 枚举允许注册与传版本，但推理引擎只有 rule 与 external_api 两种，其余格式预测必报错——这是当前版本明确的边界，不是 bug。

角色: 数据工程师（注册 + 实测）、业务分析师（核对预测历史）。

操作步骤

注册模型：name=onnx_demo、framework=onnx、format=onnx，上传版本 1.0.0（artifact_url 填文件路径）
部署该版本，到"预测测试"输入任意特征点预测
记录报错信息；再到"预测历史"看是否留有日志

系统响应: 预测返回 {"code":"INVALID_REQUEST","error":"推理引擎 \"onnx\" 暂不支持（MVP 支持 rule 与 external_api，ONNX/PMML/Python 子进程留远期）"}；由于推理失败，预测日志不落库，预测历史无该条记录。

结果洞察: 边界实测结论明确：onnx 可注册、可上传版本、可部署（部署是声明式的），但推理必失败，且失败的推理不落预测日志。想用 onnx 模型，当前需要包装成 external_api 服务接入，或等 ONNX Runtime 接入（远期）。文档与 UI 都应如实提示"可注册不可推理"。

调整建议: 生产选择格式前先确认推理能力：需要本机推理用 rule / external_api，需要文件型模型先自建推理服务包装；注册时在 UI 上留意 framework / format 与可推理引擎的对应。

动手试一试: 登录：admin / admin1。页面路径：MLOps → 注册 onnx 模型 → 上传版本 → 部署 → 预测测试。输入内容：format=onnx。预期结果：预测返回"推理引擎 onnx 暂不支持"错误，预测历史无失败记录。

限制提示: batch-predict / 部署列表 / 模型 metrics / drift-report 端点未注册（404）；模型级 RBAC 未做；预测日志是唯一审计数据源，失败推理不落日志，排查需结合平台日志。

常见问题

onnx 模型注册了为什么不能用？

当前推理引擎只有 rule 与 external_api 两种：rule 在 parameters.rules 里写 if / then，external_api 转发到第三方服务。onnx / pmml / pickle / docker_image 允许注册与上传版本，但推理会报"推理引擎暂不支持"——如需使用请自建推理服务用 external_api 接入。

部署到底部署了什么？

部署是"声明式"的：记录部署类型、端点与状态（active），不是拉起真实服务。external_api 部署把 EndpointURL 记下来供预测转发；rule 模型无外部端点直接置 active。真正跑模型的还是你指定的外部服务或规则逻辑本身。

预测日志有什么用？

每次成功预测必落日志：输入、输出、置信度、操作者、关联对象。可用于"谁在何时对哪个对象做了什么预测"的追溯，也是未来模型性能监控（调用量 / 错误率）的数据源。

预测结果怎么让业务看到？

两条路：一是 register-property 把输出注册为对象计算属性（formula="ml:<model>"），二是 PredictForObject 按对象实例推理后可选写回属性值。之后对象查询 / 仪表盘就能消费。

平台能训练模型吗？

不能。本模块定位是"推理 + 注册"：训练在 Databricks / 本地 Jupyter 等外部环境完成，平台负责注册、版本、部署、推理与日志。训练编排 / 自动调参不在当前范围内。

主题小结

一句话：MLOps 是"推理 + 注册"平台——外部训练好的模型注册进来，rule / external_api 两种引擎做预测，日志全留痕，输出可变成对象计算属性。记住边界：不训练、onnx / pmml 可注册不可推理、batch / 指标 / 漂移端点未接。