模型选型的成本—质量帕累托与自动路由（含小模型优先）

• 理解自动路由的离线评估与持续纠偏机制
• 掌握复杂度标注、误路由成本度量、规则回归
• 理解防止复杂任务误降级到小模型

自动路由要防"复杂任务被误分给小模型"，需建立"离线评估 + 持续纠偏"闭环。离线评估：建立带"复杂度标注"的评估集（每条样本标注真实复杂度），用路由规则跑一遍，度量"误路由率"（复杂任务被分到小模型的比率）与误路由成本（误路由导致的质量崩塌、返工、升级带来的额外成本）。规则回归：规则调整后，用评估集回归，确认新规则不降低质量、不增加误路由。持续纠偏：上线后用线上日志（任务结果、用户反馈、升级率）定期回测，校准路由特征与阈值；发现误路由上升则回退或调整规则。关键是把"误路由成本"量化（误路由一次的质量损失与返工成本），让路由决策有成本考量，而非只看单价。

路由的风险不在"降级"，而在"误降级"。离线评估 + 复杂度标注 + 误路由成本度量，让规则在上线前被验证；持续纠偏让规则在线上被校准。规则回归保证每次调整不退化。这是"数据驱动"而非"拍脑袋"的路由治理。

• 理解级联模式的升级触发（置信信号）
• 掌握 logprobs、自评、业务校验等升级条件
• 理解升级比例带来的延迟与成本

级联（小模型优先，置信不足时升级大模型）的关键是"升级条件"要可靠。置信信号有三类：logprobs（模型输出 token 的概率，低概率表示不确定，可触发升级）、自评（让模型评估自己回答的置信度/是否满足需求）、业务校验（用规则/校验法验证输出是否符合业务约束，如格式、数值、关键信息）。升级条件 = 这些信号综合判定（如 logprobs 低于阈值或自评低或业务校验失败则升级）。要度量升级比例带来的代价：升级比例 = 升级请求数/总请求数，它决定额外的延迟（每次升级多一次大模型调用）与成本（升级到大模型多花 token）。用评估集调校准阈值：阈值放宽→升级多、质量高但成本高；阈值收紧→升级少、省成本但质量风险大。用"升级比例 × 单次升级成本"与"降级质量损失"平衡，选最优阈值。升级要有次数上限（防止小模型反复升级死循环）。

级联的价值是"大多数简单任务用小模型省钱，少数复杂任务升级保质量"。升级条件是核心——置信信号要能区分"小模型不会"与"小模型会但不确定"。升级比例是成本与质量的平衡点，需用数据校准。

• 理解对照实验的组别设计（自动路由 vs 单一中档模型）
• 掌握同时评估成本与质量而非只看成本
• 理解实验的变量控制与统计判定

只展示成本下降不够，因为成本下降可能伴随质量下降。要用对照实验同时证明"成本更低且质量不差（或更好）"。设计：A组（实验）= 自动路由，B组（对照）= 单一中档模型通吃，两组流量随机分到同一批用户/任务，控制其他变量（缓存、配额、用户分层、Prompt 版本一致）。指标：同时度量成本（成本/请求、token 消耗）与质量（任务成功率、解决率、用户满意度、准确率），并做统计显著性检验（如 t 检验/置信区间），证明"成本下降"与"质量不降"都显著成立。质量可能因路由而"略降"（复杂任务被降级），需判断是否在可接受范围，或路由是否保住高价值任务质量。实验要足够时长与样本量，覆盖长尾场景，避免短期/小样本误导。

对照实验的核心是"公平对比"——单一中档模型是好的基线，因为它是"不说路由也够用"的默认方案。只有证明"成本下降 + 质量不降"双达标，才说明路由真的优于通吃。变量控制与显著性检验是结论可信的前提。

• 理解 Token 计费的三类（Input、Output、Cached）与价格差异
• 掌握一次问答的成本拆解公式
• 理解缓存命中率对单请求成本的影响

一次问答成本 = Input(×价) + Output(×价) + Cached(×价，显著低于 Input)。拆解：输入 token 数（问题+系统提示+上下文）按输入价，输出 token 按输出价（通常比输入贵），命中缓存的输入部分按缓存折扣价（通常仅为输入价的 10-20%）。缓存命中率变化的影响：设缓存命中率 h，则每次请求的输入成本 = (1-h)×输入价×输入token + h×缓存价×输入token。命中率越高，输入成本越低，单请求成本越低。测算方法：给定输入/输出 token 分布、三类价格、命中率 h，即可算出单请求平均成本；把 h 从 0 到 1 变化，画出"命中率 vs 单请求成本"曲线，量化"提升命中率 X 个百分点，单请求成本降 Y%"。这支撑"要不要投缓存、优化稳定前缀"的决策。

缓存命中率是压低单请求成本的最有效杠杆之一，因为缓存输入价格远低于普通输入。把成本拆成"命中/未命中"两部分，命中率就变成可量化、可优化的变量。这支撑"稳定前缀、请求规范化"等缓存优化手段的 ROI 判断。

• 理解厂商基准的局限（基准数据不代表自有业务）
• 掌握用自有任务集评估模型质量与成本
• 理解成本—质量对比的选型方法

