LLMOps 常被理解成"给模型加监控"，真正卡住团队的却是另外三件事：每次改动不知道会不会退化、每次退化不知道是哪一层改的、每次成本上涨不知道涨在哪条链路。这三个问题对应三样工程设施：用例门禁、分层版本、成本账。把它们串成闭环，才叫 LLMOps。

1. LLMOps 管的是四条线

四条线必须有同一个关联键（trace_id / release_id），否则事后只能靠时间戳对齐，永远对不上。

2. 成本账：把 token 拆成四段

def cost_breakdown(calls):
    agg = dict(prompt=0, completion=0, cached=0, retry=0)
    for c in calls:
        agg["prompt"]     += c["prompt_tokens"]
        agg["completion"] += c["completion_tokens"]
        agg["cached"]     += c.get("cached_tokens", 0)
        agg["retry"]      += c["prompt_tokens"] if c["attempt"] > 1 else 0
    total = sum(agg.values())
    return {k: round(v / total, 3) for k, v in agg.items()} | {"total_tokens": total}

retry 段最容易被忽略，因为它散落在每次失败里。把它单独计数，往往能直接定位一个"某供应商偶发 500 导致全量重试"的问题。

按段统计还能回答一个关键问题：是输入太长，还是输出太长。这两个结论对应的改法完全不同——前者改检索与提示，后者改约束与模型档位。

3. 分层版本：三个独立版本号

合在一起构成 release_id = prompt@v12 + model@x + tools@v7。发布单上写这三段，而不是"后端 v2.3"，否则线上退化时无法二分定位。

RELEASE = {"prompt": "v12", "model": "qwen3-32b-2026-05", "tools": "v7"}

def tag(rec):
    return {**rec, "release_id": "/".join(f"{k}@{v}" for k, v in RELEASE.items())}

4. LLMTestCase：用例即门禁

LLMTestCase 的核心不是"跑一遍看输出像不像"，而是把预期拆成可判定的断言，并允许三类判据混用。

from dataclasses import dataclass

@dataclass
class LLMTestCase:
    name: str
    input: dict
    expected: dict
    graders: list          # ["exact", "schema", "llm_judge", "retrieval_hit"]

    def run(self, target):
        out = target(self.input)
        fails = [g for g in self.graders if not GRADERS[g](self.expected, out)]
        return {"name": self.name, "pass": not fails, "failed": fails, "out": out}

铁律：门禁里 llm_judge 占比不要超过三成，且必须与至少一个强判据配对。全弱判据的门禁会稳定通过，然后线上翻车。

用例集规模也有讲究：50 条能挡住方向性错误，300 条以上才有统计意义。每次线上事故都应沉淀一条用例，这是唯一能让门禁随时间变强的机制。

5. 可复现任务作为回归底座

SWE-agent 这类"给定仓库 + 问题，产出补丁并通过测试"的基准，价值不在刷分，而在它把质量变成了可复现的判据：补丁跑不跑得过测试，是二值的。

关键设计是冻结环境：镜像、依赖版本、测试命令全部固定。环境一漂，"通过率下降"就无法区分是模型退化还是依赖升级。

6. 灰度：按请求特征放量，不按百分比乱放

import hashlib

def bucket(user_id, release):
    h = hashlib.sha256(f"{user_id}:{release}".encode()).hexdigest()
    return int(h[:8], 16) % 100          # 0-99 稳定分桶

def pick(user_id, release, pct):
    return "new" if bucket(user_id, release) < pct else "old"

灰度的三个必备开关：比例、白名单、一键回滚。缺了"一键回滚"的灰度只是分批上线。

7. Auto-review：自动评审能做什么、不能做什么

def auto_review(out, rules):
    hits = [r for r in rules if r.match(out)]
    if any(r.blocking for r in hits):
        return {"decision": "block", "hits": [r.id for r in hits]}
    if hits:
        return {"decision": "flag", "hits": [r.id for r in hits]}   # 进人工队列
    return {"decision": "pass"}

自动评审的正确定位是分流器，不是裁判。让它直接决定"通过/拒绝"，等于把误判率直接写进业务。

8. E2ETest：端到端要断言什么

端到端测试在 LLM 系统里最容易写成"跑一遍不报错就算过"。有效的断言只有四类：

def e2e_assert(trace, case):
    assert schema_ok(trace["output"], case["schema"])
    assert all(c["doc_id"] in trace["retrieved"] for c in trace["citations"])
    assert trace["db_delta"] == case["expect_delta"]
    assert trace["steps"] <= case["max_steps"]

把"引用必须来自检索结果"写进断言，是拦幻觉最划算的一步——它不判对错，只判"你是不是编的"。

9. 排错：六种闭环失效

10. 边界：这些事不该塞进 LLMOps

11. 自测

1. 成本账为什么要单独统计 retry 段？它能暴露哪一类问题？
2. release_id 由哪三段组成？合成一个"后端版本号"会导致什么定位困难？
3. 门禁里 llm_judge 占比过高会发生什么？如何配平？
4. 用 SWE-agent 式仓库任务做底座时，为什么必须冻结运行环境？
5. 灰度为什么优先按用户哈希而不是按流量百分比？
6. 端到端断言里"引用必须来自检索结果"拦的是哪类错误？它判不了什么？