很多企业做 AI 知识库时，第一步会想到处理 Word、PDF、PPT。但真正影响经营决策的，往往还在一张张业务数据表里：库存表、销售表、采购表、质量检测表、财务台账、客户清单、物料明细……

企业真正想问的，不只是“这份文档里写了什么”，而是：“哪些物料库存不足？”“本月哪个仓库出库最多？”“最近哪些产品质量异常？”“某个客户今年采购了多少？”“这个组织下面还有多少库存？”这些问题背后，对应的是企业报表查询、经营分析、库存管理、质量追踪和客户运营。

但数据表接入 AI 知识库，并不是简单把数据库连给大模型。因为 AI 如果看不懂字段、编码、状态值和权限范围，就很容易查错表、用错字段，甚至查到不该看的数据。所以，企业要做 AI 查报表、自然语言问数、Text2SQL，第一步不是让大模型直接写 SQL，而是先让 AI 看懂企业自己的业务字段。

这篇文章就讲一个关键问题：数据表进入 AI 知识库前，应该先做哪些语义处理，才能让 AI 查得准、答得稳、用得安全。

很多企业已经有 ERP、MES、WMS、CRM、财务系统，也有大量历史报表和业务数据库。

但问题是，数据虽然都在系统里，业务人员要查一个结果，往往还是要找信息部门导数、写 SQL、做报表，或者在多个系统之间来回切换。

AI 知识库真正有价值的地方，不只是回答文档问题，而是能不能帮业务人员更快查数、看数、理解数据。

但这一步最容易被低估：数据表不是接上就能用，字段也不是给 AI 看一眼就能懂。

企业数据库里的字段，通常不是给普通业务人员看的，而是给系统看的。比如 mtrl_code、store_code、lpn_qty、loc_stat、qlty_stat。业务人员看到这些字段，可能都要问一句：这是什么意思？更不用说 AI。

这些字段背后，其实有明确的业务含义。比如，mtrl_code 是物料编码，store_code 是仓库编码，lpn_qty 是数量，loc_stat 是位置状态，qlty_stat 是质量状态。

问题还不止字段名，很多字段的取值也是编码，比如 loc_stat = 1 表示在库，loc_stat = 2 表示出库；qlty_stat = 2 表示良品，qlty_stat = 3 表示不良品。

如果这些含义没有告诉 AI，它就只能看到一堆英文缩写和数字编码。这时候用户问“现在仓库里有哪些不良品？”，AI 可能不知道“不良品”应该对应哪个字段、哪个取值，进而查错字段或者漏掉条件。

所以，数据表处理的第一步，不是让 AI 直接写 SQL，而是先把表里的技术字段翻译成业务语言。

很多企业想做的，是让业务人员不用写 SQL，也不用反复找技术人员导数，只要直接问一句话，系统就能自动查询数据库。

比如：“库存少于 100 的物料有哪些？”“本月各仓库出库数量排名是多少？”“不良品主要集中在哪些物料上？”“某个组织下面的库存情况如何？”

这就是企业报表查询中的自然语言问数场景，也就是常说的 Text2SQL：用户用自然语言提问，AI 自动生成 SQL，查询数据库，再把结果整理成表格、图表和分析说明。

但在企业真实场景里，Text2SQL 不能简单理解为“让大模型写 SQL”。

因为企业数据库通常有大量业务表、技术字段、状态编码和权限规则。模型如果不知道当前用户能查哪些表、字段是什么意思、编码值代表什么、组织范围怎么限制，就很容易出现查错表、用错字段、漏掉条件，甚至越权查询的问题。

所以，我们的处理思路不是让 AI 一上来就写 SQL，而是先给它一套清晰的业务规则：用户问题 → 获取当前可查询的数据表 → 整理字段含义 → 补充枚举值映射 → 构造模型能理解的表结构说明

这一步的目标，是先让模型弄清楚三件事：

比如，“不良品”不是一个可以凭空理解的词，它可能对应的是某个质量状态字段里的特定取值；“当前仓库”也不是一句简单描述，而是需要结合用户权限、组织范围和当前报表菜单来确定查询边界。

只有这些规则讲清楚之后，AI 才不是“凭感觉查数”，而是在明确的数据范围和业务语义下理解问题、生成 SQL、查询数据。

对企业来说，这一步的价值不只是提升 SQL 生成准确率，更重要的是降低误查、漏查和越权查询风险，让 AI 报表问答真正具备上线条件。

企业数据和普通文档不一样。普通文档通常是“能不能看”，但数据表往往涉及更细的权限。同一个系统里，不同菜单能查的表不一样，不同岗位能看的字段不一样，不同组织能查的数据范围也不一样。

