处理超长文本的AI评论摘要:一种基于层次聚类的多通道方法
最初发表于2024年10月28日,Bazaarvoice开发者博客
引言
大型语言模型 (LLM) 是处理非结构化文本的强大工具,但如果您的文本超出上下文窗口的限制怎么办?Bazaarvoice在构建其AI评论摘要功能时就面临着这一挑战:数百万条用户评论根本无法容纳到即使是最新的LLM的上下文窗口中,即使可以容纳,成本也高得令人望而却步。
本文将分享Bazaarvoice如何通过压缩输入文本(不损失语义)来解决这个问题。具体来说,我们使用了一种多通道层次聚类方法,使我们能够明确地调整想要损失的细节级别以换取压缩,而不管选择的嵌入模型是什么。最终的技术使我们的评论摘要功能在经济上可行,并为我们未来的业务扩展奠定了基础。
问题
Bazaarvoice收集用户生成的产品评论已有近20年历史,因此我们拥有大量的数据。这些产品评论完全是非结构化的,长度和内容各不相同。大型语言模型非常适合处理非结构化文本:它们可以处理非结构化数据,并在干扰因素中识别相关信息。
然而,LLM也有其局限性,其中一个局限性是上下文窗口:一次可以输入网络的标记数量(大致相当于单词数量)。最先进的大型语言模型,例如Anthropic的Claude版本3,具有高达200,000个标记的超大上下文窗口。这意味着您可以将小型小说放入其中,但互联网仍然是一个庞大且不断增长的数据集合,我们用户生成的产品评论也不例外。
在构建我们的评论摘要功能(总结客户网站上特定产品的全部评论)时,我们遇到了上下文窗口的限制。然而,在过去的20年中,许多产品积累了数千条评论,这些评论迅速超载了LLM上下文窗口。事实上,我们甚至有一些产品拥有数百万条评论,需要对LLM进行巨大的重新设计才能在一个提示中进行处理。
即使在技术上可行,成本也会非常高昂。所有LLM提供商都根据输入和输出标记的数量收费。当您接近每个产品的上下文窗口限制时(我们有数百万个产品),我们的云托管账单很快就会超过六位数。
我们的方法
为了克服这些技术和经济上的限制来发布评论摘要,我们关注了我们数据的一个相当简单的见解:许多评论表达的是相同的意思。事实上,摘要的整个概念都依赖于此:评论摘要捕捉了评论者反复出现的见解、主题和情感。我们意识到,我们可以利用这种数据重复来减少需要发送到LLM的文本量,从而避免达到上下文窗口限制并降低我们系统的运营成本。
为此,我们需要识别表达相同意思的文本片段。这样的任务说起来容易做起来难:人们经常使用不同的单词或短语来表达相同的意思。
幸运的是,识别文本语义是否相似一直是自然语言处理领域的一个活跃研究领域。Agirre等人2013年的工作(SEM 2013共享任务:语义文本相似性。在词汇和计算语义的第二次联合会议上)甚至发表了一组人类标记的语义相似句子的数据,称为STS基准。在其中,他们要求人们根据1-5的等级来指示文本句子在语义上是相似还是不同,如下表所示(来自Cer等人,SemEval-2017任务1:语义文本相似性多语言和跨语言重点评估):
STS基准数据集通常用于评估文本嵌入模型在其高维空间中关联语义相似句子的能力。具体来说,皮尔逊相关性用于衡量嵌入模型对人类判断的表示程度。
因此,我们可以使用这样的嵌入模型来识别产品评论中语义相似的短语,然后在将它们发送到LLM之前删除重复的短语。
我们的方法如下:
在项目符号列表中写出来时,这似乎很简单,但在我们可以信任这种方法之前,我们必须解决一些细节问题。
嵌入模型评估
首先,我们必须确保我们使用的模型有效地将文本嵌入到语义相似的句子靠近,而语义不相似的句子远离的空间中。为此,我们只需使用STS基准数据集并计算我们想要考虑的模型的皮尔逊相关性。我们使用AWS作为云提供商,因此我们自然希望评估其Titan文本嵌入模型。
下表显示了不同Titan嵌入模型在STS基准测试上的皮尔逊相关性:
因此,AWS的嵌入模型在嵌入语义相似的句子方面非常出色。这对我们来说是个好消息——我们可以直接使用这些模型,而且它们的成本极低。
语义相似聚类
我们面临的下一个挑战是:如何在聚类过程中强制执行语义相似性?理想情况下,没有哪个集群的两个句子的语义相似性低于人类可以接受的程度——上表中的分数为4。然而,这些分数并不能直接转化为嵌入距离,而这是凝聚层次聚类阈值所需要的。
为了解决这个问题,我们再次转向STS基准数据集。我们计算了训练数据集中所有对的距离,并根据分数拟合多项式到距离阈值。
这个多项式使我们能够计算出满足任何语义相似性目标所需的距离阈值。对于评论摘要,我们选择了3.5分,因此几乎所有集群都包含“大致”到“大部分”等效或更高的句子。
值得注意的是,这可以在任何嵌入网络上完成。这使我们能够随着新嵌入网络的出现而进行实验,并在需要时快速更换它们,而无需担心集群将包含语义不相似的句子。
多通道聚类
到目前为止,我们知道我们可以信任我们的语义压缩,但还不清楚我们可以从数据中获得多少压缩。正如预期的那样,压缩量因不同的产品、客户和行业而异。
在没有语义信息丢失的情况下,即4的硬阈值,我们只实现了1.18的压缩比(即15%的空间节省)。
显然,无损压缩不足以使这项功能在经济上可行。
然而,我们上面讨论的距离选择方法在这里提供了一个有趣的可能性:我们可以通过以较低的阈值重复对剩余数据运行聚类来逐渐增加信息丢失量。
方法如下:
因此,在聚类的每个通道中,我们都在牺牲更多信息丢失,但获得更多压缩,并且不会混淆我们在第一通道中选择的无损代表性短语。
此外,这种方法不仅对评论摘要非常有用(我们希望以较少压缩为代价获得高水平的语义相似性),而且对其他用例也非常有用,在这些用例中,我们可能不太关心语义信息丢失,但希望在提示输入上花费更少。
在实践中,即使在多次降低分数阈值之后,仍然有大量集群只有一个向量。这些被认为是异常值,并被随机抽样以包含在最终提示中。我们选择样本大小以确保最终提示有25,000个标记,但不多于此。
确保真实性
多通道聚类和随机异常值采样允许以较小的上下文窗口(发送到LLM)为代价牺牲语义信息。这就提出了一个问题:我们的摘要有多好?
在Bazaarvoice,我们知道真实性是消费者信任的必要条件,我们的评论摘要必须保持真实,才能真正代表评论中捕捉到的所有声音。任何有损压缩方法都存在歪曲或排除花时间撰写评论的消费者的风险。
为了确保我们的压缩技术有效,我们直接测量了这一点。具体来说,对于每个产品,我们都抽取了一些评论,然后使用LLM Evals来确定摘要是否具有代表性和与每条评论相关。这为我们提供了一个硬性指标来评估和平衡我们的压缩。
结果
在过去的20年中,我们已经收集了近10亿条用户生成的评论,并且需要为数千万种产品生成摘要。这些产品中的许多产品都有数千条评论,有些甚至高达数百万条,这会耗尽LLM的上下文窗口并大幅增加价格。
然而,使用我们上述的方法,我们将输入文本大小减少了97.7%(压缩比为42),使我们能够在未来为所有产品和任何数量的评论量扩展此解决方案。此外,为我们所有十亿级数据集生成摘要的成本降低了82.4%。这包括嵌入句子数据并将它们存储在数据库中的成本。
以上是语义压缩文本以节省LLM成本的详细内容。更多信息请关注PHP中文网其他相关文章!