> | Resource | Info |
> | :---        |:--- |
> | Paper       | https://arxiv.org/abs/2409.17561 |
> | Code & Data | / |
> | Public      | arXiv |
> | Date        | 2025.01.04 |


# Summary Overview

TestBench, a benchmark for class-level LLM-based test case generation. We construct a dataset of 108 Java programs from 9 real-world, large-scale projects on GitHub, each representing a different thematic domain.

Five aspects to evaluate the LLMs: syntactic correctness, compilation correctness, test correctness, code coverage rate and defect detection rate.

When using simplified version, namely the simple context, which is dervied from the full context via abstract syntax tree analysis, the performance of these models improves significantly.

![image.png](/static/img/17fa8d7c2e16b3a18a1f1ce6a04c0296.image.png)

# Main Content

Three steps to select functions under test from various open-source projects:
1. We initially identify candidate projects by crawling Java repositories with more than 1,000 stars. We then refine the selection by filtering for projects that utilize the Maven and JUnit frameworks and have a project size between 10 to 100 MB, in order to strike a balance between representativeness and efficient compilation. After this step, we collect 99 candidate projects.
2. We carefully select 20 projects from the candidate pool, ensuring a diverse range of topics. Each project is cloned and verified for successful compilation and test execution on our verification platform. We then extract all public functions, excluding test functions, interfaces, abstract methods, and deprecated functions.
3. We manually select high-quality funcitons from the selected functions, with the primary criterion being whether a function frequently appears in real-world development scenarios. Then, we filter projects based on the number of high-quality functions they contain, helping us to achieve the same number of selected functions with fewer projects.

**Prompt Design**
1. Self-contained context
2. Full context
![image.png](/static/img/d96badfbb14f965ad7c375a6125ae320.image.png)
4. Simple context
![image.png](/static/img/77b0fcfdef03d49370586a7b2dfda470.image.png)

完整的 prompt 结构:

![image.png](/static/img/f1a4f9f0854e940959e86f9b95719770.image.png)


**Evaluation Metric:**
1. Syntactic correctness: 我们希望生成的测试用例可以直接执行。为此，我们将Javalang用作生成测试用例的Java代码的静态分析工具。
2. Compilation correctness: 由于静态分析无法识别诸如变量名称，函数名称和范围之类的错误，因此我们使用MVN测试过程动态编译生成的测试用例以对代码进行动态分析，从而确定是否可以正确编译测试用例。
3. Execution correctness: 考虑到LLMS代码生成的不确定性，它是否可以用正确的断言生成测试用例，准确地发现生产代码中的缺陷，并避免误判正确的逻辑也是至关重要的部分。我们根据测试案件执行期间是否发生故障或错误来评估测试案例的正确性。
4. Coverage rate: 对于可以正确执行的测试用例，我们旨在计算测试功能的覆盖范围，以衡量其检测潜在缺陷的能力。由于所选项目的复杂性，我们选择通过中级代码仪器来衡量覆盖范围指标。为此，我们使用jacoco计算测试用例的覆盖率。
5. Defect detection rate: 除了覆盖范围之外，我们还选择经典的突变测试来检测测试案例代码中的缺陷。为此，我们使用默认类型和突变数量来计算测试用例的突变杀伤率以评估其有效性水平。

**How do CodeLlama, ChatGPT and GPT4 perform on TestBench?**

![image.png](/static/img/f239288665d716c594bda99cbda9cb16.image.png)

![image.png](/static/img/4943f4b9f24ceee9d5ecf3eb2282e044.image.png)

![image.png](/static/img/8ff70f526e9afc7b3a1c69feb3305453.image.png)

![image.png](/static/img/ce46456cf2192db00cfcf30e79d36dbb.image.png)

![image.png](/static/img/ca17f6f6e28cbd201873e9e0b1ea9c8f.image.png)

**How do different contexts affect the results?**

![image.png](/static/img/64415f923fa6ba07b4372e2163be2001.image.png)


# 🤖ChatGPT

:::info{title="ChapGPT"}
1. 论文的创新之处与独特性：
   - **提出了首个针对类级测试用例生成的基准（TestBench）**：论文填补了测试用例生成领域缺乏公开基准的空白，通过构建TestBench，系统性地评估了大语言模型（LLMs）在生成类级测试用例中的能力。
   - **设计了多维度的评估框架**：提出了五个细化的评估指标（语法正确性、编译正确性、执行正确性、代码覆盖率和缺陷检测率），为全面评估LLMs生成的测试用例质量提供了依据。
   - **引入三种上下文描述**：通过对上下文内容的不同设计（自包含上下文、完整上下文、简化上下文），探索了上下文信息对测试用例生成质量的影响。
   - **提出启发式修复算法**：针对生成测试用例中的常见错误模式，设计了一种启发式修复算法，提高了测试用例的语法正确性和编译通过率。
   - **实验结果揭示模型规模对上下文处理能力的影响**：研究表明，较大的模型（如GPT-4）在处理复杂上下文时表现更优，而小规模模型（如CodeLlama）在面对丰富上下文时容易受到噪声干扰。

2. 论文中存在的问题及改进建议：
   - **数据泄漏的潜在威胁**：由于TestBench数据集来源于GitHub的开源项目，可能与LLMs的训练数据存在重叠，无法完全排除数据泄漏的可能性。改进建议：通过更严格的去重和验证机制，确保数据集的独立性；或者构建完全独立的测试数据集，比如从未公开的代码库中选取样本。
   - **测试用例生成的实际开发场景适用性有限**：虽然论文使用了真实的开源项目，但其测试用例生成的适用性主要集中于类级别，缺乏对更复杂场景（如跨模块测试或系统级测试）的探索。改进建议：扩展基准测试的范围，涵盖更多真实开发场景和复杂系统。
   - **模型性能分析的深度不足**：虽然论文分析了不同模型的错误类型，但未深入探讨错误的根本原因（如模型生成逻辑或上下文理解能力的不足）。改进建议：结合模型内部的生成过程，分析其在特定任务上的局限性，并提出针对性的改进方法。
   - **修复算法的通用性有限**：启发式修复算法主要针对结构性错误，未能覆盖逻辑性错误或更复杂的缺陷模式。改进建议：结合程序分析技术（如静态分析和动态分析），设计更智能的修复算法，覆盖更多错误类型。

