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