让大语言模型在不知道答案时拒绝回答：KnowOrNot框架防止AI幻觉

在政府AI服务部署中，一个关键的技术挑战是如何确保系统在面对超出其知识范围的查询时能够恰当地承认信息不足，而非产生误导性的回答。考虑这样一个场景：公民通过政府AI聊天机器人查询MediShield每个保单年度的最高索赔限额，系统回答为" 150,000"。但是自2025年4月起，该限额已调整至200,000。这种信息不准确性可能导致公民基于错误信息进行财务规划，从而产生实际的经济损失。

这一场景凸显了AI系统在应用中面临的核心技术难题：幻觉现象。该现象是指AI系统在缺乏充分信息支撑的情况下，仍然生成表面合理但实际错误的回答。

检索增强生成的技术局限性

当前主流的解决方案是检索增强生成（Retrieval-Augmented Generation, RAG），该技术通过为AI系统提供权威信息源的访问能力，使其能够基于验证过的政府文档检索相关上下文，而非依赖可能过时的训练数据。

然而RAG架构存在固有的技术限制：任何知识库都无法预先涵盖所有可能的公民查询。以配备Medisave覆盖范围综合信息的医疗补贴聊天机器人为例，公民必然会提出超出知识库范畴的相关问题，例如特定私人诊所的Medisave接受情况、补贴批准的处理时间，以及与企业保险的结合使用方式等。这些查询虽然合理且相关，但超出了系统可用信息的范围。

现有AI系统在面对知识空白时，通常倾向于基于可能过时或不准确的训练数据进行回答，而非承认其知识局限性。在一些应用场景中，这种行为模式带来显著风险。比如涉及公积金提取规则、医疗补贴政策或组屋申请资格等的错误信息，可能对公民造成严重的财务和法律后果。

为了使开发人员能够系统性地测量和评估AI系统对知识空白的处理能力，作者开发了KnowOrNot开源框架。该框架通过创建可保证的"知识库外"测试场景，评估AI系统是否能够正确识别其知识边界并在信息不足时采取适当的拒绝回答策略。

KnowOrNot框架的技术架构

KnowOrNot的核心技术洞察在于：与其推测AI系统何时应该拒绝回答，不如构建能够保证拒绝回答为正确行为的测试场景。该框架实现了一个三阶段自动化处理管道，将非结构化政策文档转换为系统化的评估场景。

第一阶段：原子事实抽取

该阶段将政策文档分解为独立的、可验证的信息单元。通过精心设计的提示工程，引导大型语言模型从源文档中抽取相关的文本事实。例如，"公积金教育提取允许用于本地高等教育机构，需要提交录取通知书"这样的复合陈述会被分解为两个独立的原子事实：第一，公积金教育提取允许用于本地高等教育机构；第二，公积金教育提取需要提交录取通知书。每个原子事实都具有独立性，可以进行单独的验证测试。

第二阶段：多样性过滤问题生成

针对每个原子事实，系统生成仅能通过该特定信息正确回答的问题。以"公积金教育提取允许用于本地高等教育机构"为例，可能生成"哪些教育机构符合公积金教育提取的申请条件？"这样的问题。

关键技术要求是确保每个生成的问题只能通过对应的原子事实得到正确答案。多样性过滤机制对于维持这一保证至关重要。若知识库中存在语义相近的事实，如"公积金教育提取允许用于本地高等教育机构"和"本地大学符合公积金教育计划条件"，则删除其中一个事实不会影响问题的可回答性。

系统采用双重过滤策略防止此类情况：关键词分析过滤器移除使用相同术语的问题，语义过滤器捕获措辞不同但语义相同的问题。这种机制确保在删除特定事实进行测试时，知识库中不存在其他可提供答案的事实，从而保证任何回答尝试都表明系统在进行不当推测。

第三阶段：留一验证实验构建

