Uncovering and Quantifying Social Biases in Code Generation

With the popularity of automatic code generation tools, such as Copilot, the study of the potential hazards of these tools is gaining importance. In this work, we explore the social bias problem in pre-trained code generation models. We propose a new paradigm to construct code prompts and successfully uncover social biases in code generation models. To quantify the severity of social biases in generated code, we develop a dataset along with three metrics to evaluate the overall social bias and fine-grained unfairness across different demographics. Experimental results on three pre-trained code generation models (Codex, InCoder, and CodeGen) with varying sizes, reveal severe social biases. Moreover, we conduct analysis to provide useful insights for further choice of code generation models with low social bias. (This work contains examples that potentially implicate stereotypes, associations, and other harms that could be offensive to individuals in certain social groups.)

Paper

References (68)

Scroll for more · 38 remaining

Similar papers

Peer review

Reviewer y9do6/10 · confidence 3/52023-06-23

Summary

This paper investigates the problem of social biases in the code generation procedure. This is the first paper to study the social bias issue in the code-generating model and demonstrate the existence of social biases. The author also introduces some evaluation metrics to quantify the bias in code as well as a classifier for scoring. They also conduct many experiments and ablation studies to provide more insight into this direction. In addition, they also validate their result and method by human annotation.

Strengths

This paper is the first paper to study social bias in code generation model. The result are also interesting that since the training datasets are often human-irrelevant but it still shows that the model will contains biases. It opens up new avenues for research and discussion about the nature of bias and how it can be subtly embedded in models. Also the human labeled prompt and dataset will be a great value for future research It conduct pretty solid experiments on various models and also conduct human annotation to further evaluate the results.

Weaknesses

The authors of this paper have taken a novel approach to uncovering biases in code generation models by constructing biased prompts. While this methodology is sound, the results are somewhat predictable. Given a biased prompt, it is likely that a code generation model will produce biased output. However, this is more a reflection of the input rather than an inherent bias within the model. For instance, a model generating 'find_good_people == 'Hispanic'' is logically equivalent to generating 'find_delicious_apple = red', but we wouldn't label the latter as biased. The model is not able to realize this unless it is trained to recognize certain attributes or words as sensitive. The study primarily focuses on 'direct bias', where the model is intentionally prompted to generate biased code. In real-world applications, it's unlikely that developers would intentionally craft such biased prompts unless they specifically aim to generate biased code. My main concern lies with 'unintentional bias', where biases are generated even when the prompt has no apparent bias. This is a more pressing issue in real-world scenarios. Furthermore, it's worth considering that code may appear unbiased at the point of generation, but could introduce bias when applied in certain contexts. This is a complex issue that warrants further investigation. Another weakness of the paper lies in its oversimplification of certain aspects in its analysis and evaluation. For instance, when considering ethnicity in UFS, the study only takes into account 'white' and 'black', neglecting the complexity and diversity of ethnic groups. This simplification could potentially limit the comprehensiveness and applicability of the study's findings. I do appreciate that this study represents an initial step towards addressing the question of bias in code generation models. However, future research should aim to delve deeper into the nuances of unintentional and context-dependent biases to provide a more comprehensive understanding of this issue.

Questions

1. In line 135, you mentioned you have 5 types of modifiers and 8 types of demographic dimensions, how did you come up with the prompt dataset with 392 samples? 2. In Table 3, why you don't include the statistics of Codex? 3. It seems like in line UFS can only applied to binary demographics, is it possible to expand this so that it can be used in ethnicity where there are more than two category?

Rating

6: Weak Accept: Technically solid, moderate-to-high impact paper, with no major concerns with respect to evaluation, resources, reproducibility, ethical considerations.

Confidence

3: You are fairly confident in your assessment. It is possible that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work. Math/other details were not carefully checked.

Soundness

3 good

Presentation

3 good

Contribution

3 good

Limitations

In the related work part, might need to include more papers that study social bias in NLP and the evaluation methods and benchmarks.

Reviewer 9vM75/10 · confidence 4/52023-06-25

Summary

This paper presents among the first study on social biases in code generation models. The authors present a method to construct bias probes. Specifically, the authors develop a template that consists of two irrelevant (to the topic of this study) functions at beginning, then a function signature with demographics info to probe the bias of code generation models. The authors perform human annotations on the resulting data, and train a bias classifier on top of the annotated data. The authors further define metrics for quantifying bias. Armed with the classifier and evaluation metrics, the authors quantify the amount of bias each code generation model has at different sizes, and share useful findings and analysis on e.g. demographics and hyperparameters.

