RAG + Text2SQL：基于 DB-GPT 的海洋环境智能查询实践

来源：市场资讯

（来源：EosphorosAI）

文章内容来自DB-GPT社区开发者投稿

本文介绍了一套面向海洋环境监管的智能查询系统，通过私有化部署 DB-GPT 平台，融合 RAG 技术与 Text2SQL 能力，解决了环境咨询业务中知识检索效率低、跨系统数据查询难、数据安全风险高等核心痛点，实现标准文件查询效率提升 。

一、业务背景与痛点分析

1.1 行业背景

生态环境治理正经历从粗放管理向精细治理的深刻转变。当前，我国生态环境治理的智能化升级步伐持续加快，以大模型为代表的生成式人工智能技术，已成为守护绿水青山的重要科技支撑，AI大模型正深度渗透环境保护全生命周期。

1.2 核心痛点

在现实业务场景中，业务人员需频繁跨越多个数据库表和业务系统，依据复杂的环保标准对监测数据进行合规性判定。海洋环境监督管理工作面临以下三大核心痛点：

痛点 1：海量非结构化知识利用率低

海洋环境标准体系庞大，涵盖政策法规、技术导则、环评报告等，文件格式包括 PDF、Word、Excel、图片等多种类型。

影响：传统方式下，工作人员需人工查阅海量资料来获取所需信息，不仅效率低下，而且知识整合难度大。

痛点 2：跨数据源信息查询和综合研判难度大

环境监管需要综合文档知识、数据库、监测系统等多类异构数据源开展分析研判。

影响：

• 业务人员需在不同系统之间反复切换，手动整合碎片化信息，研判效率和一致性难以保证

• 系统内部数据提取依赖数据开发团队，需求流转环节多、排期周期长

• 面对突发环境污染事件或临时督查任务时，滞后的数据供给模式严重制约快速研判与科学决策

痛点 3：通用大模型应用存在安全与适配问题

直接调用豆包、通义千问等公有云智能助手或 API 进行辅助分析存在以下问题：

风险一：数据隐私泄露 ，敏感的监测原始数据不能出域，存在泄露风险。

风险二：领域知识缺失导致"幻觉" ，通用模型缺乏本地专属的标准知识库和实时数据库连接，易生成虚构的标准限值或错误解读数据趋势，导致分析结论不可信，无法支撑执法决策。

传统的人工处理方式效率低下，难以支撑实际业务场景下的快速响应和精准分析需求，也与当前全领域智能化、数字化发展的趋势不相适应。因此本方案聚焦于海洋环境监测数据的即时查询与分析、多源异构环境标准的智能检索与关联研判，以及自动化监管报表的生成，构建面向海洋环境监管的实用化解决方案，同时为监测预警、执法监管、环评审批等业务环节提供可复制、可推广的实践经验。

二、技术选型与解决方案

针对以上痛点和现实预算，本项目明确需要构建一套可完全私有化部署的智能应用平台，可基于检索增强生成（RAG）技术深度融合环境领域专业知识体系，支持对接各类监测数据库，实现多源数据安全接入与知识精准调用，为环境监管与咨询业务提供安全、可靠、可解释的智能化支撑。

2.1 业界方案对比

在确定技术方案之前，项目团队对业界主流的 AI 应用开发框架进行了系统调研与横向对比，综合评估后，低代码私有化部署平台是针对该项目最为适配的技术实施方案。

2.2 技术选型:基于DB-GPT的私有化部署方案

在深入评估了当前主流的可私有化部署AI应用开发平台后，发现各平台其核心能力各有侧重，但基于检索增强生成（RAG）的知识库功能已趋于成熟，成为许多平台的标配；而将自然语言精准转换为结构化查询语言（ Text2SQL）以实现与数据库的无缝对话，仍然是衡量平台技术深度的关键指标，也是本项目需要攻克的核心难点。 这也成为了我们最终选择DB-GPT的决定性因素。

结论：基于本项目 “海洋环境数据智能查询与分析” 的核心需求，其对数据库操作能力的强烈依赖，与DB-GPT的技术定位高度契合。因此，我们选择DB-GPT作为本方案的智能体（Agent）底座。

2.3 解决方案与技术实现

痛点1：海量非结构化知识利用率低

解决方案：RAG+向量检索赋能非结构化知识利用，DB-GPT支持内置、多文件格式上传、插件自抓取等方式，可灵活自定义构建领域知识库，对海量结构化、非结构化数据做统一向量存储与检索。知识库建成之后，只需要业务人员不断提供标准文件等文本资料即可完成知识迭代更新，支撑部门常态化使用。

痛点2：跨数据源的信息查询和综合研判难度较大

解决方案：AWEL工作流和数据驱动的多Agent协作机制完成跨数据源的信息整合。 DB-GPT的核心设计理念在于深度融合“AI+数据库”，通过AWEL工作流编排和数据驱动的多Agent协作机制，实现知识问答，自然语言驱动的数据访问、分析和自动化报表生成，这一能力直接解决了当前面临的跨数据源信息查询和整合的问题。

痛点3：通用大模型应用存在数据安全和领域适配问题

解决方案：私有化部署和本地知识库数据库直连解决数据安全和领域适配问题，DB-GPT通过私有化大模型、代理脱敏等多种技术保障数据的隐私安全，实现文本和数据全程不出域，全面保障监测数据和重要资料的隐私安全，从底层架构上规避数据泄露与模型幻觉风险 。

图示为技术路线

三、核心实现过程

3.1 步骤 1：数据准备与接入

3.1.1 构建本地知识库

本案例所涉及知识库均使用向量类型进行存储，多源文本资料涵盖PDF、Excel、CSV和PPTX格式。为提升切片质量和检索精度，优化检索效果，总结了以下建议：