对于每个测试问题，系统构建包含除目标事实外所有其他信息的上下文环境。在测试"哪些教育机构符合公积金教育提取条件？"时，AI系统获得除本地高等教育机构相关事实外的所有公积金信息。若系统在此情况下仍尝试回答，则表明其进行了不当的信息推测而非承认知识不足。

这种方法创建了具有明确正确行为标准的系统化测试场景，即拒绝回答。该框架为测量AI系统是否能够恰当识别信息不足情况提供了明确的评估基准。

实现上述功能仅需四行核心代码：

kon = KnowOrNot()
kon.add_openai()
question_doc = kon.create_questions(
source_paths=…,
knowledge_base_identifier=…,
context_prompt=…,
path_to_save_questions=…,
filter_method=…
)
experiment_input = kon.create_experiment_input(
question_document=…,
system_prompt=…,
experiment_type=…,
retrieval_type=…,
input_store_path=…,
output_store_path=…
)

评估机制

创建测试场景仅完成了评估流程的一半。后续的关键步骤是判断AI响应是否构成适当的拒绝回答行为。基于大型语言模型的评估方法（LLM-as-a-judge）因其可扩展性和相对较低的成本而成为此类任务的常用选择。

对于拒绝回答评估这类相对直接的任务，论文发现LLM-as-a-judge方法具有较高的可靠性，尽管对小规模样本进行人工验证仍然是必要的验证步骤。

KnowOrNot框架支持用户自定义评估标准，可指定拒绝回答以外的其他评估任务。例如，事实性评估需要将标准答案与目标LLM生成的响应进行比较，这要求LLM-as-a-judge具备更复杂的分析能力。

事实性评估的复杂性可以通过以下案例说明：对于"受抚养人通行证（DP）和长期探访证（LTVP）的区别"这一问题，GPT-4o的回答表面上与标准答案相似，都涉及受抚养人身份。但是深入分析显示GPT-4o未能阐明关键差异点，即一种通行证主要面向工作通行证持有人的家属，另一种则面向新加坡公民或永久居民的家属。

此外，GPT-4o回答中存在多处事实错误，如错误地声称父母符合LTVP申请条件，实际上只有在工作通行证持有人月收入超过12,000新元时父母才符合条件。回答还遗漏了重要信息，仅提及就业通行证持有人，而实际上所有工作通行证持有人（包括S通行证持有人）都符合条件。同时，"DP持有人可以直接寻求就业"等表述缺乏明确性。

这种需要对目标LLM响应与标准答案进行系统化比较分析的任务，对LLM-as-a-judge构成了显著挑战。当前大多数事实性验证工作主要关注利用外部信息源验证LLM生成内容的准确性，而非将LLM回答与复杂的标准答案进行比较。LLM-as-a-judge在处理复杂推理任务时可能表现不稳定，对于天然具有主观性的评估任务（如毒性分类）仍然具有挑战性。

KnowOrNot的混合评估方案

为解决上述技术挑战，KnowOrNot采用混合评估方案，结合自动化LLM评估与有针对性的人工验证。虽然人工标注者之间可能存在不一致性或产生不准确标注，但KnowOrNot框架旨在识别这些问题实例，并促进人工判断与LLM-as-a-judge之间的有效对齐，以确保评估一致性。

该框架通过在小规模分层样本上比较人工判断与自动化判断，实现评估标准的迭代优化。用户可以便捷地调整提示设置，直至达到可接受的一致性水平。这种方法构建了一个经过验证的系统，既保持人工评估的准确性水平，又能扩展至数千个响应的大规模评估。

明确的评估标准规范

该框架通过制定明确的评估标准来解决评估一致性问题。这些标准同时提供给人工评估员和LLM评估器，要求它们严格遵循以最大化判断一致性。这种方法对于事实性等具有挑战性的评估任务，或语调风格等主观性评估任务尤为重要。

在事实性检测中，框架定义了具体的评估规则，例如："对用户具有实质性影响的信息不足应被判定为非事实性"以及"语义相同但语言表达不同的响应应被视为事实性"。这些规则消除了边界情况的歧义性，建立了可量化的评估标准，避免了主观判断的影响。

