AlphaCodium: liderando o caminho para um novo reino de geração de código, da engenharia de dicas à engenharia de processos

Original: [Geração de código de última geração com o AlphaCodium - Da engenharia imediata à engenharia de fluxo]

Por Tal Ridnik

AlphaCodium: liderando o caminho para um novo reino de geração de código, da engenharia de dicas à engenharia de processos

passar por cima

Os desafios da geração de código são diferentes daqueles do processamento comum de linguagem natural - eles envolvem seguir estritamente as regras sintáticas da linguagem de programação de destino, identificar casos normais e de limite, prestar atenção a vários detalhes na especificação do problema e lidar com outros problemas e requisitos específicos do código. Como resultado, muitas das técnicas de otimização comumente usadas no campo da geração de linguagem natural podem não ser aplicáveis às tarefas de geração de código.

Neste estudo, propomos um novo método de geração de código chamado AlfaCódio -- Um processo de tratamento iterativo, baseado em testes, em fases e com foco em código. Essa abordagem melhora significativamente a capacidade do Modelo de Linguagem Grande (LLM) de lidar com problemas de código.

Testamos o AlphaCodium em um conjunto de dados de geração de código desafiador, o CodeContests, que contém tópicos de programação de competições de plataformas como o Codeforces. Nossa abordagem obtém consistentemente ganhos significativos de desempenho nesses testes.

Por exemplo, no conjunto de dados de validação, a precisão (pass@5) do GPT-4 melhorou de 19% para 44% com uma única pista direta bem projetada após o uso do processo da AlphaCodium. A AlphaCodium não apenas supera o desempenho de pesquisas anteriores, como a AlphaCode, mas também exige muito menos recursos computacionais AlphaCodium.

Acreditamos que muitos dos princípios e práticas recomendadas desenvolvidos neste trabalho são geralmente aplicáveis a uma ampla variedade de tarefas na geração de código. Nosso mais recente projeto de código aberto [AlfaCódioNossa solução AlphaCodium para CodeContests é compartilhada em ], com avaliação completa do conjunto de dados e scripts de benchmarking para pesquisa e exploração adicionais pela comunidade.

Análise de conjunto de dados do CodeContests

[Concursos de código] é um conjunto de dados de programação desafiador do Google Deepmind. Ele se baseia em dados como [Forças de códigoUma plataforma de programação de competição, como a ], apresenta uma seleção de cerca de 10.000 tópicos de programação projetados para treinar e avaliar modelos de linguagem grandes (modelos de linguagem grandes, como GPT ou DeepSeek) Capacidade de resolver problemas complexos de programação.

Este estudo não se concentrou no desenvolvimento de um modelo totalmente novo, mas sim na criação de um processo de programação aplicável a uma variedade de grandes modelos de linguagem que já são capazes de lidar com tarefas de codificação. Portanto, nos concentramos nos conjuntos de validação e teste do CodeContests, que consistem em 107 e 165 problemas de programação. A Figura 1 mostra um exemplo de um problema típico do conjunto de dados:

Figura 1: Um problema padrão no CodeContests.

Cada problema inclui uma descrição do problema e alguns dados de teste disponíveis publicamente que podem ser usados diretamente como entrada do modelo. O desafio é escrever um procedimento que forneça a resposta correta para qualquer entrada legítima. Além disso, há um conjunto de testes, que não está disponível publicamente, que é usado para avaliar a correção do programa enviado.

Por que os CodeContests são um conjunto de dados ideal para testar o poder de programação de grandes modelos de linguagem? Em primeiro lugar, ao contrário de outros conjuntos de dados de concursos de programação, o CodeContests contém uma grande quantidade de dados de teste privados (cerca de 200 casos de teste por problema) para garantir a precisão da avaliação. Em segundo lugar, os modelos de linguagem grandes geralmente não são muito bons em perceber detalhes nas descrições de problemas que, muitas vezes, são essenciais para encontrar a solução correta. As descrições de problemas no CodeContests geralmente são complexas e detalhadas, cheias de nuances que afetam a solução (um exemplo típico é ilustrado na Figura 1). Esse design simula a complexidade dos problemas do mundo real, forçando o modelo a levar em conta vários fatores, o que contrasta com alguns dos conjuntos de dados mais simples e diretos (por exemplo, [HumanEval]) está em forte contraste. Um problema típico de programação do HumanEval é ilustrado no Apêndice 1.