厂商基准（如 MMLU、HELM）反映的是通用能力，不代表自有业务场景，因此要用自有任务集评估。方法：收集自有业务的真实任务样本（覆盖各功能、各难度、长尾场景），标注正确答案/质量标准，作为评估集。对每个候选模型（GPT-4o、Claude Sonnet、Haiku、Llama 3.3），在评估集上跑：度量质量（准确率、任务成功率、主观质量打分）与成本（按该模型实际 token 单价 × 实际消耗，含重试率）。成本还要考虑"成功成本"——质量差的模型重试多，成功任务成本更高。最后画"成本—质量"散点/帕累托，选"质量达标且成本最低"，或"成本预算内质量最高"。关键是有自己的评估集，且评估集要持续更新（覆盖线上真实分布），避免评估集与业务脱节。

厂商基准是"起点"，自有任务集是"终点"。因为每个业务的 prompt 风格、任务复杂度、质量要求都不同，只有用自己的真实数据评估，才能得出"哪个模型对我的业务最划算"。选型决策是"质量约束下的成本最优"，而非"谁基准分高"。

• 理解 Prompt 精简/压缩的 token 节省机制
• 掌握用评估集度量节省与质量损失
• 理解节省与质量的权衡

Prompt 精简（指令重写、删冗余、示例删减、压缩上下文）能减少输入 token，从而降低输入成本（尤其长上下文场景）。但精简可能损失信息与指令清晰度，导致质量下降。权衡方法：用评估集度量——同一批任务，分别用"原始 Prompt"与"精简后 Prompt"跑，度量（a）token 节省量（输入 token 减少、成本下降）与（b）质量变化（准确率、成功率的差异）。核心是找"精简度"的平衡点：过度精简（token 省很多但质量崩）不可取；适度精简（token 省可观、质量几乎不掉）最优。用"每省 1% token 对应质量下降多少"的边际权衡，或用"质量不降前提下最大化成本节省"作为优化目标。评估集要覆盖复杂任务，避免被简单任务误导（简单任务精简后质量不变，复杂任务精简后可能崩）。

Prompt 精简是"免费的降本"（改 Prompt 不花钱），但也是"有风险"的——删过头就掉质量。评估集是"安全阀"，用数据验证"到底能删多少、怎么删"，避免凭感觉精简。边际权衡帮你找"省得多且不掉质量的点"。

• 理解级联路由中"误判为不会"导致的无谓升级
• 掌握用置信信号与业务校验区分
• 理解升级决策的校准与回退

级联里区分"真不会"与"误判为不会"很关键，因为后者会导致本可小模型低成本回答的请求被无谓升级（浪费成本）。区分方法：升级触发信号要"可信"——logprobs 低、自评低、业务校验失败，但这些都是"信号"而非"事实"。要减少误判：用多个信号综合（单信号易误判，多信号共识更可靠）；校准阈值（用评估集测"信号为真"的准确率，找最优阈值）；业务校验若通过则即使 logprobs 低也判为"会"（业务校验是硬约束，比概率更可靠）；对"升级请求"做回测——若升级后回答质量与不升级一样，说明是误判，应调整规则。还要测"升级收益"：升级如果能解决本会失败的请求则值得，若升级后结果一样则纯浪费。避免"无谓升级"就是让升级决策"有依据、有回报"。

无谓升级的根源是"信号误判"。多信号共识 + 业务校验硬约束 + 阈值校准 + 升级收益回测，能把"误判为不会"的比率压下来。核心是"升级要有回报"——升级后能解决真问题才升级，否则就是浪费。

• 理解自托管 vs 商用 API 的权衡（合规、定制化、成本）
• 掌握决策树的关键判据
• 理解长尾成本拐点

自托管 vs 商用 API 的决策树关键判据：数据合规（敏感数据不能出域/出云 → 自托管；合规要求松 → 可 API）；定制化（需要专属模型微调、私有权重 → 自托管；通用能力够 → API）；延迟与稳定性（需要低延迟、可预测 → 自托管/就近；可接受 → API）；成本拐点（长期大规模、GPU 利用率高 → 自托管有拐点优势；用量小/波动大 → API 更划算，因为自托管闲置成本高）。决策树：先看合规（必须自托管则自托管）；再算成本（按预估 token 量算自托管单位成本 vs API 单价，找拐点，用量超过拐点才自托管）；再评估工程成本（自托管要运维 GPU、模型更新、故障处理，人力成本也要计入）。长尾成本拐点：用量低时 API 便宜（无闲置），用量高且利用率高时自托管便宜（摊薄固定成本）。关键是要"算全成本"（自托管含 GPU、电费、人力、闲置）。

自托管 vs API 是"成本与自由的权衡"，不是"谁一定更好"。合规是硬约束优先，成本是经济考量，定制化是能力考量。决策树按"合规 → 成本拐点 → 工程成本"顺序判断，能避免"因为便宜就自托管"或"因为省事就全用 API"的片面。

• 理解 Cost Attribution 的维度（用户、功能）
• 掌握请求级 usage 与业务标签的分摊
• 理解避免多租户争议的透明分摊

