在数字化时代，数据已成为企业最宝贵的资产之一。然而，随着数据量的爆炸性增长，如何高效地找到并使用这些数据，成为了企业面临的一个重大挑战。火山引擎DataLeap团队通过创新性地将大模型技术应用于数据资产管理平台，开发出了名为“找数助手”的工具，旨在解决这一问题。
本文将深入探讨“找数助手”的设计理念、技术实现以及在数据检索和使用中的应用实践，介绍围绕以下几点展开：找数、用数场景介绍；解决方案；大模型在检索中的应用；大模型在其他环节的应用。
引言
数据资产平台是对数据地图的一次迭代升级，可以将其视作一个更高级版本的资产管理平台。数据资产平台的定位是打造一个一站式的数据资产门户，旨在简化数据消费的流程，以此促进数据的高效生产。
这个平台涵盖了多个方面的功能，包括数据资产的消费与管理、元数据中心的建设，以及资产管理中心的能力开放。这一切都致力于为用户提供更加便捷和高效的数据管理和应用体验。
01 找数、用数场景介绍
背景
1. 场景背景及挑战
在互联网公司中，数据被视为生命线，贯穿于整个业务流程。短视频平台等产品依赖于海量的数据，而在这些数据中，最重要的部分便是数据资产。
无论是数据资产平台的核心关注点，还是公司整体的发展战略，数据消费始终是重中之重——数据消费不仅包括数据研发、分析、运营，还涉及到管理层的决策制定。
随着数据量的激增，第一个问题就是如何找到适用的数据，这是实现数据消费的前提。首先，需要快速定位到所需的优质数据。
接着，需要确保这些数据能够与实际需求匹配。例如，对于一个直播活动的运营者来说，如何找到最近30天内表现最好的主播，便是一个典型的需求。
2. 核心问题与场景应用
因此，围绕数据消费引出了两个关键问题：
第一个问题是如何在海量数据中快速定位目标数据。这个过程类似于定义一个有效的搜索机制，使用户能够基于需求精准找到所需的数据。
第二个问题是如何应用这些数据，特别是如何对选定的数据进行详细的业务分析和定义解释。
例如，在数据消费的场景中，传统方法通常依赖于结构化的组织形式和关键词检索。这种方法在数据量较少、业务复杂性较低时较为有效，通常在早期的数据地图构建中有所应用。
然而，随着数据规模的扩大和业务复杂性的增加，传统的关键词检索方式开始显得力不从心，难以应对日益复杂的需求。
实践案例
为了更好地理解找数和用数的问题，来看2个找数、用数场景case：
1. 找数据
用户在交易域中寻找特定粒度的交易数据时，传统的关键词匹配难以奏效。以“抖火极三端”为例，这一术语涉及抖音、火山、极速版三个应用的集合，且与交易域中的细分维度紧密相关。
这种情况下，关键词搜索无法有效定位所需数据，因此，需要更智能的搜索与数据分类机制，以确保用户能够快速找到符合特定业务场景的数据。
2. 用数据
在应用数据时，用户可能会问及数据表中某字段的具体类型及含义，如“user type”字段的枚举值及其含义。
这类查询超出了简单的关键词检索范围，要求系统能够识别并解释复杂的数据结构和业务逻辑。因此，平台需要具备智能数据解析能力，支持对表格字段和枚举值的深入分析与解读，以满足用户对数据理解的需求。
难点
智能数据解析能力的目标，是将传统的关键词检索和向用户提供大量文档或schema的方式，转变为一种更智能、更高效的对话式推荐答案机制。
这种机制类似于用户可以直接向数据的生产方或开发人员提问，当需要使用数据或对数据有疑问时，系统会以对话形式提供准确的答案，从而替代过去依赖关键词检索和人工阅读文档的方式。
然而，这种对话式推荐答案的方式也面临一些挑战：
1. 找数和用数问题复杂多样
数据查找和使用的需求往往非常复杂，涵盖了不同的业务场景和多样化的应用需求。这种复杂性增加了系统对数据精确查找和匹配的难度。
2. 元数据不完整或缺失，治理难度大
在数据开发过程中，原始数据的信息可能并不完整，甚至存在缺失的情况。这使得数据治理的难度加大，要求系统具备更高的治理能力以确保数据的准确性和完整性。
3. 业务黑话和术语较多，对算法模型泛化性要求高
业务领域内的专业术语和行业“黑话”较多，要求系统中的算法模型具备高度的泛化性和准确性，能够在复杂的语境中正确理解并提供数据。这对模型的性能和能力提出了较高的要求。
02 解决方案
传统search的局限性和解法
1.传统关键词搜索的局限性
传统的关键词搜索在以下几个方面存在明显的局限性：
语义理解不足
传统搜索仅匹配关键词，无法深入理解用户的真实意图，导致对复杂查询的处理能力有限。
上下文语境缺失
在用户进行多轮追问或表达含有上下文关联的查询时，传统搜索无法准确把握语境，从而导致搜索结果与用户需求不符。
无法处理自然语言表达的多样性
用户可能以不同的方式表达相同的需求，但传统搜索引擎往往只能识别固定的关键词组合，无法应对自然语言中多样化的表达方式。
无法理解语义关系
关键词搜索无法理解词与词之间的语义关系，如同义词、反义词或词语间的关联性，导致搜索结果的准确性和相关性不足。
2. 解决方案
为了克服上述局限性，提出了关键词检索与语义检索相结合，并引入大语言模型（LLM）的解决方案。这一方案通过以下几个步骤实现更为精确的搜索和推荐：
问题理解
利用大语言模型对用户查询进行语义分析，理解其背后的真实需求，即使用户以不同方式表达相同的意图，系统也能准确捕捉。
意图判断
通过语义检索，系统不仅能识别关键词，还能根据语义分析结果判断用户的意图，从而提供更贴合需求的搜索结果。
推荐答案排序
结合关键词检索与语义检索，系统能根据相关性对检索结果进行排序，将最符合用户需求的答案推荐至前列。
总结与提炼
大语言模型具备对复杂查询进行总结的能力，能够简洁明了地提炼出关键信息，帮助用户更快找到所需内容。
3. 例子
一个典型的例子是，当用户提出查询“帮我看看商家 GMV 用哪张表”时，系统首先通过语义分析识别用户意图，即查找适合的Hive表。
在召回了多个相关表之后，系统能够进一步判断哪张表与用户需求最为相关，并指出该表中哪些字段可以回答用户的问题。这展示了大语言模型在理解复杂语义和提供精确答案方面的优势。
找数助手整体架构
DataLeap找数助手-整体框架
用户的问题首先通过对话框架处理，之后进入问题理解模块。在问题理解阶段，进行意图识别和实体识别。如果用户涉及多轮对话，还会进行对话合并。这些操作可以通过调用大模型来实现，解析大模型的结果即可。
接下来，将意图识别的结果组装成参数，调用检索模块。检索过程包括经典的召回与排序，召回不仅涵盖语义检索，还包括关键词匹配和基于属性的召回。排序分为粗排和精排，最后加入大模型混排，包括结果的组装与呈现。
在底层存储方面，采用了三种存储方式：Vector DB用于存储向量，实现embedding语义召回；ES负责词匹配召回；MySQL则主要用于记录历史对话的记忆功能。
找数助手整体流程
DataLeap找数助手-具体操作流程
以下通过一个示例来说明：假设用户请求查找某个粒度的表。流程包括以下几个主要步骤：
Query
用户提交查询请求，如“要找某个粒度的表”。
问题理解
在这个阶段，系统不仅识别用户的意图，还提取关键实体，例如“xx粒度”，将其作为查询条件的一部分。
对话管理
通过对话管理模块，对用户的查询进行流程编排。这一模块整合和补全信息，以构建完整的搜索参数。
Search
使用构建好的搜索参数调用检索模块。检索模块会返回结构化数据，如相关的表信息，以及文档类的数据。
LLM混排
对返回的数据进行混排处理。混排模块将结构化数据和文档数据整合成推荐结果，例如推荐出10个相关的表。
LLM总结
最后，系统对推荐结果进行总结，提供最终建议。例如，推荐最适合的表或字段。如果查询与推荐的结果完全无关，系统会告知用户无法找到答案，并建议联系相关人员。
整体流程确保用户的查询得到准确的处理和合适的回应。
03 大模型在检索中的应用
检索系统介绍
在构建初期，使用了传统的工单词检索模型。该系统基于RAG（检索增强生成）架构，通过将查询转换为向量并存储在向量数据库中，找出最相似的前N个向量，然后将这些向量作为上下文输入到大模型中以生成回答。
然而，该系统在实际应用中暴露出了一些缺陷：
1. 低准确率
直接使用embedding模型进行排序，准确率的天花板较低。模型的本身性能限制导致召回的准确率不高。
2. 黑话和常识性问题
在Vector DB的召回过程中，可能会存在黑话（行业术语）和常识性问题，影响查询的效果。
3. 同义词和问法差异
不同的问法可能导致同义的查询被排序为不同的结果，造成用户困惑。例如，用户询问“我想找xx表”和“给我推荐一下xx表”可能得到不同的结果，但实际查询意图是相同的。
上述缺陷的对应解法则如下所述：
1. 优化Embedding
提升embedding模型的性能，强化模型的能力。通过改进embedding和引入关键词或属性增强召回质量。
2. 引入Reranker模型
在初步召回后，增加一个Reranker模型进行相关性排序。这一层能够进一步提高结果的准确性和相关性。
3. 利用LLM进行结果混排
使用大语言模型（LLM）的强泛化能力对最终结果进行混排，减少模型对输入数据量的依赖，提高整体效果。
通过这些优化措施，系统的检索性能和结果质量得到显著提升。
embedding&reranker增强
如何利用大模型（LLM）来增强现有的embedding和reranker模型。
1. 存在的难点
现有的线上数据量不足以支持有效的模型训练。之前用户的检索行为多为关键词搜索，提供的查询数据对当前模型的训练意义有限。简单的查询数据在复杂语义理解和泛化方面存在不足。
对于训练数据的标注需求较高，需要具备足够的领域知识，这使得标注过程成本高昂。传统的标注方法无法有效支撑大规模数据需求。
文档类型多样，无法通过一种通用方式划分文档内容，使得文档在切分后难以保持合适的大小以供检索。例如，白皮书中的一段500字文本可能包含多个观点，传统的工程式划分方式可能会截断这些观点，导致信息的丢失。
2. 解法
利用LLM生成数据
通过LLM生成数据，并对embedding和reranker模型进行微调与持续预训练，以克服数据不足的挑战。
知识抽取与文档优化
利用LLM对知识库进行知识抽取，将文档内容转换为Q-A对的形式，从而规避文档划分问题，确保每个知识片段完整且易于检索。
流程图展示了整个召回检索系统的结构，包括通过embedding生成向量，存储在Vector DB中，并通过排序生成最终答案。此阶段引入了大模型以辅助生成和优化结果。
为什么需要混排
尽管已有embedding和Reranker，但仍然需要在Reranker的基础上进行混排。这是因为现有的Reranker模型在复杂语义理解、泛化能力和跨领域知识融合方面存在显著的局限性。
1. Reranker问题
复杂语义理解能力弱
Reranker模型在处理具有深层嵌套结构和多重逻辑关系的文本时表现不足，导致在面对复杂查询时，无法准确理解用户意图。
泛化能力有限
Reranker模型难以处理预训练中未曾见过的知识，特别是在面对同义但表述方式不同的查询时，可能导致排序结果不一致。例如，同样的查询内容，由于表达方式的变化，原本正确的答案可能被排到后面。
跨领域知识融合弱
在需要将不同类型数据（如指标、维度、文档）混合排序的场景中，Reranker模型的表现欠佳。尽管这可能是由于训练数据的限制，但要兼容此类复杂情况，成本极高。
2. 解法
为了解决这些问题，尝试引入大型语言模型（LLM）对Reranker结构进行混排。这种混排方法不仅增强了Reranker的复杂语义理解和泛化能力，还能有效处理跨领域数据的融合。然而，直接使用LLM进行混排也面临挑战：
结构化推理能力不足
LLM在文本生成和理解方面表现出色，但在结构化推理和排序方面仍有不足。尤其在需要精确推理和排序的场景中，LLM的表现可能不理想。
Token限制
大模型的Token限制是一个主要问题。例如，当需要对包含上百个字段的大型表格进行排序时，Token限制会严重影响模型的处理能力即使选用了具有32K Token限制的模型，也可能无法完全满足需求。
耗时与幻觉问题
大模型在输出结果时，因其Transformer架构的特点，往往是逐字生成，导致处理时间较长。此外，模型可能会出现“幻觉”现象，即生成不准确的内容，这也是大模型固有的问题
为应对这些挑战，采取以下措施：
选择高泛化性的大模型
选用了火山系列的高泛化性模型，并确保Token限制足够大，以适应复杂场景的需求。
微调模型
针对特定场景，构造了专门的训练集进行微调，以提高模型的准确率并减少幻觉的出现。
流式输出优化
在产品层面，通过流式输出优化减少端到端延时。例如，在对多个表进行排序时，先展示前三个表的结果，用户需要更多内容时再进行交互展示，降低了等待时间。
通过这些优化，混排的引入不仅提升了模型的能力，还为用户提供了更快、更准确的检索体验。
LLM混排架构
接下来介绍一下LLM混排架构的流程设计。在这个架构中，有几点需要特别注意：
首先，这里有一段设计主要是为了服务于Prompt的组装，目的是确保Prompt的token数量不过多，因为过长的Prompt可能会导致模型处理效率下降。
其次，大模型存在一个固有问题，即输入的Prompt中如果包含过多无关信息，模型的准确率可能会降低，同时“幻觉”现象（生成不相关或不准确内容）的发生率也会增加。因此，在实际操作中有一个重要的经验，就是要确保输入到大模型中的内容尽量是有用且有序的。这样，大模型的表现会更好，输出结果也会更加准确。
经过这些改进，特别是引入大模型的混排机制后，系统在找表场景中的表现得到了显著提升。当前，Top 10的准确率接近70%，这已经是一个非常好的效果。
04 大模型在其他环节的应用
在答案总结中的应用
在排序之后，通常会进行一个总结环节。如果直接将排序后的结果（如TOP10的表或文档块）展示给用户，用户在有答案时可以找到所需内容，但如果没有答案，用户可能需要逐一查看这些内容，耗时费力，体验较差。
因此，理想情况下，系统应能直接告知用户是否有答案。如果有，指出正确答案；如果没有，明确告知并建议联系数据开发团队或业务负责人。
为解决这一问题，大模型被用于答案总结和拒答。具体而言，当用户询问权限域的资源类型时，大模型能够从相关文档中提取出关键信息，如0、1、2、3分别代表库、表、行、列，使用户无需翻阅整个文档即可获取所需信息。
当前大模型在自然语言处理方面表现优于Hive表处理，因此在处理用户查询时更适合用于文档总结。
在业务知识沉淀中的应用
1. 业务知识沉淀中存在的问题
业务知识是动态变化的，随着时间的推移和业务的发展，需要不断更新和优化，这对知识管理带来了挑战。
人工解答用户咨询的问题后，需将这些解答内容收集并整理为文档，这一过程繁琐且耗时，增加了数据开发团队的负担。
2. 对应的解法
对于无法自动解答的用户咨询，仍需依赖人工解答，确保问题得到及时响应。
人工解答后，大模型（LLM）会自动分析用户与数据开发人员的对话内容，将其提炼成FAQ，并自动存储到知识库中。
由于自动生成的FAQ可能存在偏差，因此需要进行人工校对和修正，确保内容准确无误。
通过这种方式，大模型能够对未存储的数据进行沉淀和总结，逐步完善知识库，实现知识管理的机制闭环，并保持业务知识的动态更新与优化。
05 总结与建议
在项目实施过程中，有一些经验教训和优化建议：
1. 经验教训
相信LLM的能力
项目初期，由于大模型的能力尚未成熟，效果不理想。然而，随着GPT-4的推出和技术进步，应用场景逐渐展现出潜力。对大模型的能力应保持乐观预期，因为技术不断提升，token成本也逐渐降低。
小模型优化至关重要
尽管大模型表现出色，但其延迟和容量限制仍需依赖小模型来弥补。优化每个环节的小模型对项目的端到端效果至关重要。
2. 后续优化
微调与优化
通过对大模型进行微调，减少生成的幻觉率，提高准确率，是提升项目效果的关键。
引入agent
为改进多轮对话和处理用户意图不明确的情况，将引入agent以优化对话流，增强相关性判断和澄清功能。
这些经验教训和优化措施将有助于进一步提升项目性能和效果。
