为什么你的AI应用会对你撒谎?以及如何在用户发现之前抓住它

为什么你的AI应用会对你撒谎?以及如何在用户发现之前抓住它
我花了3-4周时间构建一个AI驱动的研究助手。
它可以提取文档、搜索网络、综合答案,并在几秒内回应。它令人印象深刻,但后来我想,在正式发布之前,像普通用户一样使用它,无论对我还是对Agent本身,在审查方面都会大有裨益。
然后我开始真正检查它的答案。
它大约有30%的时间是错误的。不是明显的错误——而是自信、流畅、权威地错误。它引用不存在的论文。它引用统计数字时数字错误。它描述一家公司的产品时仿佛还停留在2022年。
最可怕的部分?它从不说“我不知道”。
就在那一刻,我明白了:构建AI应用和构建值得信赖的AI应用是两个完全不同的问题。

自信的幻觉——幻觉实际意味着什么
“幻觉(Hallucination)”是行业内用来形容AI编造事实的术语。听起来很戏剧化,好像模型正在经历迷幻发作。但现实更为平淡,甚至在某些方面更令人不安。
大语言模型(LLM)并不像搜索引擎那样检索事实。它们不是在数据库中查找东西。它们是在数十亿文本片段上进行模式匹配,并生成统计上最可能的下一个词,然后下一个,再下一个。
想象一个从不承认自己没有学习的学生。被问到不知道的问题时,他们不会说“我不确定”。他们会用记忆中存留的碎片,构建出听起来最具说服力的答案,并充满自信地说出来。
模型在即将说出错误信息时,内部没有任何警报响起。它不像你那样体验不确定性。它只是……生成。
这不是一个会在下一版本中被修复的bug。这是这些系统运作方式的根本特性。围绕它进行构建才是我们的工作。

你的AI目前可能在撒谎的三种方式
在讨论解决方案之前,我们先让问题具体化。根据我构建和调试LLM(大语言模型)系统的经验,幻觉(Hallucination)往往分为三类。
1. 捏造的引用
让AI用来源支持某个论断时,它常常会凭空编造。期刊名字听起来很真实。作者名字听起来很真实。标题正是你希望找到的内容。但这篇论文并不存在。
我在自己的系统中发现了这个问题:当用户询问一个冷门医学课题的研究时,AI返回了四个格式精良的APA格式引用——但我一个都找不到。深入检索日志后,我发现模型没有找到强有力的匹配结果,于是从头生成了看似合理的参考文献来填补空缺。
2. 自信的错误数字
统计数据尤其危险。“研究表明,73%的……”这个句式模型已经见过成千上万次。它知道如何令人信服地完成它。但它不知道73是不是正确的数字。
在一次测试中,我问系统一个关于市场规模数字的问题。它返回的数字数量级都错了,但句子本身构造得如此精良,以至于我差点没注意到。
3. 过时信息被当作当前事实呈现
LLM(大语言模型)有训练截止日期。模型不知道自己在该日期之后对世界的哪些方面一无所知。因此,当被问及公司现任领导、产品当前价格或法律现行状态时——它会根据训练时的真实情况回答,没有任何“情况可能已发生变化”的提示。
你的用户不会知道这一点。他们会相信这个答案。

为什么RAG(检索增强生成)有帮助——但并不能完全解决问题
为什么你的AI应用会对你说谎?以及如何在用户发现之前抓住它 - DEV社区
在每个AI项目的某个阶段,总会有人说“用RAG就行”,仿佛这是万能的答案。检索增强生成(Retrieval-Augmented Generation)确实非常强大,但它并不是魔法修复,我想坦诚地谈谈它的不足之处。
以下是用通俗语言解释RAG的作用:它不再仅仅依赖模型在训练期间记忆的内容,而是给它一个可以查找资料的“图书馆”。当用户提出问题时,你首先在图书馆中搜索最相关的文档,然后将这些文档连同问题一起交给模型。这样,模型就能基于真实、当前、具体的信息来回答,而不仅仅是凭记忆。
这显著减少了幻觉,但并没有完全消除它们。
我在生产环境中遇到的失败模式:
-
检索失败。如果由于查询模糊或嵌入(embedding)未能捕获正确的语义含义,搜索结果返回了错误的文档——模型就会根据不相关的上下文来回答。垃圾进,垃圾出。
-
上下文窗口溢出。当你检索了太多片段时,较旧的片段会被挤出模型的注意力窗口。那些技术上“给予”模型的信息实际上就消失了。
-
混合搜索不匹配。纯语义搜索会遗漏精确的关键词匹配。纯关键词搜索会遗漏概念相似性。我使用BM25+语义搜索的组合,但针对你的特定领域调整两者之间的平衡需要真正的迭代。
-
模型忽略检索到的上下文。有时模型对某个主题有非常强的先验知识,以至于它会部分忽略你给出的内容,仍然从训练数据中填充答案。这个问题尤其难以捕捉。
RAG是必不可少的,但它并不足够。

