AI News HubLIVE
站内改写5 分钟阅读

超越RAG:面向企业AI的任务感知知识压缩(AWS实现)

传统的检索增强生成(RAG)在处理跨越数百份文档的分析任务时存在局限。本文介绍如何在AWS上使用任务感知知识压缩(TAKC),预先将整个知识库压缩为任务特定的表示,按多个保真度层级缓存,并将每个查询路由到适当的层级,同时提供可部署的开源实现。

来源AWS Machine Learning Blog作者: Dhananjay Karanjkar

如果您正在使用检索增强生成(RAG)来处理需要跨数百份文档的复杂分析任务,例如财务尽职调查或法规合规审查,您很可能已经遇到了它的天花板。相似性搜索能够找到相关的片段,但常常遗漏跨文档的连接。本文将向您展示如何利用任务感知知识压缩(TAKC)来弥补这一差距,该技术可将整个知识库预先压缩为任务特定的表示,并部署在AWS上。您可以在自己的账户中部署一个完整的开源实现。

任务感知知识压缩

考虑一家私募股权公司正在评估一项价值5亿美元的制造企业收购。尽职调查团队必须分析涵盖12家子公司和5年时间的财务报表。他们还面临200多份供应商合同、来自8个设施的环境合规报告以及50多起法律案件。当分析师询问关于当前供应商条款和未决诉讼的综合财务风险时,RAG的相似性搜索无法提供答案。数百份文档包含相关信息,但它们之间的联系缺乏词汇相似性。

TAKC通过使用LLM生成更短、更聚焦于任务的文档摘要来解决这类问题,不同的任务会有不同的摘要。不同的任务需要从同一份文档中提取不同的信息。为财务分析压缩的年度报告需要收入数据、利润率和现金流数据。而为合规审查压缩的同一份报告则需要监管引文和违规历史。通用摘要试图涵盖所有内容,这会稀释任何特定用例的信息密度。TAKC通过特定任务的镜头来压缩文档,保留重要的内容并丢弃其余部分。在摄取管道部分,展示了压缩提示如何具体指定要保留的信息。对于生产部署,请将任务类型提示存储在版本化配置中(例如AWS Systems Manager Parameter Store或专门的Amazon Simple Storage Service(Amazon S3)前缀),以便提示更改可审计,并在提示更新时触发重新压缩。

系统离线压缩文档,每个任务类型每个文档一次。查询时,系统检索预压缩的表示而非原始文档。然后使用压缩版本而非完整文档来回答问题。如果压缩表示不够详细,查询复杂度分析器会将问题路由到保留更多上下文的较低压缩层级。

TAKC以压缩形式提供对整个知识库的访问,而不仅仅是相似性搜索返回的前k个块。由于压缩时文档被一起处理,系统保留了文档间的联系。它还能从同一源材料为不同任务生成不同的压缩输出。一份10-K文件的财务压缩与法律风险压缩完全不同。压缩可将token数量减少8倍至64倍,同时针对保留任务相关信息。

多速率压缩

不同的查询需要不同级别的保真度。像“第三季度营收是多少?”这样的问题所需上下文远少于分析供应商付款条件与各子公司季度现金流之间关系的请求。

TAKC通过为每种任务类型维护四个压缩层级来解决这一问题。在最小压缩(8倍)下,系统保留大约87.5%的上下文。它保留了足够的多步推理和跨文档综合细节。在中等级别(16倍)下,上下文减少约93.8%。此级别适用于中等复杂度的分析查询。高级别(32倍)将上下文减少约96.9%,适用于事实查找和明确定义的问题。在超高级别(64倍)下,减少约98.4%。此级别适用于分类任务和关键词查找。

查询复杂度分析器基于查询长度、问题类型以及分析性语言的存在等信号,将传入的问题路由到适当的层级。直接的事实性问题将命中超压缩缓存,而复杂的分析问题则使用轻度压缩缓存。这对用户来说是透明的。

大多数企业查询是查找操作,可以从较高压缩层级以最低成本提供服务。不常见的复杂查询仅在需要时消耗较大的上下文预算。这种基于层级的路由补充了现有的RAG优化技术,如元数据过滤和查询重新格式化,这些技术可以在应用压缩之前缩小文档集。为了验证压缩质量,请将每个层级的LLM响应与从完整未压缩文档生成的响应进行比较。参考实现包括测试脚本,可以对您的特定任务类型和文档进行此比较。

AWS上的架构

该实现在AWS上作为两个解耦的无服务器管道运行:一个用于摄取,一个用于查询。图1展示了这两个管道。

TAKC架构:管道流程处理数据摄取和压缩。用户流程处理经过身份验证的查询。

我们选择AWS Lambda进行计算,因为每个函数调用都是短生命周期的且由事件驱动。工作负载在摄取期间突发处理数据,并在突发之间处理可变的查询负载,使得无服务器成为自然的选择。

我们选择Amazon API Gateway将查询接口暴露为REST端点。对于缓存,我们选择Amazon ElastiCache Serverless用于在复合键(takc:{task}:{rate})上进行读取,无需分片管理。Amazon Cognito处理JWT发放和令牌刷新,无需自定义身份验证代码,减少了实现面积。

摄取管道

