基于大模型与知识库的 Code Review 自动化实践

实现思路

流程图

完成一次 CR 流程，涉及从代码变更解析到最终评论发布的完整链路。

系统架构

完成一次 CR 流程，需要用到如下技术模块：

1. 代码变更解析：提取 Diff 信息。
2. 知识库检索：RAG 流程，检索相关文档。
3. 大模型推理：生成评审意见。
4. 结果反馈：发布至 GitLab。

LLMs / 开源大模型选型

CR Copilot 功能的核心在于大语言模型基座，基于不同大模型基座生成的 CR 质量也不尽相同。对于 CR 这个场景，我们需要选型的模型满足以下几个条件：

• 理解代码
• 对中文支持好
• 较强的上下文学习能力

FlagEval 8 月大模型评测榜单显示，参数量并非唯一决定因素。

起初在众多大模型选择中，尝试了 Llama2-Chinese-13b-Chat、chatglm2-6b、Baichuan2-13B-Chat。通过一段时间模型赛马，主观上感觉 Llama2 会更适用于 CR 场景，而 ChatGLM2 更像是文科生，对代码评审没有太多建设性建议，但在中文 AIGC 上会比较有优势！

因大模型合规问题，CR Copilot 会默认使用 ChatGLM2-6B，如有使用 Llama2 模型需求需要向 Meta 申请，通过后可使用。目前支持的模型可选，仅供参考的评分如下：

• chatglm2-6b（默认）
• Llama2-Chinese-13b-Chat（推荐）
• Baichuan2-13B-Chat

知识库设计

为什么需要知识库？

大模型基座只包含互联网上的公开数据，对公司内部的框架知识和使用文档并不了解。

举个例子：公司内有个框架叫 Lynx，让大模型从内部文档中知道『什么是 Lynx？』、『怎么写 Lynx？』

这里的『强化模式』会使用向量数据库，并将匹配的知识库片段和问题生成 Prompt，发送到 LLM 执行。

怎样找到相关度高的知识？

有了知识库后，怎样将我们『搜索的问题/代码』在『知识库』中找到『相关度最高的内容』？答案是通过三个过程：

1. Text Embeddings（文本向量化）
2. Vector Stores（向量存储）
3. Similarity Search（相似性搜索）

Text Embeddings（文本向量化）

不同于传统数据库的模糊搜索/匹配关键字，我们需要进行语义/特征匹配。

例如：你搜索『猫』，只能得到带『猫』关键字匹配的结果，没办法得到『布偶』、『蓝白』等结果。要实现关联语义搜索，是通过人工打特征标签，这个过程也被称为特征工程（Feature Engineering）。

如何才能将文本自动化的方式来提取这些特征？这就要通过 Vector Embedding 向量化实现。社区通常使用 OpenAI 提供的 text-embedding-ada-002 模型生成，但这会引起两个问题：

• 数据安全问题：需要调用 OpenAI 的 API 才能做向量化
• 收费：大概 3000 页/美元

我们使用了国产文本相似度计算模型 bge-large-zh，并私有化部署公司内网，一次 embedding 向量化耗时基本在毫秒级。

Vector Stores（向量存储）

提前将官方文档进行 Vector Embeddings，然后存储在向量数据库里。这里选择的向量数据库是 Qdrant，主要考虑到是用 Rust 写的，存储和查询也许会快一些！

向量数据库选型维度参考：

Similarity Search（相似性搜索）

原理是通过比较向量之间的距离来判断它们的相似度。

那么有了『query 问题的向量』和『数据库里录入的知识库向量』后，这可以直接使用向量数据库提供的 Similarity Search 方式匹配相关内容。

加载知识库

CR Copilot 知识库分为『内置官方文档知识库』、『自定义知识库』，query 输入是先用完整代码截取前半段 + LLM 生成 summary 总结，然后和知识库做相似上下文，匹配流程如下：

截取完整代码前半段作为 query 输入，是因为大部分语言前半段都声明了 modules、packages，通过这种方式提高知识库相似匹配度。

官方文档 - 知识库（内置）

避免大家将官方文档重复录入、embedding，CR Copilot 内置了官方文档，目录包含：

并通过一个简单的 CURD 来管理内置知识库。

