Code Quality Score

Code Quality Score 流程解析

流程图描述了 代码质量评分系统 的数据流和处理步骤，从代码变更到最终用户界面展示。

步骤 1：代码输入 (Code Changes)

• 节点 Start 表示开发者提交的 代码变更，可能是 新功能、修复或重构。
• 这些代码会被 Issue Collector LLM 处理。
  公式表示：
  $$C\in \text{Code Changes}$$

步骤 2：问题收集 (Issue Collector LLM)

• Collector LLM 会 扫描代码，发现潜在问题。
• 生成 问题详情 (Issue Details)：
  • 'File'：出现问题的文件路径
  • 'Line'：代码行号
  • 'Function'：所在函数或方法
  • 'Rationale'：问题原因解释
  • 'Tag'：问题分类，如风格、逻辑、性能等
    公式表示：
    $$Issues=Collector(C)$$
    其中：
    $$Issues=\text{File},\text{Line},\text{Function},\text{Rationale},\text{Tag}$$

步骤 3：问题验证 (Issue Validator LLM)

• Validator LLM 对 Collector 提出的每个问题 进行复核。
• 生成 验证结果 (Validation Results)：
  • 'Validity'：问题是否有效（valid/invalid）
  • 'Score'：评分，范围 1–10，用于量化问题严重性
    公式表示：
    $$Validation=Validator(Issues)$$
    $$Validation=Validity,Score$$

步骤 4：后处理与展示 (Post Processing → UI)

• Post Processing：
  • 聚合 Collector 和 Validator 数据
  • 计算最终 Code Quality Score
  • 可以生成 图表、表格或评分报告
• UI 展示：
  • 最终分数、问题列表和建议呈现给开发者
  • 支持团队决策和代码改进
    公式表示：
    $$QualityScore=f(Issues,Validation)$$
    $$\text{FinalReport}=Post(Issues,Validation)$$

整体流程公式化

1. 输入代码：
   $$C\to Collector(C)=Issues$$
2. 验证问题：
   $$Issues\to Validator(Issues)=Validation$$
3. 后处理：
   $$QualityScore,Report=Post(Issues,Validation)$$
4. 输出展示：
   $$UI(Report)$$

总结

• Collector LLM：检测潜在问题
• Validator LLM：验证问题并打分
• Post Processing：整合数据，生成最终评分
• UI：展示给用户，提高代码可维护性

Code Quality Score 流程解析：Issue Collector & Validator

这个系统由两个主要 LLM 代理组成：

1. Issue Collector Agent（问题收集代理）
2. Issue Validator Agent（问题验证代理）
   两者结合可以实现 代码变更质量评分与问题验证。

A. Issue Collector Agent（问题收集代理）

1. 模型信息

• 使用 Llama 3.1-70B
• 功能：
  1. 扫描代码差异 (diffs)
  2. 针对每个问题生成评分，包括：
     • readability（可读性）
     • complexity（复杂度）
     • modularity（模块化程度）
• 训练方式：SFT（Supervised Fine-Tuning）+ DPO（Direct Preference Optimization）

2. 系统指令（SYSTEM INSTRUCTION）

Collector Agent 的输入包括：

=-Raw Source Control Code Changes BEGIN
code changes go here
-Raw Source Control Code Changes END

• code changes go here：代码差异（新增/修改/删除）
• 用于提供 LLM 原始上下文

Context for the Code Change BEGIN ==
The following additional information from the author may provide context:
Title: title
Summary: summary of code changes
=== Context for the Code Change END

• 提供开发者的 上下文信息，便于 LLM 理解代码意图

3. 评分标准（Tags）

Collector 会针对每个潜在问题生成标签 (Tag) 和建议：

标签	含义
DedupeLogic	将重复逻辑抽象为共享函数（除了日志）
DictionaryKeyExistenceCheck	访问字典前检查 key 是否存在
UseConstant	用常量替代字面量，除非是常量定义
RenamingVariable	变量名应可读且有意图表达
DomainSpecificName	使用领域术语或算法名称
BreakdownLongFunction	将 >50 行函数拆分为小函数
ExtractMethod	将可提取的代码块提取为独立方法

---

注：每个问题都需要标明 function、file、line 位置。

4. 示例输出

{
  "function": "calculateScore",
  "rationale": "Function is too long, should be split into smaller functions",
  "file": "src/utils/score.py",
  "line": 120,
  "tag": "BreakdownLongFunction"
}

• function：问题所在函数
• rationale：问题解释及改进建议
• file：文件路径
• line：行号
• tag：问题类别

B. Issue Validator Agent（问题验证代理）

