LLMOps 平台

• SaaS vs 自托管对比
• 数据主权与合规
• 运维与成本权衡

选型权衡四方面：1) 数据主权：SaaS 数据在第三方，敏感数据/PII/合规要求高时自托管更安全（数据不出域）；2) 运维：SaaS 免运维、快速上线，自托管需自建部署、升级、监控、备份，运维成本高；3) 扩展：SaaS 弹性扩展、按需付费，自托管需自备资源、扩展受限于自建集群；4) 成本：SaaS 按用量付费、初期成本低但长期可能高，自托管初期投入大（硬件/人力）但长期边际成本可控。选型：强合规/数据主权要求 → 自托管；快速迭代、运维力弱、初期成本敏感 → SaaS。可混合：敏感数据自托管、通用场景 SaaS。

SaaS 与自托管是"数据主权 vs 运维成本"的权衡。合规强、长期量大选自托管；快速启动、运维弱选 SaaS，可混合部署。

• 双漂移监控
• 分数下降归因
• 评估器 vs 应用

双漂移：应用质量退化（模型/Prompt 变差）与评估器过期（Judge 升级/漂移、评估集过时）都会造成分数下降，需区分。监控：1) 对评估器本身做"自监控"——用固定 golden 样本定期跑，确认 Judge 分数稳定（评估器未过期）；2) 对应用做"样本监控"——固定样本集上应用分数变化反映应用退化。区分方法：若"固定样本的评估器自检分数稳定"但"应用分数下降"，说明是应用退化；若"评估器自检分数也漂移"，说明评估器过期/变化，需校准评估器。用"固定输入 + 固定评估器"作为对照，隔离"应用变化"与"评估器变化"。

分数下降的根因可能是应用或评估器。用"固定样本自检评估器稳定性"作对照，能隔离两个变量，定位是应用退化还是评估器过期。

• Prompt 变更管理
• code review 与审计
• 环境污染隔离

Prompt 资产按"代码"管理：1) 版本控制：Prompt 存 Git，变更走分支 + PR；2) code review：变更需评审人 approve，评审的不仅是 diff 文本，还有"关联的评估结果"（变更前后指标对比），确保变更有效；3) 变更审计：记录变更 diff、审批人、时间、关联评估结果，形成可审计的变更日志；4) 环境隔离：开发/灰度/生产 Prompt 分离，生产 Prompt 只能通过受控发布流程修改，禁止线上直接改；5) 权限控制：生产 Prompt 修改权限最小化，评审与审批分离。防止线上无评审修改：用不可变版本 + 权限 + 审批 + 审计日志强制流程。

Prompt 是"代码"，需版本控制、评审、审计、环境隔离、权限。防止线上无评审修改的关键是"不可变版本 + 审批流程 + 审计日志"。

• 数据进入前治理
• 脱敏/采样/保留期
• RBAC

数据进入 LLMOps 前治理：1) 字段级脱敏：对敏感字段（PII、密钥、账号、内部信息）做脱敏（替换/哈希/掩码），只保留调试所需字段；2) 采样：按比例/策略采样进入平台，控制存储量与成本，同时对高风险事件全量采样；3) 保留期：设定数据保留 TTL，过期自动删除，符合合规与隐私；4) RBAC：按角色控制访问权限（谁可看原始数据、谁可看脱敏数据、谁可导出），最小权限原则。进入平台前先"脱敏 + 采样 + 定保留期 + 定权限"，保证数据安全与合规。

数据进平台前就要治理，而非事后补救。字段级脱敏保隐私、采样控成本、保留期合合规、RBAC 控权限，四者构成数据治理入口。

• 异步评估
• 采样策略
• 高风险必评

在线评估若同步做会加延迟、占资源，改用异步：1) 在线请求返回后，把响应/评估任务异步投递到队列，后台评估，不阻塞用户；2) 采样策略：低风险/常规样本低比例采样评估，控制成本；3) 高风险必评：对高风险事件（安全敏感、注入、大额操作、用户负反馈、任务失败）全量评估，不采样，保证必评；4) 分级路由：把样本按风险分级，高风险全量、中风险抽样、低风险跳过或低比例。这样既控制延迟与成本，又保证高风险不遗漏。

在线评估用"异步队列 + 分级采样"解决延迟与成本。核心是"低风险采样、高风险必评"，把评估预算花在风险最高的地方。

• 多租户隔离
• 权限控制
• 数据共享平衡

多团队共用平台：1) 项目隔离：按团队/项目分租户/命名空间，数据、Prompt、评估集、配置相互隔离，防串扰；2) 权限控制：RBAC 按角色/项目授权，跨项目访问需显式授权；3) 数据共享平衡：设"共享层"——通用的评估集、Prompt 模板、模型配置、最佳实践可共享给所有团队，但各自项目数据隔离；建立"共享 API/模板库"让团队复用，同时对敏感数据设访问边界。平衡原则：基础设施与公共资产共享，项目私有数据隔离，权限最小化。

多团队平台要"隔离 + 共享"并举：项目私有数据隔离，公共资产（模板、评估集、最佳实践）共享，用 RBAC 控制边界。避免"一刀切隔离"或"完全开放"。

