Agentic Legal RAG Challenge 2026 : comment Sparks of intelligence a testé les limites du RAG agentique

L'équipe Sparks of intelligence a publié un retour détaillé sur sa participation à l'Agentic Legal RAG Challenge 2026, un hackathon international consacré au RAG juridique. Ce n'est pas le récit d'une victoire éclatante, mais un rapport d'ingénierie utile : il explique pourquoi les systèmes de recherche documentaire cassent plus souvent à l'étape de préparation du contexte que sur le choix du LLM lui-même.

Le fonctionnement du hackathon

La compétition était organisée par la société EORA AI Applications and Services. Les participants devaient construire un système répondant à des questions sur les documents des tribunaux du Centre financier international de Dubaï (DIFC). Le hackathon se déroulait en deux phases : du 11 au 19 mars 2026, les participants ont travaillé sur 30 documents et 100 questions, et en finale, tenue du 20 au 22 mars 2026, le volume est passé à 300 documents et 900 questions. La dotation s'élevait à 32 000 dollars et plus de 300 personnes ont participé au total.

La difficulté ne tenait pas qu'au volume. Les organisateurs avaient prévu à l'avance différents types de réponses : boolean, name, date, number et free text. Un seul modèle de génération ne suffisait donc pas : le système devait extraire un fait avec précision, conserver le contexte et ne pas consommer trop de temps ni trop de tokens. Les réponses en texte libre étaient notées par un LLM, et les critères clés incluaient la précision, la vitesse et le coût de traitement. En somme, on n'évaluait pas la capacité à « brancher un chatbot », mais la maturité de toute la chaîne de retrieval.

Deux versions du système

L'équipe a bâti deux architectures sur la même stack : Qdrant comme base vectorielle, LlamaIndex pour les index et les abstractions de LLM, et Unstructured pour extraire le texte des PDF en préservant la structure. Ensuite, les chemins ont divergé.

La première version était la plus pragmatique possible : chunking par pages avec chevauchement, recherche hybride, et filtrage par métadonnées et expressions régulières. La seconde était nettement plus ambitieuse : chunking hiérarchique, analyse préalable de la structure par un LLM, et un agent routeur qui choisit l'outil de recherche adapté à chaque question.

• La version simple découpait les documents par pages et offrait d'emblée un grounding clair.
• Sa recherche combinait vecteurs, métadonnées et filtres regex.
• La version agentique utilisait un routeur et quatre outils : recherche par métadonnées, correspondance exacte, comparaison de documents et recherche hybride.
• Les deux schémas employaient un reranker pour réordonner les candidats top-k et améliorer la pertinence.

En pratique, l'architecture simple s'est montrée plus robuste. On pouvait l'assembler vite, son comportement était prévisible et la source d'une réponse plus facile à retracer. Le schéma agentique semblait plus solide sur le papier, mais coûtait plus de temps : deux appels au LLM, un chunking instable et davantage de points de défaillance. Même après avoir corrigé une partie des erreurs, l'équipe n'a pas réussi à exécuter et à régler entièrement tout le pipeline. Pour un hackathon à l'échéance stricte, c'est critique : la complexité superflue engloutit vite le gain d'une architecture « intelligente ».

Là où tout a cassé

Le chunking a été le principal problème. Un même gabarit de découpage se comportait différemment selon les pages, et les petits fragments dépourvus de sens devaient simplement être collés aux morceaux voisins. Dans le schéma simple, les regex ont aussi gêné : ils accéléraient la recherche par motifs, mais laissaient facilement passer des cas pertinents ou produisaient des faux positifs.

Le grounding a posé une question à part : au début, les liens et métadonnées nécessaires n'étaient pas chargés correctement ; le problème a ensuite été corrigé, mais la précision a baissé à mesure que le grounding progressait. C'est une bonne illustration du fait qu'un système de retrieval s'optimise rarement sur une seule métrique sans effets secondaires.

«

Construire un tel système dans des délais aussi courts est pratiquement impossible sans agents de code ».

Les résultats finaux n'ont fait que le confirmer. La solution simple a atteint une précision de 0,79 avec un grounding de 0,63 et a montré un comportement stable, quoique imparfait. La version agentique, plus complexe, perdait en précision lors de la phase préliminaire et était plus lente ; en finale, elle n'a même pas pu être soumise en raison d'erreurs d'API avant l'échéance.

Les auteurs mettent aussi en garde contre un autre piège : les agents de code sont utiles pour l'outillage périphérique et les tâches routinières, mais face à un problème complexe, ils peuvent remplacer de vraies étapes par des stubs, des « nombres magiques » ou des bidouilles regex très étroites, qui ressemblent à une solution sans résister à une vraie vérification.

Ce que cela signifie

Ce retour d'expérience montre bien le statut réel du RAG agentique en 2026. Sur les tâches de documents juridiques, ce n'est pas le schéma le plus spectaculaire qui l'emporte, mais celui où le chunking, le grounding, les métadonnées et les tests sont maîtrisés. Pour les équipes qui construisent de la recherche IA sur des bases de connaissances internes, la conclusion est simple : il faut d'abord un retrieval fiable et mesurable, et seulement ensuite ajouter routeurs, agents et orchestration complexe.