AlphaCodium: 힌트 엔지니어링에서 프로세스 엔지니어링까지, 코드 생성의 새로운 영역을 선도하는 기업

원본: [AlphaCodium을 사용한 최첨단 코드 생성 - 프롬프트 엔지니어링에서 흐름 엔지니어링까지]

By 탈 리드닉

 

 

 

훑어보기

 

코드 생성의 과제는 대상 프로그래밍 언어의 구문 규칙을 엄격하게 따르고, 정상 및 경계 사례를 식별하고, 문제 사양의 수많은 세부 사항에 주의를 기울이고, 코드에 특정한 다른 문제와 요구 사항에 대처하는 등 일반적인 자연어 처리의 과제와는 다릅니다. 따라서 자연어 생성 분야에서 일반적으로 사용되는 많은 최적화 기법이 코드 생성 작업에는 적용되지 않을 수 있습니다.

 

이 연구에서는 다음과 같은 새로운 코드 생성 방법을 제안합니다. 알파나트륨 -- 테스트 기반의 단계적, 코드 중심의 반복적 처리 프로세스입니다. 이 접근 방식은 대규모 언어 모델(LLM)이 코드 문제를 처리하는 능력을 크게 향상시킵니다.

 

코드포스와 같은 플랫폼의 경연 프로그래밍 주제가 포함된 까다로운 코드 생성 데이터 세트인 CodeContests에서 AlphaCodium을 테스트했습니다. 이러한 테스트에서 우리의 접근 방식은 일관되게 상당한 성능 향상을 달성했습니다.

 

예를 들어, 검증 데이터 세트에서 AlphaCodium 프로세스를 사용한 후 잘 설계된 단일 직접 큐를 사용하여 GPT-4의 정확도(통과율@5)가 19%에서 44%로 향상되었으며, AlphaCodium은 AlphaCode와 같은 이전 연구보다 성능이 우수할 뿐만 아니라 훨씬 적은 계산 리소스를 필요로 합니다. 알파코듐.

 

이 작업에서 개발된 많은 원칙과 모범 사례는 일반적으로 코드 생성의 다양한 작업에 적용될 수 있다고 생각합니다. 최신 오픈소스 프로젝트 [알파나트륨코드 콘테스트를 위한 AlphaCodium 솔루션은 ]에서 공유되며, 커뮤니티의 추가 연구와 탐색을 위한 전체 데이터 세트 평가 및 벤치마킹 스크립트가 포함되어 있습니다.

 

 

CodeContests 데이터 세트 구문 분석

 

[코드 콘테스트]는 구글 딥마인드의 고난이도 프로그래밍 데이터 세트입니다. 다음과 같은 데이터에서 가져옵니다.코드포스와 같은 대회 프로그래밍 플랫폼은 대규모 언어 모델(예: GPT 또는 DeepSeek) 복잡한 프로그래밍 문제를 해결할 수 있는 능력.

 

이 연구는 완전히 새로운 모델을 개발하는 것이 아니라 이미 코딩 작업을 처리할 수 있는 다양한 대규모 언어 모델에 적용할 수 있는 프로그래밍 프로세스를 만드는 데 중점을 두었습니다. 따라서 107개와 165개의 프로그래밍 문제로 구성된 코드 콘테스트의 검증 및 테스트 세트에 초점을 맞췄습니다. 그림 1은 데이터 세트의 일반적인 문제 예시를 보여줍니다:

 

 

각 문제에는 문제에 대한 설명과 모델 입력으로 직접 사용할 수 있는 공개적으로 사용 가능한 일부 테스트 데이터가 포함되어 있습니다. 문제는 모든 정당한 입력에 대해 정답을 제공하는 절차를 작성하는 것입니다. 또한 제출된 절차의 정확성을 평가하는 데 사용되는 공개되지 않은 테스트 세트가 있습니다.

 