Strengths

- This is among the first systematic work of social biases in code generation. - The authors propose a full-stack study from prompt construction, dataset, evaluation metrics, to the quantitative and qualitative analysis, setting a foundation of social bias research in code generation. - The annotated dataset can be useful for future research.

Weaknesses

- The binary classes in demographics (Table 1) are questionable. What would be the purpose to limit each demographic to have two classes only? - Related, the UnFairness Score is for binary class only, however, most demographics are not binary. It is questionable how the binary design of UFS can be useful in quantifying biases for multi-class demographics. I would recommend the authors think about how to extend the definition of UFS to match its practical use. - Despite being able to elicit biases, the dataset is very artificial and out-of-distribution (three functions with the last one being a bias prober). Such prompt used is likely to never appear in the training dataset, and the findings drawn from the study on only this dataset may be inconclusive given OOD is clearly a confounder. It also doesn't address the question of how such biases appear in realistic code generation/completion scenarios?

Questions

- Can authors clarify how the first two functions were obtained and how the diversity looks like? - Can authors share the dataset anonymously given it is one of the major contributions? - What does it mean by "Note that the order of the two demographics in each row matters."(Table 1 caption)? - Figure 6: what does it mean by "valid demographics"? There are way more "valid demographics" than what is present in the Figure. - "Effects of Hyper-Parameters" the study is on CodeGen-6B only. Would it generalize to other models? - How was the annotation quality accessed?

Rating

5: Borderline accept: Technically solid paper where reasons to accept outweigh reasons to reject, e.g., limited evaluation. Please use sparingly.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

2 fair

Presentation

3 good

Contribution

2 fair

Limitations

The authors didn't explicitly discuss the limitation. I would like to see more discussions on limitation especially on 1) the dataset, 2) the selection of demographics, and 3) the practicality of this work in realistic scenarios.

Reviewer AcqK5/10 · confidence 4/52023-07-03

Summary

With AI applications becoming increasingly common, ensuring AI fairness is important. While previous research has found biases in language models, this article focuses on investigating whether code generation models also exhibit social biases. The article proposes a new method to construct prompts containing demographic information to elicit social biases from code generation models. The article develops metrics and a dataset to quantify social biases in the generated code. A code classifier is also trained to automatically gauge social biases. Experiments show that the tested models generate code with severe social biases.

Strengths

1. The study covers a timely and important topic aiming to raise awareness of social bias in code generation applications to mitigate potential harm to vulnerable groups. 2. The authors conduct comprehensive experiments where the results demonstrate that severe social biases exist in code generation models. 3. The study yields interesting observations, for example, larger pre-trained code generation models with more parameters exhibit more social biases despite better performance compared to smaller models.

Weaknesses

1. It is unclear how applicable the proposed method is to real-world applications where code generation models are rarely used for human-related tasks. 2. The authors show that larger LLMs tend to be more biased than smaller ones. This is contradictory with findings in the literature, where smaller models tend to be more likely to capture bias in the training set. It would be great if the authors could provide more insights in terms of this phenomenon.

Questions

1. Could the authors give some realistic examples that code generation models have unfairness problem, rather than using synthetic examples? 2. Could the authors explain why larger LLMs tend to be more biased?

Rating

5: Borderline accept: Technically solid paper where reasons to accept outweigh reasons to reject, e.g., limited evaluation. Please use sparingly.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

2 fair

Presentation

3 good

Contribution

2 fair

Limitations

Yes, the authors adequately addressed the limitations.

Reviewer 6YHH4/10 · confidence 4/52023-07-07

Summary

This work explores the social bias problem in pre-trained code generation models. The authors started with the motivation that code generation datasets are usually irrelevant to humans and social bias issues are easily ignored. They propose a dataset and the corresponding evaluation metrics and try to propose a classifier that is close to human evaluation. The work also conducts experiments on the effect of hyperparameters of LLM on generating biased results.

Strengths

This work is the first to expose the problem of social bias in code generation models.

Weaknesses

