Agentic Legal RAG Challenge 2026: como Sparks of intelligence testou os limites do agentic RAG

A equipe da Sparks of intelligence publicou uma análise detalhada de sua participação no Agentic Legal RAG Challenge 2026 — um hackathon internacional focado em legal RAG. Esta não é uma história sobre uma vitória espetacular, mas um relatório de engenharia útil sobre por que os sistemas de busca de documentos costumam falhar durante a preparação de contexto em vez de durante a seleção de LLM.

Como o hackathon foi organizado

A competição foi conduzida pela EORA AI Applications and Services. Os participantes precisavam construir um sistema que respondesse perguntas sobre documentos do Dubai International Financial Centre (DIFC). O hackathon ocorreu em dois estágios: de 11 a 19 de março de 2026, os participantes trabalharam com 30 documentos e 100 perguntas, e na final, que aconteceu de 20 a 22 de março de 2026, o volume cresceu para 300 documentos e 900 perguntas.

O fundo de prêmios era de $32.000, e mais de 300 pessoas participaram da competição. A dificuldade não era apenas o volume.

Os organizadores deliberadamente incorporaram diferentes tipos de respostas: booleano, nome, data, número e texto livre. Ou seja, um único modelo de geração não era suficiente — o sistema precisava extrair fatos com precisão, manter contexto e não gastar muito tempo e tokens. Para respostas em texto livre, avaliação por LLM foi usada, e os critérios-chave incluíram precisão, velocidade e custo de processamento.

Essencialmente, os participantes foram testados não na capacidade de "conectar um chatbot", mas na maturidade de todo o loop de recuperação.

Duas versões do sistema

A equipe montou duas arquiteturas em uma única pilha: Qdrant como banco de dados vetorial, LlamaIndex para trabalhar com índices e abstrações de LLM, e Unstructured — para extrair texto de PDFs preservando a estrutura. Depois disso, os caminhos divergiram.

A primeira versão era maximamente prática: chunking por páginas com sobreposição, busca híbrida, filtragem por metadados e expressões regulares. A segunda versão era notavelmente mais ambiciosa: chunking hierárquico, análise preliminar de estrutura via LLM e um roteador de agente que seleciona a ferramenta de busca apropriada para uma pergunta específica.

• A versão simples dividiu documentos por páginas e imediatamente forneceu grounding claro.
• A busca lá foi construída em uma mistura de vetores, metadados e filtros regex.
• A versão do agente usava um roteador e quatro ferramentas: busca de metadados, correspondência exata, comparação de documentos e busca híbrida.
• Ambos os esquemas aplicaram um reranker para embaralhar os top-k candidatos e aumentar relevância.

Na prática, a arquitetura simples se mostrou mais robusta. Poderia ser montada rapidamente, o comportamento era previsível e a fonte das respostas era mais fácil de rastrear. O esquema do agente parecia mais forte no papel, mas se mostrou mais caro em tempo: duas chamadas de LLM, chunking instável e mais pontos de falha. Mesmo depois de corrigir alguns erros, a equipe não conseguiu executar completamente e ajustar todo o pipeline. Para um hackathon com prazo limite rigoroso, isso é crítico: complexidade extra consome rapidamente a vantagem de uma arquitetura "inteligente".

Onde tudo quebrou

O principal problema foi o chunking. O mesmo padrão de divisão funcionava diferentemente em páginas diferentes, e pequenos fragmentos sem sentido tinham que ser simplesmente colados a pedaços adjacentes. No esquema simples, regex também atrapalhou: aceleravam a busca por padrões, mas facilmente perdiam casos necessários ou produziam falsos positivos. Uma questão separada surgiu sobre grounding: primeiro, os links e metadados necessários não eram carregados adequadamente, depois isso foi corrigido, mas com o crescimento de grounding veio uma queda em precisão. Uma boa ilustração de que sistemas de recuperação raramente são otimizados por uma única métrica sem efeitos colaterais.

"Em prazos tão apertados, é praticamente impossível construir tal

sistema sem agentes de código."

Os resultados finais apenas confirmaram isso. A solução simples alcançou precisão de 0,79 em 0,63 de grounding e demonstrou comportamento estável, se não ideal. A versão mais complexa do agente perdeu em precisão no estágio preliminar e funcionou mais lentamente, e na final nem foi enviada devido a erros de API antes do prazo. Os autores alertam separadamente sobre outra armadilha: agentes de código são úteis para encapsulamento e tarefas rotineiras, mas em configurações complexas podem substituir etapas reais com stubs, "números mágicos" ou hacks regex estreitos que parecem soluções, mas não resistem a testes reais.

O que isso significa

A análise ilustra bem o status real de agentic RAG em 2026. Em tarefas envolvendo documentos legais, não é o esquema mais vistoso que vence, mas o que controla chunking, grounding, metadados e testes. Para equipes construindo busca com IA em bases de conhecimento internas, a conclusão é simples: primeiro você precisa construir recuperação confiável e mensurabilidade, e apenas depois adicionar roteadores, agentes e orquestração complexa.