比如，总部用户可以看多个区域的数据，分公司用户可能只能看自己组织下的数据；仓库人员主要看库存相关报表，财务人员才能看金额、成本、价格字段。所以，系统不会把整个数据库都暴露给大模型。

我们的做法是：根据用户编码、菜单编码和当前会话，从后端动态获取当前报表菜单下可查询的数据表、字段清单、基础 SQL 和字段字典。

也就是说，用户在哪个报表页面提问，系统就只给 AI 当前页面允许查询的表和字段。

这样做有两个好处：

这一步看起来像是权限控制，但它其实也是企业 AI 系统能不能落地的关键。因为 AI 查数不能只追求“会回答”，还必须保证“查得对、查得稳、查得合规”。

确定可查询范围后，下一步是整理字段含义。这一步很关键，因为大模型虽然能生成 SQL，但前提是它要知道字段是什么意思。

原始表结构可能是：

对业务人员来说，这很难读；对 AI 来说，也不够清楚。经过处理后，它会变成类似这样的说明：

这样，用户问“有哪些在库的不良品？”模型就能知道：“在库”对应 loc_stat = 1，“不良品”对应 qlty_stat = 3。

这一步看起来简单，但它决定了 AI 能不能把用户的自然语言问题，正确转换成数据库查询条件。

如果字段语义没有整理清楚，AI 生成 SQL 时就会出现很多看似“小错误”、但对业务影响很大的问题。比如，库存状态用错、质量状态漏掉、组织范围没加、时间条件不准确，最后导致查询结果看起来像真的，实际上却不可信。

字段含义整理好后，系统会把这些信息组织成 Prompt Schema。可以把它理解成一份给大模型看的“表说明书”。

这份说明书会告诉模型：有哪些表，每张表有哪些字段，字段中文意思是什么，字段有哪些取值，哪些取值对应哪些业务含义，当前查询应该参考哪个基础 SQL，当前用户应该查哪个组织范围的数据。

比如用户问：“查询当前仓库中库存数量小于 100 的良品物料。”模型看到的不是一堆陌生字段，而是：库存表里有物料编码、数量、位置状态、质量状态；“在库”对应某个状态值；“良品”对应某个质量状态；数量字段可以用来做小于 100 的筛选。

有了这份说明书，模型生成 SQL 的准确率会高很多。类似的 Prompt Schema 形式包括库存表中包含物料编码、数量、位置状态、质量状态，并将状态值与“在库、出库、良品、不良品”等业务含义对应起来。

换句话说，Prompt Schema 不只是提示词，而是把企业数据表转化为 AI 可理解、可约束、可查询的关键桥梁。

假设用户问：“当前仓库里有哪些在库的不良品？”如果没有做字段语义处理，AI 只看到 loc_stat、qlty_stat、lpn_qty、mtrl_code，它可能不知道要查哪个字段。

但经过处理后，系统会告诉模型：mtrl_code 是物料编码，lpn_qty 是数量，loc_stat 是位置状态，loc_stat = 1 表示在库；qlty_stat 是质量状态，qlty_stat = 3 表示不良品。

这时模型就能把用户问题转成更明确的查询逻辑：查库存表，筛选位置状态为在库，筛选质量状态为不良品，返回物料编码和数量等信息。

用户看到的结果也不应该是技术字段，而应该是业务人员能读懂的结果：

这就是数据表语义处理的价值：AI 不只是要“查到数据”，还要把数据翻译成业务人员真正看得懂、用得上的表达。否则，业务人员看到一堆字段名和状态码，还是需要再找技术人员解释，AI 的价值就打了折扣。

如果企业已经有大量业务系统和数据库，比如 ERP、MES、WMS、CRM、财务系统、供应链系统，那么数据表接入 AI 知识库时，通常都会遇到类似问题：

这些问题如果不提前处理，后面即使接入了大模型，也很难支撑企业报表问答和经营分析。

所以，数据表处理的重点，是把企业已有的数据表，转化成 AI 能理解、能约束、能查询的业务语义资产。

这类能力尤其适合下面几类企业：

对这些企业来说，数据表接入 AI 知识库，不只是一个技术功能，而是业务系统智能化升级的重要入口。

刘守国 手机/微信：13533786006

李   丹 手机/微信：18565067696

《“具智AI”知识专栏》由广东省制造业协会人工智能与机器人专委会与中山大学智能软件研究中心联合打造，由中山大学等高校专家定期分享人工智能与机器人最前沿技术硬核知识。

图片来源于网络，如有侵权请联系删除

技术支持：何笑雨

编辑：刘颖、叶健文、吴伟佳