搜索[Text2SQL]结果-低调大师优秀个人博客

论文复现丨基于ModelArts实现Text2SQL

本文分享自华为云社区《基于ModelArts实现Text2SQL》，作者：HWCloudAI。

2022-12-27

如何快速判定智能问数（Text2SQL）方案是否可用

判定一套智能问数（Text2SQL）方案能不能用，只需要问一个问题： **查询结果出来之前，业务人员能不能确认 "这次问对了"？** 能，方案就可落地。

2026-07-24

LLM在text2sql上的应用 | 京东云技术团队

一、前言：目前，大模型的一个热门应用方向text2sql它可以帮助用户快速生成想要查询的SQL语句。

2023-10-25

智能问数Text2SQL的JOIN噩梦怎样被DQL终结？

Text2SQL 火了三年，有一道行业级的坎始终迈不过去：多表关联（JOIN）。演示环境里百发百中的工具，一进入企业真实数据环境就频频翻车。

2026-08-10

Text2SQL智能体深度实践：从架构设计到自修正闭环

Text2SQL技术试图用大模型弥合这一鸿沟，然而现实远比想象残酷：曾在Spider 1.0上达到86%准确率的GPT-4，在更贴近真实企业数据的Spider 2.0上，整体成功率骤降至6%。

2026-09-02

用 AI 智能体做 ERP 实施服务：多租户隔离与 Text2SQL 的边界

