题目结构说明：每题四部分。考点定位讲面试官在筛什么；深拆把机制、数字、失败模式摊开；工程方案给可直接口述的伪代码或指标表；追问链是答完后 80% 会跟上的问题，附答法。标记：⭐ 高频（出现率过半）、🔥 近两年新增。Q1 LLM 应用的 tracing：span 怎么设计，一个请求记什么 ⭐考点定位：考后端分布式追踪常识能不能迁移到 LLM，再补特有维度。最常见的错误答案是「prompt 和回答全量记下来」，一答就暴露没考虑过存储和隐私。深拆：沿用 OpenTelemetry：请求是 root span，下挂 retrieval、llm_call、tool_call 子 span，trace_id 全链路透传。文本全量存失败三路：存储爆炸（一次 RAG 请求原始 IO 几十 KB，日百万请求就是 TB 级）、隐私泄漏、排查信息过载。正确做法：span 只记元数据，全文常规采 1% 到 5%，高风险场景全存；延迟拆 TTFT 和 TPOT 分开记，前者涨是排队，后者涨是吞吐。工程方案：span = { "trace_id": ctx.trace_id, # 全链路透传，跨服务不断链 "kind": "llm_call", # root / retrieval / llm_call / tool_call "model": "qwen3-32b@2026-06", # 模型名+快照版本，变更归因的钥匙 "prompt_tpl": "rag_chat_v7", # 记模板 id，不记全文 "in_tokens": 1820, "out_tokens": 340, "ttft_ms": 412, "tpot_ms": 28, # 首 token 延迟/逐 token 间隔 "truncated": False, # 上下文是否被截断，幻觉高发标记 "prompt_hash": sha1(prompt)[:12], # 哈希代替全文，撞上问题再回捞 } if random() 0.03 or scene in HIGH_RISK: # 常规采 3%，高风险全存 object_store.put(f"trace/{span['trace_id']}", raw_io)追问链：「Agent 几十步循环 span 会爆炸吗？」- 按 kind 折叠展示，另记 step_count 和去重工具序列做摘要。「版本号为什么重要？」- 线上劣化第一嫌疑永远是变更，没有 model 和 prompt 版本就无从对时间线。Q2 在线评估：不能每条都人评，线上质量怎么持续监控 ⭐考点定位：检验你有没有评估预算意识。人评一条几块钱、天级延迟，全量不现实；只看延迟成本又看不见质量，考分层：哪些信号免费全量，哪些抽样付费。深拆：第一层规则全量零成本：黑词、格式 schema 校验、长度异常（超 3 倍 P95）、空回复，拦 60% 到 80% 的硬伤。第二层代理指标全量：引用数、检索命中数、行为信号，便宜但和真实质量只是相关不是因果。第三层人评分层抽 1% 到 5%，高风险场景全量。失败模式是古德哈特定律：优化「平均回答长度」这类代理指标后长度涨了质量没动，模型学会注水，所以代理指标只做趋势，质量结论以抽样人评为准，同数据质量监控：硬校验全量、内容抽样。工程方案：def route_for_eval(req): if rules_hit(req): # 规则层全量：黑词、格式、空回复 return "rule_flag" if req.scene in HIGH_RISK: # 支付、医疗等场景全量人评 return "human_full" if hash(req.user) % 100 2: # 分层抽样：场景 x 模板分桶，桶内各抽 2% return "human_sample" return "metrics_only" # 其余只记代理指标，不进质量口径
LLM 应用可观测性与评估：线上篇（10 题）
题目结构说明：每题四部分。考点定位讲面试官在筛什么；深拆把机制、数字、失败模式摊开；工程方案给可直接口述的伪代码或指标表；追问链是答完后 80% 会跟上的问题，附答法。标记：⭐ 高频（出现率过半）、🔥 近两年新增。Q1 LLM 应用的 tracing：span 怎么设计，一个请求记什么 ⭐考点定位：考后端分布式追踪常识能不能迁移到 LLM，再补特有维度。最常见的错误答案是「prompt 和回答全量记下来」，一答就暴露没考虑过存储和隐私。深拆：沿用 OpenTelemetry：请求是 root span，下挂 retrieval、llm_call、tool_call 子 span，trace_id 全链路透传。文本全量存失败三路：存储爆炸（一次 RAG 请求原始 IO 几十 KB，日百万请求就是 TB 级）、隐私泄漏、排查信息过载。正确做法：span 只记元数据，全文常规采 1% 到 5%，高风险场景全存；延迟拆 TTFT 和 TPOT 分开记，前者涨是排队，后者涨是吞吐。工程方案：span = { "trace_id": ctx.trace_id, # 全链路透传，跨服务不断链 "kind": "llm_call", # root / retrieval / llm_call / tool_call "model": "qwen3-32b@2026-06", # 模型名+快照版本，变更归因的钥匙 "prompt_tpl": "rag_chat_v7", # 记模板 id，不记全文 "in_tokens": 1820, "out_tokens": 340, "ttft_ms": 412, "tpot_ms": 28, # 首 token 延迟/逐 token 间隔 "truncated": False, # 上下文是否被截断，幻觉高发标记 "prompt_hash": sha1(prompt)[:12], # 哈希代替全文，撞上问题再回捞 } if random() 0.03 or scene in HIGH_RISK: # 常规采 3%，高风险全存 object_store.put(f"trace/{span['trace_id']}", raw_io)追问链：「Agent 几十步循环 span 会爆炸吗？」- 按 kind 折叠展示，另记 step_count 和去重工具序列做摘要。「版本号为什么重要？」- 线上劣化第一嫌疑永远是变更，没有 model 和 prompt 版本就无从对时间线。Q2 在线评估：不能每条都人评，线上质量怎么持续监控 ⭐考点定位：检验你有没有评估预算意识。人评一条几块钱、天级延迟，全量不现实；只看延迟成本又看不见质量，考分层：哪些信号免费全量，哪些抽样付费。深拆：第一层规则全量零成本：黑词、格式 schema 校验、长度异常（超 3 倍 P95）、空回复，拦 60% 到 80% 的硬伤。第二层代理指标全量：引用数、检索命中数、行为信号，便宜但和真实质量只是相关不是因果。第三层人评分层抽 1% 到 5%，高风险场景全量。失败模式是古德哈特定律：优化「平均回答长度」这类代理指标后长度涨了质量没动，模型学会注水，所以代理指标只做趋势，质量结论以抽样人评为准，同数据质量监控：硬校验全量、内容抽样。工程方案：def route_for_eval(req): if rules_hit(req): # 规则层全量：黑词、格式、空回复 return "rule_flag" if req.scene in HIGH_RISK: # 支付、医疗等场景全量人评 return "human_full" if hash(req.user) % 100 2: # 分层抽样：场景 x 模板分桶，桶内各抽 2% return "human_sample" return "metrics_only" # 其余只记代理指标，不进质量口径