Cost Attribution 的核心是"把每笔成本精确归属到用户与功能"，前提是请求级 usage 带足业务标签。设计：每个请求在发起时打上业务标签（租户 ID、用户 ID、功能模块、业务线、产品），请求级 usage 记录携带这些标签，归集时按标签聚合即可得到"某用户成本、某功能成本"。精确分摊要求：标签完整（缺标签的请求无法归属，需兜底处理）、标签准确（错标导致归属错误）、usage 精确（token 用量准确）。为支撑"按用户/按功能"的账单，请求级 usage 要标准记录（token、模型、价格、标签）。多租户账单争议的避免：分摊基于请求级明细（可下钻到逐请求），而非粗粒度估算；提供"用户 → 请求 → 计费项"的下钻证据，让租户可核验。关键是"请求级 usage + 完整准确的业务标签"是精确分摊的基础。

Cost Attribution 的精确度取决于"标签 + usage 的粒度"。请求级 + 全标签才能做到"按用户/按功能"的精确归属。争议的解决靠"可下钻、可核验"的明细，而非拍脑袋分摊。标签治理（完整、准确、标准）是前提。

• 理解预算告警与硬限制的分层（时间/租户/功能维度）
• 掌握软告警/硬熔断的触发与动作
• 理解自动降级 vs 熔断的取舍

预算告警与硬限制要按"时间 × 租户 × 功能"多层设置。时间层：日预算（防单日异常）与月预算（防周期超支）；租户层：每租户独立配额（防单租户拖垮整体）；功能层：每功能预算（防某功能失控）。每层都设软告警（Alert，如达到 70%/80%）与硬限制（Hard Limit，如 100%）。触发后动作分两级：软告警用"自动降级"（降级模型、限流、暂停非关键功能），保留基本能力；硬限制用"熔断"（拒绝新请求、只允许读缓存），强制止损。取舍原则：降级是"渐进退让、保核心"，熔断是"最后防线、止损"。高价值核心功能不应该被轻易熔断（可降级或排队），低价值功能可先被熔断。降级与熔断的组合让"软硬结合"：先软降级缓解，再硬熔断兜底。

分层的意义是"粒度控制"——日/月管时间、租户管隔离、功能管价值。软告警→降级、硬限制→熔断，是"渐进 vs 止损"的分工。分层 + 分级让预算治理既防失控又不伤核心。

• 理解 Cost-Aware Routing 的路由特征（输入长度、任务类型、缓存命中）
• 掌握特征采集方式
• 理解路由决策本身的开销控制

Cost-Aware Routing 用特征做路由决策，特征包括：输入长度（长输入 → 大模型/缓存）、任务类型（分类/生成/复杂推理 → 不同模型）、缓存命中（命中缓存 → 便宜通道）、租户价值、历史质量。采集方式：输入长度在请求侧直接量（token 数）；任务类型用分类/关键词/语义识别；缓存命中由缓存层返回命中标识；这些特征在请求进入路由前收集，作为路由决策的输入。路由决策本身有开销：若用"额外调用一次 LLM 分类器"做路由，会引入额外成本与延迟。控制方法：优先用低成本特征（规则、长度、嵌入相似度、缓存命中）做路由，避免每次路由都调 LLM；若必须用 LLM 分类，用小模型/缓存分类结果，且分类结果可缓存复用；路由特征采集要轻量（不额外增加大请求量）。用"路由开销/总成本"监控制约，确保路由决策的收益 > 其自身开销。

路由是"为省钱而花钱的决策"，其自身开销必须 < 省下的钱。因此优先用零成本特征（长度、缓存、规则），把 LLM 分类作为"高价值任务才用"的奢侈选项。路由特征采集要内联、轻量，避免因采集而增加成本。

• 理解 TTFT、TPOT、Total Latency 的含义与分解
• 掌握用指标分解定位延迟瓶颈
• 理解延迟与成本、体验目标的联动设限

延迟指标分解：TTFT（首 token 时间，反映首包延迟，主要受输入长度、排队、网络、模型启动影响）、TPOT（每输出 token 时间，反映生成速度，受模型大小、硬件、并发影响）、Total Latency（总耗时 = TTFT + TPOT × 输出 token 数 + 后处理）。定位瓶颈：若 TTFT 高 → 前排队/输入过长/模型加载慢；若 TPOT 高 → 生成慢/模型太大/并发过高；若 Total 高但 TTFT/TPOT 正常 → 输出过多/后处理重。联动设限：延迟与成本、体验相互约束——用大模型/快硬件降低延迟但成本高，用长输出提升质量但延迟高。设限方法：按"体验目标"设延迟 SLA（如 P95 TTFT < 1s、P95 Total < 5s），按"成本预算"设模型/输出上限，超限时降级（输出限制、换模型、扩容）。用"延迟—成本—质量"三维权衡，而非单一设限。

延迟分解的价值是"定位到具体环节"（TTFT 还是 TPOT），才能对症下药。延迟、成本、体验三者是跷跷板，联动设限是"在预算内满足体验"的约束优化。设限要可测量、可监控、可自动降级。

• 理解离线评估的局限（无法覆盖线上真实分布与反馈）
• 掌握在线评测（Production Eval）的反馈闭环
• 理解在线数据如何驱动模型/路由调整

离线评估集是静态的，无法反映线上真实输入分布、用户反馈与长尾场景，因此要引入在线评测（Production Eval）闭环。在线评测采集：线上任务的真实输入、模型输出、用户反馈（点赞/点踩/纠错）、业务结果（解决率、转化率）、路由决策（哪个模型被路由、是否升级）。把这些反馈回流到评估：在线数据标注质量，形成"线上评估集"，比离线集更贴近真实；用在线数据监控"各模型档位的真实质量"（如小模型在线上某类任务的真实失败率）、"路由策略的误路由率"、"级联升级的有效性"。据此反馈调整：某模型档位在线上质量差 → 调整路由/降档；某路由规则误判多 → 校准规则；某些长尾场景离线没覆盖 → 补充评估集。形成"离线初评 → 上线 → 在线反馈 → 重评/调参"的持续闭环。