1. The work is imperfect in quantifying the existence of social bias in code generation. For example, the development of prompt engineering is straightforward. Experiments with large model hyperparameters are also inadequate. 2. Codex is based on GPT-3, which is currently offline. Codex is most likely not effectively using RLHF to correct values. I believe RLHF is important to address the issue of social bias, and I suggest that the work add experiments on gpt-3.5 and gpt-4.

Questions

I suggest that the work add experiments on gpt-3.5 and gpt-4.

Rating

4: Borderline reject: Technically solid paper where reasons to reject, e.g., limited evaluation, outweigh reasons to accept, e.g., good evaluation. Please use sparingly.

Confidence

4: You are confident in your assessment, but not absolutely certain. It is unlikely, but not impossible, that you did not understand some parts of the submission or that you are unfamiliar with some pieces of related work.

Soundness

2 fair

Presentation

2 fair

Contribution

2 fair

Limitations

It is suggested that the authors add a discussion of the limitations of this work.

Reviewer y9do2023-08-10

Thank you for the detailed response. I don't have further questions and will keep my score. Again, it will be beneficial to release the datasets, code, and models for future research once the paper is published.

Reviewer 9vM72023-08-13

Thanks for the response from the authors. I don't have further questions and will keep my score. Two final call-outs: 1. re dataset: given the dataset is a major contribution of the work, it's important that the reviewers can have access to it to assess its quality. Please consider including it in the submission for work like this in future venues. 2. re annotators: "Our annotators are well-educated postgraduates majoring in computer science who are over-qualified to distinguish biased code." Please note that it's not always the case that "well-educated postgraduates majoring in computer science" warrents or over-qualifies to "distinguish biased code", especially when the bias is subtle.

Authorsrebuttal2023-08-16

Response to Reviewer 9vM7

Thank you a lot for your efforts and valuable comments! 1. We highly appreciate your suggestion and will add the dataset as supplementary material for other work like this in future venues. 2. We are sorry for the inappropriate statement here and thank you for pointing this out.

Reviewer 6YHH2023-08-19

Thanks for the response from the authors. In relation to Q1, I am concerned that the experimental design wasn't as rigorous and comprehensive as it should be. As for Q2, I'd like clarification on whether the RLHF effect on language model training was considered. The OpenAI help documentation for CodeX mentions it's built upon GPT-3. It's crucial to ascertain if RLHF was utilized. The authors' recent submission showcasing results for GPT-4 seems to suggest that RLHF is useful. These results appear to challenge the authors' earlier observation that larger pre-trained code generation models with more parameters tend to learn more social biases.

Authorsrebuttal2023-08-19

Response to Reviewer 6YHH

**Q1: I am concerned that the experimental design wasn't as rigorous and comprehensive as it should be.** **A**: The other three reviewers have all recognized the experiments conducted in our paper. - "*comprehensive experiments*", "*interesting observations*" (Reviewer AcqK) - "*systematic work*", "*full-stack study from prompt construction, dataset, evaluation metrics, to the quantitative and qualitative analysis*" (Reviewer 9vM7) - "*conduct pretty solid experiments on various models and also conduct human annotation to further evaluate the results*." (Reviewer y9do). We acknowledge that as the first paper to study social bias in code generation models, our work is not perfect in all aspects and there is still room for improvement. However, we think this could be addressed in future work. **Q2.1: I'd like clarification on whether the RLHF effect on language model training was considered. The OpenAI help documentation for CodeX mentions it's built upon GPT-3. It's crucial to ascertain if RLHF was utilized.** **A**: As written in our paper (footnote in Line 185), we use the latest API (code-davinci-002) of Codex to run our experiments. We suggest the reviewer check the code-davinci-002 API, which is GPT-3.5, not GPT-3. Since including links is not allowed during the rebuttal phase, we also suggest that the reviewer search for the following blog: "How does GPT Obtain its Ability? Tracing Emergent Abilities of Language Models to their Sources". This blog also mentions that code-davinci-002 is GPT-3.5. Regarding the effect of RLHF, we think that the reviewer has some misunderstandings about our paper. The primary contribution of our paper is to **uncover and quantify social biases in code generation models**, rather than analyzing various factors such as RLHF's impact on social bias. We acknowledge the importance of the research direction highlighted by the reviewer but believe that it is not within the research scope of this paper. **Q2.2: The authors' recent submission showcasing results for GPT-4 seems to suggest that RLHF is useful.** **A**: Compared to GPT-3.5, there are many improvements in GPT-4, e.g., an improvement in the quality and quantity of training data, an increase in RLHF rounds, a change in alignment objectives, the use of multimodal data, and the use of MOE, etc. It's difficult to determine which factor amplifies bias and which one mitigates it. Hence, it is premature to say "RLHF is useful" without further investigation. **Q2.3: These results appear to challenge the authors' earlier observation that larger pre-trained code generation models with more parameters tend to learn more social biases.** **A**: We would like to clarify that this is NOT in conflict with our observations in Table 4. By saying "larger pre-trained code generation models with more parameters tend to learn more social biases in spite of better performance", we intend to convey that, **with the same model type but different sizes** (they share the same underlying architecture but with different numbers of parameters), the larger one might learn more social biases, rather than making a comparison across different types of models. For example, as shown in our experiments, CBS(**CodeGen** 6.1B) > CBS(**CodeGen** 2.7B), but CBS(**CodeGen** 2.7B) > CBS(**InCoder** 6.7B), where the larger CodeGen is more biased than the smaller CodeGen, but the smaller CodeGen shows more social biases than the larger InCoder. Different types of models (such as CodeGen and InCoder) often utilize different training data and strategies, making direct comparisons difficult. We will make the statement clearer in the revised paper to avoid misunderstanding.   Thank you for your review. Your questions and feedback have provided us with an opportunity to improve our paper and explore further in this research direction. If you have any further questions or suggestions, we would be more than willing to continue the in-depth discussion.