A Figura 2 ilustra como o modelo analisa o problema da Figura 1 em profundidade. Ao analisar o problema em profundidade, ele se torna mais claro e mais estruturado, o que enfatiza a importância de se ter uma compreensão mais profunda do problema durante o processo de programação.

Figura 2: Autorreflexão gerada pela IA para o problema descrito na Figura 1.

Metodologia proposta

Ao lidar com os desafios complexos da geração de código, descobrimos que nem a otimização de prompt único nem os prompts de pensamento contínuo melhoraram significativamente a eficiência da solução de problemas dos modelos de linguagem grande (LLMs) no CodeContest. Isso se deve ao fato de que os modelos muitas vezes têm dificuldade para entender completamente o problema e, portanto, produzem repetidamente códigos incorretos ou incapazes de lidar com novos casos de teste. As abordagens aplicáveis ao processamento geral de linguagem natural podem não ser ideais para tarefas de geração de código. Essas tarefas escondem um grande potencial, como a execução repetida do código gerado e sua verificação em relação a exemplos conhecidos. Em contraste com as técnicas de otimização de dicas no processamento regular de linguagem natural, descobrimos que a solução do problema do CodeContest usando a geração de código e o teste especificamente para ofluxos de trabalhomais eficaz. O processo gira em torno deiteração (matemática)O processo se desdobra, ou seja, executamos e ajustamos continuamente o código gerado para que ele passe nos testes de entrada e saída. Os dois principais aspectos desse processo específico do código são:

(a) gerar dados adicionais na fase de pré-processamento, por exemplo, autorreflexão e raciocínio para casos de teste abertos, para dar suporte ao processo iterativo, e (b) aumentar os casos de teste abertos com casos de teste adicionais gerados pela IA. Na Fig. 3, mostramos o processo que projetamos para resolver o problema de programação de corrida:

Figura 3: O processo AlphaCodium proposto.

Figura 3 Pré-processamento de compilação e fluxo de iteração de código

O processo da Figura 3 é dividido em dois estágios principais:

• pré-processamento Na etapa de análise, raciocinamos sobre o problema usando a linguagem natural, que é um processo linear.
• Iteração de código incluindo várias sessões iterativas nas quais geramos, executamos e corrigimos o código para vários testes.

Na Tabela 1, analisamos esses diferentes estágios em detalhes:

Tabela 1: Caracterização das fases de alfa-códio.

Ao explorar o processo proposto, obtivemos algumas intuições e percepções profundas.

Em primeiro lugarconhecimento cumulativoetapas do processo: começaremos com tarefas simples e gradualmente nos desafiaremos com problemas mais complexos. Por exemplo, na primeira etapa do processo, _Auto-reflexão_, aprendemos conhecimentos que podem ser usados nas etapas seguintes, mais difíceis, comoGeração de possíveis soluções. A fase de pré-processamento do processo produz resultados que alimentam a parte mais desafiadora e crítica do processo: a iteração do código, em que realmente tentamos escrever um código que resolva o problema corretamente.

Próximo.Gerar testes adicionais de IA é mais fácil do que gerar um conjunto completo de código de solução -- Esse processo depende muito da compreensão do problema e da solução básica de força bruta ou do raciocínio lógico, sem precisar resolver totalmente o problema para gerar pares de teste de entrada-saída úteis. Isso é diferente de escrever um código de solução completo e correto, o que exige que criemos uma solução algorítmica completa que possa responder corretamente a qualquer par de teste de entrada-saída. Como resultado, podemos criar mais testes de IA e usá-los para otimizar a fase de criação do código, conforme mostrado na Figura 4. Também aumentamos ainda mais a eficácia desses testes adicionais solicitando que o modelo se concentre no que não é coberto pelos casos de teste públicos originais, como lidar com entradas grandes, casos de borda etc.

