一句话定义：日志采样（Log Sampling）是在日志落盘或上报之前，按某种规则只保留其中一部分记录，用可承受的存储成本换取对系统行为的近似观察。
为什么 AI 应用尤其躲不开它
传统服务的日志一行几十字节，而 AI 应用的一条日志里常常塞着 prompt、检索到的文档片段、模型输出、工具调用参数，动辄几十 KB。请求量一上来，日志体积增长比流量还快。全量留存通常撑不了多久，于是有人随手加一行“按 1% 概率保留”，问题就从“贵”变成了“瞎”。
打个比方
高架桥上的监控。每辆车都存高清录像，硬盘一周就满。合理做法是：平时每秒抽几帧，用来估算车流密度；一旦雷达检测到急刹或碰撞，立刻切全量录像并打红标。前者回答“今天堵不堵”，后者回答“那场事故怎么发生的”。这两件事需要的数据根本不是同一批。
按比例随机丢日志，相当于连事故录像也一起抽掉了。
几种常见策略的区别
| 策略 | 决策时机 | 好处 | 代价 |
|---|---|---|---|
| 头部采样（head-based sampling） | 请求入口 | 实现简单、开销极低 | 看不到结局，错误请求大概率被抽走 |
| 尾部采样（tail-based sampling） | 请求结束后 | 出错、超时、被用户点踩的链路全部保留 | 需要先缓冲全量数据再判定，架构更重 |
| 错误优先保留（error-biased sampling） | 写入或上报时 | 改造成本低，排查时最有用 | 统计口径有偏，不能直接拿来算真实错误率 |
关键洞察是：错误是低频事件。0.1% 的错误率遇上 1% 的随机采样，几乎一条错误日志都留不下；而正常请求丢掉 99% 通常无所谓。所以合理的做法往往是“成功按比例丢、失败全量留”。但要记得同时记录采样率，用权重把平均值、成功率还原回去，否则监控面板上的数字会系统性失真。
对从业者的实际意义
排查线上问题时，prompt 和模型输出往往是最关键证据，也恰恰是最占体积的部分。把采样配成无差别随机丢弃，等于随机毁掉证据链。此外，别让同一套采样策略顺手把评测（eval）和训练数据回流的数据源也砍了，那属于另一条链路，需要单独设定。
对普通职场人来说，这也解释了一个常见困惑：用户投诉的那个偶发 bug，客服为什么查不到，很多时候不是没人管，而是那条日志早就被采样丢掉了。
具体产品的采样开关和配置项，以官方文档为准。