코드 콘테스트가 대규모 언어 모델의 프로그래밍 성능을 테스트하는 데 이상적인 데이터 세트인 이유는 무엇인가요? 첫째, 다른 프로그래밍 경시대회 데이터 세트와 달리 CodeContests에는 평가의 정확성을 보장하기 위해 대량의 비공개 테스트 데이터(문제당 약 200개의 테스트 케이스)가 포함되어 있습니다. 둘째, 대규모 언어 모델은 일반적으로 올바른 솔루션을 찾는 데 중요한 문제 설명의 세부 사항을 잘 알아채지 못하는데, CodeContests의 문제 설명은 일반적으로 복잡하고 상세하며 솔루션에 영향을 미치는 뉘앙스로 가득합니다(그림 1에 전형적인 예가 나와 있습니다). 이 디자인은 실제 문제의 복잡성을 시뮬레이션하여 모델이 여러 요소를 고려하도록 하는데, 이는 더 단순하고 간단한 일부 데이터 세트(예: [HumanEval])는 극명한 대조를 이룹니다. 일반적인 휴먼에벌 프로그래밍 문제는 부록 1에 설명되어 있습니다.

 

그림 2는 이 모델이 그림 1의 문제를 심층적으로 분석하는 방법을 보여줍니다. 문제를 심층적으로 분석하면 문제가 더 명확해지고 구조화되므로 프로그래밍 과정에서 문제를 더 깊이 이해하는 것이 중요하다는 것을 강조합니다.

 

 

 

제안된 방법론

 

코드 생성의 복잡한 문제를 다룰 때, 단일 프롬프트 최적화나 연속적 사고 프롬프트 모두 CodeContest에서 대규모 언어 모델(LLM)의 문제 해결 효율성을 크게 향상시키지 못한다는 사실을 발견했습니다. 이는 모델이 문제를 완전히 이해하지 못해 부정확하거나 새로운 테스트 케이스에 대처할 수 없는 코드를 반복적으로 생성하는 경우가 많기 때문입니다. 일반적인 자연어 처리에 적용되는 접근 방식은 코드 생성 작업에는 적합하지 않을 수 있습니다. 이러한 작업은 생성된 코드를 반복적으로 실행하고 알려진 예제와 비교하여 검증하는 등 큰 잠재력을 숨기고 있습니다. 일반 자연어 처리의 큐 최적화 기법과 달리, 코드 생성 및 테스트를 사용하여 CodeContest 문제를 해결하는 것이 특히워크플로더 효과적입니다. 이 프로세스는 다음을 중심으로 진행됩니다.반복(수학)즉, 생성된 코드가 입출력 테스트를 통과할 수 있도록 지속적으로 실행하고 조정하는 프로세스가 전개됩니다. 이 코드별 프로세스의 두 가지 핵심 측면은 다음과 같습니다:

(a) 반복 프로세스를 지원하기 위해 전처리 단계에서 추가 데이터(예: 오픈 테스트 케이스에 대한 자체 반영 및 추론)를 생성하고 (b) AI가 생성한 추가 테스트 케이스로 오픈 테스트 케이스를 보강하는 것입니다. 그림 3에서는 레이스 프로그래밍 문제를 해결하기 위해 설계한 프로세스를 보여줍니다:

 

 

 

그림 3의 프로세스는 크게 두 단계로 나뉩니다:

• 전처리 단계에서는 선형적인 프로세스인 자연어를 사용하여 문제를 추론합니다.
• 코드 반복 단계에서는 다양한 테스트를 위한 코드를 생성, 실행 및 수정하는 여러 반복 세션을 포함합니다.

 

표 1에서는 이러한 여러 단계를 자세히 살펴봅니다:

무대 이름	사명 선언문
문제 반영	문제의 목표, 입력, 출력, 규칙, 제약 조건 및 기타 중요한 세부 사항을 포함하는 간결한 글머리 기호 형태로 문제를 요약합니다.
오픈 테스트 케이스의 논리적 분석	각 테스트 케이스의 입력이 어떻게 특정 출력으로 이어지는지 설명하세요.
가능한 솔루션 개념화	2~3가지 가능한 해결책을 제안하고 일반인이 이해하기 쉬운 용어로 설명하세요.
솔루션 평가	가능한 다양한 솔루션을 평가하고 정확성, 단순성, 견고성을 고려하여 가장 적합한 솔루션을 선택합니다. (가장 효율적인 옵션으로 제한할 필요는 없습니다.)
추가 AI 테스트	원래의 오픈 테스트 케이스에서 다루지 않은 상황과 측면을 다루는 6~8가지 유형의 입출력 테스트로 문제를 보완합니다.
초기 코드 프로그램	이 단계의 목표는 문제에 대한 초기 코드 솔루션을 구성하는 것입니다. 이 코드는 가능한 한 정답에 가깝게 작성해야 이후 수정 프로세스에서 성공할 가능성이 높아집니다. 운영 프로세스는 다음과 같습니다: - 가능한 시나리오를 선택하고, 그에 맞는 코드를 작성하여 일부 공개 테스트 사례와 AI 테스트에서 사용해 보세요. - 테스트가 통과되거나 최대 시도 횟수에 도달할 때까지 이 과정을 반복합니다. - 테스트를 통과한 첫 번째 코드 또는 정답에 가장 가까운 출력을 가진 코드가 후속 단계의 기본 코드로 사용됩니다.
오픈 테스트 케이스의 반복적 최적화	기본 코드를 시작점으로 삼아 열려 있는 테스트 케이스에서 하나씩 실행하고 최적화하세요. 테스트 중 하나에서 코드에 문제가 있는 경우 오류 메시지에 따라 문제를 해결해 보세요.
AI 테스트를 위한 반복적 최적화	AI 생성 테스트에서 반복적인 최적화를 계속합니다. '테스트 앵커'(테스트의 특정 요소를 수정하여 코드를 보다 정확하게 디버그하고 개선하는 기술)를 적용합니다.

 

표 1. 알파나트륨 단계의 특성.

 

제안된 프로세스를 탐색하면서 저희는 깊은 직관과 통찰력을 얻었습니다.

첫째누적 지식과정의 단계: 간단한 과제부터 시작하여 점차 더 복잡한 문제에 도전하게 됩니다. 예를 들어, 프로세스의 첫 번째 단계인 _자기 성찰_에서는 다음과 같은 더 어려운 후속 단계에서 사용할 수 있는 지식을 배웁니다.가능한 솔루션 생성. 프로세스의 전처리 단계는 프로세스에서 가장 어렵고 중요한 부분인 코드 반복을 위한 결과를 생성하며, 실제로 문제를 올바르게 해결하는 코드를 작성하려고 시도합니다.

 

다음.추가 AI 테스트를 생성하는 것은 전체 솔루션 코드 세트를 생성하는 것보다 쉽습니다. -- 이 프로세스는 유용한 입출력 테스트 쌍을 생성하기 위해 문제를 완전히 풀지 않고도 문제를 이해하고 기본적인 무차별 암호 해독 또는 논리적 추론에 크게 의존합니다. 이는 모든 입출력 테스트 쌍에 올바르게 응답할 수 있는 완전한 알고리즘 솔루션을 만들어야 하는 완전하고 정확한 솔루션 코드를 작성하는 것과는 다릅니다. 결과적으로 그림 4와 같이 더 많은 AI 테스트를 생성하고 이를 사용하여 코드 생성 단계를 최적화할 수 있습니다. 또한 대규모 입력, 에지 케이스 처리 등과 같이 원래의 공개 테스트 사례에서 다루지 않는 부분에 집중하도록 모델에 요청하여 이러한 추가 테스트의 효율성을 더욱 높일 수 있습니다.

 

마지막으로.여러 단계를 하나의 LLM(대규모 언어 모델) 호출로 결합할 수 있습니다. -- 그림 3에 표시된 프로세스는 개념적인 데모로, 프로세스의 주요 단계를 강조하고 있습니다. 실제로는 출력을 구조화하여(다음 섹션 참조) 여러 단계를 하나의 대규모 언어 모델 호출로 결합하여 리소스를 절약하거나 특정 작업을 동시에 처리할 때 모델의 성능을 개선할 수 있습니다.

 

 