• 自动评分验证
• 防黑盒单点
• 人工校准流程

平台自动评分可能是"黑盒"（内部 Judge 不可见、逻辑不透明），不能当成唯一真相。验证与校准：1) 抽样人工复核：定期人工抽样评审平台评分，对比一致性，验证评分是否可信；2) 自有 golden 校准：用自有人工标注样本验证平台评分，校准阈值；3) 多信号交叉：平台评分与人工、业务指标、自有 Judge 交叉验证，不依赖单一来源；4) 透明性要求：要求平台暴露评估逻辑、Judge 模型、可导出评分明细，审查其合理性；5) 保留人工仲裁流程：对高风险/争议样本人工复核仲裁，人工有最终决定权。平台评分是"辅助代理"，人工校准是"真值兜底"。

自动评分"黑盒"不可全信。抽样复核、自有 golden 校准、多信号交叉、透明性要求、人工仲裁兜底，防止把平台黑盒当唯一真相。

• 环境隔离
• 权限控制
• 防误推生产

防止开发 Prompt 误推生产：1) 环境隔离：开发/测试/预发/生产 Prompt 彻底分离，各环境独立存储与配置，变更按环境流转；2) 发布流程：变更经"dev → 测试 → 预发 → 生产"的受控流程，每步验证通过才推进；3) 权限控制：生产环境的修改/发布权限最小化，仅允许授权人员操作，评审与发布分离；4) 门禁校验：发布前校验 Prompt 版本、环境标签、变更记录，防止"开发版本直接覆盖生产"；5) 审计：记录每次生产变更的来源与审批，异常发布可追溯。用"环境隔离 + 流程门禁 + 权限 + 审计"四条防线。

防误推生产靠"环境隔离（物理分离）+ 受控发布流程 + 权限最小化 + 环境标签校验"。核心是让生产变更只能走受控通道，而非直改。

• 平台演进风险
• 记录核查日期
• 退出方案

平台（SaaS/开源）迭代快，能力与价格会变，采购与架构记录要"防过期"：1) 标注核查日期：所有选型、能力、价格、SLA 记录注明"核查日期"，定期重验，防止基于过时信息决策；2) 记录版本与快照：记录平台版本、特性说明、评测数据，作为当时决策依据；3) 退出方案（exit plan）：评估"数据可导出、接口可迁移、替代方案"，提前规划迁移路径，避免被平台锁定；4) 定期复审：纳入评审周期，重验平台是否仍满足需求与成本。这样平台演进时，决策可被重新验证，且有退出路径。

平台变化快，记录必须"标注核查日期 + 定期重验 + 预留退出方案"，防止基于过时信息决策与被平台锁定。

• 告警风暴成因
• 告警降噪策略
• 告警管理

告警风暴（大量噪声告警淹没真实问题）的降噪策略：1) 阈值合理：用基线 + 动态阈值，避免固定阈值误报；2) 分级告警：按严重度分级（P0-P3），只对关键问题告警，噪声/低优先级降级；3) 聚合与去重：相似告警聚合（按服务/指标/来源），避免同一事件重复告警；4) 抑制与去抖：告警需持续超过阈值一段时间才触发（去抖），避免瞬时抖动；5) 关联分析：把相关告警关联为同一根因，避免"一因多告警"；6) 告警疲劳管理：设置告警上限、静默窗口、告警路由到正确负责人。目标：告警"少而准"，聚焦真实故障。

告警风暴源于阈值不严、未去重、未分级、瞬时抖动。合理阈值、分级、聚合去重、去抖、关联 + 告警疲劳管理，让告警少而准。

• 导出 API 重要性
• 覆盖度评估
• 数据主权与集成

导出 API 是"数据主权与集成"的命脉：若平台不能导出 trace、评估、Prompt、用户数据，数据被锁定，无法迁移、无法自建分析、无法满足合规。因此采购核心评估：1) 稳定性：导出 API 是否稳定、版本化、有 SLA，防接口破坏；2) 覆盖度：哪些字段可导出——trace（含 span、token、延迟）、评估分数、Prompt 版本、用户反馈、成本数据、元数据；3) 完整性：能否导出原始与脱敏数据、是否支持批量/增量导出；4) 可迁移性：能否导出后导入其他平台。覆盖度不足的平台会成"数据黑洞"，需在采购前验证。

导出能力决定"数据主权与是否被锁定"。评估导出 API 的稳定性与字段覆盖度，是采购防止数据锁定的核心。

• 平台 SLA 构成
• 可用性/数据保留/查询性能
• 平台可靠性评估

LLMOps 平台 SLA 应明确：1) 可用性：平台可用性（uptime 百分比）、评估/查询服务可用性、故障恢复目标（RTO/RPO）；2) 数据保留：数据保留期限、备份策略、删除可执行性、数据可导出性；3) 查询性能：查询/评估响应时间（P95）、并发能力、超时；4) 其他：支持响应时间、安全与合规承诺。评估方法：核对 SLA 文档、做性能压测、验证数据保留与删除、进行故障演练。平台 SLA 影响评估流程的稳定性与数据安全，需纳入采购评估。

平台 SLA 决定"评估流程是否可靠、数据是否安全、性能是否达标"。可用性、数据保留、查询性能是核心，需核对并验证。