自定义知识库 - 飞书文档（自定义）

飞书文档没有格式要求，能看懂正确代码是怎样就行。

这里直接使用 LangChain 提供的 LarkSuite 文档加载类，对有权限的飞书文档进行获取，使用 CharacterTextSplitter / RecursiveCharacterTextSplitter 将文本分割成固定长度的块（chunks），方法有两个主要参数：

• chunk_size: 控制每个块的长度。例如设置为 1024，则每个块包含 1024 个字符。
• chunk_overlap: 控制相邻两个块之间的重叠长度。例如设置为 128，则每个块会与相邻块重叠 128 个字符。

Prompt 指令设计

因为大模型有足够多的数据，我们想让大模型按要求执行就需要用到『Prompt 提示词』。

代码 summary 总结指令

让 LLM 通过文件代码分析当前代码涉及的知识点，用于后续知识库相似度匹配：

prefix = "user: " if model == "chatglm2" else "<s>Human: "   
suffix = "assistant(用中文): let's think step by step." if model == "chatglm2" else "\n</s><s>Assistant(用中文): let's think step by step."
      
return f"""{prefix}根据这段 {language} 代码，列出关于这段 {language} 代码用到的工具库、模块包。   
{language} 代码:   
```{language}
{source_code}

请注意：

• 知识列表中的每一项都不要有类似或者重复的内容
• 列出的内容要和代码密切相关
• 最少列出 3 个，最多不要超过 6 个
• 知识列表中的每一项要具体
• 列出列表，不要对工具库、模块做解释
• 输出中文
  {suffix}"""

其中：

- `language`：当前文件的代码语言（TypeScript、Python、Rust、Golang 等）
- `source_code`：是当前变更文件的完整代码

#### CR 指令

如果使用的模型（如 LLaMA 2）对中文 Prompt 支持较差，需要在设计 Prompt 时采用『输入英文』『输出中文』的方式，即：

