导读 本次分享由爱奇艺技术总监张晓明老师主讲，晓明老师引领了爱奇艺数据中台与 BI 系统的智能化升级，尤其在湖仓一体化架构的实践和创新方面有深入研究。本次分享题目为《盘活数据资产，驱动价值释放：解密数据仓库与 Chat BI 的融合之道》。
主要介绍了以下八个模块的内容：
1. Chat BI 相关背景介绍
2. Chat BI 核心实现流程（三步法 + 细化拆解）
3. Chat BI 技术架构设计（分层拆解 + 精准召回）
4. Chat BI 搭建关键难点与解决方案
5. 提升 Chat BI 效果的实践经验
6. 数仓接入的核心流程
7. 数据洞察：基于 RAG 知识库的深度分析
8. 用户运营：冷启动与推广策略
分享嘉宾｜张晓明 爱奇艺 技术总监
编辑整理｜孙婧婧
内容校对｜郭慧敏
出品社区｜DataFun
01
Chat BI 相关背景介绍
首先和大家分享下数据仓库与 Chat BI 融合的背景，主要围绕 BI 系统的发展历程、各阶段数据获取路径、Chat BI 的优劣势及核心关注点展开。
1. BI 系统的发展历程
BI 系统的发展可归纳为三个版本，不同版本在服务用户、核心能力及开发者要求上存在显著差异：
（1）BI 1.0 时代（报表系统）
服务用户：主要面向业务负责人，无法满足所有数据需求者。
核心特点：系统开发周期长（通常以周为单位），用户仅能获取结果数据。
开发者工作：需搭建数据仓库，并对数据资产进行盘点、建立资产目录；数据分析师、产品运营等有自主能力的人员，需通过资产平台检索资产并自行编写 SQL 取数，效率较低。
（2）BI 2.0 时代（敏捷 BI 时代）
服务用户：覆盖更多有个性化需求但无 SQL 编写能力的人群，通过拖拉拽、圈圈点点的操作方式满足需求。
核心特点：开放底层数据，用户可选择的数据范围更广；依托 OLAP 技术发展，数据查询效率大幅提升，无需长时间运行大任务。
开发者工作：要求更高，除资产管理外，还需进行数据建模，将数据打成大宽表作为数据集发布到分析平台。
（3）BI 3.0 时代（Chat BI 时代）
服务用户：无聚焦限制，所有用户均可使用，通过问答方式提取数据。
核心特点：底层架构与 BI 2.0 无太大差异，主要是在原有架构上叠加大语言模型。
核心优势：降低用户使用门槛，提升数据获取便捷性。
2. 各阶段数据获取路径对比
（1）BI 1.0 时代
路径：用户发起需求→与 BI 需求 BP 对接沟通→用户等待→BI 研发人员开发→测试人员测试→数据交付→用户分析数据。
用户体感：流程规范，无需自主操作，体感相对较好，但周期长。
（2）BI 2.0 时代
路径：分析师 / 产品运营确认数据源→自助取数→数据核对→数据分析。
用户体感：需自主完成多个环节，对用户能力有一定要求，灵活性提升但操作成本增加。
（3）BI 3.0 时代
路径：用户提交需求→产品 BP 智能体与用户交互（评估需求合理性、补充信息，无法满足时引导至真实 BP）→需求可满足则生成详细需求→研发智能体通过 NL2SQL 生成 SQL 并跑数→测试智能体进行置信度评分→数据洞察智能体提供分析建议→反馈给用户。
核心变化：用智能体替代原 1.0 时代的开发、测试等人工角色，保留 1.0 的流畅流程，同时提升效率。
3. Chat BI 的优劣势分析
优势：
支持自然语言问答，交互更便捷；
准实时响应，数据获取效率高；
用户学习成本低，只需会提问即可使用；
数据扩展性相对较强。
劣势：
易出现 “幻觉”，无法保证 100% 准确（可通过 AI 评估环节降低影响）；
稳定性不足，相同问题两次提问答案可能不同（不一定是数据错误，可能是维度下钻或指标提取差异）。
4. Chat BI 建设的核心关注点
（1）技术关注点
数据引擎基建能力与查询性能需匹配企业现状：无需追求 “最好技术”，需结合企业成本、维护难度等实际情况选择；
本地大语言模型基建能力：因数据敏感，Chat BI 基本需使用本地模型，需关注模型推理速度与质量；
低成本融入现有 BI 系统：降低改造与落地成本；
数据质量、知识库管理与数据置信度：保障输出结果可靠。
（2）应用关注点
明确产品目标用户：避免 “自嗨”，确保产品有精准服务对象；
制定推广与落地策略：确保产品能有效触达用户并发挥价值。
02
Chat BI 核心实现流程（三步法 + 细化拆解）
Chat BI 的宏观实现流程可概括为意图理解、数据开发、测试三步，但为提升准确性，实际落地时需对各环节进行细化拆解，结合多轮校验与智能体协作保障效果。
意图理解是确保后续流程准确的基础，需解决 “用户问题歧义” 与 “需求结构化” 问题，具体分为以下环节：
用户问题解析与歧义消除生成结构化详细需求细化拆解与多轮模型校验数据开发环节需完成从 “结构化需求” 到 “物理 SQL” 的转化，重点解决 “大语言模型幻觉” 与 “SQL 可用性” 问题，分为以下阶段：
语义 SQL 生成语义 SQL 校准物理 SQL 生成测试环节需覆盖 “SQL 可用性”“结果正确性”“用户可读性”，同时应对执行过程中的异常情况：
SQL 执行与降级策略结果处理与可视化置信度评估03
Chat BI 技术架构设计（分层拆解 + 精准召回）
技术架构以 “元数据管理” 为核心，通过分层设计实现 “精准召回- 需求确认 - SQL 生成 - 执行反馈” 的闭环，同时适配个性化场景与性能需求。
1. 元数据层：分类管理，提升召回准确性
元数据是 Chat BI 的 “知识基础”，需按类型拆分管理，避免召回混乱：
普通元数据
定义：通用型元数据，如数据资产平台中的指标、维度、维度值；
召回方式：采用 “精确召回 + 模糊召回” 双策略：
精确召回：将元数据信息存入 HLP（高性能检索引擎），支持用户精确提问的精准匹配；
模糊召回：将元数据同步至 RAG（检索增强生成）知识库，解决用户提问含错别字、长尾词的召回问题。
个性化元数据
定义：场景化专属元数据，如视频元数据（分辨率、时长）、用户标签元数据（会员等级、观影偏好）；
存储与召回：存入 ClickHouse，利用其高效的列式存储能力，适配个性化场景下的快速召回需求。
2. 需求确认层：模型选型适配场景
需求确认需将 “用户问题 + 召回元数据” 转化为结构化需求，核心是选择适配的大语言模型：
早期误区：优先选择推理模型，但后期易出现逻辑发散；
优化方案：改用千问类模型，其在需求聚焦与结构化输出上表现更优，可精准生成包含 “数据集、筛选条件、分组逻辑” 的需求文档。
3. SQL 生成层：多模型协同 + 语法校验
SQL 生成是技术核心，需平衡 “准确性” 与 “适配性”：
模型选择：DeepSeek 与千问模型表现相近，实际落地时根据业务线数据复杂度、指标类型灵活选择；
物理测试环节：以工程化工作为主，将语义 SQL 拆解至最细粒度，实现 “中文业务语义” 与 “物理表字段” 的精准映射，避免字段匹配错误。
4. 执行与反馈层：多引擎适配 + 缓存优化
执行引擎：主引擎 StarRocks（高效支持 OLAP 查询），兜底引擎 Spark（处理大数据量查询），高频数据缓存至 Redis；
结果反馈：执行完成后自动进行枚举值渲染与可视化处理，形成 “查询 - 执行 - 反馈” 闭环。
04
Chat BI 搭建关键难点与解决方案
Chat BI 落地需经历 “初期 -中期 - 后期” 三个阶段，各阶段难点不同，需针对性突破。
阶段
核心难点
解决方案
初期
过度依赖大语言模型，问题归因模糊（将所有错误归因为 “模型不行”）
拆解任务流程，将 “意图理解 - 数据开发 - 测试” 拆分为多个小环节，每个环节单独校验，定位具体问题，而非笼统归咎于模型
中期
流程复杂后，大语言模型负担重，易出现逻辑偏差
通过工程手段分担模型压力：如添加 SQL 语法校验工具、离线沙盒环境测试、枚举值自动替换规则，减少模型需处理的 “非核心逻辑”
后期
接入数仓数据后，元数据描述不匹配用户视角（原数仓元数据面向开发者，用户无法理解）
修正数仓元数据：补充用户易懂的业务描述，确保元数据与用户提问的语义对齐
05
提升 Chat BI 效果的实践经验
1. 提高 SQL 执行成功率的 5 个关键方法
语义 SQL 沙盒环境校验：在本地搭建与生产环境一致的沙盒，执行生成的语义 SQL，若报错则触发重新生成（最多 2 轮），避免直接执行错误 SQL；
用公有知识格式解决幻觉问题：将元数据以 “CREATE TABLE”（建表语句）格式传给大语言模型，替代自定义格式，模型对公有 SQL 语法的识别准确率更高，减少 “虚构字段”；
治理无效字段召回：样本召回时过滤不匹配的字段，避免无效字段干扰模型判断（无效字段可能导致模型生成错误 SQL，效果不如零样本）；
区分聚合指标与普通字段：Chat BI 数据集需包含聚合指标，需明确告知模型 “该指标为预定义聚合逻辑”，避免模型重复聚合；
提前规避资源不足风险：通过元数据预判查询规模，若扫描分区过大，直接调用 Spark 执行，无需先尝试 StarRocks 再降级，节省时间。
2. 提升 SQL 生成准确性的 6 个实践技巧
流程优化：二次拆解需求：对用户意图与召回元数据进行二次拆解，生成技术视角的详细需求，为模型提供清晰输入；
智能化用户接管：将模糊需求交给用户确认，而非模型自行判断，确保需求与用户预期一致；
选择高质量数据集：优先选择宽表作为底座（含多维度、多指标），满足用户多样化查询需求，后期通过日志分析优化数据集；
避免事实表与字典表冲突：确保数据集中指标唯一，若存在冲突，优先保留业务常用逻辑，删除冗余或冲突指标；
业务术语微型知识库：将行业黑话、业务专属术语整理为微型知识库，接入 RAG，提升模型对业务语义的理解；
独立置信度评估：用推理模型单独评估生成的 SQL，结合用户需求与召回元数据，判断 SQL 逻辑是否准确，不依赖开发流程自带的校验，避免 “自循环误判”。
3. 优化查询性能的 3 个方向
模型选型：按需选择大小模型，非核心环节用小模型，核心环节用大模型，平衡性能与成本；
适配企业技术架构选择引擎：不盲目追求 “最优引擎”，结合现有架构选择；
特殊向量单独处理：基数大的向量与普通指标 / 维度向量分开存储，避免相互干扰，提升召回效率；业务初期用宽表做底座，后期根据日志优化字段。
4. 保障业务上线稳定性的持续集成方案
为避免新增数据 / 术语影响历史功能，需建立 “离线 + 实时” 双集成环境：
离线集成：保底测试——每日定时用历史测试用例集测试元数据状态，仅评估 “数据集选择准确性” 与 “语义 SQL 置信度”，不校验具体数据，快速定位问题；
实时集成：版本化控制——新增元数据/ 术语时，不立即生效，而是创建新版本存入 S 环境，仅跑与改动相关的用例（无需全量跑），根据评估报告决定是否上线，避免影响历史功能。
06
数仓接入的核心流程
数仓是 Chat BI 的数据基础，接入过程需解决 “元数据对齐用户视角、“数据集精准召回”、“数据标准化” 三大核心问题，确保数仓资产能被 Chat BI 高效利用。
1. 数仓接入的核心逻辑与重点
优先接入宽表，适配用户多样化需求
接入对象：数仓分层架构中，优先选择明细宽表与主题宽表，避免接入细粒度明细表导致查询复杂；
核心原因：宽表包含多维度、多指标，能覆盖用户 “一站式查询” 需求。
解决数仓与 Chat BI 建模目标差异
差异点：传统数仓建模面向开发者（注重数据存储效率、分层逻辑），Chat BI 建模面向业务方（注重数据可读性、查询便捷性）；
解决方案：通过 “循环迭代” 补充数仓资产 —— 若业务方需求在现有数仓中无对应数据，需新增衍生字段或补充业务描述，确保数仓资产匹配用户视角。
元数据是关键：保障语义对齐
核心作用：元数据是 Chat BI 理解数仓数据的 “桥梁”，若元数据描述不规范，会直接导致 SQL 生成错误；
优化方向：补充用户易懂的业务描述，将开发者视角的元数据转化为业务视角。
2. 数据集精准召回流程（以用户问题为例）
以用户提问“昨天一线城市 iPhone 用户在首页产生的人均播放时长和收入分别是多少？”为例，数据集召回需经过 “主题匹配→指标筛选→维度过滤” 三步：
主题匹配：根据问题关键词（“播放时长”“收入”），召回 “播放主题”“收入主题” 相关的所有数据集（假设共 20 个）；
指标筛选：根据 “人均播放时长”“收入” 两个核心指标，从 20 个数据集中筛选出包含对应指标的数据集（假设剩 10 个）；
维度过滤：根据 “一线城市”（城市等级维度）、“iPhone”（产品端维度），进一步筛选出包含这两个维度的数据集（最终剩 2-3 个，如 “首页用户行为宽表”“设备端播放收入表”）。
3. 数据标准化：适配 Chat BI 的必要步骤
Chat BI 需基于标准化数据才能稳定输出结果，不同状态的数仓资产需差异化处理：
数据资产状态
标准化流程
核心动作
已建模资产
直接适配
1. 补充元数据业务描述；2. 生成数据模型；3. 映射至物理表，完成接入
未建模资产
先标准化再接入
1. 在数仓中建立数据表与元数据的关联；2. 定义指标计算逻辑；3. 生成标准化模型，再接入 Chat BI
关键原则
必须完成模型建设
无论资产是否已建模，接入 Chat BI 前均需生成标准化模型，确保数据结构、指标逻辑统一
07
数据洞察：基于 RAG 知识库的深度分析
数据洞察是 Chat BI 的增值环节，需结合 “数据解读”“归因分析” 能力，从 “提供数据” 升级为 “提供结论”，核心依赖 RAG 知识库与多工具协作。
1. RAG 知识库：数据洞察的核心支撑
知识库数据源与内容
数据源：两类核心来源 —— 飞书文档（存储静态知识）、API 接口（获取动态数据）；
核心内容：指标口径、系统手册、数据规范、分析经验、BP 信息，其中 “分析经验” 是归因分析的关键依据。
知识库搭建与服务分发
搭建工具：采用 Workflow 搭建知识服务，稳定性更高，便于维护；
分发方式：1）通过机器人检索组件供内部查询；2）提供 API 接口给第三方系统；3）由智能体（Agent）自动推送相关知识。
2. 数据洞察的两大核心能力
能力 1：数据解读 —— 适配不同数据量
小数据量：直接通过大语言模型分析，快速输出结论；
大数据量：通过 AI Coding 生成 Python 脚本，在计算引擎中运行脚本，提取关键信息，避免大模型处理超量数据导致错误。
能力 2：数据归因 —— 跨数据源找原因
痛点：仅靠单一数据集无法解释数据变化；
解决方案：基于 RAG 知识库触发跨数据源查询。
08
用户运营：冷启动与推广策略
Chat BI 需精准定位目标用户，通过 “降低使用门槛”“提供价值感知” 实现冷启动，再通过持续运营提升用户粘性。
1. 目标用户定位：优先服务高需求人群
核心用户群体：分析师、产品经理、运营人员，这类人群日常需高频查询数据，且对 “高效取数” 需求强烈；
暂不优先服务人群：业务线老板（需求偏宏观，已有专属数据工具）、基层员工（数据需求低频）。
2. 冷启动与推广的 5 个关键策略
策略 1：打通权限，降低使用门槛
与现有数据平台打通权限，用户无需额外申请权限即可使用 Chat BI，避免 “有权限才能用”导致的用户流失。
策略 2：准备痛点样本，快速建立价值感知
整理各业务线高频痛点问题，作为示例展示，用户进入系统即可看到 “自己需要的答案”，提升初始体验。
策略 3：确定北极星指标，聚焦核心目标
初期以 “SQL 生成准确率” 为核心指标，可适当牺牲性能，确保输出结果可靠，避免因准确率低导致用户放弃使用。
策略 4：跟踪用户问答，持续完善样本
主动巡检用户的真实问答日志，将 “错误案例”整理为样本，优化模型与元数据，逐步提升准确率。
策略 5：主动反馈，形成闭环
对用户的查询结果，主动推送 “结果说明”，若用户反馈错误，快速响应并修复，增强用户信任。
3. 运营推广流程
选择目标业务线→开展用户访谈（明确痛点需求）→准备数据与权限配置→内部测试→选取种子用户试点→分析试点日志（优化数据集、样本）→全业务线发布→监控准确率与用户反馈→问题修复与用户回访→输出运营报告。
以上就是本次分享的内容，谢谢大家。