Reviewer 6YHH2023-08-21

Thanks to the authors for the additional responses. For the effectiveness of the experiment, I will also consider the opinions of other reviewers. I reconfirmed that both the OpenAI help documentation and the official page description see that CodeX including code-davinci-002 is based on GPT-3. I also searched the blog mentioned by the author and categorized code-davinci-002 as a variant of GPT-3.5. I want to clarify that I am not needing to confirm the exact version number. And I suggest adding GPT-4 as a Baseline. I just wanted to suggest that with LLM technical updates like the introduction of RLHF in training, there will be an impact on the social bias phenomenon in it. I understand that the work does not attempt to address the social biases present in Code LLM, but I still believe that the additional consideration of alignment techniques is necessary to study Code LLM social biases. > “As we can see, larger pre-trained code generation models with more parameters tend to learn more social biases in spite of better performance, compared with smaller ones.” I and Reviewer AcqK noticed this sentence at the same time, and Reviewer AcqK was put on Strenths. I do think some modification is necessary.

Authorsrebuttal2023-08-21

Response to Reviewer 6YHH

1. In our first rebuttal, we followed your advice and conducted experiments with GPT-4, which will also be included in the revised paper. 2. Regarding RLHF, as we mentioned in our previous response (Q2.2), GPT-4 has incorporated many improvements compared to GPT 3.5/GPT-3, beyond just RLHF. Therefore, the comparison between GPT-4 and GPT-3.5/GPT-3 cannot elucidate the specific impact of RLHF. To thoroughly study the impact of RLHF, it's necessary to carefully select comparative models. For example, choosing a model that incorporates RLHF in addition to a baseline (only with this single improvement), and observing how social bias changes. However, to the best of our knowledge, there are no publicly available models that can support such a comparison for now. We agree that LLM technical updates have some impacts on the social bias phenomenon. But we think this exceeds the scope of our current study (**the first to uncover and quantity social biases in code generation**), and we believe it could be pursued as a separate, independent research effort. 3. As for the statement, "*As we can see, larger pre-trained code generation models with more parameters tend to learn more social biases in spite of better performance, compared with smaller ones*", we mentioned in our previous response (Q2.3) that we will make the statement clearer in the revised paper to avoid misunderstanding. For example, "*When comparing models with the same model type but varying sizes (e.g., CodeGen 6.1B v.s. CodeGen 2.7B), we observe a trend that larger pre-trained code generation models with more parameters learn more social biases in spite of better performance, compared with smaller ones*."   We thank the reviewer for providing constructive comments and valuable feedback. Since the "Author-Reviewer discussion phase" is coming to an end, if there are no further questions, we sincerely hope you find our rebuttal useful in adjusting the final review ratings. Thank you!

Program Chairsdecision2023-09-21

Decision

Accept (poster)

© 2026 NYSGPT2525 LLC