浅谈GPT在数据库重构项目中的创新应用

引言:它来了

当我们对《流浪地球2》中人工智能MOSS产生无尽的科幻联想之际,GPT已经通过大规模数据预训练,拥有了理解、生成文本的能力,并在多个行业引发了巨大冲击,从客户服务到市场营销,从医疗健康到教育,都带来了颠覆性的变革,AI元年悄然而至。

在软件研发领域,它能够帮助我们提高开发效率、改善代码质量、代码自动生成吗?本文依托于一个老项目数据库重构的背景,和大家一起探讨下GPT在研发重构过程中的应用实践。

重构:困难重重

浅谈GPT在数据库重构项目中的创新应用_第1张图片

已服役十余年的项目,应客户要求去除商业数据库中间件,使用postgreSQL替换Oracle,经过十余年的业务加载和迭代,启动重构存在很大的考验与风险:

  • 数据库方面:数据库中存在大量的存储过程、函数、动态SQL需要进行语法差异转换,并且调用链情况较为复杂,在存过、函数、动态SQL之间存在着互相调用的情况,耦合度比较高。
  • 代码方面:祖传架构方面,老式集群模式的项目下代码工程多,工程中的技术框架经过很多轮的迭代,包含JDBC、MyBatis、FreeMarker、EJB、工厂模式等。业务实现方面,有大量的存过、函数调用,并且SQL的组装无处不在,有字符串拼接、StringBuffer、StringBuilder、mapper.xml、自定义XML等方式。

综合来看,这是一项具有挑战性的任务,技术上没有瓶颈,但实施上困难重重:

  • 代码走查需仔细,否则范围难控制;
  • 对于人员经验要求高,需要熟悉框架,能够识别、发现、解决问题;
  • 大量的SQL和代码改造,具备高度经验化、高重复化的特征;
  • 项目多人员参与,经验参差不齐,如何保障重构质量。

GPT:研发团队小助手

为了提升效率,引入了chatGPT作为研发小助手,并按使用场景给它分了三个角色,看看它具体可以帮我们做什么:

浅谈GPT在数据库重构项目中的创新应用_第2张图片

下面让我们通过重构中java代码处理的一个典型场景示例,带大家一起感受一下它的魅力:

第一步:准备好需要处理的java代码段,和指令。

浅谈GPT在数据库重构项目中的创新应用_第3张图片

图片

第二步:问答交互式协助,就如同使用钉钉、微信聊天一样,输入上面的代码段+指令,让它帮我们处理。

最后:AI的响应结果符合预期,并且给出了详细的汇总分析。由此可见,只要指令够准确,它就可以快速完成代码段的分析、改造和总结,效率很高,整体耗时不会超过10秒钟。

盘它:工欲善其事必先利其器

使用过程中发现chatGPT在高度经验化、重复化的任务处理中表现不俗,研发一个以它为底座的重构工具势在必行。细心的你,会发现上面的截图并不是来自需要科学上网的chatGPT,而是源自我们做的接入GPT API的重构小工具。

浅谈GPT在数据库重构项目中的创新应用_第4张图片

自动走查,解决走查困难问题

用内置扫描器来替代人工走查,当前工具预置扫描器已支持java代码、DDL、xml扫描,精确的按任务文件维度,处理一个超大文件,在保证上下文完整的情形下,拆解成符合AI token要求的较小任务单元(代码段)。

对扫描拆解的代码段,按照预置场景下的命中策略,判断是否需要送AI处理,打标识生成真正的待办任务。

这样不再依赖于人工走查和人员经验,既节约了时间,又减少了疏漏,同时一定程度上提升任务转化效率及准确率。

可视化项目管理

传统的数据库重构项目研发管理,代码走查完成后,由研发经理分配到人,现在不需要了。工具提供项目维度的管理,将AI交互使用场景分类,进行场景化管理,场景扫描生成任务后,自动均匀分配给项目研发人员。

例如,Oracle2PostgreSQL的重构项目,包含的两种场景:

  • DDL转换场景:将Oracle数据库中的表、存储过程、函数、视图等DDL导出到文件中,文本扫描器扫描生成DDL转换任务,分配给研发人员进行审核后,就可以直接交给AI处理;
  • 代码工程转换场景:上传或git拉取代码工程并托管,javaparser、文本扫描器会对代码工程做自动走查扫描,将需要处理的java类、mapper.xml文件等,作为任务,分配给研发人员,待审核后,直接交由AI处理。

