本文目录
适合做过 RAG 评测的人，重点练评测数据怎么来、指标怎么算、错误怎么定位，以及怎样持续改进。
教学示例：先换成自己的真实项目描述，再逐题练习。下面保留完整追问分支、检查重点与评分规则。
页面加载中…
求职指南 · 简历项目模拟面试
适合做过 RAG 评测的人，重点练评测数据怎么来、指标怎么算、错误怎么定位，以及怎样持续改进。
适合做过 RAG 评测的人，重点练评测数据怎么来、指标怎么算、错误怎么定位，以及怎样持续改进。
教学示例：先换成自己的真实项目描述，再逐题练习。下面保留完整追问分支、检查重点与评分规则。
学习内容与项目面试，在同一条路上。
负责【真实 RAG 场景】评测体系，承担【样本、标注、指标或平台模块】。
需要准备：个人职责；样本来源；评测工件。
建立【真实评测集与指标】，定位【真实失败类型】并验证【真实改动】。
需要准备：指标与基线；样本切片；失败分类；验证结果。
简历原句是“【自己的真实项目描述】”。评测定义、样本收集、标注规范、平台实现和结果复核分别由谁完成？
考察重点：核验项目所有权，避免把团队或平台成果当作个人成果。
需要追加追问时：ownership_ambiguous → ownership-proof。
下一步：design。
配套学习：评测数据集怎么选?。
请展示一项可脱敏的标注规范、样本版本、评测脚本变更或评审结论，证明职责和决策。
考察重点：用可脱敏工件交叉验证职责，而不是继续听抽象表述。
下一步：design。
配套学习：项目难题怎么定位与解决?。
评测集如何从线上日志、专家样本和合成样本构建？如何去重、分层、冻结版本并避免泄漏？
考察重点：确认候选人理解端到端链路、关键接口和状态变化。
下一步：tradeoff。
配套学习：评测数据集怎么选?、大模型任务表现差怎么排查？。
哪些指标自动计算，哪些必须人工或模型评审？为什么不只用一个端到端正确率？
考察重点：验证选型来自真实约束和对比，而不是技术名词堆砌。
下一步：metrics。
配套学习：自动 vs 人工评价怎么选?、大模型应用怎么保障可靠性?。
Recall@k、排序、faithfulness、答案正确性、拒答和业务指标各怎么定义？基线与样本量是多少？
考察重点：核验效果数字是否有定义、基线、样本和可归因证据。
需要追加追问时：metric_undefined → metrics-proof；baseline_missing → metrics-proof；evaluation_set_missing → metrics-proof。
下一步：failure。
请给出评测集版本、样本来源占比、标注规范和评测器版本；若这些无法固定，就不能把两次报告直接当作提升。
考察重点：二次核验缺失的指标证据；仍无法提供时，在复盘中标记为“只有知识，没有项目事实”。
下一步：failure。
选一个 bad case，从原查询、权限、候选、重排、上下文到答案逐层定位；证据怎样排除其他根因？
考察重点：确认候选人见过方案边界，并能完成证据驱动的失败复盘。
需要追加追问时：failure_case_missing → failure-proof。
下一步：production。
配套学习：RG 系统效果差怎么排查?、检索准但生成差，怎么调优？。
请从一个 bad case 的查询、权限、候选、重排、上下文与答案逐层贴证据，并说明怎样排除至少一个竞争根因。
考察重点：要求用可回放材料证明失败复盘；若只有假设分析，必须与真实事故或 bad case 明确区分。
下一步：production。
配套学习：RG 系统效果差怎么排查?、检索准但生成差，怎么调优？。
评测如何进入发布门禁和线上监控？数据漂移、标注分歧、回归失败时怎样阻断或回滚？
考察重点：验证系统是否真实上线，并具备监控、灰度和回滚能力。
需要追加追问时：evaluation_set_missing → production-proof；production_evidence_missing → production-proof；rollback_missing → production-proof。
下一步：extension。
配套学习：大模型应用怎么保障可靠性?。
请拿一次发布门禁记录，说明数据版本、评测器版本、失败切片、阻断结论和回退动作；没有记录就不要声称评测已经进入生产流程。
考察重点：核验生产事实与设计知识的边界；没有线上材料时，只按设计能力记录，不视为上线经历。
下一步：extension。
配套学习：大模型应用怎么保障可靠性?。
如果业务新增多语言和多租户，怎样保持不同切片可比，同时避免客户数据进入错误评测集？
考察重点：测试约束变化后的迁移、容量和风险判断能力。
配套学习：Agent 如何防越权与隐私泄露?。
dimension：ownership
0：只会复述团队目标，无法说明本人职责。
1：能说出参与模块，但职责边界和决策权不清。
2：能区分本人、同事和平台职责，并给出实现证据。
3：职责、决策、协作边界和可核验工件完整一致。
dimension：chain-understanding
0：只罗列技术名词，讲不清数据如何流动。
1：能描述主流程，但关键接口和状态变化含糊。
2：能画清端到端链路，并解释关键输入输出。
3：能说明线上日志、专家样本和合成样本如何去重、分层、冻结并进入各级评测。
dimension：tradeoff
0：只说方案先进或效果好，没有备选比较。
1：知道一个备选方案，但说不清真实约束。
2：能结合质量、时延、成本或维护性解释选择。
3：有候选对比、实验或决策记录，并能说明放弃条件。
dimension：metric-credibility
0：只有提升结论，没有指标定义和基线。
1：有数字，但缺评测集、统计窗口或口径。
2：指标、基线、样本和统计口径基本完整。
3：能核对数据版本、标注规范、评测器版本、分歧处理和泄漏检查，而非只报一个总分。
dimension：failure-review
0：声称没有失败案例或只归因于模型能力。
1：能举失败现象，但没有复现和根因证据。
2：能给出代表性坏例、定位过程和修复验证。
3：有失败分类、复现材料、反事实验证和遗留边界。
dimension：production-engineering
0：只讲离线 Demo，不了解上线约束。
1：知道监控或降级概念，但没有具体阈值。
2：能说明时延、容量、监控、灰度和回滚。
3：能用发布门禁、回归报告、漂移看板与版本回退记录证明评测真实参与上线。
dimension：consistency
0：前后职责、数字或架构明显冲突。
1：主要结论一致，但追问后口径频繁变化。
2：事实、指标和方案在多轮回答中保持一致。
3：能主动声明不确定项、版本变化和证据边界，回答可交叉核验。
dimension：metric-credibility
能给出样本版本、标注规则和指标公式。
dimension：failure-review
坏例能沿链路复现并用对照排除根因。
dimension：production-engineering
评测阈值真实进入发布门禁。
dimension：metric-credibility
评测集完全由同一模型生成和打分。
dimension：consistency
不同版本更换样本却直接比较分数。
dimension：failure-review
只展示成功样本，不保留退化切片。