1. 项目概述当LLM应用需要“换芯”时我们如何优雅地“换挡”最近在折腾大语言模型应用升级的朋友估计都遇到过同一个灵魂拷问新模型上线你敢直接全量切吗我是不敢。去年我们团队就因为一次“自信满满”的全量发布新模型在某个特定业务场景下产生了不可控的“幻觉”输出直接导致线上客诉短时激增那场面至今心有余悸。这就像给一辆高速行驶的汽车直接更换发动机风险极高。于是一套源自传统软件工程的成熟方法论——Canary发布金丝雀发布被我们引入到了LLM应用的生命周期管理中核心目标就一个让模型升级像“换挡”一样平滑、可控、可观测。简单来说LLM应用的Canary发布就是通过一套精细的流量控制机制让一小部分用户流量比如1%先去“品尝”新模型v2版本的“滋味”而绝大部分用户99%依然稳定地使用旧模型v1版本。我们则像一名品酒师密切观察这1%流量下新模型的各项表现指标响应延迟、Token消耗、回答质量、业务转化率甚至是用户的主观反馈。只有确认新模型在所有关键维度上都稳定达标甚至更优我们才会逐步扩大新模型的流量比例直至完全替换。整个过程服务不停用户无感。这不仅仅是技术活更是一套工程实践体系。它围绕着三个核心动作展开灰度切流如何精准、安全地分流、快速回滚发现问题如何秒级恢复、以及流量染色如何追踪、区分和分析每一股流量。对于任何将LLM应用于生产环境尤其是面向C端用户或核心业务流程的团队来说掌握这套实践是从“玩具”走向“产品”的关键一步。无论你是算法工程师、后端开发还是SRE理解并实施它都能让你在模型迭代的惊涛骇浪中握紧手中的舵。2. 核心需求与挑战为什么LLM应用更需要Canary你可能会问传统的微服务用Canary发布很正常LLM应用不就是个API调用吗为啥这么“矫情”这里面的水其实挺深。LLM应用的升级远不止是更换一个后端服务那么简单它带来了几个独特的、高风险的挑战。2.1 模型行为的不可预测性与“退化”风险这是最核心的痛点。传统的软件升级功能是确定的修复了A Bug增加了B特性。但LLM模型的升级尤其是不同版本或不同基座模型之间的切换其输出行为存在巨大的不确定性。新模型可能在通用任务上表现更优但在你业务特有的“刁钻”问题上却可能表现得更差这种现象常被称为“模型退化”。例如v1模型能很好地遵循我们设定的“拒绝回答涉及隐私问题”的指令但v2模型可能会在同样场景下“侃侃而谈”。这种退化不是Bug而是模型内在能力分布的变化无法通过常规测试完全覆盖。2.2 输出质量的评估滞后与主观性传统接口的成败看状态码、看响应时间、看错误日志几乎可以实时判断。但LLM的输出质量评估要复杂得多。一方面自动化评估如基于规则的关键词检查、基于embedding的相似度计算只能覆盖部分维度真正的“通顺性”、“有用性”、“安全性”需要人工评估这存在分钟级甚至小时级的延迟。另一方面质量好坏有很强的主观性。Canary发布为我们赢得了宝贵的观察窗口可以将新模型的输出同步给内部评审团队或小部分友好用户进行快速验证而不是让所有用户成为“小白鼠”。2.3 性能与成本指标的剧烈波动不同模型的参数量、架构优化程度天差地别。从7B模型升级到70B模型响应延迟和Token消耗成本可能呈数量级增长。直接全量切换很可能瞬间击穿你的服务延迟SLA服务等级协议或导致当月API预算超标。通过灰度切流我们可以像“压力测试”一样逐步观察新模型对现有基础设施GPU算力、内存、带宽的真实压力并有机会在影响扩大前进行扩容或优化。2.4 复杂的上下文与依赖环境现代的LLM应用很少是孤立的/v1/chat/completions调用。它往往嵌套在复杂的业务链路中前端可能通过LangChain、Dify等工作流编排中间可能涉及RAG检索增强生成从向量数据库拉取上下文后端可能还需要调用函数工具Function Calling。新模型在理解复杂提示词Prompt、处理长上下文、或执行工具调用时可能与旧模型有细微但关键的差异。Canary发布允许我们在真实的、完整的业务上下文中验证新模型而不是在隔离的沙箱里。实操心得我们曾用新模型在测试环境跑通了所有单元测试和集成测试自信满满。但灰度到5%线上流量时发现新模型对工作流中某个特定格式的JSON输出解析失败原因是新模型在生成JSON时更“严谨”地多了一个换行符导致下游服务解析异常。这个案例告诉我们测试环境永远无法100%模拟线上流量和数据的复杂组合Canary是最后一道也是最重要的一道防线。3. 整体架构设计与核心组件要实现一套可用的LLM Canary发布系统不能只靠某个神奇的配置项它需要一组相互协作的组件共同构成一个控制平面。下图勾勒了一个典型的架构全景[客户端/网关] -- [流量调度层] -- [模型路由层] -- [v1模型服务池] 或 [v2模型服务池] | | | | | | [流量染色与上下文传递] [监控与指标收集] | | | | | | v v | -----------[统一监控与告警平台]----------- | | ----------------------[数据仓库与评估平台]----------------------3.1 流量调度层流量的“交通指挥中心”这是整个系统的入口和大脑通常由API网关或专用的流量治理服务如基于Envoy的Service Mesh担任。它的核心职责是接收所有LLM请求无论是来自前端、移动端还是其他微服务。解析请求并附加染色标识根据预设的规则如用户ID哈希、请求头、地域等决定当前请求应该走“稳定通道”v1还是“实验通道”v2并为此请求打上一个唯一的、贯穿链路的染色标签如x-model-version: canary-v2。执行分流规则维护一个动态的分流配置例如5%的流量导向v2。这个配置应该支持热更新无需重启服务即可调整分流比例。工具选型解析云原生场景Istio或Linkerd是天然的选择。它们可以通过VirtualService和DestinationRule轻松实现基于百分比的流量切分并自带强大的可观测性。你可以写一个类似如下的Istio配置apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: llm-api-route spec: hosts: - llm-api.example.com http: - match: - headers: x-user-id: exact: “test-user” # 给特定测试用户全量走v2 route: - destination: host: llm-v2-service - route: # 默认路由规则按权重分流 - destination: host: llm-v1-service weight: 95 - destination: host: llm-v2-service weight: 5传统/轻量级场景使用Nginx或OpenResty的split_clients模块或者直接在应用网关如Spring Cloud Gateway, Kong中编写自定义过滤器/插件来实现灵活性更高。3.2 模型路由层请求的“智能导航仪”流量调度层决定了“要不要去v2”而模型路由层则负责“到了v2服务后具体调用哪个模型实例”。这一层通常内嵌在LLM应用服务本身或一个轻量的代理侧车中。它的核心工作是读取流量染色标签从请求头如x-model-version中获取调度层的决策结果。动态选择模型端点根据标签将请求路由到对应的模型API端点。例如标签为canary-v2的请求会被转发至https://api.openai.com/v1/chat/completions模型参数为gpt-4-turbo-2024-04-09而稳定流量的请求则转发至https://api.openai.com/v1/chat/completions模型参数为gpt-4-0125-preview。传递染色上下文确保这个染色标签在后续的所有内部调用如调用向量数据库检索、调用外部工具中都能被传递便于全链路追踪。实现要点这里的关键是无侵入性。理想情况下业务代码不应该感知到正在运行的是哪个模型版本。路由逻辑应该被封装在基础库或中间件中。例如在Python的FastAPI应用中你可以使用一个依赖注入Dependency或中间件Middleware来根据请求头动态设置调用LLM API的客户端配置。3.3 监控与指标收集系统的“眼睛”和“耳朵”没有度量就没有控制。Canary发布的决策完全依赖于数据。我们需要收集以下几类核心指标性能指标请求耗时P50, P95, P99、Token生成速率、GPU利用率。业务指标对于聊天应用可能是会话轮次、用户满意度评分如有对于内容生成应用可能是内容采纳率、编辑修改率。成本指标每个请求的输入/输出Token消耗折算成API调用成本。质量指标最难也最关键自动化评分使用另一个轻量级LLM如GPT-4作为裁判对回答进行相关性、有用性、安全性评分。人工评估采样系统自动对一小部分Canary流量和基线流量的输出进行采样并推送至内部评估平台供标注团队快速评审。异常检测监控输出中是否出现敏感词、不符合格式要求的JSON等。工具链整合指标可以推送到Prometheus日志包含请求、响应、染色标签进入ELK或Loki追踪信息上报到Jaeger或Zipkin。最重要的是需要一个统一的仪表盘如Grafana来并排对比v1和v2通道的各项指标一目了然地发现差异。3.4 决策与回滚控制台人的“指挥棒”这是一个人机交互界面允许运维或算法工程师实时查看并排的监控仪表盘。动态调整通过滑块或输入框实时修改灰度分流比例从1%到50%。一键操作在发现严重问题时点击“一键回滚”按钮瞬间将所有流量切回v1稳定版本。查看评估报告集成人工评估的结果和自动化评分报告。这个控制台可以是一个简单的内部Web应用也可以集成到现有的运维平台如Kubernetes Dashboard或CI/CD工具如Argo Rollouts中。注意事项监控的维度一定要和你的业务目标对齐。如果业务核心是降低延迟那就重点看耗时指标如果核心是提升回答准确性那就要在质量评估上投入更多。切忌盲目收集数据却没有明确的决策标准。4. 关键实践一精细化灰度切流策略灰度切流不是简单随机分5%的流量那太粗糙了。我们需要设计更精细、更安全的策略以应对不同风险等级的场景。4.1 分流维度的选择从粗放到精细随机百分比分流最简单的方式根据用户ID或请求ID进行哈希取模。适用于风险极低、或进行初期“冒烟测试”的场景。优点是实现简单样本随机。缺点是无法控制影响范围可能误伤高价值用户。基于用户特征的分流内部用户/测试用户先行让公司员工、内测用户群100%使用新模型收集第一手反馈。这是最安全的起步方式。按用户价值分层例如先让新注册用户、低活跃度用户进入Canary保护核心高价值用户的体验。按地域分流先选择某个特定地域如某个省份的流量全量切换观察地域性数据下的表现。基于请求特征的分流按接口或功能点如果LLM服务多个功能如聊天、总结、翻译可以先在非核心功能上灰度新模型。按请求复杂度先让简单的、单轮的问答请求走新模型复杂的、多轮带上下文的对话请求仍走旧模型。按流量来源区分来自App、Web、API的不同流量可以选择从某一个来源开始。4.2 渐进式放量流程步步为营一个稳健的放量流程通常遵循“慢启动快验证稳步走”的原则阶段一内部验证0% - 1%首先将流量切给内部测试账号进行完整的功能和集成测试。同时开启对Canary流量100%的请求/响应日志记录和人工评估。阶段二小范围外部1% - 5%将1%的线上真实流量导入Canary。重点关注性能指标和异常率。此时自动化质量评估系统需要全量运行。阶段三扩大范围5% - 20%如果核心指标延迟、错误率、自动化评分均优于或持平基线且无负面用户反馈可以将比例提升至5%-20%。这个阶段要开始关注业务指标如用户停留时间、转化率的对比。阶段四全面推广20% - 50% - 100%逐步将比例提升至50%并最终全量。每次提升后需要稳定观察至少一个业务周期例如24小时确保没有隐藏的周期性问题。参数计算示例假设你的服务QPS每秒查询率是1000。1%的流量意味着每秒有10个请求会打到新模型。如果你评估一个请求的平均人工评审需要1分钟那么要积累100个有效人工评估样本大约需要100 / (10 * 60) ≈ 0.17小时即10分钟左右。这可以帮助你估算人工评估的反馈速度。4.3 流量染色Traffic Dyeing的实现细节流量染色是实现精细化监控和追踪的基础。它的核心是给每一股流量打上一个唯一的、可传递的“标签”。染色标识生成与注入通常在网关层生成。可以使用一个包含丰富信息的标识符例如canary-{version}-{hash}。这个标识需要被注入到请求头中如X-Trace-Model: canary-gpt4-2024-04-09-abc123。全链路透传这是关键这个请求头必须在整个调用链中传递。在你的LLM应用服务中在调用任何下游服务数据库、缓存、外部API时都需要携带这个头。如果你使用像OpenFeign、RestTemplate这样的HTTP客户端需要配置拦截器自动传递特定头。在异步任务如消息队列中需要将染色标识作为消息的一个属性进行传递。日志与追踪关联在记录日志或上报追踪Trace时将这个染色标识作为关键字段如model_version记录下来。这样无论是在ELK中搜索日志还是在Jaeger中查看调用链你都可以轻松地通过model_version: canary-*来过滤出所有Canary流量的相关信息实现精准的对比分析。实操心得我们曾经因为一个下游服务没有正确传递染色头导致在排查问题时无法区分某个数据库慢查询到底是v1流量还是v2流量引起的浪费了大量时间。后来我们制定了一条铁律所有内部服务间的HTTP客户端和消息队列生产者必须强制传递一组约定的“透传头”包括染色头、Trace ID等。这个规范通过代码审查和中间件强制实施。5. 关键实践二快速、可靠的自动化回滚机制回滚不是Plan B而是必须与发布并行的Plan A。目标是在发现问题的瞬间能在分钟级甚至秒级内将所有流量无感地切回稳定版本。5.1 回滚的触发条件如何定义“问题”首先需要明确什么情况下应该触发回滚。这需要预设清晰的、可量化的熔断规则硬性错误率熔断当Canary通道的HTTP 5xx错误率或模型调用超时率超过阈值如1%持续2分钟自动触发回滚。性能劣化熔断当P95或P99响应时间相比基线版本恶化超过一定比例如50%自动触发回滚。业务指标熔断如果接入了实时业务指标如订单转化率当Canary通道的指标显著低于基线通过统计检验如t-test可配置自动或人工确认后回滚。质量评分熔断自动化质量评分系统LLM-as-a-Judge给出的平均分低于阈值或检测到敏感内容的比率异常升高。人工强制回滚在控制台提供一键回滚按钮供运维人员在任何觉得不妥的时候手动触发。5.2 回滚的技术实现简单直接才最快回滚的核心操作就是修改流量调度层的路由配置。为了追求速度实现应该尽可能简单配置热更新网关或Service Mesh的路由规则必须支持不重启的热更新。通过调用其管理API如Istio的Kubernetes APINginx的nginx -s reload或动态上游配置将v2的权重直接设置为0v1的权重设置为100。状态外置分流比例、当前生效的模型版本等状态信息不应该写死在应用配置里而应该存放在一个外部配置中心如Consul, Etcd, Apollo或数据库里。控制台修改的正是这个外部状态各服务节点监听其变化。会话保持考虑对于多轮对话应用需要特别注意。如果用户的前几轮对话在v2模型上进行回滚后后续的请求被路由到v1模型。v1模型可能无法完美理解v2模型产生的历史上下文。解决方案有两种牺牲一致性保证可用性这是更常见的做法。回滚后新会话从v1模型重新开始。可以在回滚时向客户端发送一个温和的提示如“系统已优化我们重新开始吧”。上下文迁移复杂将v2模型生成的对话历史通过一定的格式转换作为v1模型的输入。这实现复杂且可能引入新的不一致性通常不推荐。5.3 回滚后的善后工作回滚操作完成流量切回v1并不意味着事情结束。问题定位立即利用染色标签从日志和监控中拉取所有Canary流量的详细记录特别是那些触发回滚的异常请求进行根因分析。是新模型本身的缺陷还是部署问题是配置错误还是遇到了未曾预料的数据分布数据清理如果Canary版本引入了新的数据格式或数据库表需要考虑是否以及如何清理这些实验数据。流程复盘召开复盘会议分析为什么这个问题没有在测试阶段被发现是测试用例覆盖不足还是评估标准有问题更新测试策略和Canary发布检查清单。避坑技巧一定要定期进行“回滚演练”。就像消防演习一样定期比如每季度在低峰期模拟一次故障并执行完整的回滚流程。这能验证你的工具链是否畅通团队对流程是否熟悉以及最重要的——回滚是否真的能在承诺的时间内完成。我们曾因为一个配置缓存问题导致回滚指令生效延迟了5分钟这个隐患就是在演练中发现的。6. 关键实践三模型质量的评估与对比这是Canary发布中最具挑战性的一环也是决定发布成败的“裁判席”。我们需要建立多维度的评估体系。6.1 自动化评估规模与效率的保障自动化评估可以在全量流量上快速运行提供实时或近实时的反馈。基于规则的检查安全性过滤检查输出是否包含敏感词、个人身份信息PII、仇恨言论等。格式合规性对于需要输出JSON、XML、特定标记语言如Markdown的场景检查语法是否正确。长度控制检查输出是否超过或短于预期长度范围。基于嵌入Embedding的相似度将新模型v2和旧模型v1对同一批输入产生的输出分别转换为向量使用如text-embedding-3-small计算它们的余弦相似度。大面积、显著的相似度下降可能预示着模型行为的重大改变。使用“裁判”LLM进行评估LLM-as-a-Judge这是目前最主流且有效的自动化评估方法。使用一个更强大、更可靠的LLM如GPT-4作为裁判让它根据一系列标准来评估v1和v2的输出。单答案评分给裁判模型提供问题Query、待评估的回答Response和评分准则Rubric让它输出一个分数如1-5分或分类如“好/中/差”。对比评估给裁判模型提供问题、回答Av1、回答Bv2让它判断哪个更好或者给出“A更好”、“B更好”、“平手”的判断。这种方法更能捕捉细微差别。实现示例使用OpenAI API进行对比评估import openai def llm_judge_comparison(query, response_v1, response_v2): prompt f 你是一个公正的评估员。请比较以下两个AI助手对同一个问题的回答。 问题{query} 回答A{response_v1} 回答B{response_v2} 请根据回答的有用性、相关性、准确性和完整性进行评估。 输出格式必须严格为[[选择]]其中选择只能是 A、B 或 Tie。 response openai.ChatCompletion.create( modelgpt-4-turbo, messages[{role: user, content: prompt}], temperature0 ) result response.choices[0].message.content.strip() # 解析结果例如提取 [[A]] 中的 A return parse_result(result)6.2 人工评估不可替代的最终防线自动化评估无法完全理解语言的微妙之处、创造力和复杂的逻辑。因此必须对Canary流量进行采样进行人工评估。采样策略不是随机采样。应该优先采样自动化评估中得分差异大v1和v2分数悬殊的样本。涉及高风险领域医疗、法律、金融的样本。用户反馈如有负面的样本。评估平台建立一个内部平台将采样的“问题-v1回答-v2回答”三元组匿名地呈现给评估员可以是算法团队成员、产品经理或众包标注员。评估员在不知情哪个是v1/v2的情况下双盲根据既定标准进行评分或选择偏好。评估标准制定清晰、可操作的评估标准卡Rubric。例如有用性回答是否解决了用户的问题相关性回答是否紧扣问题没有跑题准确性陈述的事实是否准确安全性/无害性回答是否避免了偏见、歧视和有害内容流畅性语言是否自然通顺6.3 数据驱动的发布决策最终是否扩大灰度比例或全量发布需要综合所有评估数据形成一个数据仪表盘来辅助决策评估维度指标v1 基线v2 Canary状态绿/黄/红决策权重性能P99延迟 (ms)12501350⚠️ (黄)高性能错误率 (%)0.050.03✅ (绿)高成本平均Token消耗/请求450420✅ (绿)中自动化质量LLM裁判胜率 (%)50 (基线)65✅ (绿)高人工评估偏好率 (%)4060✅ (绿)高业务用户满意度如有4.24.5✅ (绿)高决策规则可以设定一些硬性规则例如必须全部为绿所有高权重的核心维度如错误率、严重安全问题必须为绿。允许少量黄灯非核心维度如次要性能指标可以有少量黄灯但需要人工评审原因。一票否决任何维度出现红灯如检测到新增的安全漏洞立即停止发布并启动回滚。7. 实战案例一个中型AI问答应用的Canary发布全流程假设我们有一个AI问答产品“智答”当前使用模型gpt-3.5-turbov1计划升级到gpt-4-turbov2。以下是我们的操作剧本。7.1 发布前准备阶段环境与配置确保v2模型服务指向GPT-4 Turbo的端点已独立部署并完成基础的压力测试。在API网关我们使用Kong中配置好两个上游Upstreamllm-v1和llm-v2。编写并启用一个Kong插件该插件根据配置中心Consul下发的canary_ratio值对请求头X-User-ID进行哈希计算并将X-Model-Version: v1或v2注入请求头。默认比例0%全量v1。在“智答”后端服务中修改LLM客户端调用逻辑使其读取X-Model-Version请求头并动态选择对应的API密钥和模型参数。配置日志系统Fluentd - Elasticsearch确保X-Model-Version和X-Request-ID被记录在每条访问日志和模型调用日志中。在Grafana中创建两个并排的仪表盘分别过滤model_versionv1和model_versionv2的指标延迟、错误率、Token数。评估基准建立从近期线上日志中采样1000个典型的用户问题构成一个测试集。用v1模型离线跑一遍测试集将输入输出对(Q, A_v1)存储下来作为基准答案。设计自动化评估脚本使用GPT-4作为裁判对后续v2的输出进行对比评估。7.2 分阶段发布与监控Day 1-2内部员工100%灰度操作在配置中心将canary_ratio设置为一个特殊值并配置规则所有来自内部邮箱域ourcompany.com的请求强制染色为v2。监控重点功能是否正常收集内部员工的直接反馈。性能指标是否有异常波动自动化评估脚本对内部流量的评估结果如何发现问题内部员工反馈新模型对某些技术术语的解释“过于啰嗦”。我们评估后认为这在可接受范围内但决定在正式对外发布前对Prompt进行微调增加“回答请简洁”的指令。Day 31%线上流量灰度操作修改配置将canary_ratio设置为0.011%。所有流量根据UserID哈希有1%的概率被染色为v2。监控重点错误率仪表盘紧盯v2通道的5xx错误和超时。设置告警规则错误率0.5%持续5分钟则告警。延迟对比仪表盘观察v2的P95延迟是否在预期内我们知道GPT-4会慢一些。成本仪表盘观察v2通道的日均Token消耗估算全量后的成本增长。自动化评估脚本开始对1%的采样流量进行实时评估计算v2对比v1的“胜率”。我们设定目标胜率需稳定高于55%。运行结果24小时后v2错误率0.02%P95延迟比v1高40%符合预期成本高30%自动化胜率达到58%。指标全绿。Day 45%线上流量灰度操作将canary_ratio提升至0.05。监控重点同上并开始关注更细粒度的业务指标由于流量增大数据更可靠。同时从v2流量中随机采样1%的请求推送至内部人工评估平台。运行结果各项指标保持稳定。人工评估了50个样本偏好v2的占62%偏好v1的占25%其余打平。收到2条用户反馈邮件1条表扬回答更详细1条抱怨回答速度变慢恰好命中Canary用户。我们记录下速度反馈但认为在整体可控范围内。Day 5-7逐步放量至20%50%操作每24小时将比例翻倍5% - 10% - 20% - 50%。每次调整后观察一个完整的业务日24小时。监控重点持续关注所有核心指标。特别关注当流量增大后v2服务端是否有资源瓶颈如GPU内存、API速率限制。我们根据监控提前对v2服务进行了小幅扩容。运行结果一切平稳。在50%比例时我们进行了一次A/B测试数据分析发现使用v2模型的用户其“追问率”提出后续问题的比例略有下降而“会话满意评分”如果有略有上升。这或许意味着v2的回答更一次性解决了用户问题。7.3 全量发布与回滚演练Day 8全量发布操作将canary_ratio设置为1.0100%。此时所有新请求默认流向v2。但我们保留v1服务在线且路由规则随时可改。发布后观察全量后持续观察48小时重点关注长尾效应和不同用户群体的反馈。确认无异常后本次Canary发布正式成功。Day 9回滚演练操作在凌晨低峰期模拟一个“严重问题”如在监控上手动触发一个v2通道的高错误率告警。团队接到告警后按照预案登录控制台点击“一键回滚”按钮。验证按钮点击后系统自动将配置中心的canary_ratio改为0并刷新网关配置。通过监控确认30秒内所有流量指标全部切回v1通道v2通道流量降为0。演练成功。复盘记录演练耗时并更新应急预案文档。8. 常见问题与排查技巧实录在实践中你会遇到各种各样稀奇古怪的问题。下面是我和团队踩过的一些坑以及我们的排查思路。8.1 流量染色丢失导致监控失真问题现象监控仪表盘上v2的请求量远低于预期但错误日志里却出现了带有v2特征的问题。排查思路检查网关日志查看网关的访问日志确认请求是否被打上了X-Model-Version: v2的头。检查应用服务日志在应用服务中打印接收到的所有请求头确认染色头是否成功传递进来。检查内部调用链如果应用服务内部还调用了其他服务如用户服务、风控服务检查在这些内部HTTP调用中染色头是否被丢失。常见原因是使用了默认的HTTP客户端没有设置头传递。解决方案建立公司级的HTTP客户端标准库或中间件确保关键透传头Trace-ID, Span-ID, 染色头在所有的服务间调用中自动传递。8.2 新模型性能不符合预期但原因不明问题现象v2模型的延迟P99异常高但GPU利用率看起来并不高。排查思路细分延迟不要只看整体延迟。拆解延迟构成网络延迟、模型加载/预热时间、Token生成时间Time to First Token, TTFT 和 Time per Output Token, TPOT。对比请求样本从v1和v2日志中各取一批慢请求对比它们的输入特征。是不是v2流量中恰好包含了一批特别长或特别复杂的Prompt检查配置确认v2模型的推理参数如max_tokens,temperature是否和v1一致。有时为了追求质量可能会无意中调大了max_tokens导致生成时间变长。检查基础设施v2模型是否部署在和v1不同的硬件或区域网络链路是否一致解决方案我们曾遇到因为v2模型默认的max_tokens是4096而v1是2048导致生成长回答的请求耗时翻倍。统一配置后问题解决。8.3 自动化评估结果与人工评估严重不符问题现象LLM裁判GPT-4认为v2的回答远优于v1但人工评估员却普遍偏好v1。排查思路检查评估指令Prompt给裁判LLM的评估指令是否清晰、无歧义是否与人工评估员遵循的准则一致可能存在指令偏见。分析差异样本找出那些裁判和人工判断差异最大的案例进行人工复核。是不是裁判模型过度看重了“内容丰富度”而人工更看重“简洁性”和“直接性”裁判模型本身是否有问题尝试用另一个裁判模型如Claude对差异样本重新评估看结果是否一致。解决方案我们发现我们的裁判Prompt中写道“评估回答的完整性和信息量”这导致GPT-4倾向于给更长、更详细的回答打高分。而我们产品的调性需要简洁直接的回答。我们修改了Prompt加入了“在保证准确的前提下简洁性也是一个重要维度”的说明使自动化评估与人工标准对齐。8.4 回滚后部分用户会话出现混乱问题现象在回滚发生后有用户反馈“机器人突然失忆了”不记得之前对话的内容。排查思路确认会话状态存储用户的对话历史上下文存储在哪里是存储在客户端如前端还是会话状态服务器或是每次都由后端携带分析回滚时间点该用户的对话是否恰好横跨了回滚操作发生的时间点回滚前几轮用的是v2回滚后用的是v1。检查上下文传递v1模型是否能正确处理v2模型之前生成的对话历史格式可能存在微妙的格式不兼容。解决方案我们采取了“牺牲一致性”的策略。在回滚发生时向后端服务和客户端发送一个全局事件。后端服务在收到回滚后一段时间内的请求时会在响应中携带一个轻量级标记。客户端检测到这个标记后可以温和地提示用户“会话已刷新”并清空本地的历史记录开始全新的对话。虽然体验有折损但保证了服务的简单和健壮。实施LLM应用的Canary发布初期会感觉增加了不少复杂性和工作量。但当你经历过一次因为有了它而避免的线上事故后你就会明白这份“复杂”是值得的。它带来的是一种对生产环境变更的“掌控感”。从手动、胆战心惊的发布到自动化、数据驱动的渐进式交付这是工程团队走向成熟的重要标志。