本文目录
适合建设过大模型监控或 Trace 的人,重点练日志、指标、故障定位,以及如何避免同类问题再次发生。
教学示例:先换成自己的真实项目描述,再逐题练习。下面保留完整追问分支、检查重点与评分规则。
求职指南 · 简历项目模拟面试
适合建设过大模型监控或 Trace 的人,重点练日志、指标、故障定位,以及如何避免同类问题再次发生。
适合建设过大模型监控或 Trace 的人,重点练日志、指标、故障定位,以及如何避免同类问题再次发生。
教学示例:先换成自己的真实项目描述,再逐题练习。下面保留完整追问分支、检查重点与评分规则。
学习内容与项目面试,在同一条路上。
负责【真实大模型应用】可观测体系,承担【Trace、指标、日志或告警模块】。
需要准备:系统范围;个人职责;可观测工件。
通过【真实追踪或监控改动】定位【真实线上问题】,并用【真实记录】验证修复。
需要准备:事故时间线;根因证据;修复与回归;遗留风险。
简历原句是“【自己的真实项目描述】”。埋点规范、Trace 存储、仪表盘、告警和事故响应中哪些由你负责?
考察重点:核验项目所有权,避免把团队或平台成果当作个人成果。
需要追加追问时:ownership_ambiguous → ownership-proof。
下一步:design。
配套学习:Agent 系统哪些模块最易出问题?。
请用一个脱敏 Trace、告警规则、仪表盘或复盘行动项证明你的具体贡献。
考察重点:用可脱敏工件交叉验证职责,而不是继续听抽象表述。
下一步:design。
配套学习:项目难题怎么定位与解决?。
一次请求如何关联检索、重排、模型、工具和业务结果?Trace ID、span、版本与错误码怎样设计?
考察重点:确认候选人理解端到端链路、关键接口和状态变化。
下一步:tradeoff。
配套学习:Agent 系统哪些模块最易出问题?。
哪些信息进指标、日志、Trace 或样本仓?采样率、保留期、成本和隐私如何取舍?
考察重点:验证选型来自真实约束和对比,而不是技术名词堆砌。
下一步:metrics。
配套学习:Agent 如何防越权与隐私泄露?、工程化核心目标是什么?。
可用性、延迟、模型错误、检索空召回、工具失败和业务成功怎样关联?告警基线是什么?
考察重点:核验效果数字是否有定义、基线、样本和可归因证据。
需要追加追问时:metric_undefined → metrics-proof;baseline_missing → metrics-proof;evaluation_set_missing → metrics-proof。
下一步:failure。
请给出一个 SLI 的分子、分母、窗口和告警历史,并说明误报与漏报怎么复核;没有历史样本就不能证明阈值有效。
考察重点:二次核验缺失的指标证据;仍无法提供时,在复盘中标记为“只有知识,没有项目事实”。
下一步:failure。
选一次真实或演练事故,按时间线说明发现、定位、止损、根因验证和修复回归。
考察重点:确认候选人见过方案边界,并能完成证据驱动的失败复盘。
需要追加追问时:failure_case_missing → failure-proof。
下一步:production。
配套学习:项目局限性与改进方向、Agent 调用链路容错机制。
请按时间线回放一次真实或演练事故,关联告警、Trace、日志、版本和业务结果;若是演练,必须明确标注而非包装成线上事故。
考察重点:要求用可回放材料证明失败复盘;若只有假设分析,必须与真实事故或 bad case 明确区分。
下一步:production。
配套学习:项目局限性与改进方向、Agent 调用链路容错机制。
告警分级、值班、静默、Runbook、数据保留、脱敏、灰度观察和回滚如何落地?
考察重点:验证系统是否真实上线,并具备监控、灰度和回滚能力。
需要追加追问时:production_evidence_missing → production-proof;rollback_missing → production-proof;permission_risk → production-proof。
下一步:extension。
配套学习:Agent 系统哪些模块最易出问题?。
请拿一条告警或复盘行动项,说明负责人、时限、验证结果、采样与脱敏边界;没有闭环记录就不要声称事故机制已经落地。
考察重点:核验生产事实与设计知识的边界;没有线上材料时,只按设计能力记录,不视为上线经历。
下一步:extension。
配套学习:Agent 系统哪些模块最易出问题?。
若调用链跨多个团队且流量扩大十倍,采样、关联、权限、存储和查询怎样扩展?
考察重点:测试约束变化后的迁移、容量和风险判断能力。
配套学习:工程化核心目标是什么?。
dimension:ownership
0:只会复述团队目标,无法说明本人职责。
1:能说出参与模块,但职责边界和决策权不清。
2:能区分本人、同事和平台职责,并给出实现证据。
3:职责、决策、协作边界和可核验工件完整一致。
dimension:chain-understanding
0:只罗列技术名词,讲不清数据如何流动。
1:能描述主流程,但关键接口和状态变化含糊。
2:能画清端到端链路,并解释关键输入输出。
3:能用 Trace ID 与 span 关联检索、重排、模型、工具、版本、错误码和业务结果。
dimension:tradeoff
0:只说方案先进或效果好,没有备选比较。
1:知道一个备选方案,但说不清真实约束。
2:能结合质量、时延、成本或维护性解释选择。
3:有候选对比、实验或决策记录,并能说明放弃条件。
dimension:metric-credibility
0:只有提升结论,没有指标定义和基线。
1:有数字,但缺评测集、统计窗口或口径。
2:指标、基线、样本和统计口径基本完整。
3:能用 SLI 分子分母、统计窗口、告警历史与误报漏报记录说明阈值可信。
dimension:failure-review
0:声称没有失败案例或只归因于模型能力。
1:能举失败现象,但没有复现和根因证据。
2:能给出代表性坏例、定位过程和修复验证。
3:有失败分类、复现材料、反事实验证和遗留边界。
dimension:production-engineering
0:只讲离线 Demo,不了解上线约束。
1:知道监控或降级概念,但没有具体阈值。
2:能说明时延、容量、监控、灰度和回滚。
3:能用值班、Runbook、行动项闭环、采样、脱敏、灰度与回退记录证明可运营。
dimension:consistency
0:前后职责、数字或架构明显冲突。
1:主要结论一致,但追问后口径频繁变化。
2:事实、指标和方案在多轮回答中保持一致。
3:能主动声明不确定项、版本变化和证据边界,回答可交叉核验。
dimension:chain-understanding
能用同一 Trace 串起检索、模型、工具和业务结果。
dimension:failure-review
事故时间线包含反事实根因验证。
dimension:production-engineering
告警、Runbook、发布观察和回滚形成闭环。
dimension:metric-credibility
只有日志截图,没有指标基线和版本信息。
dimension:production-engineering
记录完整 Prompt 和用户数据却无脱敏权限。
dimension:failure-review
复盘只归因于模型不稳定,没有证据排除链路问题。