Claude Code elevó Legal RAG a 0.791, pero la final ARLC 2026 enfrentó limitaciones de escala

Claude Code ayudó a elevar el Legal RAG a 0.791, pero la final de ARLC 2026 se topó con un muro de escala

El caso ARLC 2026 muestra bien lo frágil que puede ser el RAG en tareas reales. En cinco días, el autor, trabajando con Claude Code, elevó el resultado de un pipeline legal de 0.034 a 0.791 en warmup, y después se topó con un muro duro de escalabilidad en la final.

De un bug a un salto

El desafío requería no solo responder preguntas sobre decisiones judiciales y leyes, sino señalar con precisión las páginas-fuente. Por eso, el grounding se convirtió en un multiplicador de toda la puntuación final: incluso con respuestas fuertes, citas débiles prácticamente anulaban la puntuación. Esto es exactamente lo que sucedió al inicio: la primera versión mostró 0.

034, aunque la precisión en la parte de respuestas ya era alta. El problema no estaba en el modelo ni en el retrieval, sino en el formato de salida. El autor pasó tres intentos antes de notar un error simple: el campo doc_id estaba enviando el nombre del archivo con .

pdf, mientras que el sistema esperaba un identificador sin extensión. Una única corrección elevó el grounding de 0.05 a 0.

55, y el resultado general de 0.034 a 0.438.

El pipeline entonces alcanzó 0.791 en warmup en 17 iteraciones. Las matemáticas F-beta con β=2.

5 también ayudaron por separado: mostraron que las páginas extras dañan más de lo que parece, y cada enlace extra puede costar 10–22% de calidad de grounding.

Arquitectura y técnicas

El mejor resultado provino de un pipeline que indexaba no chunks, sino páginas completas de PDF. Esta es una elección importante para RAG legal: si la métrica verifica el aterrizaje en una página específica, el chunking complica la atribución inversa y genera ruido. Para la búsqueda, se utilizó un esquema híbrido—BM25 más embeddings con fusión RRF—y se agregó OCR para escaneos. Además, el autor limitó el número de páginas en la salida y enrutó por separado preguntas de comparación, donde dos documentos necesitan ser comparados.

• Retrieval a nivel de página en lugar de chunks
• BM25 + embeddings + Reciprocal Rank Fusion
• Fallback de OCR para páginas vacías o escaneadas
• Limitación del número de páginas en respuestas por tipo de pregunta
• Ramas determinísticas rápidas para casos simples

"Primero valida el formato de salida.

Luego mejora la calidad."

Una línea separada del caso es el papel de Claude Code. Con su ayuda, el autor reunió alrededor de 3000 líneas de código en siete módulos en cinco días y logró hacer 17 versiones en lugar de las típicas 3–5 manualmente. El agente aceleró correcciones, refactorización, ejecución de envíos y verificación de diffs antes del envío. Pero las decisiones estratégicas siguieron siendo humanas: cuáles métricas arreglar primero, cómo interpretar regresiones y cuándo no tocar un prompt ya ajustado.

Dónde todo se rompió

En warmup, el corpus consistía en 30 documentos y 100 preguntas, pero en la final eran 303 documentos, 4244 páginas y 900 preguntas. Fue aquí donde quedó claro que un pipeline que funciona bien en un conjunto pequeño no tiene que escalar necesariamente a uno más grande. Primero, surgió un bug de caché: el sistema indexaba incorrectamente 30 documentos de warmup en lugar de 303 finales, lo que hizo que las respuestas nulas se dispararan a 37.

Después de limpiar el caché, el problema desapareció, pero el colapso principal permaneció: la puntuación final cayó 42%, a 0.457. Las causas raíz resultaron ser arquitectónicas.

Un documento enorme, DIFC Courts Rules, comenzó a contaminar la salida para muchas consultas legales; consultation papers con los mismos números pero años diferentes rompían la desambiguación; y una regex para law number estaba sustituyendo respuestas sobre multas con números de leyes. Un intento de aplicar rápidamente un lote de ocho correcciones parecía razonable, pero en conjunto empeoró el balance de métricas: parte de la precisión determinística creció, pero el grounding y la puntuación general decayeron aún más. Este análisis es valioso porque no vende magia de asistente de IA.

Claude Code dio velocidad, pero no eliminó el trabajo de ingeniería principal: validar formato, calcular métricas, probar un cambio a la vez y verificar el sistema a una escala cercana a la producción. La conclusión principal del autor es dura: si el conjunto de eval es muchas veces menor que el corpus de producción, no estás probando retrieval, sino suerte.

Lo que esto significa

Para equipos que construyen productos RAG, esta es una buena ducha fría. La victoria no la lleva el stack más complejo, sino la disciplina: formato de salida preciso, métricas claras, ruido mínimo en citas y validación a escala real. Los asistentes de codificación de IA ya proporcionan una aceleración seria, pero por ahora no reemplazan el pensamiento de ingeniería y la responsabilidad por las decisiones arquitectónicas.