3. 基于论文的内容和研究结果，提出的创新点或研究路径：
   - **创新点1：基于跨模块上下文的测试用例生成**：探索如何利用跨模块或跨类的上下文信息来生成更复杂的测试用例，评估模型对全局代码结构的理解能力。
   - **创新点2：引入语义增强的上下文表示**：通过结合程序的语义信息（如变量依赖、调用关系图等），优化上下文表示，提升测试用例生成的逻辑正确性。
   - **创新点3：开发用于测试用例生成的多模型协作框架**：设计一个框架，让不同规模和类型的模型协作生成测试用例，以结合各模型的优势，提升生成质量。

4. 为新的研究路径制定的研究方案：
   - **研究路径1：基于跨模块上下文的测试用例生成**
     - **研究方法**：从大型开源项目中提取跨模块的代码片段，构建包含跨模块上下文的测试数据集。设计包含跨模块信息的提示词，评估LLMs在生成跨模块测试用例时的表现。
     - **研究步骤**：
       1. 数据集构建：选择包含复杂模块依赖关系的开源项目，提取跨模块函数及其调用关系。
       2. 提示词设计：在提示中加入模块间依赖信息，如调用链、全局变量等。
       3. 模型评估：使用TestBench的评估框架，增加对跨模块测试用例的覆盖率和缺陷检测能力的评估。
     - **期望成果**：证明跨模块上下文能够显著提升测试用例的覆盖率和逻辑正确性，提出适用于跨模块测试用例生成的最佳实践。

   - **研究路径2：引入语义增强的上下文表示**
     - **研究方法**：通过静态分析工具提取代码的语义信息（如控制流图、数据流图），并将其嵌入到上下文中，作为提示词的一部分进行测试用例生成。
     - **研究步骤**：
       1. 语义信息提取：使用工具（如AST解析器或数据流分析工具）提取函数的语义特征。
       2. 提示词优化：将语义信息转化为自然语言描述或结构化数据，嵌入到提示中。
       3. 实验验证：比较加入语义信息前后的生成效果，分析语义增强的上下文对生成质量的影响。
     - **期望成果**：开发出一种结合语义信息的上下文设计方法，显著提升测试用例的逻辑正确性和缺陷检测能力。

   - **研究路径3：开发用于测试用例生成的多模型协作框架**
     - **研究方法**：设计一个协作生成框架，利用小模型生成初始测试用例，大模型进行优化和修复，最后通过规则或专家模型进行验证。
     - **研究步骤**：
       1. 框架设计：定义多模型协作的流程，包括任务分配、结果整合和反馈机制。
       2. 实验设置：在TestBench数据集上测试协作框架的性能，比较单模型和多模型的生成效果。
       3. 性能优化：分析不同模型在协作中的表现，调整任务分配策略以优化生成质量。
     - **期望成果**：证明多模型协作能够结合各模型的优势，生成更高质量的测试用例，并提出适用于测试用例生成的协作框架设计原则。
:::

# Others

[arXiv-2024] TestBench: Evaluating Class-Level Test Case Generation Capability of Large Language Models

> | Resource | Info |
> | :---        |:--- |
> | Paper       | https://arxiv.org/abs/2412.05210 |
> | Code & Data | https://codearenaeval.github.io/ |
> | Public      | arXiv |
> | Date        | 2024 |


# Summary Overview

当前的代码LLM专注于合成正确的代码段，忽略了与人类偏好的对齐，在这些偏好中应从实际的应用程序场景中采样查询，并且模型生成的响应应满足人类偏好。为了解决上述问题，作者提出了 CodeArena。

![image.png](/static/img/1392099da779bcb072500b5016853d56.image.png)

# Main Content

**Contributions:**
1. We propose CodeArena comprised of 397 manually annotated samples, a comprehensive code evaluation benchmark for evaluating the alignment between the model-generated response and human preference, encompassing 7 major categories and 40 subcategories.
2. We introduce SynCode-Instruct, the large-scale synthetic code instruction corpora from the website. Based on SynCode-Instruct, an effective coder Qwen2.5-SynCoder is used as a strong baseline for CodeArena.
3. We systematically evaluate 40+ LLMs on CodeArena and create a leaderboard to dynamically update the results. Notably, extensive experiments suggest that CodeArena can effectively measure the alignment between the model-generated response and human preference.

**Dataset Statistics:**

![image.png](/static/img/3c7af6981685192a626ef58cc04d8f65.image.png)

![image.png](/static/img/251a59253bf25d5509a224f6c45b7faf.image.png)

![image.png](/static/img/4ef134537cba3992c563bf94574850e6.image.png)

![image.png](/static/img/6d9018b3c3cb8570591bf1660d23ad5a.image.png)

**Prompt:**

![image.png](/static/img/d13a94cf998b676c1370ae646c56ab63.image.png)

**Results:**

![image.png](/static/img/246d9410f1d7020da2dc7ddb7b88ed5b.image.png)

**Examples:**

![image.png](/static/img/bbfcca2c01a90ac9e6df17b19b73b7b2.image.png)

**Distribution of different benchmarks:**

We visualize the quries of CodeArena and MultiPL-E(Python, Java, and CPP) by extracting the encoder representations of the last layer for t-SNE.

![image.png](/static/img/1cb76ba2682583df4a31ba54230effdf.image.png)

# 🤖ChatGPT

:::info{title="ChapGPT"}
1. 论文的创新之处与独特性：
   - **提出了CodeArena基准**：CodeArena是一个人类精心设计的高质量基准，包含397个样本，涵盖40个类别和44种编程语言，专注于评估代码生成模型与人类偏好的对齐程度。这一基准填补了现有代码基准测试（如HumanEval、MBPP等）仅关注代码正确性的不足，强调了人类偏好的重要性。
   - **引入SynCode-Instruct数据集**：作者通过从网络上扩展指令，构建了一个包含近200亿标记的大规模合成指令数据集。通过该数据集训练的Qwen2.5-SynCoder模型在CodeArena和传统代码生成基准上的表现均达到开源模型的领先水平。
   - **系统评估了40多个LLM的性能**：论文对40多个大语言模型（包括开源和闭源模型）的表现进行了全面评估，揭示了开源模型（如Qwen-Coder）与闭源模型（如Claude系列、o1）的显著性能差距，凸显了人类偏好对齐的重要性。
   - **创新的评价方法**：通过“LLM-as-a-judge”（使用GPT-4o作为评估者）进行对比评估，避免了传统基准测试中单纯依赖代码执行的局限性，更贴近真实使用场景下的人类需求。

