大模型检测代码问题优化思路

     以优化大模型检测多线程问题为例，可按四阶段走的策略进行。

第一阶段：代码段扫描

     这个阶段的目标，是让大模型每次检查一个代码片段，输出该代码段的多线程问题，并保证足够的准确率。由于本阶段扫描的是代码段，缺少非常多的上下文信息，自然会有比较高的误报率，对此有2种优化方法：

     l  优化Prompt

        利用提示词工程中的约束增强、Few Shot、思维链等技巧，降低误报率，这种方案比较容易理解，本文档不做过多阐述。

     l  训练一个小模型

        图1展示了利用小模型，降低大模型误报率的方案。该方案的核心是用小模型过滤掉误判样本，剩下的交由大模型去检测多线程问题，从而提高大模型预测的准确率。

• 数据集构建

          收集之前大模型误报的样本作为负样本，正确预测的作为正样本，将这些负样本和正样本合并在一起，以特定比例将数据集划分为训练集和测试集，训练集用于训练小模型，测试集用于评估小模型的性能指标是否满足要求。

• 小模型训练

          同传统的深度学习训练一样，定义损失函数、优化器等。

 

 图1 小模型优化方案

 

　　无论使用上述Prompt优化，还是小模型过滤，目标都是使大模型检查代码片段的准确率提升。

　　后续操作手段是找几个典型的试点工程，并将试点工程分为训练集和验证集2个部分，训练集的工程让现有AI工具去扫描，随后人工分析扫描结果的准确率，并总结被误判的例子，然后相应调整提示词或训练小模型，以规避这些误判的例子，而验证集的工程，作为基准数据集(benchmark)，验证优化后的提示词或小模型的准确率。

　　如果提示词或小模型优化到准确率可以接受的程度，就全面推广检测所有工程，同时进入第二个阶段，利用第一阶段工具扫描全部工程的时间间隙，展开第二个阶段的研究、优化工作。

第二阶段：单个文件扫描

　　大模型每次检查一个文件，这个阶段的目标、优化手段、采用的试点工程等，皆同第一阶段，区别仅在于大模型检测代码的粒度不同，第一个阶段检测代码片段，第二阶段检测一个文件。

　　如果提示词或小模型优化到准确率可以接受的程度，就全面推广检测所有工程，同时进入第三个阶段，利用第二阶段工具扫描全部工程的时间间隙，展开第三个阶段的研究、优化工作。

第三阶段：单工程扫描

　　大模型每次检查一个工程，这个阶段是让大模型拥有一次能检测一个工程所有多线程问题的能力，但这个阶段首要的目标是如何从工程中筛选出多线程相关的代码集合，因为一个工程中的累计token数，一般都远远超过目前大模型上下文长度的极限(128K)。

　　经调研，目前抽取多线程相关代码的方法，有两种方案可以尝试：

　　l  RAG + AST

　　   这种方案可参考Sweep AI的方案。

　　l  知识图谱(Knowledge Graph)

　　   知识图谱，本质上，是一种揭示实体之间关系的语义网络，图2展示了一个知识图谱样例，图中的㮋圆表示实体，实体间的连线表示两个实体的关系，连线上的文字表示关系的类型。

 图2 知识图谱样例

      下面对知识图谱提取多线程相关代码进行阐述。

       图3为一段多线程代码，图4为图3对应的知识图谱。图62中粉色㮋圆为方法对应的实体节点，方法实体节点会用code属性，存储该方法的实现代码，图4中的知识图谱会持久化存储在图数据库中，比如neo4j等。

图3 多线程代码

 

图4 图3代码对应的知识图谱

       用户输入查询query，内容为“找出工程中所有的多线程问题”，系统经过语义解析，确定用户的意图是要分析整个工程的多线程问题，系统随后将关键字多线程，替换为相应的编程语言关键字集合，比如：Thread、synchronized、volatile、Lock等，用这些编程语言的多线程关键字去查询图数据库，Thread关键字可查询出图4对应的网状结构，紧接着解析图4中实体类型为method的节点，并将其code属性取出，最后将所有检出的method节点的code属性值拼接在一起，作为Prompt的上下文，这样就完成了多线程相关代码的检索。

　　图5为前述过程的系统架构，图6为图5对应的工作流程。

图5 基于知识图谱的工程代码问题检测系统架构

 

图6 基于知识图谱的工程代码问题检测系统工作流程

 

　　无论采用哪种方案优化，在一定程度上解决了如何提取多线程代码的问题后，剩下的事情和第一个阶段、第二个阶段是一样的，重复着分析误判的例子、优化提示词、验证提示词的过程循环，以达到准确率能够接收的程度。

第四阶段：通用工具方案

       通用的代码问题检测工具，可以让用户自行选择检测代码的粒度大小，比如代码段、单个文件、整个工程。当然了，以目前大模型的能力，不同粒度对应的解决方案是不同的，工具可以根据用户选择粒度的大小，选择对应的方案来处理，下面以不同的粒度来阐述通用工具方案。

　　l  代码段/单个文件的问题检测

　　图65为基于代码段/单个文件的问题检测工具方案，工具首先让用户对问题场景进行配置(Detect Config)，确认开发语言、问题类型、开发框架、运行场景等要素后，即可开始扫描。工具在扫描前，根据Detect Config的配置，从Prompt模板管理器中选取特定的Prompt模板，后续对工程代码段/单个文件的扫描，就是使用该Prompt模板。

       该方案将不同场景、不同开发语言、不同开发框架等变化的部分，抽象为Prompt模板管理器，不同的Prompt模板对应不同的场景，让用户在工具扫描前确定好场景要素，这样后续的扫描逻辑都是一样的，以此实现工具的通用性。

       而本方案的扩展性体现在，如果后续出现了新的问题类型，比如稳定性问题，那么只需向工具的Prompt模板管理器注册稳定性问题Prompt模板即可，不需要改动工具现有代码和重新编译、发布。

 

 

图7 基于代码段/单个文件的问题检测工具方案

　　l  整个工程的问题检测

　   整个工程问题的检测，以基于知识图谱的解决方案为例。

　   本方案为了实现通用性，做了以下2点设计：

• 将不同场景、不同开发语言、不同开发框架等变化的部分，抽象为关键字模板管理器，不同的关键字模板对应不同的场景;
• 用户意图检测模块，基于Prompt，识别已知的所有场景。

       这样后续的扫描逻辑都是一样的，以此实现工具的通用性。

　　而本方案的扩展性体现在，如果后续出现了新的问题类型，比如稳定性问题，那么需要完成以下2个工作：

• 向关键字模板管理器注册稳定性问题关键字模板;
• 用户意图检测模块Prompt，需要支持稳定性问题场景。

　　除以上2个工作外，不需要改动工具现有代码和重新编译、发布。

 

图8 基于单个工程的问题检测工具方案

 

关注更多安卓开发、AI技术、股票分析技术及个股诊断等理财、生活分享等资讯信息，请关注本人公众号(木圭龙的知识小屋)