提供任务可视化及闭环管理,项目管理者在监控界面上对场景任务的分配情况一目了然。

一键AI处理

数据库替换重构项目中,需要研发经理做好技术背调,并输出任务清单,然后对研发团队进行赋能和分配任务,接下来研发人员按包路径维度,结合背调知识库,逐个修改。这样做的缺点是容易代入个人编码习惯,无法标准化,可能会带来不必要的BUG,对业务产生影响。

工具自动化后,研发人员只需要关注分配的任务,按照任务清单对代码段审核,就可以一键送AI处理,AI会响应输出结果代码段或SQL,然后针对预处理后的AI返回结果,进行人工校准,就可以一键复写生成java类和SQL。

人机交互模式,将高度经验化、重复化的部分研发工作,交由AI处理,研发人员做好审核和校验,充分利用了AI编码能力,节约了工作量,同时提升了准确率和代码质量。

干货:一点心得

模型选择:text-davinci-003模型 or gpt-3.5-turbo模型

01 模型和使用场景分析

text-davinci-003是基于GPT-3的模型,适用于广泛的自然语言处理任务,包括对话生成、问题回答、文本摘要和翻译等。它功能强大但相对较慢,适合复杂和深入的文本处理,不要求实时性。

gpt-3.5-turbo是基于GPT-3.5的模型,具有高性能、低延迟的特点。它适用于快速生成文本的场景,如在线聊天机器人、客户支持自动化和内容创作辅助。在对话和短文本方面表现出色,响应速度快。

02 token和频次限制

两种模型对于每分钟调用频次、交互token均有限制。开始我们倾向于选择token大和调用频次高的达芬奇模型,但试验后发现,在转换速率和准确率上gpt-3.5-turbo要远优于达芬奇,可是基于chatgpt更高的时效和性能要求,OpenAI对它做了更多的限流控制。

浅谈GPT在数据库重构项目中的创新应用_第5张图片

综上,gpt-3.5-turbo模型更加适合用于高效率、高质量的生成型任务,在算力性能和实时性方面优势很大,选择接入它没错。

turbo模型速率限制解决方案

turbo的限流控制很让人头疼,于是工具研发中引入了令牌桶算法,支持接入多个apikey,完美解决了限流问题。

令牌桶算法(Token Bucket Algorithm)是一种流量控制算法,用于控制资源访问速率。它是一种经典的算法,常用于网络传输、API限流、请求调度的场景。

浅谈GPT在数据库重构项目中的创新应用_第6张图片

token限制解决方案

提炼出java、xml、DDL文件不同的特征,通过预置的Java类扫描器和文本类扫描器,保障上下文完整性,以及符合交互的token限制。

场景命中策略

openai是收费的,内测中免费账户流量很快就耗费殆尽。如何筛选命中有效内容,把实际需要处理的内容交给它很关键。

基于这些考虑,抽象出了场景的概念,在场景下预置不同的正则表达式策略,并提取符合策略规则的内容/代码段,提交给AI处理。

AI交互指令校准

让我们再接着思考:在特定使用场景下如何设置合理角色和prompt?又怎么固定返回我们想要的结果?

  • 模型选择、加载:需要分析场景任务选择合适的模型,将模型加载到计算环境中,以便进行后续的校准和交互;
  • 样本数据准备:为了进行指令的校准,我们将需要问询的数据整理成样本数据;
  • 指令示例:样本数据和特定的场景指令集,组合形成待校准指令集;
  • 筛选指令:根据不同指令的响应,选择符合预期的指令作为场景的prompt。

人机交互的设计

初版设计思路为:扫描->AI处理->回写,验证后发现存在着准确性、及时率的一些问题,于是我们考虑使用半自动-人机交互模式来解决这些问题,流程优化为:扫描->任务审核->AI处理->任务校准->回写,并且提供差异比对和异常重送的功能,以提升交互准确率。

浅谈GPT在数据库重构项目中的创新应用_第7张图片

总结:说点想说的

随着AI的不断发展和应用,其强大的自然语言预处理机制和大数据的魅力,在各个领域展现出巨大的潜力。在代码解释分析、代码生成、知识库检索等方面也拥有无限可能,未来,我们可以期待它作为研发的好帮手,发挥更重要的作用。

你可能感兴趣的:(gpt,数据库,重构)