Self-Explained Keywords Empower Large Language Models for Code Generation

## Abstract

Abstract Large language models (LLMs) have achieved impressive performance in code generation.
However, due to the long-tail distribution of LLMs’ training data, low-frequency terms are typically underrepresented in the training process. Consequently, LLMs often misunderstand or overlook problem-specific, low-frequency keywords during code generation, compromising the accuracy of the generated code.
To address this, we propose a novel technique named SEK ( S elf- E xplained K eywords), which empowers an LLM for better code generation by extracting and explaining the key terms in the problem description with the LLM itself and ranking them based on frequency.
Comprehensive experiments across three benchmarks, i.e., HumanEval(+), MBPP(+), and APPS, with five representative LLMs, show that SEK can significantly improve LLMs in code generation, yielding substantial and consistent gains. For instance, SEK improves the Pass@1 of DeepSeek-Coder-V2-Instruct from 85.4% to 93.3% on the Humaneval benchmark. Further analysis confirms that SEK enables the LLMs to shift their attention from low-frequency keywords to their corresponding high-frequency counterparts.

## 1 Introduction

Code generation aims to generate a code snippet that meets the intent described in natural language. This process can potentially reduce the costs of software development (Xu et al., ; Yin & Neubig, ; Vaithilingam et al., ).
Recently, the notable success of LLMs such as ChatGPT (OpenAI, ) and Llama-3 (AI@Meta, ) has substantially enhanced the state-of-the-art in code generation. These LLMs demonstrate remarkable proficiency in comprehending natural language descriptions and translating them into code snippets.

Despite the remarkable success, their training data suffer from the long-tail distribution problem (Chen et al., ; Li et al., ), which results in insufficient training of the correspondence between some low-frequency terms and their respective code implementations. Consequently, when performing real-world coding tasks, LLMs often struggle to translate certain low-frequency keywords into appropriate code implementations accurately, and may even overlook such keywords, potentially compromising the accuracy of the generated code.

As illustrated in Figure 2, the coding problem requires returning even digits within a given range in ascending order. The term even digits rarely appears in code datasets, causing LLMs to misinterpret it as even numbers. As a result, LLMs fail to recognize that it refers to the even numbers within the range of 0 to 9. However, if we explicitly explain even digits using common, high-frequency terms and prompt the LLM to focus on it, the LLM can successfully produce a correct implementation.

Figure: Figure 1: Motivating example.
Refer to caption: x1.png

However, converting low-frequency keywords into high-frequency natural language descriptions requires additional human effort for identification and explanation. Our key idea is that although the direct mapping from low-frequency terms to code is rare in code corpora, the semantics of these terms are typically understandable by LLMs after pre-training on large-scale general corpora. Moreover, previous works find that such problem-specific key items can be identified by LLMs (Fang et al., ; Fan et al., ). Based on this, this work proposes Self-Explained Keyword (SEK), a novel technique leveraging LLMs’ own comprehension capabilities to automatically identify and explain low-frequency, problem-specific terms to enhance their understanding of coding problems.

A major challenge in implementing SEK is how to effectively identify and explain keywords that LLMs might overlook in problem descriptions. To address this, SEK employs a carefully designed prompt with a few examples, directing LLMs to focus on crucial keywords in the problem description. After extracting the keyword set, the next challenge is how to enhance the original problem prompt. Since keywords with lower frequency are more likely to be misunderstood or overlooked by LLMs, we use a frequency-based ranking algorithm to sort these keywords, which are then appended to the original problem description to construct an augmented prompt. Overall, this approach aligns with the working process of pragmatic human developers, which use auxiliary tools like blackboards to highlight, explain, and rank important parts of requirements (Hunt & Thomas., ).

By overcoming these challenges, SEK enhances LLMs’ problem-solving capabilities in a novel way, distinguishing itself from previous methods in prompt engineering for code generation. As shown in Figure 2, unlike previous approaches that often rely on introducing external knowledge, such as human feedback (Chen et al., ; Wu et al., ; Dubois et al., ) or the execution results of LLM-generated solutions (Zhong et al., ; Chen et al., ; Zhong et al., ), into the input, SEK operates by distilling additional content from the problem description using the LLM itself.
Chain of Thought (CoT) (Wei et al., ), which also utilizes LLMs’ inherent knowledge for problem-solving, bears the closest resemblance to SEK. However, the fundamental strategies of CoT and SEK are different: CoT guides the LLM to think in a chain-like manner, while SEK directs the LLM to understand and prioritize key concepts.

We evaluate SEK with five representative LLMs, including three open-source models and two closed-source models, on three widely used code generation benchmarks. Experimental results demonstrate that SEK effectively enhances code generation performance. For example, SEK enables Llama-3.1 to achieve a relative improvement of 8.8% averaged on the used benchmarks.
Notably, DeepSeek-Coder-V2-Instruct with SEK significantly outperforms it with standard prompting, achieving state-of-the-art performance on several benchmarks (e.g., HumanEval: 85.4% to 93.3%). Furthermore, our ablation studies indicate that the carefully designed prompt and the ranking component of SEK are effective.
Additionally, our attention analysis reveals that SEK helps LLMs comprehend low-frequency keywords by redirecting attention to their high-frequency counterparts. Comparative case studies with other baselines further illustrate SEK’s efficacy in enhancing LLMs’ understanding of low-frequency, problem-specific keywords.
Our code is in the Supplementary Materials and will be made public after review.

## 2 Methodology

Code generation aims to generate a solution program based on a problem description.
Typically, a problem description includes implementation requirements, and several test cases to help further understand the problem.

Figure 3 illustrates the overview of SEK. SEK is designed to address the issue of LLMs overlooking low-frequency terms in the program description due to the long-tail distribution in their training data. To address it, one key is to leverage the LLM’s capabilities to identify and explain potentially overlooked keywords within the problem description. We employ a carefully crafted prompt with a few-shot learning method to achieve this.
After obtaining the keywords and their explanations, another challenge is how to effectively integrate them with the original problem description. For this purpose, we introduce a frequency-based ranking algorithm that prioritizes less frequent tokens, which are more likely to be overlooked by the LLM. These ranked keywords are then appended to the original problem description, serving to guide the LLM towards generating an accurate solution.
The process comprises three main steps:

KeyExtract & Explain (Section 2.1): Based on the problem description, SEK constructs a prompt to guide the LLM to identify and explain keywords within the problem description.

KeyRank (Section 2.2): SEK employs a frequency-based ranking algorithm to prioritize the extracted keywords.

PromptEnrich (Section 2.3), SEK concatenates the ranked keywords and their explanations with the original problem description to create an enriched problem description. This comprehensive formulation serves as the final input for the LLM to generate code solutions.

Figure: Figure 3: The overview of Self-Explained Keyword. The details in each step are omitted.
Refer to caption: x3.png

### 2.1 KeyExtract & Explain

In this step, SEK extracts and explains keywords from the given problem description. Our key insight is that LLMs inherently possess strong understanding and reasoning abilities after training on large-scale general corpora, enabling them to explain crucial concepts within a problem description. The effectiveness of using LLMs for keyword extraction has also been demonstrated by recent studies (Maragheh et al., ; Lee et al., ).
Inspired by this insight, SEK uses the LLM itself to perform the task with a prompt-based approach.

Specifically, SEK begins by designing a prompt to instruct an LLM for keyword extraction and explanation. The prompt is shown in Prompt for KeyExtract & Explain in Figure 3, which consists of three parts. First, it provides the overall instruction for the task, namely the generation of keywords and their corresponding explanations. Then, it specifies the format of input and output. Finally, it provides detailed guidelines. Intuitively, terms associated with input, output, and supplementary content (i.e., clarifications of keywords or specifications of value ranges) within the problem description are relatively important, as they contain the problem’s core elements, objectives, and constraints (Guideline 1). For explanations, given the potential ambiguity in natural language expressions and the clarity of the public test cases, the generated explanations should be both precise and consistent with these test cases (Guideline 2,3).
We also impose limitations on the keyword quantity to guarantee that the LLM identifies and outputs only the important keywords in the problem description (Guideline 4). Ultimately, to facilitate subsequent processing, we further emphasize the output format (Guideline 5).
Additionally, we use several examples to leverage LLMs’ in-context learning ability for understanding and solving this task.

### 2.2 KeyRank