• 可观测字段选择
• 隐私与成本
• 正文记录策略

应记录的结构化字段：1) 延迟：TTFT、TPOT、总耗时、各阶段耗时；2) Token：input/output tokens、cache_read/write、总用量；3) 完成原因：stop_reason、finish_reason；4) 检索分数：检索相关度分数、命中数、top-k 分布；5) 工具结果：工具名、是否成功、参数（脱敏）、返回状态；6) 错误类别：错误类型（超时、限流、无效请求、工具失败）、错误码。正文默认不记录：完整对话正文、Prompt 全部内容、敏感正文（PII、密钥）默认不记录或做摘要/脱敏——因为正文存储成本高、隐私风险大。原则：记录"结构化、低基数、调试必要"字段，正文按需脱敏采样。

可观测性记录"结构化指标 + 脱敏正文"。正文（完整对话）成本高、隐私风险大，默认不记录，只记结构化字段与脱敏摘要。

• 延迟分解
• 瓶颈定位
• 各阶段延迟

延迟分解：TTFT（首 token 时间）= 网络耗时 + 排队耗时 + 模型首 token 生成耗时；TPOT（每 token 间隔）= 模型生成每 token 耗时 + 网络传输；总耗时 = TTFT + N×TPOT + 工具/检索等其他耗时。识别瓶颈：1) 网络慢：请求发往 Provider 到响应到达的传输耗时大（测分布式/跨区域节点）；2) 排队慢：Provider 侧排队（429/排队指标、请求积压），表现为 Provider 处理前等待长；3) 模型慢：模型生成吞吐低（TPOT 大、首 token 慢），与模型规格/推理负载相关。用分段计时（client 侧、网关、Provider 侧）分解各阶段耗时，定位是网络、排队还是模型。

延迟瓶颈要"分段归因"。TTFT/TPOT/总耗时分解后，再按网络、排队、模型三层定位，才能针对性优化（选近端点、调并发、换模型）。

• 反馈关联 trace
• 标签低基数
• 敏感数据规避

把用户反馈/任务结果关联到 trace：用 trace ID 作为关联键，反馈记录（点赞、点踩、编辑、解决）与 trace 绑定，用聚合指标（如"反馈维度"）在 trace 上打标。避免高基数敏感数据：1) 标签（label/attribute）只能用低基数、非敏感值（如 is_positive、feedback_type、task_result），不用"用户 ID、完整文本"等高基数/敏感字段做标签；2) 高基数/敏感数据放"外部关联表"（通过 trace ID 关联），而不直接写进 trace 布点；3) 标签做聚合/脱敏（如用户分桶为"新/老用户"）。这样既关联反馈又不污染 trace 的基数与隐私。

反馈用 trace ID 关联，聚合指标作标签。高基数/敏感数据（用户 ID、正文）放外部关联表，避免拖垮 trace 与泄露隐私。

• TTFT 测量定义
• SSE 心跳 vs 内容
• 精确测量方法

TTFT 应精确测量为"从请求发出到首个"内容"delta"的时间，而非"首个 SSE event"——因为 Provider 可能先发送心跳/保持连接（keep-alive）或空事件，首个 SSE event 不代表首个内容 token。正确测量：1) 记录请求发出时间；2) 记录流式响应中第一个"非心跳、非空、含实际内容 delta"的事件到达时间；3) TTFT = 该时间 - 请求发出时间。排除心跳/空事件，避免高估"首内容"时延。实现上客户端要能区分"心跳/连接事件"与"内容事件"。

TTFT 的精确性取决于"首个内容事件"而非"首个事件"。心跳/keep-alive 会误导测量，必须排除，只计算首个非心跳 delta 的到达时间。

• 调试字段选择
• 可追溯性
• 隐私平衡

调试必要字段：1) 标识：trace ID、request ID、session ID——用于关联整条链路；2) 模型信息：model 版本、用量（tokens）、温度/参数（params）——用于复现与归因；3) 时间：请求/响应时间、延迟；4) 结果：完成原因、错误码、工具调用摘要；5) 上下文：脱敏后的检索片段、Prompt 摘要（非全文）。选择原则：保留"能复现 + 能归因 + 能关联"的低基数结构化字段，正文/敏感内容脱敏或摘要。日志字段要"够用不越界"，既能调试又保隐私。

调试日志字段既要"可复现、可归因、可关联"，又要"低基数、脱敏"。trace ID、model、params、时间、结果、摘要字段足够，正文不必要全量。

• 用户画像区分
• 低基数标签
• PII 规避

区分用户画像但不暴露 PII：1) 用"低基数画像标签"（tier: free/paid/enterprise、segment）而非"用户 ID"来区分——画像标签是低基数、非敏感；2) 用户 ID/邮箱等 PII 放"外部关联表"，通过匿名 ID 关联，不直接进 trace 标签；3) 聚合：把用户归入画像桶（免费/付费/企业/地域），在 trace 上只打桶标签；4) 权限：原始用户级数据受限访问，画像级聚合数据可共享分析。这样既能在可观测性数据中区分用户画像（用于分析体验差异），又不暴露个体 PII。

