注入还是导航？面向交易法律文件LLM分析的令牌高效检索方法

# 1 引言 来源：https://arxiv.org/html/2607.05764

## 注入还是导航？面向法律交易文档的LLM分析中的令牌高效检索

Mahmoud Hany\*，Mourad ElSheraey\*，Mahmoud Said\*，Peter Naoum  
[email protected]，[email protected]，[email protected]，[email protected]  
Syntheia Pty Ltd

**摘要。** 对一组交易法律文档进行问答，最直接的做法是在每次查询时将整个语料库"注入"到LLM的上下文窗口中。这种基线方法最大限度地提高了检索召回率，但其令牌占用规模随语料库而非问题本身扩展，并且长上下文退化问题也随之加剧。本文报告了在某个法律文档分析系统中，为取代全语料注入所需完成的工作，并将其与两种在我们专有的结构感知分块基础上的结构化检索模式进行比较：嵌入检索（navembed）和基于紧凑结构索引的LLM导航（navindex）。在一个包含20个问题且带有已验证真实答案的基准测试中，经过位置偏差控制、基于参考锚点的成对评估器判定：在18个文档相关问题上，带有重排序的语义检索与注入方法在16个问题上表现相当（注入方法在2个问题上更优），同时其处理的输入令牌减少了17.3倍（通用文本嵌入GTE配置在较低的对等率下实现了29.9倍的减少）；两种模式在2个范围外控制问题上都被判定为相当。navindex在所有18个问题上被判定为相当，同时其总令牌占用减少了1.61倍，回答上下文缩小了约56倍，美元成本降低了25%。我们推导出一个封闭形式的缓存交叉规则：只有当语料库规模大约低于检索载荷的十倍时，缓存的注入在美元成本上才更便宜。范围与不确定性在第8节（https://arxiv.org/html/2607.05764#S8）中进行了量化。  
¹ 同等贡献。Mahmoud Hany构建并运行了所有三个阶段的评估程序，并撰写了论文初稿。Mourad ElSheraey修订了分析，增加了不确定性量化和有效性威胁处理，并准备了最终手稿。Mahmoud Said实现了交叉编码器重排序流程和元数据字段，并贡献了交叉引用提取。Peter Naoum实现了初始代码库，并监督了实验工作。