2. 论文中存在的问题及改进建议：
   - **数据集规模有限**：尽管CodeArena覆盖了40个类别，但样本数量仅为397，这对于评估模型在更广泛场景中的泛化能力可能不足。建议进一步扩展数据集规模，尤其是增加更多真实用户查询的样本。
   - **对齐方法的细节不足**：论文虽然强调了人类偏好对齐的重要性，但未提供关于如何高效对齐模型生成的详细技术细节。可以补充更具体的对齐方法，例如基于RLHF（人类反馈强化学习）的优化策略。
   - **缺乏对多模态代码生成的研究**：当前研究主要集中在单一文本到代码的生成任务上，而未涉及多模态输入（如图像、表格、文本结合）的代码生成任务。建议在未来的研究中探索多模态代码生成的潜力。
   - **模型性能的解释性不足**：论文主要关注模型的性能比较，但缺乏对模型生成结果的详细分析和解释，尤其是模型为何在某些任务上表现优异或不足的原因分析。

3. 基于论文的内容和研究结果，提出的创新点或研究路径：
   - **创新点1：构建多模态代码生成基准**：设计一个包含文本、图像、表格等多模态输入的代码生成基准，用于评估模型在复杂场景中的代码生成能力。
   - **创新点2：开发高效的人类偏好对齐方法**：基于RLHF或其他对齐技术，开发一种高效的训练方法，使得代码生成模型能够更好地满足人类偏好。
   - **创新点3：探索模型生成结果的解释性**：设计一种分析框架，深入研究不同模型在生成代码时的决策过程，揭示其性能差异的原因。

4. 为新的研究路径制定的研究方案：
   - **研究路径1：构建多模态代码生成基准**
     - **研究方法**：
       1. 收集多模态数据：从开源项目、技术文档和问答社区中提取包含文本、图像、表格等多模态信息的代码相关问题。
       2. 标注数据：对问题进行分类，明确每个问题的输入模态和目标输出。
       3. 设计基准测试：创建多模态任务，包括代码生成、优化和解释等。
     - **研究步骤**：
       1. 数据收集与清洗：确保数据质量并去重。
       2. 数据标注与分类：根据任务类型和输入模态对数据进行标注。
       3. 模型评估：使用现有的多模态模型（如CodeT5、ImageBind等）在基准上进行测试。
     - **期望成果**：
       1. 一个公开的多模态代码生成基准测试数据集。
       2. 对现有模型在多模态任务上的性能评估报告。
       3. 提出改进多模态代码生成的方向。

   - **研究路径2：开发高效的人类偏好对齐方法**
     - **研究方法**：
       1. 基于RLHF的对齐优化：通过人类反馈强化学习对模型生成结果进行优化。
       2. 数据增强：利用合成数据扩充偏好对齐训练数据集。
       3. 交互式学习：设计用户交互界面，收集更多人类偏好数据。
     - **研究步骤**：
       1. 构建RLHF训练框架：包括奖励模型和优化算法。
       2. 设计实验：比较不同对齐方法的效果。
       3. 模型微调：在CodeArena和其他基准上验证对齐方法的有效性。
     - **期望成果**：
       1. 一种高效的偏好对齐训练方法。
       2. 一个包含人类反馈的高质量对齐数据集。
       3. 提高模型在CodeArena等基准上的表现。

   - **研究路径3：探索模型生成结果的解释性**
     - **研究方法**：
       1. 设计生成分析工具：对模型生成的代码进行语义分析和结构分析。
       2. 引入可解释性指标：量化模型生成结果的可解释性。
       3. 比较不同模型的决策过程：揭示模型在生成代码时的逻辑。
     - **研究步骤**：
       1. 开发分析工具：包括代码语法分析器和语义匹配工具。
       2. 设计实验：比较不同模型在生成代码时的可解释性。
       3. 优化模型：通过分析结果改进模型生成逻辑。
     - **期望成果**：
       1. 一个用于代码生成分析的工具包。
       2. 可解释性指标的定义及其在模型评估中的应用。
       3. 提高模型生成代码的透明性和用户信任度。
:::

# Others

[arXiv-2024] Evaluating and Aligning CodeLLMs on Human Preference

> | Resource | Info |
> | :---        |:--- |
> | Paper       | https://arxiv.org/abs/2412.11990 |
> | Code & Data | https://execrepobench.github.io/ |
> | Public      | arXiv |
> | Date        | 2024 |


# Summary Overview

本文主要提出了 ExecRepoBench 和指令数据集 RepoInstruct。

ExecRepoBench 包括了1.2K个从活跃的 Python 仓库中抽取的样本。提出了一个基于多级语法的完成方法，该方法在抽象语法树上进行了调节，以掩盖各种逻辑单元（例如语句，表达式和函数）的掩盖代码片段。

![image.png](/static/img/0bc3842e9a8189835c5806bad60d1dc1.image.png)
# Main Content

> *However, the community still lacks an executable evaluation reposity-level benchmark from live repositories and the corresponding instruction corpora.*

ExecRepoBench 构建单元测试，以验证完成代码的正确性，该代码包含来自50个活动 Python 存储库中的1.2K样本。基于多级语法的完成来创建repoinstruct，其中在不同级别的逻辑单元下的代码片段被掩盖，以使用解析的抽象语法树（AST）完成。

![image.png](/static/img/1aa5decc5517b41e2497f7de637c5092.image.png)

## ExecRepoBench Contruction

**Data Collection and Annotation:**
1. Search Github code repositories of the Python language that have been continuously updated.
2. Given the collected repositories, the annotator should collect or create the test cases for evaluation.
3. All collected repositories should pass the test cases in a limited time for fast evaluation (<2 minutes).