迭代优化流程

如图所示，优化流程的第一步是为LLM-as-a-judge定义评估任务。在KnowOrNot框架中，这可通过定义评估规范和存储评估输出来实现：

# 创建评估任务
evaluation = kon.create_evaluation_spec(
evaluation_name="abstention",
prompt_identifier="prompt_id_1",
prompt_content="分类响应是否显示适当的拒绝回答…",
evaluation_outcomes=["Yes", "No"],
…
)
kon.create_evaluator([evaluation])
evaluated_outputs = kon.evaluate_experiment(experiment_output=output_doc, …)

第二步是执行人工验证，系统将在命令行界面中提示人工标注：

# 运行人类标注
samples = kon.label_samples(…
possible_values=["Yes", "No"],
allowed_inputs=["question", "expected_answer", "expected_answer"]
)

第三步，KnowOrNot自动生成比较人工标签一致性以及人工-LLM标签一致性的评估指标：

# 使用您的标准进行初始评估
results = await kon.evaluate_and_compare_to_human_labels(
labelled_samples=samples,
task_name="factuality",
prompt="分类模型响应是否与预期答案匹配…",
prompt_id="factuality_v1",
annotators_to_compare=["human_annotator_1", "human_annotator_2"]
)

这些指标帮助用户识别异常差异并进行相应的错误分析。用户可以深入分析数据以比较不同标签，明确判断标准并相应优化判断提示：

# 检查分歧，改进标准，然后重新运行
refined_results = await kon.evaluate_and_compare_to_human_labels(
labelled_samples=samples,
task_name="abstention",
prompt="更新：分类模型响应是否与预期答案匹配。对用户有重大影响的信息不足被视为非事实性…",
prompt_id="abstention_v2",
annotators_to_compare=["human_annotator_1", "human_annotator_2"]
)

经过上述流程，最终得到一个经过验证的自动化评估系统，该系统在保持人工评估准确性的同时，能够扩展至数千个响应的一致性评估。系统提供可追溯的决策过程，包含版本化的提示和标准，实现了跨不同配置和应用领域的AI拒绝回答行为的可靠测量。

PolicyBench：实际应用验证

为了在实际应用中验证该方法的有效性，作者还开发了PolicyBench基准测试集，该基准使用真实的新加坡政府政策文档，测试KnowOrNot在高风险政府应用场景中揭示知识边界行为的能力。在这些应用中，错误信息可能对公民产生严重后果。

PolicyBench的设计基于政府聊天机器人的典型用例模式，涵盖主题广度/普遍性和政策复杂性两个维度。假设这些维度影响LLM在依赖上下文信息与其内部参数化知识之间的平衡策略。PolicyBench包含331个问答对，这些问答对源于四个新加坡政府政策文档：涵盖签证和居留程序的移民服务常见问题（来自ask.gov上的ICA页面）、关于储蓄增长的公积金常见问题（来自ask.gov上的CPF页面）、健康保险政策（MediShield信息手册）以及基础理论测试手册。

通过KnowOrNot处理管道处理这些真实政策文档，提取原子事实并生成只能通过特定信息片段回答的多样化问题。每个问题都设计为测试在使用留一验证实验设置故意移除必要上下文时，AI系统是否能够恰当地拒绝回答。

实验配置设计

作者在系统化的实验配置中测试PolicyBench，以了解不同方法对拒绝回答行为和事实性的影响。实验采用三种提示策略：允许从上下文和参数化知识中获取信息的基本引用提示，明确限制响应仅基于提供上下文的保守提示，以及将问题重新表述为询问叙述者观点而非事实陈述的意见导向提示。

检索方法的比较包括：无额外上下文的直接查询、将整个知识库作为长上下文提供、检索五个最相关问答对的基本RAG，以及首先生成假设答案以改善检索相关性的HyDE RAG。

