AI 应用怎样把输出过滤与业务规则分开

AI 应用里最容易混在一起的两个判断是“这段输出能不能展示”和“这个用户现在能不能执行这件事”。前者属于输出过滤，后者属于业务规则。更稳妥的做法是让模型适配层只负责拿到结果，让过滤层负责格式与内容风险，让业务策略层根据用户、资源和流程状态做最终决定。

过滤通过不代表业务允许，过滤拒绝也不应该被业务层重新解释成普通权限失败。为两类判断分别定义结果类型和原因码，才能让接口、日志、重试和人工复核保持一致。

官方地址：https://huggingface.co/docs/transformers/chat_templating

把“输出有问题”拆成两个故障面

一次生成至少会经过三个边界：模型返回什么、内容是否符合安全与格式要求、业务是否愿意接受这份结果。Hugging Face Transformers 的聊天模板会把带有 role 和 content 的消息转换为模型需要的 token 序列；这属于输入和模型适配问题，不应该顺手承担业务审批。生成完成后，应用还需要把文本解析成自己的候选对象，再做过滤和业务决策。

如果把这些判断写进一个 generate_and_send() 函数，线上通常会出现两类误判：敏感内容被记录成“余额不足”，或者业务拒绝被当成模型失控反复重试。前一种会损害审计，后一种会增加调用成本。分层后，模型替换、规则调整和权限变化可以分别发布。

先把输出处理拆成三层

可以先用一个小而明确的结果对象承接每一层。过滤层只关心输出是否为空、是否能解析、是否触发内容规则；业务层只接收已经规范化的候选，不直接读取原始 token 或模型私有字段。

from dataclasses import dataclass
from typing import Literal

# 统一三种外部可见结论，避免调用方猜测空字符串的含义。
Decision = Literal["allow", "deny", "review"]

@dataclass
class PolicyResult:
    decision: Decision
    reason_code: str
    text: str = ""

def normalize_model_output(raw: object) -> str:
    # 这里只做格式归一化，不在适配层决定内容是否合规。
    if not isinstance(raw, str):
        return ""
    return " ".join(raw.split()).strip()

def filter_output(text: str) -> PolicyResult:
    # 过滤原因码只描述输出本身，便于单独统计和审计。
    if not text:
        return PolicyResult("deny", "output.empty")
    blocked_terms = {"绕过权限", "伪造凭证"}
    if any(term in text for term in blocked_terms):
        return PolicyResult("deny", "output.content_blocked")
    return PolicyResult("allow", "output.accepted", text)

def apply_business_policy(result: PolicyResult, user_role: str) -> PolicyResult:
    # 业务层不重新扫描原文，只判断当前角色能否使用已过滤结果。
    if result.decision != "allow":
        return result
    if user_role not in {"operator", "reviewer"}:
        return PolicyResult("deny", "business.role_not_allowed")
    return PolicyResult("allow", "business.accepted", result.text)

这段示例刻意把 output.content_blocked 与 business.role_not_allowed 分开。实际项目中，词表、分类器或人工复核服务可以替换过滤函数，但业务策略的输入输出契约不必跟着改变。

用结构化结果承接拒绝分支

不要让调用方通过“返回文本为空”“抛了哪个异常”来推断策略。建议把 decision、reason_code、可展示文本和追踪标识放在同一个响应对象里。对外只返回用户需要的提示，对内保留原因码和策略版本。

安全过滤适合在日志中记录规则版本、命中类型和摘要哈希，避免把完整敏感原文写入普通日志；业务策略则应该记录租户、角色、资源状态和策略版本。两套指标分开后，才能回答“模型输出质量变差了”还是“权限策略收紧了”。

四个容易漏掉的边界

• 空输出：把空文本视为明确的 output.empty，不要默认为允许，也不要无限重试。
• 过滤通过：它只代表内容层面可继续处理，不能绕过资源归属、配额、审批或角色检查。
• 人工复核：高风险但无法自动判定的内容应返回 review，不能用“暂时允许”代替。
• 规则更新：原因码保持稳定，策略版本单独记录，这样历史记录仍然可解释。

如果使用 Transformers 的生成接口，还应把停止条件、最大新 token 数和解析失败作为模型适配层的运行参数；这些参数决定生成如何结束，但不替代输出过滤与业务授权。最终的接口只需要遵循一条边界：过滤层回答“内容能不能进入应用”，业务层回答“当前请求能不能完成”。

常见问题

过滤规则应该放在提示词里吗

提示词可以作为模型行为引导，但不能作为唯一控制。真正影响业务结果的过滤和授权仍应在模型外部执行，并保留结构化原因码。

业务拒绝后能否自动换一个提示词重试

只有在失败原因明确属于暂时性的模型适配错误时才考虑重试。权限不足、配额不足和人工复核都应停止自动重试，否则会把策略拒绝放大成调用风暴。