免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


ContextCite: 探究模型生成内容与上下文引用的关系

发布日期:2025-09-19 18:36:47 浏览次数: 1518
作者:ChallengeHub

微信搜一搜,关注“ChallengeHub”

推荐语

ContextCite揭秘:如何让AI回答更透明可信?这款工具能精准追踪模型回答的每一句话来源。

核心内容:
1. ContextCite解决的核心问题:AI生成内容与上下文的准确关联
2. 技术实现原理:可扩展的上下文归因方法与基线对比
3. 应用前景:检测错误信息、投毒内容及提升LLM可靠性

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
  • 代码: https://github.com/MadryLab/context-cite)
  • 演示: https://huggingface.co/spaces/contextcite/context-cite
  • 论文: https://arxiv.org/abs/2409.00729

语言模型在回答特定问题时,可能需要借助外部信息。用户会将这些信息作为“上下文”提供给语言模型,并期望模型在回答问题时能利用这些上下文。

举个例子,假设我想用 ChatGPT这样的 AI 助手来规划本周观看日食的行程。我首先需要提供关于日食路径和天气预报的相关文档,然后才能让它利用这些信息来制定行程。

看到生成的回应后,我可能会问:所有信息都准确吗?模型是否误解或虚构了某些内容?回应是否“基于”我提供的上下文?

我们引入了 ContextCite,一个能帮助回答这些问题的方法。下面是一个例子,展示了 ContextCite 的功能(欢迎通过我们的演示和 Python 包亲自体验):

正如上图所示,ContextCite 发现“伯灵顿天气晴朗,大部分天空都是晴朗的……”这句话导致模型表述“伯灵顿的天气预报是晴朗的……”。这说明归因是准确的!

但我们也知道,模型有时会以不可预测的方式运作。请看下面这个例子:

Panel L
Panel L
Panel R backgound
Panel R backgound
Panel R backgound
Panel R backgound
Panel R1
Panel R1
Panel R2
Panel R2
Panel R3
Panel R3

在这个例子中,语言模型生成了一个包含多个陈述的长篇回复。利用 ContextCite,我们可以精确指出所提供上下文(如果存在)中哪些部分促成了某个特定陈述。将鼠标悬停在高亮显示的输出句子上,即可亲身体验。

那么,ContextCite 是如何工作的呢?

在本篇博客文章的其余部分,我们将详细解释这一点。为此,我们首先定义“上下文归因”任务:精确找出上下文中导致某个生成陈述的部分。然后,我们将介绍 ContextCite 这个简单且可扩展的上下文归因方法,并将其有效性与一些常见的基线方法进行比较。在后续的博客文章中,我们将探讨如何使用 ContextCite 来检测上下文中的误解、未经证实的内容和“投毒”信息。我们深信,上下文归因技术将有助于使大型语言模型 (LLM) 成为更可靠的工具!

什么是上下文归因?

直观地说,上下文归因的目标是将生成响应的一部分追溯到上下文中的某个片段。具体来说,假设我们有一个上下文📚 和一个查询 Q。例如,上下文可能是一些关于最近奥运会的文章,查询可能是“谁赢得的奖牌最多?”。为了执行上下文归因,我们首先将上下文 📚 划分为独立的“来源”📗1,📗2,…,📘n。我们可以根据需要以任何粒度进行划分:例如,来源可以是文章、文章中的段落或句子,甚至是单个词语。在本篇博客文章的其余部分,我们将把来源视为句子

现在我们已经有了来源,就可以进行归因了。上下文归因方法 τ 接受生成响应的一部分(与感兴趣的陈述相对应的 token 子集),并为每个来源分配一个分数。这个分数旨在表示该来源在生成此陈述时的“重要性”:

在实际应用中,我们可能需要一个“归因集”,即一组最相关的来源。为了获得这样的集合,我们可以通过后处理步骤对分数应用阈值。

上下文归因分数代表什么?

到目前为止,我们只说过分数应表示一个来源对于生成特定陈述的“重要性”。但这究竟意味着什么呢?用户可能关注两种归因类型。