离线评估的局限是"数据不真实、不新鲜"。在线评测用真实流量与反馈做"活的评估"，弥补离线不足。关键是让线上反馈回流驱动模型档位与路由的持续调整，形成闭环而非一次性决策。

• 理解输入分布漂移（任务类型、长度、复杂度变化）对模型/路由的影响
• 掌握漂移检测与告警
• 理解漂移后触发重评估与策略更新

输入分布漂移（如任务类型从简单问答变为复杂推理、输入长度变长、出现新任务类型）会改变"哪个模型档位最合适"与"路由规则是否还适用"。例如：原来大量简单任务路由到小模型省成本，若输入变复杂，小模型质量崩塌，路由规则就该调。影响：模型档位（原档位不再匹配新分布）、路由规则（特征阈值失效）、成本（漂移后成本结构变化）。漂移检测：监控输入分布特征（任务类型占比、输入长度分布、复杂度评分、路由各模型的命中率），用统计检验（如 PSI 总体稳定性指数）检测漂移。漂移告警后：触发重评估——用漂移后的新样本重新评估各模型档位质量与路由规则效果；更新策略——根据重评估结果调整路由阈值、档位映射、甚至换模型。形成"检测漂移 → 重评估 → 更新策略"的循环。

输入漂移是"静默的成本与质量杀手"——路由规则是按旧分布调的，分布变了规则就失效。漂移检测（PSI 等）是"先知"，重评估更新是"响应"。没有这个闭环，路由会随输入漂移逐渐劣化而不自知。

• 理解小模型在长尾场景的质量退化风险
• 掌握评估集按场景切片监控
• 理解长尾质量的监控与兜底

小模型承接简单任务时，平均质量可能不错，但退化常藏在长尾场景（低频、复杂、边缘任务）——按平均指标看正常，按切片看长尾已崩。防止方法：评估集按"场景切片"监控，而非只看总体均值。切片维度：任务类型、输入长度、领域、用户群体、难度、地理位置等。每个切片单独度量质量，重点监控长尾切片（低频、高难度、边缘场景）。若某长尾切片质量下降，说明小模型在该场景能力不足，应对这类场景做"路由覆盖"（长尾复杂场景升级到大模型）或补充样本重训。同时设"兜底"：长尾场景若无法处理，降级到人工/大模型，避免直接崩。监控要有"切片级告警"——某切片质量跌破阈值即告警，而非等整体均值下滑。

平均指标会掩盖长尾退化，这是小模型路由的常见陷阱。切片监控把"总体均值"拆成"场景分解"，暴露长尾问题。切片级告警 + 长尾兜底（升级/人工）是防止长尾退化失控的关键。

• 理解价格结构变化对路由性价比的影响
• 掌握价格变化后的路由策略重估
• 理解价格表作为路由输入

若小模型涨价逼近大模型，原来的"小模型省成本"假设失效，需重估路由。价格表应作为路由输入（路由决策要考虑当前价格），但不能是唯一输入——还要结合质量。重估方法：价格变化后，用当前价格重新计算各候选模型的"单位成功成本"（综合考虑价格与质量/重试），若小模型涨价后性价比不再优于大模型，则调整路由（把更多任务切回大模型，或重新分配）。降级处理：价格变化导致路由策略失效时，触发"路由策略重评估 + 灰度切换"，避免沿用旧策略导致成本增加。价格表作为路由输入意味着：路由决策实时感知价格变化（价格表热更新），并据此调整；但价格变化不能单独触发大面积切换，要结合质量复位（因为"便宜"不等于"划算"）。关键是"价格 + 质量"共同作为路由输入，价格变化触发重估而非机械切换。

价格是路由的重要输入，但单独看价格会误判（便宜但质量差不划算）。价格结构变化本质是"性价比关系变了"，需重估"单位成功成本"而非只比单价。把价格表做成路由输入并支持热更新，路由才能随价格自适应。

• 理解选型约束（延迟、配额稳定性、合规驻留）
• 掌握多约束下的选型决策
• 理解成本仅是约束之一

多个模型能力接近时，单价不是唯一决策因素，要引入约束筛选。约束包括：延迟（P95 延迟是否满足 SLA——能力接近但延迟差异大，高延迟模型即使便宜也不可用）、配额稳定性（该模型的配额/可用性是否稳定，避免频繁限流/熔断——不稳定模型再便宜也影响可用性）、合规驻留（数据是否驻留合规区域、是否满足数据出境要求——不合规则直接排除）。决策方法：先做"硬约束过滤"（合规不满足、延迟超 SLA、配额不稳定者直接排除），再在剩余候选里按"单位成功成本"（价格 + 质量）选最优。这就是"约束 + 目标"的决策：约束（延迟/配额/合规）用来筛掉不可用选项，目标（成本）用来在可用选项里选。可把延迟、配额、合规建模为"评分/加权"，与成本一起做综合评估，但硬约束（合规、关键延迟）应是一票否决。