모델은 직접적인 힌트만으로 코드 문제를 해결할 때 종종 어려움을 겪습니다. 공개적으로 사용 가능한 테스트 사례를 반복하면 솔루션이 안정화되고 개선되지만, 공개적으로 사용 가능한 테스트 사례는 충분히 포괄적이지 않기 때문에 '사각지대'가 남습니다. 전처리 단계와 공개 및 AI 생성 테스트에 대한 반복을 포함한 전체 알파코디움 프로세스를 사용하면 솔루션의 품질을 더욱 개선하고 문제 해결의 성공률을 크게 높일 수 있습니다.

 

 

코드 디자인 개념

 

이 섹션에서는 코드 생성 문제를 해결할 때 유용한 몇 가지 설계 개념, 기법 및 모범 사례를 소개합니다. 그림 3에서 소개하는 AlphaCodium 프로세스는 이러한 설계 개념을 광범위하게 활용합니다:

YAML 구조화된 출력: 우리가 제안한 프로세스의 핵심은 구조화된 출력의 사용으로, 모델이 특정 Pydantic 클래스에 해당하는 YAML 형식의 출력을 생성하도록 요구합니다. 예시입니다:

...

여러분의 목표는 가능한 해결책을 제시하는 것입니다.

각 프로그램에서 문제의 목표, 규칙 및 제약 조건이 충분히 고려되었는지 확인합니다.

출력은 다음 Pydantic 정의에 따라 $P가능 솔루션 유형에 해당하는 YAML 객체여야 합니다:

클래스 Solution(BaseModel).

name: str = Field(description="솔루션 이름")

content: str = 필드(설명=솔루션 설명")

why_it_works: str = Field(description="이 솔루션이 작동하는 이유. 문제의 규칙과 목표에 대해 구체적으로 자세히 설명해야 합니다.")

복잡성: str = Field(description="솔루션의 복잡성")

클래스 PossibleSolutions(BaseModel).

possible_solutions: List[Solution] = Field(max_items=3, description="문제에 대한 가능한 해결책의 목록입니다. 각 솔루션이 문제의 규칙과 목표를 충분히 고려하고 최신 컴퓨터에서 합리적인 실행 시간(입력이 많은 문제 제약 조건의 경우 3초 이하)을 갖도록 하세요.")

표 2. 구조화된 출력 프롬프트의 예(가능한 솔루션 생성 단계).

구조화된 출력은 '큐 엔지니어링'의 복잡성과 해킹의 필요성을 줄여주는 대신 복잡한 작업을 코드와 같은 간단한 방식으로 제시합니다. 또한 논리적이고 체계적인 사고 과정을 반영하여 여러 단계가 포함된 복잡한 답을 얻을 수 있습니다.

새 버전의 GPT는 [...]를 지원하지만JSON 스타일] 출력을 사용할 수 있지만, 특히 코드 생성 작업에서는 부록에 자세히 설명된 대로 YAML 출력이 더 적합하다고 생각합니다.

 

글머리 기호 분석 - 대규모 언어 모델(LLM)에 문제를 분석하도록 요청할 때 일반적으로 글머리 기호 형식으로 출력을 요청하면 더 나은 결과를 얻을 수 있습니다. 글머리 기호는 문제에 대한 심층적인 이해를 촉진하고 모델이 출력을 논리적 의미 영역으로 나누도록 하여 결과의 품질을 향상시킵니다. 예를 들어, 글머리 기호 자기 성찰 문제(그림 2 참조)의 경우 각 글머리 기호는 일반 설명, 목표 및 규칙, 입력 구조, 출력 구조 등 문제의 서로 다른 부분에 대한 의미론적 이해를 나타냅니다.

 

