面试题 · 评估
搜索「检索」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
RAG 最终上下文不准确时，如何定位到原文、解析、权限、检索、排序或组装，并怎样设计数据集与质量控制？
保存查询、身份/租户、可见范围、原文与知识快照、解析/切分/嵌入/索引版本、各路候选、过滤原因、融合与重排结果、最终上下文和答案。没有相同条件，两次结果差异不能归因。涉及客户数据时先最小化和脱敏。
用人工核验且有权查看的证据替换检索结果，可以区分检索/组装和生成；固定候选开关重排，可以测排序净影响。
学习内容与项目面试，在同一条路上。
先按文档/客户或时间切分，再去重和增强，避免同一来源片段泄漏到不同集合。标注指向原文证据范围、版本和权限条件，记录分歧与仲裁。自动合成可补覆盖，但要检查模板痕迹和与真实流量差异。
来源准入依据权威性、许可、适用范围、版本和业务用途，不用“只保留两年”这类统一时效阈值；历史法规或旧版本有时正是问题答案。分块长度和 overlap 由结构与评测决定，不固定 256–512 token。
监控采集完整率、解析失败、重复、索引版本差、权限/删除传播、候选覆盖、组装证据保留和坏例分布。抽检比例由风险、错误率估计和复核能力决定，不固定每周 5%。
低分反馈进入待审队列，核验许可、身份、证据和标签后再进入开发或监控集；不能自动成为训练/评测真值。
原文错就修来源和版本；解析错就修解析；候选漏失再改检索；候选已有但顺序差才改重排；上下文正确但回答错再处理生成。不存在“先数据、再检索、最后生成”的固定优先级，也不能用通用微调或 Self-RAG 掩盖具体根因。修复后在原 bad case、独立测试和相邻切片复验权限、质量、P95/P99、成本与回滚条件。
场景切入
假设你在做电商客服RAG，用户问“这款手机支持5G吗”，系统回了一段包含过时参数的上下文，结果答错了。你拿到这个bad case后会怎么一步步查问题？
层层追问
RAG系统上线后用户反馈答案不准，你一般怎么排查？……如果确定是上下文信息本身错了呢？……那你手头有哪些数据能帮你定位是知识库脏了、检索没召回到对的、还是模型没用好？
直球架构
请你设计一套RAG上下文准确性问题的诊断和修复方案。诊断层面要区分检索和生成两类根因，数据层面要列出你需要的开发集、对抗集、线上回流数据，并说明每类数据的质量怎么控制。
RAG 上下文不准时，我先冻结查询、身份和可见范围、知识快照、解析切分、嵌入索引、候选、重排、最终上下文与答案版本。条件不同就不能直接比较。
然后沿链路查：原文是否存在、有效且有权限；解析是否保留表格、否定和时间；更新删除和权限是否传播；候选资格有没有误拦或误放；各路融合是否重复或挤掉证据；重排和组装是否截断。只有上下文本身正确，才进入生成诊断。
数据集要区分开发、独立测试、挑战和线上监控。先按文档、客户或时间切分再去重，标签指向原文证据范围、版本和权限。用户低分只是取样线索，核验后才能入库。时效、chunk 长度和抽检比例都由来源和风险决定。
原文错就修原文，索引不一致就修传播，候选漏了才调检索。修复后在原 bad case、独立测试和相邻切片复验权限、质量、延迟与回滚。