Benchmark da JioHotstar compara seis formas de retrieval para agentes de código e não acha vencedor único

A JioHotstar, plataforma de streaming indiana, publicou em 11 de novembro de 2026 um benchmark comparando seis formas de dar contexto a agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → que navegam em bases de código grandes. O trabalho, conduzido por Abhishek Bansal, Senior Staff Engineer da empresa, testou se adicionar camadas de retrieval (busca e recuperação de informação) realmente melhora o desempenho de agentes como o Claude Sonnet, ou se só aumenta custo e complexidade sem ganho correspondente.

A pergunta é prática para qualquer time que já conectou um agente de codificação a um repositório grande: vale a pena indexar tudo semanticamente, ou o agente se vira melhor com grep, leitura de arquivo e busca de símbolo? A JioHotstar tentou responder com dados em vez de achismo, e o resultado desmonta a ideia de que mais contexto é sempre melhor contexto.

Os seis métodos em jogo

O estudo comparou as seguintes abordagens de navegação em código para agentes:

• Filesystem baseline: repositório local, com operações padrão de busca e leitura de arquivo, sem camada extra.
• Sourcebot: busca de texto indexada, definição e referência de símbolos, leitura de arquivos.
• Graphify: representação em grafo do código.
• CocoIndex Code: indexação semântica de código.
• Repowise: outra camada de indexação e busca sobre repositórios.
• RAG interno da JioHotstar: pipeline próprio de retrieval-augmented generation construído pela empresa.

Todas as abordagens foram avaliadas usando subconjuntos do SWE-bench e do CodeScaleBench, além de um harness de perguntas e respostas construído sobre a própria base de código da JioHotstar. O modelo usado para resolver as tarefas foi o Claude Sonnet, e as métricas incluíram acurácia na tarefa, consumo de tokens, número de turnos do agente e usabilidade das ferramentas do ponto de vista do próprio agente.

Onde a busca estrutural levou vantagem

No SWE-bench Lite, que reúne tarefas mais simples e concretas, o baseline de filesystem (sem nenhuma camada de retrieval) se manteve competitivo. Adicionar busca indexada ou semântica geralmente trouxe overhead sem melhorar os resultados de forma consistente nessas tarefas mais diretas.

Já no SWE-bench Verified, que concentra tarefas mais difíceis, o cenário mudou: o Sourcebot (busca de texto indexada, definição e referência de símbolos, leitura de arquivo) superou o baseline tanto em acurácia quanto em custo, consumindo menos tokens para chegar ao resultado. Isso sugere que o ganho da busca estrutural aparece justamente quando o problema exige navegar por muitas referências cruzadas no código, não em tarefas pontuais.

Quando a busca semântica compensa

O CodeScaleBench mostrou um padrão diferente do SWE-bench: ali, a retrieval semântica ajudou mais quando o agente precisava interpretar descrições de problema ambíguas e mapeá-las para detalhes de implementação que não ficavam óbvios numa busca exata de texto ou símbolo. Em outras palavras, quando o requisito não diz literalmente onde mexer no código, uma camada que entende significado (e não só string) faz diferença.

A conclusão da JioHotstar é que as abordagens de retrieval não são intercambiáveis: cada uma resolve um tipo de problema, e escolher errado custa tokens e turnos de agente sem ganho de acurácia. É o oposto de tratar retrieval como peça universal que sempre se encaixa.

O que o agente realmente usa

O relatório também chamou atenção para o design das ferramentas oferecidas ao agente. Na prática, os agentes preferiram operações familiares de desenvolvedor, como busca de texto, leitura de arquivo e localização de símbolo, em vez de abstrações de mais alto nível que exigiam verificação adicional antes de confiar no resultado.

Em resumo: dar ao agente uma ferramenta mais sofisticada não significa que ele vai usá-la melhor. Se a abstração exige um passo extra de checagem, o agente tende a preferir o caminho mais simples e verificável, mesmo que teoricamente mais lento.

A pergunta que fica: código não é só código

Em post no LinkedIn comentando o estudo, Siddharth Vaithinathan levantou uma questão arquitetural mais ampla: se agentes de codificação deveriam entender não só o código, mas também a empresa que o produziu. Segundo ele, indexar o repositório sozinho não captura por que decisões arquiteturais foram tomadas, quais restrições as moldaram, nem o que incidentes anteriores ensinaram ao time de engenharia.

Vaithinathan sugeriu estender o conhecimento do agente para além de código e documentação, incluindo arquitetura, restrições, decisões, justificativas, incidentes e resultados. Esse contexto adicional ajudaria o agente a avaliar escolhas de design existentes antes de propor mudanças, principalmente em sistemas onde a experiência operacional histórica influencia decisões arquiteturais. É um ponto que nenhuma das seis ferramentas testadas resolve: todas indexam código, nenhuma indexa a memória institucional do time.

A ressalva sobre o próprio benchmark

Tarun Bhargava, também comentando o estudo, levantou uma questão relevante para a interpretação de qualquer benchmark desse tipo: números de custo e acurácia precisariam vir de múltiplas rodadas da mesma configuração, já que as avaliações usam subconjuntos limitados e modelos probabilísticos. Um único run pode esconder variância que muda a conclusão sobre qual abordagem é melhor. A JioHotstar não publicou, pelo material disponível, quantas repetições rodou por configuração.

O que muda para quem constrói agentes aqui

A recomendação final da JioHotstar é pragmática: manter ferramentas de filesystem como linha de base, usar busca estrutural para problemas concretos e bem definidos, e reservar indexação semântica para requisitos ambíguos ou que cruzam várias partes do sistema. A empresa também recomenda medir os traços de uso de ferramentas (tool-use traces) junto com a acurácia da tarefa, para saber se a retrieval está de fato reduzindo exploração desnecessária ou só adicionando ruído.

Para quem no Brasil está conectando agentes como Claude Code, Cursor ou Copilot a um monorepo grande, o recado prático é direto: antes de contratar ou montar uma camada de RAG sobre o código, vale medir se o ganho de acurácia compensa o custo extra de tokens e turnos, e em qual tipo de tarefa isso acontece.

Empilhar indexação semântica em cima de um agente que já resolve bem tarefas simples com grep e leitura de arquivo pode ser dinheiro jogado fora; faltar indexação semântica num time que lida com requisitos ambíguos e sistemas legados grandes pode ser o contrário. A escolha, segundo o próprio estudo, não é sobre qual ferramenta é melhor em abstrato, mas sobre qual tarefa você está tentando resolver.

Fonte: InfoQ: JioHotStar Benchmarks Knowledge Bases for AI Coding Agents

Fonte: InfoQ