Claude Code elevou Legal RAG para 0.791, mas a final ARLC 2026 esbarrou em problemas de escala

Claude Code ajudou a elevar o Legal RAG para 0.791, mas a final do ARLC 2026 esbarrou na escala

O caso ARLC 2026 mostra bem como o RAG pode ser frágil em tarefas reais. Em cinco dias, o autor, trabalhando com Claude Code, elevou o resultado de um pipeline legal de 0.034 para 0.791 no warmup, e depois bateu em uma parede dura de escalabilidade na final.

De um bug a um salto

O desafio exigia não apenas responder perguntas sobre decisões judiciais e leis, mas apontar com precisão as páginas-fonte. Por isso, o grounding se tornou um multiplicador de toda a pontuação final: mesmo com respostas fortes, citações fracas praticamente zeravam o score. Foi exatamente o que aconteceu no início: a primeira versão mostrou 0.

034, embora a precisão na parte de respostas já fosse alta. O problema não estava no modelo nem no retrieval, mas no formato de saída. O autor gastou três tentativas antes de notar um erro simples: o campo doc_id estava enviando o nome do arquivo com .

pdf, enquanto o sistema esperava um identificador sem extensão. Um único corretivo elevou o grounding de 0.05 para 0.

55, e o resultado geral de 0.034 para 0.438.

O pipeline então atingiu 0.791 no warmup em 17 iterações. A matemática F-beta com β=2.

5 também ajudou separadamente: mostrou que páginas extras prejudicam mais do que parece, e cada link extra pode custar 10–22% de qualidade de grounding.

Arquitetura e técnicas

O melhor resultado veio de um pipeline que indexava não chunks, mas páginas inteiras de PDF. Esta é uma escolha importante para RAG legal: se a métrica verifica o desembarque em uma página específica, chunking complica a atribuição reversa e gera ruído. Para busca, foi usada uma estratégia híbrida—BM25 mais embeddings com fusão RRF—e OCR foi adicionado para digitalizações. Além disso, o autor limitou o número de páginas na saída e roteou separadamente questões de comparação, onde dois documentos precisam ser comparados.

• Retrieval no nível de página em vez de chunks
• BM25 + embeddings + Reciprocal Rank Fusion
• Fallback de OCR para páginas vazias ou digitalizadas
• Limite do número de páginas nas respostas por tipo de pergunta
• Ramificações determinísticas rápidas para casos simples

"Primeiro valide o formato de saída.

Depois melhore a qualidade."

Uma linha separada do caso é o papel do Claude Code. Com sua ajuda, o autor montou cerca de 3000 linhas de código em sete módulos em cinco dias e conseguiu fazer 17 versões em vez dos típicos 3–5 manualmente. O agente acelerou correções, refatoração, execução de envios e verificação de diffs antes do envio. Mas as decisões estratégicas continuaram com o humano: quais métricas corrigir primeiro, como interpretar regressões e quando não mexer em um prompt já ajustado.

Onde tudo desabou

No warmup, o corpus consistia em 30 documentos e 100 perguntas, mas na final eram 303 documentos, 4244 páginas e 900 perguntas. Foi aí que ficou claro que um pipeline que funciona bem em um conjunto pequeno não precisa necessariamente escalar para um maior. Primeiro, um bug de cache apareceu: o sistema indexava incorretamente 30 documentos de warmup em vez de 303 finais, o que fez as respostas nulas subirem para 37.

Após limpar o cache, o problema desapareceu, mas o colapso principal permaneceu: a pontuação final caiu 42%, para 0.457. As causas raiz se mostraram arquiteturais.

Um documento enorme, DIFC Courts Rules, começou a poluir a saída para muitas consultas legais; consultation papers com os mesmos números, mas anos diferentes, quebravam a desambiguação; e uma regex para law number estava substituindo respostas sobre multas por números de leis. Uma tentativa de aplicar rapidamente um pacote de oito correções parecia razoável, mas em conjunto piorou o equilíbrio de métricas: parte da precisão determinística cresceu, mas o grounding e a pontuação geral declinaram ainda mais. Esta análise é valiosa porque não vende magia de assistente de IA.

Claude Code deu velocidade, mas não removeu o trabalho de engenharia principal: validar formato, calcular métricas, testar uma mudança de cada vez e verificar o sistema em uma escala próxima à produção. A conclusão principal do autor é dura: se o conjunto de eval é muitas vezes menor que o corpus de produção, você está testando não retrieval, mas sorte.

O que isso significa

Para equipes que constroem produtos RAG, este é um bom choque de realidade. A vitória não vai para o stack mais complexo, mas para a disciplina: formato de saída preciso, métricas claras, ruído mínimo em citações e validação em escala real. Assistentes de codificação de IA já fornecem uma aceleração séria, mas por enquanto não substituem o pensamento de engenharia e a responsabilidade pelas decisões arquiteturais.