Claude Code a porté Legal RAG à 0.791, mais la finale ARLC 2026 s'est heurtée aux limites d'échelle

Claude Code a aidé à faire passer le Legal RAG à 0.791, mais la finale de l'ARLC 2026 s'est heurtée à un mur d'échelle

Le cas ARLC 2026 montre bien à quel point le RAG peut être fragile dans les tâches réelles. En cinq jours, l'auteur, travaillant avec Claude Code, a fait passer le résultat d'un pipeline juridique de 0.034 à 0.791 en warmup, puis s'est heurté à un mur dur de scalabilité en finale.

D'un bug à une percée

Le défi exigeait non seulement de répondre à des questions sur les décisions judiciaires et les lois, mais d'indiquer précisément les pages source. Pour cette raison, le grounding est devenu un multiplicateur de tout le score final : même avec de bonnes réponses, des citations faibles anulaient presque le score. C'est exactement ce qui s'est passé au départ : la première version a affiché 0.

034, bien que la précision sur la partie réponses était déjà élevée. Le problème ne venait pas du modèle ni du retrieval, mais du format de sortie. L'auteur a fait trois tentatives avant de remarquer une simple erreur : le champ doc_id envoyait le nom du fichier avec .

pdf, alors que le système attendait un identifiant sans extension. Une seule correction a élevé le grounding de 0.05 à 0.

55, et le résultat global de 0.034 à 0.438.

Le pipeline a alors atteint 0.791 en warmup en 17 itérations. Les mathématiques F-beta avec β=2.

5 ont également aidé séparément : elles ont montré que les pages supplémentaires nuisent plus qu'il n'y paraît, et chaque lien supplémentaire peut coûter 10–22% de qualité de grounding.

Architecture et techniques

Le meilleur résultat a été obtenu avec un pipeline qui indexait non des chunks, mais des pages entières de PDF. C'est un choix important pour le RAG juridique : si la métrique vérifie l'atterrissage sur une page spécifique, le chunking complique l'attribution inverse et génère du bruit. Pour la recherche, un schéma hybride a été utilisé—BM25 plus embeddings avec fusion RRF—et l'OCR a été ajouté pour les documents numérisés. En plus de cela, l'auteur a limité le nombre de pages en sortie et a routé séparément les questions de comparaison, où deux documents doivent être comparés.

• Retrieval au niveau de la page au lieu de chunks
• BM25 + embeddings + Reciprocal Rank Fusion
• Fallback OCR pour les pages vides ou numérisées
• Limitation du nombre de pages dans les réponses par type de question
• Branches déterministes rapides pour les cas simples

« Commencez par valider le format de sortie.

Ensuite, améliorez la qualité. »

Une ligne distincte du cas est le rôle de Claude Code. Avec son aide, l'auteur a assemblé environ 3000 lignes de code sur sept modules en cinq jours et a réussi 17 versions au lieu des 3–5 typiques à la main. L'agent a accéléré les corrections, la refactorisation, les exécutions de soumissions et les vérifications de diffs avant l'envoi. Mais les décisions stratégiques restaient humaines : quelles métriques corriger en premier, comment interpréter les régressions et quand ne pas toucher à un prompt déjà ajusté.

Où tout s'est cassé

En warmup, le corpus comportait 30 documents et 100 questions, mais en finale il y avait 303 documents, 4244 pages et 900 questions. C'est là qu'il est devenu clair qu'un pipeline qui fonctionne bien sur un petit ensemble n'a pas nécessairement à passer à un ensemble plus grand. D'abord, un bug de cache a émergé : le système indexait incorrectement 30 documents de warmup au lieu de 303 finaux, ce qui a fait que les réponses nulles ont grimpé à 37.

Après avoir vidé le cache, le problème a disparu, mais l'effondrement principal est resté : le score final a chuté de 42%, à 0.457. Les causes racines se sont avérées être architecturales.

Un énorme document, DIFC Courts Rules, a commencé à polluer la sortie pour de nombreuses requêtes juridiques ; des consultation papers avec les mêmes numéros mais des années différentes cassaient la désambiguïsation ; et une regex pour law number substituait les réponses sur les amendes par les numéros de loi. Une tentative d'appliquer rapidement un lot de huit correctifs semblait raisonnable, mais dans l'ensemble a aggravé l'équilibre des métriques : une partie de la précision déterministe a augmenté, mais le grounding et le score global ont décliné davantage. Cette analyse est précieuse parce qu'elle ne vend pas la magie de l'assistant IA.

Claude Code a fourni la vitesse, mais n'a pas éliminé le travail d'ingénierie principal : valider le format, calculer les métriques, tester un changement à la fois et vérifier le système à une échelle proche de la production. La conclusion principale de l'auteur est dure : si l'ensemble d'éval est plusieurs fois plus petit que le corpus de production, vous testez non pas le retrieval, mais la chance.

Ce que cela signifie

Pour les équipes qui construisent des produits RAG, c'est une bonne douche froide. La victoire ne va pas à la pile la plus complexe, mais à la discipline : format de sortie précis, métriques claires, bruit minimal dans les citations et validation à échelle réelle. Les assistants de codage IA fournissent déjà une accélération sérieuse, mais pour l'instant ne remplacent pas la pensée d'ingénierie et la responsabilité des décisions architecturales.