빅 언어 모델은 모듈식 코드 생성에 더 효과적입니다. - 대규모 언어 모델(LLM)을 사용하여 긴 개별 함수 블록을 작성할 때 종종 코드에 오류나 논리 구멍이 생기는 등의 문제가 발생합니다. 더 큰 문제는 이러한 크고 모놀리식 코드 덩어리가 문제를 해결하기 위한 후속 반복 작업을 방해할 수 있다는 점입니다. 오류 정보가 제공되더라도 모델이 문제를 정확히 찾아서 수정하기는 어렵습니다. 그러나 모델에 "_생성된 코드를 여러 개의 작은 하위 기능 모듈로 분할하고 의미 있는 이름을 부여하라_"고 명시적으로 지시하면 생성된 코드의 오류가 줄어들고 반복적인 수정 단계에서 성공률이 높아지는 등 결과가 훨씬 더 좋아질 것입니다.

 

유연한 의사 결정과 이중 검증의 중요성 - 대규모 언어 모델은 사려 깊고 합리적인 추론과 일상적이지 않은 심각한 결정을 내리는 능력이 필요한 코드 작업에서 종종 어려움을 겪습니다. 예를 들어, 문제에 대한 추가 테스트를 생성할 때 모델에서 생성된 테스트에 오류가 있는 경우가 많습니다. 이 문제를 해결하기 위해 이중 유효성 검사 프로세스를 도입했습니다. 이 프로세스에서는 초기 출력을 생성한 후 모델에 동일한 출력을 다시 생성하고 필요한 경우 수정하도록 요청합니다. 예를 들어, 자체적으로 생성한 AI 테스트를 입력으로 받은 후, 모델은 이러한 테스트를 다시 생성하고 오류가 있는 경우 제때 수정해야 합니다. 이러한 이중 검증 단계는 모델이 비판적으로 사고하고 추론하도록 동기를 부여할 뿐만 아니라 "이 테스트가 맞습니까?"와 같은 직접적인 예/아니오 질문을 하는 것보다 더 효과적이라는 사실을 발견했습니다. 예/아니오 질문과 같은 직접적인 질문보다 효과적입니다.

 

의사 결정 지연, 직접적인 질문 피하기, 탐색을 위한 공간 제공 - 모델에 직접 복잡한 질문을 하면 잘못되거나 비현실적인 답변을 얻는 경우가 많습니다. 따라서 아래 트윗에서 Karpathy가 설명한 것과 유사한 접근 방식을 취하여 데이터를 점진적으로 축적하고 간단한 작업에서 복잡한 작업으로 점진적으로 전환했습니다:

• 가장 간단한 작업, 즉 문제에 대한 자기 성찰과 미해결 테스트 케이스에 대한 추론부터 시작하세요.
• 그런 다음 추가 AI 테스트와 문제에 대한 가능한 해결책을 생성하는 단계로 이동합니다.
• 위의 작업에 대한 모델의 답을 얻은 후에야 코드를 생성하고 수정을 실행하는 실제 반복 프로세스로 넘어갑니다.

 

 

또 다른 예로, 하나의 알고리즘 솔루션을 선택하는 대신 여러 가지 가능한 솔루션을 평가하고 순위를 매겨 가장 높은 순위에 있는 솔루션을 초기 코드 작성에 우선순위를 둡니다. 모델이 잘못될 수 있기 때문에 돌이킬 수 없는 결정을 내리지 않고 대신 다양한 가능한 솔루션을 시도하는 탐색과 코드 반복을 위한 여지를 남겨두는 것을 선호합니다.

 

앵커 기법 테스트 - 두 번의 검증을 거쳤음에도 불구하고 일부 AI가 생성한 테스트는 여전히 틀릴 수 있습니다. 테스트가 실패하면 코드의 문제인지 테스트 자체의 실수인지 어떻게 알 수 있을까요? 모델에 "무엇이 잘못되었는지"를 직접 쿼리하면 종종 비현실적인 답변을 얻을 수 있으며, 때로는 잘못 수정된 코드로 이어지는 경우도 있습니다. 이 문제를 해결하기 위해 "테스트 앵커"라는 접근 방식을 도입했습니다:

