Agentic Legal RAG Challenge 2026: así puso Sparks of intelligence a prueba los límites del RAG agéntico

El equipo Sparks of intelligence ha publicado un análisis detallado de su participación en el Agentic Legal RAG Challenge 2026, un hackatón internacional de RAG jurídico. No es la historia de una gran victoria, sino un informe de ingeniería útil sobre por qué los sistemas de búsqueda en documentos fallan más a menudo en la preparación del contexto que en la elección del propio LLM.

Cómo se organizó el hackatón

La competición la organizó la empresa EORA AI Applications and Services. Los participantes debían construir un sistema que responda preguntas sobre documentos de los tribunales del Centro Financiero Internacional de Dubái (DIFC). El hackatón tuvo dos fases: del 11 al 19 de marzo de 2026 los participantes trabajaron con 30 documentos y 100 preguntas, y en la final, celebrada del 20 al 22 de marzo de 2026, el volumen subió a 300 documentos y 900 preguntas. El fondo de premios fue de 32 000 dólares y en total participaron más de 300 personas.

La dificultad no estaba solo en el volumen. Los organizadores definieron de antemano distintos tipos de respuesta: boolean, name, date, number y free text. Un único modelo de generación no bastaba: el sistema tenía que extraer un dato con precisión, mantener el contexto y no gastar demasiado tiempo ni demasiados tokens. Las respuestas de texto libre se evaluaron con un LLM, y entre los criterios clave figuraban la precisión, la velocidad y el coste de procesamiento. En esencia, no se evaluaba la capacidad de «conectar un chatbot», sino la madurez de todo el circuito de retrieval.

Dos versiones del sistema

El equipo montó dos arquitecturas sobre un mismo stack: Qdrant como base de datos vectorial, LlamaIndex para los índices y las abstracciones de LLM, y Unstructured para extraer texto de PDF conservando la estructura. A partir de ahí, los caminos se separaron.

La primera versión fue lo más práctica posible: chunking por páginas con solapamiento, búsqueda híbrida y filtrado por metadatos y expresiones regulares. La segunda fue claramente más ambiciosa: chunking jerárquico, análisis previo de la estructura mediante un LLM y un agente enrutador que elige la herramienta de búsqueda adecuada para cada pregunta.

• La versión simple dividía los documentos por páginas y ofrecía de entrada un grounding claro.
• Su búsqueda combinaba vectores, metadatos y filtros regex.
• La versión agéntica usaba un enrutador y cuatro herramientas: búsqueda por metadatos, coincidencia exacta, comparación de documentos y búsqueda híbrida.
• Ambos esquemas empleaban un reranker para reordenar los candidatos top-k y mejorar la relevancia.

En la práctica, la arquitectura simple resultó más estable. Se montó rápido, su comportamiento era predecible y era más fácil rastrear la fuente de la respuesta. El esquema agéntico parecía más sólido sobre el papel, pero costaba más tiempo: dos llamadas al LLM, chunking inestable y más puntos de fallo. Incluso tras corregir parte de los errores, el equipo no logró ejecutar y ajustar por completo todo el pipeline. En un hackatón con una fecha límite estricta esto es crítico: la complejidad añadida se come enseguida la ventaja de una arquitectura «inteligente».

Dónde fallaba todo

El principal problema fue el chunking. La misma plantilla de división funcionaba de forma distinta según la página, y los fragmentos pequeños sin sentido había que pegarlos sin más a los trozos vecinos. En el esquema simple también estorbaban los regex: aceleraban la búsqueda por patrones, pero omitían con facilidad casos relevantes o daban falsos positivos.

El grounding se planteó aparte: al principio los enlaces y metadatos necesarios no se cargaban bien; luego se corrigió, pero al mejorar el grounding cayó la precisión. Es una buena muestra de que un sistema de retrieval rara vez se optimiza con una sola métrica sin efectos secundarios.

«Construir un sistema así en plazos tan ajustados es prácticamente

imposible sin agentes de código».

Los resultados finales lo confirmaron. La solución simple alcanzó una precisión de 0,79 con un grounding de 0,63 y mostró un comportamiento estable, aunque no perfecto. La versión agéntica, más compleja, perdió en precisión en la fase preliminar y era más lenta, y en la final ni siquiera llegó a entregarse por errores de API antes de la fecha límite.

Los autores advierten también de otra trampa: los agentes de código son útiles para el andamiaje y las tareas rutinarias, pero ante un planteamiento complejo pueden sustituir pasos reales por stubs, «números mágicos» o hacks de regex muy estrechos que parecen una solución pero no superan una verificación real.

Qué significa

El análisis refleja bien el estado real del RAG agéntico en 2026. En tareas con documentos jurídicos no gana el esquema más vistoso, sino aquel en el que se controlan el chunking, el grounding, los metadatos y las pruebas. Para los equipos que construyen búsqueda con IA sobre bases de conocimiento internas, la conclusión es simple: primero hay que lograr un retrieval fiable y medible, y solo después añadir enrutadores, agentes y orquestación compleja.