在數字化浪潮中，數據已成為企業的核心資產。在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生成的結果做二次校驗。

未來，我們將不斷提升系統性能，提供更加高效、智能、可靠的數據服務，助力業務團隊更便捷地獲取有價值的數據洞察，推動業務持續創新發展。