O Viés Invisível dos Agentes de IA em código · danielsuhett

Quando interagimos com comunidades de desenvolvedores, é realmente notável a diferença de experiência com IA entre algumas pessoas, obviamente tudo na vida depende de treinamento, você logo vai aprender sobre prompt, contexto, modelo etc. Mas existe algo que pode ditar sua experiência logo de cara: o idioma e a codebase.

Esse artigo foca apenas na utilização dos foundation models para gerar código, não é, de maneira nenhuma, um artigo focado em machine learning, os benchmarks, estudos e o link original do meu post em en-US são citados ao fim do texto.

A variação de resultados não é algo aleatório, considerando que gerar um código se trata de prever o próximo token, obviamente idiomas e linguagens de programação com menos treinamento terão uma chance de previsão mais baixa, a depender da combinação os resultados podem ser ainda piores, por exemplo, se você quiser gerar um código em F# com um prompt escrito em Chinês, o resultado será pior do que gerar Java em chinês, que será muito pior que gerar Java em inglês.

A maneira mais rápida de tornar sua codebase apta para gerar código com agentes de IA não é apenas adquirindo o melhor modelo, a melhor ferramenta e sim entendendo como ela vai interagir com esses recursos.

OpenAI Codex is most capable in Python, but it is also proficient in over a dozen languages including JavaScript, Go, Perl, PHP, Ruby, Swift and TypeScript, and even Shell.
https://openai.com/index/openai-codex/

O efeito de dominância no treinamento

LLMs tem suas preferências, sua performance está diretamente relacionada ao seu treinamento, que por sua vez está sobrecarregado com poucos paradigmas, linguagens e padrões coletados de repositórios públicos, com código em sua maioria:

Em língua inglesa
Em paradigma imperativo
Em paradigma Orientado a objetos
Utilizando Python, Javascript e Java

Por consequência caso fuja disso você é naturalmente punido, isso não quer dizer que você não consegue usar geração de código mas é bom entender o quanto dessa influência afeta suas tentativas, estudos apontam que trocar a linguagem de programação pode ultrapassar mais de 20% da eficiência de um modelo sob o mesmo prompt, se tratando de idioma fazer o mesmo prompt em Chinês ao invés de Inglês pode reduzir a qualidade em pelo menos 13%.

A vantagem de estar seguindo a manada

Esse viés se estende para frameworks e bibliotecas do seu uso diário, os agentes mostram desempenho superior em ferramentas mainstream pelo simples motivo de serem mais utilizados. [1] Um modelo pode, por exemplo, gerar código muito eficiente em React, Express ou Django. Entretanto, caso tente utilizar algo como Ramda, Preact ou F# que mudam paradigma ou linguagem, os estudos apontam que o código produzido, embora correto em sintaxe fica muito distante da qualidade produzida por um humano qualificado nesse contexto. [2, 3]

Código limpo não é apenas para humanos

Aqui as coisas ficam interessantes, a qualidade do seu código já existente na sua codebase impacta diretamente a qualidade do output de IA. Pense da seguinte maneira, se o seu código é claro e bem documentado, com boas nomenclaturas, você estará providenciando um prompt de maior qualidade para seu IA Agent a todo momento que ele analisar seu código.

A diferença entre uma função declarada:

calculateTotalPrice(items, taxRate)
calc(arr, x) qual você acredita que tem melhor eficiência? Por obvio aquela que tem uma descrição não apenas do que ela faz mas também aquilo que é.

Documentação e comentários

Você deve perceber que os modelos de LLMs gostam muito de gerar comentários como documentação, certo? Isso não é acidental. Os modelos aprendem com o contexto de um código bem comentado e reconhecem isso como um sinal de alta qualidade no código. [4] Eu particularmente não gosto nem um pouco de comentários, porém aqui estamos estudando como fazer que seu próximo token esteja mais perto do melhor resultado possível, e sem sombra de dúvidas manter uma codebase bem documentada aumentará a qualidade do seu IA Agent.

Como o modelo reforça esteriótipos

Quando falamos sobre popularidade e exposição no treinamento, tem um fator adicional nessa história em relação as linguagens, a amostra de conteúdo não tem uma distribuição correta sobre tópicos de atuação, por exemplo, qual você acha que é a maior força de um modelo que recebeu muito código Javascript? Certamente a resposta mais sensata é lógica de front-end e UI. A essa altura você já entendeu onde eu quero chegar, por mais treinado que o modelo seja, ele ainda terá suas preferências dentro das preferências, porque as pessoas que usam aquela linguagem elas tem nichos específicos com maiores atuações em repositórios públicos. Aqui está uma lista de alguns desses "esteriótipos":

JavaScript: Lógica de Frontend, UI components, NodeJS scripts, certamente muito efetivo para tarefas relacionadas a web.
Python: A linguagem principal para data science, scripting e machine learning. Um volume enorme de notebooks, scripts e bibliotecas públicas como pandas e numpy. Certamente muito efetivo em tarefas relacionadas a algoritmos e dados.
Java: O fundamento de diversas soluções enterprise, bem estruturado e documentado quando comparamos com as outras duas, certamente muito efetivo para tarefas de construção de sistemas robustos.

Como equilibrar o jogo? RAG!

Retrieval-Augmented Generation (RAG) é uma técnica de providenciar um contexto relevante, atualizado e direcionado em tempo de consulta. Para o código, isso significa fazer um alinhamento maior de documentação, exemplos e melhores práticas no seu específico contexto independente da sua popularidade, pois afinal quem determina essas fontes de dados é você. Estudos apontam que utilizar RAG pode aumentar sua chance de sucesso em média 13.5%, especialmente para frameworks e bibliotecas lançadas depois do lançamento do modelo. Entretanto não existe mágica no RAG, esse sucesso está diretamente relacionado ao contexto providenciado, que por sua vez não é ilimitado, contexto é algo fechado e varia conforme a capacidade e o custo do modelo, ainda que você consiga providenciar mais contexto para algo não trivial sua desvantagem passaria a ser financeira e não técnica, pois provavelmente precisará aumentar a janela de contexto e o uso do modelo. [2]

Conclusão

Ainda é muito restrito e pouco falado essa diferença na utilização dos modelos, a própria forma de benchmark é muito questionada, porém o objetivo desse artigo é fazer pessoas que não tem tido uma boa experiência entender um pouco do que se trata e como melhorar isso, por exemplo trocando o modelo utilizado pois diferentes modelos podem ter diferentes treinamentos e exposição a linguagens. Lembre-se que independente disso, é importante investir em utilizar padrões de mercado e código bem documentado para que seu IA Agent tenha um bom funcionamento.

Gostaria muito de saber a opinião de vocês sobre isso e caso tenham algum estudo ou opinião para debater sobre o assunto não deixem de citar

Referências

[1] Exploring Multi-Lingual Bias of Large Code Models in Code Generation - https://arxiv.org/abs/2404.19368

[2] CodeRAG-Bench: Can Retrieval Augment Code Generation? - https://arxiv.org/abs/2406.14497

[3] Investigating the Performance of Language Models for Completing Code in Functional Programming Languages: a Haskell Case Study - https://dl.acm.org/doi/pdf/10.1145/3650105.3652289

[4] Investigates the Impact of AI-generated Code Tools on Software Readability Code Quality Factor - https://arxiv.org/abs/2402.13280

[5] MultiPL-E: A Scalable and Extensible Approach to Benchmarking Neural Code Generation https://arxiv.org/pdf/2208.08227

[6]SWE-PolyBench: A multi-language benchmark for repository level evaluation of coding agents https://arxiv.org/pdf/2504.08703