PreprintCited by 1,436Software Engineering ResearchNatural Language Processing TechniquesLogic, programming, and type systems

Evaluating Large Language Models Trained on Code

Open access
Chen, Mark, Tworek, Jerry, Jun, Heewoo, Yuan, Qiming, Pinto, Henrique Ponde de Oliveira, Kaplan, Jared, Edwards, Harri, Burda, Yuri +50 more·2021·arXiv

Abstract

We introduce Codex, a GPT language model fine-tuned on publicly available code from GitHub, and study its Python code-writing capabilities. A distinct production version of Codex powers GitHub Copilot. On HumanEval, a new evaluation set we release to measure functional correctness for synthesizing programs from docstrings, our model solves 28.8% of the problems, while GPT-3 solves 0% and GPT-J solves 11.4%. Furthermore, we find that repeated sampling from the model is a surprisingly effective strategy for producing working solutions to difficult prompts. Using this method, we solve 70.2% of our problems with 100 samples per problem. Careful investigation of our model reveals its limitations, including difficulty with docstrings describing long chains of operations and with binding operations to variables. Finally, we discuss the potential broader impacts of deploying powerful code generation technologies, covering safety, security, and economics.

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Integrity signals

Registry

DataCite · 10.48550/arxiv.2107.03374

Cites

90 of 90 references verified0 citation errors · 0 not checkable

Statistics

Claims the paper makes

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

  • OpenAI's Codex model contains 12 billion parameters, is trained on 54 million GitHub repositories, and can correctly solve 30-70% of novel Python problems.

    “OpenAI's Codex model [Chen et al. 2021], which contains 12 billion model parameters and is trained on 54 million software repositories on GitHub, is able to correctly solve 30-70% of novel Python problems”

    From Grounded Copilot: How Programmers Interact with Code-Generating Models (2023) · cites this paper as [Chen et al. 2021]

    Section 3.1 (p. 4) says the training data came from 54 million public GitHub repositories, and Section 3 (p. 4) describes Codex models with up to 12 billion parameters. The Abstract (p. 1) reports 28.8% of HumanEval problems solved with one sample and 70.2% with 100 samples per problem. The claimed 30–70% range is approximately right, but it omits that the upper end required repeated sampling and evaluation on a specific problem set. (LLM, conf=0.86)

    Experimental — accuracy not yet measured
  • Codex was initially tested on the HumanEval dataset containing 164 programming problems, where it is asked to write the function body from a docstring, and achieves 37.7% accuracy with a single generation.

    “Codex was initially tested on the HumanEval dataset containing 164 programming problems, where it is asked to write the function body from a docstring [8] and achieves 37.7% accuracy with a single generation.”

    From Reading Between the Lines: Modeling User Behavior and Costs in AI-Assisted Programming (2024) · cites this paper as [8]

    The Codex and Codex-S Performance section (p. 2) describes HumanEval as 164 programming problems used to evaluate Python function generation from docstrings. But it reports 37.7% with a single sample for Codex-S, a further fine-tuned model; Codex solves 28.8%. (LLM, conf=0.92)

    Experimental — accuracy not yet measured
  • Offline evaluation of code completion is difficult for longer completions because there are many acceptable alternatives and no straightforward automatic labeling mechanism.

    “Offline evaluation where the system is shown a partial snippet of code and then asked to complete it is difficult not least because for longer completions there are many acceptable alternatives and no straightforward mechanism for labeling them automatically [5].”

    From Productivity Assessment of Neural Code Completion (2022) · cites this paper as [5]

    Section 2.1 (p. 2) says that match-based metrics cannot account for the large space of functionally equivalent programs, supporting the point that many completions may be acceptable. It does not specifically address longer completions of partial code snippets or say that automatic labeling lacks a straightforward mechanism; instead, it describes unit tests as a way to assess functional correctness. (LLM, conf=0.85)

    Experimental — accuracy not yet measured
  • Existing works have used the Computational Accuracy metric to evaluate generative code models, but not other metrics regarding characteristics of generated artifacts and run-time efficiency.

    “For example, for the Performance category, existing works have used the Computational Accuracy metric to evaluate generative code models [9,15,33,88], but not other metrics we uncovered regarding the characteristics of the generated artifacts and run-time efficiency.”

    From Investigating Explainability of Generative AI for Code through Scenario-based Design (2022) · cites this paper as [15]

    Section 2.1 (p. 2) supports the use of functional correctness—judging generated code by whether it passes unit tests—which corresponds to the claimed Computational Accuracy metric. It does not establish that existing works omitted other metrics for generated artifacts or run-time efficiency; Appendix D (p. 25) instead notes prior recommendations to assess code-output complexity. (LLM, conf=0.84)

    Experimental — accuracy not yet measured
  • Similar studies in the code space are limited to the number of few-shot examples in the prompt, and the effect of length of prompt on performance.

    “Similar studies in the code space are limited to the number of few-shot examples in the prompt, and the effect of length of prompt on performance [9,15].”

    From Investigating Explainability of Generative AI for Code through Scenario-based Design (2022) · cites this paper as [15]

    The APPS results (section 3.5, p. 7) evaluate a one-shot prompt, and the Limitations section (p. 10) reports declining performance as synthetic docstrings grow longer. Our copy does not show an investigation of how varying the number of few-shot examples affects performance, nor establish that similar code studies are limited to these two topics. (LLM, conf=0.82)

    Experimental — accuracy not yet measured

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

