大模型企业级落地：AI 问数识别企业内部黑话与业务控制权转移

在企业数字化转型进程中，AI 问数系统凭借 “自然语言转 SQL”（Chat2SQL）能力，大幅降低了业务人员数据分析门槛。然而，通用大模型因未覆盖企业内部黑话（如 “客户发货量”“销售发货量”“实单量”），常出现 “黑话无法识别→SQL 生成偏差→数据查询失效” 的问题。本方案通过 “黑话知识库构建 + 细化系统流程 + 多任务并行处理”，实现黑话精准识别与业务端控制权转移，彻底解决 IT 与业务的认知差难题，为企业提供可落地的 AI 问数解决方案。

一、企业级 AI 问数的核心痛点：以 “客户发货量 / 销售发货量” 为例的黑话识别失效

通用 Chat2SQL 场景中，大模型可将 “查询 2024 年 5 月的订单量” 转化为基础 SQL，但企业内部问数需求往往围绕 “客户发货量”“销售发货量” 这类带私有规则的黑话展开，例如 “查 2024 年 Q3 华东区域客户发货量（按 SO PGI Date 统计）”“对比 2024 年 Q3 销售发货量与实单量差异”。这些黑话对应数据库中特定的字段筛选、日期映射与业务逻辑，通用大模型因未接触过企业私有规则，会出现两类典型失效情况，直接导致数据查询结果与业务预期脱节：

1. 字段与逻辑错配：无法识别 “客户发货量” 的专属规则

“客户发货量” 在企业业务中并非 “所有客户的发货数据总和”，而是有明确限定条件：需按 “SO PGI Date（发货确认日期）” 统计，且仅包含 “Material Group 为 1101/1102/1111/1112”“Resources Type 为 For Sale/For Sale-non-full container” 的发货数据，最终汇总 “MW（计量值）”。但通用大模型无法识别这些私有规则，会出现以下错误：

• 日期字段错配：将 “SO PGI Date” 误判为 “发货申请日期（Shipment Apply Date）” 或 “订单创建日期（Order Create Date）”，导致统计的是 “已申请未确认” 或 “已下单未发货” 的数据，与 “客户发货量” 需 “已确认发货” 的业务定义完全不符；

• 筛选条件缺失：忽略 “Material Group” 和 “Resources Type” 的限定，将非销售类物料（如 1201 类辅料）、非销售用途资源（如 For Rental 租赁类）的发货数据纳入统计，导致客户发货量结果虚高 30% 以上；

• 聚合字段错误：未识别 “汇总 MW 量” 的要求，误将 “发货订单数（Shipment Count）” 或 “发货重量（Weight）” 作为结果字段，输出 “2024 年 Q3 客户发货量 800 单”，而非业务所需的 “1100 MW”。

2. 术语混淆：无法区分 “客户发货量” 与 “销售发货量” 的差异

部分企业中 “客户发货量” 与 “销售发货量” 虽名称相似，但业务规则与数据来源完全不同：“客户发货量” 关联customer_shipments表，侧重 “客户实际收到的货量”；“销售发货量” 关联sales_shipments表，侧重 “销售团队发起的发货量”，且需额外筛选 “销售订单类型 = 直销（Direct Sales）”。通用大模型因无业务知识储备，会出现以下混淆问题：

• 数据源错配：查询 “销售发货量” 时，误调用customer_shipments表数据，遗漏 “销售订单类型” 筛选条件，导致数据包含经销商代发的非直销订单，与业务需求偏差；

• 规则复用错误：将 “客户发货量” 的 “Resources Type” 规则直接套用至 “销售发货量”，忽略销售发货量需 “排除样品发货（Sample Shipment）” 的额外规则，导致结果包含非销售用途的样品数据，影响业务决策准确性。

这种 “黑话识别失效” 直接导致 Chat2SQL 在企业级场景 “水土不服”—— 业务人员需反复修正查询需求，IT 团队需手动调整 SQL，不仅效率低下，还可能因规则传递偏差导致数据错误，影响销售复盘、物流调度等核心业务环节。而工程化方案的核心，就是通过 “规则 + 工具” 组合，为大模型补上 “客户发货量 / 销售发货量” 这类企业私有黑话的业务知识，解决识别失效问题。

