Codex (2021) 논문 리뷰

Codex 논문의 이름은 Evaluating Large Language Models Trained on Code다. (링크)

 

저자들은 Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, Wojciech Zaremba다. 

 

Github: 링크

 

Openai에서 공개한 Code 생성을 위한 LLM이다. 

 

 

2. Evaluation Framework

해당 섹션에서는 우선 pass@k metric을 정의한다. 손으로 쓴 문제 데이터셋에 대해서 HumanEval이라는 벤치마크도 소개한다. 마지막 단계에서는 model-generated code를 어떻게 안전하게 실행할 수 있는지에 대한 sandbox environment를 논한다. 

 

2.1. Functional Correctness

 

코드 생성에 대한 지배적인 벤치마크 중에서는 exact or fuzzy (BLEU score) match 등이 있다. 하지만 이는 대규모의 복잡한 프로그래밍 함수들에 대해서는 적용하기 어렵다. 때문에 최근에는 unsupervised code translation과 pseudocode-to-code translation을 funcational correctness로 전환한다.

 

Spoc: Search-based pseudocode to code 논문에서는 functional correctness에 pass@k metric을 사용한다. 이는 k개의 code samples를 만든 다음에 이를 unit tests에서 테스트 해보고 pass라면 이 숫자를 센다. $n \geq k$ per task를 생성한다. 이때 $n = 200. k \leq 100$의 값과 범위를 갖는다. Unit tests를 pass한 correct samples의 수를 $c \leq n$이라고 하면, pass@k의 unbiased estimator의 정의는 아래 (1)의 식과 같다. 

 

 

(1) 식을 코드로 쓴 식은 아래 Figure 3과 같다.

 

 

2.2. HumanEval: Hand-Written Evaluation Set

 

164개의 수작업으로 만든 프로그래밍 문제에 대한 functional correctness를 평가하는데 이를 HumanEval dataset이라고 한다. 각각의 문제는 function signature, docstring, body, and several unit tests, 그리고 문제마다 평균 7.7개의 tests를 갖는다.

데이터셋은 https://github.com/openai/human-eval에 소개되어 있다. 추가적으로 APPS dataset에는 Codeforces의 문제들에 대해 공개적으로 접근할 수 있다.

 

2.3. Sandox for Executing Generated Programs

 

공개적으로 제공되는 프로그램은 의도를 알 수 없고 생성된 프로그램은 종종 부정확한 경우가 있기 때문에 이러한 프로그램을 실행하면 보안 위험이 발생한다. 실제로 GitHub에는 환경을 변경하는 악성 프로그램이 포함된 것으로 알려져있다. 따라서 신뢰할 수 없는 프로그램을 unit tests 환경에서 안전하게 실행할 수 있는 샌드박스 환경을 개발했다. 주요 host protection 구성 요소로서  gVisor container runtime을 선택했다. eBPF-based firewall rules에 의해서 실험에 필요한 경우를 제외하고 네트워크의 inbound와 outbound를 차단한다. 

 

 

3. Code Fine-Tuning

12B 까지의 크기를 가진 GPT 모델들을 파인튜닝해서 Codex를 구성한다. 

 

3.1. Data Collection

 

2020년 5월까지 54 M의 Github의 public software repos를 수집했으며, 1MB 이하의 유니크한 python files를 총 179 GB다. Auto-generated인 것 같은 코드, 평균 100 줄 이상인 코드, 최대 길이가 1000 이상인 경우, alphanumeric characters를 조금만 가진 경우를 모두 필터링한다. 필터링한 다음의 데이터 셋의 크기는 159 GB다.

 

3.2. Methods

 

GPT-3 모델을 파인튜닝한다. 175 step linear warmup과 cosine learning rate decay를 적용한다. 총 100 B의 tokens에 대해서, Adam과 $\beta_1 = 0.9, \beta_2 = 0.95, \epsilon = {10}^{-8}$, weight decay coefficient 0.1을 가지고 학습한다. 

 

