ChatBI是今年比较火的一个话题，它和企业知识库问答一样，是ToB领域极少数有希望用相对低成本落地的LLM应用；很多企业已经对此有过一些探索，还有更多企业认为该技术尚不成熟， 还处在观望状态。
朋友圈看到有人说，预计90%的ChatBI项目都会失败——在不做任何相关配套工作的前提下，我非常认同这个观点。
关于下面的问题，相信计划或正在探索ChatBI的很多朋友也都有困惑：
经过20余项目陪跑和100余客户的深入交流，帆软FineChatBI团队积累了不少ChatBI的实践经验，我们得到了很多反直觉的认知，在这里做一些分享，希望能可以帮助你少走一些弯路。
我们的第一个观点是：LLM写SQL不靠谱。
LLM写SQL是真的不靠谱，体现在3个方面：精度、性能和可信性。
我们判断，对业务用户来说，即使再有容忍度，平均精度要达到75%~80%才能保证不会弃用。
LLM幻觉是一个已知问题，它在一定程度上是可以被容忍的，但如果在数据的应用，它会被严重放大；在用户眼里，对于非结构化的数据，结果不满意，大不了我再问一次，而结构化数据答案是不可以错的。
LLM写SQL时，会在哪些地方会有幻觉？我们和一些客户对LLM写SQL做过不少尝试，目前已经发现并且判断很难解决的地方比如对时间理解错误、排序逻辑错误、子查询错误、错误理解表关联关系等等；
FineChatBI的选择是，用LLM把用户的问题转写成结构清晰的查询语言（表达清晰的语句甚至不需要转写），用OLAP分析操作指令集调用FineBI这样一个成熟的底座，以模拟人工拖拉拽的形式直接出图，这样生成的图表直接和转化后清晰的问题意图相匹配，精度得到大幅的提升。
现在一个写SQL为主的产品，返回一个问题能做到6s已经是优秀了，部分Text2SQL产品的返回时间甚至能到都在12s甚至15s以上。一个问题等10s，这个性能，用户真的能接受么？
我们认为，一个用户能接受的最长问题的返回时长必须控制在3S内，否则体验太过糟糕，用户也不会坚持用下去；
影响LLM写SQL性能的变量有：LLM模型的尺寸、是否本地化部署、硬件资源投入如何、SQL语句复杂度等；
上面已经提到了，FineChatBI并没有选择让LLM写SQL，而是通过一个小尺寸的语义解析模型处理清晰语义，LLM去处理模糊语义，我们实现了清晰语义返回平均能到0.2s，模糊语义平均能做到2s。
ChatBI在应用中，难免会有错误的答案，怎么才能排查到结果对错？如果答案是错的，怎么能快速修复？解决这两个问题，才能代表一个ChatBI产品具有可信性。
Text2SQL路线，一般会给到用户一串SQL语句，这个思路最开始被很多IT认可，因为直觉表明这样是可以看清楚答案，也容易调试；实际上，这不是一个用户思维导向的设计：业务用户看得懂SQL么？他们想要看SQL么？另一方面，我们发现SQL的调试工作难易程度是和SQL语句的复杂度正相关的，再考虑到多表关联查询，如果在测试期间没有探索到它的边界，在应用实际落地的时候，结果排查和错题修复的挑战会很大。
FineChatBI给到了用户一段可以清楚读懂的图表生成规则，同时，用户可以调整其中的维度、指标、枚举值、分组条件等，按照自己的设想二次点选生成新的相关图表；另外，结合强大的FineBI底座，对于一些SQL很难支持的问法都可以通过FineBI原生支持的快速计算轻松实现。
我们的第二个观点是：ChatBI不能开箱即用。
一个ChatBI项目想要成功落地，需要有它的天时地利人和：
-
-
-
人和，是要有配套的组织驱动力，能链接到业务调研到真实需求，有明确的责任人能披荆斩棘往前推进。
2024年的FineChatBI就像是一个创新药在上市前需要做临床试验，我们在与客户共创的过程中，遇到过最大的挑战是，一些客户并没有找到自己的痛点，硬套ChatBI作为一个解决方案，最后发现没有效果。
建议最好是能多和业务团队对话，了解他们日常取数场景是什么样的，遇到过哪些痛苦，然后对症下药去干。
当然，如果客观上存在困难，不得不先尝试，基于成熟的数据去开发demo给用户中的积极分子，通过这个过程去找场景，但是成功率恐怕会很低，需要有一定的心理准备。
从用户数、使用频次、使用场景来出发，我们分别来看，适合使用ChatBI的用户群：
重要的事情说三遍：LLM并不擅长数据加工！LLM并不擅长数据加工！LLM并不擅长数据加工！
我们判断，50%的数据消费应用的推动都受到了数据底层准备的影响，ChatBI对数据的要求比BI要更高一些，一般体现在避免字段名歧义、数据不能有冗余、确保字段类型正确等；
准备好宽表，或干脆搭配指标管理平台吧，否则你会无比痛苦。
知识配置是不可避免的，它并不是丢一些语料给LLM就可以解决的；
就好像所有梁山好汉都喊宋江一声“哥哥”（语料），那么再先进的LLM也不可能知道宋江就是及时雨（黑话），既然黑话要准备映射表，为什么不直接做配置，反而舍近求远去训练LLM呢？
在我们的实践中，知识配置分为两类，一类是同义词，一类是企业独有的一些其他知识，如重点城市=成都市+贵阳市 华北地区=山东+山西+河南+河北；
在FineChatBI中，同义词只需要配置必要的、预计AI肯定猜不出来的企业独有知识，相似的语义或相似的字段是不需要配置的：
对于相似的语义，如字段名为销售额，问业绩，这个通过LLM是可以猜出来的；
对于相似的字段，如字段名为娃哈哈100ml矿泉水，问娃哈哈矿泉水，这个通过算法可以匹配到的。
我们的第三个观点是：ChatBI不适合先给领导用。
我们认为，ChatBI项目要成功，在企业内部需要至少3个角色的，这三个角色可能是2个人，也可能不止3个人，他们分别是：领导、产品经理和IT。
最核心的角色，承担整个项目成败的KPI，整体节奏规划，用户群确定、需求收集和识别、内部推广，拓展运营等；
ChatBI的上线是一个循序渐进的过程，由产品经理主导，大概执行下面的流程：
①项目团队组建——>职责拉通——>需求调研——>需求评估——>
②选定目标业务域1——>数据准备——>知识配置——>权限配置——>内部测试——>试点运行——>后台分析——>用户回访——>用户培训——>系统上线——>错题修复——>成果汇报——>
从上面的流程中，相信各位不难看出，当项目之初，产品经理还不具备一定经验，该项目还没有获得领导的信任和理解时，可以确定很难做好对领导的需求收集、预期管理等。
因此，ChatBI并不适合一开始就给大领导用，也不适合大规模并行推广，而应该线性推广，不断地干成、夯实，再拓展。
拍板决策投入，保障产品经理获得必要的业务支持，参加项目启动仪式，现场明确项目范围、项目成功标准、时间节奏等；
①业务代表，代表本业务团队为产品经理输入需求，讲清楚痛点；
②业务团队中的ITBP，这个角色可以协助IT进行知识配置和数据维护、权限配置，否则IT单方面很难完整收集到业务团队里的知识和权限配置要求。
对于第一个完整业务闭环，帆软经过这一年来的打磨，推出了一个【场景陪跑服务】，帮助客户把第一个场景用起来。
我想正式上线一个ChatBI，还有哪些要关注的？
在预计场景、底层准备、组织驱动力三个条件都具备的前提下，ChatBI的落地成功率是很高的，这个时候如果要正式上线，安全性、算力成本、持续运营投入是你一定会关注的地方。
是否具备企业级权限控制能力、LLM是否支持本地化部署。
理论上LLM的尺寸越大效果越好，但更大尺寸意味着更高昂的硬件资源成本，FineChatBI采用基于小尺寸开源 LLM 完成多任务精调的FineLLM，对资源成本要求是很低的。
我们常常会感叹模型日新月异的能力效果，却忽略了这个效果背后的迭代频率。
同理，我们常常会关注一个ChatBI产品的精度，却忽略了这个精度背后的定义和条件，是1个人使用下的精度，是10个维度指标下自由组合的精度，还是上线仅两天的平均精度？
当用户数扩大，当数据范围扩大，当时间线拉长，对精度的影响都是立竿见影的，这背后的迭代频率也是非常快的；
在企业内部，ChatBI的受众肯定是逐步在增大的，所以团队是否考虑过单独的资源来承接这些运营调优的工作，是否有方法论指导怎么优化，产品是否有相关功能支撑范围扩大后去运营提升问答效果，都是需要重点考虑的。
我们常对客户说，ChatBI它首先是一个严肃的企业级应用，其次才是AI；而LLM，它包含于AI，而不是等于AI。
一个企业级应用，不管有没有AI，不管用了什么技术，它的核心目的始终都是帮助客户安全、稳定、低成本地解决业务上的问题，进而创造价值。
FineChatBI在设计过程中，我们综合去考虑稳定性、性能、客户成本等很多因素去选择实现方法，对LLM的使用始终持着谨慎乐观的态度；
有一些能力比如模糊检索，LLM可以做，有成熟算法也可以实现，我们可以提供的方案是把枚举值都给LLM做训练，客户扩大自己的模型尺寸就行，但如果用算法实现，客户的成本是不是会更低，所以我们的方案未必是LLM实现；
有一些配置工作，比如知识配置，交给LLM去落地，客户的综合成本是人工配置的几十倍，效果也不稳定，所以我们并不建议客户交给LLM去处理；
再比如很多能力，LLM原本就不擅长，如预测、离群点识别等，都是靠其他更适合的AI能力实现的；
而AI之外的功能，比如可视化，更不是LLM擅长的。
商业化的ChatBI，是一个很考验厂商态度、研发投入和能力的事情，做这个事情是为了炫技，还是为了落地，背后的难度和投入不是一个数量级的；
本文主要是讲今年业内较为普遍地把【快速问数】作为ChatBI第一阶段的落地经验，实际上的ChatBI不只是查数，它希望能帮助到广大没有专业分析背景的业务用户自主完成一些个性化的分析工作，例如思路拆解、异常检测、归因分析、趋势预测、报告生成等。
挑战重重，但我们觉得我们走在正确的路上，ChatBI帮助100%业务用户用好数据，最终有一天是能实现的。 |
