去年年初我们数据团队接了一个让我头疼很久的活儿业务部门每天都在钉钉群里追着要数今天问华东区上个月退货率为什么涨了明天问新客首单转化掉了几个点后天又问帮我拉一下最近90天高价值用户的复购明细。这些需求单看都不难但架不住量大、口径杂、时段急几个分析师每天不是在写SQL就是在解释为什么数跟BI看板不一样。我们自己内部也上过自助BI、做过指标平台但业务同学普遍反馈不会用不会写条件看板是固定的、问题却是活的。后来我们决定试试一条新路把LLM塞进自助分析流程里让用户直接用大白话问数。这个项目前后做了三个多月踩了不少坑今天把这套智能化自助分析系统的搭建过程、架构取舍和上线后的真实表现完整记录下来希望给正在考虑同样方案的同学一些参考。1. 为什么自助分析喊了这么多年最后还得靠LLM来补这一环先说清楚一个背景市面上不是没有自助分析工具Tableau、Power BI、帆软包括我们自研的指标平台都算成熟产品。但自助这两个字对业务同学来说一直是个伪命题。工具的筛选、联动、钻取功能再强前提是用户脑子里得先有一个该看什么维度、该切什么条件、该对什么口径的框架。可现实是业务同学脑子里装的是经营问题不是数据结构。他问的是为什么这个月新客少了背后隐含的其实是新客定义是什么、跟哪个表关联、时间怎么对齐、和上月比还是和年初比。这个从业务语言到技术语言的翻译过程传统工具一直做得不好只能靠人来弥补——于是取数需求还是源源不断流向分析师。1.1 一线观察取数工单的真实构成和浪费在哪里我翻过我们团队半年的工单记录发现一个规律大约70%的需求其实是结构化程度很高的查询。什么意思呢就是用户要的表、字段、过滤条件基本都说得清楚只是他不会写SQL或者不想学BI工具。比如查一下1月到3月每个区域每个品类的销售额按降序排这种需求本质是固定模板但每天换个时间段、换个维度就变成一个新工单。剩下30%才是真正需要分析师手动加工的复杂分析比如归因、预测、对比解读。这里就藏着第一层机会如果LLM能把那70%的模板化查询直接消化掉分析师就能把时间省下来去做那30%的深度活儿。我们自己统计过改造后取数工单量下降了六成分析团队的人均深度分析产出提升了将近一倍。所以我一直跟别人讲评估这个系统值不值得做别盯着智能两个字看先算算你团队里有多少人力被固定SQL占走了。1.2 LLM在这里的角色不是变出结果而是听懂问题、校准口径、生成可执行查询很多朋友一听LLM做自助分析第一反应是那不就是让AI直接写SQL吗其实没那么简单。LLM当然可以写SQL但写出来和写对之间隔着指标口径、表关系、权限规则三道坎。我习惯用Transformer注意力机制里的三个角色来理解这件事Key、Query、Value。Query是你想知道什么对应业务同学那句华东区退货率为什么涨了Key是系统能提供什么对应我们元数据层里预置好的表结构、字段注释、指标定义、维度枚举Value是你最终能拿到的答案对应查询出来的真实数据。如果Key这一侧给得不全、不清晰模型就只能靠猜猜出来的SQL大概率是错的。所以LLM在系统里的定位本质是一个翻译器和编排器它不负责发明业务口径只负责把用户的问题对齐到我们已经定义好的数据资产上。想明白这一点之后整个项目的架构思路就清晰了——不能把宝全押在模型能力上要把确定性知识做扎实让模型在一个被约束好的框架里发挥弹性。2. 系统整体架构我给这个智能划了三层边界很多人的第一版设计是拿一个LLM API直接接数据库用户在对话框里问一句模型生成SQL、执行、返回。我们第一版也这么干过效果只能用翻车来形容。后来重构成了三层架构接入层、语义层、执行层。每一层各管一摊事模型只是语义层里的一个组件而不是整个系统。2.1 三层架构的落地形态和每层的核心职责接入层负责统一入口。我们做了Web端和企微机器人两个入口背后是同一个服务的两个适配器。这一层要处理的其实是工程问题登录鉴权、租户隔离、会话保持、限流配额。特别是限流LLM接口的Token成本不是固定的一个用户疯狂连问20个问题Token消耗可能抵上别人一天的量所以接入层必须做预算控制。语义层是核心负责把用户输入的原始问题一步步转成可执行的查询意图。它内部包含意图识别是查数、看趋势、还是做对比、参数抽取时间范围、维度、筛选条件、指标、指标对齐把用户说的成交额销售额GMV映射到指标字典里的唯一ID、多轮上下文管理、以及RAG检索出了问题不知道怎么办先查知识库里有没有类似的历史解法。执行层相对笨它不碰模型只做三件事校验语义层输出的查询计划、通过只读账号去数据源执行查询、把结果做后处理和可视化返回。为什么要单独拆执行层因为安全策略必须落在确定性的代码里不能依赖模型的自觉性。权限过滤、行级限制、超时中断这些如果交给模型去判断迟早会出事。2.2 系统搭建的边界感哪些逻辑永远不该交给LLM这是我在这个项目里总结出的最重要的一条经验——模型负责意图理解代码负责规则执行这两者必须物理隔离。举几个具体的例子。第一数据权限。用户是A部门的他就不该看到B部门的客户明细。这个判断如果让LLM来做哪怕你精心设计了prompt也可能在某个多轮对话的上下文拐弯处出错。我们的做法是在语义层生成查询计划时权限信息已经作为硬性过滤条件注入到SQL里模型没有决定权。第二指标口径。我们指标字典里定义了月活跃用户等于当月至少登录一次的去重用户ID数这个定义一旦写死模型负责的只是把用户问题里的月活匹配到这条定义上不允许它自己发挥解释。第三DDL和写操作。执行层直接用只读账号语法白名单双保险从物理上杜绝了模型生成DELETE或UPDATE的可能性。3. 语义层是灵魂让LLM看得懂你的指标体系和数据模型整个系统里最难做、也最容易被低估的就是语义层。模型本身的能力差距其实没有想象中那么大真正拉开体验差距的是你喂给它的上下文质量。3.1 指标字典和元数据注入相当于给模型发了一张开卷考试的小抄我们内部有一句话你把多少数据资产告诉模型模型就能还给你多少准确率。任何不经过元数据注入、直接让模型裸写SQL的方案都等于让一个刚入职的实习生不看任何文档就去写生产查询能跑但大概率是错的。我们的做法是维护了一张指标字典每一行包含指标名称、业务口径描述、来源表、涉及字段、常用聚合方式、常见筛选条件。用户问查一下近7天各门店的坪效语义层会先把坪效这个词去指标字典里做模糊匹配和同义词扩展匹配到坪效销售额/营业面积这条定义之后再把对应的表结构、字段说明、联表关系拼装成上下文和用户问题一起送给LLM生成查询计划。这里有个非常关键的细节每次请求注入的元数据不是全量的而是按需检索出来的。全库表结构可能有几百张表Token塞不下塞下了也全是噪声。我们做了一个轻量级的元数据检索器先用用户问题里的业务词去表名、字段注释里做关键词召回只把命中的表和关联表注入到上下文里。这个设计让生成准确率直接从刚过半提升到了接近九成。3.2 RAG、GraphRAG与LLM Wiki知识库我分别用在了三个不同环节聊到LLM应用RAG是个绕不开的话题。但很多人把RAG当成一个万能外挂什么知识都往里塞。我的经验是要区分知识的形态不同形态用不同的检索方案。第一类是非结构化的经验知识比如用户问环比时系统建议输出与上个周期的对比并提供差值这类说明文档、FAQ、最佳实践我放在了一个LLM Wiki式的知识库里按主题沉淀历史问题与标准解法用向量检索召回。第二类是关系型知识比如门店表通过org_id关联区域表区域通过region_id关联大区表这类表与表之间的血缘关系、层级隶属关系我建了一个轻量级本体模型Ontology用图结构来组织效果比纯向量检索好很多。第三类是经典的RAG场景用于检索SQL模板示例比如近30天销售额趋势这种高频问题直接从模板库里拿到骨架再套实际参数。我给这三种方案划了一条选型线文档说明用RAG业务查询用向量检索关系推理用GraphRAG或本体。别指望一个方案通吃也别嫌维护三个库麻烦——它们解决的是不同性质的问题维护成本换来的是准确率上的明显回报。3.3 多轮对话与上下文状态管理最容易翻车的地方全在这里用户问华东区上个月销售额是多少系统回答完用户紧接着一句那华南呢如果系统不记得上个月销售额这些前提就会生成一个残缺SQL。这算是多轮对话最简单的场景了。难的是用户在中途改条件。比如先问统计各区域上季度的销售额看到结果后又问算了不看季度了改成上个月吧。此时系统需要理解这不是新增一个条件而是替换时间粒度。我们在语义层里用了一套轻量级的槽位填充机制把时间范围、维度、指标、筛选条件做成槽位每一轮对话先把新的参数和已有槽位做比对判断是新增、覆盖还是置空再决定是直接生成查询还是向用户澄清。这里有个经验之谈不要让模型自己决定该不该问用户。我们设了一个规则关键槽位缺失时如果置信度低于阈值系统必须生成一句澄清问题而不是赌一个答案。比如用户只说看看销售情况没说时间、没说维度模型直接猜近30天其实是很危险的行为因为它猜错了用户也不知道看到结果不对劲才反馈一来一回体验反而更差。宁可让系统多问一句您想看哪个时间段也好过给一个错误的确定性结果。4. Text-to-SQL与查询执行从能生成到敢执行中间隔着一整条安全链语义层把用户问题转成查询计划之后就到了Text-to-SQL这一步。很多项目死在这一步——不是模型写不出来而是生产环境不敢执行模型写的SQL。4.1 SQL生成的三种路线对比我最终选了模板参数的组合方案业内做Text-to-SQL大体有三条路线。第一条是纯模型生成让LLM直接根据表结构写完整SQL。这条路线最灵活但风险也最高模型可能写出不存在的字段、错误的JOIN条件甚至语法都不对。第二条是模板填充预先写好一批高频查询模板模型只负责把用户条件映射成参数。这条路线最稳但覆盖不了长尾需求。第三条是语义改写模型把自然语言改写成结构化的条件表达式SQL骨架由确定性模板生成。我推荐的是模板参数的组合方案具体操作是先做一次意图分类判断用户问题是否命中高频模板。比如某区域某时间段的某指标趋势这种结构直接走上层模板模型只负责填参数。如果没命中模板再走语义改写路线模型把问题里的指标、维度、时间、过滤条件抽取成结构化对象然后由代码把对象拼装成SQL。这样做的好处是最终执行的SQL里表名、字段名、聚合函数这些关键部分全部来自我们的受控字典模型只负责填参数值从根本上压缩了模型自由度带来的风险又保留了长尾问题的覆盖能力。4.2 保护数据安全的四道防线一条都不能少执行层我设计了四道防线任何一个新来的工程师我都会先带他过一遍这个清单。第一道只读数据库账号。系统里所有查询统一走一个仅有SELECT权限的账号从数据库层面杜绝写操作。第二道强制LIMIT。所有生成的SQL自动拼接LIMIT子句默认返回上限1000行防止用户问了个全表把数据库内存打爆。第三道查询超时与资源组。我们给自助分析系统单独划分了计算资源组查询超过30秒自动终止不让一个异常SQL拖垮整个集群。第四道语法与结构的规则校验。代码层面用SQL解析器校验模型输出的查询计划只允许SELECT、只允许存在的表字段、禁止多语句注入任何一条不满足就直接拒绝并提示用户换一种问法。这四道防线缺一不可。我见过太多团队只做了第一道结果模型生成了一个笛卡尔积JOIN直接把生产库查挂了。自助分析系统一旦上线面对的用户可是完全不懂SQL的业务同学他们不会意识到自己问的所有数据背后是多大的查询量系统必须替用户兜住这个底。4.3 返回结果的可读化包装让用户信得过的关键一步执行成功不等于交付完成。最初我们直接把表格丢给用户业务同学反馈看不懂、不知道这个数跟BI上的是不是一回事。后来我们加了一层结果解释模块用LLM对查询结果做一个自然语言摘要回答用户最关心的涨了还是跌了、异常在哪、和上次比变化多少同时附上所用指标口径和数据来源。更重要的是我们在每条结果后面放了一个查看生成SQL的入口分析师点开就能核对查询条件是否准确这既是可追溯审计也是在用户心里建立信任感的必要手段。这一步的工程细节是解释文本要基于查询结果来生成而不是让模型凭空总结。我们先把结果表格摘要、对比数据、关键异常值计算好再让模型基于这几项结构化输入做文本润色避免模型为了通顺而编出数据里没有的结论。5. 生成式分析的幻觉防护与数据安全这一章决定系统能不能活过试用期把用户问题变成SQL这件事最大的天敌是幻觉。模型一本正经地告诉你根据数据分析退货率上升是因为天气原因结果数据表里根本没有天气字段这种案例在真实环境里比比皆是。做LLM应用防幻觉的优先级永远排在效果优化前面。5.1 幻觉最容易出现的三个环节字段幻觉、口径幻觉、解读幻觉我总结了三类高发幻觉排查问题时习惯先对号入座。字段幻觉是最常见也最好发现的。模型生成了表里不存在的字段名SQL执行直接报错。这类幻觉用执行前校验就能拦下来我们让生成的SQL先走EXPLAIN验证字段是否存在不通过就触发重写。口径幻觉隐蔽得多模型可能把近30天理解成自然月而我们的定义是滚动30天SQL能执行但结果是错的。这类幻觉靠元数据注入来防——把口径说明作为prompt上下文的一部分让模型有据可依。解读幻觉最危险SQL是对的、结果也是对的但LLM在生成总结时脑补了一个数据里不存在的原因。我们应对解读幻觉的办法是绝不让模型直接看原始数据表只让它基于我们预设好的统计指标做表述把它的自由发挥限制在措辞层面而不是事实层面。5.2 落地一套模型自检规则兜底的组合校验机制防幻觉不能只靠一层。我们的组合拳是这样第一层对用户问题进行意图分类分类置信度低就直接转人工兜底不硬答。第二层SQL执行前做字段和语法校验不通过就重写或澄清。第三层SQL执行后做一个结果合理性校验把关键查询结果和指标平台里的同维度历史值做差异比对差异率超过阈值就标记结果异常请谨慎参考并附上比对说明。这个组合机制上线之后系统的整体可用率从不到七成提升到了九成以上。虽然多花了一点推理成本但换来的是用户对结果的信任。我见过很多项目在POC演示时很惊艳一上生产就露馅核心原因就是没有把幻觉的兜底机制做到位。5.3 权限与数据隔离模型不该知道的事情一个字都不给它这是数据安全里最容易被忽视的一点。很多人以为做了行级权限就安全了但LLM应用的隐患在于如果Prompt里注入了不该出现的数据模型就可能顺着用户的追问泄露出去。所以我们从源头上做了隔离——元数据检索时只检索用户有权限访问的表和字段RAG知识库召回时按租户做好了数据分区生成查询计划时用户的权限维度自动作为硬编码过滤条件拼进SQL。另外还有一个工程细节所有模型请求和SQL执行都做全链路审计记录用户ID、原始问题、注入的上下文、生成的SQL、执行结果、返回给用户的解读。这样万一出了权限问题能快速定位是哪一层漏了。6. 模型选型与部署实践开源模型真的够用吗聊完系统设计说说更底层的模型选型。我们团队既用过商业API也折腾过私有化部署这块的经验分享出来能帮你省不少冤枉时间。6.1 从通用榜单到垂直场景评价指标才是真正该盯的东西很多人选模型第一件事是刷Open LLM Leaderboard之类的公开榜单看谁分高选谁。但我要泼一盆冷水通用榜单排名高不代表在你的Text-to-SQL场景里表现好。榜单测的是综合能力而你的场景要求的是准确地理解指标口径、生成结构正确的SQL、不瞎编结论。我们做了个小范围的对比测试把60条真实业务问题同时喂给几个主流模型结果发现排名靠后的开源模型在某些SQL范式上反而更稳因为它的训练数据里刚好覆盖了我们常用的数据库方言。正确的做法是尽快建立你自己的评测集用真实场景跑一轮对比再确定主模型。评测集怎么建下面第7章专门讲。这里只说选型结论在7B到14B规模的开源模型里经过良好微调或配合完善的元数据注入处理大部分结构化查询已经够用只有遇到特别复杂的分析推导问题才需要调度到更大的云端模型。6.2 私有化部署与量化把模型塞进自有服务器的几条经验出于数据合规和稳定性的考虑我们的核心场景选择了私有化部署。模型是开源权重用量化方案压到可以接受的显存占用。这里补充一点基础认知LLM本质上是深度学习模型的一种它的特殊之处在于规模和训练方式带来的涌现能力但在推理层面它依然遵循神经网络前向传播的基本逻辑。理解了这一点你就能明白为什么可以用INT8量化来显著减少显存占用——把权重精度从FP16压到INT8精度损失在可控范围内但显存需求几乎减半。在具体实现上我们有两条路可以选一条是走ONNX导出再用ONNX Runtime做GPU推理工程链路成熟、和现有CI/CD体系好集成另一条是直接用llama.cpp这类推理框架胜在部署简单CPU也能跑。我们的取舍是大模型14B以上走ONNXGPU追求吞吐小模型7B以下用轻量框架跑CPU省成本。这里有个经验别追求一次性把模型能力拉满先跑通Mini版本再逐步升级。我们用7B模型跑了两个月积累了大量真实Prompt和修正Case后来换了14B模型效果立刻又上一个台阶——因为评测集和知识库都已经准备好了模型升级的收益能立刻被验证。6.3 LLM网关多模型路由和省钱的关键组件项目跑了半年之后我愈发觉得LLM网关是个被严重低估的组件。它在接入层和模型之间加了一层代理负责三件事路由、配额、回退。路由是指同一个请求根据业务类型、数据敏感度、复杂度分发到不同模型——敏感数据走私有化模型复杂推导走云端大模型这样既保安全又省成本。配额是给不同租户设定Token预算防止单个部门把预算烧光。回退是指主模型调用失败时自动切换到备选模型不影响用户使用。把这一层做扎实之后系统的可运维性提升了一个量级。发布新模型、调整配额、观察各模型质量差异都不需要改业务代码在网关层就能完成。7. 评估体系与上线踩坑怎么科学地证明系统真的能用最后这部分是我觉得最值得分享的。智能系统的效果评估比普通软件难得多。你说它好用得先定义什么是好。我们花了整整一周时间建了一套评估体系后来所有优化排期都靠这套体系来驱动。7.1 评测集的构建从历史真实工单里挖矿评测集是整个评估体系的地基。我们的做法是从过去一年的真实取数工单里按业务主题分桶抽样人工标注标准SQL和预期结果形成首批200条评测样本。每一批新迭代再从最新反馈中抽取增量样本补充进去保证评测集能反映真实需求变化。有个细节是评测集要分难度分层。我们把问题按单表简单过滤、多表关联聚合、复杂条件嵌套、模糊意图澄清四档打标。上线初期要求前两档准确率必须达标后两档允许转人工成熟期再逐步提高后两档的通过率。这样既保证核心体验又不被长尾问题拖死。7.2 核心评估指标语义准确率、执行可用率、澄清兜底率我定义三个核心指标会看板的团队可以直接抄作业。第一个是语义准确率模型生成的SQL是否忠实反映了用户意图这个由标注人员人工判定比较费人力但必不可少。第二个是执行可用率生成的SQL能否成功执行并返回非空结果这个完全自动化计算反映的是基础干活能力。第三个是澄清兜底率系统正确识别自己不懂、并主动向用户澄清的比例这个指标看着不起眼其实决定体验下限。一个从不澄清、硬着头皮给错误答案的系统比一个老老实实说没听懂的系统危险得多。我们在内部定了一个及格线语义准确率不低于85%、执行可用率不低于90%、澄清兜底率不低于30%。这三个指标综合起来才能说明系统既能干活、又知道边界。7.3 灰度上线阶段最容易踩的三个坑作为收尾我把上线初期踩过的坑浓缩成三条供你参考。坑一全量开放给所有部门。正确做法是先挑一两个配合度高、需求简单的业务团队做种子用户灰度跑两周集中处理反馈。坑二只评测SQL生成不评测结果解读。用户最终看的是解读文本解读如果撒谎SQL再准也没用。结果解释模块一定要纳入评测范围。坑三反馈闭环断了。用户点了回答不满意之后后面没有人跟进分析为什么不满意、如何改进。我们后来专门建了一个反馈工单池每周固定时间Review不满意样本直接驱动Prompt和评测集迭代。我个人在实际操作中最大的体会是做智能化自助分析系统真正难的不是模型调优而是让模型在确定的边界内发挥弹性。模型能力会持续进步但指标口径、权限边界、安全防线、评测方法这些确定性的东西才是项目能否落地的根基。别指望一步到位先用MVP满足Top 20的高频需求让人力从重复取数中解放出来再去扩大覆盖面这个节奏最稳。
基于LLM的智能自助分析系统：从Text-to-SQL到语义层落地实践
去年年初我们数据团队接了一个让我头疼很久的活儿业务部门每天都在钉钉群里追着要数今天问华东区上个月退货率为什么涨了明天问新客首单转化掉了几个点后天又问帮我拉一下最近90天高价值用户的复购明细。这些需求单看都不难但架不住量大、口径杂、时段急几个分析师每天不是在写SQL就是在解释为什么数跟BI看板不一样。我们自己内部也上过自助BI、做过指标平台但业务同学普遍反馈不会用不会写条件看板是固定的、问题却是活的。后来我们决定试试一条新路把LLM塞进自助分析流程里让用户直接用大白话问数。这个项目前后做了三个多月踩了不少坑今天把这套智能化自助分析系统的搭建过程、架构取舍和上线后的真实表现完整记录下来希望给正在考虑同样方案的同学一些参考。1. 为什么自助分析喊了这么多年最后还得靠LLM来补这一环先说清楚一个背景市面上不是没有自助分析工具Tableau、Power BI、帆软包括我们自研的指标平台都算成熟产品。但自助这两个字对业务同学来说一直是个伪命题。工具的筛选、联动、钻取功能再强前提是用户脑子里得先有一个该看什么维度、该切什么条件、该对什么口径的框架。可现实是业务同学脑子里装的是经营问题不是数据结构。他问的是为什么这个月新客少了背后隐含的其实是新客定义是什么、跟哪个表关联、时间怎么对齐、和上月比还是和年初比。这个从业务语言到技术语言的翻译过程传统工具一直做得不好只能靠人来弥补——于是取数需求还是源源不断流向分析师。1.1 一线观察取数工单的真实构成和浪费在哪里我翻过我们团队半年的工单记录发现一个规律大约70%的需求其实是结构化程度很高的查询。什么意思呢就是用户要的表、字段、过滤条件基本都说得清楚只是他不会写SQL或者不想学BI工具。比如查一下1月到3月每个区域每个品类的销售额按降序排这种需求本质是固定模板但每天换个时间段、换个维度就变成一个新工单。剩下30%才是真正需要分析师手动加工的复杂分析比如归因、预测、对比解读。这里就藏着第一层机会如果LLM能把那70%的模板化查询直接消化掉分析师就能把时间省下来去做那30%的深度活儿。我们自己统计过改造后取数工单量下降了六成分析团队的人均深度分析产出提升了将近一倍。所以我一直跟别人讲评估这个系统值不值得做别盯着智能两个字看先算算你团队里有多少人力被固定SQL占走了。1.2 LLM在这里的角色不是变出结果而是听懂问题、校准口径、生成可执行查询很多朋友一听LLM做自助分析第一反应是那不就是让AI直接写SQL吗其实没那么简单。LLM当然可以写SQL但写出来和写对之间隔着指标口径、表关系、权限规则三道坎。我习惯用Transformer注意力机制里的三个角色来理解这件事Key、Query、Value。Query是你想知道什么对应业务同学那句华东区退货率为什么涨了Key是系统能提供什么对应我们元数据层里预置好的表结构、字段注释、指标定义、维度枚举Value是你最终能拿到的答案对应查询出来的真实数据。如果Key这一侧给得不全、不清晰模型就只能靠猜猜出来的SQL大概率是错的。所以LLM在系统里的定位本质是一个翻译器和编排器它不负责发明业务口径只负责把用户的问题对齐到我们已经定义好的数据资产上。想明白这一点之后整个项目的架构思路就清晰了——不能把宝全押在模型能力上要把确定性知识做扎实让模型在一个被约束好的框架里发挥弹性。2. 系统整体架构我给这个智能划了三层边界很多人的第一版设计是拿一个LLM API直接接数据库用户在对话框里问一句模型生成SQL、执行、返回。我们第一版也这么干过效果只能用翻车来形容。后来重构成了三层架构接入层、语义层、执行层。每一层各管一摊事模型只是语义层里的一个组件而不是整个系统。2.1 三层架构的落地形态和每层的核心职责接入层负责统一入口。我们做了Web端和企微机器人两个入口背后是同一个服务的两个适配器。这一层要处理的其实是工程问题登录鉴权、租户隔离、会话保持、限流配额。特别是限流LLM接口的Token成本不是固定的一个用户疯狂连问20个问题Token消耗可能抵上别人一天的量所以接入层必须做预算控制。语义层是核心负责把用户输入的原始问题一步步转成可执行的查询意图。它内部包含意图识别是查数、看趋势、还是做对比、参数抽取时间范围、维度、筛选条件、指标、指标对齐把用户说的成交额销售额GMV映射到指标字典里的唯一ID、多轮上下文管理、以及RAG检索出了问题不知道怎么办先查知识库里有没有类似的历史解法。执行层相对笨它不碰模型只做三件事校验语义层输出的查询计划、通过只读账号去数据源执行查询、把结果做后处理和可视化返回。为什么要单独拆执行层因为安全策略必须落在确定性的代码里不能依赖模型的自觉性。权限过滤、行级限制、超时中断这些如果交给模型去判断迟早会出事。2.2 系统搭建的边界感哪些逻辑永远不该交给LLM这是我在这个项目里总结出的最重要的一条经验——模型负责意图理解代码负责规则执行这两者必须物理隔离。举几个具体的例子。第一数据权限。用户是A部门的他就不该看到B部门的客户明细。这个判断如果让LLM来做哪怕你精心设计了prompt也可能在某个多轮对话的上下文拐弯处出错。我们的做法是在语义层生成查询计划时权限信息已经作为硬性过滤条件注入到SQL里模型没有决定权。第二指标口径。我们指标字典里定义了月活跃用户等于当月至少登录一次的去重用户ID数这个定义一旦写死模型负责的只是把用户问题里的月活匹配到这条定义上不允许它自己发挥解释。第三DDL和写操作。执行层直接用只读账号语法白名单双保险从物理上杜绝了模型生成DELETE或UPDATE的可能性。3. 语义层是灵魂让LLM看得懂你的指标体系和数据模型整个系统里最难做、也最容易被低估的就是语义层。模型本身的能力差距其实没有想象中那么大真正拉开体验差距的是你喂给它的上下文质量。3.1 指标字典和元数据注入相当于给模型发了一张开卷考试的小抄我们内部有一句话你把多少数据资产告诉模型模型就能还给你多少准确率。任何不经过元数据注入、直接让模型裸写SQL的方案都等于让一个刚入职的实习生不看任何文档就去写生产查询能跑但大概率是错的。我们的做法是维护了一张指标字典每一行包含指标名称、业务口径描述、来源表、涉及字段、常用聚合方式、常见筛选条件。用户问查一下近7天各门店的坪效语义层会先把坪效这个词去指标字典里做模糊匹配和同义词扩展匹配到坪效销售额/营业面积这条定义之后再把对应的表结构、字段说明、联表关系拼装成上下文和用户问题一起送给LLM生成查询计划。这里有个非常关键的细节每次请求注入的元数据不是全量的而是按需检索出来的。全库表结构可能有几百张表Token塞不下塞下了也全是噪声。我们做了一个轻量级的元数据检索器先用用户问题里的业务词去表名、字段注释里做关键词召回只把命中的表和关联表注入到上下文里。这个设计让生成准确率直接从刚过半提升到了接近九成。3.2 RAG、GraphRAG与LLM Wiki知识库我分别用在了三个不同环节聊到LLM应用RAG是个绕不开的话题。但很多人把RAG当成一个万能外挂什么知识都往里塞。我的经验是要区分知识的形态不同形态用不同的检索方案。第一类是非结构化的经验知识比如用户问环比时系统建议输出与上个周期的对比并提供差值这类说明文档、FAQ、最佳实践我放在了一个LLM Wiki式的知识库里按主题沉淀历史问题与标准解法用向量检索召回。第二类是关系型知识比如门店表通过org_id关联区域表区域通过region_id关联大区表这类表与表之间的血缘关系、层级隶属关系我建了一个轻量级本体模型Ontology用图结构来组织效果比纯向量检索好很多。第三类是经典的RAG场景用于检索SQL模板示例比如近30天销售额趋势这种高频问题直接从模板库里拿到骨架再套实际参数。我给这三种方案划了一条选型线文档说明用RAG业务查询用向量检索关系推理用GraphRAG或本体。别指望一个方案通吃也别嫌维护三个库麻烦——它们解决的是不同性质的问题维护成本换来的是准确率上的明显回报。3.3 多轮对话与上下文状态管理最容易翻车的地方全在这里用户问华东区上个月销售额是多少系统回答完用户紧接着一句那华南呢如果系统不记得上个月销售额这些前提就会生成一个残缺SQL。这算是多轮对话最简单的场景了。难的是用户在中途改条件。比如先问统计各区域上季度的销售额看到结果后又问算了不看季度了改成上个月吧。此时系统需要理解这不是新增一个条件而是替换时间粒度。我们在语义层里用了一套轻量级的槽位填充机制把时间范围、维度、指标、筛选条件做成槽位每一轮对话先把新的参数和已有槽位做比对判断是新增、覆盖还是置空再决定是直接生成查询还是向用户澄清。这里有个经验之谈不要让模型自己决定该不该问用户。我们设了一个规则关键槽位缺失时如果置信度低于阈值系统必须生成一句澄清问题而不是赌一个答案。比如用户只说看看销售情况没说时间、没说维度模型直接猜近30天其实是很危险的行为因为它猜错了用户也不知道看到结果不对劲才反馈一来一回体验反而更差。宁可让系统多问一句您想看哪个时间段也好过给一个错误的确定性结果。4. Text-to-SQL与查询执行从能生成到敢执行中间隔着一整条安全链语义层把用户问题转成查询计划之后就到了Text-to-SQL这一步。很多项目死在这一步——不是模型写不出来而是生产环境不敢执行模型写的SQL。4.1 SQL生成的三种路线对比我最终选了模板参数的组合方案业内做Text-to-SQL大体有三条路线。第一条是纯模型生成让LLM直接根据表结构写完整SQL。这条路线最灵活但风险也最高模型可能写出不存在的字段、错误的JOIN条件甚至语法都不对。第二条是模板填充预先写好一批高频查询模板模型只负责把用户条件映射成参数。这条路线最稳但覆盖不了长尾需求。第三条是语义改写模型把自然语言改写成结构化的条件表达式SQL骨架由确定性模板生成。我推荐的是模板参数的组合方案具体操作是先做一次意图分类判断用户问题是否命中高频模板。比如某区域某时间段的某指标趋势这种结构直接走上层模板模型只负责填参数。如果没命中模板再走语义改写路线模型把问题里的指标、维度、时间、过滤条件抽取成结构化对象然后由代码把对象拼装成SQL。这样做的好处是最终执行的SQL里表名、字段名、聚合函数这些关键部分全部来自我们的受控字典模型只负责填参数值从根本上压缩了模型自由度带来的风险又保留了长尾问题的覆盖能力。4.2 保护数据安全的四道防线一条都不能少执行层我设计了四道防线任何一个新来的工程师我都会先带他过一遍这个清单。第一道只读数据库账号。系统里所有查询统一走一个仅有SELECT权限的账号从数据库层面杜绝写操作。第二道强制LIMIT。所有生成的SQL自动拼接LIMIT子句默认返回上限1000行防止用户问了个全表把数据库内存打爆。第三道查询超时与资源组。我们给自助分析系统单独划分了计算资源组查询超过30秒自动终止不让一个异常SQL拖垮整个集群。第四道语法与结构的规则校验。代码层面用SQL解析器校验模型输出的查询计划只允许SELECT、只允许存在的表字段、禁止多语句注入任何一条不满足就直接拒绝并提示用户换一种问法。这四道防线缺一不可。我见过太多团队只做了第一道结果模型生成了一个笛卡尔积JOIN直接把生产库查挂了。自助分析系统一旦上线面对的用户可是完全不懂SQL的业务同学他们不会意识到自己问的所有数据背后是多大的查询量系统必须替用户兜住这个底。4.3 返回结果的可读化包装让用户信得过的关键一步执行成功不等于交付完成。最初我们直接把表格丢给用户业务同学反馈看不懂、不知道这个数跟BI上的是不是一回事。后来我们加了一层结果解释模块用LLM对查询结果做一个自然语言摘要回答用户最关心的涨了还是跌了、异常在哪、和上次比变化多少同时附上所用指标口径和数据来源。更重要的是我们在每条结果后面放了一个查看生成SQL的入口分析师点开就能核对查询条件是否准确这既是可追溯审计也是在用户心里建立信任感的必要手段。这一步的工程细节是解释文本要基于查询结果来生成而不是让模型凭空总结。我们先把结果表格摘要、对比数据、关键异常值计算好再让模型基于这几项结构化输入做文本润色避免模型为了通顺而编出数据里没有的结论。5. 生成式分析的幻觉防护与数据安全这一章决定系统能不能活过试用期把用户问题变成SQL这件事最大的天敌是幻觉。模型一本正经地告诉你根据数据分析退货率上升是因为天气原因结果数据表里根本没有天气字段这种案例在真实环境里比比皆是。做LLM应用防幻觉的优先级永远排在效果优化前面。5.1 幻觉最容易出现的三个环节字段幻觉、口径幻觉、解读幻觉我总结了三类高发幻觉排查问题时习惯先对号入座。字段幻觉是最常见也最好发现的。模型生成了表里不存在的字段名SQL执行直接报错。这类幻觉用执行前校验就能拦下来我们让生成的SQL先走EXPLAIN验证字段是否存在不通过就触发重写。口径幻觉隐蔽得多模型可能把近30天理解成自然月而我们的定义是滚动30天SQL能执行但结果是错的。这类幻觉靠元数据注入来防——把口径说明作为prompt上下文的一部分让模型有据可依。解读幻觉最危险SQL是对的、结果也是对的但LLM在生成总结时脑补了一个数据里不存在的原因。我们应对解读幻觉的办法是绝不让模型直接看原始数据表只让它基于我们预设好的统计指标做表述把它的自由发挥限制在措辞层面而不是事实层面。5.2 落地一套模型自检规则兜底的组合校验机制防幻觉不能只靠一层。我们的组合拳是这样第一层对用户问题进行意图分类分类置信度低就直接转人工兜底不硬答。第二层SQL执行前做字段和语法校验不通过就重写或澄清。第三层SQL执行后做一个结果合理性校验把关键查询结果和指标平台里的同维度历史值做差异比对差异率超过阈值就标记结果异常请谨慎参考并附上比对说明。这个组合机制上线之后系统的整体可用率从不到七成提升到了九成以上。虽然多花了一点推理成本但换来的是用户对结果的信任。我见过很多项目在POC演示时很惊艳一上生产就露馅核心原因就是没有把幻觉的兜底机制做到位。5.3 权限与数据隔离模型不该知道的事情一个字都不给它这是数据安全里最容易被忽视的一点。很多人以为做了行级权限就安全了但LLM应用的隐患在于如果Prompt里注入了不该出现的数据模型就可能顺着用户的追问泄露出去。所以我们从源头上做了隔离——元数据检索时只检索用户有权限访问的表和字段RAG知识库召回时按租户做好了数据分区生成查询计划时用户的权限维度自动作为硬编码过滤条件拼进SQL。另外还有一个工程细节所有模型请求和SQL执行都做全链路审计记录用户ID、原始问题、注入的上下文、生成的SQL、执行结果、返回给用户的解读。这样万一出了权限问题能快速定位是哪一层漏了。6. 模型选型与部署实践开源模型真的够用吗聊完系统设计说说更底层的模型选型。我们团队既用过商业API也折腾过私有化部署这块的经验分享出来能帮你省不少冤枉时间。6.1 从通用榜单到垂直场景评价指标才是真正该盯的东西很多人选模型第一件事是刷Open LLM Leaderboard之类的公开榜单看谁分高选谁。但我要泼一盆冷水通用榜单排名高不代表在你的Text-to-SQL场景里表现好。榜单测的是综合能力而你的场景要求的是准确地理解指标口径、生成结构正确的SQL、不瞎编结论。我们做了个小范围的对比测试把60条真实业务问题同时喂给几个主流模型结果发现排名靠后的开源模型在某些SQL范式上反而更稳因为它的训练数据里刚好覆盖了我们常用的数据库方言。正确的做法是尽快建立你自己的评测集用真实场景跑一轮对比再确定主模型。评测集怎么建下面第7章专门讲。这里只说选型结论在7B到14B规模的开源模型里经过良好微调或配合完善的元数据注入处理大部分结构化查询已经够用只有遇到特别复杂的分析推导问题才需要调度到更大的云端模型。6.2 私有化部署与量化把模型塞进自有服务器的几条经验出于数据合规和稳定性的考虑我们的核心场景选择了私有化部署。模型是开源权重用量化方案压到可以接受的显存占用。这里补充一点基础认知LLM本质上是深度学习模型的一种它的特殊之处在于规模和训练方式带来的涌现能力但在推理层面它依然遵循神经网络前向传播的基本逻辑。理解了这一点你就能明白为什么可以用INT8量化来显著减少显存占用——把权重精度从FP16压到INT8精度损失在可控范围内但显存需求几乎减半。在具体实现上我们有两条路可以选一条是走ONNX导出再用ONNX Runtime做GPU推理工程链路成熟、和现有CI/CD体系好集成另一条是直接用llama.cpp这类推理框架胜在部署简单CPU也能跑。我们的取舍是大模型14B以上走ONNXGPU追求吞吐小模型7B以下用轻量框架跑CPU省成本。这里有个经验别追求一次性把模型能力拉满先跑通Mini版本再逐步升级。我们用7B模型跑了两个月积累了大量真实Prompt和修正Case后来换了14B模型效果立刻又上一个台阶——因为评测集和知识库都已经准备好了模型升级的收益能立刻被验证。6.3 LLM网关多模型路由和省钱的关键组件项目跑了半年之后我愈发觉得LLM网关是个被严重低估的组件。它在接入层和模型之间加了一层代理负责三件事路由、配额、回退。路由是指同一个请求根据业务类型、数据敏感度、复杂度分发到不同模型——敏感数据走私有化模型复杂推导走云端大模型这样既保安全又省成本。配额是给不同租户设定Token预算防止单个部门把预算烧光。回退是指主模型调用失败时自动切换到备选模型不影响用户使用。把这一层做扎实之后系统的可运维性提升了一个量级。发布新模型、调整配额、观察各模型质量差异都不需要改业务代码在网关层就能完成。7. 评估体系与上线踩坑怎么科学地证明系统真的能用最后这部分是我觉得最值得分享的。智能系统的效果评估比普通软件难得多。你说它好用得先定义什么是好。我们花了整整一周时间建了一套评估体系后来所有优化排期都靠这套体系来驱动。7.1 评测集的构建从历史真实工单里挖矿评测集是整个评估体系的地基。我们的做法是从过去一年的真实取数工单里按业务主题分桶抽样人工标注标准SQL和预期结果形成首批200条评测样本。每一批新迭代再从最新反馈中抽取增量样本补充进去保证评测集能反映真实需求变化。有个细节是评测集要分难度分层。我们把问题按单表简单过滤、多表关联聚合、复杂条件嵌套、模糊意图澄清四档打标。上线初期要求前两档准确率必须达标后两档允许转人工成熟期再逐步提高后两档的通过率。这样既保证核心体验又不被长尾问题拖死。7.2 核心评估指标语义准确率、执行可用率、澄清兜底率我定义三个核心指标会看板的团队可以直接抄作业。第一个是语义准确率模型生成的SQL是否忠实反映了用户意图这个由标注人员人工判定比较费人力但必不可少。第二个是执行可用率生成的SQL能否成功执行并返回非空结果这个完全自动化计算反映的是基础干活能力。第三个是澄清兜底率系统正确识别自己不懂、并主动向用户澄清的比例这个指标看着不起眼其实决定体验下限。一个从不澄清、硬着头皮给错误答案的系统比一个老老实实说没听懂的系统危险得多。我们在内部定了一个及格线语义准确率不低于85%、执行可用率不低于90%、澄清兜底率不低于30%。这三个指标综合起来才能说明系统既能干活、又知道边界。7.3 灰度上线阶段最容易踩的三个坑作为收尾我把上线初期踩过的坑浓缩成三条供你参考。坑一全量开放给所有部门。正确做法是先挑一两个配合度高、需求简单的业务团队做种子用户灰度跑两周集中处理反馈。坑二只评测SQL生成不评测结果解读。用户最终看的是解读文本解读如果撒谎SQL再准也没用。结果解释模块一定要纳入评测范围。坑三反馈闭环断了。用户点了回答不满意之后后面没有人跟进分析为什么不满意、如何改进。我们后来专门建了一个反馈工单池每周固定时间Review不满意样本直接驱动Prompt和评测集迭代。我个人在实际操作中最大的体会是做智能化自助分析系统真正难的不是模型调优而是让模型在确定的边界内发挥弹性。模型能力会持续进步但指标口径、权限边界、安全防线、评测方法这些确定性的东西才是项目能否落地的根基。别指望一步到位先用MVP满足Top 20的高频需求让人力从重复取数中解放出来再去扩大覆盖面这个节奏最稳。
