Este site usa cookies e tecnologias afins que nos ajudam a oferecer uma melhor experiência. Ao clicar no botão "Aceitar" ou continuar sua navegação você concorda com o uso de cookies.

Aceitar

IA na veIA

[IA na veIA nº 18] O LLM é forte, mas cego: CodeRAG é o Byakugan que enxerga o repositório inteiro

23 de setembro de 2025
[IA na veIA nº 18] O LLM é forte, mas cego: CodeRAG é o Byakugan que enxerga o repositório inteiro

IA na veIA é uma iniciativa que explica os avanços da inteligência artificial com bom humor e analogias divertidas vindas direto do universo Geek. Aqui, conceitos complexos ganham vida através de comparações com filmes, séries, games e HQs, tornando a tecnologia mais próxima e muito mais divertida para todos.

A missão é democratizar o conhecimento sobre inteligência artificial, aproximando a comunidade científica do público leigo sem aquele “tecniquês” que dá sono. Ao usar referências de sagas épicas, super-heróis ou mundos de fantasia, transformamos pesquisas e inovações em histórias que qualquer fã de cultura pop entende e curte.

Essa abordagem cria uma ponte entre especialistas e curiosos, incentivando debates sobre o impacto ético, social e econômico da IA de forma leve, mas consciente. O resultado é uma conversa mais inclusiva, onde qualquer pessoa pode entender e participar da construção do nosso futuro tecnológico.

Se você é fã de IA e também vibra com referências Geek, o IA na veIA é o seu portal para explorar ciência com uma boa dose de risadas e imaginação.

Vamos revisar o paper a seguir:

  • CodeRAG: Finding Relevant and Necessary Knowledge for Retrieval-Augmented Repository-Level Code Completion
  • Link do paper
IA na veIA nº 18
IA na veIA nº 18.

Quem é Celso Sousa?

Celso Sousa é especialista e palestrante de inteligência artificial (IA), com doutorado em IA pela USP. Além disso, ele possui mais de 15 anos de experiência no mercado de IA para negócios.

Celso participou da gestão e/ou desenvolvimento de diversos projetos de IA nos setores financeiro e agronegócio. Alguns dos projetos de inteligência artificial mais relevantes na carreira dele são:

  • previsão de produtividade de fazendas;
  • reconhecimento visual de nematóides;
  • visão computacional para monitoramento de rebanhos por drones;
  • identificação de públicos vulneráveis;
  • sistema de gerenciamento de pastejo rotacionado;
  • identificação de irregularidades em notas fiscais de serviço.

Celso ministrou vários treinamentos e mentorias sobre inteligência artificial nos últimos anos. Ainda mais, ele foi Cientista Chefe na Secretaria das Finanças de Fortaleza-CE na auditoria fiscal.

O foco do Celso é desenvolver soluções de IA para empresas de todos os portes e segmentos. Entretanto, a prioridade é criar soluções de IA de baixo custo para empresas de pequeno e médio porte.

Celso iniciou a sua carreira ao abrir uma consultoria de inteligência artificial em 2009. Portanto, ele adquiriu muita experiência prática de como gerar resultados expressivos para as empresas usando IA.

A pesquisa científica do Celso é sobre classificação em grafos para alavancagem de negócios com marketing analytics. Além disso, ele publicou artigos científicos em diversas conferências internacionais de renome em 4 continentes.

Hoje ele aplica sua experiência na IA para ajudar os empresários a aumentarem os seus lucros. Ainda mais, ele implementa automações com agentes de IA para que os empresários tenham mais liberdade.

Essas automações podem ser aplicadas em diversos setores, como marketing, vendas, recursos humanos, tecnologia, financeiro, atendimento, etc.

Fale com o especialista e palestrante de inteligência artificial Celso Sousa nas redes sociais:


Visão geral do paper

Os modelos de linguagem gigantes voltados para código — os famosos code LLMs — se tornaram o sabre de luz da nova geração de desenvolvedores. Mas ao contrário do que a hype quer te fazer acreditar, eles ainda tropeçam quando precisam lidar com contextos de repositórios inteiros. Isso não é um bug, é uma limitação estrutural que a academia e a indústria tentam ignorar.

A promessa do repository-level code completion é clara: gerar trechos de código não apenas com base no que está ao redor do cursor, mas considerando toda a informação disponível em um repositório. Em outras palavras, entender a floresta, não só a árvore. Só que, como mostrou Zhang et al em suas investigações anteriores, a maioria dos sistemas ainda olha para as últimas linhas do código e acha que isso basta. Não basta.

Li et al já tinham apontado em 2018 que o contexto limitado ao arquivo atual ignorava dependências cruciais entre arquivos. Wang & Li, em 2021, reforçaram que representações mais complexas, como ASTs e grafos, poderiam trazer mais semântica para o jogo. Ainda assim, modelos como DraCo (Cheng et al, 2024) ou RepoCoder (Zhang et al, 2023) só arranham a superfície do problema. DraCo, por exemplo, aposta em fluxos de dados como forma de representar dependências, mas falha quando a semântica do código exige mais do que relações de variáveis.

