当前，大语言模型的应用正在全球范围内引发新一轮的技术革命与商业浪潮。腾讯音乐作为中国领先在线音乐娱乐平台，利用庞大用户群与多元场景的优势，持续探索大模型赛道的多元应用。本文将详细介绍腾讯音乐如何基于 Apache Doris 构建查询高效、实时统一分析的 OLAP 引擎，使 OLAP 作为底层基建加强模型连接转化效率、结果输出准确率，最终将大模型 + OLAP 引擎结合为用户提供个性化、实时化、灵活化的智能数据服务平台。
作者 | 腾讯音乐大数据架构师 张俊、罗雷
腾讯音乐娱乐集团（以下简称“腾讯音乐”）是中国在线音乐娱乐服务开拓者，有着广泛的用户基础，总月活用户数超过 8 亿，通过“一站式”的音乐娱乐平台，用户可以在多场景间无缝切换并享受多元的音乐服务。我们希望通过技术和数据赋能，为用户带来更好的体验，为音乐人和合作伙伴在音乐制作、发行、销售等方面提供支持。
基于公司丰富的音乐内容资产，需要将歌曲库、艺人资讯、专辑信息、厂牌信息等大量数据进行统一存储形成音乐内容数据仓库，并通过产品工具为业务人员提供数据分析服务。在内容数仓搭建的过程中，我们的工作始终围绕降本增效为主要目的进行优化与迭代，希望在数据服务方面不断提升产品工具的开发与分析效率，同时在数仓架构方面能够有效减少架构成本与资源开销。
在传统数据服务中，我们为业务分析师提供了多种数据服务，包括 SQL 查询、固定看板、定制化的分析工具以及人工跑数。然而，在实际应用过程中仍然存在一定痛点：
SQL 查询平台：业务分析师根据需求进行 SQL 语句编写，对平台数据进行查询分析，每位业务人员都需要掌握 SQL，导致学习成本高、上手难度大。
固定看板（Dashboard）：技术人员基于常规业务开发制作数据看板，虽然能够简化业务分析师查询的过程，但是看板制作成本高且灵活度低，当面对复杂的用户问题时，看板无法及时调整以满足需求变更。
定制分析工具：基于特定的业务需求，技术人员需要定制化开发产品分析工具，整体开发成本过高，且单一的开发工具不具备通用性，随着工具数量增加，操作介面变得散乱，从而降低业务效率。
人工跑数：当以上三个场景都无法满足业务需求时，业务分析师需要向技术人员提需求进行人工跑数，沟通成本过高、整体解决效率低下。
随着行业发展趋势，LLMs 大语言模型（LLMs - Large Language Models，以下统一简称为大模型）出现有效地解决了这些问题。当平台融入大模型后，平台用户输入的问题会进入大模型进行语义解析，自动转化为 SQL 语句触发 OLAP 引擎开启数据分析与查询。通过平台智能问答交互的方式，业务分析师不再需要依靠人工编写 SQL 提供查询分析结果，技术人员也不需要再制作过于固定或者过于定制化的产品工具。大模型 + OLAP 引擎结合的全新数据服务模式，不仅为平台用户提供了个性化、灵活表达、秒级回复的服务体验，还大幅降低了企业内部技术与业务学习成本，加速数据分析效率，实现多端入口统一、界面统一的平台构建。
本文将详细介绍腾讯音乐如何基于 Apache Doris 构建查询高效、实时写入且统一的 OLAP 分析引擎，使 OLAP 作为底层基建加强大模型与之连接转化的效率、结果输出的准确率，最终提供更智能化的问答交互服务，也希望通过这篇文章为有相关业务需求的公司提供不同视角和思路。
大模型 + OLAP ：开启数据服务平台新模式
在大模型 + OLAP 架构方案中，目前经典方案如下图所示，大模型充当中间层将用户输入的自然语言转化为 SQL 执行语句，OLAP 作为底层存储和数据处理的引擎，负责接受和执行从大模型发送过来的 SQL 语句，对数据进行预聚合、多维分析等操作，满足大规模数据集的查询分析需求。
然而，这种架构在实际落地过程中也面临一定挑战，例如语义理解的准确性、查询效率的优化、私域知识的理解等方面，具体如下：
复杂数据口径不统一：大模型对于技术方面的词汇，如字段、行列、表等无法理解，相反对于业务方面的词汇，如公司收入情况、日活跃用户数量等能够提供有效翻译与转换。因此挑战之一是需要思考如何引导用户进入指标范围内提问，挑战之二是当用户存在对多种指标、多类指标查询时，需要考虑如何保持指标维度口径的统一、如何有效生成对应的指标计算公式。
模型处理效率较低：现阶段大模型虽然支持交互能力，但推理速度较慢，需要花费十秒级以上响应，用户每增加一个问题输入，就需要花费更多等待时间，使服务质量降低。同时大模型整体按照 Token 收费，使用量增加时也会导致平台成本升高。
私域知识无法识别：虽然大模型已经开展许多公开数据集的语言转换训练，但面对企业内部的大量专业术语仍无法很好地理解转化。以音乐内容数据库为例，大模型时常缺少对于某些冷门歌曲的认知，在问答过程中无法正确给出交互反馈，因此我们需要增强大模型对于私域知识的理解。
定制场景无法满足：大模型主要依据自身数据集进行回答，会出现“知识幻觉”（输出缺乏依据的内容）问题，我们需要允许第三方插件的接入使大模型得以联网，让用户借助内部插件完成更定制化、更多样的任务。因此如何接入、匹配并触发组件功能是我们的重点优化目标。
面对经典方案中的落地难点，我们的总体解决思路是将以上四大挑战逐一拆解，通过组件叠加分阶段完善大模型 + OLAP 架构构建，最终实现全新的交互问答服务模式，接下来我们将介绍各阶段挑战对应的解决方案。
01 增加语义层：处理复杂数据问题
为了解决复杂数据处理问题，我们在大模型与 OLAP 中间增加 Semantic Layer（以下简称语义层）。
一方面语义层作为连接技术与业务之间的转换桥梁，能够将数据字段翻译为业务用户的术语，使业务知识作为额外的抽象层。通过语义层，业务分析师不需要在定义指标后存储于 OLAP 数仓中，能够直接在语义层中指定过滤条件，将所需指标筛选后生成 SQL 语句并在 OLAP 中进行字段查询。这意味着，业务分析师能够把多源数据按照需求定义成语义信息并形成语义标准，有效解决了多种指标、多类维度计算口径不统一的挑战。
另一方面语义层能够针对业务计算逻辑，进行语义加工、描述、关联和运算。语义层在过滤数据后，能够屏蔽由表关联所产生的复杂指标计算公式，将多表 Join 场景进行拆解、转化，形成较为简单的单表查询，以提升语义转化的准确性。
02 设定人工经验：处理模型效率问题
针对模型效率问题，我们的解决思路是对指标计算、明细查询、人群圈选等查询场景进行复杂度判定，将简单查询场景直接跳过大模型解析的步骤，进入底层 OLAP 进行处理分析，使大模型更加专注处理复杂查询场景。
为此，如上图所示我们在模型中添加人工经验判断。当业务分析师输入 “查询各大音乐平台收入”问题时，模型依据判定规则发现该场景只需要提供某个指标或几个维度即可完成，这时不需要将问题进入大模型解析，直接使用 OLAP 进行查询分析，能够有效缩短响应时间，提升结果反馈效率。此外，跳过大模型解析的步骤也能够节省 API 调用经费，解决平台使用成本升高的问题。
03 增加内容映射：处理私域知识问题
针对私域知识的问题，我们在大模型上游增加 Schema Mapper 、在外部建立业务知识库，将平台用户的问题与知识库进行连接，通过 Schema Mapper 判定是否存在部份文字能够与知识库内容匹配。如果匹配成功，大模型将进一步解析转化、OLAP 分析处理。Schema Mapper 与业务知识库的引入，有效解决了大模型对私域知识理解不足的问题，提升语言处理的效果。
目前，我们正在不断对 Schema Mapper 匹配准确性进行测试与优化，将知识库中的内容进行分类处理、字段评级等操作，同时将输入文本进行不同范围的内容映射（如全文本映射与模糊映射），通过映射结果来加强模型语义解析的能力。
04 插件接入：处理定制场景问题
定制化场景主要指代业务范围之外的查询需求，需要将音乐内容数据与法律、政治、金融、监管等方面信息结合提供问答服务。通过增加插件，使平台用户能够访问实时更新且无法包含在训练数据或业务知识库中的信息，以实现定制化交互。
由于插件类型不同，模型接入方式也会有所不同，常见的接入方式主要分为两种：
Embedding 本地文本接入：该方式首先对本地文档进行向量化处理，通过语义向量搜索，找到本地文档中相关或者相似的词语进行匹配，之后将文档内容注入大模型解析窗口中生成答案。这种方式非常适合业务分析师希望将音乐内容数据库与最新政策等一类较为私有的文件结合完成查询需求。
ChatGPT 第三方插件接入：每款插件具备对应的 Prompt 与调用函数。业务人员在安装某款插件之后，在与模型对话中可以通过 Prompt 词触发函数开启调用。目前第三方插件类型丰富，涉及行业广泛，能够有效增加多元场景的处理与响应能力。
超音数平台框架构思
根据上述大模型 + OLAP 的四大解决方案进行了方案整合，以此进行框架设计并将其命名为超音数平台。大模型主要作用于自然语言与 SQL 分析语句的连接与转化，OLAP 引擎则作为数据存储与查询分析的核心基建。
超音数平台对于业务流程如图所示，模型运转具体过程如下：
用户输入问题通过 Schema Mapper 检索，判定字段是否匹配与业务知识库。
如若匹配则跳过大模型解析步骤，直接利用知识库中的指标计算公式触发 OLAP 进行查询分析；如若不匹配则进入大模型，开启下一步判定。
大模型首先通过人工经验判定问题复杂度，简单查询将指定 OLAP 引擎直接分析，复杂查询则开启语义解析形成 DSL 语句。
DSL 语句通过语义层进一步过滤、拆解关联查询场景，生成简易单表 SQL 语句以触发 OLAP 数据处理与查询加速。
针对需要与外部信息结合的查询场景，大模型会判断是否调用第三方插件来辅助完成查询。
以“某首歌曲能否在综艺节目播出”为例，在经过检索匹配、语义解析后，大模型选择利用 OLAP 数据查询与第三方版权行业插件结合的方式进行回答，最终呈现结果由数仓中的歌曲信息与插件判定结果构成。
如今，业务分析师只需要在超音数平台中定义指标含义、维度类型即可直接开展自然语言的问答交互服务。同时还可以在平台中内置插件、丰富指标市场来拓展语义解析能力，完全覆盖了业务在常规与定制化场景下的查询需求。平台基于大模型 + OLAP 的模式加速业务分析效率，减少技术开发成本，向智能化、个性化、实时化的全新业务服务模式更近一步。
在这里希望可以与大家分享该开源项目，让更多人体验和学习大模型构建，也欢迎感兴趣的读者们共同参与大模型开发与建设。
超音数开源框架：https://github.com/tencentmusic/supersonic
超音数平台框架演进
在平台构建的过程中，OLAP 引擎作为整体架构的基建对 SQL 语句处理、数据存储分析、上游应用层的查询响应等有着至关重要的作用，我们希望通过架构升级以加强大模型到 OLAP 引擎的转化效率与结果输出准确性。
接下来我们将对比介绍 OLAP 早期架构与新一代架构在数据写入与查询两方面的差异，分享在架构演进过程中大模型 + OLAP 模型优化历程，最终助力超音数平台的构建，开启新一代的数据服务模式。
01 数据架构 1.0
我们初期的业务架构如上图所示，分为处理层、分析层、应用层三部份，用户文本在进入大模型之后解析为 SQL 语句使 OLAP 开始执行任务，具体的工作原理如下：
处理层：在 ODS- DWD- DWS 三层中将数据整合为不同主题的标签和指标体系之后，通过对 DWS 调度与采集所需字段，在 DWM 层将维度与指标数据加工成大宽表。
分析层：通过大宽表进入分析层，将数据导入 Clickhouse 与 Elasticsearch，其中 Clickhosue 主要负责维度与指标两类数据的查询加速，作为分析引擎为后续提供报表开发服务；Elasticsearch 主要负责维度数据处理，作为搜索/圈选引擎。
应用层：业务人员基于场景选取所需要的标签与指标，在应用层中创建数据集作为逻辑视图，同时可以二次定义衍生的标签与指标。
在实际业务使用中，早期架构的数据处理方式存在大宽表带来的数据延迟与存储浪费、多套组件导致架构冗余带来指标维度重复定义、学习与运维成本高等问题，具体如下：
数据延迟：处理层不支持部分列表更新，DWS 层数据写入产生延迟后会造成大宽表的延迟，进而导致数据时效性下降。
运维成本高：在处理层大宽表中维度数据量平均占一张大宽表的 50%，且在大部份情况下变化缓慢，这意味着每一张宽表的开发会将维度数据叠加，造成存储资源的浪费、维护成本增加；在分析层中存在多引擎使用的问题，查询 SQL 语句需要同时适配 Clickhouse 与 Elasticsearch 两个组件，增加人力成本，且两套组件也会加大运维难度，运维成本进一步升高。
架构冗余：在应用层进行指标与维度定义时，导致相同数据会进行多次定义使各种指标、维度定义口径不一致，造成权限不可控，例如上图所示的 T1 （标签）与 M1 （维度）在应用层中，被不同数据集多次定义。
02 数据架构 2.0
基于以上问题，我们开始对架构进行改造升级，并在众多 OLAP 引擎中选择了 Apache Doris 来替换原有组件，主要因为 Apache Doris 具备以下核心优势：
实时导入：Apache Doris 能够支持海量业务数据的高吞吐实时写入，时效性可以做到秒级完成导入。
引擎统一：支持 Multi-Catalog 功能，能够通过 Elasticsearch Catalog 外表查询，实现查询出口统一，查询层架构实现链路极简，维护成本也大幅降低。
查询分析性能：Apache Doris 是 MPP 架构，支持大表分布式 Join，其倒排索引、物化视图、行列混存等功能使查询分析性能更加高效极速。
在数据架构 2.0 版本中，数据架构保留处理层部份，主要升级分析层架构，并进行了语义层叠加：
分析层：引入 Apache Doris 替换 Clickhouse 组件，
