用ChatGPT搭建代码知识库提升开发效率

来源：未知编辑：天选资讯时间：2023-07-01

　　ChatGPT 是一种强大的自然语言处理模型。在工作中，我们可以借助其卓越的自然语言生成能力，快速检索代码信息，使程序员们能更加专注于业务逻辑的实现和优化。然而，由于它的知识库仅覆盖至 2021 年 9 月前的信息，一些新的技术文档无法被查询到，例如我们公司前端经常使用的开源框架 TDesign。本文讲解了本人为了解决这一痛点的实验过程，即通过应用 embedding 技术并结合 AST 解释器，实现了对 TDesign 代码知识库的自然语言查询。在 30 个常见用例的测试下，查询精度达到了 90%。常用组件的检索时间从平均 10 分钟缩短至 2 分钟，从而提升了前端研发效率 20%。

　　ChatGPT 的数据覆盖范围仅至 2021 年 9 月前，这意味着如果出现了 2021 年 9 月之后的新信息或技术，ChatGPT 可能无法提供准确的答案或建议。例如，前端开发中经常使用的公司开源项目 TDesign 就是一个例子：

　　幸运的是，针对这天选团队个问题，业界已经提供了解决方案——构建知识库，一般有两种路径：

　　首选的方法是对开源的大型语言模型（LLM）进行全面或部分的微调，采用 fine-tune 或者 LoRA 技术。这种方法的优点在于，它能使 LLM“记住”特定的领域知识，从而在拥有特定知识背景的条件下进行交流，如“猫娘”或“客服机器人”等。此外，因为采用了私有部署，这种方案适合用于一些尚未公开的公司内部知识。然而，这种微调方案的缺点在于，它需要大量的 GPU 算力支持，且调试过程耗时较长。

　　第二种方法是利用嵌入技术（embedding）。通过嵌入模型，将特定知识转化为向量，然后将这些向量存入相应的向量数据库中。在查询阶段，通过相似度查询，匹配出关联的 topK 结果，然后将这些结果提供给 LLM，生成相应的答案。这种方法的优点在于，OpenAI 提供了对应的 text-ada-embedding-002 模型，价格合理，效果也相当出色。然而，其缺点是可能不适合处理内部数据，存在数据泄露的风险。这里我要特别提醒一下，数据安全，人人有责。大家在实践过程中一定要防止敏感数据泄露的风险。

　　1、考虑到 TDesign 已经在公网开源，因此相关数据并不涉及敏感信息；

　　这里主要参考了 github 上面的 MrRanedeer 项目：，借鉴他的知识描述方式和信息组织的格式，综合对比之后采用了 JSON 的数据格式；

　　起初，我的计划是：组件文档说明 + 组件代码 few shots ，以让 chatGPT 直接理解相应组件的规则，然后生成相关的代码。然而，实践证明这种做法效果并不理想，即使结合 prompt 提示进行优化，其最终效果也相对有限。(原因估计是太多的特有名词模型理解不了，导致产生了幻觉(hullucination))

　　调整后的数据结构如下：组件 - 使用场景 - {场景描述 & 代码}。

　　我们将使用常见的 LLM 对接工具 Langchain 和它的 Text Splitter 工具。具体来说，我们使用的是RecursiveCharacterTextSpliter，它能在尽可能保证句子语义完整的前提下根据 ChunkSize 进行分段。但是由于 chunkSize 的局限和知识文章长度的不确定导致很多时候，切片后语义的丢失。比如：

　　{小明的自我介绍: 大家好叫小明,我的爱好是足球和绘画}，如果文本在小明这里被截断，后续搜索小明的介绍，大概率不会将小明和后面的我的爱好是足球和绘画的信息匹配到一起，而导致在数据召回阶段没办法得到准确的知识。

　　天选

　　这个阶段主要是通过提出的问题，搜索向量数据库中匹配的信息，与系统 prompt 整合之后传给 openai competition 完成知识检索。

　　{小明的自我介绍: 大家好叫小明,我的爱好是足球和绘画}，如果文本在小明这里被截断，后面的信息就丢失了小明的自我介绍的上下问信息，导致召回失败。

　　1、针对上面提到两点影响因素，第一个方案可以通过优化 chunkSize 和 topK 的参数进行微调试错，但是总的来说当查询维度提升，所需的上下文信息也会相应增多，但这可能受到 LLM 的上下文长度限制的约束。关于这一点笔者写文章时已经拿到了 claude 100k 上下文的 api，会在未来进一步的测试

　　2、针对第二点切片的导致的上下问信息丢失，笔者想出的方案是：通过 JS 解释器将文档信息转换成 Javascript AST(抽象语法树)，每次切片记录当前索引所在的 scope 信息，从而标记出当前切片的上下文信息。(体验 AST:)

　　可以看到在抽象语法树中，如果处理的是 JSON 对象，无论是 key 还是 value 都是能定位到他的字面量字符串的索引区间，所以只要知道我们每次分片的开始和结束的索引，我们就能定位到他在 AST 中的位置，当知道这个位置之后我们就可以通过算法回溯到当前片段的所有父级 key，也就是说只要我们的父级 key 足够语义化，我们上下文的信息就更加完整。

　　如果套用到前文提到的小明的例子的话，第二段我的爱好是足球和绘画的 scope 信息就是 {startScope: 小明的自我介绍,endScope: },如果我们通过特定格式将他拼接到知识信息中去就会是：

　　现在如果使用小明的兴趣爱好来匹配并召回 embedding 片段，并喂给 LLM，就能得到准确的答案了。

　　最后可以在 prompt 中通过 few shots 进一步优化匹配，到此为止优化流程就完成了。

　　经过上述 AST 优化，最终得到了显著的优化结果，统计结果显示，错误答案(Bad Case)已减少至 3 个，回答尚有瑕疵(Not Perfect)的数量也降至 2 个。这样计算下来，正确率达到了 83.3%（25/30），可用率为 90%（27/30）。在当前样本集下，正确率提升了 15.6%，可用率也提升了 13.3%。