“佐证性归因”(Corroborative attribution)识别“支持”或“暗示”某个陈述的来源。而“贡献性归因”(contributive attribution)则识别“导致”模型生成某个陈述的来源。如果一个陈述是准确的,那么其佐证性来源和贡献性来源很可能相同。然而,如果一个陈述不准确,佐证性归因和贡献性归因方法可能会表现出不同。例如,假设模型误解了上下文中的一个事实。佐证性方法可能找不到任何归因(因为上下文中没有任何内容支持其陈述)。另一方面,贡献性方法将识别出模型误解的事实。

目前已经有几种现有方法用于语言模型的佐证性归因。这些方法通常涉及显式训练或提示模型在生成每个陈述时同时生成引用。许多人工智能驱动的搜索产品都提供这类引用(但它们仍难以验证)。

然而,ContextCite 提供的是贡献性归因。正如我们将看到的,与现有的佐证性方法相比,这种归因类型产生了多样且独特的用例和应用(例如,检测误解、查找被“投毒”的上下文)。

评估归因质量

我们如何评估贡献性归因方法的质量?直观上,如果一个来源很重要,那么移除这个来源应该会显著改变响应。遵循这一直觉,评估上下文归因方法的一种方式是观察当我们移除 k 个得分最高的来源时会发生什么。具体来说,我们测量模型分配给原始响应的对数概率下降了多少:

在这个例子中,得分最高的来源是上下文中的关键信息,模型据此推断仙人掌有刺是为了“防御食草动物并协助水分 H 保持”。当我们移除它时,这个响应的概率显著降低,这表明该来源确实很重要。更一般地,如果移除一个归因方法中得分最高的来源导致比移除另一个方法中得分最高的来源更大幅度的下降,那么我们认为前者方法更准确。

ContextCite 方法

我们已经确定,一个有效的上下文归因方法,能够识别出如果不存在就会显著改变响应的来源。我们能否直接模拟这个过程?也就是说,是否存在一个简单的模型,能够预测当我们排除一部分来源时,原始响应的概率将如何变化?

附注:在我们的数据建模和组件建模工作中,我们也探索了类似的思维方式——通过代理模型进行理解。例如,在数据建模中,一个线性代理模型编码了训练数据集中每个样本如何影响模型对给定测试样本的预测。正如我们将看到的,那些对数据建模有效的代理模型类型,即以 logit 尺度概率为目标的稀疏线性模型,在上下文归因设置中也表现出色。

事实证明,答案是肯定的!这正是 ContextCite 设计的核心理念。具体来说,ContextCite 包含以下步骤:

  1. 根据给定的上下文和查询生成响应(这一步没有什么新奇的)。
  2. 随机“消融”上下文中的来源(即,选择一部分来源排除,并构建一个不包含它们的修改后的上下文)。然后,计算生成原始响应的概率。重复此过程多次,以创建由消融掩码和相应的概率组成的“训练数据集”。 3.拟合一个代理模型,以估计生成原始响应的概率与消融掩码之间的函数关系。

下图总结了 ContextCite 的工作原理:

在实践中,我们发现(就像在数据建模中一样)一个预测 logit 尺度概率的线性代理模型非常有效!为什么要进行 Logit 尺度转换? (点击展开) 拟合一个线性模型来预测概率可能会有问题,因为概率的取值范围被限制在 [0,1][0,1] 之间。Logit 尺度转换是一种将 [0,1][0,1] 映射到 (−∞,∞)(−∞,∞) 的方法,使得 Logit 尺度概率在线性回归设置中更适合作为预测值。

然后,我们可以将这个代理模型的权重视作归因分数,表示每个来源对生成内容的决定性作用。

稀疏性助阵!

现在,一个自然而然的问题是:我们需要计算多少次随机上下文消融才能得到一个准确的代理模型?由于我们正在解决一个线性回归问题,我们预期所需的消融次数与来源数量呈线性关系。但鉴于代理模型学习的每一次消融都需要对我们正在归因的模型进行一次额外的推理过程,我们希望将消融次数保持在较低水平。

事实证明,ContextCite 通过利用潜在的稀疏性,能够以明显更少的消融次数学习到一个准确的代理模型。特别是,在许多情况下,模型生成的陈述可以通过少数几个来源得到很好的解释。这意味着大多数来源对特定陈述的影响非常小。因此,我们可以使用 Lasso 来学习一个稀疏(但仍然准确)的线性代理模型,只需极少的消融次数。