用"画像桶标签"替代"用户 ID"区分用户，既保留分析维度又不暴露 PII。PII 走外部关联表，聚合数据共享分析。

• 错误率细分
• 全局指标局限
• 维度归因

错误率须按维度细分：1) 按 Provider：某 Provider 故障/限流导致错误率高，其他正常；2) 按模型：某模型规格错误率高；3) 按租户：某大租户/特殊租户集中报错；4) 按错误类型：超时、限流、无效请求、工具失败各自占比。单一全局错误率会"掩盖"问题：某 Provider 错误率 30% 但只占 1% 流量，全局错误率可能只显示 1%，看起来正常，实际特定 Provider 已严重故障。细分后能定位"哪个维度、哪种错误"异常，及时处理。全局指标只看"整体健康"，细分指标看"局部异常"。

全局错误率会被"低流量高错误率的维度"稀释，掩盖局部故障。按 Provider/模型/租户/错误类型细分，才能发现并定位局部异常。

• 日志隐私风险
• 加密的局限
• 最小化原则

即使日志平台加密，密钥/个人数据/内部思考也不应进日志，原因：1) 加密是"存储层面"保护，访问权限、日志导出、备份、第三方、系统内部人员仍可能触达，加密不等于可控；2) 日志可能被复制、转发、进入其他系统（如监控、备份、分析工具），泄露面扩大；3) 密钥/敏感数据一旦进日志，就失去"最小化"原则，合规风险（数据保留、删除、泄露）增大；4) 内部思考（CoT/推理）可能含敏感决策或越权信息，不应记录。原则：日志在源头就不应包含敏感数据（少记、脱敏、不记），而非依赖加密兜底。加密是最后防线，不是允许记录的理由。

加密解决"存储安全"，不解决"访问、复制、转发、合规"风险。密钥/个人数据/内部思考必须"源头不记"，而非依赖加密后记录。

• GenAI 语义约定
• 标准化工程意义
• span/token/tool 追踪

OpenTelemetry GenAI Semantic Conventions 定义 LLM 可观测性的标准语义：1) LLM span attributes：标准化的 span 属性（model、provider、prompt、temperature、usage 等）统一命名，不同框架/工具按同一语义打点；2) token 用量：标准化的 input/output tokens、cache 用量字段，跨 Provider 可比；3) tool 调用追踪：标准化的 tool 调用 span 与事件，记录工具名、参数、结果，关联 Agent 链路。工程意义：1) 跨工具/框架可移植（不绑定某厂商）；2) 数据可互操作（不同系统能读同一语义）；3) 降低平台锁定；4) 构建统一的可观测性体系。标准化让 LLM 可观测从"各自为政"走向"统一语义"。

GenAI Semantic Conventions 是"LLM 可观测的通用语言"，统一 span 属性、token、tool 调用语义，实现跨工具可移植与互操作，降低锁定。

• 会话级聚合
• 任务漏斗
• 关联键设计

会话级聚合：把单个会话的多轮 trace 聚合为"会话级"分析，构建任务完成漏斗：发起（会话开始）→ 澄清（触发澄清）→ 工具成功（工具调用成功）→ 解决（任务完成）。每层统计流失率，定位"哪一环节用户流失"。跨 trace 关联键设计：用会话 ID（session ID）+ 用户标识（匿名 ID）作为关联键，把同一会话的多轮 trace 串起来；用轮次/时间戳排序；用任务 ID 关联任务级事件。关联键要"低基数、稳定、非敏感"，避免用高基数或含 PII 的字段。漏斗分析让单条 trace 的"点"变成会话的"流"。

单条 trace 是"点"，会话漏斗是"流"。用会话 ID + 匿名用户 + 轮次关联多轮 trace，构建任务完成漏斗，定位流失环节。

• 持续剖析
• CPU/内存瓶颈定位
• 与传统 APM 区别

OTel Profile（持续剖析）通过持续采样进程堆栈/CPU/内存，定位 AI 服务的性能瓶颈：1) CPU 瓶颈：分析火焰图/CPU 采样，定位热点函数（如重计算、解析、序列化、向量检索）；2) 内存瓶颈：分析内存分配/GC，定位内存泄漏、大对象、缓存膨胀。与传统 APM 区别：APM 关注"请求级指标"（延迟、错误率、吞吐），告诉你"哪里慢"（哪个服务/接口）；持续剖析关注"函数级/代码级"（CPU/内存/堆栈），告诉你"为什么慢"（哪个函数吃 CPU、哪里泄漏内存）。两者互补：APM 定位服务、Profile 定位代码，AI 服务（向量检索、推理调度）需 Profile 深入定位。

APM 看"请求级"（哪里慢），Profile 看"代码级"（为什么慢）。AI 服务的 CPU/内存瓶颈（热点、泄漏）需持续剖析定位，与 APM 互补。

• 主动离开 vs 系统放弃
• 漏斗失真
• 流失区分