**Decontainmation:**

To avoid data leakage, we remove exact matches (20-gram word overlap) from CrossCodeEval and the pretraining corpus stack V2.

![image.png](/static/img/96c9a670f56ea68ea9a11ca107a59949.image.png)

![image.png](/static/img/3057622c9c737e002a966284e3a3b7d2.image.png)

**Completion:**
- Problem Defintion
    - In-file Completion
    - Reposity-level Completion
- Multi-level Grammar-based Completion
    - Expression-level Completion
    - Statement-level Completion
    - Function-level Completion

## Qwen2.5-Coder-Instruct-C

$$
\mathcal{L}_c = -\frac{1}{K} \sum_{k=1}^K \mathbb{E}_{x_p^{L_k}, x_m^{L_k}, x_s^{L_k} \in D_x^{L_k}} 
\left[ P(x_m^k \mid x_p, x_s, z; \mathcal{M}) \right]
$$

$$
\mathcal{L}_{qa} = -\frac{1}{K} \sum_{k=1}^K \mathbb{E}_{a^{L_k}, q^{L_k} \in D_{q,a}^{L_k}} 
\log P(q^{L_k} \mid a^{L_k}; \mathcal{M})
$$

$$
\mathcal{L}_{all}=\mathcal{L}_{c}+\mathcal{L}_{qa}
$$

# Experiments

## Metrics

- Edit Similarity
- Pass@k

## Results

![image.png](/static/img/1bcc193551609ac0f0a3b36b5419a071.image.png)

![image.png](/static/img/14b928d68f5b0015dceb7f1eba507f1a.image.png)
## Case Study

![image.png](/static/img/c30255a0c9c852d73e5d96a166ef6585.image.png)

# 🤖ChatGPT

:::info{title="ChapGPT"}
1. 论文的创新之处与独特性：
   - **全新的可执行代码补全评估基准（EXECREPOBENCH）**：论文提出了一个基于真实代码库的评估基准 EXECREPOBENCH，区别于传统的静态评估方法，该基准通过单元测试验证代码补全的正确性，真实反映代码补全模型在实际开发中的表现。
   - **多层次语法驱动的代码补全方法**：通过基于抽象语法树（AST）的多层次掩码策略（表达式级、语句级、函数级等），改进了代码补全任务的细粒度性和上下文依赖性。
   - **针对大规模开源模型的定制优化**：论文基于开源大模型 Qwen2.5-Coder，通过混合指令调优（Hybrid Instruction Tuning），结合代码补全和问答任务，提出了性能优异的 Qwen2.5-Coder-Instruct-C 模型。
   - **多语言支持与强大的跨语言性能**：模型在 EXECREPOBENCH 和 MultiPL-E 等基准上展现了跨语言的优秀性能，尤其在 Pass@1 指标上显著优于其他同类模型。
   - **强调执行结果的指标**：论文指出传统基于字符串匹配的指标（如 Edit Similarity）存在局限性，提出以代码可执行性为核心的 Pass@k 指标更能反映模型实际能力。

2. 论文中存在的问题及改进建议：
   - **多语言场景的覆盖不足**：尽管模型在多语言评估中表现良好，但论文主要集中于 Python，其他语言（如 JavaScript、C++）的评估样本较少，未能全面验证模型在复杂多语言代码库中的表现。
     - 改进建议：扩展 EXECREPOBENCH 的多语言代码库，增加多语言代码的单元测试覆盖率，进一步验证模型在多语言场景下的泛化能力。
   - **未充分探索模型的生成错误类型**：论文主要关注生成代码的正确性，但未深入分析模型生成错误的具体类型（如逻辑错误、语法错误）。
     - 改进建议：对生成错误进行分类统计，结合错误分析优化模型的训练目标，例如引入基于错误类型的权重调整或对常见错误场景进行强化学习。
   - **缺乏对用户体验的优化探索**：论文提出模型可用于本地开发服务，但未深入探讨其在实际开发环境中的用户体验（如响应速度、交互性）。
     - 改进建议：设计用户调研或与 IDE 集成的实验，评估模型在真实开发场景中的使用效果，并针对用户反馈进行优化。
   - **模型优化方法的局限性**：论文主要采用监督微调（SFT）和混合指令调优，未探索诸如强化学习（RLHF）等方法的潜力。
     - 改进建议：结合用户反馈或自动化测试结果，采用基于强化学习的模型优化方法，进一步提升模型的实际表现。

3. 基于论文的内容和研究结果，提出的创新点或研究路径：
   - **创新点 1：多语言动态依赖解析与代码补全**  
     在复杂代码库中，动态依赖解析是一个关键问题。设计一个能够自动解析多语言代码库中跨文件依赖关系并利用其进行上下文感知补全的模型。
   - **创新点 2：基于错误类型的自适应训练方法**  
     针对代码补全生成的错误类型（如语法错误、逻辑错误等），设计一种自适应训练方法，通过错误分类权重调整模型的学习目标。
   - **创新点 3：实时交互式代码补全与调试系统**  
     开发一个实时交互式代码补全与调试系统，结合模型生成与单元测试结果，实时为开发者提供代码建议和错误修复。

