前两篇写过这套系统的架构和落地评论区不少朋友想看更细的。这篇换个玩法挑一条真实的请求从进站到出站一站一站看它都经历了什么。背景交代一句。底层是跑了挺久的智慧园区综合管理平台楼宇房源、租客、合同、账单、物联设备的数据都在里面。上面叠的这层是数智安全问数平台负责把大白话变成查询。// 一条请求的五站旅程STEP 1进站。运营在页面里敲了一句各楼栋空置率排个序。这条请求先到问数页面除了问题本身还带上了当前用户的身份和所属园区。身份的用处后面会看到。STEP 2听懂。模型接到问题配合两样东西把它翻译成结构化的意图。一样是业务数据模型里面登记着空置对应哪些表哪些字段、按什么口径算。另一样是 FewShot 样例库存着历史问法和正确写法的配对。这一步的输出大概长这样示意。{ intent: vacancy_rank, metric: vacancy_rate, group_by: building, order: desc, scope: park_001 }翻译歪了后面全歪所以这步是我们盯得最紧的地方。错例会持续补进样例库。STEP 3取数。结构化意图交给 Trino 查询网关。网关按模型层的映射生成 SQL去连各处的源库。源库账号是只读的查多快、扫多少都有上限。生成的 SQL 和扫描量会记进审计日志。谁在什么时候问过什么以后翻日志都能翻到。STEP 4出结果。数据回来后组装成三件套结论一句、图表一张、明细一页。来源也一并附上查了哪张表、口径是什么版本都写在答案底下。运营看到数不对能顺着来源找到原因。STEP 5回站。整条链路走完答案回到页面。这次查询本身也会作为一条新样本进样例库问得多了下次同类问题就答得更稳。这条链路上的三个闸门模型只读不写。网关只连只读账号。审计把每一次查询都记下来。三道闸都在生产库才敢放心让它碰。// 三道闸门缺一不可走完这一趟你会发现模型在这条链路里只占一小段更多的工作在模型外面映射、样例、闸门、日志。这类系统的功夫在诗外。下篇打算写写样例库怎么运营、错例怎么收。想看的留言区吱一声。