Optimización de RAG para tareas legales

Optimizando RAG para Documentos Legales: Lecciones del Reto Legal Agentic RAG

El equipo de desarrollo probó RAG sobre un corpus de documentos legales del Reto Legal Agentic RAG. El enfoque principal fue mejorar el anclaje y la precisión de las citas. Los documentos del DIFC (sentencias judiciales, leyes, actos regulatorios) se procesaron desde PDFs a Markdown mediante renderizado visual de páginas como imágenes, seguido de procesamiento con Qwen 3.5-9b en un Mac Studio M3 Ultra.

El segmentado semántico impulsado por embeddings densos (FRIDA) y dispersos (GTE) dividió 30 documentos en ~2.000 fragmentos. Cada fragmento incluye:

• text: una idea o hecho completo
• path: identificador del documento fuente
• context: descripción del contenido circundante dentro del documento

El contexto se genera mediante LLM (Qwen), alimentando tanto el fragmento como el documento completo. Esto compensa la pérdida de coherencia durante la división. Los embeddings se almacenan en Qdrant. Indexar 30 documentos tomó ~2 horas, con cuello de botella en la latencia de prellenado durante la generación de contexto (15–20 segundos por fragmento localmente).

Pipeline de Generación de Respuestas

Para cada consulta:

• Intención: LLM genera búsquedas alternativas.
• Selección: vectorizada mediante FRIDA/GTE, buscada en Qdrant usando RRF, devolviendo los mejores N fragmentos. LLM los reordena y filtra según relevancia.
• Respuesta: los fragmentos filtrados se envían al LLM con instrucciones para responder y citar números específicos de fragmentos para garantizar anclaje.

Métricas de competición: Total = (0.7 × S_det + 0.3 × S_asst) × G × T × F. Factor clave G (anclaje) valida referencias a números de página. S_det mide precisión de respuestas deterministas (booleanas, fechas, nombres, números). S_asst evalúa calidad de texto libre mediante puntuación basada en LLM.

Resultados y Benchmarking de Experimentos

15 pruebas previas (30 docs, 100 preguntas) mostraron progreso desde RAG básico hasta versiones optimizadas. Iteraciones clave:

| Versión | S_det | S_asst | G | Total |

|--------|--------|---------|---|--------|

| v3 (GPT-5.4) | 0.843 | 0.667 | 0.451 | 0.362 |

| v5 (CAG Qwen 1M) | 0.971 | 0.553 | 0.563 | 0.403 |

| v6 (BM25) | 0.943 | 0.540 | 0.390 | 0.269 |

| v7 (BM25 + RRF semántico) | 0.871 | 0.567 | 0.717 | 0.468 |

| v11 (MORAG v3) | 1.000 | 0.680 | 0.757 | 0.664 |

| v15 (final) | 0.986 | 0.733 | 0.901 | 0.780 |

G mejoró de 0.45 a 0.90—esto impulsó el éxito. BM25 puro tuvo peor desempeño (Total: 0.269). CAG (prompt con contexto completo de 350K tokens en Qwen 3.5-Flash) destacó en S_det (0.971) pero falló en anclaje.

RAG integrado de OpenAI en PDF obtuvo 0.362—precisión aceptable, pero mala citación.

Comparación de Enfoques: RAG vs Alternativas

• BM25: Búsqueda rápida por palabras clave (TF-IDF), pero ignora significado—bajo G (0.390).
• CAG: Contexto completo en prompt (1M tokens), alto S_det, pero el anclaje sufre sin referencias explícitas.
• RAG Híbrido (MORAG): FRIDA/GTE + RRF + reordenamiento por LLM + razonamiento adaptado al tipo de pregunta. Logró 1.000 S_det, 0.901 G.

Elemento agente: tras la selección, el modelo decide autónomamente el siguiente paso (activar/desactivar razonamiento, fijar mapas).

MORAG (github.com/catonmoon/morag) superó al RAG integrado de OpenAI/Grok en todos los métricas.

El Mac Studio M3 Ultra manejó bien el indexado (embeddings nativos), pero tuvo problemas con tareas de prellenado intensivo—se cambió a OpenRouter.

Conclusiones Clave

• Anclaje (G) es el factor dominante: incluso respuestas perfectas fracasan sin citas precisas a páginas.
• Recuperación híbrida (densa + dispersa + RRF) + reordenamiento por LLM mejora drásticamente la relevancia de fragmentos.
• Segmentado semántico con generación de contexto preserva coherencia sin el costo de modelos grandes.
• El tipo de pregunta dicta el modo: razonamiento para respuestas libres, directo para respuestas deterministas.

— Editorial Team