Specification and Detection of LLM Code Smells
Este artigo introduz o conceito de "code smells" de LLM ao formalizar cinco práticas de codificação problemáticas recorrentes para inferência de LLM, estende a ferramenta SpecDetect4AI para detectá-las e demonstra, por meio de um estudo de 200 sistemas de código aberto, que esses smells afetam mais de 60% de tais sistemas com alta precisão de detecção.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você acabou de construir um assistente robô superinteligente (um Grande Modelo de Linguagem, ou LLM) e o convidou para viver dentro do seu software. É como contratar um mago genial para ajudar você a lançar feitiços no seu código. Mas aqui está o problema: se você não der ao mago regras claras, uma mão firme e um mapa, as coisas podem ficar bagunçadas. O robô pode ficar confuso, ficar sem magia ou começar a gritar nonsense.
Este artigo é como um guia de detetive para identificar os "maus hábitos" que os desenvolvedores acidentalmente adquirem ao convidar esses magos para o seu código. Os autores, Brahim, Zacharie, Naouel, Quentin e Florent, perceberam que, embora todos saibam escrever código, ninguém havia escrito uma lista formal dos "odores" específicos (aqueles hábitos ruins sutis que não causam um erro imediato, mas deixam o software doente mais tarde) que acontecem especificamente quando se usa LLMs.
Os Cinco "Maus Hábitos" (Os Odores)
A equipe vasculhou artigos de pesquisa, blogs de tecnologia e códigos do mundo real para encontrar cinco problemas recorrentes. Pense nisso como os "Top 5 Maneiras de Estragar o Trabalho do Seu Mago":
- O Odor de "Orçamento Infinito" (Métricas Máximas Não Limitadas / Unbounded Max Metrics): Imagine dizer ao seu mago: "Vá escrever uma história, mas não pare até que o papel ou o tempo acabem". No mundo real, as APIs têm limites. Se você não definir um limite de quantas palavras (tokens) o mago pode cuspir, ou quanto tempo eles podem pensar (timeouts), você pode receber uma história incompleta ou, pior, seu computador pode ficar travado esperando para sempre enquanto você paga uma fortuna. A solução? Sempre defina uma parada rígida para a duração e o comprimento.
- O Odor de "Alvo Móvel" (Falta de Fixação da Versão do Modelo / No Model Version Pinning): Imagine que seu mago se chama "GPT-4". Mas e se a empresa por trás do mago trocar secretamente o cérebro dentro do corpo do "GPT-4" por um diferente amanhã? Se você não fixar seu código a uma versão específica (como "GPT-4 de 20 de novembro de 2024"), seu software pode funcionar hoje e agir de forma totalmente estranha amanhã porque o mago mudou. A solução? Trave o mago em uma versão específica e imutável.
- O Odor de "Sem Chefe" (Sem Mensagem de Sistema / No System Message): Imagine enviar seu mago para uma sala sem dizer a eles quem eles são ou quais são as regras. Eles podem agir como um comediante quando você queria um professor, ou um poeta quando você queria um programador. Sem uma "Mensagem de Sistema" para definir o tom e o papel, os resultados são imprevisíveis e difíceis de controlar. A solução? Sempre dê ao mago uma descrição de cargo clara antes de começarem a trabalhar.
- O Odor de "Mesa Bagunçada" (Sem Saída Estruturada / No Structured Output): Imagine pedir ao seu mago uma lista de ingredientes, mas ele lhe entrega um parágrafo de texto divagante em vez de uma lista organizada. Se o seu software espera uma lista organizada (como JSON) para fazer o seu trabalho, ele irá travar ao tentar ler a bagunça. A solução? Force o mago a escrever em um formato estrito, como uma lista de verificação, para que seu software possa lê-lo facilmente.
- O Odor de "Montanha-Russa" (Temperatura Não Definida Explicitamente / Temperature Not Explicitly Set): Imagine o "dial de criatividade" do seu mago. Se você não o configurar, o mago pode ser super sério um dia e totalmente caótico no outro, dependendo de qual configuração padrão estiver definida. Isso torna seu software não confiável porque a mesma pergunta recebe uma resposta diferente a cada vez. A solução? Sempre gire o dial para um número específico para que o mago se comporte da mesma maneira todas as vezes.
O Que Eles Encontraram (A Evidência)
Para ver quão comuns são esses maus hábitos, a equipe construiu uma ferramenta especial chamada SpecDetect4LLM. Pense nela como um corretor ortográfico que só procura por esses cinco erros específicos relacionados ao mago. Eles rodaram essa ferramenta em 200 diferentes projetos de software de código aberto que usam LLMs.
Aqui está a grande revelação: 60,50% desses 200 projetos tinham pelo menos um desses maus hábitos. Isso é mais da metade!
A ferramenta foi muito boa em detectar os problemas reais, com uma precisão de 86,06%. Isso significa que, quando a ferramenta dizia: "Ei, você tem um mau hábito aqui", ela estava certa cerca de 86 vezes em cada 100.
Eles também detalharam a frequência com que cada odor aparecia:
- Saída Não Estruturada (NSO): O mais comum, encontrado em 40,50% dos sistemas.
- Métricas Máximas Não Limitadas (UMM): Encontrado em 38,00% dos sistemas.
- Falta de Fixação da Versão do Modelo (NMVP): Encontrado em 36,00% dos sistemas.
- Temperatura do LLM Não Definida Explicitamente (TNES): Encontrado em 36,50% dos sistemas.
- Sem Mensagem de Sistema (NSM): Encontrado em 34,50% dos sistemas.
O Que Eles Não Sabem (Os Limites)
É importante notar o que este artigo não fez. Os autores não tentaram contar quantos maus hábitos eles perderam (eles não mediram o "recall/revocação"). Eles apenas verificaram o quão precisos eram quando encontravam algo. Além disso, a ferramenta deles analisa o código na página (análise estática), portanto, não consegue ver o que acontece quando o código está realmente rodando e conversando com o mago em tempo real. Eles sugerem que trabalhos futuros possam observar esses efeitos em execução, mas, por enquanto, eles apenas mediram o código conforme ele reside nos arquivos.
A Conclusão
O ponto principal não é que esses sistemas estejam quebrados além do reparo. É que os desenvolvedores estão frequentemente tratando essas ferramentas poderosas de IA como caixas mágicas sem ler o manual de instruções. Ao definir esses cinco "odores" e construir uma ferramenta para encontrá-los, os autores estão dando aos desenvolvedores um checklist para tornar seus softwares integrados com IA mais confiáveis, mais baratos de operar e mais fáceis de consertar depois. Eles não estão dizendo que resolveram todo o problema da segurança da IA, mas certamente encontraram os primeiros cinco buracos na estrada e colocaram placas para que todos possam evitá-los.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.