如何真正抓住谎言:评估流水线解析?
大多数团队在这里掉链子——不是因为他们不在乎,而是因为评估看起来没有上线功能那么紧迫。但事实并非如此。用户每发现一次幻觉,就会造成信任赤字,而你需要花几个月才能恢复过来。
以下是我追踪的指标,以及每个指标为什么重要。
检索精度
在模型生成答案之前,我们是否检索到了正确的文档?我通过取一组已知的问答对,只运行检索步骤,然后检查正确的源文档是否出现在前几个结果中来衡量这一点。如果检索出了问题,再多的提示词工程也救不了你。
幻觉率
在大规模场景中衡量这一指标比较困难,但至关重要。我构建了一个独立的评估流水线,其中第二个LLM调用会检查生成的答案是否确实基于检索到的上下文。它并不完美,但能抓住最严重的捏造内容。当我第一次在我的系统上运行这个检测时,幻觉率是31%。经过三轮提示词迭代,我把它降到了8%以下。
p95延迟
可靠性和速度都是信任信号。一个系统虽然准确,但5%的时间超时,仍然会侵蚀信心。我追踪p95延迟(第95百分位的延迟——即最慢的用户实际体验到的延迟),因为平均值会隐藏对你伤害最大的异常值。
答案质量评分
除了事实正确性之外,我还运行A/B提示词测试,根据相关性、完整性和清晰度对输出进行评分。这更为主观,但随着时间的推移,信号是真实的。从模糊的系统提示词切换到精心结构化的提示词(包含少量示例),我的质量评分提高了约30%。
我用于所有这些工作的工具是LangSmith——它与LangChain配合使用,为你提供链中每一步的完全可观测性:检索了什么、传递给模型什么、返回了什么、每一步花了多长时间。如果你在构建严肃的LLM应用而不使用类似工具,那你就是在盲目飞行。

置信度评分与人工交接:最后一道防线
即使检索出色、评估仔细,某些查询也总会落在系统所知与用户所需之间的间隙中。对此,诚实的工程答案不是更努力地猜测,而是知道何时该停止猜测。
在构建我的研究助手时,我实现了基于置信度的人工交接。它的工作原理是:每个答案都附带一个置信度信号,该信号来源于检索文档与查询的匹配程度,以及模型答案与源材料的一致性。当置信度低于阈值时,系统不会返回潜在的错误答案,而是将该对话标记为需要人工审查,并通过 WebSocket 实时流式传输给人工代理,用户几乎察觉不到过渡。
我认为,这是目前应用 AI 领域最被低估的理念。
几十年来,我们一直在教导人类,承认不确定性是软弱的表现。但在 AI 系统中,情况恰恰相反。一个说“我对此不够自信,无法回答,让我为您连接能够回答的人”的系统,比一个自信地编造答案的系统要可靠得多。
将“我不知道”工程化到你的 AI 中不是后备方案。这是一项特性。
实用清单:在发布 AI 功能之前
如果你正在构建一个集成 LLM(大语言模型)的系统,以下是我认为在面向真实用户之前必须做到的事项:
-
首先构建评估数据集。 至少包含 50 个问答对,覆盖你的重要使用场景,包括边缘情况和已知的失败模式。在你能衡量任何东西之前,你需要这个数据集。
-
将检索精度与生成质量分开衡量。 不要将它们混为一谈。糟糕的答案可能是检索失败,而不是模型失败——它们需要不同的修复方式。
-
使用自动化检查器跟踪幻觉率。 不完美但至关重要。即使是一个粗略的信号,也能告诉你随着迭代,情况是变好还是变坏。
-
设置置信度阈值。 提前决定系统在不确定时该做什么。转接给人类,返回“找不到可信答案”的消息,或者至少将响应标记为低置信度。
-
在生产环境中监控,而不仅仅是在测试中。 真实用户的查询会让你大吃一惊。真实用户的查询会破坏你测试集从未设想过的事情。从第一天起就设置日志记录。
-
在任何提示词被视为“完成”之前,运行提示词的 A/B 测试。 你的第一个系统提示词几乎肯定不是最好的一个。像对待代码一样对待它——迭代、衡量、改进。
令人不安的真相
我们正处在一个比以往任何时候都更容易看起来构建了智能东西,但比以往任何时候都更难实际构建出可信赖东西的时刻。一个令人印象深刻的演示与一个能够赢得长期用户信任的产品之间的差距,正是本文所讨论的差距。
那些缩小这个差距的团队——那些在系统出现问题之前就构建评估流水线的团队,那些像重视运行时间一样重视幻觉率的团队,那些从一开始就将“我不知道”设计到系统中的团队——正是那些构建的 AI 产品在两年后仍然拥有用户的团队。
其他人则是在构建演示。