QUEST LOG · 园区数字化 · 实施复盘
NL2BI · 数据网关 · 语义建模 · 一线实施笔记
▲ LEVEL 1 · 需求进来了
接到需求那天我心里嘀咕,这有啥难的,大模型接个数据库,写个 SQL 生成器不就完了。
真上手才知道,生成 SQL 只占两成工作量。剩下八成,全在数据怎么接、口径怎么定、错了怎么兜。本文拿园区这个场景做样本,把整个实施过程按顺序捋一遍,坑都标出来。
先交代背景。要接的业务系统是一套智慧园区管理平台,综合管理端跑在 Web 上,配套移动管理端、租客端和数据大屏。核心数据全在综合管理平台里,粗数一下有十个模块,从空间资产、招商、租赁合同,到财务交易、运营服务、智慧物联。
01 选战场
别贪心,先接四类数据
十个模块全接是不现实的,语义建模的工作量会爆炸。我们挑了业务方问得最多的四类。
空间资产,项目、楼栋、房源三层结构,状态字段决定「空置」怎么算。客商档案,租客企业的主数据。租赁合同,含电子签和归档,租期、免租期、递增条款都在这里。财务交易,应收账单、实收流水、发票,收缴率就靠它算。
挑选标准很简单,拿历史取数工单统计一下,八成的临时查询落在这四类里。剩下两成,等跑稳了再说。
02 连接层
只读账号,一个字都不能少
这一步没有技术难度,有政治难度。业务系统团队一听「外部平台要连生产库」,第一反应都是拒绝,换我我也拒绝。
最后谈下来的方案是这样。给问数平台开专用只读账号,权限收到具体 schema,业务库一行数据都改不了。中间架一层 Trino 查询网关,所有查询从网关走,业务库对问数平台完全隐身。每次查询带身份和问题原文,落日志。
这个方案说服业务方的关键就一句,你们的数据对我只读,我的每一次动作对你可查。
03 语义层
口径之争,占了整个工期的一半
我以为建模就是给表和字段起别名。天真了。
第一个坑,「空置房源」四个字,招商部、物业部、财务部的理解完全不同。含不含未交付楼栋,装修期算不算空置,预定未签约的算不算。这三个问题吵了一下午,最后形成的口径写进了业务数据模型里,作为唯一计算依据。
第二个坑,收缴率的分母。按应收算还是按到期应收算,差异能到好几个点。这里我的建议是别自作主张替业务方定,把两种口径都配上,让它们在模型里并存,用的时候按问题里的措辞路由。
技术上的教训是,语义模型文档要跟数据库的字典同步维护。业务系统一发版改了字段,模型没跟上,问数平台就开始一本正经地胡说。我们后来把「模型字段核对」挂进了业务系统的发版流程。
04 回答层
Prompt 规则和样例库,兜住下限的
模型自己发挥是下限游戏,配置才是下限保障。我们配了两层。
一层是回答规则。查不到就说查不到,禁止编数。涉及金额的回答必须带明细入口。图表类型按问题意图固定,趋势问题出折线,对比问题出柱状,明细问题直接上表格,不给模型自由发挥的空间。
另一层是 FewShot 样例库。把历史问过的真实问题和标准答案沉淀进去,用户问法再刁钻,命中的是人工校过的模板。这个库要持续养,每次人工纠错的结果都回灌进去。跑得越久越准,这大概是整个系统里唯一有复利的东西。
对了,样例库里那些问法别自己编。让业务同事口述他们平时怎么问,口语里的坑比你想的多得多。
05 验证
五连问,一把尺子量到底
上线前我们拿一组固定问题做回归,从粗到细五个层级。
问总量,空置房源一共多少间。问对比,各楼栋空置放一起比。问趋势,近半年收缴率怎么走。问对账,本月各费用类型应收和实收。问明细,把空置房源的楼栋楼层面积列出来。
每一问的答案都拿人工算的数去对,口径对不上就回语义层改,改完重跑全套。这五连问后来成了验收标准,也成了业务方信任度曲线的起点。头两周他们拿着计算器抽查,后来就不抽了。
06 踩坑清单
血泪条目,按疼的程度排序
语义口径没白纸黑字定下来就开干,返工成本最高。先吵架,后建模。
业务系统发版不通知问数侧,字段一改全线安静挂掉。发版流程里加一道模型核对,五分钟的事。
低估了「追问」的实现难度。用户问完空置接着问「那明细呢」,上下文要接得住。多轮会话的上下文设计别省。
图表类型让模型自己选,它会给你惊喜,惊的那种。按意图固定映射,朴素但有效。
演示数据不脱敏。只读账号保住了写入安全,保住不了截图外流。演示环境单独拉一份脱敏数据,这钱不能省。
复盘下来,这套东西的技术分量没有想象中重,重的全在协作。跟业务方对口径,跟业务系统团队谈权限,把每一次纠错沉淀回样例库。技术只负责把这三件事的结果执行出来。
如果你也要做类似的事,我的建议压缩成一句。先拿四类数据、五个问题跑通最小闭环,跑通了再谈规模。
下次打算写写查询网关那层的具体配置,包括怎么控制慢查询。有兴趣的留个言,写的时候好歹知道有人在等。
- QUEST CLEAR -
你在做 NL2SQL 或者 BI 问答类项目吗?口径管理那一步你们是怎么解的,评论区交换一下打法。