The self-check needs the paper’s full text.

Cites

Flagged first, then by citations

6 of the 96 references couldn’t be matched to a known paper.

Research works printed but not linked: 11

  1. Aye, G. A., Kim, S., and Li, H. Learning autocompletion from realworld datasets. 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) , pp. 131-139, 2021.
  2. Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., Neelakantan, A., Shyam, P., Sastry, G., Askell, A., Agarwal, S., Herbert-Voss, A., Krueger, G., Henighan, T., Child, R., Ramesh, A., Ziegler, D. M., Wu, J., Winter, C., Hesse, C., Chen, M., Sigler, E., Litwin, M., Gray, S., Chess, B., Clark, J., Berner, C., McCandlish, S., Radford, A., Sutskever, I., and Amodei, D. Language models are few-shot learners. ArXiv , abs/2005.14165, 2020. · arXiv
  3. Carlini, N., Tram` er, F., Wallace, E., Jagielski, M., Herbert-V oss, A., Lee, K., Roberts, A., Brown, T., Song, D., Erlingsson, U., Oprea, A., and Raffel, C. Extracting training data from large language models. In 30th USENIX Security Symposium (USENIX Security 21) . USENIX Association, August 2021. URL https://www . usenix . org/conference/ usenixsecurity21/presentation/carliniextracting . https://www.usenix.org/conference/usenixsecurity21/presentation/carlini-extracting
  4. Crawford, K. The trouble with bias. NIPS 2017 Keynote , 2017. URL https://www . youtube . com/watch?v= fMym BKWQzk .
  5. Devlin, J., Uesato, J., Bhupatiraju, S., Singh, R., rahman Mohamed, A., and Kohli, P. Robustfill: Neural program learning under noisy i/o. In ICML , 2017.
  6. Eghbal, N. Working in public: the making and maintenance of open source software . Stripe Press, 2020.
  7. Goues, C. L., Dewey-Vogt, M., Forrest, S., and Weimer, W. A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each. 2012 34th International Conference on Software Engineering (ICSE) , pp. 3-13, 2012.
  8. Graves, A., Wayne, G., and Danihelka, I. Neural turing machines. arXiv preprint arXiv:1410.5401 , 2014. · arXiv
  9. Raffel, C., Shazeer, N. M., Roberts, A., Lee, K., Narang, S., Matena, M., Zhou, Y., Li, W., and Liu, P. J. Exploring the limits of transfer learning with a unified text-to-text transformer. ArXiv , abs/1910.10683, 2020. · arXiv
  10. Rokon, M. O. F., Islam, R., Darki, A., Papalexakis, E. E., and Faloutsos, M. Sourcefinder: Finding malware source-code from publicly available repositories in github. In 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020) , pp. 149-163, San Sebastian, October 2020. USENIX Association. ISBN 978-1-93913318-2. URL https://www . usenix . org/conference/ raid2020/presentation/omar .
  11. Yin, P. and Neubig, G. A syntactic neural model for generalpurpose code generation. In Proceedings of the 55th Annual Meeting of the Association for Computational Linguistics (ACL) , pp. 440-450, 2017.

Cited by

Sorted by citations

Authors
Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. D. O., Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., Ray, A., Puri, R., Krueger, G., Petrov, M., Khlaaf, H., Sastry, G., Mishkin, P., Chan, B., Gray, S., Ryder, N., Pavlov, M., Power, A., Kaiser, L., Bavarian, M., Winter, C., Tillet, P., Such, F. P., Cummings, D., Plappert, M., Chantzis, F., Barnes, E., Herbert-Voss, A., Guss, W. H., Nichol, A., Paino, A., Tezak, N., Tang, J., Babuschkin, I., Balaji, S., Jain, S., Saunders, W., Hesse, C., Carr, A. N., Leike, J., Achiam, J., Misra, V., Morikawa, E., Radford, A., Knight, M., Brundage, M., Murati, M., Mayer, K., Welinder, P., McGrew, B., Amodei, D., McCandlish, S., Sutskever, I., & Zaremba, W.
Affiliations
  • OpenAI (United States) (US)
  • Anthropic (United States) (US)
  • Zipline International (United States) (US)
Venue
arXiv
Publisher
arXiv
Published
2021
ISSN
2331-8422 (ISSN-L)
OpenAlex
W3177813494
Cited by
1,436
References
96
Citations by year
2026: 121 · 2025: 261 · 2024: 376 · 2023: 551 · 2022: 93 · 2021: 34
Type
posted content
Language
en
Open access
Locations
  • arXiv (Cornell University) (submittedVersion)
  • arXiv (Cornell University)
Funders
  • National Natural Science Foundation of China (62472339, 62302375)
  • China Postdoctoral Science Foundation (2023M723736)
  • Ministry of Industry and Information Technology of the People's Republic of China
Topics
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Research
  • Physical Sciences › Computer Science › Artificial Intelligence › Natural Language Processing Techniques
  • Physical Sciences › Computer Science › Artificial Intelligence › Logic, programming, and type systems
Keywords
large language models, code generation, LLVM intermediate representation, AI-generated code, AWS Lambda, performance comparison, memory usage, CPU utilization, garbage collection overhead

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review