```python
# llama2
f"""Human: please briefly review the {language}code changes by learning the provided context to do a brief code review feedback and suggestions. if any bug risk and improvement suggestion are welcome(no more than six)
<context>
{context}
</context>

<code_changes>
{diff_code}
</code_changes>
</s><s>Assistant: """

# chatglm2
f"""user: 【指令】请根据所提供的上下文信息来简要审查{language} 变更代码，进行简短的代码审查和建议，变更代码有任何 bug 缺陷和改进建议请指出（不超过 6 条）。
【已知信息】：{context}

【变更代码】：{diff_code}

assistant: """   

其中：

• language：当前文件的代码语言（TypeScript、Python、Rust、Golang 等）
• context：根据知识库返回的上下文信息
• diff_code：是变更的代码（不使用完整代码主要是考虑 LLM max_tokens 最大限制）

评论到变更代码行

为了能计算出变更代码行，写了一个函数，通过解析 diff 来输出变更的行数：

import re

def parse_diff(input):
    if not input:
        return []
    if not isinstance(input, str) or re.match(r'^\s+$', input):
        return []

    lines = input.split("\n")
    if not lines:
        return []

    result = []
    current_file = None
    current_chunk = None
    deleted_line_counter = 0
    added_line_counter = 0
    current_file_changes = None

    def normal(line):
        nonlocal deleted_line_counter, added_line_counter
        current_chunk["changes"].append({
            "type": "normal",
            "normal": True,
            "ln1": deleted_line_counter,
            "ln2": added_line_counter,
            "content": line
        })
        deleted_line_counter += 1
        added_line_counter += 1
        current_file_changes["old_lines"] -= 1
        current_file_changes["new_lines"] -= 1

    def start(line):
        nonlocal current_file, result
        current_file = {
            "chunks": [],
            "deletions": 0,
            "additions": 0
        }
        result.append(current_file)

    def to_num_of_lines(number):
        return int(number) if number else 1

    def chunk(line, match):
        nonlocal current_file, current_chunk, deleted_line_counter, added_line_counter, current_file_changes
        if not current_file:
            start(line)
        old_start, old_num_lines, new_start, new_num_lines = match.group(1), match.group(2), match.group(
            3), match.group(4)

        deleted_line_counter = int(old_start)
        added_line_counter = int(new_start)
        current_chunk = {
            "content": line,
            "changes": [],
            "old_start": int(old_start),
            "old_lines": to_num_of_lines(old_num_lines),
            "new_start": int(new_start),
            "new_lines": to_num_of_lines(new_num_lines),
        }
        current_file_changes = {
            "old_lines": to_num_of_lines(old_num_lines),
            "new_lines": to_num_of_lines(new_num_lines),
        }
        current_file["chunks"].append(current_chunk)

    def delete(line):
        nonlocal deleted_line_counter
        if not current_chunk:
            return

        current_chunk["changes"].append({
            "type": "del",
            "del": True,
            "ln": deleted_line_counter,
            "content": line
        })
        deleted_line_counter += 1
        current_file["deletions"] += 1
        current_file_changes["old_lines"] -= 1

    def add(line):
        nonlocal added_line_counter
        if not current_chunk:
            return
        current_chunk["changes"].append({
            "type": "add",
            "add": True,
            "ln": added_line_counter,
            "content": line
        })
        added_line_counter += 1
        current_file["additions"] += 1
        current_file_changes["new_lines"] -= 1

    def eof(line):
        if not current_chunk:
            return
        most_recent_change = current_chunk["changes"][-1]
        current_chunk["changes"].append({
            "type": most_recent_change["type"],
            most_recent_change["type"]: True,
            "ln1": most_recent_change["ln1"],
            "ln2": most_recent_change["ln2"],
            "ln": most_recent_change["ln"],
            "content": line
        })

    header_patterns = [
        (re.compile(r"^@@\s+-(\d+),?(\d+)?\s++(\d+),?(\d+)?\s@"), chunk)
    ]

    content_patterns = [
        (re.compile(r"^\ No newline at end of file$"), eof),
        (re.compile(r"^-"), delete),
        (re.compile(r"^+"), add),
        (re.compile(r"^\s+"), normal)
    ]

    def parse_content_line(line):
        nonlocal current_file_changes
        for pattern, handler in content_patterns:
            match = re.search(pattern, line)
            if match:
                handler(line)
                break
        if current_file_changes["old_lines"] == 0 and current_file_changes["new_lines"] == 0:
            current_file_changes = None

    def parse_header_line(line):
        for pattern, handler in header_patterns:
            match = re.search(pattern, line)
            if match:
                handler(line, match)
                break

    def parse_line(line):
        if current_file_changes:
            parse_content_line(line)
        else:
            parse_header_line(line)

    for line in lines:
        parse_line(line)

    return result

这里机器人账号调用 Gitlab API 进行的评论，会默认被 Resolved，这样可以避免 CR Copilot 评论过多造成每个评论要手动点下 Resolved。

运维与优化建议

在实际落地过程中，除了核心功能实现，还需关注以下方面以确保系统的稳定性和可用性：

1. 缓存策略：对于相同的代码变更或类似的上下文，应建立缓存机制，减少重复的 LLM 调用，降低延迟和成本。
2. 超时控制：设置合理的推理超时时间，防止单个 MR 的 CR 请求阻塞整个 CI 流水线。
3. 人工反馈闭环：收集开发人员对 AI 评论的采纳情况，定期将这些反馈数据用于微调模型或优化 Prompt，持续提升准确率。
4. 灰度发布：新功能上线初期，建议先在部分项目或小组中灰度运行，观察效果后再全量推广。

一点感想

一切皆概率：基于 LLM 的应用最大特点在于『输出不确定性』，在候选词中选概率最高的进行输出，即使像 1+1=? 这样看起来有确定性输出的，LLM 也是基于概率给出的！

开源 LLMs + 领域知识库 + 私有化部署是企业级应用的一种实践方式：

这里 LLMs 指多个大模型组合使用；大模型再强大也必须结合内部的知识库才能发挥作用；

私有化部署好处是打消各行各业对数据安全的担忧！

大模型在 Chat 聊天的产品形态更多是秀肌肉，让各行各业能被触达到；最终的产品形态需要具体场景具体分析！

AI+ 刚刚开始：CR Copilot 只是达人 LLMs + 研发工程化其中一个应用场景，还有一些应用/工具等达人团队打磨好后再和大家一起分享！