完整题目
请反思你所参与项目的局限性或未解决的问题，分析其根本原因并提出可能的改进方向。
用真实失败证据做项目复盘
回答只填写本人确实参与的项目：
- 项目目标为【】，本人职责为【】，当前结果以【指标、数据版本和观察窗口】衡量。
- 主要局限是【失败切片或系统瓶颈】，证据来自【错误样本、日志、用户反馈或消融】。
- 根因候选包括【数据、检索、模型、工具、交互或部署】，通过【对照实验】排除【】，目前最支持的是【】。
- 已尝试【方案】，结果【】，副作用【】；下一步以【最小实验】验证。
- 若无法在预算内解决，采用【回退、拒答、人工或权限限制】控制风险。
RAG 项目要拆分 retrieval recall/precision、证据进入上下文、context utilization、faithfulness、最终任务成功和延迟成本。召回提高可能带来更多噪声，但并不存在“召回和幻觉天然此消彼长”的定律。top-k、重排、上下文组织、模型能力和任务分布共同决定结果，必须用同一评测集做曲线。
不得补写候选人的召回率、优化周期和涨点。一个有说服力的局限，来自可复现失败、根因证据和明确的风险边界。
继续追问 · 3 个问题
- 如果重来一次，哪个决策你会最早改变？
- 这些改进方案中，哪些因为资源约束被迫放弃，如何权衡？
- 团队对这些问题认知是否一致，如何推动改进落地？
换一种问法，检查是否真正理解
场景切入
假设现在一个 RAG 系统在多条件问题上经常答错，但单跳问答正常。你会怎样把链路拆开，确定问题来自覆盖、召回、重排、上下文还是生成？
层层追问
先看端到端正确率够吗？……怎样分别测检索覆盖和排序质量？……检索正确但答案错时查什么？……改动如何灰度、回滚并证明有效？
直球技术
请给出 RAG 复杂问题失败的分层诊断方案，覆盖数据、召回、重排、上下文构造、生成、引用与评测，并为每个根因匹配证据和修复。