09. 如何说明一个项目真的有提升，而不是主观感觉变好了？
整理如何说明一个项目真的有提升，而不是主观感觉变好了？的面试回答思路与拆解方式。
简单回答
证明项目"真的有提升"需要三个要素：明确的评测指标（Recall@K、准确率、用户满意度等）、可对比的基线（优化前的指标值）、以及可复现的评测流程（固定的评测集和评测方法）。核心原则是用数据说话而不是用感觉，并且要区分"离线评测提升了"和"线上业务指标提升了"——两者不一定一致。
详细解释
为什么"感觉变好了"不靠谱
大模型应用的效果评估有一个典型陷阱：开发者自己测了几个 case 觉得效果好了很多，但实际上可能只是恰好测的那几个 case 变好了，其他 case 可能没变甚至变差了（这叫"回归"——优化了 A 场景却打坏了 B 场景）。
另一个陷阱是确认偏误——你做了优化，潜意识里希望它有效，测试的时候会不自觉地选择它表现好的 case 来"验证"。
正确的评估方法
建立评测集。 这是最基本也最重要的一步。从业务场景中收集有代表性的测试用例，标注正确答案。评测集应该覆盖各种问题类型、难度级别和边界情况。规模上几百条就够做量化分析，但要确保覆盖面够广。
评测集的来源：线上真实用户的提问（脱敏后）、人工构造的典型问题、已知的 bad case、以及刻意设计的边界 case（如否定性问题"产品 A 支不支持 X 功能"、知识库没覆盖的问题"你们有没有 Y 服务"）。
定义明确的评测指标。 指标要具体、可量化、可比较。"效果变好了"不是指标，"Recall@5 从 72% 提到 85%"是指标。
检索端用 Recall@K、MRR、NDCG。生成端用准确率（回答是否正确）、Faithfulness（是否忠实于上下文）、完整性（是否覆盖了问题的所有方面）。用户体验层面用用户满意度评分、Bad case 率（人工抽检的错误比例）。
记录基线。 在做任何优化之前先在评测集上跑一遍拿到基线数据。后续每次改动都在同一个评测集上跑，和基线对比。没有基线就没有"提升"可言——你连从哪里出发的都不知道，怎么说"走了多远"？
控制变量。 每次只改一个因素，验证它的独立效果。同时改了 Chunk 策略和 Embedding 模型，即使效果提升了也不知道是哪个改动贡献的。这在实际项目中可能做不到完全的单变量控制（时间紧任务重），但至少要有意识地记录每次改了什么。
做回归测试。 优化了某个方面后，要检查其他方面有没有退步。比如优化了表格类问题的处理后，要检查普通文本问题的效果是不是还正常。
离线评测 vs 线上评测
离线评测在固定的评测集上做，结果可复现、可对比。但离线评测集可能不完全代表真实用户的使用模式——评测集的问题分布、长度分布、难度分布可能和线上不一样。
线上评测用真实的用户数据，更接近实际效果。常见方式有：A/B 测试（新旧版本各服务一部分用户，对比用户行为指标）、线上抽检（从线上请求中随机抽样做人工评测）、用户反馈（点赞/点踩、满意度评分）。
最靠谱的方式是离线评测和线上评测结合——离线评测做快速迭代（每次改动跑一遍评测集），通过离线评测的版本再做线上 A/B 测试确认。
用 LLM-as-Judge 做自动化评测
人工评测最可靠但成本高。用一个强 LLM（如 GPT-4o）作为"裁判"自动评分可以大规模化。但 LLM 评判有偏差，需要先在一个小样本上和人工评测做一致性校验（Cohen's Kappa > 0.7 通常可接受），确认一致性够高后才能用 LLM 评判替代人工。
面试时可以这样答
证明项目有提升要靠三个东西：评测集、基线和指标。先建一个有代表性的评测集，在做任何优化之前跑一遍拿到基线数据。每次改动后在同一个评测集上跑同样的指标，和基线对比。没有这三个东西，说"效果好了"就是主观感觉。
指标要具体——检索用 Recall@K，生成用准确率和 Faithfulness，用户体验用 bad case 率。不能只说"效果提升了"，要说"Recall@5 从 72% 到 85%，准确率从 78% 到 86%"。
离线评测做快速迭代，通过离线评测的版本再做线上 A/B 确认。还要做回归测试——优化了 A 类问题不能打坏 B 类问题。
自动化评测可以用 LLM-as-Judge，但要先和人工评测做一致性校验，确认 LLM 的评判足够可靠。
常见追问
- 你的评测集有多大？怎么保证它有代表性？
- 如果离线评测提升了但线上 A/B 没有提升，可能是什么原因？
- LLM-as-Judge 的评分和人工评分一致性能到多少？