PIPELINE简而言之
语言模型生成文本的可能延续。它没有“我不知道”的概念——它只有概率。一个听起来合理的错误答案对模型来说无法与正确答案区分。
01
为什么会发生
语言模型生成文本的可能延续。它没有“我不知道”的概念——它只有概率。一个听起来合理的错误答案对模型来说无法与正确答案区分。
02
什么无效
要求模型不要编造。这会稍微降低频率，但无法消除问题。
03
有帮助的做法
三件事组合：只允许从经过验证的来源提供答案，在答案中标注来源，并为找不到内容的情况提供明确的退出机制。第三点最重要，也最常被忽略。
04
上线前的测试
提出答案不在文档中的问题。构建良好的机器人会说它不知道，并进行转接。构建不良的会编造内容——这会在客户那里被发现。
05
实践中的一个例子
没有来源绑定的聊天机器人在回答关于某个保修期限的问题时，给出了一个听起来合理但错误的数字——直到客户依此主张权利时才有人发现。如果有来源绑定，机器人要么会从保修条款中引用正确期限，要么会诚实地说它不知道。
问题
常见问题
更新的模型不是更擅长不编造吗？
它们确实更好，但问题从根本上依然存在——这不是模型版本的问题，而是工作原理的问题。没有来源绑定的系统总会偶尔编造内容，无论它有多新。
实践中这种情况多久发生一次？
在没有对策的情况下，遇到复杂或罕见问题时会明显频繁。通过严格的来源绑定和明确的退出机制，发生率会降至很低的水平，此时几乎所有剩余情况都会被捕获为“我不知道”而非错误断言。
可以在现有系统中事后加装吗？
可以，大多数情况下无需全部重建。来源绑定和明确的退出机制可以加装到现有配置中——工作量主要在测试，而非重建。
如何系统地测试这一点，而不是只尝试几个问题？
使用一份包含真实请求的固定列表，其中特意包含一些答案不在文档中的问题。每次更改后重新运行这份列表——这就是随机抽样与真正测试的区别。
下一步
让我们简短讨论一下这对您是否划算。
二十分钟的对话通常就足以弄清一个项目是否有意义。如果没有，我们会直说——这对双方来说都比一份无人需要的报价更便宜。