Mlops

LLM可观测性 与传统微服务应用所关注的黄金三指标（请求数，错误，耗时）类比，我们认为 AI 应用的黄金三指标可能是 Token，Error，Duration。 耗时主要关注的是模型推理延迟，也就是在推理过程中我们通常需要关注模型的首包延迟，即 TTFT(Time to first token)，这个指标反映了相应的速度，还有像 TPOT (Time Per Output Token) 反映生成的效率和流畅度。另外一个比较重要的指标就是吞吐率。吞吐率可以衡量我们这个模型本身，能够同时去支撑多少个推理请求。所以这几个指标是需要进行一些平衡的，三个指标不可能同时满足得特别好。 Token 可能是 AI 应用最重要的一个指标，所以每次请求会记录 Token 的消耗情况，甚至我们需要精确地区分 Input Token 和 Output Token 的消耗，因为大家知道模型的定价里面 Input Token 和 Output Token 是不一样的，我们在成本核算的时候，会将输入 Token 和输出 Token 分别进行统计。 不同卡的负载情况也是不一样的，这个也应该上报，并在扛不住的时候，自动熔断降级（比如用其他的卡） 耗时耗在哪？ ==> 全链路追踪 问答质量 我们要解决模型回答得好不好，每次模型的升级和优化，都需要建立一个基线，并且确保模型的迭代满足这个基线，否则回答的质量会导致用户体验受损。为此，我们把模型的 input/output 全部都采集到日志平台中，接下来我们可以筛选出一批记录，通过数据加工，引用外部的裁判员模型，对当前这个模型回答的输入输出结果进行一个评估。 要把Trajectory做好 Trajectory 直译是：轨迹、路径、运行过程。 在 LLM Agent / AI Agent 里，Trajectory 通常指： Agent 为了完成一个任务，从接收用户问题开始，到最终输出答案为止，中间经历的完整执行过程。 它不只是最终答案，而是包括中间所有步骤。 例如用户问： “帮我查一下某个法规，并总结适用条件。” 一个 Agent 的 trajectory 可能是： 1. 接收用户问题 2. 判断用户意图：法规查询 + 条件总结 3. 改写检索 query 4. 调用知识库检索工具 5. 读取召回的法规条文 6. 判断哪些条文相关 7. 再次调用工具补充查询 8. 组织答案 9. 输出最终回答 这些步骤合起来，就叫一条 Agent trajectory。 ...