4. 为新的研究路径制定的研究方案：
   - **研究路径 1：多语言动态依赖解析与代码补全**
     - **研究方法**：
       1. 构建多语言代码库，涵盖 Python、JavaScript、C++ 等主流语言，标注跨文件依赖关系。
       2. 使用图神经网络（GNN）建模代码库的依赖关系图，捕获跨文件的上下文信息。
       3. 将依赖关系图嵌入到代码补全模型中，结合语法树（AST）进行上下文感知的代码生成。
     - **研究步骤**：
       1. 数据准备：扩展 EXECREPOBENCH，收集多语言代码库并标注依赖关系。
       2. 模型设计：设计结合 GNN 和 AST 的代码补全模型。
       3. 模型训练与评估：在扩展后的 EXECREPOBENCH 上训练模型，使用 Pass@k 和执行结果验证性能。
     - **期望成果**：
       提出一种支持多语言动态依赖解析的代码补全方法，显著提升模型在跨文件依赖场景下的补全准确性。

   - **研究路径 2：基于错误类型的自适应训练方法**
     - **研究方法**：
       1. 对现有代码补全数据进行错误分类标注，区分语法错误、逻辑错误等。
       2. 设计一种基于错误类型的损失函数，动态调整模型对不同错误类型的关注权重。
       3. 引入强化学习（RLHF），结合用户反馈优化模型生成质量。
     - **研究步骤**：
       1. 数据标注：对 EXECREPOBENCH 和其他公开数据集中的生成错误进行分类。
       2. 模型训练：设计基于错误类型的自适应损失函数，并进行模型训练。
       3. 用户评估：结合用户调研和实验评估模型对不同错误类型的改进效果。
     - **期望成果**：
       提出一种基于错误类型的自适应训练方法，显著降低模型生成错误率，提高代码补全的准确性和实用性。

   - **研究路径 3：实时交互式代码补全与调试系统**
     - **研究方法**：
       1. 设计一个 IDE 插件，集成代码补全模型和单元测试模块。
       2. 开发实时交互功能，允许开发者对生成代码进行反馈并实时更新模型建议。
       3. 利用强化学习优化模型的交互性能，提升用户体验。
     - **研究步骤**：
       1. 系统设计：开发一个结合代码补全与单元测试的 IDE 插件。
       2. 用户实验：邀请开发者参与实验，收集使用反馈。
       3. 模型优化：基于用户反馈和测试结果，使用 RLHF 优化模型性能。
     - **期望成果**：
       开发一个实时交互式代码补全与调试系统，显著提升开发者的生产力和模型的实际应用价值。
:::

# Others

[arXiv-2024] ExecRepoBench: Multi-level Executable Code Completion Evaluation

> | Resource | Info |
> | :---        |:--- |
> | Paper       | https://arxiv.org/abs/2412.08905 |
> | Code & Data | / |
> | Public      | arXiv |
> | Date        | 2024.12.17 |


# Summary Overview

这篇是 Phi-4 的技术报告，将模型训练分为了三个阶段 (Pretraining, Midtraining, Post-Training)，主要聚焦在各个阶段的数据构造和配比，并且在 Post-Training 阶段提出了用于构造 DPO 对的新技术 pivotal token search。

> phi-4 strategically incorporates synthetic data throughout the training process.


![image.png](/static/img/6a55a4968f717237f5980c2c65fa7081.image.png)

![image.png](/static/img/1b42967c2826580bf2d856716e42f568.image.png)
# Main Content

Rather than serving as a cheap substitute for organic data, synthetic data has several direct advantages over organic data.

**Principles.** Our approach to generating synthetic data fo phi-4 is guided by the following principles:

1. **Diversity:** The data should comprehensively cover subtopics and skills within each domain. This requires curating diverse seeds from organic sources.
2. **Nuance and Complexity:** Effective training requires nuanced, non-trivial examples that reflect the complexity and the richness of the domain. Data must go beyond basics to include edge cases and advanced examples.
3. **Accuracy:** Code should execute correctly, proofs should be valid, and explanations should adhere to established knowledge, etc.
4. **Chai-of-Thought:** Data should encourage systematic reasoning, teaching the model various approaches to the problems in a step-by-step manner. This fosters coherent outputs for complex tasks.

**Targeting High-quality Web Data**
- Targeted Acquisitions
- Filtering Web Dumps
- Multilingual Data
- Custom Extraction and Cleaning Pipelines

**Two key observations**
- Web datasets showed small benefits on reasoning heavy benchmarks. Prioritizing more epochs over our synthetic data led to better performance with respect to adding fresh web tokens.
- Models trained only with synthetic data underperformed on the knowledge-heavy benchmarks and demonstrated increased hallucinations.

### Pivotal Token Search

![image.png](/static/img/a2163090806078578833b18741a8d210.image.png)


![image.png](/static/img/247d730b6eabe40dfb2ed6dd7ef98e05.image.png)

Pivotal Token Search (PTS) 是一种用于生成偏好数据的技术，旨在识别生成序列中对模型成功率具有关键影响的“关键性”令牌（pivotal tokens）。这一方法通过分析模型在生成每个令牌时的正确率变化，找到那些对生成结果有显著影响的令牌，并将其用于优化模型的偏好学习流程（如 Direct Preference Optimization, DPO）。

背景与动机

在生成任务中，部分令牌对最终结果的正确性有着决定性作用，而其他令牌的影响则较小甚至会引入噪声。例如，在数学推导或编码任务中，某些关键步骤的输出可能会显著改变问题解决的方向。这些关键令牌被称为“pivotal tokens”。PTS 的目标是：

- 识别这些关键令牌，并生成能够突出它们影响的数据。
- 减少噪声：避免非关键令牌对优化过程的干扰。
- 提高训练效率：通过聚焦关键令牌，增强模型在推理和问题解决中的表现。

![image.png](/static/img/1ed3d8910d261d496e680530d06a3fe6.image.png)

# 🤖ChatGPT

:::info{title="ChapGPT"}
1. 论文的创新之处与独特性：
   - **数据质量优先的训练策略**：论文强调通过高质量的合成数据来提升模型性能，尤其是在推理和问题解决任务上的表现。这种策略展示了在计算资源有限的情况下，通过优化数据质量而非单纯扩大模型规模也能取得显著提升。
   - **合成数据的多样化生成方法**：引入了多代理提示（multi-agent prompting）、自我修订（self-revision）和指令反转（instruction reversal）等创新方法，生成高复杂度和多样化的合成数据，尤其适用于推理和问题解决任务。
   - **后训练阶段的优化技术**：论文提出了基于拒绝采样（rejection sampling）和关键标记搜索（Pivotal Token Search, PTS）的直接偏好优化（DPO）方法。这些技术显著提高了模型在数学、代码等推理密集型任务上的表现。
   - **高效的小模型性能**：Phi-4 模型在多个推理相关基准测试中表现优异，甚至超越了其教师模型 GPT-4o 和一些更大规模的模型（如 Llama-3.3-70B），证明了小规模模型通过优化数据和训练策略可以实现性能突破。
   - **去污染与新鲜数据验证**：论文在数据去污染和新鲜测试集（如 AMC-10/12 数学竞赛测试集）上采取了严格措施，确保评估的公平性和可靠性。

