智慧园区落地复盘：数智安全问数平台从数据接入到验收的完整实施记录

上一篇我们拆解了平台从自然语言提问到可信 SQL 查询的整体架构。这一篇换一个视角：以智慧园区场景为例，完整记录一次落地实施的全过程——环境准备、语义建模、规则配置、样例冷启动、验证调优，以及最后验收时踩过的坑。配图取自系统实际界面（数据为演示环境）。

1. 项目背景与目标

园区客户已有完整的业务系统在运行，数据持续沉淀在库里：楼宇房源、租客企业、租赁合同、合同账单。业务侧的日常状态是——想查个数，先提需求、再排期、然后等人取数；拿到了数字，还要反复确认口径和出处。

项目目标因此非常明确，且首要目标不是"能回答"，而是"回答可信"：

1. 常见经营问题由业务人员直接发起查询，少等一次取数；
2. 统计口径全局统一，结果按同一套规则呈现；
3. 每个答案可核对——结论、图表、明细、来源俱全；
4. 实施完成后，客户侧团队能够自行维护，而不是永远依赖驻场。

对应平台侧的接入范围：楼宇房源、租客企业、租赁合同、合同账单四类经营数据，不改动原业务表结构。

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. 第五步：验证与调优——质量门禁闭环

配置完成后进入验证阶段。平台提供问数质量门禁做自动巡检：

闭环是三段式的：

1. 保留标准问题，明确每个问题应该查到什么（基准）；
2. 定位出错环节——巡检把问题归因到数据、查询或连接，并给出修复建议；
3. 重复验证——调整后用标准问题复查，直至通过。

验证期间实际遇到的问题分布也符合预期：数据类（源表脏数据、口径理解偏差）多于查询类，查询类多于连接类。质量门禁的价值在于把"模型回答不对"这种模糊抱怨，拆解成了可归因、可修复的工程问题。

8. 交付验收：回答四个问题

验收不谈感觉，只回答四个问题：

9. 实测结果（演示环境数据）

验收后的日常使用中，三类高频问题的实际效果：

业务人员在问数页面选择园区助手后直接提问，无需了解库表结构：

收缴趋势与账单分析的实际呈现：

10. 踩坑与经验总结

复盘整个实施过程，值得记录的经验有五条：

1. 口径核对没有捷径。"空置怎么算""收缴率分母是谁"，必须与业务方逐项确认后写进模型。跳过这一步，后面所有调优都是在错误地基上盖楼；
2. 对象必须分开建模。房源、合同是两个对象，混算必然导致口径漂移——这是语义层存在的第一理由；
3. 先试查再使用，接入层的纪律不能省。脏数据在接入层处理，成本远低于在问答层反复调 Prompt；
4. 标准问题复验是工程纪律，不是可选项。任何规则、样例、模型配置的变更，都要用标准问题集回归一遍；
5. 把样例库当资产经营。每次人工核验都沉淀回 FewShot 样例库，平台能力随使用时间增长，这是"越用越准"的来源。

11. 写在最后

这次园区落地验证了一件事：NL2SQL 的企业级难点不在"生成 SQL"，而在口径治理与质量保障的工程化。语义层建模、样例资产化、质量门禁三件套，是让"问数"从演示走向生产的路径。

园区之外，OA（超期事项）、ERP（延迟订单）、CRM（商机阶段）、财务（未收款项）等系统都可按同样的方法论评估接入：

如果你正在做 ChatBI / NL2SQL 落地，欢迎评论区交流实施细节——尤其是语义层设计和口径治理这两个环节的经验。