技术摘要：注入还是导航？用于法律交易文档 LLM 分析的高效 Token 检索方案

问题陈述

本文探讨了针对交易类法律文档（如协议、修正案、侧函、附表）语料库进行问答的挑战。基准方法被称为注入（inject），即在每次查询时将整个语料库放入大语言模型（LLM）的上下文窗口中。虽然这种方法通过确保不遗漏任何信息来最大化检索召回率，但随着语料库规模的增长，它面临两个关键局限性：

1. Token 足迹： 其成本随语料库规模而非问题本身而增长，导致在大规模文档集上的效率低下。
2. 长上下文退化： LLM 在长输入上的注意力分布不均，往往会丢失位于上下文窗口中间位置的信息。
3. 上下文窗口限制： 法律事务往往会超过当前模型的最大上下文窗口，使得全量注入变得无法实现。

现有的基准测试（如 CUAD、ContractNLI）通常针对单个文档进行操作，未能捕捉到交易类法律分析中固有的跨工具依赖关系（例如：定义项、交叉引用、修正案）。

方法论

作者使用了一种由 Syntheia 开发的具有结构感知能力的分块方法，对两种结构化检索策略进行了评估，并将其与 inject 基准进行了对比。评估是在一个包含 6 份法律文档、共 20 个问题（其中 18 个为带有验证事实依据的文档相关问题，2 个为范围外控制问题）的基准测试上进行的。

评估协议

• 裁判： 使用了一个经过位置偏差控制、参考锚定的成对裁判（使用 claude-opus-4-7），用于比较基准方法与检索方法的答案。只有当两个方向的比较结果一致时，才会判定为“平局（tie）”，这证明了两个答案在与事实依据的一致性上是同等的。
• 指标： 研究追踪了Token 足迹（模型关注的总 Token 数，包括缓存的上下文）和美元成本（运营支出，考虑了提示词缓存折扣）。由于缓存可以降低成本但不减少模型必须处理的 Token 数，因此将两者视为独立的指标。

三种模式

1. 注入 (Inject - 基准)： 将完整语料库放入上下文窗口进行每次查询。
2. 嵌入导航 (Navigate-Embeddings - navembed)： 文档被预先嵌入到一个节点树中。查询时，通过余弦相似度检索前 $k$ 个最相似的节点（可选配交叉编码器重排序），并将它们放入上下文中。
3. 索引导航 (Navigate-Index - navindex)： 一种无向量的方法，LLM 导航一个紧凑的结构化索引。该索引包含：
   • 布尔语义标志：（例如：isDefinition [是否为定义项]、hasMoney [是否涉及金额]、hasLiabilityLimit [是否有责任限制]）。
   • 结构元数据： 标题、条款引用以及显式的交叉引用/定义项图谱。
   • 导航流程： LLM 扫描索引 (S1)，根据布尔过滤器和摘要选择最多 10 个节点 ID，然后确定性地获取这些节点的原文文本 (S2)，以生成答案 (S3)。

关键结果

Inject vs. navembed

• 性能： 最强配置（语义检索 + 重排序，RUN-012）在 18 个文档相关问题中，有 16 个被判定为与 inject 持平（inject 在 2 个问题中更优）。
• 效率： 该配置将输入 Token 足迹减少了 17.3 倍（188K tokens 对比 3.26M tokens）。
• 成本： 在所有验证运行中，其美元成本均低于 inject。
• 失效模式： 一种混合 BM25 配置（RUN-011）出现了“长度偏差”，导致有效载荷膨胀，未能有效降低成本。

Inject vs. navindex

• 性能： Token 优化配置（Config 6）在所有 18 个文档相关问题及两个范围外控制问题上，均被判定为与 inject 持平。这代表了研究中最高的单次运行平局率。
• 效率：
  • Token 足迹： 减少了总输入 Token 数 1.61 倍。
  • 回答上下文： 将模型在生成答案期间关注的上下文减少了 约 56 倍（2.9K tokens 对比 163K tokens）。
  • 成本： 记录到比 inject 低 25% 的美元成本（$1.21 对比$1.61）。
• 机制： navindex 的成功归功于其对结构化信号（交叉引用和定义项）的显式编码，这使得它比仅靠余弦相似度更能捕捉到这些信号，从而能够在不完全依赖语义接近性的情况下检索到所需的精确上下文。

成本分析：缓存交叉规则 (The Caching Crossover Rule)

论文推导出了一个闭式规则，用于判断缓存后的 inject 在美元成本上何时比检索更便宜：
$$C < 10 \times R$$
其中 $C$ 是语料库大小，$R$ 是检索有效载荷。

• 含义： 只有当语料库大约是检索有效载荷的 10 倍 时，缓存后的 inject 才会更便宜。
• 现实情况： 对于测试的 163K-token 语料库，在稳态下，navembed 和 navindex 都比缓存后的 inject 更便宜。然而，对于非常小的语料库（<35K tokens），inject 仍然是更经济的选择。
• 注意事项： 这假设了一个“热”会话，即缓存有效（5 分钟 TTL）。在异步工作流中，可能会重复产生缓存写入成本，从而削弱 inject 的优势。

核心贡献

1. 配对评估： 在一个具有验证事实依据的法律问答集上，对全量语料注入与结构化检索进行了严谨的、受位置偏差控制的评估。
2. navindex 设计： 设计了一种用于法律文书的导航描述符，通过特定的提示词工程，实现了类型化布尔标志、交叉引用图谱和定义项解析的运作。
3. 缓存交叉规则： 提出了一个区分 Token 足迹与美元成本的闭式经济规则，强调了 Token 减少是一种结构性收益，而成本节省则是取决于会话的。
4. 失效模式目录： 识别了需要避免的具体失效模式，例如 BM25 长度偏差、仅标题过度选择以及未受限的节点选择。

重要性与主张

论文声称，结构化检索是法律文档分析中一种可行且通常优于全量语料注入的替代方案，前提是检索策略必须尊重法律文本的结构依赖关系。

• 质量保持： 结构化检索可以匹配全量注入的答案质量（以参考锚定裁判衡量），同时大幅减少 Token 足迹和回答上下文。
• 结构保真度： navindex 方法表明，将法律结构信号（交叉引用、定义项）直接编码进索引，比单纯依赖向量相似度更为有效，尤其是在处理需要协调修正案和附表的查询时。
• 经济可行性： 虽然对于极小规模语料库或单次查询，全量注入更便宜，但随着语料库规模增长或检索有效载荷显著小于全量语料时，结构化检索在经济上更具优势。

作者对自己的主张保持了审慎态度，指出评估受限于单一模型系列、特定的 20 个问题集，并且由于缺乏 ground-truth 节点标签，并未直接测量检索召回率（precision/recall）。他们强调，“平局”判定的含义是验证了与事实依据的一致性，而非绝对的正确性，且结果针对所评估的特定语料库和提示词工程。