背景情况 登陆页面上的支持聊天器将知识库的内容作为LLM的系统提示,然后让它回答用户的任何要求.
在实际操作中,“准确回答”这样的通用指令并没有包括:同样的似是而非的错误, LLM吸收了大量的一般技术知识.
这正是为什么,当它问到什么的时候, 它倾向于把一般的知识结合到 一个听起来完全令人信服的答案。
棘手的一点是,答案足够令人信服,即错误是很难发现的。
例1:猜测主机提供者的 SSH 主机名格式 当一个用户问起"我不知道我的SSH主机名"时,一个LLM被诱惑去倚靠一般模式,提供类似"它通常格式化为这样和这样"的东西.
并且公平地说,一些主机供应商确实有典型的主机名惯例.
但这是一种危险的帮助。
实际格式因托管提供者,计划层级,甚至合同年代的不同而不同——有时甚至在同一提供者内部跨出不同的计划.
提供"通用格式"的LLM无法保证它与这个特定用户的实际合同相匹配.
如果这是错误的,用户最后在原作的上方出现了一种新的混乱:"我仔细地看了一下应用程序告诉我的地方,却不在那里".
正确的答案是"检查您主机提供者的控制面板的SSH连接细节,并复制那里显示的确切字符串"——而不是被猜测的格式样本.
但是,不提供特定格式是正确动作的判断并不是一个通用的"准确回答"指令本身可靠产生的.
例2:一个可信但错误的"你需要转换这个"指令 另一个案例涉及我们所支持的一个托管提供者发布的私人密钥格式.
这些密钥以PKCS#8格式发布,自1.6.3版本起,该app在本地读取了该格式,没有额外的步骤.
但如果一个LLM只得到一个"我的私人密钥不会加载"的问题,它可以达到一般的SSH知识,并提出一些可能存在但错误的东西,比如"你可能需要将其转换为PuTTY格式(.ppk)"——这个步骤既没有必要,也超出了当前版本的要点.
这种模式是一样的:这个建议听起来很有帮助,在技术上是连贯的,但对这个产品来说是完全不正确的。
正确的答案是远为简单的"更新应用到最新版本,然后将其指向已下载的密钥文件为-is"——但LLM发现通用转换程序更可信.
单是普通指示,何以不足以像"准确回答"或"你不知道的时候不要猜"这样的指令,可以写出一次,前行,系统即时.
但是它们过于抽象,无法捕捉到这样的单个陷阱.
从模型的角度来看,无论是猜测主机名格式还是描述密钥转换程序都是"一般正确的技术知识"——在抽象的指令中没有任何迹象表明,这种特定产品的情况使得这种普遍正确的知识在这里是错误的.
固定点:将目标明确的修正放在陷阱旁边。
我们采取的方法是,在某一问题和事实所在的知识库的确切位置直接附上一个说明——最终用户看不见的说明。
在相关的FAQ条目旁边,有一个注释说,实际上,“当这个问题出现时,模型往往会在这里犯一个似是而非的错误;实际的答案是这个。” 与其说一个抽象的"不要产生幻觉"规则在一个单一的地方,这个想法更接近在实际发生错误的每一个特定地点进行定向接种.
每当一个新的陷阱浮出水面, 便会在那个位置上加注。
实际上,一堆小的、局部的校正对真实的解答质量来说比一次扫荡更有用