2. 论文中存在的问题及改进建议：
   - **指令遵从性不足**：Phi-4 在严格遵循复杂指令（如特定格式要求、表格输出等）方面表现较差。这可能是因为训练数据中过于注重推理类任务，而忽略了指令遵从能力。改进建议：
     - 在训练数据中增加针对复杂指令的合成数据。
     - 设计专门的后训练阶段，优化模型在指令遵从任务上的表现。
   - **对知识型任务的局限性**：尽管模型在推理任务上表现出色，但在知识密集型任务（如 IFEval 和 SimpleQA）上表现不佳，可能与合成数据的知识覆盖面不足有关。改进建议：
     - 增加高质量的知识型数据（如百科全书、领域知识文档）作为训练数据的补充。
     - 在合成数据生成中加入更多涉及知识推理的任务。
   - **冗长回答问题**：由于模型在链式推理（chain-of-thought）任务中训练较多，Phi-4 在简单问题上也可能给出冗长的回答，影响用户体验。改进建议：
     - 在后训练阶段加入任务权重调整，优化模型对简单问题的简洁回答能力。
     - 设计用户交互式调节机制，允许用户选择回答的详细程度。
   - **事实幻觉问题**：模型在回答未知问题时可能生成虚假的内容（如编造人物传记）。改进建议：
     - 在后训练阶段进一步加强拒绝回答（refusal to hallucinate）的能力。
     - 增加检索增强机制（如集成搜索引擎）以减少幻觉。

3. 基于论文的内容和研究结果，提出的创新点或研究路径：
   - **研究路径 1**：开发更高效的合成数据生成技术，专注于多语言环境中的推理任务。
   - **研究路径 2**：探索关键标记搜索（PTS）在其他领域（如多模态模型、长上下文模型）中的应用。
   - **研究路径 3**：针对小模型的知识增强任务，结合知识图谱和检索增强方法，提升知识型任务的表现。

4. 为新的研究路径制定的研究方案：
   - **研究路径 1：高效合成数据生成技术**
     - **研究目标**：设计一种新的合成数据生成框架，支持多语言推理任务的数据生成。
     - **研究方法**：
       1. 从多语言语料库中提取高质量种子数据，涵盖不同语言的逻辑推理、数学问题和知识问答。
       2. 使用多代理提示和自我修订技术生成多语言合成数据，并确保数据的多样性和复杂性。
       3. 设计多语言推理基准测试，评估生成数据对模型性能的提升效果。
     - **期望成果**：
       1. 一套高效的多语言合成数据生成工具。
       2. 提升小模型在多语言推理任务上的性能。
       3. 推动多语言领域的推理研究。

   - **研究路径 2：关键标记搜索在多模态模型中的应用**
     - **研究目标**：将关键标记搜索（PTS）技术扩展到多模态模型的训练和优化中，提升跨模态推理能力。
     - **研究方法**：
       1. 在多模态任务（如图像-文本匹配、视频问答）中定义“关键标记”。
       2. 设计基于 PTS 的数据生成与优化流程，生成关键标记对模型性能有显著影响的多模态数据。
       3. 通过实验验证 PTS 在多模态任务中的有效性，并与传统优化方法进行对比。
     - **期望成果**：
       1. 一种适用于多模态任务的关键标记搜索技术。
       2. 提升多模态模型在复杂推理任务中的表现。
       3. 为多模态数据优化提供新的思路。

   - **研究路径 3：结合知识图谱的知识增强**
     - **研究目标**：通过结合知识图谱和检索增强方法，提升小模型在知识型任务（如 IFEval 和 SimpleQA）上的表现。
     - **研究方法**：
       1. 构建一个高质量的知识图谱，涵盖广泛领域的实体和关系。
       2. 在训练中引入知识图谱增强机制，使模型能够从知识图谱中检索相关信息并整合到回答中。
       3. 设计知识检索任务和基准测试，评估增强机制的效果。
     - **期望成果**：
       1. 一种结合知识图谱的小模型知识增强框架。
       2. 提升模型在知识型任务上的准确性和鲁棒性。
       3. 为小模型的知识推理能力提供新的解决方案。
:::

# Others

[arXiv-2024] Phi-4 Technical Report

> | Resource | Info |
> | :---        |:--- |
> | Paper       | https://arxiv.org/abs/2305.04207 |
> | Code & Data | https://github.com/FudanSELab/ChatTester/tree/main |
> | Public      | FSE |
> | Date        | 2024.12.16 |


# Summary Overview

尽管传统技术能够以合理的覆盖范围生成测试，但证明它们的可读性较低，而开发人员在实践中仍然无法直接采用。在这项工作中，我们执行了第一项经验研究，以评估ChatGpt（即，在代码生成和理解中具有出色表现的最具代表性的LLM之一）的能力。我们进一步提出了ChatTester，这是一种基于ChatGPT的新型单元测试生成方法，该方法利用ChatGPT来提高其生成的测试的质量。

# Main Content

**Unit test:**

- test prefix: 测试前缀通常是一系列方法调用语句或分配语句，旨在将 focal method 推向可测试状态。
- test oracle: 用作检查 focal method 当前行为是否满足预期的规范。

传统的单元测试生成技术利用基于搜索 (search-based)，基于约束 (constraint-based) 或基于随机的策略 (random-based)生成一套单元测试，其主要目标是最大化测试软件中的覆盖范围。

为了启用全面的评估，我们首先构建了1,000个Java焦点方法的数据集，每种方法以及完整且可执行的项目环境。我们合并了为每种焦点方法生成单元测试的CHATGPT，并分析生成测试的质量以回答以下四个研究问题。

- **RQ1 (Correctness): How is the correctness of the unit tests generated by ChatGPT?**
- **RQ2 (Sufficiency): How is the sufficiency of the unit tests generated by ChatGPT?**
- **RQ3 (Readability): How is the readability of the unit tests generated by ChatGPT?**
- **RQ4 (Usability): How can the tests generated by ChatGPT be used by developers?**