1. 模型信息

• 使用 Llama 3.1-70B
• 功能：验证 Collector 提出的每个问题的 正确性与评分

2. 输入

• 差异代码（diff view）
• Collector 输出的 问题列表

3. 验证流程

1. 检查问题有效性：
   • Issues 可能不准确，需要结合实际代码判断
   • 标记每个问题为 valid / invalid
2. 打分规则：
   • 高分（8-10）：解决重大 bug 或安全问题
   • 中分（3-7）：针对小问题，如代码风格、可读性、可维护性
   • 错误问题：评分为 0
3. 输出顺序：
   • 按输入的 issue 顺序返回评分和验证结果

公式化描述

• Collector 输出问题列表：
  $$Issues=issu{e}_1,issu{e}_2,...,issu{e}_n$$
  其中：
  $$issu{e}_i=function,file,line,tag,rationale$$
• Validator 验证和打分：
  $$Validatio{n}_i=Validator(issu{e}_i,cod{e}_{d}iff)$$
  $$Validatio{n}_i=Validity\in valid,invalid,Score\in [0,10]$$
• 最终质量评分：
  $$QualityScore=f(Issues,Validation)$$

函数 $f$ 可根据有效问题数量及其评分计算总体质量分。

4. 理解总结

1. Collector LLM：扫描代码变更，识别潜在问题，给出具体改进建议。
2. Validator LLM：复核每个问题的正确性，评分并过滤无效问题。
3. 评分逻辑：重大问题打高分，小问题打中分，无效问题打 0 分。
4. 最终输出：
   • 每个函数/文件的具体问题列表
   • 每个问题的评分
   • 用于 Code Quality Score 计算与展示

Issue Collector Agent Training S1 流程解析

这个流程描述了 如何训练 Llama 3.1-70B 模型 用于 收集代码问题 (Issue Collector)，特别是通过 人类注释+代码差异 来生成高质量“rationales（问题解释）”。

1. 流程概览

• TD 表示 从上到下 (Top Down) 的流程图
• 使用了三种节点样式：
  • document 文档类型节点（代码、注释、数据）
  • model 模型节点（LLM）
  • process 处理节点（训练、计算损失）

2. 流程分解

A. 输入阶段

• 输入数据：
  • 代码变更（diff）
  • 人类代码审查注释（comments）
• 作用：提供上下文给模型，用于学习识别问题

B. 提取阶段

• 从输入中提取结构化信息：
  • File：文件路径
  • Line：代码行号
  • Function：函数名
  • Rationale：问题解释
  • Tag：问题类型（如 DedupeLogic, ExtractMethod 等）
• 目的是把自由文本注释转成 机器可读的数据结构

C. 模型初步处理

• Llama 3.1-70B Instruct 模型
• 功能：
  1. 对人类注释进行评分（grade human comments）
  2. 重写注释为结构化的 rationales（rewrite into rationales）

D. 模型输出与过滤

• 输出的数据：
  • 高质量 rationales
  • 低质量评论会被过滤掉（过滤策略在后续 SFT 阶段使用）

E. 数据准备（SFT 训练输入）

• E：原始代码变更，作为输入
• F：模型训练目标（SFT targets）
  • 只包含 高质量的 rationales
  • 用于监督学习 (Supervised Fine-Tuning, SFT)

F. 训练阶段

• 训练目标：
  • 最小化 SFT loss
  • 输入：代码变更 E
  • 输出：高质量 rationales F
• 公式化表示：
  $$\text{Loss}\ast SFT=\frac{1}{N}\sum \ast {i=1}^N\text{CrossEntropy}(\text{model}(cod{e}_i),rationale{s}_i)$$
• 模型更新：
  • Llama 3.1-70B Instruct 模型 被微调以生成高质量问题解释

3. 流程总结

1. 输入：代码变更 + 人类评论
2. 提取：结构化注释信息
3. 初步处理：LLM 评分并生成 rationales
4. 过滤：去除低质量的注释
5. SFT训练：输入代码变更 + 高质量 rationales → 更新模型

最终目标：训练一个 高效的 Issue Collector LLM，能够自动识别代码问题并生成高质量建议。

Issue Collector Agent Training S2 流程解析

这个阶段主要是 DPO (Direct Preference Optimization) 微调阶段，在 SFT 阶段之后进一步优化模型，使其能够 更好地选择高质量 rationales。

1. 流程概览