After extracting and explaining the keywords, the next goal is to enhance the original prompt. Previous research has demonstrated that LLMs are sensitive to the order of tokens in the prompt, known as position bias (Li et al., ; Yu et al., ). It highlights the need to carefully arrange the extracted keywords. Notably, pragmatic human developers tend to place more important keywords at the beginning in practice (Hunt & Thomas., ). This preference may be reflected in the training dataset, leading LLMs to also focus more on the keywords written at the front. Therefore, we propose a set of heuristic rules to rank keywords by importance, namely KeyRank. The specific Algorithm is provided in the Appendix A.

We first examine the keywords extracted by two LLMs (Llama 3.1 and DeepSeekCoder-V2) for part of the coding problems in the APPS training set. These keywords can generally be categorized into three types: (1) Function keywords, which match the desired function names, such as count_nums in Figure 3. (2) General keywords, which appear in the problem description, like sum of digits in Figure 3. (3) Abstract keywords, which do not appear in any input; instead, they are abstract terms summarized from multiple concepts. For example, for two different concepts “substring before the dot” and “substring after the dot” in the problem description, LLM may combine them into a single keyword substring before/after the dot. The proportions of these three categories are 22.5%, 59.9%, and 17.7%.

We hypothesize that abstract keywords are the most important, as they encompass explanations across multiple concepts. General keywords refer to single concepts and are of secondary importance, while function Keywords, whose explanations have already appeared in the problem description, are the least important. Therefore, we propose ordering the keywords as abstract $\rightarrow$ general $\rightarrow$ function. Appendix E.1 demonstrates that this heuristic combination order yields the best results.

Moreover, since general keywords represent the majority (59.9%) and LLMs could extract multiple general keywords for a single problem, we further perform an internal ranking of these general keywords. We argue that a keyword is more important if it appears more frequently in the problem description (i.e., higher term frequency). Conversely, if a keyword appears less frequently in a corpus (i.e., lower document frequency), the corresponding code conversion could be more challenging as we stated in the Introduction section, and thus its explanation is more significant. Therefore, we use the TF-IDF, a widely used metric that combines term frequency (TF) and inverse document frequency (IDF), to assess the importance of general keywords. TF-IDF is calculated as follows:

$$ $\text{TF-IDF}=\frac{n_{i}}{{\textstyle\sum_{k}n_{k}}}\times\log\frac{|D|}{1+| \{j:t_{i}\in d_{j}\}|}.$ $$

The first term represents TF, where $n_{i}$ denotes the number of times the keyword appears in the problem description, and the denominator represents the total occurrences of all items with the same number of grams. The second term represents IDF, where $|D|$ is the total number of documents in the corpus, and the denominator represents the number of documents containing the keyword $t_{i}$.

We adopt the Python subset of the eval-codealpaca-v1 (Luo et al., ) as the corpus for computing document frequency, which is generated by ChatGPT and can partially reflect the distribution of LLMs’ training data. In addition, we demonstrate that SEK is robust across various corpora.

### 2.3 PromptEnrich

After obtaining the ranked keywords and their explanations, SEK integrates them with the original problem. As shown in the enriched problem in Figure 3, SEK appends the ranking results to the end of the problem, providing additional explanations for key concepts in the problem. It’s worth noting that, to maintain the coherence of the problem context, we insert the phrase “Analyze the following key terms and their relationships within the problem context:” after the problem. This acts as a semantic buffer, smoothly transitioning from the original problem description to the appended keywords. The enriched problem is then input into the LLM to generate the final solution.

## 3 Experimental Setup

We conduct a series of experiments to evaluate the effectiveness of the proposed approach SEK. In this section, we describe our experimental setup, including the selected models, benchmarks, evaluation metrics, baselines, and implementation details.

### 3.1 Studied LLMs

We select five representative LLMs to evaluate SEK, balancing between open-source and proprietary models, as well as covering a range of model sizes and architectures. The open-source models include Llama-3.1-70B-instruct (Dubey & Abhinav Jauhri, ), which is a dense decoder-only model with 70-billion parameters, Mixtral-8×22B-instruct-v0.1 (Jiang et al., ), which is a sparse Mixture-of-Experts (MOE) model having 141-billion total parameters with 39B active, and DeepSeek-Coder-V2-236B-Instruct-0724 (Zhu et al., ), which is a sparse MOE model having 236B parameters with 21B active. We access DeepSeek-Coder via DeepSeek-AI’s API. For proprietary models, we include GPT-3.5-turbo-0125 (OpenAI, ) and GPT-4o-mini (OpenAI, ), accessed via OpenAI’s API. Detailed specifications for each model are provided in the Appendix B.

### 3.2 Benchmarks and Evaluation Metric

Following previous work (Chen et al., ; Dong et al., ; Zhong et al., ; Jiang et al., ), We conduct experiments on three public code generation benchmarks HumanEval(+) (Chen et al., ; Liu et al., ), MBPP(+) (Austin et al., ; Liu et al., ), and APPS (Hendrycks et al., ). Considering the high cost of evaluating the entire APPS test problems and following prior work (Olausson et al., ; Huang et al., ; Le et al., ; Yang et al., ), we randomly select 300 problems from the APPS test set for evaluation(^1^11There are three different difficulty levels of problems in APPS, i.e., introductory, interview, and competition. Specifically, based on the frequency distribution of problems with different difficulty levels, we sample 60, 180, and 60 problems at the introductory, interview and competition levels, respectively. All tasks are listed in Appendix E.3.). To mitigate the uncertainty introduced by random sampling, we conduct multiple experiments with different sample seeds. More details are in Appendix E.3. For detailed descriptions of each benchmark, please refer to Appendix 3. We evaluate model performance using the Pass@1 metric, which measures the ability to generate correct solutions in a single attempt. This also aligns with real-world scenarios where developers aim to produce accurate code on the first try.

### 3.3 Baselines

- $\bullet$
Default LLM:
This approach is based on the EvalPlus framework (Liu et al., ), using problems from the benchmark as input to prompt LLMs for code generation.
- $\bullet$
CoT (Chain-of-Thought) (Wei et al., ):
This approach generates a series of reasoning steps during the solution-generation process for each problem. To ensure comparative fairness, both the CoT baseline and SEK employ an equal number of demonstrations.
- $\bullet$
SelfEvolve (Jiang et al., ): This approach first uses LLMs to generate problem-specific knowledge and produce initial code solutions based on such knowledge. Then, it iteratively refines code solutions with LLMs based on execution feedback. Notably, SelfEvolve uses different prompt templates for different benchmarks to extract knowledge. Since these prompt templates have been open-sourced, we consistently apply its two-stage prompts on HumanEval (see Appendix H) in our replication process. For a fair comparison, we remove the self-refinement module, and employ the same number of demonstrations as SEK.
- $\bullet$
Beam Search (Wiseman & Rush, ): This approach employs distinct search beams and optimizes selection during the decoding process. Given that SEK requires two LLM invocations per coding problem (one for generating keywords and explanations, and one for generating the code), we demonstrate the benefit of the process of SEK by comparing it with performing two searches within the LLM’s searching space, i.e., beam search with a beam size of 2.

### 3.4 Implementation Details

Prompt Design. It’s worth noting that the implementations of SEK, CoT, and Beam Search are based on the EvalPlus framework.
Specifically, the only difference between SEK and Default is the addition of keywords and explanations to the problem description. APPS contains problems in two formats: call-based formatormat. Following previous work (Olausson et al., ; Inala et al., ; Chen et al., ), we employ a two-shot prompt to guide the LLM to generate appropriate solutions for different formats.

Demonstration Selection Strategy. Inspired by previous work (Wei et al., ; Mu et al., ; Wang et al., ), we adopt a differentiated strategy that varies based on benchmark complexity (See Appendix D). To reduce bias, we employ an LLM separate from our target LLMs (Claude-3.5-Sonnet) to generate keywords and explanations for each demonstration, which are then manually reviewed and refined (See Appendix D).

Configuration. In our experiments, we treat the LLMs as black-box generators and only need to set a few key interface parameters. We maintain consistent settings across all LLMs, employing greedy decoding for output generation. The maximum output length is uniformly set to 2048 tokens.
Specifically, the LLMs accessed via APIs do not support Beam Search. Thus, we only implement Beam Search for Llama-3.1-70B-Instruct and Mixtral-8×22B-Instruct-v0.1. Due to resource limitation, we compare SelfEvolve using GPT-3.5-turbo following the original paper (Jiang et al., ) and additionally use two open-sourced LLMs (Llama-3.1 and Mixtral-8x22B).

