本文目录
适合简历中写过企业知识库或 RAG 项目的人，重点练自己负责的部分、项目架构、检索效果和上线问题。
教学示例：先换成自己的真实项目描述，再逐题练习。下面保留完整追问分支、检查重点与评分规则。
页面加载中…
求职指南 · 简历项目模拟面试
适合简历中写过企业知识库或 RAG 项目的人，重点练自己负责的部分、项目架构、检索效果和上线问题。
适合简历中写过企业知识库或 RAG 项目的人，重点练自己负责的部分、项目架构、检索效果和上线问题。
教学示例：先换成自己的真实项目描述，再逐题练习。下面保留完整追问分支、检查重点与评分规则。
学习内容与项目面试，在同一条路上。
负责【真实业务场景】企业知识库 RAG，承担【真实职责】，交付【真实工件】。
需要准备：真实业务目标；个人职责边界；可核验工件。
在【固定评测集】上将【真实指标】从【真实基线】改善到【真实结果】，同时满足【时延或成本约束】。
需要准备：指标定义；评测集来源；基线与结果；工程代价。
简历原句是“【自己的真实项目描述】”。这条链路中哪些部分由你独立完成，哪些来自同事、云服务或既有平台？
考察重点：核验项目所有权，避免把团队或平台成果当作个人成果。
需要追加追问时：ownership_ambiguous → ownership-proof。
下一步：design。
配套学习：项目难题怎么定位与解决?。
请拿一个可脱敏的设计记录、提交、评审结论或故障处理动作，说明它如何证明你刚才的职责。
考察重点：用可脱敏工件交叉验证职责，而不是继续听抽象表述。
下一步：design。
配套学习：技术项目怎么讲出亮点?。
从请求进入开始，依次讲清鉴权、查询处理、召回、重排、上下文组装、生成、引用和返回的数据流。
考察重点：确认候选人理解端到端链路、关键接口和状态变化。
下一步：tradeoff。
配套学习：RAG 原理与核心架构、RAG 数据处理与索引流程?。
为什么采用这套 RAG 架构，而不是关键词搜索、直接长上下文、微调或更简单的问答流程？
考察重点：验证选型来自真实约束和对比，而不是技术名词堆砌。
下一步：metrics。
你所说的效果改善具体是哪一个指标？基线、评测集、样本量、统计窗口和单变量实验分别是什么？
考察重点：核验效果数字是否有定义、基线、样本和可归因证据。
需要追加追问时：metric_undefined → metrics-proof；baseline_missing → metrics-proof；evaluation_set_missing → metrics-proof；ablation_missing → metrics-proof。
下一步：failure。
配套学习：召回策略怎么选? Recall@k 怎么看?。
先暂停提升结论。请把评测集版本、指标公式、基线配置和各模块消融记录逐项补齐；哪一项拿不出可核验记录？
考察重点：二次核验缺失的指标证据；仍无法提供时，在复盘中标记为“只有知识，没有项目事实”。
下一步：failure。
配套学习：召回策略怎么选? Recall@k 怎么看?。
哪类查询在新方案里仍然失败，甚至比旧方案更差？你如何复现、归因并决定修复还是拒答？
考察重点：确认候选人见过方案边界，并能完成证据驱动的失败复盘。
需要追加追问时：failure_case_missing → failure-proof。
下一步：production。
配套学习：RAG 查不到文档怎么降级?。
请用一条可脱敏查询，按原始候选、重排结果、上下文和最终答案回放。若没有记录，请明确这是设计分析而非已发生事故。
考察重点：要求用可回放材料证明失败复盘；若只有假设分析，必须与真实事故或 bad case 明确区分。
下一步：production。
配套学习：RAG 查不到文档怎么降级?。
上线时的 P95 延迟、峰值 QPS、单次成本、知识更新、监控、降级和回滚条件分别是什么？
考察重点：验证系统是否真实上线，并具备监控、灰度和回滚能力。
需要追加追问时：production_evidence_missing → production-proof；rollback_missing → production-proof；scale_unverified → production-proof。
下一步：extension。
配套学习：Agent 中 RAG 瓶颈怎么破?。
请区分“做过上线”和“知道怎么上线”：给出一个可脱敏监控、灰度或回滚记录，并说明当时的文档量与请求规模；没有记录就按设计题回答。
考察重点：核验生产事实与设计知识的边界；没有线上材料时，只按设计能力记录，不视为上线经历。
下一步：extension。
配套学习：Agent 中 RAG 瓶颈怎么破?。
如果数据量扩大十倍并增加多租户权限，现有索引、缓存、过滤和容量方案要怎样重构？
考察重点：测试约束变化后的迁移、容量和风险判断能力。
配套学习：垂直领域 RAG 完整架构。
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：能用真实监控和灰度记录解释文档量、峰值 QPS、知识更新、降级与回滚。
dimension：consistency
0：前后职责、数字或架构明显冲突。
1：主要结论一致，但追问后口径频繁变化。
2：事实、指标和方案在多轮回答中保持一致。
3：能主动声明不确定项、版本变化和证据边界，回答可交叉核验。
dimension：ownership
能用设计记录和变更说明本人职责。
dimension：metric-credibility
指标、基线、评测集和消融口径一致。
dimension：production-engineering
能给出灰度、监控、降级和回滚证据。
dimension：ownership
把团队或云平台能力全部说成个人实现。
dimension：metric-credibility
只给提升比例，不说明样本与统计口径。
dimension：failure-review
声称线上没有坏例或无法展示失败切片。