在数字化浪潮中，数据已成为企业的核心资产。在B站大会员中心部门，数据智能平台扮演着举足轻重的角色。它不仅要处理和分析大规模的会员数据，为会员服务的优化和拓展提供坚实的数据支撑，还要满足业务对于数据洞察的多样化需求。
传统的数据查询方式依赖专业的SQL语句，这对于非技术背景的业务人员来说，无疑是一道难以跨越的门槛。他们往往有明确的业务问题，却因为缺乏SQL技能而无法快速获取所需数据。例如，运营人员想要了解特定时间段内新开通大会员用户的OGV内容消费情况，以制定针对性的推广策略，但编写复杂的SQL语句对他们来说并非易事。
此时，LLM 的出现为解决这一困境带来了曙光。通过自然语言转SQL技术，LLM能够让业务人员用日常的语言与数据智能平台进行交互。业务人员只需输入 “查询男性用户且年龄大于20岁的观看《xxx》的近一周总vv和vt”，平台就能理解其意图，并将自然语言转换为准确的SQL查询语句，快速返回所需数据，大大提高了数据获取的效率和便捷性 ，为业务决策赢得了宝贵的时间。
RAG技术原理剖析
传统LLM生成SQL的困境
尽管LLM在自然语言处理领域展现出了强大的能力，但在直接生成SQL语句时，仍然面临着诸多挑战，主要存在“幻觉” 问题：模型在生成SQL时，可能会产生与实际数据模式或业务逻辑不相符的语句，例如，在处理数据时，可能会出现字段名错误引用，或者错误地关联了不相关的表，甚至编造一些实际不存在的表名和字段名，导致查询结果不准确甚至无法执行。
RAG工作流程
RAG（Retrieval-Augmented Generation）技术的出现，为解决上述问题提供了有效的途径。它创新性地将向量数据库与LLM相结合，通过引入外部知识库，极大地提升了生成SQL的准确性和可靠性 。在RAG架构中，向量数据库扮演着关键的角色，它能够存储和管理大量的上下文信息，包括数据模型、业务规则、历史查询示例等。这些信息被转化为向量形式存储在向量数据库中，通过向量检索技术可以快速准确地获取与用户问题语义相近的上下文。其工作流程框图如下所示：
文档预处理与向量库构建阶段
非结构化加载器
作为系统的数据入口，通过适配不同文件格式的解析组件，实现对本地多类型文档（.docx/.xlsx/.PDF ）的结构化转换，提取文本内容并统一输出为纯文本流（TEXT）
数据切片
基于文本语义与长度约束（如按段落、固定 Token 数）对纯文本（TEXT）进行分段切割，生成语义相对完整的文本块（CHUNKS） 。核心作用是控制文本单元大小，适配后续向量模型输入限制，同时保留局部语义完整性，为召回精准上下文做准备。
向量化（EMBEDDING）
利用预训练的文本向量模型，将文本块（CHUNKS）转化为高维向量（EMBEDDING） 。通过语义映射，把文本语义转化为向量空间的数值表示，使后续可基于向量相似度衡量文本关联度。
向量数据库
作为向量的持久化存储与检索引擎，接收并存储文本块向量（EMBEDDING） ，构建索引加速相似性查询。支持基于向量距离（如余弦相似度）的快速检索，为问答阶段提供 “语义召回” 能力。
问答推理阶段
问题向量化（EMBEDDING）
对用户输入的自然语言问题，采用与文档切片相同（或兼容）的向量模型，转化为问题向量（EMBEDDING） ，使问题与文档块在同一向量空间具备可比性。
问题检索
基于向量数据库，通过向量相似度算法，在已构建的文档向量库中检索与 “问题向量” 最匹配的文本块（CHUNKS） ，输出相关段落（CONTEXT） 。本质是语义层面的 “内容召回”，筛选与问题相关的文档上下文。
提示模板与 Prompt 构建
将用户问题与召回的相关段落（CONTEXT），按照预设的提示工程模板（如 Instruction + Context + Question 格式 ）拼接，生成符合 LLM 输入要求的 Prompt（提示词 = 问题 + CONTEXT） 。核心是通过模板约束，引导大模型聚焦上下文进行推理。
LLM 大语言模型推理
大模型接收格式化 Prompt 后，基于预训练知识与上下文信息，执行语义理解、逻辑推理，生成针对用户问题的回答内容 。利用上下文学习（In-context Learning）能力，实现基于私有文档的精准问答。
这样，LLM在生成SQL时，不再是基于自身有限的知识和记忆，而是基于从向量数据库中检索到的准确上下文，从而有效避免了 “幻觉” 问题，提高了生成SQL的准确性。例如，在处理复杂查询时，RAG可以从向量数据库中检索到相关的表结构、字段含义以及以往类似查询的成功案例，为LLM生成正确的SQL提供有力的支持。
技术方案实现
该平台整体的技术架构图如下：
基础层
为查询处理提供基础运行环境与通用能力，包括：
配置中心：管理 Query 解析规则（如意图分类词典、实体识别模板 ）、召回策略（候选集数量 / 类型）、LLM 推理参数（温度系数、最大 tokens 等 ），支持动态更新。
日志与监控：记录用户 Query、各环节耗时 / 结果（解析结果、召回列表、LLM 输出、SQL 执行日志 ），监控 Query 处理成功率、关键节点耗时、LLM 推理失败率等，异常触发告警。
权限管理：控制各环节操作权限（如 LLM 推理服务的模型调用权限、SQL 执行的数据库读写权限 ）。
数据层
为查询流程提供数据输入，涵盖：
用户侧数据：用户画像（年龄、偏好标签 ）、历史 Query 记录、交互行为（点击 / 反馈结果 ），辅助 Query 意图理解与个性化处理。
业务数据：待查询的业务库表数据（如商品信息、内容库 ）、知识库（FAQ 问答、领域知识文档 ），作为召回与推理的素材。
元数据：数据库表结构、索引信息、字段约束，用于 SQL 优化与查询合法性校验。
存储层
支撑数据的持久化与快速访问，可设计：
业务库：存储业务主数据（内容剧集信息 ）、用户配置、Query 解析规则模板。
缓存：缓存高频 Query 解析结果、召回候选集、LLM 推理缓存（如通用知识回答 ），减少重复计算。
向量存储：若用向量召回（如用户 Query 向量、内容向量 ），存储向量索引，加速召回匹配。
服务层
拆分查询流程为原子服务，支持灵活组合：
Query 解析服务：封装 NLP 能力（规则 / 模型 ），实现意图识别、实体抽取、语义结构化（如转化为查询 DSL ）。
召回服务：调用存储层 / 数据源，通过关键词匹配、向量检索、关联推荐等方式，获取候选结果集（如候选文档、数据库记录 ）。
LLM 推理服务：对接大模型，结合业务知识库（RAG 模式 ），完成语义理解增强、推理补全、结果格式化（如生成 SQL 草稿 ）。
SQL 优化服务：基于元数据与查询计划，进行索引推荐、语法优化、执行计划调整，输出最优 SQL。
应用层
面向最终用户 / 业务场景，输出查询能力：
终端查询应用：直接响应用户 Query（如搜索入口、智能问答机器人 ），经全流程处理后返回结果。
工具嵌入场景：为数据分析平台、运营后台提供查询处理 SDK，支持批量 Query 解析、结果查询（如报表生成工具调用 SQL 优化与执行 ）。
智能化扩展：基于查询流程，衍生 “Query 意图洞察”“用户需求挖掘” 等分析应用，反哺业务运营。
在自然语言转SQL的场景下，其主要的工作流程可以归纳如下：
（一） 用户层
用户通过Web界面提交Query，进入系统处理流程。为提升用户体验，系统提供开场白提示，以及让用户自主决定是否获取查询结果，以满足不同人员的SQL/取数需求。
（二）解析层
基于维度分析理论对用户Query进行语义分析，确定用户需要分析的指标和维度等信息。例如查询昨日站内订单数和金额，经过解析层处理后会得到分析维度包括日期、订单类型，分析指标包括订单数量、订单金额；查询男性用户且年龄大于20岁的观看《xxx》的近一周播放数和播放时长，经过解析层处理后会得到分析维度包括性别、年龄、剧集名称、日期，分析指标包括vv和vt。
（三） 核心处理层
包括召回服务和LLM推理服务，其中召回服务根据解析后的Query从向量知识库中检索召回相关联的知识块；将召回的知识块作为上下文，结合精心设计的Prompt工程，完成相应推理及结果生成。在Prompt设计中，明确工作流程、任务指令、提供示例参考，并合理设置参数，引导大语言模型生成准确、符合业务需求的结果。
召回服务以向量数据库为基础，所以首先我们要做的就是基于已有的各类知识，其中包括数据模型元数据、业务规则文档等不同格式的文件形式，构建出高质量的知识库。在构建知识库的过程中，数据标注是极为重要的初始环节，它为整个知识库的质量和实用性奠定基础，具体原因如下：
明确数据语义与业务规则
提升数据检索的准确性
规范数据格式与结构
便于数据管理与维护
以下是经过标注后的数据模型元信息示例
{ "table_name": "xxx_order_a_d", "description": "xxx订单表", "partition_strategy": { "field": "log_date", "format": "yyyyMMdd" }, "business_time": { "field": "pay_time", "format": "substr(pay_time,1,10)", "date_format": "yyyy-MM-dd" }, "fields": [ { "name": "order_id", "type": "varchar", "description": "业务订单唯一标识", }, { "name": "pid", "type": "bigint", "description": "套餐产品标识", }, { "name": "order_amt", "type": "double", "description": "订单金额（单位：元）", "is_metric": true, "aggregation": "SUM()" }, { "name": "pay_type", "type": "bigint", "description": "支付方式", "enum_mapping": { "1": "支付方式A", "2": "支付方式B", "3": "支付方式C" } } ]}日常工作涉及的数据模型往往多达数百甚至上千个，若采用传统人工标注方式，不仅需要耗费大量人力成本，且标注周期长、效率低，因此我们构建了AI workflow自动化标注系统。该系统能够自动识别数据表的结构特征、字段类型及业务含义，相比人工标注效率提升超 80%，同时显著降低人为错误率，确保元数据的一致性和准确性。
在完成数据模型的元数据标注后，将文件导入向量数据库时，数据分块策略的选择对检索性能和召回质量起着关键作用。常见的分块策略各有优劣：
固定长度切分：按照预设的字符数或token数量（如每块500字）进行硬性划分，这种方式实现简单、易于执行，但由于忽略了文本的语义结构，可能会在关键语句中间截断，导致信息碎片化，影响检索结果的连贯性。
滑动窗口切分：通过设置一定比例的重叠区域（例如前一块末尾20%与后一块重叠），有效缓解了语义断裂问题，使相邻数据块保持语义衔接。然而，该方法会增加数据冗余度，在处理大规模数据时可能占用更多存储空间和计算资源。
语义切分：依据标点符号、段落结构、标题层级等语义标识进行划分，能够最大程度保留文本完整性，适合处理结构化良好的文档。但在面对格式不规范或无明显语义边界的数据时，其切分效果会受到影响。
综合考虑检索精准度与上下文完整性的双重需求，本文采用创新的父子分段模式。该模式采用双层嵌套结构设计：上层的父区块（Parent-chunk）以段落、小节等较大文本单元为划分单位，旨在保留丰富的上下文信息，确保回答具备充足的背景支撑；下层的子区块（Child-chunk）则将父区块进一步细分为句子或短句，用于实现精准的关键词匹配。系统运行时，首先通过子区块进行细粒度检索，快速定位与查询最相关的数据片段，随后自动调取对应的父区块内容，将精确匹配的子句与完整的上下文信息相结合，从而生成逻辑清晰、内容详实的响应结果。
经实际测试，该模式在问答系统中的准确率提升30%，同时有效减少了因上下文缺失导致的回答偏差问题，为高效的数据检索与知识应用提供了可靠保障。实际召回测试结果如下：
（四） 优化层
该层主要对SQL进行优化，包括语法检查、逻辑优化以及性能调优等。例如通过语法检查工具确保语法的正确性，对于复杂的多表关联查询，进行逻辑优化，减少不必要的计算和数据扫描，提高查询的执行效率。
（五） 输出层
将优化后的SQL语句发送到查询引擎中执行，返回用户所需的数据结果，并且支持以可视化图表的方式展现，利于用户分析。
应用效果
自该平台上线后，数据查询效率得到了显著提升。在传统的查询方式下，业务人员需要花费大量时间学习和编写SQL语句，平均每次查询从提出需求到获取数据，可能需要数小时甚至数天的时间，这还不包括中间可能因为SQL编写错误而进行的反复修改和调试 。而现在，借助RAG技术，业务人员只需在系统中输入自然语言问题，几分钟内就能得到准确的查询结果。例如，以前进行一次关于会员观看行为的复杂分析，可能需要数据分析师花费半天时间编写SQL并进行数据处理，现在业务人员自己就能在几分钟内完成查询，大大缩短了数据获取的周期，使业务决策能够更加及时地基于最新的数据做出。对于简单的单表查询和复杂的多表关联查询，平台均能给出准确的分析过程和结果。示例如下
同时，后台对一定周期内用户的Query和回答进行数据回收，过滤知识库Scope以内的查询后，经过人工对比，整体准确率达到85%+。
挑战与未来展望
平台在取得阶段性成果的同时，也遇到了一些亟待解决的挑战。
在推理速度方面，目前系统的响应时间仍有待优化。这主要是因为该系统涉及多个复杂的子过程，包括用户Query的解析、向量检索以及大模型生成SQL等步骤。其中，向量检索过程需要在海量的向量数据库中进行相似度计算，随着业务数据量的不断增长以及知识库规模的持续扩大，检索耗时也随之增加。而大模型在生成SQL时，由于其本身的计算复杂度较高，同样会消耗大量的时间。例如在处理复杂查询时，系统从接收到用户问题到返回SQL语句，有时需要数秒甚至更长时间，这对于追求实时性的数据查询场景来说，用户体验会受到较大影响。
为了应对推理速度慢的问题，我们计划从多个角度进行优化。在向量检索环节，我们将探索更高效的向量索引算法，同时，对向量数据库进行合理的分片和缓存策略设计，减少不必要的检索开销。对于大模型生成SQL部分，我们考虑采用模型蒸馏、量化等技术，在不显著降低模型性能的基础上，减小模型的计算量和存储需求，从而加快推理速度。
在迭代测试方面，由于涉及到自然语言理解、SQL生成等多个环节，每个环节都是非幂等性过程，其中任何一个环节的变动都可能影响到最终结果的准确性和可靠性。例如，当对知识库进行更新时，很难快速准确地评估这些变化对整个系统性能的影响。而且，不同业务场景下的查询需求复杂多样，难以通过有限的测试用例覆盖所有可能的情况。
当前我们建立了半自动化测试工作流，通过后台收集用户Query，然后通过API请求生成测试结果，最后人工对测试报告进行review，评估是否满足上线要求，不过该方案的缺点就是耗费人力。因此我们计划引入AI Agent，对测试报告进行全面的review，最后人工抽样对Agent生成的结果做二次校验。
未来，我们将不断提升系统性能，提供更加高效、智能、可靠的数据服务，助力业务团队更便捷地获取有价值的数据洞察，推动业务持续创新发展。
-End-
