上一篇我们拆解了平台从自然语言提问到可信 SQL 查询的整体架构。这一篇换一个视角以智慧园区场景为例完整记录一次落地实施的全过程——环境准备、语义建模、规则配置、样例冷启动、验证调优以及最后验收时踩过的坑。配图取自系统实际界面数据为演示环境。1. 项目背景与目标园区客户已有完整的业务系统在运行数据持续沉淀在库里楼宇房源、租客企业、租赁合同、合同账单。业务侧的日常状态是——想查个数先提需求、再排期、然后等人取数拿到了数字还要反复确认口径和出处。项目目标因此非常明确且首要目标不是能回答而是回答可信常见经营问题由业务人员直接发起查询少等一次取数统计口径全局统一结果按同一套规则呈现每个答案可核对——结论、图表、明细、来源俱全实施完成后客户侧团队能够自行维护而不是永远依赖驻场。对应平台侧的接入范围楼宇房源、租客企业、租赁合同、合同账单四类经营数据不改动原业务表结构。2. 实施前提先把边界和安全谈清楚动工前先约定三件事这一步决定了后面所有配置的形态数据边界明确哪些库表可查、结果范围如何限定。原则是专用只读账号——查询链路对业务库只读从账号层面杜绝误写业务范围首批只覆盖四类经营数据。范围越小验证越充分这一点后面会反复体现环境形态对话模型、相似内容检索模型、Trino 查询引擎与业务数据库按项目环境部署或连接凭证统一管理、查询记录全量留存。3. 第一步数据接入——先试查再使用数据接入统一收敛到Trino 查询网关集中维护连接、浏览库表字段、执行试查。这里的关键纪律是先试查再使用——任何连接在通过试查验证前不进入正式问数链路。试查阶段就能暴露大量问题字段类型不符、空值占比异常、日期格式混乱。这些问题在接入层处理掉比在问答层反复调 Prompt 便宜得多。4. 第二步语义建模——本次实施中最重要的一步平台把模型负责理解表达、业务规则决定如何取数分开处理语义层就是业务规则的载体。围绕园区四类业务对象分别建模建模时的三个关键决策① 分对象建模避免混算。房源数量和合同数量是两个对象上的两个指标。如果混在一个模型里园区有多少空置这类问题就会出现口径漂移。我们按park_building_resource建筑房源资源、park_tenant租客企业、park_contract租赁合同、park_bill合同账单、park_operation_monthly园区月度经营分析分别声明再显式建立关联。② 分清字段用途。名称类字段楼栋名称、费用类型、企业行业用于分类分组数值类字段面积、金额、收缴率用于统计聚合——建模阶段就声明清楚而不是指望模型现场猜。③ 口径逐项与业务方核对。空置的定义、当月收缴率的分母、日期口径与去重规则全部与业务方逐项确认后写入模型。这一步没有捷径5. 第三步回答规则——把统计条件写进模板回答规则Prompt 管理约定了选数据、写查询、解释结果的任务分工并把业务统计条件固化进模板例如收缴率类问题的统计条件按月聚合、实收/应收口径、月份排序方式写进规则后模型每次生成都遵循同一套约束。配套纪律是规则修改后必须用标准问题复查——改了一处规则可能影响另一类问题的生成复验不能省。6. 第四步FewShot 样例库冷启动样例库是平台效果的资产池标准问法与核验过的标准 SQL 配对保存覆盖统计、趋势、明细三类问题运行时由相似内容检索模型召回。冷启动的做法和业务方一起梳理高频问题清单逐条配置并核验。以收缴趋势为例核验后的查询形如示意SELECT bill_month AS 账单月份, ROUND(SUM(paid_amount) * 100.0 / SUM(receivable_amount), 2) AS 收缴率 FROM park_bill GROUP BY bill_month ORDER BY bill_month;每核验一条就沉淀一条。样例库越厚生成越稳——这是平台随使用时间变准的根本机制。7. 第五步验证与调优——质量门禁闭环配置完成后进入验证阶段。平台提供问数质量门禁做自动巡检闭环是三段式的保留标准问题明确每个问题应该查到什么基准定位出错环节——巡检把问题归因到数据、查询或连接并给出修复建议重复验证——调整后用标准问题复查直至通过。验证期间实际遇到的问题分布也符合预期数据类源表脏数据、口径理解偏差多于查询类查询类多于连接类。质量门禁的价值在于把模型回答不对这种模糊抱怨拆解成了可归因、可修复的工程问题。8. 交付验收回答四个问题验收不谈感觉只回答四个问题验收问题核对方式数据对不对与原系统按相同时间和范围核对问题理解对不对对象、条件和计算方式符合提问结果能不能用图表清楚、明细可查、失败有提示后续能不能维护规则变化后可更新并重新验证9. 实测结果演示环境数据验收后的日常使用中三类高频问题的实际效果问题平台回答业务用途各楼栋空置房源有多少间合计 7175 间最高楼栋 891 间、占比约 12.42%来源可查资源盘点、招商排查每月收缴率如何变化按月绘制趋势曲线异常月份可下钻收费跟踪、异常核对各费用类型的应收和实收是多少费用分布与对比可核对账单明细对账、欠费排查业务人员在问数页面选择园区助手后直接提问无需了解库表结构收缴趋势与账单分析的实际呈现10. 踩坑与经验总结复盘整个实施过程值得记录的经验有五条口径核对没有捷径。空置怎么算收缴率分母是谁必须与业务方逐项确认后写进模型。跳过这一步后面所有调优都是在错误地基上盖楼对象必须分开建模。房源、合同是两个对象混算必然导致口径漂移——这是语义层存在的第一理由先试查再使用接入层的纪律不能省。脏数据在接入层处理成本远低于在问答层反复调 Prompt标准问题复验是工程纪律不是可选项。任何规则、样例、模型配置的变更都要用标准问题集回归一遍把样例库当资产经营。每次人工核验都沉淀回 FewShot 样例库平台能力随使用时间增长这是越用越准的来源。11. 写在最后这次园区落地验证了一件事NL2SQL 的企业级难点不在生成 SQL而在口径治理与质量保障的工程化。语义层建模、样例资产化、质量门禁三件套是让问数从演示走向生产的路径。园区之外OA超期事项、ERP延迟订单、CRM商机阶段、财务未收款项等系统都可按同样的方法论评估接入如果你正在做 ChatBI / NL2SQL 落地欢迎评论区交流实施细节——尤其是语义层设计和口径治理这两个环节的经验。