午参加了百度 MEG 数据中台的技术沙龙，之前一直想学习借鉴的百度 ChatBI 也揭开了神秘的面纱。LLM 浪潮兴起之后，国内的 AI×Data领域， 个人比较关注的几个头部也基本都有了初步了解，于是新开一个系列，专门记录自己从这些产品中学习到的内容。
功能一览
现场百度的老师在介绍的时候，用「朴素」一词来表达在ChatBI 中实现的功能特点，没有太花哨的东西，都是现在实际在数据消费过程中的重要节点和关键过程。
- 出数与图表
- 问数据
- 出图表
- 做报表
- 归因与洞察
- 智能总结
- 波动归因
设计目标
虽然功能是朴素的，但是在设计的思路和目标上，可以看得出来还是有比较严格的诉求的。这里其实想重点聊聊这几条标准。
目标：一个优秀的可投入工业生产环境的智能化 BI 标准 1：有丰富完备的 BI 功能
标准 2：极速的交互秒级
标准 3：结果 100% 准确可信赖
百度 ChatBI，2024-01-13
先从标准 3 说起，因为在数据场景里，准确性是第一位的，如果无法做到可信和可依赖，就会影响用户对工具的质疑。但是 LLM 偏偏又有一定的随机性，包括幻觉的出现，所以团队定义的 100% 准确度目标是让人敬佩又让人怀疑的。
所以在后面的 QA 环节，我毫不犹豫的问了这个问题。老师的回答让我关注他们采取的 prompt Suggestion、知识增强和人工干预甚至可修改干预的措施。这些我理解是用工程的手段来弥合用户的问题和数据结果的GAP，但是我依然对 100% 的目标是存疑的，当然我对 100% 的定义是 用户发出的自然语义 Vs 数据结果。之所以这么判断，是因为用户的口语化表达极不收敛，即使校准 Prompt。
标准 1 表达的是借助 LLM 调用现有的 BI 内容和功能，BI 内容比如借助智能助手直达看板中的指标卡片， BI 功能是指借助智能助手进行 BI 工具的操作甚至是看板制作。标准 2 是快速的查询和响应，对于速度这个问题确实是个会影响用户体验的问题，但是从个人角度来看，当前的实践标准能完成标准 3已经是相当强悍了，在这样一个数据场景下，准确度的重要性远高于速度。
价值衡量
当前 LLM 的应用是一种技术热潮，基本是个研发团队都会想试试 LLM 能给他们带来的东西，但是就像跨越鸿沟的模型一样。不仅用户有鸿沟，场景和功能也有鸿沟。在这个降本增效为主旋律的语境下，降低用户使用门槛和提高效率这些价值论述是一种模糊的正确。就是感觉对，也能提供一些论据，但总是隔靴搔痒，无法提供有力的数据证明。
就笔者自己在内部推进的感受而言，用户的感受和跨越鸿沟的曲线一样，对技术感兴趣的左侧人群觉得这个特别好，虽然有不准的，但是可以忍受，已经觉得有不错的表现；比较严谨的右侧人群，依然觉得帮不上大忙；而中间沉默的大多数则是一种偶然遇到了试一试的态度。
所以这引发了我另一个很好奇的问题，这个项目推进的产出怎么衡量？当把这样一个问题抛给百度的老师时，我得到的回答是优先满足场景，现在单纯得看用户数和渗透率是没有意义的。而且在老师的演讲过程中，他也提到了这是一个长期的事情，方向对，持续做才行。
技术细节
- 如何做到更好的准确性？
- 多表定位和多表关联怎么做的更好？
- 归因分析这里，具体采用的技术是什么样的？是在 Prompt 中加入数据扫描的规则吗？
- 权限校验和表定位以及 SQL 执行的逻辑和顺序？
- Prompt 的构成有哪些？
- LLM 的选型过程中，没有考虑过 GPT 吗？
- 在数据这个场景下，Chat 是一个好的方式吗？
- ……
这些都是我脑海里一直出现的问题，也希望今天借此机会交流的问题。但是受限于时间，有很多问题都还没有搞清楚。但是有一些被回应到的问题，还是印象深刻，也记录于此。
- ChatBI 从一开始就是基于文心一言，只有文心一言，因为是公司内部自研的，所以安全性相对可控。所以对于现场提出 OpenAI 接口带来安全性的问题，在百度这个场景下不存在。
- 多表定位的问题，本质上是个分类问题，所以即使不使用大模型来解决，使用常见的分类模型 CNN也可以很好的解决这个问题。
- 权限是安全里重要的一环，但是 ChatBI 也不是从头构建权限，而是对接原有的 BI 工具权限体系
- Prompt 的构成包括身份+清晰的任务描述+提示。身份就是角色设定，比如BI 专家；清晰的任务描述，就是规定好任务动作，而且这里还用了前述的 PromptSuggestion 的方式，能够在一定程度上收敛用户的提问；提示，就是最好能用到一些 FewShot 的方式。
- SFT 调优技术，要有足够高的样本质量，和足够充足的样本数据。当然这里在聊的时候有顺便推广了一下文心千帆。
对于关心的自动化归因分析和多表关联的场景，还有待进一步交流确认。
津公网安备12011002023007号