## 4 Experimental Results

### 4.1 Main Results

Table 1 presents the performance of SEK and the selected baselines across five representative LLMs on Humaneval(+), MBPP(+) and APPS of different difficulty levels. To be noted, the Default results of Mixtral-8×22B-Instruct-v0.1 and DeepSeekCoder-V2-Instruct on Humaneval(+) and MBPP(+) are from the official leaderboard of the EvalPlus (Liu et al., ). However, as the other three LLMs are not in this leaderboard, we adhere to the EvalPlus framework to obtain their results.

Overall, SEK substantially improves code generation performance, achieving notable gains across various LLMs and datasets. We observe that SEK achieves greater performance improvements on HumanEval(+) and APPS than MBPP(+). For instance, on HumanEval, SEK demonstrates an absolute average performance improvement of 4.4% over the Default, whereas, it achieves an improvement of 1.8% on MBPP. This may be because the problems in HumanEval(+) and APPS are more complex than those in MBPP, and simple problems are easy to understand and alleviate the need to extract and explain keywords. As shown in Table 3, the average number of tokens per problem is 26.1 for MBPP, while those numbers are 67.7 and more than 257.3 for HumanEval(+) and APPS. These results may indicate that SEK can better improve LLMs’ problem-solving capabilities on relatively complex problems than on simple problems.

**Table 1: Pass@1 (%) results of SEK and baseline methods on HumanEval(+), MBPP(+) and APPS of different difficulty levels. Bold numbers indicate the best-performing baseline for each model.**
| Model | Method | HumanEval | HumanEval+ | MBPP | MBPP+ | APPS<br>Introductory | APPS<br>Interview | APPS<br>Competition | Average |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Llama-3.1-70B-Instruct | Default | 78.0 | 73.8 | 87.6 | 70.9 | 50.0 | 15.0 | 5.0 | 54.3 |
| Beam Search | 79.3 | 74.4 | 87.8 | 70.9 | 55.0 | 16.1 | 5.0 | 55.5 |  |
| CoT | 79.9 | 74.4 | 87.0 | 71.7 | 43.3 | 16.6 | 6.7 | 54.2 |  |
| SelfEvolve | 81.7 | 75.6 | 85.4 | 70.4 | 50.0 | 15.5 | 8.3 | 55.3 |  |
| SEK | 84.8 | 79.3 | 88.4 | 71.2 | 61.7 | 20.0 | 8.3 | 59.1 |  |
| Mixtral-8×22B-Instruct-v0.1 | Default | 76.2 | 72.0 | 73.8 | 64.3 | 28.3 | 7.7 | 1.6 | 46.3 |
| Beam Search | 78.7 | 73.2 | 81.2 | 70.6 | 33.3 | 8.8 | 6.6 | 50.3 |  |
| CoT | 72.0 | 65.9 | 78.0 | 68.0 | 31.6 | 3.8 | 5.0 | 46.3 |  |
| SelfEvolve | 56.7 | 50.0 | 68.5 | 60.1 | 33.3 | 7.2 | 5.0 | 40.1 |  |
| SEK | 81.1 | 75.6 | 79.1 | 66.9 | 33.3 | 10.0 | 6.6 | 50.4 |  |
| GPT-3.5-turbo<br>(API) | Default | 72.6 | 67.7 | 84.1 | 71.2 | 46.6 | 18.3 | 0.0 | 51.5 |
| CoT | 58.5 | 54.9 | 84.1 | 68.8 | 41.6 | 17.2 | 1.6 | 46.7 |  |
| SelfEvolve | 73.2 | 67.7 | 82.3 | 66.7 | 45.0 | 19.4 | 1.6 | 51.8 |  |
| SEK | 75.6 | 69.5 | 84.1 | 72.5 | 53.3 | 20.6 | 5.0 | 54.4 |  |
| GPT-4o-mini<br>(API) | Default | 87.8 | 84.1 | 85.7 | 72.8 | 53.3 | 31.6 | 11.6 | 61.0 |
| CoT | 87.2 | 84.1 | 88.1 | 73.3 | 50.0 | 33.8 | 11.6 | 61.2 |  |
| SEK | 87.2 | 84.1 | 87.8 | 74.1 | 58.3 | 35.0 | 13.3 | 62.8 |  |
| DeepSeekCoder-V2-Instruct<br>(API) | Default | 85.4 | 82.3 | 89.4 | 75.1 | 70.0 | 36.1 | 10.0 | 64.0 |
| CoT | 88.4 | 82.3 | 90.5 | 75.4 | 60.0 | 40.5 | 10.0 | 63.9 |  |
| SEK | 93.3 | 85.4 | 90.2 | 76.2 | 75.0 | 41.1 | 13.3 | 67.8 |  |

We first discuss the performance on HumanEval(+) and APPS.
These benchmarks are relatively complex compared to MBPP, and better demonstrate the effectiveness of SEK.
SEK consistently outperforms Default across most LLMs. For instance, SEK achieves average absolute improvements of 6.7%, 3.6%, and 3.7% on APPS-Introductory, APPS-Interview, and APPS-Competition, respectively.
However, GPT-4o-mini is an exception, which experiences a slight performance decline on Humaneval(+). This may be because the built-in prudence of GPT-4o-mini (Huang et al., ) makes it tend to select more generic keywords, and such generic keywords fail to help LLMs understand low-frequency terms in the problem description. This conjecture is further underpinned by an observation that CoT similarly fails to enhance GPT-4o-mini’s performance. The consistent improvements of SEK across most LLMs highlight its effectiveness in enhancing the problem-solving capabilities of LLMs.

Compared to Beam Search, which also invokes LLMs twice, SEK shows notable performance improvements. For instance, on Humaneval and Humaneval+, SEK achieves absolute average improvements of 4.0% and 3.7%, respectively, over Beam Search. These can be attributed to SEK’s unique technique: appending the problem’s critical parts to the end, enabling LLMs to focus on and comprehend these key concepts. In contrast, Beam Search merely expands the search space without gaining a deep understanding of the problem, leading to lower diversity in outputs (Li & Jurafsky, ). Consequently, it cannot enhance problem-solving capabilities in a targeted manner like SEK (See Appendix I for different cases).

Compared to CoT and SelfEvolve, SEK demonstrates a notable and consistent performance advantage. For instance, on Humaneval and Humaneval+, SEK achieves absolute average performance improvements of 7.2% and 6.5% over CoT. In contrast, the performance of CoT and SelfEvolve are inconsistent, sometimes even lower than Default. For instance, with Mixtral-8×22B-Instruct-v0.1, SelfEvolve’s performance on APPS-Interview is 0.5% lower than Default.
The unstable performance of CoT can be attributed to its inherent unsuitability for generation tasks (Sprague et al., ). Similar phenomena have been observed in prior work (Wang et al., ; Zhang et al., ; Luo et al., ; Jiang et al., ). While both SelfEvolve and SEK utilize LLMs to extract relevant knowledge from problem descriptions, they differ in the types of extracted knowledge. SEK focuses on low-frequency keywords, which are more difficult to be mapped to code implementation. This enables SEK to effectively fill the knowledge gaps during code generation. In contrast, SelfEvolve tends to merely restate the complete problem description for problems in code generation benchmarks. As a result, it is less effective in addressing the specific knowledge gaps that hinder LLM performance in code generation.

We then discuss the performance on MBPP(+), a relatively simple benchmark. SEK surpasses SelfEvolve and Default across most LLMs, further demonstrating SEK’s effectiveness. For instance, when applied to Llama-3.1-70B-Instruct, SEK achieves performance improvements of 3.0% and 0.8% over SelfEvolve on MBPP and MBPP+, respectively.

### 4.2 Discussion

We conduct additional experiments to comprehensively evaluate SEK’s performance and robustness.

Figure: (a) HumanEval
Refer to caption: x4.png

**Table 2: SEK works under different corpus for Humaneval(+).**
| Model | Method | Humaneval | Humaneval+ |
| --- | --- | --- | --- |
| Llama-3.1-70B-Instruct | Default | 78.0 | 73.8 |
| SEK (corpus = APPS training set) | 84.1 | 78.7 |  |
| SEK (corpus = Python subset of eval-codealpaca-v1) | 84.8 | 79.3 |  |
| DeepSeekCoder-V2-Instruct | Default | 85.4 | 82.3 |
| SEK (corpus = APPS training set) | 90.9 | 85.4 |  |
| SEK (corpus = Python subset of eval-codealpaca-v1) | 93.3 | 85.4 |  |