二、工程化核心方案：构建 “黑话知识库 + 细化系统流程” 闭环

针对黑话识别与多任务处理需求，方案以 “黑话知识库” 为业务知识载体，以 “轻量化 AI 系统” 为执行工具，设计 “需求输入→黑话匹配→系统路由→任务分解→规则增强→SQL 生成→SQL 执行→结果汇总” 的完整流程，支持单任务精准执行与多任务并行处理，无需复杂的大模型微调。

1. 基础支撑：黑话知识库的结构化设计（业务端自主维护）

黑话知识库是系统识别黑话、执行规则的核心基础，需包含 “黑话术语→数据逻辑→业务场景→关联数据源” 的完整映射，且支持业务人员通过可视化界面自主维护，无需技术介入。以下为核心业务名词的知识库配置实例：

（1）客户发货量 / 销售发货量配置

配置项	客户发货量配置内容	销售发货量配置说明
黑话术语	客户发货量	销售发货量（注：若企业中两者规则一致，可设为 “同义词”，共享同一规则）
所属业务域	物流履约 - 客户交付	物流履约 - 销售执行
数据逻辑描述	按 SO PGI Date（发货确认日期）统计的客户交付 MW 量，需满足：1. Material Group IN (‘1101’,‘1102’,‘1111’,‘1112’)；2. Resources Type IN (‘For Sale’,‘For Sale-non-full container’)；最终汇总 MW 字段值	按 SO PGI Date 统计的销售类发货 MW 量，需满足：1. Material Group IN (‘1101’,‘1102’,‘1111’,‘1112’)；2. Resources Type IN (‘For Sale’,‘For Sale-non-full container’)；3. 销售订单类型 = 直销（Direct Sales）；4. 排除样品发货（Shipment Type != ‘Sample’）；最终汇总 MW 字段值
关联表 / 字段	表：customer_shipments（客户发货表）；字段：SO PGI Date（发货确认日期）、Material Group（物料组）、Resources Type（资源类型）、MW（计量值）	表：sales_shipments（销售发货表）；字段：SO PGI Date、Material Group、Resources Type、Sales Order Type（销售订单类型）、Shipment Type（发货类型）、MW
维护人 / 更新时间	张物流 / 2024-10-23	李销售 / 2024-10-23
状态	启用（enabled）	启用（enabled）

（2）实单量配置

配置项	实单量配置内容
黑话术语	实单量
所属业务域	销售执行
数据逻辑描述	已确认且未取消的实际订单 MW 汇总，需满足：1. 订单状态 = 已确认；2. 取消状态 = 未取消；3. Material Group IN (‘1101’,‘1102’,‘1111’,‘1112’)；4. 销售订单号 NOT LIKE ‘S%’；按 Order Month 分组
关联表 / 字段	表：actual_orders（实单表）；字段：Order Month（订单月份）、Order Status（订单状态）、Cancel Status（取消状态）、Material Group、Sales Order No、MW
维护人 / 更新时间	王执行 / 2024-10-22
状态	启用（enabled）

（3）销售预测量配置