ChatTester包括初始测试生成器和迭代测试修改器。初始测试生成器将测试生成任务分解为两个子任务，通过（i）首先利用ChatGPT通过意图提示来理解焦点方法，然后（ii）利用ChatGPT与生成意图一起生成焦点方法的测试通过一代提示。然后，迭代测试修改器迭代地修复了初始测试生成器生成的测试中的汇编错误，该测试生成的测试遵循验证和固定范式以根据编译错误消息和其他代码上下文提示ChatGPT。

- **RQ5 (Improvement): How effective is ChatTester in generating correct tests compared to ChatGPT? How effective is each component in ChatTester?**
- **RQ6 (Generalization): How effective is ChatTester in improving the quality of generated tests when applied to other LLMs?**
- **RQ7 (Project-level Effectiveness): How effectiness is ChatTester when applied to the entire projects?**

## Study Setup

### Benchmark

**Project Collection:** 

Two criteria:

1. the project is under continuous maintenance (i.e., the project should have been updated as of January 1, 2023);
2. the project has at least 100 stars;
3. the project is built with Maven framework (for the ease of test executions) and it could be successfully compiled in our local environment

**Data Pair Collection:** 我们从185个Java项目中提取数据对。每个数据对均指焦点方法及其相应的测试方法。

Following steps:

1. Given a Java project, we first find all the test classes in the project. If a class contains at least one method annotated with `@Test`, we regard this classes as a test class and collect all the test methods in this test class.
2. We then find the corresponding focal method for each test method based on the file path and the class name matching.

### Basic Prompt Design

![image.png](/static/img/f1a824f56282c36874a4ac680c5b097e.image.png)

**Two parts:**
1. the natural language description part (i.e., NL part) that explains the task to ChatGPT.
2. the code context part (i.e., CC part) that contains the focal method and the other relevant code context.

![image.png](/static/img/0bd7a974f611e134abc042e815cf494f.image.png)

### Experimental Procedure

**RQ1: Correctness**

Three metrics:
1. syntactic correctness (whether the test could pass the syntax checker)
2. compilation correctness (whether the test could be successfully compiled)
3. execution correctness (whether the test could pass the execution)

**RQ2: Sufficiency**

1. the statement coverage of the test on the focal method
2. the branch coverage of the test on the focal method
3. the number of assertions in the test case

**RQ3 & RQ4: User study for readability and usability**

![image.png](/static/img/3d83661375682e0d8f88ceafbe947592.image.png)

## Study Results

![image.png](/static/img/7070131276df3fc1e796e713424a0d02.image.png)

![image.png](/static/img/56a660028bc3d2f4ca5fc8e04440428f.image.png)

![image.png](/static/img/ed81fd9a921574dd9c73f8c61f2382fb.image.png)

![image.png](/static/img/696f23a2d7cf6bf57d92e4108d79372a.image.png)

**Enlightenment: two directions**
1. to provide ChatGPT with deep knowledge about the code
2. to help ChatGPT better understand the intention of the focal method, so as to reduce its compilation errors and assertion errors, respectively

## Approach of ChatTester

![image.png](/static/img/22351b04f4b7c9c65cd89bce98c108a8.image.png)

### Initial Test Generator

1. first leveraging ChatGPT to understand the focal method via the intention prompt
2. then leveraging ChatGPT to generate a test for the focal method along with the generated intention via the generation prompt

![image.png](/static/img/d582b684c4d7dd1697499f437ac62f50.image.png)

### Iterative Test Refiner

1. first validating the generated test by compilinig it in a validation environment
2. second constructing a prompt based on the error message during compilation and the extra code context related to the compilation error

![image.png](/static/img/068af09dbe8693b48ae52975e1b40ed5.image.png)

**Iterative Prompt Constructor**
1. an EM parser that analyzes the error message about the compilation error
2. a code analyzer that extracts the additional code context related to the compilation error

- Error type
- Buggy location
- Buggy element

## Evluation Results

### RQ5

![image.png](/static/img/884bae05600d710af39d0e6049f59d20.image.png)

**Cost and number of iterations**

![image.png](/static/img/d04a3b586a21dfc61137b872a2cbcd62.image.png)

"＃Iteration"显示了迭代的数量；"＃Tests"显示了此迭代中仍在完善的测试数量；"＃Success Compilation"和"＃Passing Execution"分别显示了在当前迭代中成功编译和执行的测试数。

### RQ6

![image.png](/static/img/2f7e730a3d4e20806e2eaf1b919deaaa.image.png)

### RQ7
表10显示了ChatTester在每个项目中生成的测试以及所有基准生成的测试的说明覆盖范围（"SC"）和分支覆盖范围（"BC"）。

![image.png](/static/img/3479c36da88b61540c1a0193dfa2f181.image.png)

## Related Work

**LLMs for Test Generation**

一种典型的基于LLM（大语言模型）的测试生成技术类别主要将测试生成视为一个神经机器翻译问题[54, 73]（即，从目标方法到相应的测试前缀或测试断言），并在测试生成数据集上微调LLM。例如，AthenaTest [73] 在一个测试生成数据集上对BART [14] 进行微调，该数据集的输入是包含相关代码上下文的目标方法，而输出是完整的测试用例。我们的研究结果表明，ChatGPT在生成更高正确性和覆盖率的测试方面优于AthenaTest。

最近，随着指令调优LLM的快速发展，越来越多的测试生成技术通过合适的提示（prompt）利用指令化的LLM，而非微调模型[21, 22, 81]。例如，将复杂任务分解为更小的任务（如链式思维推理[80]和树式思维推理[85]）已被证明是有效的提示策略，这些也是启发ChatTester的高级理念。Nashid等人[53]提出了一种基于检索的提示构造策略，通过少样本查询Codex生成测试断言。而与他们的工作不同，我们的研究专注于零样本学习场景，生成包括测试前缀和测试断言在内的完整测试用例。

CODAMOSA [46] 通过使用Codex生成的测试来增强传统的基于搜索的技术，以帮助其在搜索过程中摆脱“平台期”。实际上，ChatTester可以与CODAMOSA形成互补关系，因为ChatTester旨在通过LLM为给定的目标方法生成一个测试，而CODAMOSA则通过结合LLM和基于搜索的算法为给定模块生成一组测试。因此，ChatTester可以在CODAMOSA的搜索过程中提供更高质量的测试作为种子。