Guidelines in the prompt for KeyExtract & Explain provide essential guidance for LLMs, and KeyRank effectively prioritizes keywords. Our ablation studies confirm that both guidelines and KeyRank play crucial roles in enhancing performance. As shown in Figure 4(a)-4(b), We evaluate Llama-3.1 and Mixtral-8×22B on Humaneval (+). Removing either the guidelines or the KeyRank module results in performance degradation. For instance, removing the KeyRank module results in performance decreases of 2.4% and 1.2% on HumanEval and HumanEval+, respectively, for Mixtral-8×22B-Instruct-v0.1. Moreover, removing each guideline from the prompt individually also results in performance degradation in most cases (See Appendix 5). It is worth mentioning that even without KeyRank, SEK remains superior to the Default baseline. For instance, without KeyRank module, Mixtral-8×22B-Instruct-v0.1 shows a 2.5% improvement on HumanEval compared to the Default, underscoring the strength of SEK’s core mechanisms.

SEK demonstrates robustness to variations in demonstrations, and the corpus used in KeyRank. To show its performance is not tied to a fixed set of keyword explanations within the demonstrations used in KeyExtract & Explain, We conduct experiments using two additional sets of keyword explanations randomly generated from the same LLM (i.e., Claude-3.5-Sonnet). As shown in Figure 4(c), although there is performance variance among different keyword explanations, as would be expected when using exemplar-based prompting  (Gao et al., ; Min et al., ; Reynolds & McDonell, ), the three sets of keyword explanations consistently outperform the Default. Additionally, to evaluate the robustness to the corpus used in KeyRank, we employ select different corpus, as shown in Table 2. We observe that using SEK with Llama-3.1-70B-Instruct still shows a 6.1% absolute improvement on Humaneval compared to Default. These results demonstrate the robustness of SEK.

SEK enhances the model’s focus on core keywords in the problem description (See Appendix G). Using a visualization tool, we analyze SEK’s behaviors from the perspective of attention distribution. We select a simple problem, i.e., “Write a function to find the nth nonagonal number”, choosing the keyword “nonagonal” with its explanation for detailed analysis. By comparing the attention distribution in the Default and SEK settings, we observe that SEK help the LLM allocate more attention to the keyword and its explanation. This indicates the way SEK uses to enrich the prompt can help LLMs better focus on the key concepts in the problem description, leading to improved code generation.

### 4.3 Case Study

Figure: Figure 5: A real case from HumanEval generated by two baselines and SEK.
Refer to caption: x7.png

To further evaluate the effectiveness of SEK, we conduct a qualitative analysis. As shown in Figures 5, we select one representative sample from HumanEval, use DeepSeek-Coder-V2-Instruct as the base model, and compare the outputs of SEK with Default and CoT. See Appendix J for more details.

The problem requires finding boredom from a string of words. A boredom refers to a sentence that begins with words starting with “I”. Default fails at the very beginning by incorrectly segmenting sentences, possibly due to an inadequate understanding of the concept sentence. Although CoT correctly segments sentences through chain-of-thought reasoning, it errs when searching for boredom, mistakenly seeking sentences starting with “I” instead of boredom, indicating an incomplete understanding of the boredom concept. In contrast, SEK correctly identifies key concepts in the problem: sentence, boredom, and the method name is_bored. In their explanations, SEK precisely explains these key concepts by incorporating the provided test cases.

Through reranking, SEK helps the LLM understand the problem according to the importance of concepts: The LLM first comprehends the concept of boredom, then the sentence, and finally the is_bored. This precise comprehension and organization of key concepts enable SEK to grasp the core elements of the problem, thereby generating correct code solutions.

## 5 Related Work

LLM-based code generation: Recent advancements in LLMs have significantly improved code generation capabilities. Models like CodeGen (Nijkamp et al., ), StarCoder (Li et al., ), and GPT series (Black et al., ; Chen et al., ) have demonstrated remarkable performance in translating natural language descriptions into code snippets. These models primarily use decoder-only architectures and next-token prediction for pre-training. A subset, including CodeT5  (Wang et al., ) and PLBART (Ahmad et al., ), employs encoder-decoder architectures. Our work builds upon these foundations, focusing on enhancing LLMs’ problem-solving capabilities without additional training.

Prompting techniques for code generation: Prompting techniques for code generation can be broadly categorized into three types: The first type utilizes external knowledge to enhance LLMs’ understanding of coding problems or intermediate outputs (Mu et al., ; Nashid et al., ; Zhong et al., ). For example,
CEDAR (Nashid et al., ) retrieves relevant code examples from an external knowledge base to help LLMs understand task requirements. The second type relies solely on LLMs’ inherent capabilities, using prompt design to guide LLMs in generating code snippets that meet specific requirements (Wei et al., ; Wang et al., ; Yao et al., ). For instance, Chain of Thought (Wei et al., ) employs a step-by-step, chain-of-thought style prompt to guide LLMs in producing correct results.
The third type integrates the previous two types, leveraging both external knowledge and the LLM’s inherent knowledge to solve coding problems (Chen et al., ; Jiang et al., ; Tian & Chen, ; Chen et al., ; ). For example, Self-Debug (Chen et al., ) uses the code execution results or the code explanations generated by the LLM itself to debug the incorrect code multiple times.
SEK belongs to the second category.
Different from other methods, it focuses on improving LLMs’ comprehension of the problem by identifying and explaining the key concepts in the problem description with LLMs themselves.

Keyword extraction: Keyword extraction methods have evolved from traditional statistical (Sparck Jones, ; El-Beltagy & Rafea, ; Florescu & Caragea, ; Rose et al., ) and graph-based approaches (Mihalcea & Tarau, ; Wan & Xiao, ; Gollapalli & Caragea, ; Grineva et al., ) to more advanced techniques leveraging language models (Mahata et al., ; Bennani-Smires et al., ; Sun et al., ; Arora et al., ). Recent works like AttentionRank (Ding & Luo, ) and LLM-TAKE (Maragheh et al., ) use self-attention mechanisms and language models to identify significant keywords. Our work extends this concept to the domain of code generation, using LLMs to extract and explain problem-specific keywords to enhance code solution generation.

## 6 Conclusion and Limitations

In this work, we propose SEK, a simple yet effective method to enhance the code generation capabilities of LLMs. SEK leverages the LLM to extract and explain keywords from the problem description, followed by ranking them based on their frequency. Through extensive experiments, we demonstrate that SEK facilitates LLMs in capturing and clarifying key concepts within problems, thereby generating more accurate code solutions.

One limitation of SEK is that the two-stage invocation process of SEK incurs additional computational overhead. Future work could explore compressing the process into one invocation. In addition, keywords are extracted and explained by LLMs, of which the quality cannot be guaranteed due to the hallucinations of LLMs (Ji et al., ). Mitigating this requires enhancing the factual accuracy of LLMs (Mitchell et al., ; Tang et al., ) and proposing effective approaches for detecting factual errors (Chen et al., ; Min et al., ).

## Appendix A Aglorithm of KeyRank

Figure: Algorithm 1 KeyRank Procedure

First, we initialize the General Keywords, Abstract Keywords, and output as $K_{g},K_{a},K_{y}$, respectively. ExtractFunctionName extracts the method name if provided in the problem description. Otherwise, it returns a null value. Then, keywords are classified and scored. They can be divided into three classes: Abstract Keywords, General Keywords, and Function Keyword. Abstract keywords do not appear in any input; they are abstract terms summarized from multiple concepts and stored in $K_{a}$. General keywords denote items in the problem description. We calculate their importance using TF-IDF based on a code-related corpus. General keywords and their scores are stored in $K_{g}$. Function keyword refers to the method name for solving the problem. Its explanation provides a coarse-grained description of the problem requirements. We assign a score of -1 to the function keyword, and also store them in $K_{g}$. Finally, SortDescending sorts the keywords in $K_{g}$ based on their scores. The keywords are combined in the order of abstract, general, and function keywords, and are then returned as the Ranked Keywords.

## Appendix B Studied LLMs

