运行时护栏——把确定性检查搬进生产路径
测试的孪生做法:不(仅仅)在评测集里检查输出,而是把确定性检查内联进每一次生产执行,并在失败时立刻采取行动——阻断、带着反馈重试,或降级到安全的兜底方案。相关框架:Guardrails-AI(围绕模型调用的校验器库:schema、PII、脏话、可溯源性/groundedness),NVIDIA NeMo Guardrails(对话层面的护栏:话题边界、工具权限护栏、越狱规避)。
每次调用的标准护栏栈:输入护栏(注入检测、话题/权限边界,发生在模型看到文本之前)→ 输出护栏(schema 有效性、禁止内容、引用可解析、PII)→ 工具护栏(这条流程可以调用哪些工具、参数边界——也就是能力围墙)→ 失败时:把校验器给出的错误反馈回去自动重试,或直接拒绝。延迟预算迫使护栏必须便宜且确定——LLM 评判层大多留在离线/异步执行(online-evals)。
概念上的要点:护栏承认,对于随机性程序而言,评测时的信心不会自动转移到运行时——每一次执行都是一次全新的采样,所以每一次执行都要被检查。这与软件 1.0 形成对比:在软件 1.0 里,测试通过一次(基本上)就是永久的证明。
与 um 的关系: um 在遇到这些框架之前,就已经有了这种直觉——law 1 本身就是一条运行时护栏("发布者不相信一个已通过的声明——它会在发布时,对已提交的条目重新跑一遍 lint"),而浏览器操作能力的拆分(#7:只有发布者持有已登录的 profile)则是一条被物理化的工具护栏。um 可以吸收的地方在于输入护栏——law 4 已经宣布平台文本是数据、不是指令,但除了已文档化的分隔符约定之外,目前在 context 组装边界处,还没有任何机制去筛查/界定入站文本;在 L0/L1 摄入阶段加一道确定性的注入模式筛查,就是 law 4 的护栏化实现(automated-red-teaming 就是测试这条护栏的方法)。
来源:evals 主流实践(Guardrails-AI / NVIDIA NeMo Guardrails,2026-07 现状梳理)