• 먼저 공개적으로 사용 가능하고 올바른 것으로 알려진 테스트를 반복합니다. 이 단계가 완료되면 통과된 모든 테스트가 벤치마크 테스트(앵커 테스트)로 지정됩니다.
• 그런 다음 AI가 생성한 테스트를 하나씩 확인합니다.
• 테스트를 통과한 항목은 앵커 테스트 목록에 추가됩니다.
• 테스트에 실패하면 기본적으로 코드가 잘못된 것으로 간주하고 코드를 수정하려고 시도합니다. 중요한 것은 수정된 코드가 기존의 모든 앵커 테스트도 통과해야 한다는 것입니다.

 

이러한 방식으로 앵커 테스트는 코드를 수정할 때 잘못 수정되는 것을 방지하는 역할을 합니다. 또한, 앵커 포인트 테스트의 또 다른 개선 사항은 AI 생성 테스트를 난이도 순으로 정렬하는 것입니다. 이를 통해 반복 프로세스 초기에 앵커 테스트를 더 쉽게 사용할 수 있게 되었으며, 특히 잘못된 출력이 발생할 가능성이 높은 AI 테스트를 다룰 때 추가적인 안전장치를 제공했습니다. 이 전략은 특히 복잡하고 까다로운 AI 생성 테스트를 처리할 때 테스트 프로세스의 안정성과 신뢰성을 효과적으로 향상시킵니다.

 

 

결국

 

다이렉트 팁과 알파나트륨의 비교

그림 5는 알파코디움의 결과를 잘 설계된 단일 직접 힌트 방법의 결과와 비교한 것입니다. 평가 기준은 pass@k(문제 해결 성공률), 즉 각 문제에 대해 k를 사용하여 생성된 솔루션의 비율입니다.

 

 

AlphaCodium 접근 방식은 CodeContests로 프로그래밍 문제를 해결할 때 대규모 언어 모델(LLM)의 성능을 상당히 일관되게 향상시킨다는 것을 알 수 있습니다. 이 결론은 검증 및 테스트 세트 모두에서 오픈 소스 모델(예: DeepSeek)과 비공개 소스 모델(예: GPT) 모두에 적용됩니다.

 

다른 연구와 비교:

표 3에는 문헌의 다른 방법과 비교한 AlphaCodium의 결과가 나와 있습니다.

 

모델링	데이터 집합	방법론	점수
GPT-3.5	유효성 검사 집합	알파나트륨  (pass@5)	25%
GPT-3.5	유효성 검사 집합	코드체인 (pass@5)	17%
GPT-3.5	테스트 세트	알파나트륨 (pass@5)	17%
GPT-3.5	테스트 세트	코드체인 (pass@5)	14%
GPT-4	유효성 검사 집합	알파나트륨 (pass@5)	44%
딥마인드 미세 조정	유효성 검사 집합	AlphaCode (pass@10@1K)	17%
딥마인드 미세 조정	AlphaCode (pass@10@100K)	24%
GPT-4	테스트 세트	알파나트륨 (pass@5)	29%
딥마인드 미세 조정	테스트 세트	AlphaCode (pass@10@1K)	16%
딥마인드 미세 조정	테스트 세트	AlphaCode (pass@10@100K)	28%
Gemini-pro	AlphaCode2: 기존 CodeContests 버전에서는 AlphaCode2에 대한 비교 결과가 보고되지 않습니다. 에 따르면 알파코드2에 대한 기술 보고서연구진은 미공개 데이터 세트에 대한 AlphaCode의 결과와 AlphaCode2의 결과를 비교한 결과 대규모 언어 모델(LLM) 호출 수가 크게 줄어든 것을 발견했습니다(@100) 경우, AlphaCode2는 AlphaCode와 비슷한 성능을 발휘합니다. 29%, pass@10.

 

표 3: 알파나트륨과 다른 문헌의 연구 결과 비교

 

