Inject or Navigate? Token-Efficient Retrieval for LLM Analysis of Transactional Legal Documents

背景

大型语言模型（LLM）在处理事务性法律文档（如合同、协议）的问答任务时，最直接的方法是将整个语料库注入到每次查询的上下文窗口中（全量注入）。这种基线方法理论上能最大化检索召回率，但其 token 开销随语料库规模线性增长，而非随问题复杂度变化；同时，长上下文性能退化问题也随 token 数量加剧。为了在保持答案质量的同时大幅降低 token 消耗，研究者探讨了两种结构化检索方案：基于嵌入的检索（NAVEMBED）与基于 LLM 导航的紧凑结构索引（NAVINDEX），并与全量注入进行了系统比较。该工作发表于 arXiv（cs.CL），提交时间为 2026 年 7 月 7 日。

核心内容

研究团队在一个专有的结构感知分块（structure-aware chunking）基础上，构建了两种检索模式，并在一个包含 20 个问题的法律文档基准测试（其中 18 个问题涉及文档内的具体信息，2 个为超出范围的控制问题）上进行评估，所有问题均带有经过验证的 ground-truth 答案。评估使用了一种位置偏差受控、参考锚定的成对判断器（pairwise judge），以衡量语义检索与全量注入之间的输出质量差异。

• 全量注入（baseline）：每次查询时，将整个法律文档语料库的全部文本直接放入 LLM 的上下文窗口。优点是召回率理论上 100%，但 token 开销巨大，且长上下文可能导致性能下降。
• NAVEMBED（嵌入检索）：利用通用文本嵌入模型（如 GTE）将文档分块并建立向量索引，然后对每个问题执行相似性检索，选出最相关的块送入 LLM 上下文。
• NAVINDEX（LLM 导航紧凑索引）：构建一个紧凑的结构化索引，由 LLM 通过逐步导航（而非全局检索）找到相关段落，进一步压缩上下文 token 量。

主要结果：

• 在 18 个文档内问题上，NAVEMBED 与全量注入在 16 个问题上持平（pairwise judge 判定为无显著差异），全量注入仅在 2 个问题上更优。同时，NAVEMBED 处理的输入 token 数量减少了 17.3 倍（使用通用文本嵌入 GTE 配置时，token 减少可达 29.9 倍，但持平率略低）。
• 对于 2 个超出范围的控制问题，两种检索模式均与全量注入被判定为持平。
• NAVINDEX 在所有 18 个文档内问题上均与全量注入持平，且其总 token 占用仅为全量注入的 1/1.61（即减少了约 38%），回答上下文（answering context）大小的缩减高达 ~56 倍，同时美元成本降低了 25%。
• 研究进一步推导了一个缓存切换规则（caching-crossover rule）：如果采用缓存方案（即预先缓存语料库的上下文），则只有在语料库规模小于大约 10 倍检索载荷（retrieval payload）时，全量注入才在美元成本上更便宜；否则检索方案更具成本优势。该规则的适用范围与不确定性在第 8 节中进行了量化分析。

关键要点

• 全量注入并非最优解：尽管是检索召回率的上限，但 token 开销和长上下文退化使其在规模化场景下效率低下。
• 检索模式可实现质量持平：在 16/18 和 18/18 的问题上，NAVEMBED 与 NAVINDEX 均与全量注入输出质量无显著差异，证明结构化检索在事务性法律文档分析中可行。
• Token 效率提升显著：NAVEMBED 减少 17–30 倍输入 token，NAVINDEX 减少回答上下文约 56 倍，总 token 占用减少 1.61 倍。
• 成本收益明确：NAVINDEX 在美元成本上降低 25%（相对全量注入），且缓存交叉规则帮助决策何时该用全量注入、何时该用检索。
• 结构化索引比嵌入检索更紧凑：NAVINDEX 以更小的 token 占用（总 token 1.61x vs. 17x+）实现同等质量，表明紧凑索引在多步导航中更节省 token。
• 控制问题不引入偏见：两个超出范围的控制问题（out-of-scope）在所有模式下均持平，验证了检索不会因筛选而遗漏关键信息。

意义与影响

该工作为法律文档分析场景下的 LLM 应用提供了一个实用的效率-质量权衡指南。其核心贡献在于：

1. 方法论验证：首次在事务性法律文档这一高价值、高精度领域，系统比较了全量注入、嵌入检索与紧凑导航索引三种范式，并给出了经过严格控制的 pairwise 判断结果。
2. Token 效率突破：证明了通过结构感知分块和紧凑索引导航，可将 LLM 的上下文 token 需求降低两个数量级（回答上下文缩减 56 倍），同时不牺牲回答质量——这对 Token 敏感的商业部署（如按 token 计费的 API）具有直接的成本优势。
3. 决策框架：缓存交叉规则提供了一个简洁的数学条件（语料库大小 vs. 检索载荷的 10 倍关系），帮助企业根据自身语料规模快速选择最优推理策略。
4. 对 RAG 系统的启示：传统 RAG 多依赖嵌入检索（如 NAVEMBED），而 NAVINDEX 证明了基于 LLM 导航的紧凑索引在 token 效率上更优，可能引导未来 RAG 系统向多步推理与索引优化方向发展。
5. 局限性：研究结果基于一个 20 问题的基准测试（含 2 个控制问题），样本量有限；且 NAVINDEX 的构建与导航需要额外的工程实现。未来需在更大规模、更多样化的法律文档任务中验证其泛化性。