把过滤脚本换成裁判模型之前，先问三件事

Databricks 10 月 9 日起允许在 Unity Gateway 的服务策略里，用 OpenJev（基于 Qwen3.5 4B）当“LLM 裁判”，功能处于 Beta。³服务策略是网关上的闸门，模型服务和 MCP 工具的每次请求、每次响应都要先过它。²原来的写法有两种：写 SQL 函数，按关键词、工具名、参数做精确判断；或者用自然语言写标准，交给聊天模型去判。¹OpenJev 只做分类、不生成 token，通常比聊天模型快。³

这是用决策模型替代一部分过滤脚本，方向我很喜欢。但用 Databricks 的团队大多身处强审计场景，固定脚本至少能保证同样的输入永远得到同样的结果，事后也查得清。所以我把官方文档和别人的做法放在一起，问三个问题：置信度看不看得到，结论能不能重放，判错了改起来贵不贵。

网关里的 OpenJev 只给结论，看不到置信度

在策略里，OpenJev 答的是一道二选一：拦，还是放。选哪个就是结论，没有阈值可以调；“拦”这个选项的措辞让它在内容可能违规时胜出，所以边界内容更容易被拦下。它也不写理由。¹

模型本身是有概率的。直接调用 System One API，或者在 SQL 里用 ai_decide 函数，都能拿到每个选项的概率和一个 confidence 值。⁴⁵放进网关策略以后，这些数字被收成了一个“拦”或“放”。

好的一面是，Databricks 替你选定了出错的方向：宁可多拦。策略整体也是失败即拒绝，字段缺失或任何评估错误都按拒绝处理。¹坏的一面是，我在 d1 那篇里主张的按置信度分流，在网关里做不了：没有分数，就没法把没把握的交给大模型或人工。

能留下记录，但同一个输入不保证同一个结论

固定脚本的审计靠重放：同样的输入再跑一遍，结果一样，就证明当时是按规则判的。Databricks 的文档直说，裁判模型的结论不确定，同一个输入可能得到不同结论；需要可重复的检查，就用 SQL 策略。²

所以审计证据只能从“能重放”换成“有记录”。统一追踪表会记下每条策略的判定，只记不拦的 Log 模式下还会记“本来会怎么判”。²但它的投递是尽力而为，官方说它只是审计日志的补充。⁷裁判的推理要另外在评估模型上打开推理表才看得到。²用裁判模型，就要多存一套留痕：判定结果、提示词版本、评估模型版本，缺一样都说不清某一条为什么被拦。

判断写进表里，回退才真正贵

在网关里，策略只做决定，不改写内容。判错的代价是一次调用被误拦；改了提示词，一般一两分钟就生效，没有历史数据要改。²

管道里不一样。ai_classify、ai_decide 可以在 SQL 里给每一行打标签，结果写进表，下游接着用。⁵⁶两份文档都写明，出现更好的模型时，Databricks 可能更换底层模型；ai_decide 还提醒每次调用的答案可能不同；ai_classify 不显式指定版本，会退回旧的 1.0。⁵⁶算一笔假设的账：一张 1,000 万行的历史表，换模型后哪怕只有 1% 的标签翻转，也有 10 万行要重写，每一行都得能向审计解释为什么变了。

我担心的回退和重写成本，主要出在管道里。

别人的做法：规则先挡，模型只管语义，结论再蒸馏下来

Databricks 自己建议分层：规则精确、可重复的用 SQL 策略，关键词表达不了的语义检查才交给裁判模型；先用 Log 模式在真实流量上看误拦和漏拦，再切到强制执行；OpenJev 在英文上效果最好。¹多条策略按优先级执行，前一级拒绝了，后面的就不再跑，²所以便宜、确定的规则放在前面。

Josh Melton 2025 年 5 月在 Databricks 社区技术博客上给过管道里的思路：先用大模型给数据打标签，再用这些标签训练 XGBoost、逻辑回归这类传统模型；用语义相似度和编辑距离给标签补一个置信度，低于阈值的交给人工复核。⁸我的推断是，权重固定、由团队自己保管的小模型，同一个输入给出同一个输出，版本也不会被平台换掉，对审计很友好。原文没有从审计角度讨论。

我会这样用：判断交给模型，落表的结论要能追溯

• 拦截类判断放在网关：SQL 规则排第 1 级，OpenJev 只做规则写不出来的语义检查；先跑 Log 模式，并事先打开评估模型的推理表。
• 需要按置信度分流的判断，在管道里用 ai_decide，把概率一起落表，低于阈值的交给人工。
• 落表的结论连同模型、函数、提示词的版本一起存，只追加不覆盖，版本参数写死。
• 必须原样重放的判断，保留固定脚本，或者蒸馏成自己保管的小模型。

用决策模型替代过滤脚本，我仍然很乐意看到。前提是先想清楚：模型判错时错向哪一边，判断落进表以后能不能说清它是怎么来的。