这次我们来看一个更偏工程视角的 AI 话题AI 系统的不确定性、可观测性和插桩。这个选题来自一场技术分享Charity Majors 把 AI、Determinism、Instrumentation 放在一起聊。它没有给你一个可以下载的模型也没有一键启动的 WebUI但它解决的问题比“跑通一个 demo”更接近生产当模型输出不固定、链路又长又黑你靠什么判断系统是正常还是异常先说结论AI 应用真正难的不是把模型调通而是让模型在复杂链路里可复现、可观测、可控。模型输出不确定prompt 改一个词结果就变用户输入分布和测试集不一致线上效果立刻衰减模型更新后没人知道哪个版本正在服务。这些问题的共同答案就是确定性和插桩。这篇内容适合正在做 AI 应用、模型部署、算法平台或 SRE 的同学前半部分讲思路后半部分给可落地的插桩模板、指标设计和排查清单。我会按这个顺序展开先给一张核心要点速览再分析为什么 AI 系统更需要可观测性然后讲怎样设计插桩数据、怎样定义关键指标接着给出模型部署、批量任务、API 调用时的工程化做法最后是常见问题排查和最佳实践。里面包含 JSON 日志示例、Python 元数据记录示例和批量任务伪代码都是通用模板需要按你实际项目的接口和路径调整。1. 核心要点速览这个选题不是模型跑分也不是工具安装教程。它的核心是一套工程方法论。所以我不堆模型名和版本号而是先把关键维度拉一张表。维度要点核心问题AI 在生产环境中的不确定性和黑盒问题关键词AI、Determinism、Instrumentation、可观测性核心判断确定性需要被设计和记录插桩是 AI 工程实践的入场券落地产物结构化日志、链路追踪、关键指标、实验记录、回归测试适用角色后端工程师、平台工程 / SRE、AI 应用开发者、技术管理者典型场景LLM 对话服务、批量推理任务、模型版本升级、Prompt 调优、成本分析不适用场景只做离线实验、不关心线上质量、不需要跨团队协作的临时脚本从工程实践的角度看AI 系统最大的问题不是“模型效果不够好”而是“效果好或不好都说不清原因”。传统后端有明确的调用链、状态码和异常堆栈AI 系统则经常只有一堆 prompt 和一堆输出坏了不一定抛异常只是答案变差了。所以可观测性不是“上了监控就行”而是要把每一次推理变成可以被查询、被对比、被重放的数据。这也是插桩在 AI 工程实践中被反复强调的原因没有数据就没有确定性没有确定性就没有稳定可迭代的 AI 服务。你可以在任意 LLM、图像模型或语音模型项目里套用这套框架。它不绑定具体技术栈也不需要立刻引入重量级平台。先从规范日志和记录元数据开始已经能解决大部分问题。2. 为什么 AI 系统比传统系统更需要可观测性2.1 从“函数调用”变成“概率推理输出”传统后端服务里一个函数输入固定参数输出基本可预期。即使出现错误也有异常类型、堆栈和错误码可以定位。AI 服务不是这样。每次推理都带着概率采样温度、随机种子、批处理顺序都可能影响输出。即使同一个 prompt上一次和下一次也可能给出不同的答案。这意味着线上出现一个坏结果时你不能简单地说“代码出 bug 了”。它可能是 prompt 的问题、模型版本的问题、输入分布变化的问题、采样参数的问题甚至只是用户的表达方式超出训练分布。没有可观测数据你只能靠重新复现这个 case 去猜。更麻烦的是AI 模型的坏结果往往不是“500 错误”而是“200 响应的内容不对”。传统监控里的错误率、延迟、流量这类黄金信号只能告诉你服务是否可用不能告诉你模型回答质量是否下降。可观测性在 AI 场景里必须覆盖到语义层和决策层。2.2 看不见的输入漂移和模型漂移模型训练时的数据分布和线上真实分布永远有差距。上线初期可能不明显随着用户增长、时间推移输入的自然语言表达、图片风格、语音口音都会逐渐变化。这种现象叫输入漂移。模型本身也会漂移比如你在某个版本的权重上做推理一个月后供应商更新了服务端模型输出风格和稳定性都变了。这些漂移不会直接报错但会慢慢侵蚀业务效果。比如客服机器人开始答非所问审核模型误判率上升推荐系统点击率下降。要发现漂移只能靠持续的指标采集和对比。你至少要记录每个请求的关键输入特征、输出特征、模型版本和推理参数才能回答“这个变化是什么时候开始的”。可观测性的本质是让看不见的问题变成可以查询的表格。AI 可观测性的本质则是让模型在每一层都留下可查证的脚印。2.3 成本和质量纠缠在一起传统服务里的成本相对稳定接口调用次数和资源用量基本成正比。AI 服务不同token 数量直接影响成本而 token 数量又由输入长度、系统 prompt、模型版本、用户行为共同决定。一个使用人数不多的功能可能因为 prompt 太长、输出 token 上限设置过高产生远超预期的账单。成本和质量还经常互相影响。为了省成本你可能缩短输出长度结果答案质量下降为了提高质量你增加更复杂的 prompt结果 token 消耗变大。如果可观测性里只有延迟和错误率没有 token 消耗和单请求成本优化时就会像盲人摸象。所以我建议AI 服务的标准日志里必须包含 prompt_tokens、completion_tokens、总 token 数并尽可能计算出单次推理成本。这样才能把“质量变差了”和“成本变高了”放在同一张表里分析。3. 确定性AI 工程实践里最容易忽略的复现问题3.1 AI 确定性到底指什么Determinism确定性指的是“同样的输入和条件是否得到同样的输出”。传统代码里这是默认行为到了 AI 场景反而成了稀缺品。模型的推理结果受采样参数、随机种子、浮点计算顺序、硬件型号甚至批处理大小影响同一个 prompt 在不同环境下可能得到不同结果。确定性之所以重要是因为它直接决定了你能不能调试。如果同一个问题在线上复现不出来所有的性能排查、质量评估、安全审查都会变得异常困难。你可以接受模型有一定随机性但必须知道随机性来自哪里并且有能力在需要时固定它。一个可落地的做法是为每次推理生成一个 inference_id并记录完整的上下文。这样无论结果好坏你都能回到真实的请求现场而不是对着一条孤零零的日志猜测。3.2 每次推理至少要记录什么下面这段 Python 代码是一个通用的推理元数据构建示例比较适合作为记录的最小集合。实际字段按项目调整。import hashlib import time import uuid def build_inference_metadata(prompt, model_name, model_version, temperature0.0, seed42): prompt_hash hashlib.sha256(prompt.encode(utf-8)).hexdigest()[:16] return { inference_id: str(uuid.uuid4()), timestamp: time.time(), model_name: model_name, model_version: model_version, prompt_hash: prompt_hash, temperature: temperature, seed: seed, max_tokens: 512, stop_sequences: [\n\n], }这段代码解决三个问题一是每条推理都有全局唯一 ID方便和链路追踪关联二是记录模型版本方便后续做回归对比三是记录 prompt 的哈希值既能在不暴露完整文本的前提下判断“哪些请求用了相同 prompt”。如果你在图像生成、语音合成等场景可以类似地记录输入图哈希、参考音频哈希、分辨率、步数、采样器等关键参数。原则是一样的保证实验结果可以被复盘。3.3 不要迷信“温度设为 0 就完全确定”很多团队会把 temperature 设为 0以为这样输出就完全稳定。实际上温度只是影响随机性的一个因素。GPU 算子、并行推理顺序、模型量化、API 服务端的隐藏更新都可能带来细微差异。对于大部分业务场景温度设为 0 能显著降低随机性但你不能把它当作绝对保证。更可靠的做法是把确定性问题拆成“我们能否复现”和“我们需要多大程度稳定”两个层次。像分类、抽取这类结构化任务要求严格稳定像文案润色、创意生成这类任务接受一定随机性但每次推理都必须记录参数否则后面没法归因。另外如果你的应用依赖外部模型 API确定性会更难控制因为你无法控制服务端的 batch 和推理实现。这时候要在应用层做兜底保存输入和输出快照定期对关键 case 做对比测试而不是假设同一个请求永远返回同一个结果。4. 插桩不是记日志AI 可观测性的数据采集设计4.1 传统系统日志和 AI 事件日志的差别传统日志经常是“发生了什么异常”的记录格式相对简单时间、级别、消息、堆栈。AI 场景需要的是“一次推理完整旅程”的记录它更像事件流而不像错误日志。一个 AI 事件至少应该包含以下几个维度请求入口信息用户、会话、trace_id、来源渠道。模型调用信息模型名、模型版本、温度、seed、max_tokens、停止词。输入信息prompt 或输入的哈希、长度、关键特征。输出信息输出文本或结果的哈希、长度、token 数。性能信息首 token 延迟、总延迟、排队时间。成本信息prompt_tokens、completion_tokens、估算成本。质量信息人工评价、点赞点踩、是否安全、是否触发兜底逻辑。传统日志只要做到“能定位异常”AI 事件日志要做到“能还原现场”。两者差别很大前者是事后查错后者是事中和事后的综合复盘。4.2 一份可落地的 AI 结构化日志模板JSON 格式是最容易落地的结构化日志格式方便写入 Elasticsearch、ClickHouse、Loki 或各类云日志平台。下面是一个最小示例{ timestamp: 2025-01-01T10:00:00Z, trace_id: abc123, inference_id: uuid-001, event: llm_completion, model: gpt-4o-mini, model_version: 2025-01-01, prompt_hash: f1a2b3c4d5e6, prompt_tokens: 230, completion_tokens: 120, total_tokens: 350, latency_ms: 850, first_token_latency_ms: 120, cost_usd: 0.0002, temperature: 0.0, seed: 42, response_hash: a1b2c3, user_feedback: null, status: success }字段不是固定的。你可以按业务加入 input_schema、output_schema、错误码、重试次数、缓存命中与否等。这里特别提醒不要把完整的原始 prompt、用户隐私数据、文件内容直接写进日志。建议对敏感内容做哈希或脱敏处理日志平台也要做权限控制。合规问题是 AI 工程实践里绝不能忽略的一环。4.3 插桩密度全量、采样和摘要很多团队担心“全量插桩”会带来大量日志成本。确实AI 日志字段多、单条体积大全量保存到生产环境压力不小。比较稳妥的策略是分级处理全量记录inference_id、trace_id、model_version、token 数、延迟、状态这些基础字段。采样记录原始输入输出中按比例采样比如 10% 或 1%用于质量评估。摘要记录对完整 prompt 和输出做哈希、长度统计用于分布分析。关键 case 全保留触发异常、用户反馈差、成本异常高的请求一定要完整保存。这个思路既控制了存储成本又保留了关键时刻的完整现场。不要一上来就“全部都要”也不要因为成本干脆什么都不记。根据实际流量的量级逐步加大密度比一开始追求完美更现实。4.4 隐私和合规边界采集 AI 推理数据时要特别注意数据合规。用户输入的内容可能包含个人信息、商业机密输出内容也可能涉及版权问题。建议遵循以下原则能脱敏就脱敏能哈希就哈希。日志平台做访问控制禁止随意查询原始输入。批量任务里的输入文件处理完要及时清理或加密归档。涉及人脸、声音、私有文档的场景必须先确认是否有合法授权。如果使用第三方模型 API要明确数据是否会被用于训练必要时用私有化部署方案。这不是可有可无的“政治正确”而是生产系统能不能长期运行的基础条件。插桩采集到的数据越敏感系统在隐私保护上的要求就越高。5. 落地一套 AI 可观测指标体系5.1 通用性能指标传统可观测性里的指标在 AI 服务里依然有效。我建议把以下几类作为最低标准分类指标含义流量请求数、并发数、token 消耗总量看服务用量和成本趋势性能P50/P95/P99 延迟、首 token 延迟、排队时间判断用户体验和瓶颈错误请求失败率、超时率、异常响应率判断服务是否可用资源CPU、内存、显存、磁盘判断部署资源是否充足特别是首 token 延迟对 LLM 流式输出非常重要。传统服务的“整体延迟”在流式场景下不够直观用户往往更关心第一个字什么时候出现。这个指标应该在应用层埋点计算而不是只依赖模型调用耗时。5.2 AI 特有质量指标通用指标只能告诉你“系统是不是活着”AI 特有指标才能告诉你“系统是不是输出得对”。质量指标因业务而异下面列出几类常见方向语义相似度或人工评分适用于聊天、客服、内容生成。结构化字段准确率适用于提取、分类、标签任务。用户反馈信号点赞/点踩、复制、采纳、二次编辑率。安全指标违规内容拦截率、幻觉率、敏感信息泄露率。成本指标单请求 token 数、单请求成本、成本环比变化。这些质量指标不能只靠模型离线评估必须和线上真实用户行为绑定。比如对话机器人可以记录“用户是否重新提问”推荐系统可以记录“推荐内容的点击率”内容生成工具可以记录“用户是否再次编辑”。这些行为信号比任何离线评估都更接近业务结果。5.3 阈值怎么定、报警怎么设很多团队一上来就设一堆阈值结果要么告警风暴要么阈值形同虚设。更稳妥的做法是先记录两周基线数据再看指标分布定阈值。比如延迟类指标可以先看 P95 基数再设“超过基线 20% 持续 5 分钟”之类规则成本类指标先看日均 token 消耗再设“单日成本超出预期 30%”的额度告警质量类指标如果人工评分还没有建立就先别急着报警先把数据收集起来。报警不是目的定位才是。每条报警都应该能跳转到对应的 trace_id、inference_id 和原始事件日志。如果报警只能告诉你“服务变慢了”但你不能定位是某个模型版本、某类 prompt 还是某类输入造成的那这个报警价值很低。6. AI 模型部署、批量任务与接口调用的工程化6.1 模型发布前的回归验证AI 模型升级不能只看离线指标。版本上线前应该准备一套固定回归测试集覆盖典型场景和边界情况。回归的目的是比较新旧版本在同一批输入上的输出差异尤其是关键业务字段和安全性。回归测试不一定要自动化得很复杂。最基础的做法是维护一批固定 prompt 或输入文件每次模型升级后跑一遍人工或半自动地检查输出是否符合预期。如果输出质量明显变化就要追查是新模型的问题还是有意的 prompt 变化。建议把回归测试的输入、输出、模型版本、时间都记录下来。这样后续如果有人问“这个输出是哪个版本生成的”你能给出明确答案。6.2 金丝雀发布先跑小流量模型服务不像普通后端服务切换版本后不能保证输出行为一致。直接全量上线有风险更稳妥的方式是金丝雀发布先在少量流量上切到新模型和旧模型的结果做对比确认关键指标没有恶化再逐步扩大流量。实际操作中可以在网关或应用层加一个分流开关按用户 ID、请求 ID 的哈希百分比控制新模型流量。同时把新旧两个版本的结果都记录到可观测平台比较 token 消耗、延迟、用户反馈、安全命中率等指标。金丝雀发布需要可观测数据支撑否则你不知道该在什么时候回滚。这里又回到了插桩的必要性没有版本号、没有 trace_id、没有结果对比你只能用“感觉新模型好像不太行”来决策这显然不是工程化的方式。6.3 批量任务的任务状态与幂等设计批量推理是 AI 工程实践里很常见的一类场景大量文档解析、批量图片处理、离线内容审核、TTS 音频生成等。批量任务比在线接口更容易出问题因为任务量大、执行时间长、失败原因多而且中断后不好恢复。批量任务至少要有以下字段task_id、输入文件引用、任务状态、重试次数、幂等键、开始时间、结束时间、最后一次错误信息。下面是一个参考字段结构import hashlib import uuid def create_task(input_ref, max_retry3): task { task_id: str(uuid.uuid4()), input_ref: input_ref, input_hash: hashlib.sha256(input_ref.encode(utf-8)).hexdigest()[:16], status: pending, retry_count: 0, max_retry: max_retry, idempotency_key: hashlib.sha256(input_ref.encode(utf-8)).hexdigest(), created_at: None, started_at: None, finished_at: None, last_error: None, } return task幂等键的设计非常关键。比如处理同一个文档时网络中断导致任务重试如果不带幂等键就可能重复生成、重复计费。生产级任务队列通常会设置一个唯一业务键重复投递时直接被丢弃或返回已有结果。批量任务的状态机建议至少包含pending、running、succeeded、failed、retrying、dead。dead 队列用来存放多次重试仍然失败的任务方便人工介入。所有状态变更都需要有时间戳和错误信息这样排查时才能快速定位是哪一个文件、哪一次执行、什么原因失败。6.4 API 接口调用与重试策略AI 服务通常会暴露 HTTP API。调用方需要注意超时、重试和限流问题。下面是一个简单的 Python 调用模板import requests def call_completion_api(prompt, temperature0.0, timeout30): url http://127.0.0.1:8000/v1/completion payload { prompt: prompt, temperature: temperature, max_tokens: 512, } try: response requests.post(url, jsonpayload, timeouttimeout) response.raise_for_status() return response.json() except requests.exceptions.Timeout: return {error: timeout, prompt: prompt[:50]} except requests.exceptions.HTTPError as exc: return {error: fhttp_error: {exc.response.status_code}}实际使用时需要按项目的接口地址、鉴权方式和参数名调整。这里重点想说的是两个工程原则网络错误可以重试但要把超时时间设短并加指数退避避免雪崩。业务错误不能盲目重试。比如模型返回内容不合规、被限流、参数错误重试只会增加成本。如果有缓存还要注意缓存键的设计。缓存键应包含模型名、模型版本、prompt 哈希、采样参数等否则新版本模型上线后还可能命中旧版本的结果缓存造成版本混乱。6.5 接口服务的安全边界对外或对内提供 AI 接口时安全边界不能省接口要加鉴权避免被任意调用刷成本。如果接口面向公网建议做速率限制、配额管理和访问来源限制。批量上传的输入文件要做类型检查、大小检查和内容安全扫描。涉及肖像、声音、版权素材的任务必须保留授权记录不能把“用户提交了”当成“用户有权使用”。这是 AI 工程实践里容易被忽略但风险很高的部分。代码和模型再完善如果接口裸奔出的就是安全事故。7. 常见问题与排查方法下面按实际工程中经常出现的问题整理一张排查表。它不绑定具体平台只提供排查思路。问题现象可能原因排查方式解决方案相同模型相同 prompt 结果不一样采样参数、随机种子、批处理顺序、API 服务端隐藏更新对比两次推理的 metadata 和请求参数固定 temperature/seed记录模型版本关键任务使用缓存模型升级后线上结果变差没有做回归测试就直接全量上线查看生产流量中的 model_version 分布建立固定回归测试集先金丝雀发布再逐步放量接口偶发超时服务冷启动、排队过长、下游模型 API 抖动查看排队时间、首 token 延迟、下游调用日志加超时和重试做负载均衡必要时扩容批量任务卡住不结束任务缺少状态机、没有超时回收机制查看任务状态是否长期停留在 running增加任务超时、重试和死信队列日志查询不到或者难定位没有 trace_id / inference_id日志字段不统一检查日志是否关联到同一个请求上下文在入口生成请求级 ID全链路透传上下文成本突然上涨prompt 变长、输出过多、模型版本成本上涨、被恶意调用按 model、接口、用户维度分组统计 token 成本设置 token 上限、限流、配额管理建立成本告警显存或内存不足并发过高、模型过大、批量数设置过大观察资源曲线和请求并发量降低 batch size、模型量化、排队限流、扩容模型输出质量不稳定输入漂移、prompt 设计脆弱、模型版本变动对比输入分布、输出分布、用户反馈指标建立质量基线定期回归对关键场景做兜底规则这里需要特别提醒一点如果你的系统里 trace_id 和 inference_id 还没有贯通排查任何 AI 问题时都会非常吃力。你可以在网关层生成统一请求 ID然后通过日志库的上下文传递到下游把一次用户请求涉及的所有模型调用串起来。这是一切高级监控、评估和归因的基础。8. 吃你的蔬菜AI 工程实践里的最佳习惯8.1 把基础工程放在追新模型前面“Eating your broccoli”翻译成工程语言就是做那些不好看、不性感、但必须做的基础工作。每天追新模型、换更强的 prompt 技巧当然让人兴奋但如果没有版本管理、没有结构化日志、没有回归测试、没有批量任务的可重试机制新模型带来的收益很快会被混乱抵消。从长期看一个团队能不能稳定交付 AI 能力取决于基础工程做得有多扎实。固定的模型版本、固定的数据采集流程、固定的发布流程这些都比某一个模型的精度提升更重要。不是反对用新模型而是要让新模型在新的可观测机制下安全上线。我最常看到的翻车案例是团队花大量时间调 prompt线上效果一旦变差没有人能回答“是不是模型服务端偷偷换了版本”或者“哪些用户输入导致输出漂移”。这类问题靠换模型解决不了只能靠可观测性解决。8.2 团队落地建议如果团队刚开始建设 AI 可观测性不要一口吃成胖子。建议分三步走第一步从一次推理的最小元数据开始。为每个请求补上 inference_id、model_version、prompt_hash、token 数和时间戳。第二步把日志格式统一成 JSON并把 trace_id 或业务请求 ID 透传到所有下游服务。这一步完成后至少可以回答“这个用户这次请求经历了什么”。第三步把模型发布流程和回归测试打通。每个模型版本上线前必须跑固定测试集上线后保留一段时间的流量对比再决定是否全量。这三步做完你已经超过很多“只跑 demo、只调 prompt”的团队了。后面再上自动评估、异常检测、成本分析平台都是水到渠成的事。8.3 最值得先做的三件事如果只能做三件事我强烈建议按下面的顺序来第一固定模型版本和关键推理参数。不要在线上“随机使用最新模型”每次调用都要能追溯到具体版本。第二给每次推理生成一个唯一 ID并把它写入日志、缓存键、任务状态和错误信息里。这个 ID 是所有排查工作的锚点。第三先把结构化日志模板做出来。JSON 里哪怕先只有十个字段也比散落的、没有上下文的文本日志强得多。有了结构化数据后面用工具分析或写脚本统计都顺畅。这三件事都不需要引入大型平台也不需要一两天就能全部做完。但它们决定了你在生产环境里能不能快速定位一个 AI 故障决定了你换模型、调 prompt、分析成本时有没有依据。先不要急着上复杂平台也不要把精力全放在追最新模型上。把插桩和确定性这两件基础工作吃透比任何一次模型升级都更值。建议收藏备用尤其是你正在把 AI 功能推到生产环境的时候。先把最小可观测闭环跑通再谈更高级的自动评估和成本优化这条路更稳。