只看单价是"局部最优"，多约束是"全局最优"。合规、延迟、配额是"能不能用"的硬约束，成本是"好不好"的软目标。先约束后目标，避免选了个便宜但不可用/不合规的模型。

• 理解路由器自身的调用成本（额外分类调用）
• 掌握把路由成本计入总核算
• 理解路由划算的边界（量级与价差）

若路由器用"额外一次 LLM 分类调用"做路由，每次请求都多一次调用成本，这一成本必须计入核算，否则路由的"省"会被"路由开销"吃掉。核算：总成本 = 路由成本 + 各模型调用成本。路由划算的条件：路由省下的钱 > 路由开销。设路由开销 c（每次分类调用成本），路由省下的钱 = 分配到便宜模型的比例 × 与大模型价差。量级与价差分析：只有当请求量大、模型价差大（大模型远贵于小模型）、且大多数请求能落到便宜模型时，路由才划算；若请求量小、价差小、或路由后大多仍落大模型，则路由开销占比高，不划算。控制方法：优先用零成本路由（规则、嵌入、缓存），避免 LLM 分类；若必须 LLM 分类，用极便宜的分类模型 + 结果缓存，降低路由开销。用"路由开销/总成本"指标监控，确保路由净收益为正。

路由是"花小钱省大钱"的生意，前提是"花的小钱 < 省的大钱"。核算路由成本是防止"路由本身比省下的还贵"的关键。量级与价差决定路由的盈亏平衡点，零成本路由（规则/嵌入）是首选。

• 理解路由决策留痕的必要性（审计"为何贵"）
• 掌握 trace 与账单中的路由决策字段
• 理解可回答"为何走昂贵模型"的证据链

路由决策要留痕，使审计能回答"这笔请求为何走了昂贵模型"。留痕内容：在 trace 中记录路由决策的完整上下文——请求特征（输入长度、任务类型、复杂度）、路由规则/版本、命中哪个候选、为何选该模型（如"因复杂任务升级到旗舰"、"因小模型失败升级"）、路由决策者（规则/分类器/级联）。在账单中把"路由决策"作为一笔请求的元数据（model 选择原因、路由 process 版本、升级标志），与 token 成本关联。这样审计可以：看到该请求走了贵模型 → 追溯路由决策 → 判断是"合理升级"（复杂任务该用贵模型）还是"误路由"（本可省钱却用了贵模型）。证据链要能回答"为什么"，因此 trace 要记录决策依据（触发升级的置信信号、路由规则命中），而非只记录"用了哪个模型"。

审计"为何贵"比"贵了多少"更重要。路由留痕要记录"决策依据 + 决策版本"，而非只记录"结果"，才能回答"为什么走贵模型"。这既是成本透明，也是路由质量的审计手段。

• 理解 trace 全量记录的成本（存储爆炸）与隐私风险
• 掌握采样与脱敏策略
• 理解成本归因与路由复盘所需的最小记录

全量记录 Prompt/响应/工具事件会存储爆炸且泄露敏感数据，需采样与脱敏。策略：采样——按层采样（全量记录"成本/用量"元数据，按比例采样"内容"），如成本归因只需 token 数、模型、价格，这些全量且轻量；而 Prompt/响应文本只采样（如 1%-10%，或按需开启 debug 采样），降低存储。脱敏——对采样的内容做 PII 脱敏（手机号、身份证、邮件、密钥替换/打码），防止敏感数据进入日志。分层保留：成本元数据全量保留（支撑归因与对账），内容采样保留（支撑路由复盘与质量评估），过期内容定期清理。路由复盘需要"能定位问题"的样本，采样要保证能覆盖异常（对异常/高成本/升级请求提高采样率，如自适应采样），而非均匀随机，否则复盘时异常样本被漏掉。

成本归因与路由复盘对数据的需求不同：成本只需"元数据"，复盘需要"内容样本"。因此"元数据全量 + 内容采样 + 异常加权采样 + 脱敏"是平衡存储、成本、隐私与复盘能力的方案。异常优先采样是复盘有效的关键。

• 理解 OTel GenAI 语义约定的标准字段
• 掌握统一记录模型、token、成本属性
• 理解跨 Provider 成本对比报表

OTel GenAI 语义约定（gen_ai 命名空间）定义了统一的 span 属性，用于标准化记录 LLM 调用：gen_ai.system（Provider）、gen_ai.request.model（模型）、gen_ai.usage.input_tokens / output_tokens（token 用量）、gen_ai.usage.cache_read_input_tokens（缓存命中）、自定义的 gen_ai.cost 等。统一记录的意义：不同 Provider 的调用通过同一套字段标准记录，消除了"每家字段名不同"的差异，从而能生成跨 Provider 的成本对比报表。落地：在 LLM 调用链路埋 OTel GenAI span，把模型、token、缓存、成本（按当时价格算）写入标准属性；成本属性可统一为 gen_ai.cost（币种统一）+ 保留原始 token 供按价格表复算。成本报表按"system + model"维度聚合，跨 Provider 对比"同模型档位、不同 Provider"的成本与用量。关键是标准化字段 + 统一币种 + 统一价格口径，让跨 Provider 数据可比。

跨 Provider 对比的障碍是"各家字段不统一"。OTel GenAI 语义约定提供"标准字段"，统一模型、token、成本属性的记录方式，是跨 Provider 报表的前提。标准 + 统一币种/价格，才能生成可比的对比报表。

