作者：腾讯音乐大数据架构师，张俊、罗雷
导读： 当前，大语言模型的应用正在全球范围内引发新一轮的技术革命与商业浪潮。腾讯音乐作为中国领先在线音乐娱乐平台，利用庞大用户群与多元场景的优势，持续探索大模型赛道的多元应用。本文将详细介绍腾讯音乐如何基于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 架构构建，最终实现全新的交互问答服务模式，接下来我们将介绍各阶段挑战对应的解决方案。
增加语义层：处理复杂数据问题
案：处理复杂数据
为了解决复杂数据处理问题，我们在大模型与 OLAP 中间增加Semantic Layer (以下简称语义
层)。
一方面语义层作为连接技术与业务之间的转换桥梁，能够将数据字段翻译为业务用户的术语，使业务知识作为额外的抽象层。通过语义层，业务分析师不需要在定义指标后存储于OLAP 数仓中，能够直接在语义层中指定过滤条件，将所需指标筛选后生成SQL语句并在OLAP 中进行字段查询。这意味着，业务分析师能够把多源数据按照需求定义成语义信息并形成语义标准，有效解决了多种指标、多类维度计算口径不统一的挑战。
另一方面语义层能够针对业务计算逻辑，进行语义加工、描述、关联和运算。语义层在过滤数据后，能够屏蔽由表关联所产生的复杂指标计算公式，将多表 Join 场景进行拆解、转化，形成较为简单的单表查询，以提升语义转化的准确性。
设定人工经验：处理模型效率问题 
针对模型效率问题，我们的解决思路是对指标计算、明细查询、人群圈选等查询场景进行复杂度判定，将简单查询场景直接跳过大模型解析的步骤，进入底层 OLAP 进行处理分析，使大模型更加专注处理复杂查询场景。
为此，如上图所示我们在模型中添加人工经验判断。当业务分析师输入“查询各大音乐平台收入”问题时，模型依据判定规则发现该场景只需要提供某个指标或几个维度即可完成，这时不需要将问题进入大模型解析，直接使用OLAP 进行查询分析，能够有效缩短响应时间，提升结果反馈效率。此外，跳过大模型解析的步骤也能节省API调用经费，解决平台使用成本升高问题。
增加内容映射：处理私域知识问题
针对私域知识的问题，我们在大模型上游增加Schema Mapper、在外部建立业务知识库，将平台用户的问题与知识库进行连接，通过Schema Mapper判定是否存在部份文字能够与知识库内 容匹配。如果匹配成功，大模型将进一步解析转化、OLAP分析处理。Schema Mapper与业务知识库的引入，有效解决了大模型对私域知识理解不足的问题，提升语言处理的效果。
目前，我们正在不断对Schema Mapper匹配准确性进行测试与优化，将知识库中的内容进行分类处理、字段评级等操作，同时将输入文本进行不同范围的内容映射(如全文本映射与模糊映射),通过映射结果来加强模型语义解析的能力。
插件接入：处理定制场景问题
定制化场景主要指代业务范围之外的查询需求，需要将音乐内容数据与法律、政治、金融、监管等方面信息结合提供问答服务。通过增加插件，使平台用户能够访问实时更新且无法包含在训练数据或业务知识库中的信息，以实现定制化交互。
由于插件类型不同，模型接入方式也会有所不同，常见的接入方式主要分为两种：
·Embedding 本地文本接入：该方式首先对本地文档进行向量化处理，通过语义向量搜索，找到本地文档中相关或者相似的词语进行匹配，之后将文档内容注入大模型解析窗口中生成答案。这种方式非常适合业务分析师希望将音乐内容数据库与最新政策等一类较为私有的文件结合完成查询需求。
·ChatGPT 第三方插件接入： 每款插件具备对应的Prompt 与调用函数。业务人员在安装某款插件之后，在与模型对话中可以通过Prompt 词触发函数开启调用。目前第三方插件类型丰富，涉及行业广泛，能够有效增加多元场景的处理与响应能力。
更多精彩内容，欢迎观看：
带你读《Apache Doris 案例集》——05 当 Apache Doris 遇上大模型：探秘腾讯音乐如何 基于大模型+ OLAP 构建智能数据服务平台（2)：https://developer.aliyun.com/article/1405739