• LR 表示 从左到右 (Left to Right) 的流程图
• 节点样式说明：
  • SFT checkpoint：蓝色节点，表示在 S1 阶段训练好的模型检查点
  • LLM-judge：绿色节点，用于评估输出质量
  • Preference pairs：粉色节点，DPO 使用的偏好对
  • DPO loss：蓝紫色节点，用于训练优化

2. 流程分解

A. 输入阶段：代码变更

• 输入：代码差异 (Code Changes)
• SFT checkpoint：在 S1 阶段训练得到的模型权重
• 作用：作为 DPO 的初始模型

B. 高温采样 (High Temperature Sampling)

• 原理：
  • 使用 高温采样 (temperature > 1) 来增加生成多样性
  • 模型生成 多种 candidate rationales
• 输出结构：
  • File：文件路径
  • Line：行号
  • Function：函数名
  • Rationale：问题解释
  • Tag：问题类型
• 公式表示高温采样概率分布：
  $$P_{\text{temp}}(x_i)=\frac{\exp (\frac{\log P(x_i)}{T})}{{\sum }_j\exp (\frac{\log P(x_j)}{T})},T>1$$

$T$ 越大，输出越多样化

C. 输出评估：LLM-judge

• LLM-judge 用于对生成的 rationales 排序和评估质量
• 功能：
  • 判断哪条 rationales 更合理
  • 提供 偏好对 (Preference pairs) 给 DPO

D. 生成偏好对 (Preference Pairs)

• 算法原理：
  • 对生成的多个 candidate rationales 两两比较
  • 生成一个偏好对 $(x_{\text{better}},x_{\text{worse}})$
• 这是 DPO 微调的核心输入
• 公式化表示：
  $$\text{PrefPairs}=(x_i,x_j)\mid \text{judge}(x_i)>\text{judge}(x_j)$$

E. DPO Loss 优化

• DPO Loss 用于优化模型，使其更倾向于选择高质量 rationales
• 损失函数公式：
  $$\mathcal{L}\ast \text{DPO}(\theta )=-\mathbb{E}\ast (x_{\text{better}},x_{\text{worse}})\sim D[\log \sigma (s_{\theta }(x_{\text{better}})-s_{\theta }(x_{\text{worse}}))]$$
• 其中：
  • $s_{\theta }(x)$：模型对 rationales $x$ 的评分
  • $\sigma$：sigmoid 函数
  • 目标：最大化模型对更好 rationales 的评分差异

3. S2 流程总结

1. 输入：代码变更 + SFT 模型
2. 高温采样：生成多样化 rationales
3. LLM-judge：对 rationales 打分，生成偏好对
4. DPO Loss：微调模型，使其偏好高质量 rationales
5. 目标：在 SFT 的基础上进一步提高模型生成 rationales 的质量和可用性

总结：S2 是 DPO 微调阶段，通过偏好学习 (preference learning) 来优化 SFT 模型，使得 Issue Collector LLM 能够生成更可靠、更专业的代码问题建议。

Issue Validator Agent Training 理解

这个训练流程的目标是 训练一个模型验证代码审查 (code review) 的质量，即 Issue Validator Agent。
与 Issue Collector 不同，它专注于对已有的 code review 进行评估、打分和筛选。

1. 流程概览

• TD 表示 从上到下 (Top to Down) 的流程
• 主要分为几个模块：
  1. 输入阶段：Code Changes + SFT checkpoint
  2. 生成代码审查：SFT 模型生成初步 review
  3. 开发者反馈：提供 critique 或 thumbs up/down
  4. 过滤与目标准备：筛选高质量反馈
  5. SFT 训练：微调模型以学习验证高质量 review

2. 流程分解

A. 输入阶段

• Code Changes：代码变更差异 (diffs)
• SFT checkpoint：预先训练好的模型权重（通常是 S1 或 S2 阶段 Issue Collector 的 checkpoint）
• 功能：作为 Issue Validator 的初始模型

B. 生成初步代码审查

• 模型输出 初步代码审查结果：
  • File：代码所在文件
  • Line：代码行号
  • Function：函数名
  • Rationale：问题分析说明
  • Tag：问题类型
• 本阶段对应 SFT (Supervised Fine-Tuning) 阶段的生成过程

C. 开发者反馈

• Critique：开发者提供对代码审查的文字反馈
• Thumbs Up/Down：开发者对 review 的评分（+1/-1）
• 作用：
  • 提供 偏好信号
  • 帮助模型识别哪些代码审查是高质量的
• 数据结构示例：

{
  "file": "src/main.py",
  "line": 42,
  "function": "compute_sum",
  "rationale": "Variable names are unclear",
  "tag": "RenamingVariable",
  "thumbs": +1
}

D. 模型处理反馈

