字节云后端一面：实习与 Agent 评测，收尾问时序数据库和 metrics

《面试题目》

1. 实习期间主要做了哪些事情？
2. Agent 的评测体系是怎么搭的？从哪些维度评价一个 Agent 的好坏？
3. 评测集从哪里来？怎么保证评测结果可信？
4. 时序数据库了解吗？它和普通关系型数据库的设计差异在哪？
5. metrics 监控体系怎么设计？哪些指标值得采集？
6. 线上服务出现抖动时，你会怎么用时序指标定位问题？

《参考解析》

Agent 评测：不要只答“看回答对不对”。一个可落地的评测体系通常分四层：结果层看任务成功率、答案正确性与格式合规；过程层看工具选择是否正确、参数是否合法、调用步数与轨迹是否合理；成本层看端到端时延、token 消耗与工具调用次数；体验层看多轮一致性、拒答与澄清是否恰当。确定性强的部分（工具名、参数 schema、是否越权、是否超时）写成规则断言，语义部分用 LLM-as-judge 加人工抽检校准，避免裁判模型与被测模型同源带来的偏置。评测集要覆盖正常路径、边界输入、对抗输入和线上坏例回流，每次线上事故都要沉淀成回归样本。

评测可信度：样本要分层——核心回归集小而稳定，业务场景集按域组织，探索集放新能力；每条样本记录输入、期望、约束和来源。跑评测时固定模型版本、温度、工具版本与提示词版本，否则结果不可复现。指标上除了均值还要看分位数和失败分布，几十条样本的 2% 提升没有统计意义，应该报置信区间或做多次重跑。

时序数据库：它的数据模型是“时间戳 + 标签集合 + 数值”，写多读少、按时间追加、几乎不更新。设计上会做列式存储与时间分区、按标签建倒排索引、对历史数据做降采样与冷热分层，并用压缩编码（差值、Gorilla 等）降低存储。关系型数据库擅长事务与复杂关联，时序库擅长高吞吐写入和按时间窗口聚合，二者不是替代关系。选型时要关注基数问题：标签组合过多会让索引膨胀，用户 ID、请求 ID 这类高基数字段不能随便做标签。

metrics 与排障：指标按 USE（利用率、饱和度、错误）和 RED（请求速率、错误率、耗时）两套框架铺开，服务端至少覆盖 QPS、P50/P95/P99 延迟、错误码分布、线程池与连接池水位、GC 次数与停顿、下游依赖耗时。排障时先看时间对齐：把故障时间点与发布、配置变更、流量突增对齐，再按依赖链路逐跳对比 P99，区分是自身变慢还是下游拖累。指标只能告诉你“哪里异常”，具体原因还要结合日志与 Trace，三者用同一个 request ID 串起来。