LIBRO [43] 利用Codex为给定的错误报告生成测试。而与LIBRO不同，我们的研究专注于没有错误报告的测试生成场景。Li等人[48] 提出了差异化提示（differential prompts），通过ChatGPT生成导致失败的测试输入，该方法侧重于通过LLM生成测试输入，而我们的工作专注于生成包括测试输入和测试代码（例如测试前缀）在内的完整单元测试用例。

Ring System [42] 和 TestPilot [69] 也分别使用LLM进行测试生成和错误修复。Ring System采用单轮的方法，专注于特定的代码片段，而我们的工具ChatTester通过与LLM进行多轮对话的方式进行迭代优化，并引入额外的代码上下文以提高准确性。TestPilot与ChatTester在其反馈机制上有所不同，TestPilot通过目标方法搜索代码片段，而ChatTester从错误信息中提取并利用额外的上下文信息以改进测试生成。
# 🤖ChatGPT

:::info{title="ChapGPT"}
1. 论文的创新之处与独特性：
   - **首次系统性评估ChatGPT在单元测试生成中的能力**：论文通过大量实验（覆盖正确性、充分性、可读性和可用性）全面分析了ChatGPT生成单元测试的表现，为理解LLM在软件工程任务中的潜力提供了重要参考。
   - **提出ChatTester框架**：论文在发现ChatGPT生成测试存在准确性问题后，设计了ChatTester框架，通过初始测试生成器和迭代测试优化器两个模块显著提高了生成测试的正确性。这种利用LLM自身能力提升生成质量的思路具有启发性。
   - **通用性验证**：论文不仅在ChatGPT上验证了ChatTester的效果，还将其应用于开源LLM（如CodeLlama-Instruct和CodeFuse），显示了该方法的普适性。
   - **综合实验与用户研究**：论文结合自动化评估和用户研究，全面分析了生成测试的覆盖率、断言质量、可读性和开发者接受度，为未来研究提供了可靠的实验设计模板。
   - **明确提出改进LLM生成测试的两大方向**：即为LLM提供代码的深层知识以及帮助其更好地理解焦点方法的意图。这些方向为后续研究指明了路径。

2. 论文中存在的问题及改进建议：
   - **对生成测试失败原因的分析深度不足**：虽然论文列举了错误类型，但对某些错误（如符号解析错误或断言错误）的深层次成因缺乏更具体的探讨。改进建议：结合ChatGPT的生成过程日志，分析错误生成的上下文和模式，从而更精准地定位问题。
   - **对迭代优化的终止条件设置较为简单**：论文中设置了固定的最大迭代次数，未深入探讨动态终止条件（如基于错误修复的收敛性）。改进建议：引入动态策略，例如基于错误类型的优先级或生成质量的实时评估，优化迭代效率。
   - **对用户研究的范围限制**：用户研究主要集中在Java开发者，且参与人数有限。改进建议：扩大参与者范围，涵盖更多编程语言和开发背景，同时引入更大规模的用户研究以提高结论的普适性。
   - **对生成测试的执行错误处理不足**：论文仅讨论了编译错误的修复，而未尝试优化执行错误的测试生成。改进建议：设计自动化的执行错误分析器，结合运行时信息生成更有效的修复提示。

3. 基于论文的内容和研究结果，提出的创新点或研究路径：
   - **创新点1：基于代码语义分析的深度上下文增强**  
     针对ChatGPT生成测试的符号解析错误和类型错误，开发一种结合代码语义分析的上下文扩展方法，动态为LLM提供更完整的代码依赖关系和类型信息。
   - **创新点2：多模态测试生成与验证框架**  
     将LLM生成的测试与动态分析工具（如符号执行或模糊测试）结合，通过多模态验证进一步提升生成测试的覆盖率和正确性。
   - **创新点3：基于用户反馈的自监督测试优化**  
     利用开发者对生成测试的评分和修改建议，设计一个自监督学习框架，让LLM通过持续学习改进测试生成能力。

4. 为新的研究路径制定的研究方案：
   - **研究路径1：基于代码语义分析的深度上下文增强**
     - **研究方法**：
       1. 开发一个代码语义分析模块，提取代码中的依赖关系、类型信息和访问权限。
       2. 将语义信息嵌入到LLM的提示中，动态调整生成测试的上下文。
       3. 比较增强后的LLM生成测试与原始测试在编译和执行正确性上的差异。
     - **研究步骤**：
       1. 收集多语言的代码和测试数据集（如Java、Python）。
       2. 实现语义分析模块并与ChatGPT集成。
       3. 设计实验评估生成测试的编译成功率、执行成功率和覆盖率。
     - **期望成果**：
       提出一种通用的上下文增强方法，显著降低生成测试的符号解析错误和类型错误。

   - **研究路径2：多模态测试生成与验证框架**
     - **研究方法**：
       1. 使用LLM生成初始测试，并通过动态分析工具验证其覆盖率和正确性。
       2. 将分析结果反馈给LLM，生成修正后的测试。
       3. 设计实验比较单一LLM生成与多模态框架生成的测试质量。
     - **研究步骤**：
       1. 选择一个动态分析工具（如Evosuite或Pynguin）。
       2. 构建一个多模态测试生成框架，集成LLM和动态分析工具。
       3. 在不同规模和领域的项目中评估框架性能。
     - **期望成果**：
       提出一种结合LLM与动态分析的多模态框架，提升测试生成的覆盖率和断言质量。

   - **研究路径3：基于用户反馈的自监督测试优化**
     - **研究方法**：
       1. 收集开发者对生成测试的评分和修改建议。
       2. 将用户反馈作为训练数据，微调LLM以改进生成能力。
       3. 设计实验验证优化后的LLM在用户满意度和测试质量上的提升。
     - **研究步骤**：
       1. 创建一个用户反馈收集平台，邀请开发者参与测试。
       2. 使用反馈数据微调LLM，优化生成策略。
       3. 比较优化前后LLM生成测试的可读性、可用性和开发者接受度。
     - **期望成果**：
       提出一种基于用户反馈的自监督优化框架，实现LLM对开发者需求的更高适配性。

:::

# Others