周三下午，你的RAG系统刚刚上线。产品经理说"看起来不错"，你松了口气。两周后，客服工单爆了——系统在教用户删除生产数据库。你翻日志发现，向量检索确实找到了正确的API文档，但大模型把"请勿执行"理解成了"立即执行"。这不是bug，这是幻觉。而你的测试套件里，没有任何一行代码在检测这个问题。
2026年的企业级AI开发，"能跑通demo"和"能上线"之间隔着一道鸿沟：可量化的真实性验证。Spring AI 1.2带来的Evaluator框架，正在把这道鸿沟填平。
大多数开发者在这件事上栽跟头，原因出奇地一致。首先是"看起来没问题"陷阱——依赖人工抽查，测试套件没有为"真实性"设定量化阈值，本质上是在等待生产事故。其次是混淆检索与准确性：向量搜索返回了正确的文档片段，不代表大模型不会把"否"幻觉成"是"。更隐蔽的是忽略上下文窗口——你根本没验证大模型是否真的使用了检索到的文档，还是纯粹从训练数据里编了一套答案。
行业正在转向LLM-as-a-Judge模式。Spring AI的评估框架把定性的"感觉"转化为硬指标。FaithfulnessEvaluator测量回复与检索文档的对齐程度；RelevancyEvaluator确保答案真正回应用户原始意图，而非关键词匹配。这些评估器直接嵌入JUnit 5生命周期，当真实性分数低于0.9阈值时构建失败。Spring AI Test Integration则提供成本可控的方案：CI流程中mock模型响应，用"黄金数据集"保证生产级测试覆盖。
具体实现上，你需要一个"裁判"模型（如GPT-4o或Claude 3.7）来审计"学生"模型的输出。代码层面，先构建FaithfulnessEvaluator实例，从向量存储执行相似性搜索获取上下文，调用RAG服务生成回复，封装为EvaluationRequest后执行评估。关键断言有两层：isPass()检测幻觉，getScore()要求分数高于0.95。这不是"差不多就行"，这是2026年的工程底线。
三个结论值得记住。第一，"感觉"不是策略——Faithfulness和Relevancy这类自动化指标是RAG规模化生产的唯一路径。第二，Spring AI简化了裁判模式，无需手写评估用的prompt模板，Evaluator API封装了复杂逻辑。第三，用分数门禁部署流程——如果staging环境的真实性分数衰退，构建必须失败。幻觉不会自己消失，但你可以让它在到达用户之前被拦截。
热门跟贴