• LLAMA_Instruct：LLM 模型处理开发者反馈
• 功能：
  • 过滤低质量反馈
  • 整合高质量反馈，形成训练目标
• 公式表示：
  $$\text{FilteredReview}=r_i\in \text{DeveloperFeedback}\mid \text{quality}(r_i)>\tau$$

其中 $\tau$ 是过滤阈值

E. SFT 训练目标准备

• SFT Targets：微调训练目标
• 输入：高质量 developer feedback
• 输出：模型需要学习的目标 rationales

F. SFT 训练过程

• 输入：
  1. Code changes
  2. 代码审查 (reviews)
  3. SFT Targets (开发者反馈)
• 训练目标：
  • 学习将模型生成的 review 与高质量 developer feedback 对齐
  • 提升模型 验证和评分 review 的能力
• SFT 损失函数：
  $$\mathcal{L}\ast \text{SFT}(\theta )=-\sum \ast {i=1}^N\log P_{\theta }({\text{target}}_i\mid {\text{input}}_i)$$

${\text{target}}_i$ 对应高质量 developer feedback，${\text{input}}_i$ 是代码及初步 review

• 训练模型：
  • LLAMA 3.1-70B Instruct 通过最小化 SFT 损失进行微调

G. 循环反馈

• 通过循环机制，将 高质量反馈回传，不断改进模型生成的 review
• 这是 强化学习式的迭代优化，确保模型越来越可靠

3. 样式说明

• 蓝色：模型 checkpoint
• 绿色：模型处理阶段
• 粉色：反馈/训练目标
• 蓝紫色：损失函数/训练过程

4. 总结

1. 输入代码变更 + SFT checkpoint
2. 生成初步代码审查
3. 开发者提供反馈（文字 + Thumbs）
4. LLM 过滤低质量反馈，生成 SFT Targets
5. SFT 微调：将模型生成的 review 与高质量反馈对齐
6. 循环优化：高质量反馈迭代更新训练数据

核心目标：训练 Issue Validator Agent 能够自动 评估、验证和评分代码审查的质量，为后续自动化 code review 提供可靠判断。
根据您上传的图片，我为您提取并转换成了两个对应的 Markdown 表格。

TABLE I: The features used in the logistic regression that is in production

---

Feature type	Feature used in Logistic Regression
Diff	• log of the added and deleted SLOC relative to size of file (ratio)
	• New files created by the diff (boolean)
	• Diff only creates new files (boolean)
Diffusion	• log of the number of files in this diff
	• log of the number of authors that modified changed files
Criticality	• Previous SEV in the file (boolean)
	• Previous SEV in the folder (boolean)
	• Is file involved in high-criticality service (boolean)
Expertise	• Programming is the original creator of the file
	• Number of diffs previously landed by the author

---

TABLE II: The features fed the LLMs during both training and inference for DRS

---

Feature type	Feature fed to the LLM
Diff Title	Title of the diff, typically a concise description of the code change in a few words
Test Plan	Commands (build, lint, tests) executed by author validate the code changes
Code changes	Filenames and the content of the diff

---

Diff Risk Score (DRS) 理解

Diff Risk Score (DRS) 用于 评估代码变更 (diff) 导致严重故障 (SEV, Severe Fault) 的可能性。

• SEV：严重影响最终用户的软件缺陷
• DRS 结合 统计特征 + LLM，用于预测代码变更风险
  核心思路：

1. 对 diff 特征进行 逻辑回归 (Logistic Regression) 评分
2. 对 diff、测试计划、代码内容等信息喂给 LLM 进行更高级评估

1. 逻辑回归特征（TABLE I）

A. Diff 特征

• 描述代码变更的 规模与新增文件情况

• log(新增/删除代码行数 / 文件总行数)  # 相对修改量
• 新建文件 (boolean)                 # 是否有新文件
• 仅创建新文件 (boolean)             # diff 仅新增文件

B. Diffusion 特征

• 描述代码变更 扩散范围

• log(本次 diff 涉及文件数量)
• log(修改这些文件的作者人数)

C. Criticality 特征

• 描述代码变更的 重要性

• 文件是否有历史 SEV (boolean)
• 文件所在目录是否有历史 SEV (boolean)
• 文件是否属于高关键性服务 (boolean)

D. Expertise 特征

• 描述作者经验与熟练度

• 作者是否为该文件原始创建者 (boolean)
• 作者之前提交的 diff 数量

2. LLM 输入特征（TABLE II）

---

特征类型	LLM 输入内容
Diff Title	代码变更标题，简明描述改动
Test Plan	作者执行的构建、lint、测试命令，用于验证代码变更
Code Changes	代码变更的文件名及具体内容

