Agentic Legal RAG Challenge 2026: cómo Sparks of intelligence probó los límites del agentic RAG

El equipo de Sparks of intelligence publicó un análisis detallado de su participación en el Agentic Legal RAG Challenge 2026 — un hackathon internacional centrado en legal RAG. No es una historia sobre una victoria espectacular, sino un informe de ingeniería útil sobre por qué los sistemas de búsqueda de documentos suelen fallar durante la preparación del contexto en lugar de durante la selección de LLM.

Cómo se organizó el hackathon

La competencia fue conducida por EORA AI Applications and Services. Los participantes necesitaban construir un sistema que respondiera preguntas sobre documentos del Centro Financiero Internacional de Dubái (DIFC). El hackathon se desarrolló en dos etapas: del 11 al 19 de marzo de 2026, los participantes trabajaron con 30 documentos y 100 preguntas, y en la final, que tuvo lugar del 20 al 22 de marzo de 2026, el volumen creció a 300 documentos y 900 preguntas.

El fondo de premios fue de $32.000, y más de 300 personas participaron en la competencia. La dificultad no era solo el volumen.

Los organizadores incorporaron deliberadamente diferentes tipos de respuestas: booleano, nombre, fecha, número y texto libre. Es decir, un único modelo de generación no era suficiente — el sistema tenía que extraer hechos con precisión, mantener contexto y no gastar demasiado tiempo y tokens. Para respuestas en texto libre, se utilizó evaluación por LLM, y los criterios clave incluían precisión, velocidad y costo de procesamiento.

En esencia, se probaba a los participantes no en la capacidad de "conectar un chatbot", sino en la madurez de todo el circuito de recuperación.

Dos versiones del sistema

El equipo armó dos arquitecturas en una sola pila: Qdrant como base de datos vectorial, LlamaIndex para trabajar con índices y abstracciones de LLM, e Unstructured — para extraer texto de PDFs preservando la estructura. Después de eso, los caminos divergieron.

La primera versión era máximamente práctica: fragmentación por páginas con superposición, búsqueda híbrida, filtrado por metadatos y expresiones regulares. La segunda versión era notablemente más ambiciosa: fragmentación jerárquica, análisis preliminar de estructura mediante LLM y un enrutador de agente que selecciona la herramienta de búsqueda apropiada para una pregunta específica.

• La versión simple dividió documentos por páginas y proporcionó inmediatamente grounding claro.
• La búsqueda allí se basaba en una mezcla de vectores, metadatos y filtros regex.
• La versión del agente usaba un enrutador y cuatro herramientas: búsqueda de metadatos, coincidencia exacta, comparación de documentos y búsqueda híbrida.
• Ambos esquemas aplicaron un reranker para reorganizar los candidatos top-k y aumentar relevancia.

En la práctica, la arquitectura simple resultó ser más robusta. Podía ser armada rápidamente, el comportamiento era predecible y la fuente de las respuestas era más fácil de rastrear. El esquema del agente se veía más fuerte en el papel, pero resultó ser más costoso en tiempo: dos llamadas de LLM, fragmentación inestable y más puntos de fallo. Incluso después de corregir algunos errores, el equipo no logró ejecutar completamente y sintonizar todo el pipeline. Para un hackathon con una fecha límite estricta, esto es crítico: la complejidad adicional consume rápidamente la ventaja de una arquitectura "inteligente".

Dónde todo se rompió

El principal problema resultó ser la fragmentación. El mismo patrón de división funcionaba de manera diferente en diferentes páginas, y pequeños fragmentos sin sentido tenían que ser simplemente pegados a trozos adyacentes. En el esquema simple, las expresiones regulares también fueron un obstáculo: aceleraban la búsqueda por patrones, pero fácilmente perdían casos necesarios o producían falsos positivos. Un problema separado surgió en torno al grounding: primero, los enlaces y metadatos necesarios no se cargaban correctamente, luego se solucionó, pero con el crecimiento del grounding vino una caída en precisión. Una buena ilustración de que los sistemas de recuperación rara vez se optimizan por una única métrica sin efectos secundarios.

"En plazos tan ajustados, es prácticamente imposible construir tal

sistema sin agentes de código."

Los resultados finales solo confirmaron esto. La solución simple alcanzó precisión de 0,79 con grounding de 0,63 y demostró un comportamiento estable, aunque no ideal. La versión más compleja del agente perdió en precisión en la etapa preliminar y funcionó más lentamente, y en la final ni siquiera fue entregada debido a errores de API antes de la fecha límite. Los autores advierten por separado sobre otra trampa: los agentes de código son útiles para encapsulamiento y tareas rutinarias, pero en configuraciones complejas pueden sustituir pasos reales con stubs, "números mágicos" o hacks regex estrechos que se ven como soluciones, pero no resisten pruebas reales.

Qué significa todo esto

El análisis ilustra bien el estado real de agentic RAG en 2026. En tareas que involucran documentos legales, no es el esquema más vistoso el que gana, sino el que controla fragmentación, grounding, metadatos y pruebas. Para equipos que construyen búsqueda con IA en bases de conocimiento internas, la conclusión es simple: primero necesitas construir recuperación confiable y mensurabilidad, y solo entonces agregar enrutadores, agentes y orquestración compleja.