• 理解 A/B 测试的变量控制（缓存、配额、用户分层）
• 掌握控制变量的方法
• 理解胜出判定指标（成本 + 质量）

模型/路由 A/B 测试要控制干扰变量，否则结论不可信。需保持不变的变量：缓存（两组缓存命中率要一致或缓存状态一致，否则命中率差异污染成本对比）、配额（两组配额/限流一致，避免配额差异导致结果差异）、用户分层（两组用户分布一致，用随机分流或分层抽样保证可比）、Prompt 版本（一致）、其他路由（被测之外的路由逻辑一致）。判定胜出的指标要"成本 + 质量"双维度：成本（成本/请求、token 消耗、单位成功成本）、质量（任务成功率、解决率、准确率、用户满意度、误路由率）。胜出判定：一组的"单位成功成本"显著更低且质量不降（或质量等价），才算胜出；避免只看成本（质量下降）或只看质量（成本过高）。做统计显著性检验，并覆盖长尾与足够样本。

A/B 测试的可信度取决于"变量控制"。缓存、配额、用户分层是最容易污染结果的变量，必须控制。胜出判定要"成本降 + 质量不降"双达标，且用显著性检验，避免小样本/短期误导。

• 理解 LLM Observability 平台的功能与选型标准
• 掌握与 OTel GenAI 语义约定的关系
• 理解成本观测与可观测平台的集成

各平台定位：Langfuse（开源、LLM 追踪 + 成本 + 评测，可自托管）、LangSmith（LangChain 生态，追踪 + 评测 + 数据集）、Helicone（专注成本监控与代理，轻量探针）。选型标准：功能（追踪/成本/评测/路由）、成本（SaaS 费用 vs 自托管）、数据合规（是否可自托管、数据出境）、集成（与现有技术栈/OTel 兼容）、开放（是否支持导出到通用监控）。与 OTel GenAI 语义约定的关系：OTel 是"开放标准"，定义了统一的 LLM span 字段；这些平台是"商业化实现"，有的原生支持 OTel GenAI 语义约定（数据可导出到 OTel 兼容的监控），有的用私有 schema。选型时优先选"支持 OTel GenAI 语义约定"的平台，这样数据可开放导出、可迁移、可与其他监控统一，避免锁定在私有 schema。关系是"平台是标准的具体实现，标准是平台的通用语言"。

选型要兼顾"功能"与"开放性"。功能决定能不能用，开放性（是否支持 OTel GenAI 约定）决定数据能不能带走、能不能统一。优先 OTel 兼容的平台，避免 schema 锁定，让成本观测数据可复用、可对比。

• 理解 OpenInference、OpenLLMetry 的定位
• 掌握其导出 token 用量与成本的机制
• 理解成本报表复用

OpenInference 是规范了 LLM 调用追踪 span 的语义约定（类似 OTel GenAI，定义 model、token、metadata 等字段），OpenLLMetry 是基于 OpenTelemetry 的库，把 LLM 调用（OpenAI、Anthropic 等）自动生成 OTel span，并记录 token 用量、模型、耗时等。它们把 token 用量与成本导出到通用监控的方式：通过 OTel Collector 把 span 发送到 Prometheus/Grafana、Jaeger、Datadog 等通用监控；span 中带 token 用量（input/output）与模型，成本报表端用"模型 × token × 价格"计算成本，或由平台直接算好成本属性。导出后，成本报表可作为通用监控的仪表盘复用：按模型/租户/功能聚合 token 与成本，无需每家 Provider 单独采集。关键是"标准 span + 通用导出"，让成本数据进入统一监控体系，供多个报表复用。

这些库/规范的价值是"标准化 + 通用导出"。把 LLM 调用变成标准 OTel span，导出到通用监控，成本报表就能复用同一套采集数据，避免重复埋点。这支撑了"一套观测、多端复用"。

• 理解按功能价值评估模型档位
• 掌握成本与客户价值（调用频率、价值）的匹配
• 理解避免低频功能用旗舰模型

CRM 助手选型要"按功能价值 × 调用频率"匹配模型档位，避免为低频高级功能长期支付旗舰模型费用。评估方法：把 CRM 功能列出，标注每个功能的调用频率（高频/低频）与客户价值（直接影响成单/客户满意度 vs 辅助功能）。旗舰模型只用于"高频且高价值"或"低频但对业务关键"的功能；低频且低价值功能降级到小模型；高频但简单功能用缓存 + 小模型。成本评估：对每个功能，分别算"旗舰模型单位成本"与"小模型单位成本"，结合调用量算总成本；低频高级功能若用旗舰模型，总成本可能不高（因为低频），但长期看是"为不常用能力付费"，可评估是否值得。更优做法：用"功能级路由"——同一 CRM 内，简单功能走小模型、复杂功能走旗舰，而非一个功能档位对应一个模型。避免"低频高级功能长期支付旗舰费用"= 按功能价值分级，不为低频功能长期绑旗舰。

选型要"按价值付费"而非"按能力上限付费"。低频功能用旗舰模型，是"为不常用能力持续付费"的浪费。功能级路由 + 频率/价值评估，让每个功能用匹配的模型档位，避免浪费。

• 理解按会话量计费下"单会话成本"是核心指标
• 掌握模型档位路由削减单会话成本
• 理解缓存策略削减会话内重复调用