Enquanto isso, Gao et al em 2023 revisaram o panorama do RAG — Retrieval-Augmented Generation — e mostraram que a ideia de combinar LLMs com bases de conhecimento externas tem fôlego. Só que adaptar RAG para código é outro monstro. Jin et al (2024) e Dong et al (2024) mostraram que há uma desconexão constante entre o que o retriever busca e o que o LLM realmente precisa. Um problema de alinhamento que também foi discutido por Zhang et al (2024), com foco em QA, mas ignorado na prática por muita gente do mundo do código.

Sun et al (2023) foram além e sugeriram que LLMs poderiam atuar como re-rankers em cenários de reranqueamento zero-shot, mas não investigaram a fundo os impactos disso em código. Pradeep et al (2023) apostaram em listwise prompting, confiando que LLMs obedeceriam listas estruturadas. Spoiler: obedecem mal quando são pequenos e custam caro quando são grandes.

Para quem achava que usar embeddings e cosine similarity resolveria tudo, Sarthi et al (2024) mostram que a segmentação do código ainda é um calcanhar de Aquiles. Separar classes ou funções por tamanho ou delimitadores ignora a semântica da linguagem de programação. Ou seja: cortar um “if” no meio pode ser tão catastrófico quanto deixar de carregar uma runa em Diablo.

Outro ponto ignorado é o custo computacional. Shao et al (2023) defenderam a iteração entre geração e recuperação, mas ignoraram o peso que isso coloca em inferência. Se a sua navegação no código vira um loop infinito de geração-recuperação, até o Chewbacca desiste.

A maioria dos modelos ainda trata o código como texto plano. Mesmo quando Liu et al (2024) criaram grafos que combinam dependências de controle, dados e fluxo, o resultado não escala bem. É como usar um mapa da Terra Média para encontrar um endereço no Brooklyn.

A solução? Parar de fingir que RAG genérico resolve tudo. As limitações específicas do domínio de código pedem métodos específicos. O desafio é alinhar a estrutura do repositório, a semântica do código e as preferências do LLM. E não, isso não se resolve só jogando mais parâmetros no modelo.


A CodeRAG entra em cena como a Manopla do Infinito da completude de código

Zhang et al propõem a CodeRAG como uma framework que ataca diretamente os três vilões do code completion em repositório: consultas mal formuladas, recuperação limitada e desalinhamento com o LLM. E fazem isso com um combo de habilidades que parece saído de um RPG de alto nível.

Primeiro, abandonam a ideia de que as últimas k linhas do código são suficientes para formar uma boa query. Em vez disso, usam um mecanismo baseado em log-probabilities para encontrar os trechos do código que mais influenciam a previsão do LLM. Um probing guiado por confiança probabilística. Uma espécie de “Sentido Aranha” do modelo, que mostra onde está o verdadeiro perigo semântico.

Depois, em vez de escolher um único caminho de recuperação (sparse, dense ou dataflow), a CodeRAG junta tudo. É literalmente o multiverso da recuperação de código: você tem matching exato com TF-IDF, similaridade semântica com embeddings e fluxo de dados com análise de dependências. Cada caminho cobre um tipo de relação diferente. E sim, há casos em que só um deles resolve. Mas quando combinados, aumentam drasticamente a cobertura e a chance de pegar aquele pedaço obscuro de código que o LLM precisa para completar uma função corretamente.

O terceiro ponto é o reranking. Aqui entra o BESTFIT — uma abordagem de reranqueamento baseada nas preferências do LLM. Em vez de tentar gerar uma lista completa e ordenada (o que é caro e impreciso), o modelo é instruído a escolher o trecho mais relevante em cada janela de candidatos. Um processo iterativo otimizado com heap sort, que reduz drasticamente o custo computacional.

E pra quem ainda acha que usar LLM como reranker é pesado, os autores oferecem uma versão distilada — uma espécie de “sidekick” do LLM original — que aprende com as escolhas do modelo maior e assume a reranquear quando necessário. Uma versão treinada com LoRA, focada apenas no ranking. O custo cai, e a performance ainda se mantém competitiva.


O apocalipse da completude: sem a CodeRAG, os LLMs continuam como padawans perdidos no repositório

Imagine usar um modelo poderoso como o StarCoder2-3B e vê-lo tropeçar porque não conseguiu recuperar a definição de uma classe ou a inicialização de uma variável num outro arquivo. A ausência de uma framework como CodeRAG faz exatamente isso. O modelo completa o código como se estivesse vendado, guiado apenas por sorte e tokens anteriores.

É como jogar Dota sem ver o minimapa. Você pode até acertar uns combos, mas vai ser emboscado eventualmente. A falta de recuperação estruturada e relevante transforma o LLM em um bardo tagarela que sabe recitar padrões, mas não entende a lore do código.