![路程图1.jpg](https://developer.qcloudimg.com/http-save/yehe-12807933/77a351711efbc4efec12164837cd2642.jpg) >我们是一家做 ERP 的小公司，过去两年一直在试一件事：把「实施服务」和「二次开发」这两件人力密集的事，尽可能交给 AI 智能体去做。这篇不讲愿景，只讲我们实际跑通的链路、踩到的坑，以及目前还做不到的部分。部署形态上我们对比过两条路：托管方案重点评估了 **腾讯云 ADP**，自部署方案用的是 Dify。本文第三节保留了这次取舍的过程与理由。 ## 一、先给结论：哪些能做，哪些短期别指望很多人问「AI 能不能替代 ERP 实施顾问」。我们跑下来的答案是：**不能替代，但能吃掉实施里最耗人的那一半。** **已经能稳定交付的三件事**： | | | | |:-:|:-:|:-:| |能力|说明|效果| |**操作/配置问答**|「这张单据怎么审核」「这个字段在哪配」→ AI 直接答，还能顺手查库确认|客户不用等顾问回消息| |**实施步骤与流程草案**|调研问卷、实施计划表、蓝图方案、基础资料导入清单 → AI 按行业生成初稿|顾问从「从零写」变成「改一稿」| |**数据查询自证**|「我本月有多少未审核销售单」→ AI 调接口查真实数据回答|减少"我帮你查一下"的往返| **短期不要指望的三件事**： - **需求判断**：客户说的和他真正要的往往不是一回事，这需要现场经验 - **跨部门协调**：上线推进本质是项目管理，不是知识问题 - **数据对错的兜底**：AI 说「已保存成功」不等于业务上真的对，必须有校验 **一句话总结：AI 把「知识检索 + 文档初稿 + 数据查询」这三块吃掉了，但「判断」和「担责」还在人身上。** ## 二、ERP 实施为什么是门人力密集生意做了十几年 ERP 实施，痛点就三条： 1. **知识全在顾问脑子里**：一个成熟的实施顾问要 3–5 年才能带项目，人一走知识就断 1. **同一个问题答一百遍**：「怎么新增用户」「为什么审核不了」「报表在哪导出」——90% 的客户咨询是重复的 1. **文档从零写**：调研问卷、蓝图方案、导入模板、培训课件，每个项目都重写一遍，但 80% 内容是共通的这三条恰好都是**「知识密集 + 高度重复」**——正是大模型最擅长的场景。所以问题不是「AI 有没有用」，而是「怎么把它接进现有的系统里，且不出事」。 ## 三、选型：托管方案 vs 自部署做 ERP 智能体，绕不开一个选择：**用云厂商的托管智能体平台，还是自己部署一套（比如 Dify）。** | | | | |:-:|:-:|:-:| |维度|托管方案（如腾讯云 ADP）|自部署（如 Dify）| |**上手速度**|快，控制台配好插件就能用|慢，要自己起服务、配模型、调向量库| |**知识库**|平台自带，文档解析省事|自建，可控但需维护| |**工具调用**|插件机制，写个 HTTP 接口就能挂|工作流/工具节点，灵活但要自己写编排| |**数据主权**|文档要上传到厂商侧|**完全在自己机器上**（对 ERP 很关键）| |**成本形态**|按调用量计费，用得多不一定便宜|服务器固定成本，量大更划算| |**可控性**|受平台限制（模型版本、超时、并发）|全部可控| **我们的实际做法**：**两条都跑**。用托管平台快速验证链路（先证明「能跑通」），同时按自部署的架构设计，避免以后迁移时推倒重来。 **结论性建议**：如果客户数据敏感度不高、想两周内看到效果，先上托管；如果是 ERP 这种「客户数据就是命」的场景，**最终一定要能自部署**——这不是技术偏好，是合规和信任问题。下面讲的部分，是我们已经实测跑通的链路（托管方案形态）；涉及自部署的部分，我讲的是架构设计，不假称已经上线。 ## 四、整体链路：一次提问背后发生了什么很多人以为「AI 问答」就是「把问题发给大模型」。真接进 ERP 之后，一次提问实际是这样的： ``` ```这条链路里有三个设计决策值得单独说，也是我们踩过坑才想明白的。 ## 五、五个关键实现点 ### 5.1 多租户隔离：一个 AI 服务多家客户，绝不能串数据一套智能体服务多个客户账套时，最容易出的致命事故是「A 客户问到了 B 客户的数据」。我们的做法是**两段式隔离**： **第一段：会话级 token**。ERP 后端在用户登录时调 `/register`，把该用户所属账套的数据库连接信息注册到平台，换回一个 `tenant_token`，存在用户会话里。之后每次提问都带上这个 token，平台据此路由到正确的账套。用户登出时调 `/unregister`，**token 立即失效**——不留长连接、不存常驻凭证。 **第二段：数据级分支隔离**。这是 ERP 侧自己的机制：所有业务表按 `FHBranchID`（分支=机构）隔离，每个注册账号有自己的分支，查询条件一律带上当前会话的分支值。两段叠加的结果是：**即使 token 泄漏，拿到的也只是某一个账套、某一个分支的只读数据**，不会横向穿透。 >**经验**：多租户 AI 的隔离不能只做一层。会话 token 解决「路由到哪个库」，数据分支解决「库里能看到哪些行」，缺任何一层都是事故隐患。 ### 5.2 给 AI 只读连接，写操作走业务接口这是我们最坚持的一条设计原则：**不要给 AI 数据库写权限。** AI 拿到的数据库连接**永远是只读的**： - 本地部署：账套的 `bin` 目录下有一个只读连接配置文件（`RealOnlyConnectstring.ini`），里面存的就是只读账号 - 云端账套：只读连接由云端自动下发，客户端不需要也无法自行指定那 AI 想「帮客户新建一张销售单」怎么办？**走业务接口，不走 SQL。** ERP 暴露的是一组业务动作接口：取号、保存、审核、反审核、删除…… AI 只能「调用动作」，不能在数据库里直接改数据。这样做有三个好处： 1. **天然的权限边界**：AI 能做的事，就是它被允许调用的那几个动作，不会越权 1. **业务规则仍然生效**：单据编号规则、审核校验、必填校验全在原有链路里，AI 绕不过去 1. **可审计**：所有变更都留下单据操作痕迹，事后能追到「哪次是 AI 触发的」 >**一条通用原则：给 AI「业务动作」比给 AI「数据库权限」安全一个数量级。** 前者的最坏结果是「多建了一张单」（可撤销），后者的最坏结果是「数据被改坏了」（不可逆）。 ### 5.3 不要给 AI 裸 SQL，给它模板和参数第二个关键设计：**AI 不直接写 SQL。** ERP 里所有的 SQL 都集中存在一张表里（每个 SQL 有唯一编号），业务代码和插件都通过编号引用它。AI 要查数据时，做的是： ``` ```也就是说，**AI 只能在「已经写好、验证过的查询」里选，然后填参数**。这带来三个实际好处： - **不出乱 SQL**：模型偶尔会写出全表扫描、笛卡尔积甚至删库语句，这条路直接堵死 - **权限可控**：能查什么由「有哪些查询模板」决定，而不是由模型的心情决定 - **性能可预测**：模板里的 SQL 都是人工优化过的，不会因为模型写法不同而雪崩 **这里踩过一个很隐蔽的坑**：这套接口的「执行动作」参数有四种取值，其中一种传的是纯编号，另一种传的是「模板编号,查询动作,,参数」这样的复合编号。我们一开始把复合编号传给了「纯编号」那个动作，结果**接口没报错**——它把整串复合编号当成了单据编号去查，于是生成了一条 `where 单据编号 = '10,查询动作,,1'` 的查询，**静默返回空结果**。排查花了小半天，因为日志里一切正常、接口返回 200、只是永远查不到数据。 >**教训**：**静默失败比报错危险得多。** 凡是「查不到数据」的情况，先怀疑参数形态不匹配，再怀疑数据本身不存在。后来我们给这类接口加了「结果为空 + 条件里出现非法字符」的告警——宁可误报，也不要静默。 ### 5.4 知识库要分两套，而且必须先结构化 ERP 的知识分两类，性质完全不同： | | | | |:-:|:-:|:-:| |知识库|内容|使用者| |**实施服务库**|产品架构、模块功能、实施 SOP、调研问卷、导入规范、培训课件、售后 FAQ|售前 / 实施 / 客户| |**二次开发库**|插件开发规范、表结构、接口说明、代码模板、典型场景实现|开发（人和 AI）| **为什么必须分两套**：混在一起的直接后果是检索污染。客户问「这张单据怎么审核」，系统可能会召回一段插件开发代码；开发问「插件怎么读子表」，系统可能召回一段客户培训话术。**两套知识混库，等于两套都变差。** 分类之外，**更重要的是结构化**。我们整理实施知识库时，最有价值的一份不是产品文档，而是**标准实施流程的环节拆解**： ``` ```把这条链拆成结构化阶段后，AI 才能回答「第几步该做什么」「这一步需要客户提供什么」。**如果只扔一堆散文档进去，AI 能做的只是「检索段落」，做不了「生成实施步骤」。** >**经验**：知识库的价值不在于「喂了多少字」，而在于**有没有把流程拆成机器可用的结构**。一份 3000 字的 SOP 拆解，胜过 30 万字散文档。 ### 5.5 动作要有「读回自证」，不能信 AI 的嘴这是最后一条，也是我们后来补上的：**AI 说「已经保存成功」不算成功。** 所有会改数据的动作，都要有一个**可核验的返回**。我们用的办法是：动作执行后返回一个结果字段（例如审核动作返回结果为空表示成功、非空表示失败原因），AI 必须拿到这个返回，并且**再查一次**确认数据真的变了，才能说「完成」。做法很朴素，但解决了一个很现实的问题：**模型会自信地报告成功，包括它其实失败了的时候。** >**原则**：凡是有副作用的动作，**必须「执行 + 读回 + 断言」三步**，断言失败要如实告诉用户失败。宁可说「我不确定是否成功，请你确认一下」，也不要谎报成功。 ## 六、我们踩过的四个坑 **坑 1：知识库越堆越差** 一开始什么都往里塞（幻灯片、截图、会议纪要、过期文档），结果检索质量反而下降。**对策**：知识库要设「版本」和「失效标记」，过期文档必须标死——AI 没有时间观念，它会平等地引用三年前和昨天的内容。 **坑 2：AI 用「通用 ERP 常识」回答我们的产品问题** 问「你们的审批流怎么配」，模型会用它训练语料里的通用审批流知识作答，听起来很对，但和我们系统的实际路径不一致。**对策**：回答必须能落到具体文档/接口/数据的引用上，落不到就明确说「文档里没写」——这比编一个像样的答案有用得多。 **坑 3：同一个问题，不同客户得到不同答案** 改了知识库之后，老客户的答案变新、新客户的答案变旧，出现口径不一致。**对策**：把关键口径（价格、模块边界、功能有无）做成**固定事实表**而不是散在文档里，让 AI 优先引用它。 **坑 4：把「能答」当成「能交付」** AI 能答出「怎么配置权限」，不代表它知道「这个客户的组织结构适合哪种权限模型」。**对策**：分清「知识型问题」（AI 直接答）和「判断型问题」（AI 给选项 + 顾问拍板），并在提示里明确标注当前这条属于哪类。 ## 七、边界：我们不做什么 - **不做「全自动上线」**：AI 出草案，人审后再执行。实施出错的代价远高于顾问省下的时间 - **不让 AI 直接改数据库**：写操作一律走业务动作接口（见 5.2） - **不让 AI 代替顾问做承诺**：工期、价格、定制范围，必须由人确认 - **不做没有返回值的动作**：凡执行必读回，读不回就说「无法确认」 ## 八、跑下来什么感觉最大的变化不是「省了多少人」，而是**回答速度**： - 以前客户提个操作问题，等顾问看到消息再回，半天到一天 - 现在基础操作问题当场答，还能顺手查到真实数据自证对顾问来说，省下的是**被反复打断的时间**——这部分其实是最值钱的，因为实施顾问最贵的成本是「上下文切换」。至于「能不能省一个人」，我们的实测结论是：**能省掉的是「重复答疑 + 文档初稿」这部分人力，省不掉项目实施本身的推进工作。** 对小微软件公司来说，这已经够划算了——因为这两块恰好是最难招人、最容易流失的部分。

2026-10-29