区分"用户主动离开"（完成任务、自然离开）与"系统导致放弃"（AI 答错、卡住、超时、无法完成导致用户放弃）：1) 用终态标记：会话是否达成目标（任务完成）、是否触发解决/谢谢；2) 用行为信号：放弃前是否有"重试、抱怨、转人工"（系统问题）vs"离开即完成"（自然离开）；3) 用系统事件：是否发生超时/错误/工具失败（系统导致）；4) 用延迟/质量信号：卡在等待、低质量回答后离开判为系统导致。防止漏斗被自然流失扭曲：把"自然完成"与"系统放弃"分开统计，只把"系统导致放弃"作为漏斗优化目标，避免把"用户本来就该走"误判为流失。用分类/规则给离开事件打标。

漏斗流失需区分"自然离开"与"系统放弃"。打标（终态、行为、系统事件）区分，只优化"系统导致放弃"，防止漏斗被自然流失扭曲。

• 评估闭环
• 版本可追溯
• 数据链路

建立"数据 → 实验 → 追踪 → 反馈 → 回归"闭环：1) Dataset：评估/训练数据集版本化；2) Experiment：在 dataset 上跑实验（模型/Prompt 变更），记录实验配置与结果；3) Trace：线上运行产生 trace，关联到实验/版本；4) Feedback：线上反馈（用户、业务）关联到 trace；5) Regression：badcase 回流到 dataset，形成新回归用例。保持版本可追溯：每个环节绑定版本（dataset commit、experiment id、trace id、feedback id、regression 版本），用统一 ID 关联，形成可追溯链路。这样"评估→上线→反馈→再评估"闭环且每一步可追溯归因。

闭环让"离线评估、线上运行、用户反馈、回归集"互相打流通，版本可追溯让每一步可归因。核心是统一 ID + 版本绑定。

• 降低平台锁定
• 标准 vs 自定义
• 语义边界

OpenTelemetry 提供通用可观测性标准（trace/metric/log），OpenInference 在其上定义 GenAI 语义（LLM、检索、Agent span），两者让数据用"标准语义"记录，可被任何支持该标准的工具读取，从而降低平台锁定（不绑定某厂商的私有格式）。降低锁定的机制：数据可导出、语义标准、与采集器/后端解耦。仍需应用自定义的语义：业务特有动作（领域特定的工具、业务事件）、自定义指标（业务成功率、业务维度标签）、私有字段（脱敏的租户信息）——这些不在标准内，需应用自定义 span attributes/业务指标，但用标准"前缀"命名避免冲突。标准覆盖通用，业务特有需自定义。

标准语义（OTel/OpenInference）让数据可移植降锁定，但业务特有语义仍需自定义。标准为基座、自定义补充业务，是合理架构。

• Prompt 版本管理内容
• 版本化与回滚
• 变更治理

Prompt 版本管理管理：Prompt 文本、版本、环境（dev/prod）、关联模型、参数、评估结果、变更记录。实现版本化：1) Prompt 存版本库（Git/平台），每次变更生成新版本（version id/hash）；2) 版本绑定环境（开发/灰度/生产）与模型，可追溯"哪个 Prompt 版本在哪个环境用哪个模型"；3) 支持回滚：记录 golden 版本，异常时可回滚到上一稳定版本；4) 变更审计：记录变更 diff、审批人、关联评估结果；5) 灰度发布：新版本 Prompt 可灰度，验证后再全量。Prompt 版本管理让"Prompt 变更"像"代码变更"一样可控、可测、可回滚。

Prompt 版本管理是"把 Prompt 当代码管理"：版本化、环境绑定、回滚、审计、灰度。保证 Prompt 变更安全可控、可追溯。

• 平台集成成熟度
• 标准支持程度
• 评估方法

LLMOps 平台与 OTel/OpenInference 集成成熟度差异大：有的平台原生支持 OpenInference 语义（可直接消费标准 trace），有的只支持私有格式、需适配器，有的支持部分（如只支持 trace 不支持 metric）。评估方法：1) 核对官方文档：查看平台是否声明支持 OTel/OpenInference、支持哪些 span 语义与维度；2) 验证导出：能否导出标准格式 trace、能否被标准后端读取；3) 测试互操作：把平台数据导入标准采集器，看能否完整还原；4) 关注版本：标准与平台都在演进，按当前最新状态评估，标注核查日期。评估目标是"平台集成越标准，越易迁移、锁定越低"。

平台集成成熟度决定"数据是否可移植、是否易迁移"。按官方最新文档核对标准支持、导出与互操作，评估集成成熟度。

• 过度平台化的代价
• 环境区分
• 治理成本

把所有 Prompt 都放进平台并非总是好：平台化带来"流程成本、权限管理、评估开销、平台依赖"，对高频试错、未成熟的开发态 Prompt 过度平台化会拖慢迭代。应区分环境：1) 开发态：本地/快速试错，用轻量方式（代码/本地文件），不强制进平台，快速迭代；2) 灰度态：进入平台做版本管理、评估、灰度，验证质量；3) 生产态：受控发布，平台管理、权限、审计、回滚、监控。只有"进入生产/需要治理"的 Prompt 才严格平台化，开发期保持轻量。分级管理避免"过度治理"。

平台化是"治理成本"，不是越全越好。开发态轻量快速、灰度态验证、生产态受控，分级管理让成本与需要的治理匹配。

• Trace ID 传播
• 跨节点串联
• 分布式链路