---

• 用途：
  • 在 训练和推理阶段，将这些信息喂给 LLM，让 LLM 学习预测该 diff 是否可能引入 SEV
  • LLM 可以理解代码逻辑、依赖关系和潜在风险

3. 数学公式表示（Logistic Regression 部分）

逻辑回归的目标是预测某个 diff 引入 SEV 的概率 $p$:
$$p=\sigma (\mathbf{w}\cdot \mathbf{x}+b)=\frac{1}{1+e^{-(\mathbf{w}\cdot \mathbf{x}+b)}}$$

• $\mathbf{x}$：特征向量，包含 Diff / Diffusion / Criticality / Expertise 等所有特征
• $\mathbf{w}$：对应特征的权重
• $b$：偏置项
• $\sigma$：Sigmoid 函数，将输出映射到 [0,1]，表示风险概率

若 $p>0.5$，预测该 diff 有较高 SEV 风险

4. 代码注释风格示例

# DRS 特征向量构造
features = {
    # Diff 特征
    "log_sloc_ratio": np.log(added_lines + deleted_lines) / file_total_lines,
    "new_file_created": bool(new_files),
    "only_new_files": bool(only_new_files),
    # Diffusion 特征
    "num_files_log": np.log(len(changed_files)),
    "num_authors_log": np.log(len(authors)),
    # Criticality 特征
    "prev_sev_file": bool(prev_sev_in_file),
    "prev_sev_folder": bool(prev_sev_in_folder),
    "high_critical_service": bool(is_high_critical_service),
    # Expertise 特征
    "is_creator": bool(is_original_creator),
    "author_past_diffs": num_past_diffs,
}
# Logistic Regression 预测 SEV 概率
risk_score = sigmoid(np.dot(weights, features) + bias)

• 这里 risk_score 就是 Diff Risk Score (DRS)
• 可以用于：
  • 提前标记高风险 diff
  • 提示 reviewer 优先关注

关键收获（Key Takeaways）解析

1. 前所未有的挑战与机遇
   • 当下软件开发正面临 极大挑战：如复杂代码库、交付压力、用户需求快速变化
   • 也是 前所未有的机遇：AI agent、LLM 等技术可以大幅提升开发效率和质量

# 表示软件开发现状
challenges = ["复杂代码库", "交付压力", "快速需求变化"]
opportunities = ["AI agents", "LLM自动化", "上下文驱动开发"]

2. Vibe Coding 与 AI Agent 已经到来，并将长期存在
   • Vibe Coding：强调 快速原型和迭代 的开发模式
   • AI Agent：可以自动生成代码、调试、优化、测试
   • 两者结合，可以 增强开发生产力

# AI Agent 长期价值
ai_agents_present = True
vibe_coding_present = True
long_term_trend = ai_agents_present and vibe_coding_present

3. AI Agent 成功依赖于现有代码库状态
   • 成功率、成本、交付时间都是关键指标
   • 如果代码库混乱或文档缺失，AI agent 的效果会大打折扣

• 例如：

# AI agent 成功依赖条件
code_base_quality = 0.85  # 0~1
delivery_speed = 0.7
cost_efficiency = 0.8
agent_success_rate = (code_base_quality + delivery_speed + cost_efficiency) / 3

4. 成功关键策略：上下文工程、工具、文档、记忆与自我反思
   • Context Engineering：提供 AI agent 足够上下文
   • Custom Tools：如 MCP 工具，处理特定任务
   • .md 文件：代码总结、类图、流程图，提高理解效率
   • Memory：会话跟踪、检查点、历史记录
   • Reflection：自我评估与迭代改进

# 成功 AI agent 的关键策略
success_strategies = {
    "context_engineering": True,
    "custom_tools": ["MCP", "Linters", "Compilers"],
    "md_files": True,
    "memory": True,
    "reflection": True,
}

5. AI Agent 可帮助提升代码质量、复杂度控制与可靠性
   • 通过 Diff Risk Score、Code Quality Score、自动测试生成 等机制
   • 可以在 大规模代码库 中保持 高质量、低缺陷、可维护性强

# AI agent 提升代码质量示例
code_quality = 0.75
ai_agent_improvement = 0.15
new_code_quality = code_quality + ai_agent_improvement

总结

• 当前软件开发环境既充满挑战也充满机遇
• AI Agent 已成为长期趋势
• 成功依赖 现有代码库质量 + 工具与上下文 + AI 自我优化机制
• 可大幅提升 质量、复杂度控制和可靠性