Resumen Técnico: ¿Inyectar o Navegar? Recuperación Eficiente en Tokens para el Análisis de Documentos Legales Transaccionales por LLM

Declaración del Problema

El artículo aborda el desafío de responder preguntas sobre un corpus de documentos legales transaccionales (por ejemplo, acuerdos, enmiendas, cartas laterales, anexos). El enfoque de referencia, denominado inject (inyectar), consiste en colocar todo el corpus en la ventana de contexto del Modelo de Lenguaje Extenso (LLM) para cada consulta. Si bien esto maximiza la recuperación de información al asegurar que no se pierda nada, sufre de dos limitaciones críticas a medida que el corpus crece:

1. Huella de Tokens: El costo escala con el tamaño del corpus en lugar de con la pregunta, lo que resulta ineficiente para conjuntos de documentos grandes.
2. Degradación del Contexto Largo: Los LLM exhiben una atención desigual a través de entradas largas, perdiendo a menudo información posicionada en la parte media de la ventana de contexto.
3. Límites de la Ventana de Contexto: Los asuntos legales suelen exceder la ventana de contexto máxima de los modelos actuales, lo que hace imposible la inyección completa.

Los benchmarks existentes (por ejemplo, CUAD, ContractNLI) suelen operar sobre documentos únicos y no logran capturar las dependencias entre instrumentos (por ejemplo, términos definidos, referencias cruzadas, enmiendas) inherentes al análisis legal transaccional.

Metodología

Los autores evaluaron dos estrategias de recuperación estructurada frente al baseline de inject utilizando un método de fragmentación (chunking) consciente de la estructura, desarrollado en Syntheia. La evaluación se llevó a cabo mediante un benchmark de 20 preguntas (18 vinculadas a documentos con verdad de referencia verificada, 2 controles fuera de alcance) a través de seis documentos legales.

Protocolo de Evaluación

• Juez: Un juez de pares anclado a referencias y con control de sesgo de posición (usando claude-opus-4-7) comparó las respuestas del baseline y el método de recuperación. Se otorgó un "empate" solo si ambas direcciones de comparación estaban de acuerdo, certificando que ambas respuestas eran igualmente consistentes con la verdad de referencia.
• Métricas: El estudio rastreó la huella de tokens (total de tokens a los que el modelo atiende, incluyendo el contexto en caché) y el costo en dólares (gasto operativo, considerando los descuentos por almacenamiento en caché de prompts). Estos se trataron como mét la métricas separadas porque el almacenamiento en caché reduce el costo sin reducir el número de tokens que el modelo debe procesar.

Los Tres Modos

1. Inject (Baseline): El corpus completo se coloca en la ventana de contexto para cada consulta.
2. Navigate-Embeddings (navembed): Los documentos se pre-incrustan (embedded) en un árbol de nodos. En el momento de la consulta, los $k$ nodos más similares se recuperan mediante similitud de coseno (con re-clasificación opcional de codificador cruzado/cross-encoder) y se colocan en el contexto.
3. Navigate-Index (navindex): Un enfoque sin vectores donde un LLM navega por un índice compacto y estructurado. El índice contiene:
   • Banderas semánticas booleanas: (por ejemplo, isDefinition, hasMoney, hasLiabilityLimit).
   • Metadatos estructurales: Encabezados, referencias de cláusulas y grafos explícitos de referencias cruzadas/términos definidos.
   • Proceso de Navegación: El LLM escanea el índice (S1) para seleccionar hasta 10 IDs de nodos basados en filtros booleanos y resúmenes, luego recupera de forma determinista el texto literal de esos nodos (S2) para generar la respuesta (S3).

Resultados Clave

Inject vs. navembed

• Rendimiento: La configuración más fuerte (recuperación semántica + re-clasificación, RUN-012) fue juzgada como empatada con inject en 16 de las 18 preguntas vinculadas a documentos (inject fue preferido en 2).
• Eficiencia: Esta configuración redujo la huella de tokens de entrada en 17.3× (188K tokens vs. 3.26M tokens).
• Costo: Logró un costo en dólares menor que inject en todas las ejecuciones validadas.
• Modo de Fallo: Una configuración híbrida de BM25 (RUN-011) sufrió de "sesgo de longitud", inflando la carga útil y fallando en reducir los costos de manera efectiva.

Inject vs. navindex

