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

L'équipe de Sparks of intelligence a publié une analyse détaillée de sa participation au Agentic Legal RAG Challenge 2026 — un hackathon international axé sur legal RAG. Ce n'est pas une histoire de victoire spectaculaire, mais un rapport d'ingénierie utile sur les raisons pour lesquelles les systèmes de recherche de documents échouent généralement lors de la préparation du contexte plutôt que lors de la sélection du LLM.

Comment le hackathon a été organisé

La compétition a été menée par 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 s'est déroulé en deux étapes : du 11 au 19 mars 2026, les participants ont travaillé avec 30 documents et 100 questions, et en finale, qui s'est tenue du 20 au 22 mars 2026, le volume s'est développé à 300 documents et 900 questions.

Le fonds des prix était de 32 000 dollars, et plus de 300 personnes ont participé à la compétition. La difficulté ne résidait pas seulement dans le volume. Les organisateurs ont délibérément incorporé différents types de réponses : booléen, nom, date, nombre et texte libre.

Autrement dit, un seul modèle de génération ne suffisait pas — le système devait extraire les faits avec précision, maintenir le contexte et ne pas consommer trop de temps et de jetons. Pour les réponses en texte libre, l'évaluation par LLM a été utilisée, et les critères clés comprenaient la précision, la vitesse et le coût de traitement. Essentiellement, les participants ont été testés non sur leur capacité à « connecter un chatbot », mais sur la maturité de l'ensemble de la boucle de récupération.

Deux versions du système

L'équipe a assemblé deux architectures sur une seule pile : Qdrant comme base de données vectorielle, LlamaIndex pour travailler avec les indices et les abstractions LLM, et Unstructured — pour extraire le texte des PDF tout en préservant la structure. Après cela, les chemins ont divergé.

La première version était au maximum pratique : chunking par pages avec chevauchement, recherche hybride, filtrage par métadonnées et expressions régulières. La deuxième version était notablement plus ambitieuse : chunking hiérarchique, analyse préalable de la structure via LLM et un routeur d'agent qui sélectionne l'outil de recherche approprié pour une question spécifique.

• La version simple a divisé les documents par pages et a fourni immédiatement un grounding clair.
• La recherche s'y est construite sur un mélange de vecteurs, de métadonnées et de filtres regex.
• La version agent utilisait un routeur et quatre outils : recherche de métadonnées, correspondance exacte, comparaison de documents et recherche hybride.
• Les deux schémas ont appliqué un reranker pour réorganiser les candidats top-k et augmenter la pertinence.

En pratique, l'architecture simple s'est avérée plus robuste. Elle pouvait être assemblée rapidement, le comportement était prévisible et la source des réponses était plus facile à tracer. Le schéma agent semblait plus fort sur le papier, mais s'est avéré plus coûteux en temps : deux appels LLM, chunking instable et plus de points de défaillance. Même après correction de certaines erreurs, l'équipe n'a pas réussi à exécuter complètement et à affiner tout le pipeline. Pour un hackathon avec une date limite stricte, c'est critique : la complexité supplémentaire consomme rapidement l'avantage d'une architecture « intelligente ».

Où tout s'est cassé

Le principal problème s'est avéré être le chunking. Le même modèle de division fonctionnait différemment sur différentes pages, et les petits fragments sans sens devaient simplement être collés à des morceaux adjacents. Dans le schéma simple, les expressions régulières ont également posé problème : elles accéléraient la recherche par motifs, mais manquaient facilement les cas nécessaires ou produisaient de faux positifs. Une question distincte s'est posée autour du grounding : d'abord, les liens et métadonnées nécessaires n'étaient pas chargés correctement, puis cela a été corrigé, mais avec la croissance du grounding est venue une baisse de précision. Une bonne illustration du fait que les systèmes de récupération sont rarement optimisés selon une seule métrique sans effets secondaires.

«

Dans des délais aussi serrés, il est pratiquement impossible de construire un tel système sans agents de code. »

Les résultats finaux n'ont que confirmé cela. La solution simple a atteint une précision de 0,79 avec un grounding de 0,63 et a démontré un comportement stable, sinon idéal. La version plus complexe de l'agent a perdu en précision à la phase préliminaire et a fonctionné plus lentement, et en finale, elle n'a même pas été soumise en raison d'erreurs API avant la date limite.

Les auteurs avertissent séparément d'un autre piège : les agents de code sont utiles pour l'encapsulation et les tâches routinières, mais dans des paramètres complexes, ils peuvent substituer des étapes réelles avec des stubs, des « nombres magiques » ou des hacks regex étroits qui ressemblent à des solutions mais ne résistent pas aux tests réels.

Ce que cela signifie

L'analyse illustre bien l'état réel du agentic RAG en 2026. Dans les tâches impliquant des documents juridiques, ce n'est pas le schéma le plus voyant qui gagne, mais celui où le chunking, le grounding, les métadonnées et les tests sont contrôlés. Pour les équipes construisant une recherche avec IA sur des bases de connaissances internes, la conclusion est simple : d'abord, vous devez construire une récupération fiable et la mesurabilité, et ce n'est qu'ensuite que vous ajoutez des routeurs, des agents et une orchestration complexe.