串联 Trace ID：1) 入口生成：前端/网关在请求入口生成 trace ID（W3C TraceContext），注入请求头；2) 跨服务传播：Java 服务、Agent 节点、检索、工具调用都通过 OTel SDK 自动/手动传播 trace context（traceparent header），保证同一 trace ID 贯穿所有节点；3) 异步传播：异步任务/队列需显式传递 trace context（用 context 传播）；4) 外部调用：模型 Provider、检索、工具调用在其 span 中记录同一 trace ID（作为子 span）；5) 汇聚：所有 span 按 trace ID 汇聚成完整链路，前端→服务→模型→检索→工具→Agent 全链路可查。用统一的 trace context 传播机制（OTel 自动注入 + 手动传播）保证跨节点一致。

Trace ID 串联靠"统一 trace context 在入口生成、跨节点传播、外部调用承载"。前端、Java 服务、Agent、工具都共享同一 trace ID，才能汇聚成完整链路。

• 端到端 trace 节点
• 关键 span 设计
• 全链路追踪

端到端 trace 应包含关键节点 span：1) 前端意图：用户输入/意图识别；2) 后端路由：路由决定用哪个模型/Agent/流程；3) 检索：检索系统（query、embedding、hit、分数）；4) Prompt 组装：最终 Prompt 的组装（含模板、上下文、工具说明）；5) 模型：LLM 调用（model、params、token、TTFT）；6) 工具调用：工具执行（工具名、参数、结果、耗时）；7) 生成：最终输出生成。每个节点用 span 记录输入输出摘要、耗时、关键指标，按时间串联成完整链路。这样一次请求的"从意图到生成"全流程可观测、可归因。

端到端 trace 覆盖"意图→路由→检索→组装→模型→工具→生成"关键节点，每个 span 记录摘要与指标，才能完整还原请求并定位瓶颈。

• 响应式传播
• Trace 上下文传播
• Baggage 传递

正确传播：1) Java 服务（同步）：OTel Java SDK 自动处理 HTTP 场景的 traceparent 注入/提取；2) WebFlux（响应式）：响应式/异步链路需用 OTel 的 Reactor instrument 或手动把 context 绑定到当前线程/订阅链路，避免异步切换导致 context 丢失（用 Reactor Context、context propagation）；3) Agent 节点：Agent 多步调用需在同一步内传播 trace context，并用 Baggage 传递业务上下文（如租户 ID、实验分组、session）——Baggage 是 W3C 标准，随请求跨服务传播，不随 trace 自动继承需显式设置/读取；4) 统一用 OTel Context Propagation（W3C TraceContext + Baggage）机制，同步用 thread-local，异步用 context propagation 库。核心是"异步/响应式场景显式传播 context"。

Java 同步靠 SDK 自动注入，WebFlux 响应式需显式 context 传播（防切换丢失），Agent 用 Baggage 传业务上下文。关键是异步链路显式传播。

• GenAI 语义指标
• 低基数指标记录
• 指标与 span 结合

用 OTel GenAI Semantic Conventions 记录：1) Token 用量：作为 span attribute（gen_ai.usage.input_tokens/output_tokens）及 metric（counter）；2) TTFT/TPOT：作为 span attribute（耗时）或 metric（histogram），记录模型调用 span 的首 token 与每 token 时间；3) cache hit：作为 span attribute（gen_ai.usage.cache_read_tokens）与 metric（counter/ratio），记录缓存命中。低基数指标：用 metric（counter、histogram、gauge）聚合，加低基数标签（model、provider、tier），避免高基数（用户 ID）。把"质量/性能指标"与"trace"结合：span 记录单次明细，metric 聚合统计，实现"单次可查、整体可监控"。

GenAI 语义约定给出 token/TTFT/TPOT/cache 的标准字段与 metric。用 span attribute 记明细、metric 聚合统计，低基数标签控维度，实现可观测。

• 各标准协作
• 跨服务关联
• 术语体系

协作分层：1) W3C TraceContext：定义 trace ID、span ID、采样标志 的传输格式（traceparent header），保证跨服务/跨厂商的 trace 关联；2) Baggage：定义跨服务传递业务上下文（key-value，如租户、实验组）的标准格式（baggage header），不承载 trace 但随请求传播；3) OpenTelemetry：实现并统一采集/导出以上标准，提供 SDK 与传播机制；4) OpenInference：在 OTel 上定义 GenAI 语义（LLM/检索/Agent span 属性），让 AI 场景的 trace 有标准语义。协作：TraceContext 关联链路、Baggage 传业务上下文、OTel 是采集底座、OpenInference 定义 AI 语义，四者共同构成标准化的跨服务 GenAI 可观测体系。

四者各司其职：TraceContext 管链路关联、Baggage 管业务上下文、OTel 管采集底座、OpenInference 管 AI 语义，协作实现标准化跨服务追踪。

• 反馈回填
• 关联 key 设计
• 低基数