1.统一格式：将文档统一转为Markdown格式，在上传时以markdown header来进行语义化切片。

2.人工检验：上传知识库前辅以人工校验，更好地控制每个切片的内容。最好每个切片能保留章节语义且内容长度均衡，从数据源层面来优化检索效果。

3.文档处理工具：推荐使用MinerU进行文档处理，该工具支持本地部署，可进一步降低敏感资料外发与出域风险（https://mineru.net/）。

4.检索策略：知识库检索建议选择混合检索策略，效果更好。

3.1.2 知识库构建策略：从“单一大库”到“分类小库”

痛点发现：初期将500余份环境标准及规范性文件统一存入1个知识库，导致检索上下文噪声过大，匹配精度显著下降，回答准确率难以满足业务需求。

优化方案：实施“数据分类 + 多库隔离 + 路由分发”，在数据预处理阶段就将资料进行分类，确保各类别间内容互斥，避免交叉重叠，为每一类数据创建独立的知识库及应用实例，在提示词里明确定义每个应用及包含的知识库所覆盖的知识边界与核心内容，这样意图识别的会更准确，能更加高效地去检索相关的知识库。

存在问题：尽管分类互斥能大幅提升检索准确率，但仍然可能存在“意图漂移”风险（即用户提问属于知识库A范畴，却被错误分配至至知识库B）。目前做法是尽量把提示词写好，通过强化边界描述和增加少样本（Few-shot）示例，大部分情况下都能检索到正确的知识库。

3.1.3 数据库接入

按照提示连接数据库。

3.1.4 数据库查询 Text2SQL准确性问题

痛点发现：DB-GPT原生的 Text2SQL 能力在实际业务查询中表现不稳定，常因元数据理解偏差生成错误SQL或者生成空的SQL，导致查询结果为空、报错或者查询错误。

优化方案：在提示词中详细注入数据库的全量元数据信息，包括表名、字段名、字段类型、主外键关系及关键枚举值含义；且在这一步可以限定访问权限，让大模型只访问允许访问的表格。

成效：提升了模型对表结构的理解深度，提高了查询准确率。

未经优化的提示词及其效果：直接使用 DataScientist 的原生提示词，无法很好适配实际表情况，导致生成错误 SQL。文中所提“南山区”和“异常情况”都需要使用编码来进行查询，如果在提示词里没有描述，大模型会根据自己的猜测生成 SQL，而这些 SQL 通常是不正确的。

优化前（使用原始提示词）

在原始提示词中添加关于库表和字段的详细解释之后，模型能够生成正确的 SQL 语句，SQL生成的准确率从60%提升到80%。

优化后（添加库表和字段详细解释）

3.2 步骤2:本地模型部署

大语言模型采用通义千问（Qwen）系列大模型，为严格保障业务数据与文档资料全程不出域，同时实现DB-GPT平台与 Qwen 系列大模型的高效兼容，本方案采用本地私有化部署大语言模型的技术路线，并选用vLLM推理引擎提供模型加速支撑。相较于 TensorRT-LLM、Text Generation Inference（TGI）等主流推理框架，vLLM 具备：

• 卓越的高并发处理能力与动态批处理优化特性，可显著提升文本生成速度、降低推理延迟；
• 对 Qwen 系列大模型的原生支持度高，部署轻量、环境适配性强。

vLLM 能够在本地离线环境中稳定实现大模型高性能推理，全面满足数据不出域、模型兼容适配、推理效率保障的核心需求。

Embedding模型选用bge-m3，该模型在多功能性、多语言性和多粒度方面表现卓越。

3.3 步骤3：应用构建

3.3.1 知识库问答应用

针对每个独立知识库分别构建应用，选择单一智能体模型进行创建，本案例中使用Summarizer智能体来做知识问答，并绑定对应的知识库完成应用配置。

3.3.2数据库问答应用

选择单一智能体模型创建应用，使用DataScientist智能体来实现 Text2SQL数据库问答，并绑定对应的数据库和提示词完成应用配置。

3.4 步骤4:意图识别提示词构建

实现方式：将 app_code 放到意图识别提示词中，告诉意图识别智能体遇到什么问题应该启动哪一个应用。

操作方法：将提示词写入 .txt 文件，再上传到意图识别知识库。

提示词示例：

3.5 步骤5:工作流编排

工作流编排中涉及两个智能体（其他智能体均已在应用中配置完成）：

• Intent Recognition Expert：根据意图识别提示词和用户输入，判断用户意图；
• AppLauncher：根据意图识别结果启动对应的应用。

例如，当用户提问“入海排口的一级分类有哪些”时：

• Intent Recognition Expert 判定为知识问答意图；
• AppLauncher 启动对应应用，从知识库检索并生成回答。

案例中还增加了一个分支作为保底问答，当意图识别出错或者无输出时，从保存了所有文件的知识库检索并生成回答。

四、成果实现

• 成果展现：上线海洋环境智能问答助手。
• 效率提升：实现标准文件查询效率的指数级跃升。将单次检索耗时由平均30分钟大幅压缩至1-3分钟，响应速度提升超90%，释放了大量人力资源。
• 简化工作：有效降低业务操作门槛，解决了传统人工比对流程繁琐、易出错的痛点，显著降低工作复杂度。
• 存在问题与后续方向： 初期还希望实现的一个效果是通过智能化手段自动完成监测分析报告。但在实际操作中，数据查询和知识问答被设计为两个不同意图，每次只能执行一个意图，因此暂未实现数据和文本的融合分析。 随着 DB-GPT 0.8.0 版本数据分析助手实现多源数据打通，从技术上已具备实现该效果的基础，后续可在此版本能力上继续演进。