为何我们只需少量消融即可? (点击展开) 在我们的稀疏线性回归设置中,我们完全控制协变量(即,上下文消融)。具体来说,我们独立地消融上下文中的来源,每个来源的消融概率为 1/2。 这使得由此产生的回归问题“表现良好”。 更具体地说,这使我们能够利用已知结果(定理7.16 和 7.20),它告诉我们只需 O(s log(n)) 次上下文消融即可,其中 n 是源的总数,s 是与响应具有非零相关性的源的数量。 换句话说,所需的上下文消融次数随来源总数的增长非常缓慢。 它只与模型在生成特定陈述时所依赖的来源数量呈线性增长。

实际上,在我们的 demo 和评估中,即使上下文包含数百个来源,我们也可以只使用 32 次消融!

下图显示了 ContextCite 用于归因 Mistral-7B-Instruct 模型对“仙人掌是否会被浇水过多?”问题的回答时,代理模型权重,其中上下文使用的是维基百科上关于仙人掌的文章。

在中间部分,我们可以看到整个维基百科文章中有三个句子的权重远高于其他句子——这三个句子是导致模型做出回应的主要原因。在右侧,我们展示了代理模型对许多随机上下文消融和整个上下文的 logit 概率预测以及实际的 logit 概率。代理模型看起来非常准确!这些“垂直簇”是由 Lasso 中使用的 ℓ1 范数正则化引起的稀疏性所导致:模型的大部分预测都取决于这三个关键句子的存在与否。

与现有工作的联系

除了数据建模和组件建模之外,还有一些工作探索了使用代理模型来解释和归因模型行为。我们过去曾对此进行了大量思考,以及其他近期研究已将数据模型应用于语境学习设置,以选择更好的示例作为演示。在可解释性文献中,LIME 使用局部稀疏线性代理模型来根据特征解释模型的预测。

ContextCite 归因效果如何?

ContextCite旨在识别上下文中那些能解释模型为何生成特定内容的部分。那么它在这方面的效果如何呢?我们通过以下三个基于先前研究的自然基线方法,对 ContextCite 进行了基准测试(旨在作为上下文归因的参考):

  • 注意力(Attention):根据将注意力机制作为语言模型行为解释的文献,我们平均了最终层注意力分数,以将其归因于每个来源。
  • 相似度(Similarity):我们使用现成的预训练模型将待归因的选定内容和每个来源进行嵌入,并将嵌入的余弦相似度作为归因分数。
  • 梯度(Gradient):我们计算了待归因的选定内容相对于每个来源的梯度,并将梯度范数作为归因分数。

正如我们前面讨论的,我们通过消融 k 个得分最高的来源并测量原始响应的对数概率下降(按响应长度归一化)来量化归因方法的有效性。在不同的任务中,ContextCite 始终优于这些基线方法:

为了更细致地评估,我们还考虑了归因分数是否能准确“排序”消融不同来源集合的效果。在数据归因文献中,线性数据建模分数(LDS)正是衡量这一点(在那里,它对消融不同训练样本集合的效果进行排序)。在 LDS 方面,我们也发现 ContextCite 优于基线方法:

到目前为止,我们已经看到 ContextCite 能够学习准确的贡献性归因。这正是 ContextCite 的设计目的。然而,我们可能也想知道,在存在真实标签来源的情况下,ContextCite 是否也能有效识别它们。上面提到的 Hotpot QA 数据集就包含了回答每个问题所需的精确句子列表的标注。我们发现,与基线方法相比,ContextCite 在识别这些真实标签来源方面也同样有效:

总结

在这篇文章中,我们介绍了上下文归因问题:精确指出上下文中哪些部分导致语言模型生成了特定的陈述。我们提出了 ContextCite,一种可扩展的上下文归因方法,可以灵活应用于任何现有的语言模型。




图片
添加微信,备注”LLM“进入大模型技术交流群
图片
图片

如果你觉得这篇文章对你有帮助,别忘了点个赞、送个喜欢

>/ 作者:致Great

  >/ 作者:欢迎转载,标注来源即可


53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询