大型语言模型使得直接审问文档变得实用：用户用自然语言提出问题，并获得基于源文本的答案，无需手动构建查询界面或手动审查。几乎没有哪个职业能比法律行业从中获益更多，法律日常工作主要包括定位、协调和解释分散在冗长、密集交叉引用的文件中的条款。Syntheia为这种工作负载提供数据层：一个关于协调的"交易集"（原始协议及其修订、补充函、附件和披露文件）的结构化文档索引，通过API提供服务，并直接通过模型上下文协议[1（https://arxiv.org/html/2607.05764#bib.bib1）]提供给Claude等LLM，供文档工具在此基础上构建。本文报告了决定如何在该索引上进行检索的评估：为用结构化检索取代全语料注入而不牺牲答案质量所需完成的工作，以及每种替代方案在令牌和美元成本上的代价。

最简单的方法是在每次查询时将整个语料库放入模型的上下文窗口中。我们称这种方法为**注入**，并有意将其作为基线，因为它代表了检索召回率的上限。每个条款、定义术语和交叉引用在每次查询时都在上下文中，因此检索器不会遗漏任何内容，也没有配置错误的风险。因此，一个审慎的评估者无法区分的替代方案，是一个比仅仅优于有损检索器更强的结果；语料库的规模是特意设定的，以使注入方法可运行（第3节（https://arxiv.org/html/2607.05764#S3））。

随着语料库的增长，两个成本限制了注入方法。令牌占用规模随语料库而非问题本身扩展（每次查询无论相关性如何都要为每个条款付费），并且语料库根本无法超过上下文窗口。此外，LLM在长输入上的注意力分布不均，并且会丢失位于上下文中间位置的信息[2（https://arxiv.org/html/2607.05764#bib.bib2）]。法律领域加剧了这两种情况：答案往往依赖于定义术语、附件与执行条款之间的交叉引用，以及原始协议与后续修订的交互方式，因此与问题相关的文本分散在整个语料库中，很容易被周围材料稀释。现有的合同基准（CUAD[3（https://arxiv.org/html/2607.05764#bib.bib3）]，ContractNLI[4（https://arxiv.org/html/2607.05764#bib.bib4）]）在单一文档上运行，并未捕捉到这种跨文件的依赖性，这仍是法律检索评估中的一个未攻克的空白。

这里研究的两种模式都在相同的输入表示上运行：由Syntheia开发的专有结构感知方法分块的文档，而非分割成固定大小的片段。分块作为一个固定的预处理步骤保持不变，因此我们衡量的是检索策略而非分块本身；我们不评估朴素的固定大小分块，其倾向于分割条款并降低检索质量的问题已有充分记录[5（https://arxiv.org/html/2607.05764#bib.bib5），6（https://arxiv.org/html/2607.05764#bib.bib6）]。

我们报告两个比较：

**比较1**（第4节（https://arxiv.org/html/2607.05764#S4））评估了**导航-嵌入**（navembed），该方法预先嵌入文档节点，在查询时通过余弦相似度检索最相似的top-k个节点，仅将这些节点放入回答模型的上下文中。十二种配置（RUN-001–012）分三个阶段运行：第一阶段到第二阶段在测试工具成熟过程中运行（RUN-001–008），第三阶段以完整的20个问题规模运行（RUN-009–012）。每个都是内部控制的成对比较（在相同问题上注入方法 vs. navembed），主要结论基于第三阶段运行。

**比较2**（第5节（https://arxiv.org/html/2607.05764#S5））评估了**导航-索引**（navindex），该方法用基于紧凑结构索引的引导式导航替代向量相似度：包括布尔语义标志、生成的摘要以及显式的交叉引用和定义术语图。我们遍历了六种描述符配置（检索器看到的每个节点的元数据），以表征质量与令牌占用之间的权衡。

两种导航模式沿着提示缓存已经分离的两个维度减轻了注入方法的负担：令牌占用和美元成本。缓存降低了重新读取大型上下文的**价格**，但并未减少模型在回答时必须处理的令牌，因此这两个维度在整个过程中被分开追踪（第3.3节（https://arxiv.org/html/2607.05764#S3.SS3））。缓存折扣也仅在单个热会话内有效（一系列时间上足够接近的查询，以保持提供商短暂的提示缓存有效），并且超出上下文窗口的语料库无论如何都无法注入（第7节（https://arxiv.org/html/2607.05764#S7））。在这个框架内，两种模式位于质量-令牌占用曲线的不同点（表4（https://arxiv.org/html/2607.05764#S6.T4））：navindex在令牌占用适度增加的情况下最大化结构保真度，navembed最大化令牌占用的减少，而它们与缓存的注入之间的美元比较取决于语料库规模（第7节（https://arxiv.org/html/2607.05764#S7））。图1（https://arxiv.org/html/2607.05764#S3.F1）说明了所有三种模式。

贡献如下：(i) 在一个带有已验证真实答案的打分法律问答评估集上，对全语料注入与两种结构化检索模式进行成对评估，由位置偏差控制、基于参考锚点的成对协议进行判断（答案级别等价；未直接测量检索召回率），并在整个过程中量化不确定性；(ii) navindex格式的设计，一种适用于法律文件的导航描述符（类型化布尔标志、交叉引用和定义术语图、硬性选择上限），通过发布的提示记录到字段级别，这些提示也实现了修订优先顺序和定义术语解析（附录D（https://arxiv.org/html/2607.05764#A4））；(iii) 一个分离令牌占用与美元成本的封闭形式缓存交叉规则，附带其会话经济学注意事项；(iv) 一份我们不会发布的故障模式目录（BM25长度偏差、仅标题过度选择、无上限节点选择）以及对评估局限性的说明。

## 2 相关工作

RAG将参数化生成器与非参数化检索器配对，使生成基于获取的证据[7（https://arxiv.org/html/2607.05764#bib.bib7）]；近期调查绘制了设计空间[8（https://arxiv.org/html/2607.05764#bib.bib8）]。密集段落检索[9（https://arxiv.org/html/2607.05764#bib.bib9）]确立了学习型双编码器作为强默认选项，随后出现了一系列通用句子嵌入（Sentence-BERT[10（https://arxiv.org/html/2607.05764#bib.bib10）]，E5[11（https://arxiv.org/html/2607.05764#bib.bib11）]，GTE[12（https://arxiv.org/html/2607.05764#bib.bib12）]，BGE[13（https://arxiv.org/html/2607.05764#bib.bib13）]以及基于MPNet的编码器[14（https://arxiv.org/html/2607.05764#bib.bib14）]）。BM25仍然是强大的词汇基线[15（https://arxiv.org/html/2607.05764#bib.bib15）]；混合系统通过互惠排名融合[16（https://arxiv.org/html/2607.05764#bib.bib16）]融合密集和稀疏信号，交叉编码器重排序器[17（https://arxiv.org/html/2607.05764#bib.bib17）]以更高保真度重新评分候选。我们最强的navembed配置是检索-然后-重排序流水线；我们的混合BM25运行说明了在条款结构化文本上的一种已知故障模式（长度偏差）。分块粒度影响检索质量[5（https://arxiv.org/html/2607.05764#bib.bib5），6（https://arxiv.org/html/2607.05764#bib.bib6）]；我们保持结构感知分块固定，仅改变检索策略。

两个观测结果使令牌占用成为这里的一等指标。长上下文性能在相关信息位于长输入中间时下降[2（https://arxiv.org/html/2607.05764#bib.bib2）]，而提供方侧的提示缓存折扣对固定前缀的重新读取[18（https://arxiv.org/html/2607.05764#bib.bib18）]，降低了大型上下文的**价格**，但并未降低模型需处理的**令牌数**。因此，美元成本和令牌占用必须作为独立数量进行追踪。

在评估方面，LLM作为裁判的协议很常见[19（https://arxiv.org/html/2607.05764#bib.bib19）]，但表现出位置偏差[20（https://arxiv.org/html/2607.05764#bib.bib20）]；我们的正向/反向协议是直接回应。在法律NLP中，CUAD[3（https://arxiv.org/html/2607.05764#bib.bib3）]和LEDGAR[21（https://arxiv.org/html/2607.05764#bib.bib21）]是领先的合同基准，而ContractNLI[4（https://arxiv.org/html/2607.05764#bib.bib4）]表明，合同的蕴含关系需要解析定义术语和交叉引用，这些是平面检索无法表示的结构依赖关系。层次索引将节点组织成树，并从粗略摘要导航到精细条款[22（https://arxiv.org/html/2607.05764#bib.bib22）]；一条补充线使用类型化元数据预过滤器，在任何相似度计算之前缩小索引范围，类似于查询优化中的谓词下推。法律文档需要两者：定义术语跨章节传播含义，交叉引用将执行条款与附件绑定，修订在余弦相似度和BM25都无法表示的方式下取代基础条款。navindex格式直接编码这些信号，属于层次导航范式而非平面RAG；在无向量导航器中，它最接近PageIndex[23（https://arxiv.org/html/2607.05764#bib.bib23）]（第5.1节（https://arxiv.org/html/2607.05764#S5.SS1））。

## 3 问题设定与方法

### 3.1 语料库与模型

**文档语料库。** 该基准索引了来自三个业务领域的十五份交易法律协议。六份**信贷协议**（FA）涵盖两个借款人：Fluor公司（一份18亿美元循环贷款额度加一份修订）和Generac（一份ABL额度加两份定期贷款修订和一份2024年再融资）。三份**有限合伙协议**（LP）涵盖两个基金：Thomas Green基金，一只针对LEED认证办公和多户资产的美国房地产基金，承诺上限5亿美元，附带一份配套补充函；以及Carlyle PE Partners，一只5% IRR门槛和12.5%激励分配的私募股权基金。六份**股份/资产购买协议及披露附表**（SP）涵盖四笔交易：Meta向Shutterstock出售Giphy（购买价1.28亿美元）、First Avenue Networks披露附表、PPG/Comex跨境收购，以及Royal Wolf Holdings一份信贷协议。另外两份Netflix信贷协议在开放搜索工作区中已索引，但未绑定任何评分问题。评分基准运行使用了十五份文档中的六份：一份Thomas Green Fund LPA、一份Carlyle PE Partners LPA、Meta/Giphy SPA、First Avenue Networks披露附表、Generac 2024年修订以及Fluor信贷设施修订。所有十五份文档均为公开文件，来源于SEC EDGAR附件、肯塔基养老金FOIA披露以及英国政府来源。带有已验证参考答案及每份文档来源引用的评分问题集作为补充材料发布；所有提示均打印在附录D（https://arxiv.org/html/2607.05764#A4）中。

**问题集。** **评分评估集**包含20个带有已验证真实答案的问题（附录C（https://arxiv.org/html/2607.05764#A3））：18个绑定到特定源文档（每个业务领域六个，每个文档三个问题），2个是**范围外控制**问题，其答案故意不在任何已索引文档中，用于测试系统是否正确拒绝回答而非产生幻觉。由于控制问题测试的是拒绝而非检索，我们在整个过程中将其与文档相关问题的计数分开报告。前两个阶段在*DocNavBench*的一个15问题文档固定子集上运行，DocNavBench是一个针对同一语料库的52问题开放搜索集，由审阅律师编写：其问题故意以问题为导向，如同从业者在**阅读前**且不预设答案存在时提出的问题（因此“协议中没有这个”可以是正确的发现），并且它与文档无关，仅进行成对判断，没有真实答案。第一阶段到第二阶段运行首先使用3个问题，随着测试工具成熟逐步扩展到9个然后全部15个（附录A（https://arxiv.org/html/2607.05764#A1））；navindex描述符扫描（配置1-5，第5节（https://arxiv.org/html/2607.05764#S5））也属于第二阶段，共享其池和语料库。20个问题的评分集是在第三阶段由工程团队新编写的：问题和参考答案用同一模型系列针对六个评分文档起草，对照源文档验证，并由审阅律师认可，添加范围外控制问题，使得每个文档相关问题按设计都可以从索引文档中得到答案。它与第一阶段至第二阶段的问题池没有任何共享问题，因此流水线调优过的部分不会在评分中体现。律师对该集难度的评估