AI 产品从 0 到 1：把“持续变好”做成工程机制

原创

IT大佬 jzit-top

发布于 2026-11-06 16:53:29

1100

AI 产品从 0 到 1 最危险的错觉，是认为 Demo 跑通意味着产品接近完成。MIT 2025 年的研究显示，95% 的企业 AI 试点仍未被客户视为成功。差距不在技术，而在方法论：Demo 验证的是模型能力的上限，产品要兜住的是模型在真实分布上的下限，而让下限持续上移的机制，必须在第一行产品代码之前就开始设计。

第一项机制是推理分级，它同时解决成本与延迟。 将所有请求发给同一个前沿模型，是 MVP 阶段最常见的浪费。Fireworks 的报告显示，将每个请求路由到“能可靠处理它的最小模型”，可实现 60%–80% 的成本降低和 10–40 倍的推理加速；2026 年覆盖 200+ 企业项目的基准进一步指出，“先便宜后升级”的级联路由可将 60%–75% 的流量移到便宜层级，中位节省 42%，且没有可测量的质量回退。下面的路由器把请求按复杂度分到两档，并记录每一档的实际花费与延迟——路由规则可以迭代，但成本必须从第一天就被看见。

import time
from dataclasses import dataclass

@dataclass
class Tier:
    name: str; model: str; cost_per_1k: float

TIERS = [Tier("fast", "small", 0.0005), Tier("deep", "large", 0.005)]

def route(query: str, history: list) -> Tier:
    simple = len(query) < 50 and not any(k in query for k in ["为什么", "对比", "如何保证"])
    continuation = history and "刚才" in history[-1].get("content", "")
    return TIERS[0] if simple and not continuation else TIERS[1]

def serve(query, history, call_model):
    t = route(query, history)
    t0 = time.time()
    out = call_model(t.model, query)          # 占位：替换为真实调用
    return {"tier": t.name, "cost": t.cost_per_1k * len(query) / 1000,
            "latency": round(time.time() - t0, 3), "answer": out}

路由本身不难，难的是知道何时不该信任路由。上例的 simple 判断若把复杂问题误判为简单，省下的钱会以质量事故的形式还回去。因此第二项机制必须紧随其后：评测集即回归门禁。

评测不是上线后“看效果”，而是上线前的准入条件。 FutureAGI 2026 年的框架把这件事讲得很清楚：Benchmark 回答“哪个模型更聪明”，Metric 回答“这个系统在你的数据上是否正常工作”；前者用于选型，后者用于每一次变更的放行判断。一个可运行的最小评测不需要上千条样本，但必须覆盖三类：正常流量、边缘案例、以及每一个已修复的 Bad Case——修过的 Bug 必须变成永久的回归用例。下面的 gate 函数把三项指标转化为放行/拦截决策，核心不是阈值本身，而是让“是否上线”成为一个代码可以回答的问题。

def gate(results: dict, thresholds=None) -> str:
    th = thresholds or {"accuracy": 0.90, "hallucination": 0.05, "format_valid": 0.99}
    failures = []
    if results["accuracy"] < th["accuracy"]:
        failures.append(f"准确率 {results['accuracy']:.2%} < {th['accuracy']:.0%}")
    if results["hallucination"] > th["hallucination"]:
        failures.append(f"幻觉率 {results['hallucination']:.2%} > {th['hallucination']:.0%}")
    if results["format_valid"] < th["format_valid"]:
        failures.append("结构化输出校验未达标")
    return "BLOCK: " + "; ".join(failures) if failures else "PASS"

# 示例：两版 Prompt 的评测结果对比
v1 = {"accuracy": 0.91, "hallucination": 0.04, "format_valid": 0.995}
v2 = {"accuracy": 0.93, "hallucination": 0.08, "format_valid": 0.998}
print(gate(v1))   # PASS
print(gate(v2))   # BLOCK: 幻觉率 8.00% > 5%

v2 的准确率更高，但幻觉率越界，门禁必须拦截它。这正是评测集作为工程纪律的意义：它不追求单一分数的最大化，而是防止某一维度的改善以另一维度的劣化为代价。

第三项机制是让 Bad Case 回流成为默认路径，而非偶尔的人工操作。 没有回流，评测集是一个静止的过去时；有回流，它才成为飞轮的一部分。NVIDIA 的 NVInfo AI 在三个月部署期收集了 495 条负样本，分析出路由错误和查询改写错误两类主要失效模式，然后用微调把路由模型从 70B 换为 8B，路由准确率达到 96%，模型尺寸缩小 10 倍、延迟改善 70%。Notion 的 AI 团队则将系统化评测嵌入日常研发后，修复问题的速度从每天 3 个提升到 30 个，新模型发布到生产的周期压缩到 24 小时以内。这些数字的共同前提，是失败被结构化地捕获、归类、修复，并重新进入门禁。

从 0 到 1 的终点，不是产品上线那一刻，而是“产生失败信号 → 归因 → 修复 → 门禁验证 → 回到生产”这个循环第一次完整闭合的那一刻。推理分级让产品在经济上可持续，评测门禁让质量可被测量地守住，Bad Case 回流让系统在每一次失败后都比上一次更接近可用。AI 产品从 0 到 1 的专业性，最终不体现在选了哪个模型，而体现在是否把“持续变好”本身做成了不依赖个人意志的工程机制。

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

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

产品