反馈回填：用户点击点赞/点踩后，通过 trace ID 或请求 ID 把反馈关联到对应 trace，在 trace 上打"反馈标签"（如 is_positive、feedback_type）。关联 key 设计避免高基数：1) 用 trace ID 关联明细（trace ID 是唯一的，但只用于关联不回填为聚合标签）；2) 回填到 trace 的"标签"只用低基数聚合值（如 feedback_type: positive/negative、rating_bucket），不用"原始用户 ID、完整评论"；3) 高基数/敏感数据（用户 ID、评论文本）放外部存储，通过关联 ID 连接，不进 trace 标签；4) 聚合反馈到 trace 的维度（如"是否被点踩"）用布尔/低基数枚举。这样反馈可关联分析又不拖垮 trace 基数。

反馈回填用 trace ID 关联，标签只用低基数聚合值（positive/negative），高基数敏感数据（用户 ID、评论）放外部表，避免污染 trace。

• SLI/SLO 设计
• 质量指标纳入
• 错误预算

AI 应用 SLI/SLO 分两类：1) 系统类：可用性（请求成功率）、延迟（P95 TTFT/TPOT）、错误率；2) 质量类：任务成功率、引用支持率、安全通过率、用户满意度。SLI/SLO 需把质量指标与系统指标一起纳入，因为 AI 应用"能响应但不正确"同样是故障。SLO 定义：如"任务成功率 ≥ 90%、引用支持率 ≥ 95%、P95 延迟 ≤ 2s、可用性 ≥ 99.9%"。错误预算分配：每个 SLO 有错误预算（1 - SLO），错误预算按"风险权重"分配——质量类错误预算可更小（更严格），系统类按可用性目标；消耗：每次未达标消耗错误预算，当预算耗尽触发"冻结发布/强制修复/回滚"。用错误预算把"质量与可用性"统一为可量化、可运营的机制。

AI 的 SLO 必须含质量指标（正确性），否则"能响应但错"不算故障。错误预算把质量与可用性统一，消耗完触发降级/冻结/回滚。

• 存储完整文本的代价
• 聚合指纹
• 隐私与成本

不应在 trace 存完整对话文本：1) 隐私：对话含 PII/敏感内容，存储扩大泄露面、违反合规；2) 成本：完整文本存储量大、成本高、检索慢；3) 价值低：完整文本对多数分析非必需。应保留"聚合指纹"：1) 结构化摘要：问题类型、意图、解析后的关键字段；2) 低基数标签：token 用量、延迟、模型、错误类型、反馈；3) 哈希/指纹：敏感内容可哈希（不计隐私强度但可用于去重）；4) 触发条件采样：仅对异常/高风险样本按需存完整正文（脱敏）。原则：默认存结构化聚合字段，完整正文按需脱敏采样，控制隐私与成本。

完整对话文本"贵且敏感"。默认存结构化聚合指纹，完整正文按需脱敏采样，在可观测性与隐私/成本间平衡。

• Exemplar 机制
• 指标到 trace 跳转
• 异常定位

Exemplar（示例）是 OTel/指标系统的机制：为一个"异常或代表性地标值"附带一个具体 trace 的引用（trace_id + span_id），当指标异常时，可直接从该指标值跳转到具体的 trace。原理：指标是聚合的（如 P95 延迟），聚合丢失了"哪个请求慢"的明细；Exemplar 让聚合值"携带示例"——标记引发该值的某次 trace。用法：定义指标时启用 Exemplar，记录代表性/异常样本的 trace ID；当指标异常（如延迟飙升）时，点击 Exemplar 直接跳到对应 trace，看完整链路归因。避免"盲找"：Exemplar 在异常点提供"现成入口"，无需人工在大量 trace 中搜索。

指标是聚合的，Exemplar 为聚合值附加"具体 trace 引用"。异常时从指标直接跳到 trace，避免人工大海捞针式盲找。

• Baggage 适用场景
• 上下文传递
• 低基数与限制

Baggage 适合传递"跨服务需要、低基数、非敏感、不涉及巨额追踪"的业务上下文：租户 ID（租户隔离与计费）、实验分组（A/B 分组，保证路由一致）、地区/环境、会话类型、请求来源。这些值在跨服务时被传播，用于路由、计费、隔离、分析。不适合：敏感数据（PII、密钥）、高基数数据（每请求唯一）、大体积数据——Baggage 会在每个请求头传播，增加开销与泄露面。用法：在入口设置 Baggage（用 OTel Baggage API），随请求自动传播，下游读取。配合 TraceContext 使用：TraceContext 管链路，Baggage 管业务上下文。

Baggage 传递"低基数、非敏感、跨服务需要的业务上下文"（租户、实验分组）。敏感/高基数/大体积数据不适合放 Baggage。

• 版本控制差异
• AI 资产特殊性
• 工具选型

差异：1) 传统 CI/CD 管"代码"，LLMOps 管"Prompt、数据集、模型、评估"等 AI 资产；2) 代码变更以"确定性测试"验证，Prompt/dataset 变更以"评估集 + Judge"验证（概率性、需 golden 对齐）；3) Prompt/dataset 版本还需绑定"模型版本、评估结果、embedding"等，形成更复杂的版本矩阵；4) 数据集版本可能涉及"数据漂移、标注、脱敏"等专门治理；5) 传统 Git 适合代码，但 Prompt/dataset 的"大文件、二进制、与模型/评估的关联"需专门 LLMOps 工具或扩展。二者可互补：用 Git 管代码，用 LLMOps 管 Prompt/dataset 的版本与评估，Prompt 版本与代码 commit 关联。