按会话量计费时，收入是"会话数 × 单价"，成本是"会话总成本"，因此控制"单会话成本"是盈亏关键。手段：模型档位路由——一个客服会话内多次调用，按各自复杂度路由（简单 FAQ 走小模型/直答、复杂咨询走旗舰），而非整个会话统一用旗舰；缓存策略——会话内重复问题、系统提示、历史总结命中缓存，缓存命中输入价远低，显著降单会话成本；语义缓存——相同/相似问题直接返回缓存答案，省掉再生成。还要控制"会话长度"——会话越长调用越多，用"会话预算/轮次上限"防滚雪球。综合"路由 + 缓存 + 会话预算"把单会话成本压到"单价 × 会话数"的毛利空间内。单会话成本 = 会话内所有调用成本之和，要监控其分布与异常。

按会话量计费是"固定单价、变动成本"，单会话成本超了单价就亏。路由（按复杂度分模型）+ 缓存（命中省输入）+ 会话预算（防无限增长）是控制单会话成本的三板斧。核心是"单会话成本"这个可下钻的指标。

• 理解高并发任务的成本特征
• 掌握小模型优先与批处理降本
• 理解单位成本控制

营销文案生成是高并发、量大、延迟不敏感（可批量）的任务，适合两种降本手段。小模型优先：文案生成多为模板化、重复性任务，质量要求中等，可用小模型承接（简单模板文案），大模型只用于复杂策划/创意；且文案生成可先用"评估集"验证小模型质量，达标才用。批处理生成：营销文案量大且不要求实时，可走 Batch API（批量提交，延迟换取折扣，通常便宜 50%），把"逐个实时生成"改为"批量提交 + 定时领取"。落地：把高并发文案任务按复杂度路由（模板→小模型+批量、创意→大模型），批量任务进队列异步生成，降低单位成本。监控"单位文案成本"（每篇文案的成本），验证降本效果。

高并发 + 延迟不敏感是"批处理 + 小模型"的天然适用场景。小模型压单价、批处理压折扣，两者叠加把单位成本压到最低。单位成本（每篇文案）是衡量效果的核心指标。

• 理解 HR 场景各功能（简历解析、员工问答）的成本特征
• 掌握按功能归集成本
• 理解哪些功能可降级到小模型

HR 场景按功能归集：简历解析（结构化抽取，量大、模板化、可批量）、员工问答（FAQ 问答、政策查询）、面试评估、报告生成等。每个功能带功能标签，成本按标签归集，看各功能成本占比。可降级判断：简历解析——结构化抽取、规则性强，可批量 + 小模型（若抽取质量达标，用评估集验证）；频繁 FAQ 问答——可语义缓存 + 直答 + 小模型；复杂员工问答（政策难点、多轮）——需大模型；面试评估——主观性强、价值高，需大模型。降级原则：规则化、模板化、量大、质量要求适中的功能（简历字段抽取、FAQ 直答）可降级到小模型；开放性、高价值、复杂推理（面试评估、复杂问答）留大模型。按功能归集 + 评估集验证，决定每个功能用哪个档位。

按功能归集是"看清钱花在哪"，降级是"把能省的功能省下来"。规则化/模板化功能（简历抽取、FAQ）天然适合小模型 + 批量，开放性高价值功能（评估、复杂问答）留大模型。评估集验证是降级的安全前提。

• 理解 ERP 助手中低价值问答与高价值操作的差异
• 掌握按价值路由与审批门槛控制
• 理解高价值操作的成本与风险平衡

ERP 助手的操作分两类：低价值问答（查库存、查状态、FAQ）与高价值操作（下单、审批、改数据）。成本差异：低价值问答量大、简单，用便宜模型即可；高价值操作少、复杂、风险高，需大模型 + 审核。控制方法：路由——低价值问答路由到小模型/直答/缓存，高价值操作路由到大模型（因为操作错误代价高）；审批门槛——高价值操作无论模型如何，都要"人工审批"或"二次确认"作为门槛（下单需确认、审批需复核），既控成本又控风险。成本控制：高价值操作虽然贵，但量少且价值高，成本可控；关键是避免"高价值操作被误当低价值问答用便宜模型处理"导致出错。用"操作类型"标签区分，按价值路由，高价值操作设审批门槛保底。

ERP 的价值分层是"低价值省钱、高价值保质量"。低价值问答用便宜模型压成本，高价值操作用大模型 + 审批门槛保质量与风控。审批门槛是"成本与风险"的平衡点——高价值操作不因省钱而牺牲正确性。

• 理解语义路由的机制（查询嵌入 + 路由模板相似度）
• 掌握基于误路由代价矩阵校准阈值与 top-k
• 理解路由器成本、LLM 回退与线上回测设计

语义路由用查询嵌入与各 pipeline 模板的相似度选 pipeline，核心是"阈值与 top-k 的校准"。误路由代价矩阵：定义"错分到某 pipeline 的代价"——错分到小模型（质量崩塌）代价高、错分到大模型（成本浪费）代价低、错分到转人工（人工成本）中等。据此校准相似度阈值：高代价错分（把复杂问题分给 FAQ 直答）要设高阈值（只有非常相似才分派），低代价错分可放宽。top-k：若 top-k 候选相似度都低于阈值，则"回退"到 LLM 分类器或转人工，避免硬分流。路由器成本：嵌入调用本身有成本，用缓存嵌入 + 批量嵌入降低；低价值请求避免每次都嵌入，或用轻量嵌入。回退设计：相似度不足时回退到 LLM 分类器（更准但贵）或转人工，作为兜底。线上回测：用线上日志（真实查询 + 路由结果 + 用户反馈）回测路由准确率，定期校准阈值与模板，监控误路由率与回退率。