Finalmente.Várias etapas podem ser combinadas em uma única chamada de modelo de linguagem grande (LLM) -- O processo mostrado na Figura 3 é uma demonstração conceitual, destacando as principais etapas do processo. Na prática, ao estruturar a saída (consulte a próxima seção), podemos combinar vários estágios em uma única chamada de modelo de linguagem grande para conservar recursos ou melhorar o desempenho do modelo ao lidar com tarefas específicas ao mesmo tempo.

A Figura 4 demonstra os aprimoramentos feitos com a aplicação do processo AlphaCodium.

Os modelos geralmente enfrentam dificuldades quando resolvem problemas de código com base apenas em dicas diretas. A iteração em casos de teste disponíveis publicamente estabiliza e melhora a solução, mas deixa "pontos cegos" porque os casos de teste disponíveis publicamente não são suficientemente abrangentes. Quando usamos o processo completo do AlphaCodium, incluindo a fase de pré-processamento e a iteração em testes públicos e gerados por IA, podemos melhorar ainda mais a qualidade da solução e aumentar significativamente a taxa de sucesso da solução de problemas.

Conceitos de design para código

Nesta seção, apresentamos alguns conceitos de design, técnicas e práticas recomendadas que consideramos úteis ao resolver problemas de geração de código. O processo do AlphaCodium que apresentamos na Figura 3 faz uso extensivo desses conceitos de design:

Saída estruturada YAML: Uma parte importante do nosso processo proposto é o uso de saída estruturada, exigindo que o modelo gere uma saída formatada em YAML equivalente a uma classe Pydantic específica. Um exemplo:

...

Seu objetivo é apresentar possíveis soluções.

Garantir que os objetivos, as regras e as restrições do problema sejam totalmente levados em conta em cada programa.

A saída deve ser um objeto YAML correspondente ao tipo $PossibleSolutions, de acordo com a seguinte definição Pydantic:

class Solution(BaseModel).

name: str = Field(description="Name of the solution")