- $\bullet$
Llama-3.1-70B (Dubey & Abhinav Jauhri, ) is an open-sourced, decoder-only language model, pre-trained on 15t tokens from public sources. In our experiments, we use the Llama-3.1-70B-Instruct version.
- $\bullet$
Mixtral-8$\times$22B (Jiang et al., ) is an open-source, sparse Mixture-of-Experts (MOE) model with 141B total parameters, utilizing 39B active parameters. We use the Mixtral-8$\times$22B-Instruct-v0.1 version.
- $\bullet$
DeepSeek-Coder-V2-Instruct-0724 (Zhu et al., ), developed by DeepSeek-AI, is an open-source MoE code language model pre-trained on 10.2T tokens. The instruction-tuned version is further trained on 11B tokens.
- $\bullet$
GPT-3.5-turbo-0125 (OpenAI, ) is a close-sourced LLM from OpenAI, building on GPT-3 with optimizations for more efficient text generation.
- $\bullet$
GPT-4o-mini (OpenAI, ) is a smaller, cost-effective(^2^22GPT-4 is not selected due to the high experimental cost required.) variant of GPT-4 (OpenAI & Josh Achiam, ), offering strong performance across various tasks.

## Appendix C Benchmark Details

**Table 3: Statistics of benchmarks: the total number of problems in each benchmark (Problems), the average number of hidden test cases per problem (#Avg Tests), and the average number of space-separated tokens of the problem (#Avg Tokens).**
| Benchmark | Humaneval | Humaneval+ | MBPP | MBPP+ | APPS<br>Introductory | APPS<br>Interview | APPS<br>Competition |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Problem | 164 | 164 | 399 | 399 | 60 | 180 | 60 |
| #Avg Tests | 9.6 | 764.1 | 3.1 | 105.4 | 15.1 | 25.7 | 17.3 |
| #Avg Tokens | 67.7 | 67.7 | 26.1 | 26.1 | 257.3 | 319.8 | 377.4 |

We use three widely-used benchmarks, i.e., HumanEval(+), MBPP(+), and APPS, for evaluation.
Table 3 presents their key statistics.
(1) HumanEval (Chen et al., ) consists of 164 hand-written programming problems, each including a method signature, docstring, body, and unit tests. We use both HumanEval and its extended version, HumanEval+(Liu et al., ), which enhances the original with 80$\times$ additional test samples to address test case insufficiency (Liu et al., ).
(2) MBPP (Austin et al., ) contains crowd-sourced Python programming problems. Our study uses the versions proposed by (Liu et al., ), including MBPP and MBPP+. Each of them contain 399 tasks, and the latter adds 35$\times$ test samples.
(3) APPS (Hendrycks et al., ) includes 10,000 coding problems from open-access websites, split equally into training and test sets. It includes two problem formats: call-based format (input via function parameters) and standard input format (using stdin/stdout). Problems are categorized into introductory, interview, and competition levels. There are three different difficulty levels of problems in APPS, i.e., introductory, interview and competition. Each of them has 1000, 3000, and 1000 tasks, respectively. Considering the cost of evaluating the entire APPS test set and following prior work (Olausson et al., ; Huang et al., ; Le et al., ; Yang et al., ), we randomly select problems in accordance with the frequency distribution of these difficulty levels and sample 60, 180, 60 problems at the introductory, interview, and competition levels, respectively.

## Appendix D Implementation Details

Demonstration selection strategy. Specifically, for HumanEval, we select the first two problems as demonstrations. For MBPP, we choose the first problem. For APPS, considering the model’s input length limitation and to avoid randomness, we select the two shortest problems from the first five problems in the training set. The reason for this differentiated strategy is that HumanEval and APPS problems are more complex, requiring more examples, while MBPP problems are relatively simple in form, and one example is enough.

Keywords and explanations involved in demonstrations. The prompt for KeyExtract & Explain uses several demonstrations to guide LLMs to produce keywords and their explanations. To ensure the quality of each demonstration, we first employ Claude-3.5-Sonnet, an LLM separate from our target LLMs, to generate multiple sets of keywords and explanations for each demonstration. The generated contents are then manually reviewed, and the most accurate set for each demonstration is selected and used in the prompt. This can mitigate the potential bias in human-generated explanations. Additionally, for HumanEval(+) and MBPP(+) datasets, which provide function names, the first two authors discuss and write the explanation for the function name in each demonstration.

## Appendix E Additional experiments

### E.1 Influence of Keyword Combination Orders

**Table 4: The experiments of different combination orders on Humaneval(+) with two LLMs.**
| Model | Combination Order | HumanEval | HumanEval+ |
| --- | --- | --- | --- |
| Llama-3.1-70B-Instruct | Func_Abs_Gen | 83.5 | 78.7 |
| Gen_Func_Abs | 84.1 | 78.7 |  |
| Gen_Abs_Func | 84.1 | 78.7 |  |
| SEK | 84.8 | 79.3 |  |
| Mixtral-8×22B-Instruct-v0.1 | Func_Abs_Gen | 78.0 | 72.0 |
| Gen_Func_Abs | 78.0 | 72.0 |  |
| Gen_Abs_Func | 76.8 | 71.3 |  |
| SEK | 81.1 | 75.6 |  |

In KeyRank, we combine different types of keywords based on the order of abstract $\rightarrow$ general $\rightarrow$ function.
We investigate the influence of keyword combination orders by comparing the order used by SEK with three alternative ordering strategies using two LLMs, i.e., Llama-3.1-70B-Instruct and Mixtral-8×22B-Instruct-v0.1.
Table 4 presents the experimental results, where the abbreviations Abs, Gen, and Func denote abstract keywords, general keywords, and function keywords, respectively.
The results reveal performance variations across different keyword combination orders, indicating that the order of different keyword types impacts LLMs’ comprehension of coding problems. The combination order used by SEK consistently yields optimal performance, suggesting its rationality.

### E.2 Influence of Guidelines

**Table 5: Ablation experiments on removing one guideline at a time from Keyword Prompt on HumanEval(+) with two LLMs.**
| Model | Ablations | HumanEval | HumanEval+ |
| --- | --- | --- | --- |
| Llama-3.1-70B-Instruct | w/o Guideline(1) | 85.4 | 78.7 |
| w/o Guideline(2) | 82.3 | 75.6 |  |
| w/o Guideline(3) | 81.7 | 76.8 |  |
| w/o Guideline(4) | 81.1 | 76.2 |  |
| w/o Guideline(5) | 83.5 | 77.4 |  |
| ALL Guidelines | 84.8 | 79.3 |  |
| Mixtral-8×22B-Instruct-v0.1 | w/o Guideline(1) | 76.8 | 72 |
| w/o Guideline(2) | 77.4 | 72.6 |  |
| w/o Guideline(3) | 79.3 | 73.8 |  |
| w/o Guideline(4) | 75.0 | 70.1 |  |
| w/o Guideline(5) | 76.8 | 73.2 |  |
| ALL Guidelines | 81.1 | 75.6 |  |

In Section 4.2, we investigate the effectiveness of the guidelines in the KeyExtract & Explain prompt as a whole.
This section further investigates the impact of each guideline by removing it from the prompt and re-evaluate the performance of SEK with two LLMs, i.e., Llama-3.1-70B-Instruct and Mixtral-8×22B-Instruct-v0.1 on HumanEval(+).
Table 5 presents the experimental results, where the performance of the two LLMs decreases in almost all cases, indicating the contribution of each guideline to the effectiveness of SEK.

### E.3 More Experiments on APPS

**Table 6: The Pass@1 (%) results of SEK and baseline methods on differently sampled APPS-Introductory sets.**
| Model | Method | Introductory(A) | Introductory(B) | Introductory(C) | Average |
| --- | --- | --- | --- | --- | --- |
| Llama-3.1-70B-Instruct | Default | 51.6 | 45.0 | 46.6 | 47.7 |
| Beam Search | 55.0 | 45.0 | 45.0 | 48.3 |  |
| CoT | 41.6 | 46.6 | 45.0 | 44.4 |  |
| SelfEvolve | 45.0 | 53.3 | 46.6 | 48.3 |  |
| SEK | 58.3 | 56.6 | 50.0 | 55.0 |  |
| GPT-3.5-turbo<br>(API) | Default | 45.0 | 51.6 | 43.3 | 46.6 |
| CoT | 48.3 | 53.3 | 46.6 | 49.4 |  |
| SelfEvolve | 46.6 | 48.3 | 45.0 | 46.6 |  |
| SEK | 48.3 | 53.3 | 50.0 | 50.5 |  |

In the main experiment, we randomly sample problems from the APPS test set for evaluation due to limited resources. The performance of LLMs on APPS may be affected by the randomness of the selected samples. To mitigate this variability, we conduct additional experiments by randomly selecting three new subsets of problems at the introductory level from the APPS test set and using two LLMs for evaluation, i.e., Llama-3.1-70B-instruct and GPT-3.5-Turbo. The number of sampled tasks is fixed at 60, consistent with the main experiment. For reproducibility, the selected tasks are provided in Table 7.
As shown in Table 6, SEK achieve optimal performance across different subsets. For instance, considering Llama-3.1-70B-Instruct, SEK outperforms the Default, Beam Search, and CoT baselines by an average of 7.3%, 6.7%, and 10.6%, respectively. This corroborates the credibility of our conclusions.

**Table 7: The tasks in different sampling Introductory sets.**
| Datasets | Tasks |
| --- | --- |
| Introductory(A) | 4029, 4032, 4050, 4054, 4060, 4099, 4116, 4131, 4132, 4148, 4157, 4166, 4180, 4206, 4211, 4232, 4251, 4256, 4283, 4289, 4317, 4320, 4323, 4332, 4343, 4356, 4417, 4451, 4469, 4471, 4527, 4538, 4541, 4542, 4546, 4599, 4625, 4640, 4676, 4680, 4704, 4721, 4748, 4774, 4780, 4781, 4787, 4800, 4806, 4826, 4837, 4864, 4868, 4878, 4888, 4896, 4924, 4926, 4930, 4943 |
| Introductory(B) | 4021, 4046, 4051, 4073, 4115, 4127, 4138, 4140, 4156, 4163, 4201, 4225, 4230, 4233, 4236, 4263, 4270, 4294, 4295, 4347, 4358, 4375, 4376, 4407, 4424, 4446, 4453, 4454, 4460, 4469, 4478, 4486, 4489, 4528, 4547, 4570, 4580, 4596, 4638, 4644, 4656, 4678, 4692, 4695, 4726, 4730, 4735, 4740, 4780, 4803, 4842, 4869, 4871, 4890, 4905, 4918, 4932, 4947, 4970, 4975 |
| Introductory(C) | 4018, 4028, 4042, 4085, 4102, 4134, 4146, 4172, 4201, 4203, 4257, 4274, 4281, 4309, 4314, 4324, 4353, 4356, 4387, 4418, 4447, 4461, 4465, 4473, 4474, 4486, 4499, 4506, 4510, 4528, 4560, 4592, 4604, 4617, 4627, 4701, 4704, 4710, 4712, 4713, 4716, 4719, 4723, 4732, 4763, 4772, 4801, 4812, 4867, 4879, 4893, 4898, 4907, 4924, 4929, 4944, 4957, 4973, 4974, 4975 |

## Appendix F Selected APPS tasks

For reproducibility, we provide the complete list of selected tasks of APPS in Table 8.

**Table 8: The tasks in different difficulty levels of APPS.**
| Difficulty | Tasks |
| --- | --- |
| Introductory | 4007, 4032, 4049, 4050, 4054, 4060, 4114, 4116, 4132, 4148, 4157, 4166, 4180, 4211, 4215, 4232, 4251, 4283, 4289, 4317, 4323, 4332, 4343, 4356, 4372, 4417, 4439, 4451, 4469, 4527, 4540, 4541, 4546, 4549, 4582, 4585, 4599, 4625, 4631, 4640, 4676, 4678, 4704, 4721, 4774, 4781, 4787, 4800, 4806, 4826, 4837, 4861, 4864, 4868, 4878, 4888, 4924, 4926, 4929, 4930 |
| Interview | 6, 10, 35, 44, 56, 76, 82, 95, 105, 106, 115, 133, 135, 178, 188, 198, 210, 213, 231, 240, 248, 278, 300, 305, 319, 342, 357, 372, 377, 379, 420, 457, 460, 483, 484, 489, 546, 553, 566, 567, 584, 634, 664, 669, 675, 686, 696, 701, 734, 785, 817, 855, 861, 876, 903, 909, 914, 932, 973, 989, 993, 994, 1017, 1020, 1025, 1033, 1039, 1053, 1069, 1101, 1122, 1132, 1140, 1144, 1158, 1166, 1167, 1224, 1226, 1232, 1280, 1313, 1346, 1351, 1361, 1373, 1375, 1391, 1394, 1406, 1409, 1432, 1458, 1459, 1478, 1487, 1491, 1508, 1520, 1527, 1534, 1540, 1557, 1563, 1565, 1590, 1635, 1640, 1715, 1720, 1733, 1749, 1761, 1768, 1775, 1813, 1823, 1833, 1838, 1864, 1881, 1885, 1955, 1976, 1982, 1989, 2003, 2006, 2011, 2015, 2048, 2053, 2062, 2077, 2097, 2101, 2145, 2177, 2192, 2209, 2273, 2293, 2317, 2361, 2406, 2443, 2492, 2494, 2495, 2502, 2513, 2514, 2533, 2542, 2546, 2552, 2554, 2609, 2615, 2641, 2642, 2655, 2657, 2684, 2707, 2725, 2726, 2728, 2729, 2762, 2767, 2776, 2784, 2788, 2815, 2850, 2874, 2914, 2982, 2999 |
| Competition | 3009, 3024, 3031, 3071, 3097, 3131, 3138, 3171, 3188, 3204, 3206, 3210, 3211, 3252, 3262, 3263, 3298, 3301, 3313, 3319, 3326, 3372, 3379, 3445, 3456, 3479, 3481, 3501, 3517, 3535, 3573, 3579, 3618, 3629, 3654, 3680, 3684, 3690, 3713, 3721, 3727, 3731, 3733, 3745, 3762, 3775, 3786, 3788, 3802, 3803, 3843, 3863, 3882, 3886, 3893, 3901, 3943, 3945, 3948, 3972 |

## Appendix G Attention Analysis

We aim to explain SEK from the perspective of attention distribution.
We use BertViz(^3^33https://github.com/jessevig/bertviz) to present explainability visualizations. Due to limited computational resources, we select a short problem and remove its test cases. Specifically, the problem description is “Write a function to find the nth nonagonal number.” and we select a keyword with its explanation “[nonagonal]: A nine-sided polygon. Nonagonal numbers represent the count of dots forming nonagons of increasing size”. We select Mixtral-8×22B-Instruct-v0.1 as the base model and extract the attention from its last layer for analysis.

The key to this problem lies in understanding “nonagonal”. With Default, Figure 7 shows the overall attention distribution for the problem, while Figure 7 displays the attention distribution for a part of the keyword “nonagonal”. It can be observed that most of the attention is allocated to the beginning words, with the keyword “nonagonal” receiving relatively less attention. This may lead to insufficient focus on the core concept of the problem when generating code. In contrast, with SEK, Figure 9 presents the overall attention distribution of the LLM with SEK and Figure 8 shows the attention distribution for “nonagonal”. It can be seen that the model allocates additional attention to the added keywords and explanations, encouraging the model to focus more on the core concepts of the problem. With SEK, the LLM further distributes attention to the added keywords and explanations, which can enhance its understanding of the key concepts in the problem.

Figure: Figure 6: Attention visualization with Default.
Refer to caption: x8.png

Figure: Figure 8: Attention visualization for a part of the keyword ”nonagonal” with SEK.
Refer to caption: x10.png

Figure: Figure 9: Final layer of the attention visualization with SEK
Refer to caption: x11.png

## Appendix H Prompt For Self-Evolve

Figure: Listing 1: The first prompt of Self-Evolve

Figure: Listing 2: The Second prompt of Self-Evolve

## Appendix I Case Study of the Difference between Beam Search and SEK

Figure: Listing 3: A problem from Humaneval (problem ID $131$)

Figure: Listing 4: The output of Default from Humaneval (problem ID $131$)

Figure: Listing 5: The output of Beam Search from Humaneval (problem ID $131$)

Figure: Listing 6: The output of SEK from Humaneval (problem ID $131$)

Despite expanding the search space, Beam Search is still less effective than SEK due to its failure to deepen its understanding of the problem. To illustrate this, we use Problem 131 from Humaneval, generated by Llama 3.1-70B-Instruct. Although Beam Search and the Default implementations differ, neither approach fully comprehends the problem. Specifically, when handling odd digits, both methods incorrectly return 0 when the product of the odd digits is 1. In contrast, SEK not only identifies but also correctly interprets the concept of odd digits in the problem description, allowing it to handle cases where the product of the odd digits equals 1 accurately. This demonstrates that SEK, by focusing on the underlying semantic understanding of key problem concepts, develops a deeper comprehension of the task, ultimately leading to the correct solution.

## Appendix J More examples

We extract an example from MBPP. The problem involves finding an element with a 1-based index in a given array. It can be observed that both Default and CoT make the same mistake: they perform unnecessary sorting operations on the array, resulting in the generation of incorrect code solutions. In contrast, SEK does not conduct sorting. It accurately extracts the core concepts of the problem, i.e., 1-based indexing and kth element. Explanations of these two key concepts do not mention any need for sorting, demonstrating a precise grasp of the problem’s requirements. Consequently, SEK successfully generated the correct code solution.

Figure: Listing 7: A problem from MBPP (problem ID $101$)

Figure: Listing 8: The output of Default from MBPP (problem ID $101$)

Figure: Listing 9: The output of CoT from MBPP (problem ID $101$)

Figure: Listing 10: The keywords output of SEK from MBPP (problem ID $101$)

Figure: Listing 11: The enriched problem of MBPP (problem ID $101$)

Figure: Listing 12: The output of SEK from MBPP (problem ID $101$)

We also present an example from APPS-Introductory. This problem requires solving an optimization problem with the goal of minimizing the number of thieves while ensuring that each thief steals the same number of swords and accounting for all missing swords. This solution requires the use of the greatest common divisor (GCD). It can be seen that both CoT and Default make the same mistake: they use the difference between the maximum and minimum sword counts to calculate the number of swords each person takes. In contrast, only SEK correctly utilizes the GCD, resulting in the generation of accurate code.

Figure: Listing 13: A problem from APPS-Introductory (problem ID $4372$)

Figure: Listing 14: The output of Default from APPS-Introductory (problem ID $4372$)

Figure: Listing 15: The output of CoT from APPS-Introductory (problem ID $4372$)

Figure: Listing 16: The enriched problem of APPS-Introductory (problem ID $4372$)

Figure: Listing 17: The output of SEK from APPS-Introductory (problem ID $4372$)

Figure: Listing 18: A problem from MBPP (problem ID $594$)

Figure: Listing 19: The output of Default from MBPP (problem ID $594$)

Figure: Listing 20: The output of CoT from MBPP (problem ID $594$)

Figure: Listing 21: The enriched problem of MBPP (problem ID $594$)

Figure: Listing 22: The output of SEK from MBPP (problem ID $594$)

## Appendix K Details of demonstrations used in KeyExtract & Explain

Figure: Listing 23: The selected demonstrations and corresponding keywords and explanations in Humaneval(+) benchmark

Figure: Listing 24: The selected demonstrations and corresponding keywords and explanations in MBPP(+)

Figure: Listing 25: The selected demonstrations and corresponding keywords and explanations in APPS

## Peer Reviews

confidence: 4
contribution: 3
initial_rating: 5
presentation: 3
questions: - Could the authors provide more detail (and an example) on the construction of the full CoT prompts presented to the models (including demonstrations). One surprising result in Table 5 was the large drop in human-eval performance for GPT-3.5-turbo for CoT relative to the default setup. It would be helpful to readers to understand how the demonstrations used might impact quality of generation.
- Table 4 shows results for experiments for 4 different combination orders in order to determine the best one. But shouldn't there be 6? Abs_Func_Gen and Func_Gen_Abs seem to be missing. Why weren't these other combinations evaluated?
	- As an aside it would help to put "SEK (Abs_Gen_Func)" in the table to help the reader compare.
- How many keywords are extracted and how many explanations are generated? The motivation for ranking the keyword descriptions based on locality bias in LLMs is a factor I wouldn't have expected to be relavant over the short token spans of the examples shown so was surprising to see.
- Fig 5 case study. I may have misunderstood something, but I couldn't understand the description of the case study associated with figure 5. It suggests that the CoT result searches for the string "boredom" rather than "I", but I couldn't identify that bug. I transcribed all 3 solutions and found the default and CoT ones were correct and the SEK one was wrong (not correctly capturing the sentences). I've included the code I used below for the authors to examine and point out if i missed something. 

```py
def is_bored_default(S):
    # Split the string into sentences based on delimiters '. ', '?', and '!' 
    sentences = S.split('.') 
    sentences += S.split('?') 
    sentences += S.split('!') 
    # Remove empty strings from the list 
    sentences = [sentence.strip() for sentence in sentences if sentence.strip()] 
    # Count the number of sentences that start with "I" 
    boredom_count = 0 
    for sentence in sentences: 
        words = sentence.split()
        if words and words[0].lower() == "i":
            boredom_count += 1 
    return boredom_count


def is_bored_cot(S):
    # Step 1: Initialize 
    count = 0 
    sentences = S.split('.') # Split by '.' first 
    # Step 2: Further split by '?' and '!'
    sentences = [sentence for sublist in [sentence.split('? ') for sentence in sentences] for sentence in sublist]
    sentences = [sentence for sublist in [sentence.split('! ') for sentence in sentences] for sentence in sublist] 
    # Step 3: Check each sentence 
    for sentence in sentences: 
        # Step 4: Strip leading/trailing whitespace and ch eck if it starts with "I" 
        if sentence.strip().startswith("I"): 
            count += 1 
    # Step 5: Return the count 
    return count


def is_bored_sek(S):
    # Split the string into sentences based on '.', '?', or '!' 
    sentences = [] 
    start = 0
    for i, char in enumerate(S): 
        if char in '.?!': 
            print("Appending", S[start:i+1].strip())
            sentences.append(S[start:i+1].strip()) 
            start = i + 1 
    # Count the number of boredoms 
    boredom_count = 0 
    print("Se", sentences)
    for sentence in sentences:
        # Check if the sentence starts with the word "I" 
        if sentence.startswith("I ") or sentence == "I": 
            boredom_count += 1 
    return boredom_count


print("is_bored_default")
print(is_bored_default("Hello world"))
print(is_bored_default("The sky is blue. The sun is shining. I love this weather"))
print(is_bored_default("The sky is blue. I think The sun is shining. I love this weather"))

print("is_bored_cot")
print(is_bored_cot("Hello world"))
print(is_bored_cot("The sky is blue. The sun is shining. I love this weather"))
print(is_bored_cot("The sky is blue. I think The sun is shining. I love this weather"))

print("is_bored_sek")
# Outputs 0
print(is_bored_sek("Hello world"))
# Outputs 0 instead of 1
print(is_bored_sek("The sky is blue. The sun is shining. I love this weather"))
# Outputs 1 instead of 2
print(is_bored_sek("The sky is blue. I think The sun is shining. I love this weather"))
```
soundness: 3
strengths: - The paper presents a structured and domain-motivated approach to think about prompt refinement that I think also could be useful in other non-code domains as well. Particularly ones where there is some shared structure between instances or in the general process of solving the task that we can identify apriori.
- It seems possible that one could use this general approach to combine models that are specialized towards explanations with models specialized towards solving tasks in the target domain.
- I think the results point to the fact that many problems may be 'underspecified' and that models are capable of (self) improvement of the specification before solving the problem. The general approach proposed is elegant, simple and targeted.

Overall I think this is an interesting paper, there were a few things that made my score a bit lower that might be addressable by the authors during the discussion.

**Post-discussion update**

I've increased my score based on the updates to the papers from the authors.
summary: This paper introduces a two-stage prompting technique called “Self-Explained Keywords”, that improves the quality of code generated from a variety of LLMs. The technique primarily works by first inducing the model to produce descriptions of select keywords, then ranking these descriptions and finally appending them to the original context before proceeding with code generation. The paper suggests that the ideal keywords to select are low-frequency terms in the model training corpus that the model may have more difficulty understanding. The authors evaluate their method on 5 different LLMs across 3 major code generation benchmarks (and an additional variant of the HumanEval and MBPP benchmarks) and find that performance increases across various models.
weaknesses: - **No evaluation of zero-shot CoT**: From what I can tell there is no evaluation of zero-shot CoT [Kojima et al, 2022], (aka "lets think step by step"). The proposed method seems similar in spirit to zero-shot CoT albeit more structured and tailored to code generation. The paper would be stronger if it benchmarked against that method, as it would provide a condition that is not dependent on the effect of demonstrations in the original CoT formulation and would allow readers to understand how much problem refinement models are able to do without the use of a specialized prompt.

- **Selecting number of beams=2 because SEK calls the model twice doesn't seem all that well motivated.** Beam search is significantly less costly than full generation so if the goal is to match compute it doesn't seem necessary to limit to just two beams. Since the beam search results are somewhat competititive with other methods, it would be helpful to readers to understand how this saturates as the number of beams increases. The  Wiseman & Rush 2016 citation for beam search experiemnts with beams=5 and beams=10. Could the authors shed some more light on their seelction and why?

- **Results bounds**
	- Table 1 does not show any result bounds like standard deviation or confidence intervals. The authors do present the ranges for the different sampled APPS sets in Table 6 in the appendix, but this should be brought into the main table to allow readers to see the variability of scores for that benchmark. 
	- Alternatively the paper would be stronger if it also presented with pass@k (where k > 1) to capture some of the variablity that may be present in each of the methods.
	- In particular the results in Table 4 would benefit from repeated sampling and error bounds to better understand the importance of the ranking step as the scores are somewhat close.

- **Low frequency assumption**
	- One area of the paper that I did not find particularly convincing was the assertion that the keywords worth explaining are low-frequency tokens *in the training corpus*. I couldn't really find any evidence for this presented in the paper, if I missed this then I'd certainly appreciate clarification. If not then I think the paper would be better served if this were framed as a motivating assumption. While I think the intuition that rarity may play a role is not unreasonable, it seems somewhat overstated as causative. To give an example, L043 "The term even digits rarely appears in code datasets, causing LLMs to misinterpret it as even numbers." — how do we know that **"even digits"** occurs rarely in training datasets (presumably compared to "even numbers")?
	- The prompt used to select "keywords" wouldn't necessarily bias towards selecting low frquency terms in the training corpus. It mainly tries to select and expand on key terms for the problem at hand and for generating correct functions

---

confidence: 3
contribution: 2
initial_rating: 3
presentation: 2
questions: 1. Did you explore the integration of RAG or similar methods into your approach?
2. Have you considered developing more advanced methodologies or theoretical frameworks at a higher level to enhance your proposed solution?
soundness: 2
strengths: a practical motivation for this paper and a good writing in the introduction section.
Extensive experiments in this paper.
summary: This paper presents SEK (Self-Explained Keywords), a straightforward approach designed to enhance the code generation capabilities of large language models (LLMs). SEK utilizes the LLM to identify and elucidate keywords from problem descriptions and ranks them based on frequency. The authors conduct extensive experiments to show that SEK aids LLMs in recognizing and clarifying essential concepts within problems, thereby improving the accuracy of generated code solutions.


I concur with the paper's motivation, recognizing that due to the long tail of training data, LLMs often misinterpret or miss problem-specific, low-frequency keywords during code generation, which compromises the accuracy of the generated code. The method outlined in the paper involves three steps: keyword extraction and explanation via prompt-based LLMs, rule-based keyword ranking, and enriched prompt input for the final code generation step. 


I maintain reservations about the first step, which depends on the LLM's capability to extract and understand keywords. This reliance on the LLM’s inherent abilities seems contradictory to the paper’s motivation. As noted in the paper, LLMs exhibit biases toward low-frequency text comprehension. Therefore, I remain my concerns for this step. The method needs a more generalized or innovative strategies to mitigate this issue, making it challenging to achieve broad applicability solely with constructed prompts. Have the authors investigated the performance of the LLMs specifically in extracting low-frequency keywords? Is there any observed bias? Given the known instability of LLM results, have the authors performed any experimental analyses or discussions on this issue? For instance, running the LLM multiple times, analyzing variations, and conducting separate experiments on low-frequency words to assess the LLM's effectiveness. I suggest that the authors consider using pre-defined keyword extraction dictionaries or tools alongside LLMs for more robust keyword extraction.


In the second and third steps (keyword ranking and prompt enrichment), the ranking method based on heuristic rules is not very flexible or portable and may become unreliable with updates. The concepts of these steps seem akin to Retrieval Augmented Generation (RAG). I recommend that the author consider enhancing these steps by integrating RAG principles. Using heuristic rules and external low-frequency dictionaries as knowledge sources within RAG could allow for a recombination of LLM and RAG to improve the ranking algorithm. Ultimately, this could enrich the prompt with more relevant retrieved context. I think using RAG may be more effective than relying solely on rule-based ranking because it is closer to current technology trends and makes the paper's approach more flexible.


Overall, although it seems that numerous experiments validate the method's effectiveness, the approach remains fundamentally simple, centered primarily around prompt engineering. It lacks substantial theoretical depth and appears to reiterate existing methods rather than presenting innovative solutions. I recommend that the author consider replacing heuristic rules with RAG and integrating existing keyword extraction tools or custom low-frequency keyword dictionaries to create a more adaptable system. Relying excessively on heuristic rules to enhance prompts could render the method cumbersome and challenging to apply to different datasets or application contexts.
weaknesses: Dependence on LLM's Existing Capabilities: The method heavily relies on the LLM's existing keyword extraction and comprehension abilities, which could perpetuate inherent biases, particularly with low-frequency text.
The method proposed, such as prompt engineering and rule-based ranking, are not fundamentally novel and rely heavily on existing techniques, which may limit their impact in advancing the field.

---

confidence: 4
contribution: 2
initial_rating: 5
presentation: 3
questions: See Weaknesses.
soundness: 2
strengths: - This paper presents a well-designed pipeline to address the issue of overlooking low-frequency terms in program descriptions due to the long-tail distribution present in LLM training data. The experimental results demonstrate that SEK effectively enhances code generation performance.

- The authors have conducted a wide spectrum of experiments, encompassing five leading LLMs, four baseline models, and three established code generation benchmarks. This extensive evaluation adds robustness and credibility to the findings.
summary: This paper introduces **SEK** (Self-Explained Keywords), a pipeline to improve large language model (LLM) code generation by translating low-frequency keywords in the problem description into high-frequency natural language descriptions. The authors evaluate the effectiveness of SEK on three code generation benchmarks and claim that SEK provides substantial and consistent performance improvements.
weaknesses: - **Simplistic Benchmarks:** The selected benchmarks seem relatively simple and may not adequately capture the real-world effectiveness of the proposed approach. To enhance the rigor and applicability of this study, incorporating more recent and realistic benchmarks [1,2] would be beneficial. This would strengthen the overall soundness and relevance of the paper.

- **Similarity to One-step CoT or One-shot Learning:** The SEK approach exhibits similarities with one-step chain-of-thought (CoT) and one-shot learning strategies. To better elucidate and highlight the advantages of SEK, I suggest conducting a simple experiment, which could ask a language model to rephrase the problem description using precise language. The rephrased description would then be fed back into the language model to determine if this simple rephrasing enhances performance as well as SEK does.

[1] Zhuo, T. Y., Vu, M. C., Chim, J., Hu, H., Yu, W., Widyasari, R., ... & Von Werra, L. (2024). Bigcodebench: Benchmarking code generation with diverse function calls and complex instructions. arXiv preprint arXiv:2406.15877.

[2] Shypula, A., Madaan, A., Zeng, Y., Alon, U., Gardner, J., Hashemi, M., ... & Yazdanbakhsh, A. (2023). Learning performance-improving code edits. arXiv preprint arXiv:2302.07867.

Meta-review: This paper introduces a novel two-stage prompting method called “Self-Explained Keywords”, aimed at improving code generation quality across a variety of large language models (LLMs). The technique involves: (1) prompting the model to generate descriptions for selected keywords from the problem context, (2) ranking these descriptions, and (3) appending the selected descriptions to the original context before initiating code generation. The approach prioritizes low-frequency keywords from the model’s training corpus, hypothesized to be terms the model struggles to understand. The method is evaluated on five different LLMs across three major code generation benchmarks, including variants of HumanEval and MBPP, showing consistent performance improvements.

However, this work has key limitations. Firstly, the evaluation is restricted to a limited set of benchmarks, raising questions about whether the benchmarks sufficiently validate the method’s underlying assumptions. Secondly, the rationale behind the approach lacks clarity and strong scientific grounding. The hypothesis regarding low-frequency keywords and their explanations is not well substantiated, leaving room for skepticism about why the method succeeds.

Decision: Reject