语义路由的"性价比"取决于阈值校准——太严则大量回退（贵）、太松则误路由（质量崩）。用"误路由代价矩阵"量化"错分到哪最贵"，让阈值与代价对齐。回退到 LLM 分类器是"准确兜底"，线上回测是"持续校准"，三者结合让语义路由既省又准。

• 理解用自有评估集测绘帕累托前沿
• 掌握厂商基准与单价的局限
• 理解帕累托前沿的选型方法

帕累托前沿测绘：用自有评估集，对每个候选模型跑出"质量分"（在评估集上的准确率/成功率）与"成本"（单位成功成本，含重试），以"成本为 X 轴、质量为 Y 轴"画散点，连线得到帕累托前端（成本低且质量高的点集合）。选型落在前沿上。为什么厂商基准排名不能直接用：厂商基准测的是通用能力，不代表自有业务分布与质量要求，某模型基准高但你的任务上不一定好。单价不能直接用：单价只反映"每 token 价格"，不反映"完成某任务需要多少 token、重试多少次"——便宜但重试多、质量差，单位成功成本反而高。所以要用"自有评估集 + 单位成功成本"测绘前沿，而非厂商基准或单价。

帕累托前沿把"成本"与"质量"放在同一坐标系，暴露"每单位质量要花多少钱"。厂商基准与单价都是"片面的代理指标"，无法反映自有业务与成功成本。自有评估集 + 单位成功成本是选型的可靠依据。

• 理解 BI 问答高频查询的成本特征
• 掌握缓存、小模型、语义缓存的降本
• 理解高频查询的 token 成本控制

BI 问答高频查询（相同/相似的可视化、指标询问）适合三种降本。精确缓存：完全相同的查询（同问题、同维度）直接返回缓存结果，零 token 成本；语义缓存：相似的查询（不同措辞同意图）用 embedding 相似度匹配，命中缓存返回，省掉再生成；小模型：高频简单的 BI 查询（指标解释、简单对比）用小模型承接，复杂分析（多表 join、复杂推理）用大模型。落地：BI 查询先查缓存（精确 + 语义），未命中再根据复杂度路由到小/大模型。缓存命中率越高，token 成本越低。注意缓存失效：数据变更后缓存要失效，避免读到过期指标。监控"缓存命中率"与"高频查询的 token 成本"，验证降本效果。

BI 高频查询的"重复性"是缓存的天堂——相同/相似查询占比高，缓存命中能省下大量重复生成成本。语义缓存对"措辞不同但意图相同"的查询尤其有效。小模型承接简单查询进一步压成本。

• 理解销售批量生成（邮件、摘要）延迟不敏感特征
• 掌握批处理 API 与模型降档
• 理解摊薄 token 成本

销售批量生成（大批量邮件、会议摘要）有"量大、延迟不敏感、模板化"特征，适合两种降本。批处理 API：把大量邮件/摘要任务批量提交，不走在线实时，换取批量折扣（通常便宜 50%），任务异步完成、定时领取，摊薄单位 token 成本。模型降档：邮件/摘要是模板化、重复性任务，质量要求中等，可用小模型承接（评估集验证质量达标），大模型只用于高价值客户邮件或复杂摘要。落地：批量任务走 Batch API + 小模型，简单模板邮件用模板直填（不调用 LLM），综合摊薄成本。监控"每封邮件/每份摘要的成本"验证效果。注意：批量任务有截止时间，要在 SLA 内完成；结果领取要设计好。

销售批量生成是"量大事多、不急"的典型，批处理 + 小模型 + 模板直填，把"逐条昂贵生成"变成"批量便宜生成"。延迟换取折扣、降档换取单价，单位成本被大幅摊薄。

• 理解法律文档处理的高质量要求
• 掌握按环节的价值与风险分级
• 理解哪些环节旗舰、哪些可降级

法律文档处理质量要求高、出错代价大，但也不是所有环节都需旗舰模型。分级：必须用旗舰模型——高风险环节（合同条款分析、法律意见生成、风险识别、涉及法律责任的结论），因为出错代价极高（法律风险、赔偿）；可降级——低风险环节（文档格式整理、摘要、关键词提取、信息检索、去重），这些规则化、辅助性、出错影响小，可用小模型或规则/模板。平衡方法：按"环节风险 × 价值"分级，高风险环节旗舰 + 人工复核，低风险环节小模型/规则。成本控制：高风险环节虽贵但量少（关键闭环），低风险环节量大但用便宜手段，整体成本可控。对旗舰模型用量也要控制（如限制输出长度、缓存相似条款）。关键：风险高的必须旗舰 + 人工把关，不能为省钱省掉高风险环节的质量。

法律场景的平衡是"风险与成本"的权衡。高风险环节是"命门"（出错代价 > 节省成本），必须旗舰 + 人工复核；低风险环节是"可省"（出错影响小），用便宜手段。按风险分级，既保质量又控成本。