content: str = Field(description=Descrição da solução")

why_it_works: str = Field(description="Por que essa solução funciona. Precisa ser detalhado especificamente para as regras e os objetivos do problema.")

complexity: str = Field(description="The complexity of the solution")

classe PossibleSolutions(BaseModel).

possible_solutions: List[Solution] = Field(max_items=3, description="Uma lista de possíveis soluções para o problema. Certifique-se de que cada solução considere totalmente as regras e as metas do problema e tenha um tempo de execução razoável em um computador moderno - não mais do que três segundos para restrições de problemas com um grande número de entradas.")

Tabela 2: Exemplos de prompts de saída estruturados (fase Gerar soluções possíveis).

A saída estruturada reduz a complexidade da "engenharia de dicas" e a necessidade de hacking e, em vez disso, apresenta tarefas complexas de forma direta e semelhante a um código. Isso também possibilita a obtenção de respostas complexas que contêm vários estágios, refletindo processos de pensamento lógicos e organizados.

Embora a nova versão do GPT seja compatível com [Estilo JSON], mas acreditamos que, especialmente em tarefas de geração de código, a saída YAML é mais apropriada, conforme detalhado no apêndice.

Análise de pontos - Quando um Modelo de Linguagem Ampla (LLM) é solicitado a analisar um problema, geralmente se obtêm melhores resultados solicitando o resultado em um formato de marcadores. Os marcadores promovem uma compreensão mais profunda do problema e forçam o modelo a dividir o resultado em regiões semânticas lógicas, melhorando assim a qualidade dos resultados. Por exemplo, no caso do problema de autorreflexão com marcadores (veja a Figura 2), cada marcador representa uma compreensão semântica de uma parte diferente do problema - descrição geral, metas e regras, estrutura de entrada e estrutura de saída.

Os Big Language Models são melhores para gerar código modular - Quando deixamos que o Modelo de Linguagem Grande (LLM) trabalhe escrevendo um longo bloco de funções individuais, muitas vezes nos deparamos com problemas: geralmente há erros ou falhas lógicas no código. Pior ainda, esses blocos de código grandes e monolíticos podem interferir nas iterações subsequentes para corrigi-los. Mesmo quando as informações de erro são fornecidas, é difícil para o modelo identificar e corrigir o problema. Entretanto, se instruirmos explicitamente o modelo a "_Dividir o código gerado em vários módulos subfuncionais pequenos e dar-lhes nomes significativos_", os resultados serão muito melhores, com menos erros no código gerado e uma taxa de sucesso maior na fase de correção iterativa.

A importância da tomada de decisão flexível e da validação dupla - Os modelos de linguagem grandes geralmente têm dificuldades com tarefas de código que exigem inferências ponderadas e racionais e a capacidade de tomar decisões sérias e não rotineiras. Por exemplo, ao gerar testes adicionais para um problema, os testes gerados pelo modelo geralmente contêm erros. Para resolver esse problema, introduzimos o processo de dupla validação. Nesse processo, após gerar o resultado inicial, o modelo é solicitado a gerar o mesmo resultado novamente e corrigi-lo, se necessário. Por exemplo, depois de receber como entrada seus próprios testes de IA gerados, o modelo precisa gerar novamente esses testes e corrigir os erros neles (se houver) em tempo hábil. Descobrimos que essa etapa de validação dupla não só motiva o modelo a pensar e raciocinar de forma crítica, mas também é mais eficaz do que fazer perguntas diretas de sim/não, como "Esse teste está correto?" como perguntas do tipo sim/não.

Atrasar a tomada de decisões, evitar perguntas diretas, dar espaço para a exploração - Quando fazemos perguntas complexas diretamente ao modelo, geralmente obtemos respostas erradas ou irrealistas. Portanto, adotamos uma abordagem semelhante à que Karpathy descreve no tweet abaixo, acumulando dados de forma incremental e passando gradualmente de tarefas simples para complexas:

• Começando com as tarefas mais simples, ou seja, autorreflexão sobre o problema e raciocínio sobre casos de teste abertos.
• Em seguida, passe a gerar testes adicionais de IA e possíveis soluções para o problema.
• Somente depois de obter as respostas do modelo para as tarefas acima é que passamos para o processo iterativo real de geração de código e execução de correções.

Karpathy: Isso se encaixa perfeitamente na "necessidade de um modelo de linguagem grande (LLM)". Token A ideia de "pensar". Em alguns casos, a cadeia de pensamento pode simplesmente servir para fornecer um armazenamento adicional de informações, em vez de desempenhar outras funções mais importantes.

Outro exemplo é que, em vez de escolher uma única solução algorítmica, avaliamos e classificamos várias soluções possíveis, priorizando as mais bem classificadas para a elaboração do código inicial. Como os modelos podem dar errado, preferimos evitar tomar decisões irreversíveis e, em vez disso, deixamos espaço para exploração e iterações de código que tentam diferentes soluções possíveis.

Tecnologia de teste de âncoras - Apesar de terem sido validados duas vezes, alguns testes gerados por IA ainda podem estar errados. Isso gera um problema: quando um teste falha, como podemos saber se é um problema com o código ou um erro no próprio teste? Ao consultar o modelo diretamente para saber "o que está errado", geralmente obtemos respostas irrealistas, o que às vezes leva a um código modificado incorretamente. Para enfrentar esse desafio, introduzimos uma abordagem chamada "âncoras de teste":

• Iterar primeiro nos testes que estão disponíveis publicamente e que são conhecidos por serem corretos. Quando essa etapa for concluída, todos os testes aprovados serão designados como testes de referência (testes âncora).
• Em seguida, comece a verificar os testes gerados pela IA, um a um.
• Aqueles que passam no teste são adicionados à lista de testes de âncora.
• Se o teste falhar, o padrão é que o código está incorreto e é feita uma tentativa de corrigir o código. É importante ressaltar que o código corrigido também deve passar em todos os testes de ancoragem existentes.

Dessa forma, os testes de ponto de ancoragem funcionam como uma proteção contra a correção incorreta do nosso código à medida que o corrigimos. Além disso, outro aprimoramento dos testes de ponto de ancoragem é classificar os testes gerados por IA em ordem de dificuldade. Isso tornou os testes de ponto de ancoragem mais prontamente disponíveis no início do processo iterativo, além de fornecer salvaguardas adicionais ao lidar com testes de IA mais complexos, especialmente ao lidar com testes de IA que tinham maior probabilidade de gerar resultados incorretos. Essa estratégia aumenta efetivamente a estabilidade e a confiabilidade do processo de teste, especialmente ao lidar com testes complexos e exigentes gerados por IA.

no final

Comparação de pontas diretas com AlphaCodium

Na Figura 5, comparamos os resultados do AlphaCodium com os de um único método de dica direta bem projetado. O critério de avaliação é pass@k (taxa de sucesso na solução do problema), ou seja, a proporção de soluções geradas pelo uso de k para cada problema.

Figura 5: Comparação do método AlphaCodium com o método de sugestão direta em diferentes modelos.

É possível observar que a abordagem AlphaCodium melhora de forma significativa e consistente o desempenho dos modelos de linguagem grande (LLMs) na solução de problemas de programação com o CodeContests. Essa conclusão se aplica tanto a modelos de código aberto (por exemplo, DeepSeek) quanto a modelos de código fechado (por exemplo, GPT), tanto em conjuntos de validação quanto de teste.

Comparação com outros estudos:

Na Tabela 3, mostramos os resultados do AlphaCodium em comparação com outros métodos da literatura.

Tabela 3: Comparação do AlphaCodium com outros trabalhos de pesquisa na literatura

Figura 6: Comparação de eficiência.

A figura mostra que a abordagem da AlphaCodium demonstra excelente desempenho em uma variedade de modelos e critérios de avaliação, especialmente ao resolver desafios de programação usando grandes modelos de linguagem. Esses resultados comparativos não apenas demonstram a inovação técnica da AlphaCodium, mas também destacam sua eficácia e aplicabilidade em aplicativos do mundo real.

De modo geral, o AlphaCodium demonstra seu notável potencial no campo da programação inteligente, especialmente no aprimoramento da capacidade dos modelos de linguagem de grande porte de lidar com problemas complexos de programação. Essas descobertas oferecem percepções importantes para pesquisas e desenvolvimentos futuros e fornecem referências valiosas para o desenvolvimento e a otimização de modelos de linguagem grandes.

Figura 6: Comparação de eficiência. É assim que a AlphaCodium se compara a outras soluções em termos de precisão em relação ao número de chamadas ao Large Language Model (LLM). Em comparação com a AlphaCode, a AlphaCodium requer milhares de vezes menos chamadas LLM para obter uma precisão semelhante.

Quando comparamos o AlphaCodium com o mesmo modelo GPT-3.5 e o critério de "taxa de aprovação em 5 tentativas" [Cadeia de códigoQuando comparado com [ ], fica claro que o AlphaCodium tem um desempenho melhor. Quando comparado com [Código AlfaAo comparar os métodos do [AlphaCode], é importante observar que o AlphaCode emprega uma estratégia de geração de código diferente: ele otimiza um modelo específico para resolver o problema de codificação, gera um grande número de cenários de codificação, classifica-os e, por fim, seleciona um número de cenários para envio a partir das classificações principais. Por exemplo, "10 tentativas aprovadas em 100.000 soluções" significa que ele gera 100.000 soluções, classifica-as e, em seguida, seleciona 10 para enviar. O AlphaCode usa um modelo especialmente otimizado que usa um número maior de chamadas LLM, semelhante a uma estratégia exaustiva. No entanto, o AlphaCodium teve um desempenho melhor em termos de resultados principais.

Também vale a pena mencionar que nem o AlphaCode nem o CodeChain fornecem soluções replicáveis, incluindo scripts de avaliação completos de ponta a ponta. Há muitos detalhes que precisam ser levados em conta ao avaliar os resultados, como lidar com tópicos de várias soluções, mecanismos de tolerância a falhas, problemas de tempo limite, etc. Nossa comparação baseia-se nos dados relatados em seus artigos, mas para a confiabilidade e a reprodutibilidade de futuras comparações, fornecemos um conjunto completo de código reprodutível e scripts de avaliação.

Comparação da força computacional: AlphaCode vs. AlphaCode2

No processo da AlphaCodium, a solução de cada problema requer cerca de 15 a 20 chamadas para o Modelo de Linguagem Grande (LLM), o que significa que, ao fazer cinco tentativas, são necessárias cerca de 100 chamadas para o LLM.

E o AlphaCode não informa explicitamente quantas chamadas ao modelo de linguagem grande são necessárias por problema. Se presumirmos que ele é chamado uma vez por tentativa (o que ainda é desconhecido e pode, na verdade, ser mais), então, para cada uma das 10 tentativas, filtradas das 100.000 soluções, ele precisaria chamar o modelo de linguagem grande 1 milhão de vezes, o que é quatro ordens de magnitude a mais do que o AlphaCodium. Entretanto, pelos resultados que vimos, o AlphaCodium tem um desempenho muito melhor, como demonstra claramente a Figura 3.

Um estudo publicado recentemente, chamado AlphaCode2 ([...Relatório técnico]) no qual os pesquisadores avaliaram um modelo chamado Gemini-Pro ajustado para problemas de programação. O estudo também explorou a avaliação comparativa do CodeContests, mas usando uma versão atualizada não publicada. De acordo com o relatório do AlphaCode2, com apenas cerca de 100 amostras, o AlphaCode2 atinge o nível de desempenho que o AlphaCode atinge com milhões de amostras, o que o torna mais de 10.000 vezes mais eficiente em termos de amostras do que o AlphaCode. Como resultado, tanto o AlphaCode2 quanto o AlphaCodium são muito mais eficientes do que o AlphaCode em termos do número de chamadas de modelos de linguagem grandes.

No entanto, o AlphaCode2 emprega um sistema elaborado, projetado especificamente para competições do CodeContests.ajuste finoO modelo AlphaCodium é baseado em um modelo básico moderno, enquanto o AlphaCodium usa um modelo genérico não modificado. Mesmo assim, o AlphaCodium melhora o desempenho do modelo sem dados adicionais e fases de treinamento caras.

apêndice

1) Um exemplo de avaliação manual de um problema de código:

/*

Em um conjunto de números, verifica se há dois números com uma distância entre eles que seja menor que um limite numérico específico. >>>

has_close_elements({1.0, 2.0, 3.0}, 0.5) false >>>

has_close_elements({1.0, 2.8, 3.0, 4.0, 5.0, 2.0}, 0.3) true

*/

#include

#include

#include

usando o namespace std;

bool has_close_elements(vector numbers, float threshold){

Tabela 4.O problema é relativamente intuitivo e simples, sem muitos detalhes ou sutilezas para o modelo raciocinar.

2) Por que a saída YAML é mais adequada para tarefas de geração de código do que a saída JSON

Embora a nova versão do GPT tenha [suporte nativo], mas acreditamos que, para a geração de código, a saída YAML é mais apropriada. Isso ocorre porque o código gerado geralmente contém aspas simples, aspas duplas e caracteres especiais. No formato JSON, é difícil para o LLM colocar esses caracteres corretamente, pois a saída JSON precisa ser cercada por aspas duplas. A saída YAML, por outro lado, [Adoção de escalares em blocoBasta seguir as regras de recuo e qualquer texto ou código devidamente recuado é legal. Além disso, a saída YAML tem menos tokens, o que significa menor custo e tempos de inferência mais rápidos, bem como melhor qualidade, pois o modelo tem menos tokens não críticos nos quais se concentrar. Aqui está um exemplo que compara a saída JSON e YAML (usando [https://platform.openai.com/tokenizer] gerado):

importar json

importar yaml

s1 = 'print("double quote string")'

s2 = "print('string entre aspas simples')"

s3 = 'print("""string de aspas triplas""")'

s4 = f"{s1}\n{s2}\n{s3}"

# Crie um dicionário com chaves como nomes de variáveis e valores como strings

data = {'s1': s1, 's2': s2, 's3': s3, 's4': s4}

# Converter dicionário em string no formato JSON

json_data = json.dumps(data, indent=2)

print(json_data)

# Conversão de dicionários em strings de formato YAML no estilo escalar de bloco

yaml_data = yaml.dump(data, indent=2, default_style='|')

print(yaml_data)

Saída.

Tabela 5.

Saída JSON:

Figura 7: Exemplo de contagem de tokens usando a saída JSON.

Um exemplo de saída YAML é mostrado abaixo:

Figura 8: Exemplo de contagem de tokens usando a saída YAML.

Obviamente, a geração de código que mantém apenas a indentação adequada não é apenas mais concisa e clara, mas também eficaz na redução de erros.