Modelos grandes não podem ser produtores de código! A descoberta surpreendente de Princeton: GPT-4 tem uma taxa de sucesso 0 na resolução de problemas de programação do GitHub
ferramentas de codificação de IA como o ChatGPT são ameaçadoras, e o Stack Overflow demite novamente! No entanto, Princeton e Chicago descobriram que o GPT-4 tinha uma taxa de resolução de 0% para problemas reais do GitHub.
Stack Overflow, já criado pelo ChatGPT!
Como os programadores migraram para o ChatGPT e o Github Copilot, a Stack Overflow teve que anunciar demissões de mais de 100 funcionários hoje, representando quase 1/3 do número de funcionários.
Então, ferramentas de codificação de IA como o ChatGPT realmente vão subverter toda a indústria?
Mas um estudo recente de Princeton e Chicago descobriu que LLM não é tão fácil de fazer como um fazendeiro de código.
Endereço em papel:
Diante de 2294 problemas reais do GitHub, a taxa de aprovação do GPT-4 resolvendo problemas aleatórios do GitHub acabou sendo de 0%!
Mesmo o melhor modelo, o Claude 2, resolve apenas 1,96% deles.
Os programadores podem perder seus empregos por causa do ChatGPT? A resposta é: absolutamente não no momento.
Adaptar ou perecer
Como o site assistido por código favorito de todos os desenvolvedores no mundo, o Stack Overflow já se saiu bem antes, desencadeando uma onda de contratações no ano passado, dobrando a força de trabalho da empresa para 540.
No entanto, tudo mudou desde que a OpenAI lançou o ChatGPT em novembro passado.
A ajuda fornecida pelos chatbots de IA é mais específica do que o post do fórum há 5 anos. Com o LLM, os desenvolvedores podem corrigir instantaneamente o código exato, sugestões de otimização e uma descrição do que cada linha de código está fazendo.
Embora o LLM não forneça respostas 100% confiáveis, a capacidade única de validar o código imediatamente simplesmente testando-o no ambiente de desenvolvimento integrado do IDE torna a escrita de código um caso de uso ideal para o ChatGPT.
Como resultado, o tráfego do Stack Overflow foi muito reduzido, e as ferramentas de programação de IA, como o ChatGPT e o Github Copilot alimentado por GPT-4, tornaram-se novos lugares para os criadores de código.
Hoje, o CEO Prashanth Chandrasekar anunciou que a Stack Overflow demitiu mais de cem funcionários, ou 28% de sua força de trabalho.
A explicação do CEO para as demissões é que a Stack Overflow está tentando entrar no caminho da lucratividade sob pressão macroeconômica e continua a introduzir inovações de produtos.
** Atravessar o rio e derrubar a ponte? **
A maior ironia do impacto do ChatGPT no Stack Overflow é que o poder do modelo de linguagem grande vem em grande parte de sites de scraping como o Stack Overflow.
O que acontece se grandes modelos de linguagem esvaziarem esses dados sem dar nada de volta e se todas as fontes de dados forem forçadas a sair do negócio?
Agora, muitas empresas de tecnologia já têm um problema iminente: se houver menos programadores, haverá menos dados artificiais.
Como treinar novos modelos de IA sem dados atualizados?
Quer utilizar os nossos dados? Pegue o dinheiro**
Stack Overflow, é claro, não pode ficar parado, ele escolheu duas maneiras de se salvar -
Uma é desenvolver sua própria ferramenta de codificação de IA, OverflowAI, e a outra é buscar parcerias diretamente com empresas de tecnologia como a OpenAI, que usam os dados do Stack Overflow para construir modelos de IA.
A OpenAI está desenvolvendo controles de rastreador da Web para ChatGPT para que os dados de sites como o Stack Overflow não possam ser rastreados.
O CEO disse que a Stack Overflow fez sua posição: quem quiser usar nossos dados para treinar LLM paga.
Os CEOs acreditam que sites como o Stack Overflow são fundamentais para o desenvolvimento de grandes modelos de linguagem e, para avançar, eles precisam ser treinados em novos conhecimentos.
Prashanth Chandrasekar, CEO da Stack Overflow
LLM quer obter o code farmer, ainda é cedo
Então, os grandes modelos de linguagem podem realmente aceitar agricultores de código?
As equipas de Princeton e Chicago descobriram que não era assim tão fácil!
No artigo mais recente, os pesquisadores propõem uma nova estrutura, SWE-bench, para avaliar a capacidade de grandes modelos para resolver 2294 problemas do mundo real no GitHub.
Verificou-se que os principais modelos grandes como GPT-4 e Claude 2 tinham menos de 5% de capacidade para resolver problemas reais.
Para ser mais específico, o GPT-4 pode resolver problemas aleatórios do GitHub com uma taxa de aprovação de 0%, enquanto o melhor modelo, Claude 2, só pode resolver 1,96% deles.
Além disso, ao usar o BM-25 para recuperar os arquivos de código relevantes para cada problema, apenas 23% dos patches escritos por Claude 2 eram válidos (repo-ready), e apenas ~1% realmente resolveu o problema.
Além disso, o desempenho de diferentes modelos na resolução de problemas com 12 bibliotecas Python populares também varia.
O modelo GPT-4 alcançou tal resultado, o que é realmente surpreendente, afinal, muitas pessoas há muito o consideram como uma "arma de programação".
Mas para ver claramente, a verdadeira força da IA, não seja pontuado e fique preocupado.
Alguns internautas disseram que esta é a melhor resposta para a questão de "se os agricultores estão desempregados devido à programação".
Finalmente, alguém fez um conjunto de dados real para o modelo de código, e Hum foi apenas a entrevista leetcode de LLM. Todos sabemos que esta é a medida errada para os engenheiros humanos. Menos de 4% parece certo, já que os modelos grandes ainda estão longe de ser totalmente autônomos.
Então, este é realmente o caso dos resultados da SWE-bench na avaliação das capacidades de modelos grandes?
SWE-bench: Projetado para modelos de codificação
Neste estudo, os autores descobriram que muitos benchmarks atuais para medir a capacidade de codificação de grandes modelos tornaram-se saturados e não podem medir a verdadeira força de grandes modelos.
Por exemplo, em Human, o problema do desafio é muito simples, e o LLM só precisa de algumas linhas de código para resolver um problema independente.
No entanto, a engenharia de software não é tão simples na realidade.
Corrigir um bug pode exigir navegar em uma enorme biblioteca de recursos, entender as relações entre funções em arquivos diferentes ou encontrar um pequeno bug no código intrincado.
Inspirados por isso, pesquisadores de Princeton e Chicago introduziram o SWE-bench.
O SWE-bench obtém instâncias de tarefas de um repositório Python real conectando problemas do GitHub e soluções de solicitação de mesclagem para resolver testes relacionados.
Como mostrado na imagem, a tarefa do modelo, geralmente um relatório de bug ou solicitação de recurso, é resolver um problema comprometido com o repositório GitHub.
Cada tarefa requer gerar um patch e descrever as alterações a serem aplicadas à base de código existente.
Em seguida, use a estrutura de teste SWE-bench do repositório para avaliar a base de código modificada.
Para encontrar exemplos de alta qualidade de tarefas em grande escala, os pesquisadores passaram por três etapas de triagem:
**Etapa 1: Seleção do armazém e pesquisa de dados. **
As solicitações pull (PRs) foram coletadas pela primeira vez de 12 repositórios Python de código aberto populares no GitHub, gerando um total de cerca de 90.000 PRs.
Os pesquisadores se concentraram em repositórios populares porque eles tendem a ser melhor mantidos, têm diretrizes claras de contribuidores e têm melhor cobertura de testes. Cada RP tem uma base de código associada, ou seja, o estado do repositório antes da fusão do PR.
**Fase 2: Filtragem baseada em atributos. **
A tarefa do candidato é criada selecionando um PR mesclado que atenda aos seguintes critérios: (1) resolve o problema do GitHub; (2) Modificado o arquivo de teste do repositório, o que indica que o usuário provavelmente contribuiu com testes para verificar se o problema foi resolvido.
**Fase 3: Filtragem baseada em execução. **
Para cada tarefa do candidato, aplica-se o conteúdo do teste de RP e os resultados relevantes do teste antes e depois do outro conteúdo do RP são aplicados.
O pesquisador filtra instâncias de tarefas que não têm pelo menos um teste, e o status desses testes muda de reprovado (doravante referido como "reprovado no teste"). Além disso, as instâncias que causam erros de instalação ou operação são filtradas.
Por meio dessas etapas de triagem, os 90.000 RPs originais são selecionados em 2.294 instâncias de tarefas, que compõem a bancada SWE.
A classificação final dessas instâncias de tarefa em diferentes repositórios é mostrada na Figura 3 abaixo, com a tabela sendo a principal característica das instâncias de tarefa SWE-bench.
Os pesquisadores enfatizam que essas bases de código são grandes, contendo milhares de arquivos, e que as solicitações pull de referência geralmente modificam vários arquivos ao mesmo tempo.
O SWE-bench oferece várias vantagens em relação aos benchmarks de programação LM existentes.
Isso inclui configurações do mundo real com problemas e soluções enviados pelo usuário, entradas diversas com perguntas de código exclusivas de 12 repositórios, uma estrutura de avaliação robusta baseada em execução e a capacidade de atualizar continuamente benchmarks com novas instâncias com intervenção humana mínima.
Tarefa LLM: Editar Base de Código, Resolver Problemas
O pesquisador dará ao modelo grande uma descrição textual do problema, bem como uma base de código completa.
A tarefa do modelo grande é editar a base de código para resolver o problema.
Na prática, os pesquisadores representam as alterações como arquivos de patch, que especificam quais linhas na base de código devem ser modificadas para resolver o problema.
Como avaliar se a solução dada pelo LLM é boa ou não?
Os pesquisadores usam patches Unix, aplicam patches gerados à base de código e, em seguida, executam testes de unidade e sistema relacionados a instâncias de tarefas.
Se o patch for aplicado com êxito e todos esses testes forem aprovados, o esquema recomendado pelo LLM pode ser considerado como tendo resolvido o problema com êxito.
Uma métrica da linha de base, que é a porcentagem de instâncias de tarefas resolvidas.
Construindo um conjunto de dados exclusivo para SWE-bench
Os benchmarks tradicionais de PNL normalmente envolvem apenas sequências curtas de entrada e saída e consideram alguns problemas "artificiais" criados especificamente para benchmarks.
Em contraste, para construir o SWE-bench, os pesquisadores injetaram propriedades únicas no conjunto de dados.
Por exemplo, tarefas reais de engenharia de software são usadas.
Como cada instância de tarefa no SWE-bench contém uma base de código grande e complexa e uma descrição do problema associado, a solução do SWE-bench requer as habilidades complexas e o conhecimento de engenheiros de software experientes, que muitas vezes não são avaliados em benchmarks tradicionais de geração de código.
Além disso, o processo de coleta pode ser facilmente aplicado a qualquer repositório Python no GitHub com pouca ou nenhuma intervenção humana.
Como resultado, os pesquisadores podem estender o SWE-bench fornecendo novas instâncias de tarefa e avaliar o modelo de linguagem para problemas criados após a data de treinamento, garantindo que o corpus de treinamento não contenha uma solução.
Além disso, os pesquisadores garantem diferentes entradas longas no benchmark, avaliação robusta, edição de código entre contextos, ampla gama de soluções, etc.
Ajuste fino SWE-Llama
Em seguida, é hora de avaliar a eficácia de modelos abertos e proprietários na estrutura SWE-bench.
No entanto, os pesquisadores descobriram que os modelos de ajuste fino CodeLlama prontos para uso não podiam seguir instruções detalhadas para gerar edições de código em toda a biblioteca, muitas vezes emitindo respostas de espaço reservado ou código irrelevante.
Para avaliar as capacidades desses modelos, os pesquisadores realizaram ajuste fino supervisionado (SFT) no modelo CodeLlama-Python de 7 bilhões de parâmetros e no modelo CodeLlama-Python de 13 bilhões de parâmetros.
O modelo resultante é um editor de repositório especializado que é executado em hardware de nível de consumidor e resolve problemas do GitHub.
### Grandes modelos falham
Em seguida, os pesquisadores avaliaram GPT-3.5, GPT-4, Cluade 2 e modelos ajustados.
Descobriu-se que todos os modelos falharam - nenhum deles resolveu todos, exceto os problemas mais simples.
Por exemplo, Claude 2 e GPT-4 só conseguem resolver 4,8% e 1,7% das tarefas, respectivamente.
Depois de usar o BM25 retriever, o desempenho de Claude 2 caiu ainda mais para 1,96%.
**Diferentes bibliotecas têm diferentes níveis de dificuldade. **
Se você dividir o desempenho por repositório, verá que todos os modelos exibem tendências semelhantes nas bibliotecas.
Ainda assim, os problemas abordados por cada modelo não se sobrepõem necessariamente extensivamente. Por exemplo, em uma configuração oracle, Claude 2 e SWE-Llama 13b têm desempenho comparável, resolvendo 110 e 91 instâncias por modelo, respectivamente.
**A dificuldade depende da duração do contexto. **
Os modelos podem ser pré-treinados em sequências de código longas, mas normalmente exigem que uma única função seja gerada de cada vez e fornecem uma estrutura com contexto limitado para determinar o problema.
Como mostrado, você pode ver que o desempenho de Claude 2 se degrada significativamente à medida que o comprimento total do contexto aumenta, o que também pode ser observado em outros modelos.
Mesmo que aumentar o tamanho máximo de contexto do BM25 melhorasse o recall em relação aos arquivos Oracle, o desempenho ainda se degradaria porque o modelo simplesmente não conseguia localizar o código problemático no vasto dicionário de sinônimos.
**A dificuldade é independente da data de resolução do problema. **
A Tabela 7 mostra os resultados do modelo por data para RPs criados antes ou depois de 2023 nas configurações de pesquisa "oracle".
Para a maioria dos modelos, com exceção do GPT-4, há pouca diferença no desempenho antes ou depois desta data.
Além disso, o estudo descobriu que o ajuste fino do modelo é sensível a mudanças na distribuição de contexto, e é mais fácil gerar um patch do que gerar um arquivo inteiro. E modelos grandes tendem a produzir edições mais curtas e simples.
LLM não é um substituto para programadores, mas pode acelerar fluxos de trabalho
Alguns internautas têm esperanças e esperanças para o futuro do "modelo generalista".
Isso mesmo, é o que estou dizendo. O modelo generalista não é bom o suficiente para ter um comprimento de contexto amplo o suficiente para codificar por conta própria, exceto por trechos de código relativamente curtos.
Mas acho que é apenas uma questão de tempo. Posso prever que, num futuro próximo, o LLM generalista com formação específica se tornará um modelo muito profissional.
Embora os modelos grandes não substituam os programadores, eles podem acelerar seus fluxos de trabalho. O que costumava levar uma equipe de 10 pessoas agora pode precisar de apenas 4 pessoas. Isso libera recursos para outros objetivos elaborados pela empresa.
Em vez de demitir funcionários para economizar dinheiro, deixe que os desenvolvedores realizem grandes coisas em uma velocidade vertiginosa!
Recursos:
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
Modelos grandes não podem ser produtores de código! A descoberta surpreendente de Princeton: GPT-4 tem uma taxa de sucesso 0 na resolução de problemas de programação do GitHub
Fonte do artigo: Shin Ji Yuan
Stack Overflow, já criado pelo ChatGPT!
Como os programadores migraram para o ChatGPT e o Github Copilot, a Stack Overflow teve que anunciar demissões de mais de 100 funcionários hoje, representando quase 1/3 do número de funcionários.
Mas um estudo recente de Princeton e Chicago descobriu que LLM não é tão fácil de fazer como um fazendeiro de código.
Diante de 2294 problemas reais do GitHub, a taxa de aprovação do GPT-4 resolvendo problemas aleatórios do GitHub acabou sendo de 0%!
Mesmo o melhor modelo, o Claude 2, resolve apenas 1,96% deles.
Adaptar ou perecer
Como o site assistido por código favorito de todos os desenvolvedores no mundo, o Stack Overflow já se saiu bem antes, desencadeando uma onda de contratações no ano passado, dobrando a força de trabalho da empresa para 540.
No entanto, tudo mudou desde que a OpenAI lançou o ChatGPT em novembro passado.
Embora o LLM não forneça respostas 100% confiáveis, a capacidade única de validar o código imediatamente simplesmente testando-o no ambiente de desenvolvimento integrado do IDE torna a escrita de código um caso de uso ideal para o ChatGPT.
Como resultado, o tráfego do Stack Overflow foi muito reduzido, e as ferramentas de programação de IA, como o ChatGPT e o Github Copilot alimentado por GPT-4, tornaram-se novos lugares para os criadores de código.
Hoje, o CEO Prashanth Chandrasekar anunciou que a Stack Overflow demitiu mais de cem funcionários, ou 28% de sua força de trabalho.
** Atravessar o rio e derrubar a ponte? **
A maior ironia do impacto do ChatGPT no Stack Overflow é que o poder do modelo de linguagem grande vem em grande parte de sites de scraping como o Stack Overflow.
O que acontece se grandes modelos de linguagem esvaziarem esses dados sem dar nada de volta e se todas as fontes de dados forem forçadas a sair do negócio?
Agora, muitas empresas de tecnologia já têm um problema iminente: se houver menos programadores, haverá menos dados artificiais.
Como treinar novos modelos de IA sem dados atualizados?
Quer utilizar os nossos dados? Pegue o dinheiro**
Stack Overflow, é claro, não pode ficar parado, ele escolheu duas maneiras de se salvar -
Uma é desenvolver sua própria ferramenta de codificação de IA, OverflowAI, e a outra é buscar parcerias diretamente com empresas de tecnologia como a OpenAI, que usam os dados do Stack Overflow para construir modelos de IA.
O CEO disse que a Stack Overflow fez sua posição: quem quiser usar nossos dados para treinar LLM paga.
Os CEOs acreditam que sites como o Stack Overflow são fundamentais para o desenvolvimento de grandes modelos de linguagem e, para avançar, eles precisam ser treinados em novos conhecimentos.
LLM quer obter o code farmer, ainda é cedo
Então, os grandes modelos de linguagem podem realmente aceitar agricultores de código?
As equipas de Princeton e Chicago descobriram que não era assim tão fácil!
Verificou-se que os principais modelos grandes como GPT-4 e Claude 2 tinham menos de 5% de capacidade para resolver problemas reais.
Para ser mais específico, o GPT-4 pode resolver problemas aleatórios do GitHub com uma taxa de aprovação de 0%, enquanto o melhor modelo, Claude 2, só pode resolver 1,96% deles.
Além disso, o desempenho de diferentes modelos na resolução de problemas com 12 bibliotecas Python populares também varia.
Mas para ver claramente, a verdadeira força da IA, não seja pontuado e fique preocupado.
SWE-bench: Projetado para modelos de codificação
Neste estudo, os autores descobriram que muitos benchmarks atuais para medir a capacidade de codificação de grandes modelos tornaram-se saturados e não podem medir a verdadeira força de grandes modelos.
Por exemplo, em Human, o problema do desafio é muito simples, e o LLM só precisa de algumas linhas de código para resolver um problema independente.
No entanto, a engenharia de software não é tão simples na realidade.
Inspirados por isso, pesquisadores de Princeton e Chicago introduziram o SWE-bench.
O SWE-bench obtém instâncias de tarefas de um repositório Python real conectando problemas do GitHub e soluções de solicitação de mesclagem para resolver testes relacionados.
Como mostrado na imagem, a tarefa do modelo, geralmente um relatório de bug ou solicitação de recurso, é resolver um problema comprometido com o repositório GitHub.
Cada tarefa requer gerar um patch e descrever as alterações a serem aplicadas à base de código existente.
Em seguida, use a estrutura de teste SWE-bench do repositório para avaliar a base de código modificada.
As solicitações pull (PRs) foram coletadas pela primeira vez de 12 repositórios Python de código aberto populares no GitHub, gerando um total de cerca de 90.000 PRs.
Os pesquisadores se concentraram em repositórios populares porque eles tendem a ser melhor mantidos, têm diretrizes claras de contribuidores e têm melhor cobertura de testes. Cada RP tem uma base de código associada, ou seja, o estado do repositório antes da fusão do PR.
**Fase 2: Filtragem baseada em atributos. **
A tarefa do candidato é criada selecionando um PR mesclado que atenda aos seguintes critérios: (1) resolve o problema do GitHub; (2) Modificado o arquivo de teste do repositório, o que indica que o usuário provavelmente contribuiu com testes para verificar se o problema foi resolvido.
**Fase 3: Filtragem baseada em execução. **
Para cada tarefa do candidato, aplica-se o conteúdo do teste de RP e os resultados relevantes do teste antes e depois do outro conteúdo do RP são aplicados.
O pesquisador filtra instâncias de tarefas que não têm pelo menos um teste, e o status desses testes muda de reprovado (doravante referido como "reprovado no teste"). Além disso, as instâncias que causam erros de instalação ou operação são filtradas.
Por meio dessas etapas de triagem, os 90.000 RPs originais são selecionados em 2.294 instâncias de tarefas, que compõem a bancada SWE.
A classificação final dessas instâncias de tarefa em diferentes repositórios é mostrada na Figura 3 abaixo, com a tabela sendo a principal característica das instâncias de tarefa SWE-bench.
Os pesquisadores enfatizam que essas bases de código são grandes, contendo milhares de arquivos, e que as solicitações pull de referência geralmente modificam vários arquivos ao mesmo tempo.
O SWE-bench oferece várias vantagens em relação aos benchmarks de programação LM existentes.
Isso inclui configurações do mundo real com problemas e soluções enviados pelo usuário, entradas diversas com perguntas de código exclusivas de 12 repositórios, uma estrutura de avaliação robusta baseada em execução e a capacidade de atualizar continuamente benchmarks com novas instâncias com intervenção humana mínima.
Tarefa LLM: Editar Base de Código, Resolver Problemas
O pesquisador dará ao modelo grande uma descrição textual do problema, bem como uma base de código completa.
A tarefa do modelo grande é editar a base de código para resolver o problema.
Na prática, os pesquisadores representam as alterações como arquivos de patch, que especificam quais linhas na base de código devem ser modificadas para resolver o problema.
Os pesquisadores usam patches Unix, aplicam patches gerados à base de código e, em seguida, executam testes de unidade e sistema relacionados a instâncias de tarefas.
Uma métrica da linha de base, que é a porcentagem de instâncias de tarefas resolvidas.
Construindo um conjunto de dados exclusivo para SWE-bench
Os benchmarks tradicionais de PNL normalmente envolvem apenas sequências curtas de entrada e saída e consideram alguns problemas "artificiais" criados especificamente para benchmarks.
Em contraste, para construir o SWE-bench, os pesquisadores injetaram propriedades únicas no conjunto de dados.
Por exemplo, tarefas reais de engenharia de software são usadas.
Além disso, o processo de coleta pode ser facilmente aplicado a qualquer repositório Python no GitHub com pouca ou nenhuma intervenção humana.
Como resultado, os pesquisadores podem estender o SWE-bench fornecendo novas instâncias de tarefa e avaliar o modelo de linguagem para problemas criados após a data de treinamento, garantindo que o corpus de treinamento não contenha uma solução.
Além disso, os pesquisadores garantem diferentes entradas longas no benchmark, avaliação robusta, edição de código entre contextos, ampla gama de soluções, etc.
Ajuste fino SWE-Llama
Em seguida, é hora de avaliar a eficácia de modelos abertos e proprietários na estrutura SWE-bench.
No entanto, os pesquisadores descobriram que os modelos de ajuste fino CodeLlama prontos para uso não podiam seguir instruções detalhadas para gerar edições de código em toda a biblioteca, muitas vezes emitindo respostas de espaço reservado ou código irrelevante.
Para avaliar as capacidades desses modelos, os pesquisadores realizaram ajuste fino supervisionado (SFT) no modelo CodeLlama-Python de 7 bilhões de parâmetros e no modelo CodeLlama-Python de 13 bilhões de parâmetros.
O modelo resultante é um editor de repositório especializado que é executado em hardware de nível de consumidor e resolve problemas do GitHub.
Em seguida, os pesquisadores avaliaram GPT-3.5, GPT-4, Cluade 2 e modelos ajustados.
Descobriu-se que todos os modelos falharam - nenhum deles resolveu todos, exceto os problemas mais simples.
Por exemplo, Claude 2 e GPT-4 só conseguem resolver 4,8% e 1,7% das tarefas, respectivamente.
Depois de usar o BM25 retriever, o desempenho de Claude 2 caiu ainda mais para 1,96%.
**Diferentes bibliotecas têm diferentes níveis de dificuldade. **
Se você dividir o desempenho por repositório, verá que todos os modelos exibem tendências semelhantes nas bibliotecas.
Ainda assim, os problemas abordados por cada modelo não se sobrepõem necessariamente extensivamente. Por exemplo, em uma configuração oracle, Claude 2 e SWE-Llama 13b têm desempenho comparável, resolvendo 110 e 91 instâncias por modelo, respectivamente.
**A dificuldade depende da duração do contexto. **
Os modelos podem ser pré-treinados em sequências de código longas, mas normalmente exigem que uma única função seja gerada de cada vez e fornecem uma estrutura com contexto limitado para determinar o problema.
Como mostrado, você pode ver que o desempenho de Claude 2 se degrada significativamente à medida que o comprimento total do contexto aumenta, o que também pode ser observado em outros modelos.
Mesmo que aumentar o tamanho máximo de contexto do BM25 melhorasse o recall em relação aos arquivos Oracle, o desempenho ainda se degradaria porque o modelo simplesmente não conseguia localizar o código problemático no vasto dicionário de sinônimos.
A Tabela 7 mostra os resultados do modelo por data para RPs criados antes ou depois de 2023 nas configurações de pesquisa "oracle".
Para a maioria dos modelos, com exceção do GPT-4, há pouca diferença no desempenho antes ou depois desta data.
LLM não é um substituto para programadores, mas pode acelerar fluxos de trabalho
Alguns internautas têm esperanças e esperanças para o futuro do "modelo generalista".
Isso mesmo, é o que estou dizendo. O modelo generalista não é bom o suficiente para ter um comprimento de contexto amplo o suficiente para codificar por conta própria, exceto por trechos de código relativamente curtos.
Mas acho que é apenas uma questão de tempo. Posso prever que, num futuro próximo, o LLM generalista com formação específica se tornará um modelo muito profissional.
Em vez de demitir funcionários para economizar dinheiro, deixe que os desenvolvedores realizem grandes coisas em uma velocidade vertiginosa!