最近我把内部的数据分析平台做了一次大改造，核心方向就是围绕“基于大模型（LLM）的智能化自助分析系统”这条路子展开。折腾了几个月，踩了不少坑，也沉淀了一些能直接复用的经验。这次就专门写一篇完整的搭建探索记录，从整体设计、底层概念、实操落地到问题排查，一次性讲透。如果你也在考虑给自己的团队上一套“说人话就能查数”的分析系统，这篇文章应该能帮你少走很多弯路。
先交代一下背景：我们团队日常有大量的数据查询和报表需求，业务同学要数往往要排队等开发排期，一个简单口径折腾一两天是常事。我最初的目标很朴素——让业务同学直接用自然语言提问，让系统自动完成“理解需求—生成查询—返回结果—解释结论”这条链路。做完之后发现，这事远不只是接一个大模型API那么简单。它涉及指标口径梳理、检索增强、查询生成、结果校验、权限管控、推理优化等多个环节，任何一个环节偷懒，最终体验都会崩。
这篇分享没有藏着掖着，所有的设计思考、参数计算、提示词模板、故障排查都是这几个月真实跑下来的产出。适合正在规划自助分析平台的技术负责人、数据开发，以及对LLM应用落地感兴趣的同学参考。
1. 整体设计思路：先想清楚“自助”到底是在解决谁的什么问题
1.1 从“提需求”到“自助分析”，转变的不只是入口
过去业务同学取数的典型路径是这样的：在IM上给数据开发发一句“帮我拉一下上周各区域的销售额”，“最好能同比一下”，“哦对了，剔除退货”，然后陷入漫长的等待。这中间真正的成本不是写SQL那几分钟，而是来回澄清口径、确认表结构、对齐时间范围的沟通成本。我在设计智能化自助分析系统时，首先不是去想要怎么“替代”数据开发，而是思考怎么把“澄清口径”这个环节自动化。
自助分析系统本质上是把一个隐性的“需求翻译过程”显性化。业务同学脑子里想的是“最近华东区的销售情况怎么样”，系统需要把它拆解成：时间范围是最近多久？销售情况指销售额还是订单量？华东区是按收货地址还是下单地址？要不要对比上个月？这些拆解能力，恰好是大模型最擅长的事情之一，但前提是你得给它足够清晰的知识上下文。
对于这类系统，LLM并不是主角，主角是“知识”和“流程”。大模型更像是一个调度核心，它负责理解意图、编排动作、解释结果，真正干活的还是背后的数据引擎。想清楚这点，整个架构就不会跑偏。
1.2 模块划分：把系统拆成五个可独立演进的层次
我最终的架构大致分成五层：接入层、理解层、翻译层、执行层、解释层。
接入层负责接收用户的自然语言问题，可能是对话框，也可能是企业IM里的机器人，这个没什么难度。理解层是大模型第一次发挥作用的地方，它需要把用户的模糊问题转化为结构化意图，包括识别指标、维度、时间范围、过滤条件、对比需求。翻译层则把结构化意图转化为可执行的SQL或API调用，这是整个系统最核心也最容易出错的地方。执行层负责真正查询数据，可能是ClickHouse、Doris这类OLAP引擎，也可能是预先封装好的指标服务。解释层在大模型拿到查询结果后，生成自然语言解读，并对异常数据进行初步归因。
分层设计最大的好处是每一层都可以独立优化。比如刚开始时翻译层直接让模型生成SQL，结果准确率只有六成；后来把翻译层改为“先生成指标树再拼接SQL”，准确率一下子提升到九成。这个优化后面会细讲。
提示：不要一上来就搞大而全的架构。MVP阶段完全可以省掉解释层，先把“查数准确”跑通，再逐步增加解释、归因、建议能力。
1.3 设计总原则：把模型当“实习生”，把系统当“工作台”
这个原则是我在踩了无数坑之后总结出来的。很多人做大模型应用，会不自觉地希望模型“什么都会”，但现实是：越自由，越容易出错。我始终把模型当成一个能力很强但缺乏业务常识的实习生。你不会把一个实习生直接丢到生产数据库上让他随便写SQL，你会先给他一份指标字典、告诉他哪个表是什么、哪些口径不能用，让他写完之后你还要review一遍。
对应到系统上就是：
- 模型不直接连数据库，而是通过指标层和受控的查询模板去执行；
- 模型不能凭空生成指标口径，所有口径来自预先维护的知识库；
- 模型给出的答案必须经过规则校验收敛，比如聚合函数是否合法、时间条件是否完整。
这套“实习生”框架还有一个好处：它让整个系统的行为可预期。可预期意味着可控，可控意味着可以上生产环境。
2. 动工前的底层认知：Token、知识边界与检索增强的取舍
2.1 Token机制：拆解“我是谁、我在找什么、我能提供什么”
做LLM应用绕不开Token这个话题。刚开始我理解Token就是计费单位，后来发现Token的边界划分直接影响问答质量。业界有个很形象的说法：Token的三个关键点是“key我是谁、query我在找什么、value我能提供什么”。在一个Prompt或者一个检索片段里，如果这三个信息不完整，模型就很难正确理解和使用这段内容。
举个例子，指标字典里如果只写“销售额=sum(amount)”，模型并不知道这个指标属于哪个业务域、能回答什么问题、底层字段来自哪张表。但如果你把一条指标描述组织成“【我是谁】订单销售额：指用户实际支付成功的订单金额总和；【我在找什么】用于回答销售规模、趋势对比类问题；【我能提供什么】支持按时间、区域、渠道、品类维度下钻，口径已剔除退款订单”，你会发现模型的理解准确率提升一个档次。
Token机制的另外一个用途是控制上下文长度。在自助分析场景里，知识库内容往往非常多，如果一股脑全部塞进Prompt，会面临两个问题：超出模型上下文窗口导致截断，以及无关Token稀释注意力导致回答质量下降。正确的做法是先检索、再注入、后生成，只把与当前问题最相关的知识片段放进上下文。
2.2 LLM Ontology：给大模型构建一张“业务概念网络”
热词里反复出现“LLM Ontology（本体）”、“LLM Wiki”这些概念，一开始我也觉得这是学术圈玩的虚东西，直到在自助分析领域里撞了墙才意识到它的价值。
问题出现在一个很简单的场景：用户问“头部客户的复购情况怎么样”。系统检索指标字典时，“头部客户”这个词在字典里没有对应定义，导致查询失败。后来我意识到，系统缺的不是指标描述，而是一张业务本体网络——它需要知道“头部客户”是一种客户分层，“客户分层”是客户维度的属性，“复购”与“购买频次”“留存率”存在语义关联。换句话说，你需要把散落的指标、维度、业务概念组织成一张网，模型才能在这个网络里做推理，而不是靠碰关键词。
在落地时，我给每个核心业务对象建了本体卡片：客户、商品、订单、门店、渠道、营销活动，各自有属性、关系、常用指标。这套本体结构最终以两种形态存在：一种是给大模型做推理的知识文本，另一种是给检索系统做关联扩展的图谱结构。这就是从RAG走向GraphRAG的动因，后面会细说。
构建LLM Ontology的建议从高频问题反推：先收集业务方过去三个月提得最多的50个问题，逐一拆解它们涉及的实体和关系，再抽象出本体层。不要一开始就追求完备，那是不现实的。
2.3 RAG、GraphRAG与LLM Wiki知识库：我为什么最终在系统里同时用了三者
检索增强生成（RAG）是解决大模型“不知道自己不知道”问题的经典方案。在自助分析系统里，RAG承担的是“把知识喂进去”的任务，比如指标口径、表结构、业务术语、权限规则等。但传统的向量RAG有一个天然短板：它适合找相似的碎片，不适合做多跳推理。
举个例子，用户问“深圳龙华区的门店在促销活动期间的客单价环比变化”。这个问题涉及门店区域（深圳龙华）、活动（促销活动）、指标（客单价）、对比（环比）四个知识片段。传统RAG很可能只检索到门店和客单价两个片段，而GraphRAG能把活动与门店的关联关系作为路径检索出来。在自助分析场景里，这种多实体关联查询非常频繁，所以GraphRAG是必要的补充。
LLM Wiki知识库更多是工程层面的组织方式。我没有用那种全局统一的大知识库，而是按业务子域拆成多个小知识库，每个知识库有独立的更新责任人。比如销售域知识库由销售数据负责人维护，供应链域由供应链同学维护。这样做的好处是职责清晰、更新及时，也方便做知识库级别的权限控制。你可以把它理解成给公司不同的业务模块各建了一个维基，大模型在回答某个域的问题时，只加载对应的维基内容。
3. 实操搭建：从零到可用系统的完整落地过程
3.1 环境选型和框架评估：别急着选模型，先找“网关”和“网关之后的东西”
搭建LLM应用系统时，很多人第一步就是问“选哪个大模型合适”。我的建议是反过来的：先把你需要的能力抽象出来，选框架再选模型。
这里说的框架不只是LangChain这类编排工具，而是“应用骨架”。我在选型时重点关注3件事：支持模型的切换能力、检索组件的可插拔性、以及可观测性。最后选择了一条比较务实的路线：自研了一个轻量级的LLM Gateway（大模型网关），把模型调用、Key管理、限流、缓存、fallback全部收敛在网关层，上层应用只面向一个统一的接口。这个网关后来帮我省了太多事：模型升级时只需要换网关背后的配置，上层业务代码一行不用动。
模型选型上，当前阶段我采用“三模型策略”：一个强模型（用于复杂SQL生成和归因分析）、一个经济模型（用于意图识别和简单问答）、一个本地部署的小模型（用于离线批量分析）。我会对照Open LLM Leaderboard这类公开榜单做初筛，但说实话，榜单分数和实际业务表现差距很大，最终的判断依据是在自己的数据集上跑出来的准确率和延迟。
部署推理方面，对必须本地化的场景，我用ONNX Runtime部署过开源模型。ONNX部署最大的价值是摆脱了对Python推理框架的强依赖，可以方便地嵌入Java/Go的服务里。不过ONNX部署LLM也有不少限制，动态形状处理和算子兼容性都会带来麻烦，如果不是强合规需求，优先用官方推理服务会省心得多。
3.2 数据接入与指标层建设：把“口径”清洗成模型看得懂的字典
这一节是整个系统的地基。我见过很多团队做大模型查询系统，一上来就急着让模型写SQL，结果数据的准确性永远提不上去，原因几乎都是指标层没做好。指标层的作用是让模型不需要理解原始表结构，它只需要理解“销售额”“毛利”“客单价”这些业务概念，以及每个概念的计算逻辑和限制条件。
我的做法分四步。
第一步，梳理核心指标，每一类指标建立一张卡片，明确指标名称、业务定义、计算公式、统计周期、过滤条件、维度、同环比规则、数据源表。第二步，把指标卡片转化为模型友好的Token文本，也就是前面提到的“我是谁、我在找什么、我能提供什么”三段式结构。第三步，对指标做分层管理，核心指标（订单量、销售额、毛利）和衍生指标（客单价、复购率、库存周转天数）分开存放，衍生指标可以引用核心指标的定义，避免重复维护。第四步，建立指标血缘，一条指标可以被追溯到底层物理表，模型生成SQL后，可以通过血缘验证表名、字段名的正确性。
这里有个很容易被忽略的细节：业务口径是会变的。比如“销售额”年初定义是不含税，6月份财务说要调整为含税口径。如果你的指标卡片没有版本管理，模型还在用旧口径回答问题，那麻烦就大了。我最终给每个指标增加了生效日期和失效日期，销毁的指标不会被知识库检索命中，但历史分析场景依然可以使用旧版本。这套机制看着简单，但在实际运营中救了我很多次。
3.3 Prompt与NL2SQL核心实现：模板化、约束化、可纠错
NL2SQL（自然语言转SQL）是自助分析系统的胜负手。很多人以为把用户的自然语言问题直接抛给模型就能得到SQL，实测下来准确率大概只有五到七成，生产环境根本不敢用。我必须把它改造成一个有约束的生成过程。
先说提示词结构。我使用的NL2SQL提示词严格包含四块：
- 任务定义：明确说明“你是一个数据分析师，请根据给定指标字典生成SQL查询，只允许使用字典中出现的表和字段”；
- 知识注入：放入与问题相关的指标卡片、维度字典、样本SQL片段；
- 对话历史：如果用户进行了追问（比如“那看下华南区呢”），带上上一轮的解析结果，保持会话连续性；
- 输出约束：要求模型输出JSON，包含SQL、使用的指标、对应的口径说明、可解释性文本。
模板只是第一步。真正提升准确率要靠两点。
第一点是“意图先拆分，再生成”。用户的问题往往是复合的：“帮我看下这周各品类的销售额排名，以及和上周对比的变化率”。如果让模型直接生成一个完整的SQL，很可能出错。我的做法是先把问题拆成多个子任务——时间范围是本周、维度是品类、指标是销售额和环比变化率、操作是排名——然后分别解析，最后用一个规则脚本拼接成最终查询。这里拆分的准确率比直接生成的准确率高出一大截。
第二点是“样本少而精”。与其给模型几百条SQL样例让它“学会”，不如给20条高质量、覆盖典型查询模式的样本SQL。我维护了一组“黄金样本”，涵盖了时间对比、同环比、分组排名、占比计算、条件筛选、多表关联六大类场景。每新增一类查询模式，我先把对应样本补充进去，再让模型尝试回答。实测下来，黄金样本的维护优先级远高于微调。
{ "task": "生成SQL查询", "query": "本周各品类销售额排名及环比变化率", "sub_tasks": [ {"type": "time_range", "value": "本周（周一至周日）"}, {"type": "dimension", "value": "品类"}, {"type": "metric", "value": ["销售额", "环比变化率"]}, {"type": "operation", "value": "按销售额降序排名"} ], "sql_template": "SELECT category_name, sales_amount, (sales_amount - prev_sales_amount)/prev_sales_amount AS mom_ratio FROM ... WHERE date >= CURRENT_DATE - 7 GROUP BY category_name ORDER BY sales_amount DESC" }3.4 增强检索链路：向量检索、知识图谱和重排的组合使用
RAG链路的质量直接决定LLM得到的信息是否准确、是否完整。基本流程是：用户提问 → 意图识别 → 多路检索 → 重排融合 → 上下文注入 → 生成回答。多路检索是关键。
什么叫多路检索？就是针对同一个问题，同时使用不同的检索策略，最后合并结果。我用了三路：向量检索（按语义相似度找指标卡片和知识片段）、关键词检索（按精确匹配找表名、字段名、业务术语）、图谱检索（按实体关系找关联概念和历史查询模板）。三路各擅胜场，向量适合模糊意图，关键词适合精确术语，图谱适合多跳关系。
重排阶段我试过不少方案，从简单的RRF（Reciprocal Rank Fusion，倒数排名融合）到Cohere Rerank这种模型级重排。站在性价比的角度，大多数场景RRF已经够用。只有当准确率卡在临界点上、怎么调都上不去时，我才会引入模型级重排。有一个经验值得记下来：排序权重不要静态固定，要根据问题类型动态调整。如果用户问题包含明确的专业术语（比如“SKU”“GMV”），关键词检索结果的权重应该上调，向量检索的权重下调；如果用户用口语提问（“最近生意咋样”），向量检索的权重应该更高。
检索链路还有一个“主动澄清”机制：当检索结果的置信度低于阈值时，系统不会硬猜，而是反问用户“你是想看销售额还是订单量？按自然日还是工作日统计？”这个机制一开始被我认为会影响体验，实际上线后用户反馈很好，因为错误答案造成的返工成本远高于一次澄清交互。
3.5 服务化部署与推理优化：把Token预算和并发控制在掌握中
部署层面的问题在原型阶段完全暴露不出来，一旦放到真实业务上，就是“不做优化就是灾难”。我遇到的最典型的两个问题：Token超限和并发打满。
Token超限的解法是把“对话历史”和“知识注入”做动态裁剪。对话历史只保留最近两轮完整内容和更早信息的摘要；知识注入块按照重排分数只取前Top K个片段，K的上限根据模型上下文长度动态计算。我的计算公式是：可用Token数 = 模型上下文上限 - 输出预留Token - 系统提示词Token。假设模型上下文是32K，输出预留4K，系统提示词占1K，那么知识注入和对话历史的可用Token大约是27K。按照每个知识片段平均500 Token估算，知识片段最多放50个，但我实践下来30个左右效果好于50个，因为片段太多会稀释模型的注意力。
并发控制的解法是引入网关层的分级限流和排队机制。核心链路（NL2SQL）请求走强模型，昂贵且慢，必须做严格的并发限制；意图识别和常规问答走经济模型，可以放更多并发。网关层会按照服务优先级分配流量，核心分析请求排队超过2秒时，降级为“先返回检索结果，再异步生成结论”的模式，避免用户干等。
对部署形态也要提前想清楚。如果公司对数据出域有严格要求，本地化部署是无法回避的选项。ONNX部署是一条值得探索的路径，尤其在模型推理需要嵌入已有Java服务时，它的跨语言部署优势就体现出来了。ONNX部署LLM的核心难点在注意力算子和动态轴的处理，建议提前测试目标模型对ONNX的兼容性，再决定是否值得投入工程改造。
注意：不要把本地部署理解成“下载个模型就完事”。部署完成后的监控同样关键，至少要看生成延迟、Token消耗、请求错误率、上下文命中率四个指标。我发现很多系统上线后效果变差，不是模型退化了，而是知识库更新后检索命中率下降导致的。实时监控检索命中率，比盯着模型准确率更有操作价值。
3.6 前端交互与权限控制：让“自助”真正被业务用起来
系统后端做得再好，前端交互拉胯，业务同学照样不用。我对前端交互的核心体验要求是：低门槛提问、结果可解释、异常可追溯。
入口设计上，我做了两个入口：一个是Web页面里的对话式分析助手，一个是企业IM里的机器人。IM入口的活跃度远高于Web，因为业务同学的日常工作场景在IM里。对话式界面不搞复杂的花哨组件，就是一个输入框加上结果卡片区。结果卡片区分三块：数据结论（自然语言汇总）、明细表格（可下载）、查询说明（展示系统理解的口径和SQL）。
查询说明是建立信任的关键。用户对AI的不信任很大程度来自“黑箱感”——你凭什么给我这个数字？所以我在每次回答下面都附上“系统理解”：我理解你的问题是看最近7天的销售额，按区域分组，时间范围是6月1日到6月7日，统计口径是剔除退款。用户如果有异议，可以直接点“修正”按钮，系统会根据用户的修正意见重新生成查询。这个机制让“自助”的过程变成一个可协商的过程，而不是一次性问答。
权限控制这部分容易被技术人员忽略，但其实是业务上线的硬门槛。我的做法是在指标层就做权限标注：每个指标卡片标记可见的数据范围（比如某些指标仅限大区经理以上可见）。模型生成SQL时，权限规则作为硬约束注入提示词，并在执行层做二次校验——即使模型生成了越权的查询条件，SQL执行引擎也会拒绝。双重保障的意义在于：你没法保证模型每次都100%遵守提示词，但规则层可以100%拦截。
4. 踩坑记录与排查手册：六个高频问题的实战修复经验
4.1 幻觉治理：数字幻觉与口径幻觉的“双线作战”
幻觉是LLM应用绕不开的问题，在数据分析场景里尤其危险，因为用户会把系统输出的数字当成事实依据。我把幻觉分成两类：数字幻觉和口径幻觉。
数字幻觉是指模型生成了表中不存在或计算错误的数字，比如把销售额算成了订单量。这类幻觉的根源往往是SQL生成错误，对应的治理手段就是SQL的规则校验。我搭建了一套SQL校验脚本：检查SELECT字段是否都在指标字典的白名单内、聚合函数是否与指标类型匹配（金额类指标一般用SUM、比率类指标一般用AVG或单独计算）、GROUP BY字段是否都出现在SELECT里、WHERE条件是否有明确的时间范围（防止用户问“今年”时模型只查了最近7天）。
口径幻觉更隐蔽：SQL没写错，但统计口径不对。比如“销售额”应该剔除退款，但模型生成的SQL没有加退款过滤条件，结果数字看起来合理，实际完全错误。这类问题的治理手段是“前置注入+事后校验”双保险：在生成SQL前把指标卡片里的口径规则注入提示词，在执行后把查询条件和指标卡片的“必含条件”做比对。我们开发了一个简单的“口径检查器”，如果查询SQL没有包含指标卡片上标注的“必含过滤条件”，系统直接拒绝执行并要求重写。上线之后，口径类问题的占比从原来的接近30%降到了5%以下。
4.2 Token超限与成本失控：预算版“三明治”策略
大模型应用当成生产系统来跑，Token成本不是小事。我一开始把全量知识库都放在系统提示词里，一个月下来账单直接爆掉，而且响应变慢、准确率反而下降。后来改成“检索注入”才把成本和效果调整到平衡点。
成本控制我给出一组实测数据供参考：一个中等规模公司的自助分析场景，每天大约2000次查询，每次请求的Token消耗如果控制在3K左右（输入2.4K+输出0.6K），使用主流商业模型，一个月的成本基本在可接受范围内。但如果每次请求因为知识注入过多而涨到10K，成本直接翻3倍，而且延迟会明显增加。控制Token消耗的关键动作有三个：限制知识片段数量、裁剪对话历史、统一走网关缓存。
说到缓存，这是最有效但最容易被忽略的成本优化手段。相同或高度相似的问题，直接命中缓存，不调用模型。我在网关层加了基于向量相似度的语义缓存，相似度超过0.95的请求直接复用历史答案。上线后缓存命中率约25%，扣除缓存搭建成本后，整体Token成本下降了约五分之一。
4.3 检索不命中：不是模型笨，是知识库“没有准备好”
“我怎么问模型都答不对”一半的原因不在模型，而在检索阶段就没有找到正确答案。排查检索问题时我一般按以下顺序检查：
第一，检索到了但排序太低，正确答案被淹没在Top K之外。解法是检查重排权重，或增加针对该场景的样本数据。第二，知识库里根本没有对应内容。比如用户问“履约时效趋势”，但知识库里没建这道指标，那无论怎么调检索都没用，只能补充指标卡片。第三，检索Query本身有问题。用户的原话是“能不能看下我们最近做得比较差的品类”，这个Query直接拿去检索效果极差，需要先用意图识别模型把它改写成“销售额低的品类 最近30天”，再去做检索。这个“改写后检索”的链路，我强烈建议每个RAG项目都配上，效果提升立竿见影。
还有一个在GraphRAG场景的特有问题：实体识别不完整。用户问“华东区的门店和华南区的门店在促销期间的表现对比”，图谱检索需要识别出“华东区”和“华南区”两个实体以及与“促销活动”的关系。如果实体识别只认出其中一个，查询结果就会缺一半。这类问题需要增强实体识别层的模型能力，或者给图谱查询接口增加“实体补全”提示，让大模型在查询图谱的同时检查是否遗漏了并列实体。
4.4 并发与网关问题：面对真实业务流量的一定要做的事
真实业务流量跟测试完全两回事。我们的系统上线第一周就碰到一个现象：上午10点到11点业务高峰，请求量是平峰的6倍，结果强模型服务被打满，排队超过5秒，用户纷纷反馈“系统卡死”。
排查之后发现原因很明确：没有做基于业务优先级的排队调度。所有请求都优先走强模型，导致常规问答也挤占了核心分析的资源。修复方案是增加拓扑路由规则：简单意图识别和常见FAQ类问题全部走经济模型或缓存，只有真正的分析型问题才进入强模型链路。另外给强模型链路配置了独立线程池和排队长度的上限，一旦排队超过阈值，直接返回“系统繁忙，稍后重试”而不是让用户无限等待。
网关层还有一个容易踩的坑是Key治理。多模型、多账号切换时，如果没有统一的Key管理和自动轮转，很容易出现某个账号因为成本阈值触发限流，然后整个服务不可用。我做了一个很小的“账号断路器”：连续三次调用失败就自动切换到备用Key，同时把告警发出来。别小看这么个小机制，它能让你睡个安稳觉。
4.5 部署调优：ONNX本地推理的优缺点与实测体会
如果业务允许，优先用云端的推理服务，因为性能和工程成本都最优。但合规要求、私有化部署、成本控制这些原因，可能让你必须本地跑模型。我分别在ONNX Runtime和原生PyTorch上跑过同一个7B级别的开源模型，实测数据供参考。
ONNX部署推理的速度在CPU上通常能接近甚至稍优于原生PyTorch的FP16，但是差距也就几十个百分点；真正显著的提升是在批量推理和显存控制方面。ONNX对于内存的占用和线程管理更加可控，适合做离线批量分析任务，比如每天夜里跑全量用户的经营健康度分析，每次分析不需要实时回答，只求稳定运行、不爆内存，这种场景ONNX部署是很好的选择。
ONNX部署的调试难度比PyTorch大得多，算子不支持、模型转换失败、动态形状报错，每一个都足够卡半天。我的建议是：如果没有专门的推理优化人力，优先考虑vLLM或者官方的高性能推理框架，因为整体工程成熟度和调试文档都要完善很多。ONNX路线适合“别无选择”或者“明确定位离线批处理”的场景，不要因为它听起来“轻量”就觉得是首选。
4.6 用户预期管理：从“AI算命”到“可用工具”的转变
最后聊聊一个技术之外但同样重要的问题：业务用户对LLM系统的预期管理。我发现一个很普遍的现象：用户第一次用系统时，期望值被拉得很高，觉得“AI应该什么都知道”。一旦碰到一次答错，就迅速失去信任，甚至再也不用了。而真正能支撑系统跑下去的关键，恰恰是管理好预期。
我在上线初期刻意做了“降级宣传”：不承诺“100%准确的分析”，而是强调“每一步都可校验、可修正”。系统每次回答都展示查询说明，让用户知道系统的理解依据是什么；回答底部提供“反馈纠错”按钮，鼓励用户帮忙纠正口径。这套机制跑了一个月后，有效用户留存率明显比一开始做“全自动无敌AI”宣传时的表现好得多。
还有个值得分享的细节：我在界面上特意弱化了“机器人”的概念，没有用一个卡通机器人头像来代表系统，而是直接用公司名称+分析助手的字样。从心理上，用户面对“一个产品功能”比面对“一个AI替身”更理性，会更包容，也更愿意配合修正流程。
5. 复盘与延展：下一步的优化方向
写到这里，核心的搭建和踩坑经历都梳理完了。最后分享几个我当前正在做的优化方向，这些内容没有写进正文，是为了保持主线清晰，但也算是这个项目后续的自然延伸。
第一个方向是OpenAI Function Calling式的原生工具编排。目前我们的系统里NL2SQL和检索链路是分立的，下一步想把它们整合为一个“轻代理”模式：系统可以自主决定是否需要检索、是否调SQL引擎、是否进行多轮澄清，而不是每一步都由外部流程编排。这种模式更适合复杂分析场景，但对可观测性的要求会更高，我正在摸索两者之间的平衡。
第二个方向是把LLM Wiki知识库的管理从“人工维护”向“人机协作”演进。现在的知识库卡片大多靠人写，我在尝试用模型辅助生成初稿，再由业务负责人审核。把模型从“使用者”变成“知识整理者”，知识库的更新速度会快一个量级。这里的关键是审核流程，不能完全放手让模型自己维护口径。
第三个方向是增加“分析内省”能力：当系统发现某个指标出现异常波动时，主动提示用户“销售额环比下降12%，是否要看下原因分析？”并自动生成归因探索的候选方向。这一步如果做扎实了，系统就不只是一个取数工具，而是一个真正能辅助决策的分析助手。
我个人的体会是：基于LLM的智能化自助分析，最大的门槛不在模型能力，而在工程化能力。模型负责“聪明”，系统负责“可靠”。把知识体系、校验规则、权限边界、部署稳定性这些“笨功夫”做到位，LLM应用才能真正从Demo走向生产环境。这条路没有捷径，但每走一步，系统都会变得更有价值。
