Claude Code ayudó a subir un RAG jurídico a 0.791, pero la final de ARLC 2026 chocó con la escala

El caso de ARLC 2026 muestra lo frágil que puede ser un RAG en tareas reales. En cinco días, el autor y Claude Code subieron el resultado de un pipeline jurídico de 0.034 a 0.791 en el warmup, y después se toparon con un muro de escalado en la final.

Del bug al salto

El reto exigía algo más que responder preguntas sobre sentencias y leyes: había que indicar con exactitud las páginas fuente. Por eso el grounding se convirtió en un multiplicador de toda la puntuación final: incluso con buenas respuestas, las referencias débiles dejaban el score casi a cero. Eso ocurrió al principio: la primera versión obtuvo 0.034, aunque la precisión en parte de las respuestas ya era alta.

El problema no estaba en el modelo ni en el retrieval, sino en el formato de salida. El autor gastó tres intentos antes de detectar un error simple: en el campo doc_id se enviaba el nombre del archivo con .pdf, mientras que el sistema esperaba un identificador sin extensión. Esa corrección subió el grounding de 0.05 a 0.55 y el resultado global de 0.034 a 0.438. Después, el pipeline llegó a 0.791 en el warmup en 17 iteraciones.

También ayudó la matemática de F-beta con β=2.5: mostró que las páginas de más perjudican más de lo que parece, y que cada referencia superflua puede costar entre un 10% y un 22% de calidad de grounding.

Arquitectura y técnicas

El mejor resultado lo dio un pipeline que indexaba páginas completas de PDF en lugar de chunks. Es una decisión importante en RAG jurídico: si la métrica comprueba el acierto en una página concreta, el chunking complica la correspondencia con el origen y añade ruido. Para la búsqueda se usó un esquema híbrido de BM25 más embeddings, combinados con RRF, y se añadió OCR para los escaneos. Además, el autor limitó el número de páginas devueltas y enrutó por separado las preguntas de comparación, que exigen cotejar dos documentos.

• Retrieval por página en lugar de chunks
• BM25 + embeddings + Reciprocal Rank Fusion
• OCR de respaldo para páginas vacías o escaneadas
• Límite de páginas por respuesta según el tipo de pregunta
• Ramas deterministas rápidas para casos sencillos

«Primero valida el formato de salida.

Después mejora la calidad».

Claude Code ocupa una línea aparte en el caso. Con su ayuda, el autor escribió unas 3000 líneas de código en siete módulos en cinco días y logró 17 versiones en lugar de las 3–5 que, según sus estimaciones, habría hecho a mano. El agente aceleró ediciones, refactorizaciones, envíos y la revisión de diffs antes de enviar. Pero las decisiones estratégicas siguieron en manos humanas: qué métricas arreglar primero, cómo interpretar las regresiones y cuándo no tocar un prompt ya ajustado.

Dónde se rompió todo

El corpus del warmup constaba de 30 documentos y 100 preguntas; el de la final, de 303 documentos, 4244 páginas y 900 preguntas. Ahí quedó claro que un pipeline que funciona bien con un conjunto pequeño no tiene por qué trasladarse a uno grande.

Primero apareció un bug de caché: el sistema indexó por error los 30 documentos del warmup en lugar de los 303 de la final, y las respuestas null subieron a 37. Tras limpiar la caché el problema desapareció, pero el fallo principal persistió: el score final cayó un 42%, hasta 0.457.

Las causas de fondo eran arquitectónicas. El enorme documento DIFC Courts Rules empezó a contaminar los resultados de muchas consultas jurídicas, los consultation papers con el mismo número pero distinto año rompían la desambiguación, y la regex del número de ley sustituía las respuestas sobre multas por números de leyes. Un paquete rápido de ocho correcciones parecía razonable, pero empeoró el equilibrio de las métricas: parte de la precisión determinista mejoró, mientras que el grounding y el score global cayeron aún más.

Este análisis es valioso porque no vende magia de asistente de IA. Claude Code aportó velocidad, pero no eliminó el trabajo de ingeniería esencial: validar el formato, calcular la métrica, probar un cambio cada vez y comprobar el sistema a una escala cercana a producción. La conclusión del autor es tajante: si el conjunto de evaluación es varias veces menor que el corpus real, no estás probando el retrieval, sino la suerte.

Qué significa

Para los equipos que construyen productos RAG, es una buena ducha fría. No gana el stack más complejo, sino la disciplina: formato de salida exacto, métrica clara, mínimo ruido en las referencias y pruebas a escala real. Los asistentes de programación con IA ya ofrecen una aceleración seria, pero todavía no sustituyen el criterio de ingeniería ni la responsabilidad sobre las decisiones de arquitectura.