我是一名专注于文档自动化和信息提取领域的AI工程师。在这个行业中，使用大语言模型（LLM）会遇到许多挑战，其中之一就是幻觉问题。想象一下AI将发票金额从$1,000误读为$100,000，导致100倍的过付款。在面对这种风险时，防止幻觉成为构建强大AI解决方案的关键。以下是我在设计可能容易出现幻觉的解决方案时关注的一些主要原则。使用验证规则和“人类在环”在AI系统中有多种方式可以引入人为监督。
有时候，提取的信息总是会呈现给人类审查。例如，解析的简历可以在提交给申请追踪系统（ATS）之前显示给用户。更常见的是，提取的信息会自动添加到系统中，只有在出现潜在问题时才会标记给人类审查。任何AI平台的重要组成部分是确定何时包含人为监督。这通常涉及不同类型的验证规则：1. 简单规则，例如确保每行条目的总数与发票总额匹配。
2. 查找和集成，比如在会计系统中验证总金额与采购订单的一致性或验证付款细节与供应商以前的记录一致。这些过程是好的。但我们也不希望AI不断触发安全措施并强制人工干预。如果AI不断触发这些保护措施，幻觉就会破坏使用AI的目。小型语言模型
防止幻觉的一个解决方案是使用“小型语言模型（SLM）”，它们是“提取型”的。这意味着模型会将文档的部分标记出来，并我们将这些标记收集到结构化输出中。
我建议尽可能使用SLM，而不是默认使用LLM解决每个问题。例如，在工作板上的简历解析中，等待LLM处理简历30秒以上通常是无法接受的。对于这种用例，我们发现SLM在2-3秒内可以提供比大型模型（如GPT-4o）更高精度的结果。我们的管道中的一个示例
在我们的初创公司中，一个文档可以由多达7个不同的模型处理，其中只有2个可能是LLM。这是因为LLM并不总是最好的工具。某些步骤如“检索增强生成”
依赖于一个小型的多模态模型来创建有用的嵌入进行检索。第一步——检测某物是否是文档——使用一个小型且超快速的模型，达到99.9%的准确率。很重要的是将问题分解成小块，然后确定LLM最适合哪些部分。这样，可以减少幻觉发生的机会。区分幻觉和错误
我特别要区分幻觉（模型编造信息）和错误（模型误解现有信息）。例如，选择错误的收据金额总数是一个错误，而生成不存在的金额是一个幻觉。
提取模型只能犯错，而生成模型既可以犯错也可以产生幻觉。风险容忍度和基线
在使用生成模型时，我们需要一些方法来消除幻觉。基线是指任何强制生成AI模型用一些权威信息来证明其输出的技术。如何管理基线取决于每个项目的风险容忍度。例如——一个具有通用收件箱的公司可能希望识别操作项目。通常，需要操作的电子邮件会直接发送给客户经理。一个充满发票、垃圾邮件和简单回复（“谢谢”，“好的”
等）的通用收件箱有太多信息要人类检查。如果操作被错误地发送到这个通用收件箱，该项操作经常会被遗漏。如果模型犯了错误，但总体准确性更高，已经比什么都不做好。此时，对于错误/幻觉的容忍度可以较高。其他情况可能要求特别低的风险容忍度——比如财务文件和“直通处理”。在这种情况下，提取的信息会自动添加到系统中，未经人类审查。
例如，除非（1）付款金额与采购订单中的金额完全匹配，并且（2）付款方式与供应商以前的付款方式匹配，否则公司可能不允许发票自动添加到会计系统中。即使在风险较低的情况下，我仍然倾向于谨慎行事。每当我专注于信息提取时，我遵循一个简单的规则：如果从文档中提取文本，那么它必须与文档中找到的文本完全匹配。这在信息是结构化的情况下是复杂的（例如表格）——特别是因为PDF不包含页面上词序的信息。
例如，一行条目的描述可能分布在多行中，因此目标是围绕提取的文本画一个连贯的框，而不考虑词语的左到右顺序（或某些语言中的右到左）。强制模型指向文档中的确切文本是“强基线”。强基线不仅限于信息提取。例如，客户服务聊天机器人可能需要从内部知识库中的标准化响应中逐字引用。这并不总是理想的，因为标准化响应可能实际上无法回答客户的问题。另一种复杂情况是信息需要从上下文中推断。
例如，一个医疗助手AI可能根据症状推断出某种疾病的存在，而没有明确说明疾病。确定这些症状提到的位置是一种“弱基线”。对响应的解释必须存在于上下文中，但确切的输出只能从提供的信息中合成。另一种基线方法是强制模型搜索医疗条件，并证明这些症状是相关的。这可能仍然需要弱基线，因为症状可以以很多方式表达。复杂问题的基线
使用AI解决越来越复杂的问题可能使使用基线变得困难。例如，如果模型需要执行“推理”
或从上下文中推断信息，如何进行基线？以下是为复杂问题添加基线的一些考虑：识别可以分解为一组规则的复杂决策。不让模型生成最终决策的答案，而是生成决策的组成部分。然后用规则展示结果。（警告——这有时会使幻觉变得更糟。向模型提出多个问题会给它多次产生幻觉的机会。问一个问题可能更好。但我们发现目前的模型在复杂的多步推理方面表现较差。
）
如果某事可以用多种方式表达（例如症状描述），第一步可以是让模型标记文本并标准化（通常称为“编码”）。这可能为更强的基线提供机会。为模型设置可以调用的“工具”，这些工具将输出限制为非常具体的结构。我们不希望执行LLM生成的任意代码。我们希望创建工具，模型可以调用这些工具并对这些工具进行限制。尽可能在工具使用中包括基线——例如，通过在将响应发送到下游系统之前验证回应的上下文。最终输出是否可以验证？
如果难以手工编写规则，我们能否编写提示进行验证？（并且还遵循上述对验证模型的规则）。主要要点
在进行信息提取时，我们不容忍未在原始上下文中找到的输出。我们通过验证步骤来捕捉错误和幻觉。我们做的其他所有事情都涉及风险评估和最小化风险。将复杂问题分解成较小的步骤，并确定是否真的需要LLM。对于复杂问题，使用系统的方法识别可验证的任务：——强基线强制LLM逐字引用可信来源。这始终是首选。
——弱基线强制LLM参考可信来源，但允许合成和推理。——在可以将一个问题分解为较小任务的情况下，尽可能在任务中使用强基线。
admin