Sem reranking inteligente, os trechos recuperados são jogados aleatoriamente no prompt, criando mais ruído do que sinal. O LLM se perde no meio de APIs irrelevantes, funções depreciadas e imports fora de contexto. A performance cai, os bugs sobem e a confiança na IA desmorona.


O escudo vibranium da CodeRAG: como o método defende os LLMs dos seus próprios erros

A espada de Gryffindor: extraindo contexto com precisão

A primeira etapa do CodeRAG é construir a code knowledge base. Nada de dividir o código arbitrariamente. Eles extraem funções, variáveis globais, métodos de classes e atributos diretamente da AST. A estrutura sintática do código é respeitada, e o conhecimento é armazenado de forma semanticamente coesa.

Isso transforma a base de dados em um arsenal organizado, como o inventário de um mago: cada item está em seu slot, pronto para ser usado.

O Byakugan dos LLMs: usando log-probability como guia

O query construction é baseado na capacidade do LLM de prever com alta confiança. Em vez de adivinhar, o modelo testa diferentes trechos de código para ver quais aumentam sua certeza na hora de gerar a continuação. Os chunks com maior log-prob gain são selecionados para formar a query.

É um pouco como o Batman escolhendo seus gadgets com base na missão: só vai o que realmente ajuda na execução.

O martelo de Thor: múltiplos caminhos de recuperação

A recuperação é feita por três vias: sparse (via TF-IDF), dense (via embeddings) e dataflow (via grafos de dependência). Cada método captura um tipo de relação diferente com o código. A união dos três cobre uma gama maior de possibilidades semânticas.

E o melhor: os caminhos são complementares. Quando o sparse falha, o dense pode salvar. Quando o dense é ambíguo, o dataflow resolve. É literalmente uma trindade.

O sharingan do ranking: reranking com BESTFIT

O reranking é feito com prompts direcionados. O modelo é instruído a escolher o melhor trecho entre janelas de 3 candidatos, usando um prompt claro e direto. O resultado é um ranking mais robusto e alinhado com as preferências do próprio LLM que vai gerar o código.

E ainda há a opção de usar o modelo distilado, que aprende com os resultados do reranking e replica o comportamento de forma mais leve.


As métricas não mentem: a CodeRAG é o verdadeiro MVP dos repositórios

O Hyper Beam do StarCoder2-3B

Nos benchmarks ReccEval e CCEval, a CodeRAG destrói os concorrentes. No ReccEval, com Qwen2.5-Coder-7B, atinge 47.48% de EM e 70.82% de ES, superando DraCo, RepoFuse, RepoCoder e todos os demais métodos.

Em termos de Identifier Match, atinge F1 de 68.68% — um valor que, em se tratando de completude de código, é praticamente um Kamehameha na hype do Zero-Shot.

O Hadouken dos rerankers

Mesmo com reranker distilado, a CodeRAG mantém performance competitiva. E com reranker full (LLM), o salto é expressivo: +3 a +5 pontos percentuais em todas as métricas.

A variação do número de trechos reranqueados (u) mostra que há ganhos significativos ao passar de 1 para 5, mas que saturam depois de 10 — exatamente como o limite de dano em um ataque crítico no WoW.

Custo computacional? Parece alto, mas não é

Apesar de múltiplas etapas, o tempo por query gira em torno de 0.23s — muito próximo de métodos como RepoCoder. E como os autores admitem, ainda há espaço para aceleração com vLLM e Faiss.


O feitiço virou contra o feiticeiro: o hype da IA esqueceu do repositório

Enquanto todo mundo celebra os LLMs que escrevem código como se fossem deuses do Olimpo, poucos lembram que sem recuperação adequada, eles só são bons em completar o óbvio. CodeRAG prova que, sem o contexto do repositório, LLMs se comportam como estagiários desavisados: completam com confiança, mas erram feio.

Esse trabalho escancara o que a indústria quer esconder: que completar código de forma útil em escala real exige mais do que parâmetros. Exige estrutura. Exige recuperação. Exige reranking.

A CodeRAG mostra que entender o repositório é mais importante do que inflar o modelo. E que o verdadeiro poder está na combinação entre estrutura, semântica e preferência do modelo.


O mapa do Maroto da IA: refletindo além da hype

Se você é um jovem pesquisador, pense nisso: a completude de código não se resolve com mais parâmetros ou mais linhas de código treinadas. O caminho é entender como LLMs pensam, onde eles falham, e como guiá-los com contexto relevante.

CodeRAG é um passo nesse sentido. Não é uma solução final, mas é um alerta. Sem estrutura, sem reranking e sem múltiplos caminhos de recuperação, estamos apenas jogando tokens no escuro.

A próxima geração de ferramentas para desenvolvedores não virá apenas de modelos maiores, mas de arquiteturas mais inteligentes. E se você quiser estar na vanguarda, precisa entender isso agora.