|
|
|
We can load HumanEval dataset and pass@k metric from 🤗 [`datasets`](https://huggingface.co/docs/datasets/index) and 🤗 [`evaluate`](https://huggingface.co/docs/evaluate/index) |
|
|
|
```python |
|
from datasets import load_dataset |
|
from evaluate import load |
|
|
|
human_eval = load_dataset("openai_humaneval") |
|
code_eval_metric = load("code_eval") |
|
``` |
|
|
|
We can easily compute the pass@k for a problem that asks for the implementation of a function that sums two integers: |
|
|
|
```python |
|
test_cases = ["assert add(2,3)==5"] |
|
candidates = [["def add(a,b): return a*b", "def add(a, b): return a+b"]] |
|
pass_at_k, results = code_eval_metric.compute(references=test_cases, predictions=candidates, k=[1, 2]) |
|
print(pass_at_k) |
|
{'pass@1': 0.5, 'pass@2': 1.0} |
|
``` |
|
|
|
To better understand how pass@k metric works, we will illustrate it with some concrete examples. We select two problems from the HumanEval dataset and see how CodeParrot 🦜 (110M) performs and which code completions pass the unit tests of the two problems below: |
|
|
|
**Problem 1:** |
|
|
|
```python |
|
|
|
from typing import List |
|
|
|
|
|
def separate_paren_groups(paren_string: str) -> List[str]: |
|
""" Input to this function is a string containing multiple groups of nested parentheses. Your goal is to |
|
separate those group into separate strings and return the list of those. |
|
Separate groups are balanced (each open brace is properly closed) and not nested within each other |
|
Ignore any spaces in the input string. |
|
>>> separate_paren_groups('( ) (( )) (( )( ))') |
|
['()', '(())', '(()())'] |
|
""" |
|
```` |
|
**Problem 2:** |
|
```python |
|
|
|
def truncate_number(number: float) -> float: |
|
""" Given a positive floating point number, it can be decomposed into |
|
and integer part (largest integer smaller than given number) and decimals |
|
(leftover part always smaller than 1). |
|
|
|
Return the decimal part of the number. |
|
>>> truncate_number(3.5) |
|
0.5 |
|
""" |
|
```` |
|
|
|
For each problem, instead of 200 candidate solutions, we will only generate 20 samples for illustration purposes. We use nucleus sampling with top-p where `p=0.95`, `temperature=0.2`, and sample tokens from the model until we encounter a stop sequence indicating the end of a method: ‘\nclass’, ‘\ndef’, ‘\n#’, ‘\nif’, or ‘\nprint’. For more details about decoding strategies for language generation, we recommend this [blog](https://huggingface.co/blog/how-to-generate). |
|
|
|
**Remark**: |
|
|
|
Regarding the temperature parameter, in [CodeGen](https://github.com/salesforce/CodeGen) paper, the authors observed that the best performing temperature increases as the number of samples permitted k increases. When a model is only allowed a few samples to pass unit tests, it is beneficial to use the learned distribution, through a low temperature, to select candidates that are likely to pass. But when a model is allowed for more chances with a high k, using a higher sampling temperature to tilt the learned model distribution lets it explore diverse samples and thus have a greater chance of synthesizing a correct program. |
|
|
|
|
|
For our experiment, we compute pass@1, pass@10 and pass@20, each correspending to unit test pass rate when selecting respectively 1, 10 and 20 samples from the candidate solutions. |
|
|
|
``` |
|
|
|
Results: {'pass@1': 0.0750, 'pass@10': 0.4473, 'pass@20': 0.5} |
|
|
|
```` |
|
|
|
If we take a closer look at the unit test results for each candidate solution in the two problems, we find that 3 passed the test for the second problem, and none did for the first problem. This means that we have 3 correct solutions among 40, which corresponds to our pass@1 value `3/40 = 0.075`. The scores pass@10 and pass@20 are higher, because the more samples we select from the candidate completions, the more likely we are to include the correct implementation. As |
|
for pass@20, it is `1/2 = 0.5`, since if we select all 20 candidates for each problem, the second problem get solved which gives 50% success rate. If you are curious about the candidate solutions that passed the tests, they all implemented this function: |
|
|
|
```python |
|
|
|
def truncate_number(number: float) -> float: |
|
""" Given a positive floating point number, it can be decomposed into |
|
and integer part (largest integer smaller than given number) and decimals |
|
(leftover part always smaller than 1). |
|
|
|
Return the decimal part of the number. |
|
>>> truncate_number(3.5) |
|
0.5 |
|
""" |
|
return number % 1 |
|
``` |