当文档以任务类型前缀(例如raw-data/financial/)落入Amazon S3时,S3事件通知会触发一个AWS Lambda函数。该函数将文档分割为256个token的块,重叠50个token以防止边界信息丢失。然后,它异步调用一个压缩Lambda函数来处理每个块,实现并行处理。对于大规模摄取,请在压缩函数上配置预留并发,并在分块和压缩步骤之间放置一个Amazon Simple Queue Service(Amazon SQS)队列,以优雅地处理节流。

第二个函数调用Amazon Bedrock在所有四个压缩层级压缩这些块。每次压缩调用包括一个任务感知提示,告知模型要保留哪些信息:

任务:财务分析。保留收入指标、利润率、现金流、债务义务和财务风险指标。 压缩目标:减少到原始长度的约1/16。 说明:

  • 专注于与任务相关的事实和关系
  • 保留数值数据和指标
  • 维护实体及其属性
  • 保留因果关系和依赖关系
  • 删除冗余或不相关的信息

模型知道要保留什么,因为提示指定了任务的重要内容。这一区别使得它成为任务感知而非通用压缩。系统将压缩输出存储在Amazon ElastiCache Serverless中,键结构如takc:financial:medium,并备份到S3以实现持久性。Redis OSS数据模型支持多速率缓存查找所需的分层键结构。缓存条目使用24小时TTL,并备份到S3。如果缓存条目被驱逐或过期,查询函数将回退到S3备份,并在读取时重新填充缓存。

查询管道

用户通过Amazon Cognito进行身份验证,接收JWT,然后通过Amazon API Gateway发送查询。AWS WAF位于API前端,用于速率限制和威胁防护。一个Lambda函数使用启发式方法(关键词信号和查询长度)分析查询复杂度,从Amazon ElastiCache Serverless检索适当的压缩缓存,然后将压缩上下文和查询发送到Amazon Bedrock进行推理。当路由置信度低时,系统默认使用中等压缩层级作为安全回退。

更高成本的Bedrock压缩调用仅在摄取期间发生一次。查询路径包括缓存查找和在压缩上下文上的推理。

该栈使用Amazon Bedrock(Anthropic Claude 3 Haiku、Claude 3 Sonnet和Amazon Titan Text)进行压缩和推理。模型选择可通过CDK上下文值配置,无需代码更改。AWS Lambda(Python 3.12+)处理数据处理和查询逻辑。Amazon ElastiCache Serverless存储压缩缓存,而Amazon S3存储原始数据、块和缓存备份(KMS加密)。Amazon API Gateway暴露REST端点,Amazon Cognito提供基于JWT的身份验证。AWS WAF位于API前端,提供速率限制和托管安全规则。Amazon CloudWatch提供监控和指标,AWS Key Management Service(AWS KMS)管理加密密钥。

将基础设施定义为单个AWS Cloud Development Kit(AWS CDK)栈,并使用单个命令部署。AWS CDK提供可重复的部署,并允许您通过上下文值自定义参数,如压缩块大小、Lambda内存分配和ElastiCache存储限制。对于生产部署,考虑将有状态资源(S3、ElastiCache、Cognito)分离到自己的栈中,以减少爆炸半径并实现计算和存储层的独立生命周期管理。

成本比较

针对一个包含100,000个token的知识库,每天查询1,000次(输出token被排除,因为响应长度与上下文大小无关):

方法 每次查询输入token 每日输入token 相对输入成本 完整上下文 100,000 100,000,000 100% RAG(前10个块) ~10,000 10,000,000 10% TAKC轻度(8倍) ~12,500 12,500,000 12.5% TAKC中级(16倍) ~6,250 6,250,000 6.25% TAKC高级(32倍) ~3,125 3,125,000 3.1% TAKC超高级(64倍) ~1,563 1,563,000 1.6%

压缩带来的token节省直接源自压缩比率。实际节省取决于您特定的Bedrock模型定价和查询模式。

TAKC需要预先通过一次性Bedrock调用进行压缩成本。对于变化不频繁且被反复查询的知识库,该成本可以得到摊销。对于每小时变化的知识库,RAG的每次查询检索模型可能更实用。

何时选择TAKC、RAG或两者结合

下表总结了根据工作负载特征,每种方法更适合的情况:

因素 有利于TAKC 有利于RAG 查询类型 跨文档推理、综合 直接的事实查找 知识库稳定性 每天或更少变化 每小时或更频繁变化 任务可预测性 明确定义的任务类型 不可预测的查询模式 覆盖范围要求 必须考虑整个语料库 只有少数文档相关 来源归属 不需要 需要(用户需要看到来源) Token预算 紧张 灵活

在实践中,生产系统通常受益于两者。RAG高效处理快速查找。TAKC处理基于检索的方法无法捕捉到连接的分析查询。查询复杂度分析器可以在它们之间路由。当用户需要将响应追溯到特定源文档时,使用RAG。对于需要跨文档推理和可审计性的受监管工作负载,结合TAKC和RAG:使用TAKC进行分析性响应,使用RAG检索支持性源文档以形成审计线索。

开始使用

前提条件

要部署此参考实现,请确保您具备以下条件:

一个具有Amazon Bedrock模型访问权限的AWS账户。

AWS CDK CLI。

Python 3.12或更高版本。

Node.js 18或更高版本。

部署

[为节省成本,原文已截断]

超越RAG:面向企业AI的任务感知知识压缩(AWS实现) | AI News Hub