Claude Code ajudou a levar um RAG jurídico a 0,791, mas a final do ARLC 2026 esbarrou na escala

O caso do ARLC 2026 mostra como o RAG pode ser frágil em tarefas reais. Em cinco dias, o autor e o Claude Code elevaram o resultado de um pipeline jurídico de 0.034 para 0.791 no warmup, e depois bateram em uma parede de escalabilidade na final.

Do bug ao salto

O desafio exigia mais do que responder perguntas sobre decisões judiciais e leis: era preciso indicar com exatidão as páginas de origem. Por isso, o grounding virou um multiplicador de toda a nota final: mesmo com boas respostas, referências fracas deixavam o score quase zerado. Foi o que aconteceu no início: a primeira versão marcou 0.034, embora a precisão em parte das respostas já fosse alta.

O problema não estava no modelo nem no retrieval, e sim no formato de saída. O autor gastou três tentativas até notar um erro simples: o campo doc_id recebia o nome do arquivo com .pdf, enquanto o sistema esperava um identificador sem extensão. Essa correção elevou o grounding de 0.05 para 0.55 e o resultado geral de 0.034 para 0.438. Depois, o pipeline chegou a 0.791 no warmup em 17 iterações.

A matemática do F-beta com β=2.5 também ajudou: ela mostrou que páginas extras prejudicam mais do que parece, e cada referência desnecessária pode custar de 10% a 22% da qualidade do grounding.

Arquitetura e técnicas

O melhor resultado veio de um pipeline que indexava páginas inteiras de PDF, e não chunks. É uma escolha importante para RAG jurídico: se a métrica verifica o acerto em uma página específica, o chunking complica o mapeamento de volta à origem e gera ruído. Para a busca, usou-se um esquema híbrido de BM25 com embeddings, combinados via RRF, e OCR para documentos escaneados. Além disso, o autor limitou o número de páginas na resposta e roteou separadamente as perguntas de comparação, que exigem confrontar dois documentos.

• Retrieval por página em vez de chunks
• BM25 + embeddings + Reciprocal Rank Fusion
• OCR de fallback para páginas vazias ou escaneadas
• Limite de páginas por resposta conforme o tipo de pergunta
• Ramificações determinísticas rápidas para casos simples

«Primeiro valide o formato de saída.

Depois melhore a qualidade».

O Claude Code tem papel à parte no caso. Com ele, o autor montou cerca de 3000 linhas de código em sete módulos em cinco dias e conseguiu 17 versões, em vez das 3–5 que, pelas estimativas dele, faria manualmente. O agente acelerou edições, refatoração, envios e a checagem de diffs antes do submit. Mas as decisões estratégicas continuaram com o humano: quais métricas consertar primeiro, como interpretar regressões e quando não mexer em um prompt já ajustado.

Onde tudo quebrou

No warmup, o corpus tinha 30 documentos e 100 perguntas; na final, eram 303 documentos, 4244 páginas e 900 perguntas. Ali ficou claro que um pipeline que vai bem em um conjunto pequeno não necessariamente se sustenta em um grande.

Primeiro surgiu um bug de cache: o sistema indexou por engano os 30 documentos do warmup em vez dos 303 da final, e as respostas null subiram para 37. Depois de limpar o cache, o problema sumiu, mas a falha principal permaneceu: o score final caiu 42%, para 0.457.

As causas-raiz eram arquiteturais. O enorme documento DIFC Courts Rules passou a poluir os resultados de muitas consultas jurídicas, os consultation papers com o mesmo número mas anos diferentes quebraram a desambiguação, e a regex do número de lei trocava respostas sobre multas por números de leis. Um pacote rápido de oito correções parecia razoável, mas piorou o equilíbrio das métricas: parte da precisão determinística subiu, enquanto o grounding e o score geral caíram ainda mais.

Esta análise é valiosa porque não vende mágica de assistente de IA. O Claude Code deu velocidade, mas não eliminou o trabalho central de engenharia: validar o formato, calcular a métrica, testar uma mudança por vez e checar o sistema em escala próxima à de produção. A principal conclusão do autor é dura: se o conjunto de avaliação é muitas vezes menor que o corpus real, você não está testando o retrieval, e sim a sorte.

O que isso significa

Para times que constroem produtos RAG, é um bom choque de realidade. Quem vence não é o stack mais complexo, e sim a disciplina: formato de saída exato, métrica clara, mínimo de ruído nas referências e testes em escala real. Os assistentes de programação com IA já oferecem uma aceleração séria, mas ainda não substituem o raciocínio de engenharia nem a responsabilidade pelas decisões de arquitetura.