AI 产品实战：演示与生产之间，隔着一层可执行的治理

原创

资源大佬 jzit-top

发布于 2026-10-29 11:08:11

1470

AI 产品最危险的错觉，是“演示跑通了就等于产品做完了”。一个 LLM 应用可以在一个周末搭出来，但要让它在模型升级、工具变更、流量波动之后仍然保持工作，需要的是另一种东西。某大型零售企业的库存推荐系统给出了一个精确的对照：上线第一个月末，约 15% 的智能体返回是幻觉——言之凿凿，但毫无事实依据；六个月后，这个数字降到了 1.5%。推动下降的不是更强的模型，而是一个架构决定：不再把大模型能力当作应用层业务逻辑，而是当作平台基础设施来治理。AI 产品的实战分水岭，不在于模型调得多好，而在于是否在生成与用户之间，插入了一层模型无法绕过的、可执行的治理。

评估：从“跑一次看效果”到“每次变更都过门禁”

演示阶段的评估通常是单次快照：跑几个例子，看着不错，就认为可以了。但非确定性系统的本质是，一次“绿色”运行不能证明下一次任何事情。Google 的 Agents CLI 把评估做成了一条爬山回路：eval generate 驱动智能体跑数据集，eval grade 打分，eval compare 对比两次运行，分数上升就保留变更，分数下降就回滚。这条回路的关键不在于工具有多复杂，而在于评估被嵌入变更流程，而不是留在某个人手动跑一次的笔记本里。

一个真实的回归案例说明了为什么单次快照不可靠。开发者不小心把天气智能体的 system prompt 换成了厨师人设，代码编译通过，lint、类型检查全部正常，但评估均分从 4.0 掉到 2.75——一个看似无害的字符串变更，在传统 CI 中完全隐形。门禁的价值恰恰在于它拦住了传统测试拦不住的东西。

以下评估门禁代码把“通过率阈值 + 安全一票否决 + 零回归”写成机械判定，而非留给评审者“感觉一下”：

GATE = {"min_pass_rate": 0.85, "allow_safety_fail": False,
        "max_cost_growth": 0.30}

def eval_gate(baseline: dict, candidate: dict) -> list[str]:
    errors = []
    if candidate["pass_rate"] < GATE["min_pass_rate"]:
        errors.append(f"PASS_RATE_LOW: {candidate['pass_rate']:.2f}")
    if candidate["safety_fail"] and not GATE["allow_safety_fail"]:
        errors.append("SAFETY_VETO: 安全用例失败，一票否决")
    if candidate["cost"] > baseline["cost"] * (1 + GATE["max_cost_growth"]):
        errors.append("COST_REGRESSION: 成本涨幅超限")
    if candidate["score"] < baseline["score"]:
        errors.append("QUALITY_REGRESSION: 质量回归，禁止合入")
    return errors

# CI 中的调用：错误非空则以非零退出码阻断合并
if errors := eval_gate(baseline_run, candidate_run):
    raise SystemExit(f"评估门禁未通过：{errors}")

门禁的工程含义是把“质量”从一种主观判断转化为一种可执行的放行条件。没有通过门禁的版本，不进入灰度，更不进入生产。

Schema：把幻觉从“感觉不对”变成“可统计的结构化事件”

零售平台把幻觉率从 15% 压到 1.5% 的关键机制之一，是让模型在输出时以机器可读的形式承诺其答案是否有检索证据支撑。Pydantic Schema 中一个 grounded 字段，生成成本几乎为零，但校验失败、字段缺失、grounded 与 sources 不一致，全部转化为可重试、可统计的结构化失败事件，而不是一个“看起来对”的答案被直接放行。Schema 不只是格式化数据，它是给模型的显式指令，也是隔离和度量幻觉的追踪字段。

from pydantic import BaseModel, Field

class AnswerOut(BaseModel):
    answer: str
    sources: list[str] = Field(default_factory=list)
    grounded: bool = Field(
        description="True 当且仅当全部结论均来自已拉取的文档"
    )

def grounded_or_reject(payload: dict) -> AnswerOut:
    out = AnswerOut(**payload)
    if out.answer and not out.grounded:
        raise ValueError("HALLUCINATION_SIGNAL: grounded=False，拒绝放行")
    if out.grounded and not out.sources:
        raise ValueError("EVIDENCE_MISSING: grounded=True 但无引用来源")
    return out

grounded=False 的响应不是“低质量答案”，而是一个明确的失败任务，应进入按类别路由的重试或人工复核，而不是流向用户。这里的原则与治理层的判断一致：可观测性告诉你违规发生了，治理阻止违规发生。Schema 校验属于后者。

发布：门禁必须与模型无关，回滚必须由代码持有

Datadog 2026 年的报告揭示了一个结构性事实：70% 的生产组织运行三种以上模型，运行六种以上的比例一年内接近翻倍，每一次模型切换都是一次行为变更。这意味着依赖某个模型“自觉遵守”的约束是不可靠的。治理必须在生成之前执行，且与哪个模型执行提示词无关——这是一层设计上模型无关的强制层。

发布侧的工程纪律对应为“版本化 → 评估门禁 → 灰度 → 自动回滚”的链路：上线走 Canary，指标门限被击穿时自动回滚，回滚以快照为粒度、5 分钟内可执行、回滚动作本身留有记录。更关键的是回滚权限由代码持有，而不是由 Agent 的自我判断持有。以下发布门禁在灰度阶段检查健康信号，失败即翻回已知良好的快照：

def canary_gate(health: dict, thresholds: dict) -> str:
    if health["error_rate"] > thresholds["error_rate"]:
        return "ROLLBACK"
    if health["p95_latency_ms"] > thresholds["p95_latency_ms"]:
        return "ROLLBACK"
    if health["eval_score"] < thresholds["eval_score"]:
        return "ROLLBACK"
    return "PROMOTE"

def release(version: str, health: dict) -> None:
    decision = canary_gate(health, THRESHOLDS)
    if decision == "ROLLBACK":
        rollback_to(last_known_good_snapshot())  # 快照粒度，5分钟内
        audit("rollback", version, health)        # 回滚动作本身留痕
    else:
        promote(version)

ROLLBACK 不是建议，而是代码路径。灰度中的版本一旦触线，自动回到上一个已知良好的快照，不需要等待值班人员“确认一下”。

AI 产品从演示走向生产的距离，不是由模型参数或提示词技巧决定的，而是由评估是否被嵌入变更流程、Schema 是否把模糊故障转化为可重试的结构化事件、发布门禁是否与模型无关且由代码强制执行这三件事决定的。零售平台幻觉率从 15% 到 1.5% 的下降，Datadog 报告里“模型变更即行为变更”的警告，以及 Agents CLI 把评估做成爬山回路的实践，指向的是同一个结论：AI 产品的成熟度，最终是一种治理成熟度。当门禁、Schema 和回滚边界都由代码持有、模型无法绕过时，产品才真正从“能演示”变成“敢交付”。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

产品运营

产品