• Rrendimiento: La configuración optimizada de tokens (Config 6) fue juzgada como empatada con inject en todas las 18 preguntas vinculadas a documentos y en ambos controles fuera de alcance. Esto representa la mayor tasa de empate de una sola ejecución en el estudio.
• Eficiencia:
  • Huella de Tokens: Redujo el total de tokens de entrada en 1.61×.
  • Contexto de Respuesta: Redujo el contexto al que el modelo atiende durante la generación de la respuesta en aproximadamente 56× (2.9K tokens vs. 163K tokens).
  • Costo: Registró un costo en dólares un 25% menor ($1.21 vs. $1.61) en comparación con inject.
• Mecanismo: El éxito de navindex se atribuye a su codificación explícita de señales estructurales (referencias cruzadas y términos definidos), que la similitud de coseno por sí sola no puede capturar, permitiendo al modelo recuperar el contexto exacto necesario sin depender únicamente de la proximidad semántica.

Análisis de Costos: La Regla de Cruce de Caché (Caching Crossover Rule)

El documento deriva una regla de forma cerrada para determinar cuándo el inject con caché es más barato en dólares que la recuperación:
$$C < 10 \times R$$
Donde $C$ es el tamaño del corpus y $R$ es la carga útil de recuperación.

• Implicación: El inject con caché es más barato solo si el corpus es aproximadamente 10 veces más pequeño que la carga útil de recuperación.
• Realidad: Para el corpus de 163K tokens probado, tanto navembed como navindex fueron más baratos que el inject con caché en estado estacionario. Sin embargo, para corpora muy pequeños (<35K tokens), inject sigue siendo la opción más económica.
• Advertencia: Esto asume una sesión "caliente" donde la caché es válida (TTL de 5 minutos). En flujos de trabajo asíncronos, el costo de escritura de la caché puede incurrirse repetidamente, erosionando la ventaja de inject.

Contribuciones Clave

1. Evaluación por Pares: Una evaluación rigurosa, con control de sesgo de posición, de la inyección de corpus completo frente a la recuperación estructurada en un conjunto de preguntas legales con verdad de referencia verificada.
2. Diseño de navindex: El diseño de un descriptor de navegación para instrumentos legales que codifica banderas booleanas tipadas, grafos de referencias cruzadas y resolución de términos definidos, operacionalizado mediante prompts específicos.
3. Regla de Cruce de Caché: Una regla económica de forma cerrada que separa la huella de tokens del costo en dólares, destacando que la reducción de tokens es un beneficio estructural mientras que el ahorro de costos depende de la sesión.
4. Catálogo de Modos de Fallo: Identificación de modos de fallo específicos a evitar, tales como el sesgo de longitud de BM25, la sobreselección de solo títulos y la selección de nodos sin límite.

Significancia y Reivindicaciones

El artículo sostiene que la recuperación estructurada es una alternativa viable y, a menudo, superior a la inyección de corpus completo para el análisis de documentos legales, siempre que la estrategia de recuperación respete las dependencias estructurales de los textos legales.

• Preservación de la Calidad: La recuperación estructurada puede igualar la calidad de respuesta de la inyección completa (medida por un juez anclado en referencias) mientras reduce drásticamente la huella de tokens y el contexto de respuesta.
• Fidelidad Estructural: El enfoque navindex demuestra que codificar las señales estructurales legales (referencias cruzadas, términos definidos) directamente en el índice es más efectivo que confiar únicamente en la similitud vectorial, particularmente para preguntas que requieren la reconciliación de enmiendas y anexos.
• Viabilidad Económica: Aunque la inyección completa es más barata para corpora muy pequeños o consultas de sesión única, la recuperación estructurada se convierte en la opción económicamente superior a medida que el tamaño del corpus crece o cuando la carga útil de recuperación es significativamente menor que el corpus completo.

Los autores mantienen la modestia en sus afirmaciones, señalando que la evaluación está limitada a una sola familia de modelos, un conjunto específico de 20 preguntas y que no mide directamente la recuperación de información (precisión/exhaustividad) debido a la falta de etiquetas de nodos de verdad de referencia. Enfatizan que el veredicto de "empate" certifica la equivalencia en la consistencia con la verdad de referencia, no la corrección absoluta, y que los resultados son específicos para el corpus y la ingeniería de prompts evaluados.