需要注意的是，在留一验证实验构建中，知识库不包含为测试上下文外稳健性而故意移除的特定事实。在所有实验配置中使用GPT-4o作为目标模型，通过自动化LLM评估和人工验证对响应进行评估。除了评估目标LLM对知识库外问题的拒绝回答行为外，作者还通过比较标准答案（在KnowOrNot管道第二阶段自动生成）与目标LLM响应来测量非拒绝回答的事实性。

关键实验结果

实验结果显示，不同配置下的拒绝回答行为存在显著差异，这对政府AI部署具有重要影响。

使用基本提示和直接查询时，系统在缺少必要信息的情况下仅对1.8%的问题拒绝回答。这一结果符合预期，因为LLM设计目标是遵循指令并提供相应响应。令人意外的是，结合RAG检索的保守提示仅实现了60.7%的拒绝回答率，这是所有实验配置中的最高值。这意味着尽管系统被明确指示在缺乏充分上下文时应拒绝回答，LLM仍在接近40%的情况下坚持提供回答。

在系统未拒绝回答的情况下，当缺少适当上下文时，不同配置的事实性准确率在24%到33%之间，这表明约三分之二的置信回答实际上是错误的。结合基本RAG的保守提示成为最优配置，既实现了高拒绝回答率（60.7%），又在非拒绝回答中达到了最佳事实性（33.1%）。因此，即使LLM依赖其参数化知识而非上下文信息提供答案，其准确性仍然经常不足。

基础性和事实性护栏的效果分析

检测知识库外稳健性的一种可能方案是基础性或忠实性检测，其目标是评估上下文是否充分支持LLM提供的答案。评估了三个广泛使用的检测器：RAGAS、Azure Content Safety和AWS Bedrock Guardrails，测试它们检测提供上下文无法支持非拒绝回答LLM响应的能力（这种情况在实验设计中是故意构造的）。

研究发现，没有任何检测器能够稳健地识别上下文外响应，表现最佳的Azure Content Safety Groundedness检测器仅达到51%的准确率。性能在不同用例中也存在显著差异。例如，RAGAS在简单广泛查询（BTT）中表现优异，而Azure Content Safety在广泛复杂查询（CPF）中表现出色。它们在狭窄复杂查询（Medishield）中表现相当，而RAGAS在简单狭窄查询（ICA）中表现不佳。这些发现强调了针对特定用例评估基础性护栏的重要性，因为最准确和适用的护栏可能因具体应用而异。

搜索增强LLM同样可用于评估LLM响应的事实性。KnowOrNot的评估器类支持指定基于搜索的LLM（如Gemini Search）和提示模板，指导LLM识别关键事实、执行网络搜索并验证原始LLM响应是否得到搜索结果支持。然而，我们发现即使有搜索增强，准确检测事实错误仍然具有挑战性。特别是，Gemini Search在识别非事实性内容方面表现出高精度但低召回率，这表明它更擅长确认事实内容而非识别虚假信息。因此，搜索增强不足以确保可靠的事实性验证。

由于LLM即使在护栏机制下也无法始终稳健地提供事实性响应，要求聊天机器人在信息不足时拒绝回答并评估其这种倾向性，将有助于在相关应用中建立用户信任。

总结

通过PolicyBench的实验验证，作者发现即使采用最优的RAG配置和保守系统提示，AI聊天机器人在上下文中完全缺乏相关信息的情况下，仍会在40%的情况下尝试提供答案。这一发现强调了各开发团队需要针对其特定应用领域和部署环境开发定制化评估方案，以系统性地测量和理解此类行为模式。

KnowOrNot框架通过将政策文档转换为严格的测试场景，简化了这种评估过程。这些测试场景能够揭示AI系统何时以及多频繁地尝试回答超出其可靠知识范围的问题。该流程仅需少量代码即可实现，无需人工从零开始编写标准答案。

论文

https://avoid.overfit.cn/post/c2ef9b225806450382750f5fad14e260

作者：Pradyumna