이 그림은 AlphaCodium 접근 방식이 다양한 모델과 평가 기준, 특히 대규모 언어 모델을 사용하여 프로그래밍 문제를 해결할 때 탁월한 성능을 발휘한다는 것을 보여줍니다. 이러한 비교 결과는 AlphaCodium의 기술적 혁신을 보여줄 뿐만 아니라 실제 애플리케이션에서의 효과와 적용 가능성을 강조합니다.

 

전반적으로 알파코디움은 지능형 프로그래밍 분야에서, 특히 복잡한 프로그래밍 문제를 처리하는 대규모 언어 모델의 능력을 향상시키는 데 있어 놀라운 잠재력을 보여줬습니다. 이러한 연구 결과는 향후 연구 개발에 중요한 통찰력을 제공하며 대규모 언어 모델의 추가 개발 및 최적화를 위한 귀중한 참고 자료가 될 것입니다.

 

그림 6: 효율성 비교. 이것이 대규모 언어 모델(LLM) 호출 수 대비 정확도 측면에서 다른 솔루션과 AlphaCodium을 비교하는 방식입니다. AlphaCode와 비교했을 때 AlphaCodium은 비슷한 정확도를 달성하기 위해 수천 배 더 적은 수의 LLM 호출이 필요합니다.

동일한 GPT-3.5 모델과 '5회 시도 합격률' 기준으로 AlphaCodium을 비교했을 때 [코드체인[ ]와 비교했을 때, 알파코디움의 성능이 더 우수하다는 것을 알 수 있습니다. 와 비교했을 때 [ [AlphaCode알파코드]의 방식을 비교할 때, 알파코드는 코딩 문제를 해결하기 위해 특정 모델을 최적화하고 많은 수의 코딩 시나리오를 생성한 다음 이를 분류하고 최종적으로 주요 분류에서 제출할 여러 시나리오를 선택하는 다른 코드 생성 전략을 사용한다는 점에 유의하는 것이 중요합니다. 예를 들어 "100,000개의 솔루션 중 10개의 통과 시도"는 100,000개의 솔루션을 생성하고 분류한 다음 제출할 10개를 선택한다는 의미로, AlphaCode는 철저한 전략과 유사하게 더 많은 수의 LLM 호출을 사용하는 특별히 최적화된 모델을 사용합니다. 그럼에도 불구하고 AlphaCodium은 최고 결과 측면에서 더 나은 성능을 보였습니다.

 

알파코드나 코드체인 모두 완전한 엔드투엔드 평가 스크립트를 포함해 복제 가능한 솔루션을 제공하지 않는다는 점도 언급할 가치가 있습니다. 다중 솔루션 주제, 내결함성 메커니즘, 시간 초과 문제 등을 다루는 등 결과를 평가할 때 고려해야 할 세부 사항이 많이 있습니다. 비교는 논문에서 보고된 데이터를 기반으로 하지만, 향후 비교의 신뢰성과 재현성을 위해 재현 가능한 코드 및 평가 스크립트의 전체 세트를 제공합니다.

 

연산 능력 비교: AlphaCode와 AlphaCode2

알파코디움의 프로세스에서 각 문제를 풀려면 대규모 언어 모델(LLM)을 약 15~20회 호출해야 하는데, 이는 5번 시도하는 과정에서 약 100번의 LLM 호출이 필요하다는 뜻입니다.

 

그리고 알파코드는 문제당 얼마나 많은 대규모 언어 모델 호출이 필요한지 명시적으로 보고하지 않습니다. 시도당 한 번 호출한다고 가정하면(아직 알려지지 않았으며 실제로는 더 많을 수도 있음), 100,000개의 솔루션에서 필터링한 10개의 시도 각각에 대해 대규모 언어 모델을 100만 번 호출해야 하며, 이는 AlphaCodium보다 4배나 많은 횟수입니다. 그러나 지금까지 살펴본 결과에서 알 수 있듯이 그림 3에서 알 수 있듯이 AlphaCodium의 성능이 훨씬 우수합니다.

 

최근 발표된 AlphaCode2라는 연구([...기술 보고서])에서 연구원들은 프로그래밍 문제에 맞게 미세 조정된 Gemini-Pro라는 모델을 평가했습니다. 이 연구는 또한 CodeContests의 벤치마킹을 시도했지만, 아직 공개되지 않은 업데이트 버전을 사용했습니다. 알파코드2 보고서에 따르면 알파코드2는 약 100개의 샘플만으로 알파코드가 수백만 개의 샘플로 달성하는 수준의 성능을 달성하여 알파코드보다 10,000배 이상 샘플 효율이 높습니다. 그 결과, 대규모 언어 모델 호출 수 측면에서 AlphaCode2와 AlphaCodium 모두 AlphaCode보다 훨씬 더 효율적입니다.

 

하지만 알파코드2는 코드 콘테스트 대회를 위해 특별히 설계된 정교한 시스템을 사용합니다.미세 조정AlphaCodium 모델은 최신 기본 모델을 기반으로 하는 반면, AlphaCodium은 수정되지 않은 일반 모델을 사용합니다. 그럼에도 불구하고 AlphaCodium은 추가 데이터와 값비싼 학습 단계 없이도 모델의 성능을 향상시킵니다.

 

부록

 

1) 코드 문제에 대한 수동 평가의 예입니다:

/*

숫자 집합에서 두 숫자 사이의 거리가 특정 숫자 임계값보다 작은 두 숫자가 있는지 확인합니다. >>>

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

네임스페이스 STD를 사용합니다;

bool has_close_elements(벡터 숫자, 플로트 임계값){

 

표 4.문제는 비교적 직관적이고 간단하며, 모델이 추론해야 할 세부 사항이나 미묘한 부분이 많지 않습니다.

 

2) YAML 출력이 JSON 출력보다 코드 생성 작업에 더 적합한 이유

새 버전의 GPT에는 [...네이티브 지원)를 사용할 수도 있지만, 코드 생성의 경우 YAML 출력이 더 적합하다고 생각합니다. 생성된 코드에는 작은따옴표, 큰따옴표 및 특수 문자가 포함되는 경우가 많기 때문입니다. JSON 형식에서는 JSON 출력을 큰따옴표로 묶어야 하기 때문에 LLM이 이러한 문자를 올바르게 배치하기 어렵습니다. 반면에 YAML 출력은 [[큰따옴표로 묶어야 합니다.블록 스칼라 채택스타일로 들여쓰기 규칙을 따르기만 하면 들여쓰기된 텍스트나 코드는 모두 합법적입니다. 또한 YAML 출력에는 토큰 수가 적기 때문에 비용이 절감되고 추론 시간이 빨라질 뿐만 아니라 모델에 집중해야 할 중요하지 않은 토큰이 적어 품질이 향상됩니다. 다음은 JSON과 YAML 출력을 비교하는 예시입니다([[] 사용).https://platform.openai.com/tokenizer] 생성됨):

json 가져오기

yaml 가져오기

s1 = 'print("큰따옴표 문자열")'

s2 = "print('작은따옴표 문자열')"

s3 = 'print("""큰따옴표 문자열""")'

S4 = F"{S1}\N{S2}\N{S3}"

# 키를 변수 이름으로, 값을 문자열로 사용하여 사전을 만듭니다.

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

# 사전을 JSON 형식의 문자열로 변환하기

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

print(json_data)

# 블록 스칼라 스타일로 사전을 YAML 형식 문자열로 변환하기

yaml_data = yaml.dump(데이터, 들여쓰기=2, 기본_스타일='|')

print(yaml_data)

출력.

 

표 5.

JSON 출력:

 

그림 7: JSON 출력을 사용한 토큰 카운팅 예시.

YAML 출력 샘플은 아래와 같습니다:

 

 

그림 8: YAML 출력을 사용한 토큰 카운팅의 예.

물론 적절한 들여쓰기만 유지하는 코드를 생성하는 것이 더 간결하고 명확할 뿐만 아니라 오류를 줄이는 데도 효과적입니다.