代码与 AI 资产的版本控制本质不同：AI 资产需绑定模型/评估、需概率性验证、需专门治理。LLMOps 工具与 Git/CI 互补而非替代。

• 各语言 OTel SDK 成熟度
• GenAI 支持
• 选型考量

各语言 OTel SDK 成熟度：1) Python：GenAI 生态最活跃，LLM 框架（LangChain、OpenAI）的 GenAI 语义集成最成熟，常用；2) Java：OTel Java SDK 稳定，GenAI 语义支持在演进、部分框架（如 Spring AI）有集成，成熟度中等；3) Node.js：OTel 基础稳定，GenAI 语义支持相对较新，集成需更多手动。选型考量：1) 看官方最新文档与各语言的 GenAI Semantic Conventions 支持情况；2) 看业务语言生态（所用 LLM 框架是否便于打点）；3) 看是否需要自定义传播（响应式/异步）；4) 按最新状态评估，标注核查日期。多数场景 Python 生态最成熟，Java/Node 视业务框架而定。

各语言 GenAI 支持成熟度不同，Python 最成熟、Java/Node 在演进。按官方最新状态 + 业务框架生态选择，并定期重验。

• 采样策略类型
• head vs tail 权衡
• 采样设计

head-based（入口采样）：在请求入口按概率/规则决定整条 trace 是否采样，简单高效、开销小，但无法针对"异常/重要"的 trace 精准采样（可能漏掉异常 trace）。tail-based（出口采样）：先记录 trace 片段，在结束时按"规则/异常"决定是否保留整条 trace，能精准保留异常/高风险 trace，但需缓存中间数据、开销大、复杂度高。选择：head-based 适合"成本敏感、采样需求简单、需控制开销"；tail-based 适合"需要精准捕获异常/慢 trace、可接受更高开销"。AI 场景常混合：head-based 做基础采样 + tail-based 对异常/错误/高风险事件精准保留（如错误、慢 trace 必采）。

head-based 简单省开销但难精准捕异常，tail-based 精准但贵。AI 场景常混合：head 基础采样 + tail 对异常精准保留。

• 可观测性维度
• 质量/可用性/延迟/成本
• 完整可观测体系

AI 应用可观测性四维：1) 质量维度：任务成功率、引用支持率、安全通过率、用户满意度（评估指标）；2) 可用性维度：请求成功率、错误率、超时率、服务可用性；3) 延迟维度：TTFT、TPOT、总耗时、P95/P99；4) 成本维度：Token 用量、缓存命中率、每请求成本、成本预算。四维共同构成完整可观测：质量看"做得好不好"、可用性看"稳不稳"、延迟看"快不快"、成本看"贵不贵"。落地：用 trace 记录单次明细、用 metric 聚合统计、用评估填质量、用日志辅助，形成"质量+可用性+延迟+成本"的一体化可观测体系。

AI 可观测不能只看系统指标，要覆盖质量、可用性、延迟、成本四维。质量与成本是 AI 特有，缺一都会掩盖真实问题。

• 各平台能力
• 定位差异
• 选型对比

各平台定位差异：1) LangSmith：LangChain 生态深度集成，tracing 强、评估、Prompt 管理完善，适合 LangChain 用户；2) Langfuse：LangChain 生态通用，tracing、评估、Prompt 管理、数据集管理，开源可自托管，定位全面；3) Phoenix（Arize Phoenix）：以可观测性、Embedding 可视化、评估与 bad case 探索为主，开源，适合深度分析；4) Helicone：定位"代理/网关 + 可观测"，侧重成本、限流、缓存、安全、多 Provider 路由，评估相对轻。比较：tracing 上 LangSmith/Langfuse/Phoenix 均强，Helicone 更偏网关；评估上 LangSmith/Langfuse/Phoenix 强；Prompt 管理 LangSmith/Langfuse 强；网关 Helicone 强。选型按"评估/探索 vs 网关/成本"需求。

各平台定位不同：LangSmith/Langfuse 全面评估、Phoenix 侧重可观测探索、Helicone 侧重网关与成本。按需求选型。

• 平台迁移
• 数据导出导入
• 可迁移性

平台迁移涉及四类资产：1) Trace：通过导出 API 把 trace（含 span、token、延迟）导出为标准格式（JSON/OTel），再导入新平台；2) Prompt：导出 Prompt 文本、版本、元数据，在新平台重建版本；3) Dataset：导出数据集（输入、golden、标签），导入新平台；4) 评分：导出评估分数、标注、反馈，映射到新平台。迁移要点：1) 确认源平台导出 API 覆盖度与字段支持；2) 用标准格式（OTel/JSON）中转，避免私有格式丢失；3) 映射 ID 关系（trace、session、prompt）；4) 迁移后验证数据完整性（trace 数、样本数、分数）；5) 考虑"新平台能力差异"（Helicone 评估能力弱于 Langfuse，需决定是否寻找替代评估）。迁移前先评估可导出性与目标平台能力。

平台迁移依赖"导出 API 覆盖度 + 标准格式 + ID 映射 + 完整性验证"。同时要考虑目标平台能力差异，避免"神数据迁成鸡肋"。