基于RAG的文生SQL应用（脱敏）

RAG

大模型（LLM）的浪潮席卷了各个行业，由于其强大的搜索能力和生成能力，被应用也是极为广泛。但是常常市面上开源的大模型更多是通用大模型，针对企业级的大模型应用往往需要微调，但这需要消耗很大的资源，因此RAG（Retrieval Augmented Generation）即增强检索生成的研究给专用大模型带来了希望，不用重新训练模型，仅仅喂给大模型足够多的知识，即可减少大模型幻觉，增强结果。一个RAG的流程大概如下图所示：

文生SQL

通常指的是将自然语言（文本）转换为SQL查询的过程或技术。
比如：
文：显示所有员工的姓名和工资，其中工资高于50000。
SQL：

SELECT name, salary FROM employees WHERE salary > 50000;
1

但这往往只能回答一些简答的问题，针对企业的需求是不可能充分满足的。根据接触到的场景，大模型几乎无法完成，比如：

• 海量表结构管理：企业数据库中表的数量往往是惊人的，且许多表具有大量的列（大宽表），这增加了理解和解析数据结构的难度。大模型难以准确地捕捉和处理这种高维度数据之间的复杂关联。
• 动态与临时表操作：业务场景下，为了特定需求而创建的临时表是常见的。这些表往往需要通过一系列的SQL操作（如JOIN、GROUP BY、聚合函数等）从原始数据中提炼生成。大模型在追踪这种多步骤、依赖于特定业务逻辑的表构建流程上，表现得较为乏力。
• 复杂查询合成：在实际应用中，一个完整的业务需求可能涉及到从多个源表中提取数据，通过复杂的SQL脚本进行加工，再将结果整合到一张或多张结果表中。这一过程不仅要求理解单个查询的语义，还需要具备将多个独立查询组合成连贯的、高效的数据处理流程的能力，这是当前的大模型所难以达到的。
• 跨表数据融合：接口表的构建通常需要从多张结果表中抽取数据，每张结果表本身可能就是通过多表联结生成的。这种多层次、跨表的数据融合操作，要求系统能理解并执行高度嵌套的SQL查询，而大模型在此类任务上的性能尚待提升。

当然，我猜想可能有财大气粗的公司会训练这一功能，但是SQL脚本动辄上千行，token数巨大，成本实在是太高，我认为实现这一需求可能不会付出这么多资源。
这时候RAG技术真的就十分强大了（与其说RAG技术强大，不如说大模型的理解能力真的很强），在真正进行我们的项目介绍前，需要介绍一下LangChain。

LangChain

LangChain是一个开源框架，专为开发基于语言模型的应用程序设计。它由三大部分组成：语言模型、链（chains）和向量数据库。LangChain旨在帮助开发者轻松构建和部署涉及自然语言处理（NLP）的任务，特别是那些利用大型语言模型的场景。

• 语言模型：这部分包含了对各种语言模型的封装和接口，允许开发者直接使用这些模型进行文本生成、问答、翻译等任务，而无需深入了解模型内部的工作原理。
• 链（Chains）：链条是LangChain的核心概念之一，指的是将多个语言模型和其他组件串联起来，形成更复杂的工作流。链条可以定义数据如何在不同模型之间流动，从而实现高级功能，例如，先使用一个模型进行文本摘要，然后使用另一个模型进行情感分析。
• 向量## 标题数据库：向量数据库用于存储和检索高维向量，通常用于表示文本或其他非结构化数据的特征。LangChain集成了向量数据库，使得应用程序能够有效地搜索和管理大量文档或知识库，这对于构建智能问答系统或推荐引擎非常有用。

最初的LangChain是基于python的后来为了满足软件开发人员，相继出现了LangChain4J，这是一个基于java的工具包，你可以搭建自己的工作流，有丰富的组件和函数供你使用。

介绍了这么多前置知识，现在介绍一下项目背景。

项目背景

在电子商务行业中，精准的用户画像构建是至关重要的。这些用户画像包括用户的浏览行为、购买偏好等多方面信息，使电商企业能够提供更加个性化的推荐和营销服务。然而，营销团队通常不具备直接操作数据分析工具的能力，这限制了他们快速响应市场变化的能力。因此，他们需要依赖数据团队将业务需求转化为数据分析和挖掘的结果，以支持他们的营销决策。说白了就是业务人员不懂技术，他们想通过一些指标来分析用户行为以便他们的工作，就需要技术人员实现这个需求，把这个需求“算”出来，然后做成接口，直接让业务人员查看。

应用背景

该应用作为脚本开发平台中的辅助工具，旨在帮助开发人员通过自动化的方式快速理解业务需求，并提供一个可操作的SQL脚本起点。通过减少从业务需求到技术实现的转化时间，开发人员可以更高效地进行脚本的优化和调整，提升数据处理的精确度和效率。 说白了就是帮技术人员省点劲，提升效率，给点SQL脚本参考。

项目技术栈

SpringBoot+Redis+MySQL+Gauss DB+MyBatis-Plus+Langchain4J，其实项目逻辑挺容易的，但是亮点在于其新颖。

项目内容

因为设计到公司内容，所以放出简化版，仅仅是个思路，大概是通过检索找到相似的口径，然后通过一系列操作找出对应的SQL加工脚本，最后pt工程。
功能方面：参考了DAIL的prompt模板，多智能体协同（避免一人承担所有）等
系统稳定性：引入了限流、异步操作增强系统鲁棒性，redis避免总使用接口去解析SQL，对输入和输出都做正反馈机制，比如规范化输入，保存好的输出增加知识库等。