Stop sequences인 토큰은 다음과 같다.

 

• \nclass
• \ndef
• \n#
• \nif
• \nprint

 

HumanEval 데이터 셋의 문제 예시는 아래 Figure 2에 소개되어 있다.

 

 

 

 

 

아래 Table 1은 GPT-NEO, GPT-J, TabNine과 Codex의 HumanEval에 대한 실험 결과를 보여준다.

 

 

 

4. Supervised Fine-Tuning

GitHub에 있는 파이썬 코드들에는 class implementations, configuration files, scripts, 그리고 저장에 사용되는 files 도 포함하고 있다. 

 

 

Codex의 관심있는 태스크의 분포와 관련된 문제들로 정리하기 위해서 독립적으로 실행되는 함수들 위주로 데이터를 수립한다.

 

 

4.1. Problems from Competitive Programming

 

프로그래밍 컨테스트나 면접 준비 웹사이트에 있는 숨겨진 unit tests가 있다. 여기에는 잘 작성된 문제 설명과 테스트 커버리지를 가진다. 저자들은 여러 유명 프로그래밍 콘테스트 및 면접 준비 웹사이트에서 문제 설명, 함수 시그니처, 그리고 해결책을 수집했다. 그 다음 문제 설명을 docstring으로 사용하여 HumanEval과 유사한 데이터셋을 만들었다. 

 

 

 

4.2. Problems from Continuous Integration

Continuous Integration (CI)는 프로젝트 추적에 이상적인 후보다. 빌드 및 테스트 명령이 포함된 CI 구성 파일의 명령에 따라 가상 환경을 설정하고, 종속성을 설치하고, 통합 테스트를 실행한다. 이러한 프로젝트에는 신뢰할 수 없는 코드가 포함되어 있기에 위에서 설명한 샌드박스 환경에서 통합 테스트의 실행이 중효하다.
문제를 선별할 수 있는 잠재적 함수는 수백만 개에 달하지만, 모든 함수가 입력을 받고 출력을 반환하는 것은 아니기 때문에 약 4만 개만 수집했다. 그렇게 하더라도, 런타임에 캡처된 대부분의 객체는 프로젝트가 설치되지 않은 경우 샌드박스 외부에서 피클링 및 복원될 수 없었다.
Tracing 추적 방법론은 호출된 모든 함수에 대해 입력과 출력을 생성했기 때문에, 프로젝트에서 가져온 내장 및 라이브러리 호출조차도 문제로 간주되었다. 이러한 이유로 추적에서 생성된 함수는 명령줄 유틸리티의 구성 요소가 되는 경향이 있었다. 이러한 작업을 성공적으로 수행하기 위해 모델은 고급 알고리즘이나 데이터 구조를 알 필요가 없다. 오히려 docstring에 명시된 기능을 구현하기 위한 instructions 지침을 따를 수 있어야 한다. 따라서 추적은 코딩 경진 대회 문제의 퍼즐적 특성을 보완하고 작업 분포를 넓혀줍니다.

 

 

4.3. Filtering Problems

 

문제 품질의 제어가 어렵다. 일부 프롬프트에서는 함수가 제대로 구체화되어 있지 않아서 패너리를 받을 수도 있다. 

이를 해결하기 위해서 Codex-12B를 이용해서 curated problem 마다 100개의 샘플을 생성한다. 단위 테스트를 통과하는 샘플이 없으면 작업이 모호하거나 너무 어렵다고 판단하여 필터링한다. 상태가 안정적으로 유지되거나 비결정적인 상황을 제거하기 위해 이 검증을 여러 번 다시 실행했다.

 

Codex-S를 Supservised fine-tuned Codex다. 

 

 

4.5. Results

 

아래에서는 GPT-Neo와 Codex를 둘 다 SFT한 다음 비교한 결과다. 

 

 

Problem Sample

 

이제 문제와 올바른 completion와 틀린 completion의 예시로 마무리한다.