Agentic Legal RAG Challenge 2026: como a Sparks of intelligence testou os limites do RAG agêntico

A equipe Sparks of intelligence publicou uma análise detalhada de sua participação no Agentic Legal RAG Challenge 2026, um hackathon internacional de RAG jurídico. Não é a história de uma vitória retumbante, mas um relatório de engenharia útil sobre por que sistemas de busca em documentos costumam quebrar mais na preparação do contexto do que na escolha do próprio LLM.

Como o hackathon foi organizado

A competição foi realizada pela empresa EORA AI Applications and Services. Os participantes precisavam construir um sistema que responde a perguntas sobre documentos dos tribunais do Centro Financeiro Internacional de Dubai (DIFC). O hackathon teve duas etapas: de 11 a 19 de março de 2026, os participantes trabalharam com 30 documentos e 100 perguntas, e na final, realizada de 20 a 22 de março de 2026, o volume subiu para 300 documentos e 900 perguntas. O prêmio total foi de 32 000 dólares, e ao todo participaram mais de 300 pessoas.

A dificuldade não estava só no volume. Os organizadores definiram previamente diferentes tipos de resposta: boolean, name, date, number e free text. Um único modelo de geração não bastava: o sistema precisava extrair um fato com precisão, manter o contexto e não gastar tempo e tokens demais. As respostas em texto livre foram avaliadas por um LLM, e entre os critérios principais estavam precisão, velocidade e custo de processamento. Na prática, os participantes não eram testados pela capacidade de «plugar um chatbot», mas pela maturidade de todo o circuito de retrieval.

Duas versões do sistema

A equipe montou duas arquiteturas sobre a mesma stack: Qdrant como banco vetorial, LlamaIndex para índices e abstrações de LLM, e Unstructured para extrair texto de PDFs preservando a estrutura. A partir daí, os caminhos se separaram.

A primeira versão foi a mais prática possível: chunking por páginas com sobreposição, busca híbrida e filtragem por metadados e expressões regulares. A segunda foi bem mais ambiciosa: chunking hierárquico, análise prévia da estrutura via LLM e um agente roteador que escolhe a ferramenta de busca adequada para cada pergunta.

• A versão simples dividia os documentos por páginas e já entregava um grounding claro.
• Sua busca combinava vetores, metadados e filtros regex.
• A versão agêntica usava um roteador e quatro ferramentas: busca por metadados, correspondência exata, comparação de documentos e busca híbrida.
• Os dois esquemas usavam um reranker para reordenar os candidatos top-k e melhorar a relevância.

Na prática, a arquitetura simples se mostrou mais estável. Dava para montá-la rápido, o comportamento era previsível e a fonte da resposta era mais fácil de rastrear. O esquema agêntico parecia mais forte no papel, mas custou mais tempo: duas chamadas ao LLM, chunking instável e mais pontos de falha. Mesmo após corrigir parte dos erros, a equipe não conseguiu rodar e ajustar completamente todo o pipeline. Num hackathon com prazo apertado, isso é crítico: a complexidade extra rapidamente consome o ganho de uma arquitetura «inteligente».

Onde tudo quebrou

O principal problema foi o chunking. O mesmo modelo de divisão funcionava de um jeito em uma página e de outro em outra, e fragmentos pequenos sem sentido tinham de ser simplesmente colados aos trechos vizinhos. No esquema simples, os regex também atrapalharam: aceleravam a busca por padrões, mas deixavam passar casos relevantes com facilidade ou geravam falsos positivos.

O grounding apareceu como questão à parte: no início, os links e metadados necessários não eram carregados corretamente; depois isso foi corrigido, mas, com a melhora do grounding, a precisão caiu. É uma boa ilustração de que um sistema de retrieval raramente é otimizado por uma única métrica sem efeitos colaterais.

«Construir um sistema desse tipo em prazos tão curtos é praticamente

impossível sem agentes de código».

Os resultados finais só confirmaram isso. A solução simples chegou a uma precisão de 0,79 com grounding de 0,63 e mostrou comportamento estável, ainda que não perfeito. A versão agêntica, mais complexa, perdeu em precisão na etapa preliminar e era mais lenta, e na final nem chegou a ser entregue por causa de erros de API antes do prazo.

Os autores também alertam para outra armadilha: agentes de código são úteis para a infraestrutura de apoio e tarefas rotineiras, mas, diante de um problema complexo, podem trocar etapas reais por stubs, «números mágicos» ou gambiarras de regex muito estreitas, que parecem uma solução, mas não resistem a uma verificação real.

O que isso significa

A análise mostra bem o status real do RAG agêntico em 2026. Em tarefas com documentos jurídicos, ganha não o esquema mais vistoso, mas aquele em que chunking, grounding, metadados e testes estão sob controle. Para equipes que constroem busca com IA em bases de conhecimento internas, a conclusão é simples: primeiro é preciso ter um retrieval confiável e mensurável, e só depois adicionar roteadores, agentes e orquestração complexa.