配置项	销售预测量配置内容
黑话术语	销售预测量
所属业务域	销售预测
数据逻辑描述	按 Sales Estimation Month 统计的销售预估 MW 量，需满足：1. Sales Estimation Month = 查询时间（按月份截断，查年拆分为当年所有月）或 =‘Carry over’；2. Material Group IN (‘1101’,‘1102’,‘1111’,‘1112’)；3. PO report IN (’ 可用 PO’,’ 可 PO - 无价不参与 ASP 运算 ‘,’ 可用 PO-B/C 类不参与 ASP 运算 ')；4. Sales Order No NOT LIKE ‘S%’
关联表 / 字段	表：sales_estimation（销售预测表）；字段：Sales Estimation Month、Material Group、PO report、Sales Order No、MW
维护人 / 更新时间	李销售 / 2024-10-22
状态	启用（enabled）

知识库配置关键说明

• 日期字段明确化：如客户发货量指定 “SO PGI Date”，避免 AI 误匹配 “订单创建日期” 等其他字段；

• 多条件精准筛选：严格按业务规则配置 Material Group、Resources Type 等筛选值，确保数据范围准确；

• 聚合逻辑统一化：明确汇总字段（如 MW）与聚合函数（如 SUM ()），避免单位或计算方式混淆；

• 术语差异区分：针对 “客户发货量” 与 “销售发货量” 的规则差异，在配置中分别补充专属筛选条件（如销售发货量的 “销售订单类型”“排除样品”），避免混淆。

2. 核心流程：细化 AI 问数系统的全链路执行逻辑

系统各模块分工明确，新增 “系统路由” 实现多任务分发，拆解 “任务分解”“规则增强” 确保逻辑清晰，各模块联动如下：

模块	核心功能	关键操作与知识库联动逻辑
需求解析模块	识别需求中的黑话术语、任务数量（单 / 多任务）、核心关键词（时间、聚合维度）	如 “查询 2024 年 Q3 客户发货量和实单量”，拆分为：时间 = 2024Q3、黑话 = 客户发货量 + 实单量、任务数 = 2
黑话匹配模块	基于黑话检索知识库，匹配业务规则与关联数据源	匹配 “客户发货量→customer_shipments 表规则”“实单量→actual_orders 表规则”，获取筛选条件与聚合逻辑
系统路由模块	按业务域、关联数据源，将多任务分发至并行数据节点	客户发货量属物流履约域、实单量属销售执行域，路由至两个节点并行处理，避免串行延迟
任务分解模块	将子任务拆解为 “时间筛选、业务筛选、聚合维度、结果字段” 四要素	客户发货量子任务拆解：时间 = 2024-07 至 2024-09、业务筛选 = Material Group+Resources Type 规则、聚合 = SO PGI Date 月份、结果 = SUM (MW)
规则增强模块	合并子任务要素与知识库规则，生成 “结构化增强需求”	客户发货量增强需求：“查询 2024Q3 客户发货量，筛选 Material Group IN (‘1101’,…)、Resources Type IN (‘For Sale’,…)，按 SO PGI Date 月份汇总 MW”
Chat2SQL 生成模块	基于增强需求生成独立 SQL	为每个子任务生成符合规则的 SQL，确保字段、筛选条件完全匹配知识库配置
SQL 执行模块	校验 SQL（语法 / 权限），并行执行查询并返回原始数据	禁止删改操作，并行执行客户发货量与实单量 SQL，提升多任务效率
结果汇总模块	按统一维度（如月份）整合多任务数据，生成易懂报表	按 2024-07/08/09 月份整合客户发货量与实单量，标注日期字段来源，支持 Excel 导出

三、多任务案例演示：查询 2024 年 Q3 客户发货量与实单量

以业务人员高频需求 “查询 2024 年 Q3 客户发货量和实单量，按月份汇总对比” 为例，完整演示系统全流程执行过程，验证方案落地效果。

1. 步骤 1：需求解析与黑话匹配

• 需求解析：输入需求后，系统识别关键信息：

  • 时间范围：2024 年 Q3（2024-07-01 至 2024-09-30）；

  • 黑话术语：客户发货量、实单量（任务数量 = 2）；

  • 聚合维度：均按 “月份” 汇总（客户发货量按 SO PGI Date，实单量按 Order Month）；

• 黑话匹配：检索知识库，获取两条黑话的核心规则（如前文配置所示），明确关联表、筛选条件与聚合逻辑。

2. 步骤 2：系统路由与任务分解

• 系统路由：客户发货量关联customer_shipments表（物流履约节点），实单量关联actual_orders表（销售执行节点），系统自动分发至两个并行节点；

• 任务分解（客户发货量）：

子任务要素	分解结果（基于知识库规则）
时间筛选	SO PGI Date BETWEEN ‘2024-07-01’ AND ‘2024-09-30’
业务筛选	Material Group IN (‘1101’,‘1102’,‘1111’,‘1112’)；Resources Type IN (‘For Sale’,‘For Sale-non-full container’)
聚合维度	SO PGI Date（按月份截断，格式：2024-07）
结果字段	SUM (MW)（客户发货量，单位：MW）

• 任务分解（实单量）：

子任务要素	分解结果（基于知识库规则）
时间筛选	Order Month BETWEEN ‘2024-07’ AND ‘2024-09’
业务筛选	Order Status = 已确认；Cancel Status = 未取消；Material Group IN (‘1101’,‘1102’,‘1111’,‘1112’)；Sales Order No NOT LIKE ‘S%’
聚合维度	Order Month（格式：2024-07）
结果字段	SUM (MW)（实单量，单位：MW）

3. 步骤 3：规则增强与 SQL 生成

• 规则增强（客户发货量）：

  “查询 2024 年 7 月 1 日至 9 月 30 日客户发货量，筛选条件：Material Group 为 1101、1102、1111、1112，Resources Type 为 For Sale、For Sale-non-full container，按 SO PGI Date 月份分组，汇总 MW 字段作为客户发货量，单位 MW”；

• 生成 SQL（客户发货量）：

SELECT 
    DATE_TRUNC('month', "SO PGI Date")::DATE AS shipment_month,
    SUM(MW) AS customer_shipment_mw
FROM 
    customer_shipments
WHERE 
    "SO PGI Date" BETWEEN '2024-07-01' AND '2024-09-30'
    AND "Material Group" IN ('1101','1102','1111','1112')
    AND "Resources Type" IN ('For Sale','For Sale-non-full container')
GROUP BY 
    shipment_month
ORDER BY 
    shipment_month;

• 规则增强（实单量）：

  “查询 2024 年 7 月至 9 月实单量，筛选条件：Order Status = 已确认、Cancel Status = 未取消、Material Group 为 1101-1112、Sales Order No 不以 S 开头，按 Order Month 分组，汇总 MW 字段作为实单量，单位 MW”；

• 生成 SQL（实单量）：

SELECT 
    "Order Month" AS order_month,
    SUM(MW) AS actual_order_mw
FROM 
    actual_orders
WHERE 
    "Order Month" BETWEEN '2024-07' AND '2024-09'
    AND "Order Status" = '已确认'
    AND "Cancel Status" = '未取消'
    AND "Material Group" IN ('1101','1102','1111','1112')
    AND "Sales Order No" NOT LIKE 'S%'
GROUP BY 
    order_month
ORDER BY 
    order_month;

4. 步骤 4：SQL 执行与结果汇总

• SQL 执行：系统先对两条 SQL 进行双重校验 —— 语法校验确保无字段错误、逻辑冲突（如 “SO PGI Date” 格式匹配），权限校验禁止删改表数据、仅开放查询权限。校验通过后，将两条 SQL 分发至对应数据节点并行执行，避免串行处理导致的耗时叠加。最终从数据库获取原始数据：

  • 客户发货量（按 SO PGI Date 月份）：2024-07（1100 MW）、2024-08（1450 MW）、2024-09（1300 MW）；

  • 实单量（按 Order Month 月份）：2024-07（1200 MW）、2024-08（1500 MW）、2024-09（1350 MW）；

• 结果汇总：系统按 “月份” 统一维度整合数据，自动标注两个指标的日期统计依据（避免业务人员混淆 “发货确认日期” 与 “订单月份”），生成可视化对比报表，并支持导出 Excel、CSV 格式用于二次分析：

月份	客户发货量（MW）（统计依据：SO PGI Date）	实单量（MW）（统计依据：Order Month）	差异（实单量 - 发货量）	差异占比（差异 / 实单量）
2024-07	1100	1200	100	8.3%
2024-08	1450	1500	50	3.3%
2024-09	1300	1350	50	3.7%
合计	3850	4050	200	4.9%

四、核心价值：业务端控制权转移，彻底破解 “IT - 业务认知差”

传统 AI 问数系统中，“客户发货量”“销售发货量” 等黑话的规则维护、多任务 SQL 编写均依赖 IT，业务人员需反复解释 “SO PGI Date 是什么”“Material Group 为什么只选 1101-1112”，IT 因不熟悉业务细节易出现规则遗漏（如忽略 “Resources Type=For Sale”），导致数据偏差需多次返工。本方案通过 “知识库 + 流程优化”，将三大核心控制权完全转移给业务端，从根源解决认知差问题：

1. 规则定义权：业务人员 “自主掌控黑话逻辑”

业务端无需技术背景，通过可视化界面即可完成规则配置与更新，确保规则与业务同步。例如：

• 当 “销售发货量” 需新增 “排除海外仓发货（Warehouse Type != ‘Overseas’）” 规则时，物流专员可直接在知识库 “销售发货量” 条目下，通过 “字段选择 + 条件设置”（下拉选择 “Warehouse Type”，设置 “不等于”“Overseas”）完成配置，系统自动将规则同步至后续 SQL 生成环节；

• 若 “客户发货量” 的 Material Group 新增 “1113” 类物料，业务人员仅需在筛选条件中补充该值，无需等待 IT 修改代码，1 分钟内即可完成规则迭代。

2. 多任务控制权：业务人员 “自由组合与调整需求”

业务人员可根据分析场景灵活组合多任务，系统自动完成路由与执行，无需依赖 IT 编写复杂关联 SQL。例如：

• 提出 “查询 2024 年 Q3 华东区域客户发货量、销售发货量、实单量对比” 需求时，系统自动匹配三个黑话规则，识别 “华东区域” 对应 “Region Code IN (‘East-01’,‘East-02’)”（需提前在知识库补充区域编码映射），路由至三个并行节点执行，最终按 “区域 + 月份” 整合数据；

• 若需调整时间范围（如从 “Q3” 改为 “Q2+Q3”），业务人员仅需在需求输入界面修改时间参数，系统自动更新 SQL 筛选条件，无需重新沟通需求。

3. 结果校验权：业务人员 “一键回溯纠错”

生成结果后，业务人员可自主校验数据准确性，无需依赖 IT 排查问题。系统提供 “规则溯源” 功能：点击报表中某一指标（如 “客户发货量”），即可查看对应的黑话规则、生成的 SQL 语句、原始数据来源 —— 若发现 7 月发货量数据异常（如遗漏 “Resources Type=For Sale-non-full container”），可直接在知识库修正规则，点击 “重新查询” 即可获取正确结果，整个纠错过程不超过 5 分钟。

五、降低使用门槛：让非技术业务人员 “会用、易用、敢用”

为确保物流、销售等非技术部门顺畅使用系统，方案从 “输入 - 维护 - 输出” 全环节设计轻量化操作，适配业务人员使用习惯：

1. 需求输入：“零自然语言” 可视化配置

提供 “多任务组合界面”，业务人员无需手动输入复杂需求：

• 点击 “添加子任务”，下拉选择 “客户发货量”“实单量” 等黑话；

• 通过日历组件选择时间范围（如 “2024-07 至 2024-09”），勾选聚合维度（如 “月份”“区域”）；

• 系统自动生成完整需求描述（如 “查询 2024 年 Q3 客户发货量和实单量，按月份汇总”），业务人员确认后即可提交，避免因自然语言歧义导致的需求误解。

2. 规则维护：自然语言“无代码” 条件配置

知识库维护界面采用直接自然语言描述查询条件，无需任何编程或者SQL基础。配置好后，通过AI进行核对描述是否明确，并给出修改意见，降低规则维护难度，也避免维护黑话规则模糊的问题。

3. 结果输出：“场景化” 报表与预警

避免输出纯数据表格，针对不同业务场景生成可视化报表：

• 销售部门：生成 “实单量 - 发货量差异趋势图”，自动标注差异占比超 10% 的月份，触发预警提示；

• 物流部门：生成 “各区域发货量分布热力图”，直观展示华东、华北等区域的履约情况；

• 报表支持 “一键分享”，可直接发送至企业微信、邮件，无需手动整理格式。

六、总结：从 “黑话识别” 到 “业务自主” 的 AI 问数升级

本方案的核心价值并非仅解决 “客户发货量”“销售发货量” 等黑话的识别问题，而是通过 “黑话知识库 + 细化流程 + 轻量化操作”，实现 AI 问数系统从 “技术工具” 到 “业务伙伴” 的转变：

• 对业务端：彻底摆脱对 IT 的依赖，从 “被动等待数据” 变为 “主动掌控分析”，将数据分析时间从 “天级” 压缩至 “分钟级”，让业务人员聚焦于 “数据解读” 而非 “需求沟通”；

• 对 IT 端：减少重复的 SQL 编写、规则调整工作，将精力投入到系统稳定性、数据安全等核心技术环节，降低运维成本；

• 对企业端：打通 “业务规则 - 数据查询 - 决策分析” 的闭环，让数据真正服务于销售复盘、物流优化等业务场景，加速数字化转型落地。