RAG 项目有一个很奇怪的倾向：系统一旦答错，大家首先怀疑的总是模型。 这当然可以理解。模型是整套系统里最显眼的部分，也是最容易替换的部分。换一个模型，输出立刻就会变化；调整一下提示词，当天就能找到几个更好的答案。相比之下，整理文档、检查版本、设计测试，看起来既慢又不够聪明。它们很少在演示里制造惊喜，更多时候只是让一些错误不再发生。 但是呢，生产系统的质量，恰恰是在这些“稳”中体现的。要我说，一个 RAG 项目的工作大概是 50% 评测，40% 整理数据，8% 接入业务，最后 2% 才是模型训练。 这说的可能有点夸张了啊，但是实际上你想想是不是这样。我们喜欢优化模型，理论上说是“模型最重要”，实际上是因为它最容易给人进展感。 但是一评测，就会发现，这种令人舒服的模糊其实挺虚幻的：什么叫回答得不错？是找到了相关文档，就算不错？引用了真实页面，就算不错？还是答案必须使用当前有效的制度，保留原文中的限制条件，在材料不足时承认自己不知道？ 如果这些问题没有提前说清楚，每一次优化都只能依赖感觉。团队会拿几个熟悉的问题反复测试。新模型碰巧答得更顺，就认为它更好。至于它是否在其他...