當(dāng)今大模型如此火熱，作為一名數(shù)據(jù)同學(xué)，持續(xù)在關(guān)注LLM是如何應(yīng)用在數(shù)據(jù)分析中的，也關(guān)注到很多公司推出了AI數(shù)智助手的產(chǎn)品，比如火山引擎數(shù)智平臺VeDI—AI助手、 Kyligence Copilot AI數(shù)智助理、ThoughtSpot等，通過接入人工智能大模型，提升數(shù)據(jù)處理和查詢分析的效率。智能數(shù)據(jù)分析助手，采用對話式分析技術(shù)，每個普通人都可以與數(shù)據(jù)進行隨時隨地的實時交互，根據(jù)用戶的使用反饋，不斷學(xué)習(xí)，自我迭代找到答案，并在團隊內(nèi)分享對數(shù)據(jù)的見解。

簡單分析一下數(shù)據(jù)分析的發(fā)展階段：第一階段，以靜態(tài)報表為主，傳統(tǒng)BI和靜態(tài)報表基本上都是面向開發(fā)部門的，業(yè)務(wù)部門提出需求之后，由開發(fā)根據(jù)報表工具開發(fā)出固定的報表，然后業(yè)務(wù)部門查看報表結(jié)果。第二階段，敏捷BI自助式分析，在業(yè)務(wù)部門提出需求之后，數(shù)據(jù)分析可以基于敏捷BI的工具幫助業(yè)務(wù)部門快速獲取所需的數(shù)據(jù)，幫助他們獲得所需要的結(jié)果。第三階段，不管是基于大模型的AskBI還是增強分析，都是直接面向業(yè)務(wù)的，其理念是業(yè)務(wù)部門直接使用對話式BI工具能夠解決問題，獲得所需的數(shù)據(jù)結(jié)果。這一過程無需像之前那樣依賴開發(fā)部門開發(fā)報表，或者數(shù)據(jù)分析師基于敏捷BI再提供數(shù)據(jù)結(jié)果，而是直接由業(yè)務(wù)部門推進落地。

一、整體方案

通過多家數(shù)AI數(shù)智助手調(diào)研，實現(xiàn)智能數(shù)據(jù)分析的核心有：一是以指標(biāo)為中心，二是大模型。其中也分享出了如何把指標(biāo)平臺+AI技術(shù)落地方案，提出了：人人用數(shù)=AI Copilot + 指標(biāo)體系 + 合理成本的關(guān)鍵技術(shù)觀點。

指標(biāo)體系給到我們的是一個通用的數(shù)據(jù)語言，當(dāng)我們每一個人都用數(shù)據(jù)來溝通時，我們遇到的第一個障礙一定是缺乏通用的語言。就像普通話讓13 億中國人能夠自由溝通，數(shù)據(jù)的解釋權(quán)有一個標(biāo)準(zhǔn)一致的口徑也是非常重要的，是數(shù)據(jù)共享和協(xié)作的前提。

指標(biāo)數(shù)據(jù)最理想的使用場景就是，想要就有，數(shù)據(jù)準(zhǔn)確，可視化展示。用戶期望能夠隨時查看自己想要的業(yè)務(wù)指標(biāo)數(shù)據(jù)，絕大多數(shù)人都有自己的使用指標(biāo)的渠道和方法，但是需要用戶熟悉系統(tǒng)的操作、數(shù)據(jù)內(nèi)容可能會根據(jù)需求提前預(yù)設(shè)好，如果是需要指標(biāo)的話，就依賴支持者的時間了，或者需要排期開發(fā)。雖然每個人都各顯其通能夠拿到數(shù)據(jù)，但于用戶體驗來說，還是需要有操作和時間成本。

智能化的指標(biāo)應(yīng)用可以大幅提高數(shù)據(jù)指標(biāo)的用戶體驗和效率。我們希望的場景是，用戶對著手機：“告訴我昨天的DAU、用戶留存、銷售額”，系統(tǒng)就能快速的反饋給用戶這三個指標(biāo)的結(jié)果，并且是準(zhǔn)確的。

指標(biāo)的加工處理到使用中間有很多過程，從數(shù)據(jù)沉淀->數(shù)倉加工->口徑定義->報表->系統(tǒng)->用戶，中間流程最直接的方式就是自然語言直接對接到數(shù)據(jù)。

通用方案

通用做法是基于指標(biāo)要素生產(chǎn)出指標(biāo)的模型（提前預(yù)算好所有的可能），通過NLP技術(shù)，將自然語言轉(zhuǎn)譯成SQL，直接讀取指標(biāo)模型，大概的技術(shù)思路如下：

基于大模型

目標(biāo)：通過大模型技術(shù)，打造用戶在靈活搜索指標(biāo)的時候能夠快速反饋給用戶正確的指標(biāo)體驗。

核心聚焦：

1. 讓系統(tǒng)盡可能的去理解自然語言，并準(zhǔn)確的把它轉(zhuǎn)換成可執(zhí)行的SQL。
2. 盡最大的可能覆蓋用戶的靈活需求，提高指標(biāo)要素組合的成指標(biāo)的組合數(shù)量。

基于LLM生成準(zhǔn)確可執(zhí)行SQL的關(guān)鍵思路：把指標(biāo)管理模型的定義、指標(biāo)要素等元數(shù)據(jù)信息送給LLM當(dāng)作prompt進行指標(biāo)搜索與生成。

二、Text-to-SQL

Text-to-SQL（簡寫為T2S，或者是Text2SQL），顧名思義就是把文本轉(zhuǎn)化為SQL語言，更學(xué)術(shù)一點的定義是：把數(shù)據(jù)庫領(lǐng)域下的自然語言（Natural Language，簡寫為NL）問題，轉(zhuǎn)化為在關(guān)系型數(shù)據(jù)庫中可以執(zhí)行的結(jié)構(gòu)化查詢語言（Structured Query Language，簡寫為SQL）。

Text-to-SQL是什么

Text-to-SQL任務(wù)相對正式的定義：在給定關(guān)系型數(shù)據(jù)庫（或表）的前提下，由用戶的提問生成相應(yīng)的SQL查詢語句。下圖是spider數(shù)據(jù)集的樣例，問題：有哪些系的教師平均工資高于總體平均值，請返回這些系的名字以及他們的平均工資。可以看到該問題對應(yīng)的SQL語句是很復(fù)雜的，并且有嵌套關(guān)系。

數(shù)據(jù)集

常見的數(shù)據(jù)集有GenQuery、Scholar、WikiSQL、Spider、Spider-SYN、Spider-DK、Spider-SSP、CSpider、SQUALL、DuSQL、ATIS、SparC、CHASE等。

數(shù)據(jù)集的分類有單領(lǐng)域和交叉領(lǐng)域；有單輪對話和多輪對話；有簡單問題和復(fù)雜問題；有中文語言和英文語言；有單張表和多張表等。重點介紹兩個數(shù)據(jù)集：WikiSQL、Spider。

WikiSQL

WikiSQL數(shù)據(jù)集是目前規(guī)模最大的Text-to-SQL數(shù)據(jù)集，由2017年美國的Salesforce公司提出，場景來源于Wikipedia，屬于單領(lǐng)域。數(shù)據(jù)標(biāo)注采用外包。

1. 包含了80654個自然語言問題，77840個SQL語句。
2. 包含了26521張數(shù)據(jù)庫表，1個數(shù)據(jù)庫只有1張表。
3. 預(yù)測的SQL語句形式比較簡單，基本為一個SQL主句加上0-3個WHERE子句條件限制構(gòu)成，如下圖所示：

Spider

Spider數(shù)據(jù)集是多數(shù)據(jù)庫、多表、單輪查詢的Text-to-SQL數(shù)據(jù)集，也是業(yè)界公認(rèn)難度最大的大規(guī)?？珙I(lǐng)域評測榜單，由2018年耶魯大學(xué)提出，由11名耶魯大學(xué)學(xué)生標(biāo)注。

1. 10181個自然語言問題，5693個SQL語句。
2. 涉及138個不同領(lǐng)域的200多個數(shù)據(jù)庫。
3. 難易程度分為：簡單、中等、困難、特別困難。如下圖所示

Spider數(shù)據(jù)集論文地址：https://arxiv.org/pdf/1809.08887.pdf。

CSpider是西湖大學(xué)在EMNLP2019上提出了一個中文text-to-sql的數(shù)據(jù)集，主要是選擇Spider作為源數(shù)據(jù)集進行了問題的翻譯，并利用SyntaxSQLNet作為基線系統(tǒng)進行了測試，同時探索了在中文上產(chǎn)生的一些額外的挑戰(zhàn)，包括中文問題對英文數(shù)據(jù)庫的對應(yīng)問題(question-to-DBmapping)、中文的分詞問題以及一些其他的語言現(xiàn)象。

評估指標(biāo)

目前廣泛使用的是執(zhí)行準(zhǔn)確率（Execution Accuracy，簡稱EX）和邏輯形式準(zhǔn)確率（WxactMatch，簡稱EM）。

執(zhí)行準(zhǔn)確率

定義：計算SQL執(zhí)行結(jié)果正確的數(shù)量在數(shù)據(jù)集中的比例。

缺點：存在高估的可能。因為一個完全不同的非標(biāo)準(zhǔn)的SQL可能查出于與標(biāo)準(zhǔn)SQL相同的結(jié)果（例如，空結(jié)果），這時也會判為正確。

舉個例子：假如有個學(xué)生表，我們想要查詢學(xué)生表中年齡等于19的學(xué)生姓名，就如“SELECT sname FROM Student where age = 19”所示，通過數(shù)據(jù)庫執(zhí)行標(biāo)準(zhǔn)SQL后得到結(jié)果為null；此時Text-to-SQL模型預(yù)測的SQL為“SELECT sname FROM Student where age = 20”，通過數(shù)據(jù)庫執(zhí)行后也得到結(jié)果為null。雖然預(yù)測的SQL跟標(biāo)注的SQL不一致，但是結(jié)果是一樣的，根據(jù)執(zhí)行準(zhǔn)確率指標(biāo)來比較，那么就認(rèn)為模型預(yù)測是正確的。

# groundtruth_SQL
SELECT sname FROM Student where age = 19；
# SQL執(zhí)行結(jié)果
null


# predict_SQL
SELECT sname FROM Student where age = 20；
# SQL執(zhí)行結(jié)果
null

邏輯形式準(zhǔn)確率

定義：計算模型生成的SQL和標(biāo)注SQL的匹配程度。

缺點：存在低估的可能。如一個SQL執(zhí)行結(jié)果是正確的，但于標(biāo)注SQL的字符串并非完全匹配，例如，只是select 列的順序不同或SQL查詢目的完全相同的不同SQL。為了解決一部分該問題，有研究指出了一種查詢匹配精度query match accuracy：將生成的SQL和標(biāo)注SQL都以標(biāo)準(zhǔn)形式表示，再計算兩者匹配精度。這種方法只解決了由于排序問題而導(dǎo)致的誤判。另外，通過對列和表進行排序并使用標(biāo)準(zhǔn)化別名來對SQL進行規(guī)范化，也可以消除不同SQL格式導(dǎo)致的誤判問題。

舉個例子：同樣地，假如有個學(xué)生表，我們想要查詢學(xué)生表中年齡等于19的學(xué)生姓名和學(xué)生學(xué)號。就如“SELECT sname FROM Student where age = 19”所示，通過數(shù)據(jù)庫執(zhí)行標(biāo)準(zhǔn)SQL后得到結(jié)果為（張三，123456）；此時Text-to-SQL模型預(yù)測的SQL為“SELECT sno,sname FROM Student where age = 19”，通過數(shù)據(jù)庫執(zhí)行后也得到結(jié)果為（123456，張三），如果從邏輯形式準(zhǔn)確率指標(biāo)來看，因為SQL并不是一模一樣，盡管兩者只是篩選順序的語序問題，所以會認(rèn)為模型預(yù)測是錯誤的。

# groundtruth_SQL
SELECT sname,sno FROM Student where age = 19；
# SQL執(zhí)行結(jié)果
張三，123456


# predict_SQL
SELECT sno，sname FROM Student where age = 19；
# SQL執(zhí)行結(jié)果
123456，張三

研究方法

在深度學(xué)習(xí)的研究背景下，將 Text-to-SQL看作一個類似神經(jīng)機器翻譯的任務(wù)，主要采取seq2seq的模型框架?；€模型seq2seq在加入Attention、Copying等機制后，能夠在ATIS、GeoQuery數(shù)據(jù)集上達到84%的精確匹配，但是在WikiSQL上只能達到23.3%的精確匹配，37.0%的執(zhí)行正確率；在Spider上則只能達到5～6%的精確匹配。

究其原因，可以從編碼和解碼兩個角度來看。首先編碼方面，自然語言問句與數(shù)據(jù)庫之間需要形成很好的對齊或映射關(guān)系，即問題中到底涉及了哪些表格中的哪些實體詞，以及問句中的詞語觸發(fā)了哪些選擇條件、聚類操作等；另一方面在解碼部分，SQL作為一種形式定義的程序語言，本身對語法的要求更嚴(yán)格（關(guān)鍵字順序固定）以及語義的界限更清晰，失之毫厘差之千里。普通的seq2seq框架并不具備建模這些信息的能力。

于是，主流模型的改進與后續(xù)工作主要圍繞著以下幾個方面展開：通過更強的表示（BERT、XLNet）、更好的結(jié)構(gòu)（GNN）來顯式地加強Encoder端的對齊關(guān)系及利用結(jié)構(gòu)信息；通過樹形結(jié)構(gòu)解碼、填槽類解碼來減小搜索解空間，以增加SQL語句的正確性；通過中間表示等技術(shù)提高SQL語言的抽象性；通過定義新的對齊特征，利用重排序技術(shù)，對beamsearch得到的多條候選結(jié)果進行正確答案的挑選；以及非常有效的數(shù)據(jù)增強方法。

基于模板和匹配的方法

因為輸出SQL本質(zhì)上：是一個符合語法、有邏輯結(jié)構(gòu)的序列，本身具有很強范式結(jié)構(gòu)，所以可以采取基于模板和規(guī)則的方法。簡單SQL語句都可以抽象成如下圖：

簡單SQL模板示例：

1. AGG表示聚合函數(shù)，如求MAX，計數(shù)COUNT，求MIN。
2. COLUMN表示需要查詢的目標(biāo)列。
3. WOP表示多個條件之間的關(guān)聯(lián)規(guī)則“與and /或 or”
4. 三元組 [COLUMN, OP, VALUE] 構(gòu)成了查詢條件，分別代表條件列、條件操作符（>、=、<等）、條件值。
5. *表示目標(biāo)列和查詢條件不止一個！

基于模板和匹配的方法，是早期的研究方法，適用于簡單SQL，定義后的sql準(zhǔn)確率高；不適合復(fù)雜SQL，沒有定義模板的SQL不能識別。

基于Seq2Seq框架的方法

對于Text-to-SQL研究而言，本質(zhì)上屬于自然語言處理（Natural Language Processing，NLP），而在NLP領(lǐng)域中，常見的任務(wù)可以大概分為如下四個場景，1、N和M代表的是token的數(shù)量。

1. 1 -> N：生成任務(wù)，比如輸入為一張圖片，輸出圖片的文本描述。
2. N -> 1：分類任務(wù)，比如輸入為一句話，輸出這句話的情感分類。
3. N -> N：序列標(biāo)注任務(wù)，比如輸入一句話，輸出該句話的詞性標(biāo)注。
4. N -> M：機器翻譯任務(wù)，比如輸入一句中文，輸出英文翻譯。

可以發(fā)現(xiàn)的是，Text-to-SQL任務(wù)是符合N -> M機器翻譯任務(wù)的，處理機器翻譯任務(wù)最主流的方法是基于Seq2Seq框架方法，Seq2Seq是一種基于序列到序列模型的神經(jīng)網(wǎng)絡(luò)架構(gòu)，它由兩個部分組成：編碼器Encoder和解碼Decoder。因此，Text-to-SQL最主流的方法也是基于Seq2Seq框架。

更多學(xué)習(xí)和研究Text-to-SQL相關(guān)內(nèi)容，可以參考2篇綜述文章：《A Survey on Text-to-SQL Parsing: Concepts, Methods, and Future Directions》Text-to-SQL解析的概念、方法和未來方向；《Recent Advances in Text-to-SQL: A Survey of What We Have and What We Expect》Text-to-SQL領(lǐng)域的最新進展：關(guān)于我們所擁有該領(lǐng)域的知識以及和所期盼的發(fā)展方向的綜述。

三、DIN-SQL

2022年底，ChatGPT爆火，憑借LLM強大的邏輯推理、上下文學(xué)習(xí)、情景聯(lián)系等特點，按理說LLM應(yīng)該可以超過seq2seq、BERT等系列的模型，但是使用少樣本、零樣本提示方法用LLM解決NL2SQL問題效果卻比不上之前的模型。今天分享的這篇來自NLP頂級會議的論文解決了這個問題：如何改進Prompt讓LLM超越之前的方法，并讓LLM在Spider數(shù)據(jù)集上霸榜。

論文原文鏈接：DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction（地址：https://arxiv.org/abs/2304.11015）?

摘要：我們研究將復(fù)雜的文本到 SQL 任務(wù)分解為更小的子任務(wù)的問題，以及這種分解如何顯著提高大型語言模型 (LLM) 在推理過程中的性能。目前，在具有挑戰(zhàn)性的文本到 SQL 數(shù)據(jù)集（例如 Spider）上，微調(diào)模型的性能與使用 LLM 的提示方法之間存在顯著差距。我們證明 SQL 查詢的生成可以分解為子問題，并且這些子問題的解決方案可以輸入到 LLM 中以顯著提高其性能。我們對三個 LLM 進行的實驗表明，這種方法持續(xù)將其簡單的小樣本性能提高了大約 10%，將 LLM 的準(zhǔn)確性推向 SOTA 或超越它。在 Spider 的 Holdout 測試集上，執(zhí)行準(zhǔn)確度方面的 SOTA 為 79.9，使用我們方法的新 SOTA 為 85.3。我們的情境學(xué)習(xí)方法比許多經(jīng)過嚴(yán)格調(diào)整的模型至少高出 5%。

該論文提出了一種基于少樣本提示Few-shot Prompt的新穎方法，將Text-to-SQL的任務(wù)分解為多個步驟。

編寫SQL查詢的思維過程可以分解為：

1. 檢測與查詢相關(guān)的數(shù)據(jù)庫表和列
2. 識別更復(fù)雜查詢的一般查詢結(jié)構(gòu)（例如分組、嵌套、多重聯(lián)接、集合運算等）
3. 制定任何可以識別的過程子組件
4. 根據(jù)子問題的解決方案編寫最終查詢。

基于這個思維過程，將文本到SQL任務(wù)的方法分解為4個模塊：

1. 模式鏈接
2. 查詢分類和分解
3. SQL生成
4. 自我修正

如果問題被簡單地分解到正確的粒度級別，LLM就有能解決所有的這些問題。

Schema Linking Module

模式鏈接負(fù)責(zé)識別自然語言查詢中對數(shù)據(jù)庫模式和條件值的引用。它被證明有助于跨領(lǐng)域的通用性和復(fù)雜查詢的綜合（Lei 等人，2020），使其成為幾乎所有現(xiàn)有文本到 SQL 方法的關(guān)鍵初步步驟。在我們的案例中，這也是LLM失敗次數(shù)最多的一個類別（圖 2）。我們設(shè)計了一個基于提示的模式鏈接模塊。提示包括從 Spider 數(shù)據(jù)集的訓(xùn)練集中隨機選擇的 10 個樣本按照思路鏈模板（Wei 等人，2022b），提示以“讓我們一步一步思考”開頭，正如 Kojima 等人（2022）建議的那樣。對于問題中每次提到的列名，都會從給定的數(shù)據(jù)庫模式中選擇相應(yīng)的列及其表。還從問題中提取可能的實體和單元格值。如下圖顯示模式鏈接模塊的輸入和輸出的示例。

Classification & Decomposition Module

對于每個連接，都有可能未檢測到正確的表或連接條件。隨著查詢中聯(lián)接數(shù)量的增加，至少一個聯(lián)接無法正確生成的可能性也會增加。緩解該問題的一種方法是引入一個模塊來檢測要連接的表。此外，一些查詢具有過程組件，例如不相關(guān)的子查詢，它們可以獨立生成并與主查詢合并。

為了解決這些問題，我們引入了查詢分類和分解模塊。該模塊將每個查詢分為三類之一：簡單、非嵌套復(fù)雜和嵌套復(fù)雜。easy 類包括無需連接或嵌套即可回答的單表查詢。非嵌套類包括需要連接但沒有子查詢的查詢，而嵌套類中的查詢可以需要連接、子查詢和集合操作。類標(biāo)簽對于我們的查詢生成模塊很重要，該模塊對每個查詢類使用不同的提示。除了類標(biāo)簽之外，查詢分類和分解還檢測要為非嵌套和嵌套查詢以及可能為嵌套查詢檢測到的任何子查詢連接的表集。如下圖顯示分類和分解模塊的輸入和輸出的示例：

SQL Generation Module

隨著查詢變得更加復(fù)雜，必須合并額外的中間步驟來彌合自然語言問題和 SQL 語句之間的差距。這種差距在文獻中被稱為不匹配問題（Guo et al, 2019），對 SQL 生成提出了重大挑戰(zhàn)，這是因為 SQL 主要是為查詢關(guān)系數(shù)據(jù)庫而設(shè)計的，而不是表示自然語言中的含義。

雖然更復(fù)雜的查詢可以從思路鏈?zhǔn)教崾局辛谐鲋虚g步驟中受益，但此類列表可能會降低更簡單任務(wù)的性能（Wei 等人，2022b）。在相同的基礎(chǔ)上，我們的查詢生成由三個模塊組成，每個模塊針對不同的類別。

對于我們劃分的簡單類別中的問題，沒有中間步驟的簡單的少量提示就足夠了。此類示例 Ej 的演示遵循格式 <Qj, Sj, Aj>，其中 Qj 和 Aj 分別給出英語和 SQL 的查詢文本，Sj 表示模式鏈接。

我們的非嵌套復(fù)雜類包括需要連接的查詢。我們的錯誤分析（第3節(jié)）表明，在簡單的幾次提示下，找到正確的列和外鍵來連接兩個表對于法學(xué)碩士來說可能具有挑戰(zhàn)性，特別是當(dāng)查詢需要連接多個表時。為了解決這個問題，我們采用中間表示來彌合查詢和 SQL 語句之間的差距。文獻中已經(jīng)介紹了各種中間表示。特別是，SemQL（Guo et al, 2019）刪除了在自然語言查詢中沒有明確對應(yīng)項的運算符 JOIN ON、FROM 和 GROUP BY，并合并了 HAVING 和 WHERE 子句。NatSQL（Gan 等人，2021）基于 SemQL 構(gòu)建并刪除了集合運算符。作為我們的中間表示，我們使用 NatSQL，它與其他模型結(jié)合使用時顯示出最先進的性能 (Li et al, 2023a)。非嵌套復(fù)雜類的示例 Ej 的演示遵循格式 <Qj, Sj, Ij, Aj>，其中 Sj 和 Ij 分別表示第 j 個示例的模式鏈接和中間表示。

最后，嵌套復(fù)雜類是最復(fù)雜的類型，在生成最終答案之前需要幾個中間步驟。此類可以包含不僅需要使用嵌套和集合操作（例如 EXCEPT、UNION 和 INTERSECT）的子查詢，而且還需要多個表連接的查詢，與上一個類相同。為了將問題進一步分解為多個步驟，我們對此類的提示的設(shè)計方式是LLM應(yīng)首先解決子查詢，然后使用它們生成最終答案。此類提示遵循格式<Qj, Sj , <Qj1, Aj1, ..., Qjk, Ajk> , Ij, Aj>，其中k表示子問題的數(shù)量，Qji和Aji分別表示第i個問題-第一個子問題和第i個子查詢。和之前一樣，Qj 和 Aj 分別表示英語和 SQL 的查詢，Sj 給出模式鏈接，Ij 是 NatSQL 中間表示。

Self-correction Module

生成的 SQL 查詢有時可能會缺少或冗余關(guān)鍵字，例如 DESC、DISTINCT 和聚合函數(shù)。我們對多個 LLM 的經(jīng)驗表明，這些問題在較大的 LLM 中不太常見（例如，GPT-4 生成的查詢比 CodeX 生成的查詢具有更少的錯誤），但仍然存在。為了解決這個問題，我們提出了一個自我糾正模塊，指示模型糾正這些小錯誤。

這是在零樣本設(shè)置中實現(xiàn)的，其中僅向模型提供有錯誤的代碼，并要求模型修復(fù)錯誤。我們?yōu)樽晕壹m正模塊提出了兩種不同的提示：通用和溫和。通過通用提示，我們要求模型識別并糾正“BUGGY SQL”中的錯誤。另一方面，溫和提示并不假設(shè) SQL 查詢有錯誤，而是要求模型檢查任何潛在問題，并提供有關(guān)要檢查的子句的一些提示。我們的評估表明，通用提示可以在 CodeX 模型中產(chǎn)生更好的結(jié)果，而溫和的提示對于 GPT-4 模型更有效。除非另有明確說明，否則 DINSQL 中的默認(rèn)自我更正提示對于 GPT-4 設(shè)置為“溫和”，對于 CodeX 設(shè)置為“通用”。

效果對比

spider的測試集上的執(zhí)行精度（EX）和邏輯匹配精度（EM），使用GTP-4實現(xiàn)了最高的執(zhí)行精度，使用CodeX Davinci實現(xiàn)了第三高的執(zhí)行精度。

四、指標(biāo)體系

什么是指標(biāo)體系

我們在討論一個人是否健康的時候，常常會說出一些名詞：體溫、血壓、體脂率等。當(dāng)一份體檢報告出具時，上面會羅列數(shù)十項體檢指標(biāo)，而將這些指標(biāo)綜合起來考量，大概就能了解一個人的健康狀況。若其中一向指標(biāo)飄紅，那就說明身體的某項機能出了問題。

同樣，判斷一家公司的經(jīng)營情況，可以通過指標(biāo)對業(yè)務(wù)進行監(jiān)控，可往往一個指標(biāo)沒辦法解決復(fù)雜的業(yè)務(wù)問題，這就需要使用多個指標(biāo)從不同維度來評估業(yè)務(wù)，也就是使用指標(biāo)體系。

指標(biāo)體系（Indication System）就是從不同維度梳理業(yè)務(wù)，把指標(biāo)有系統(tǒng)地組織起來，形成的一個整體。

指標(biāo)的理解

理解指標(biāo)必須明確兩個重要的概念【度量】和【維度】，一個正確的指標(biāo)必須包括度量和維度?！靶詣e”是維度，“男性數(shù)量”，“女性數(shù)量”，“男性占比”，“女性占比”是度量；“城市”是維度，“一線城市占比”，“省會城市數(shù)量”，“GDP 大于 1 萬億的城市數(shù)量”是包含了維度和度量的指標(biāo)。

指標(biāo)都是匯總計算出來的，有聚合過程。例如單筆訂單的金額不能是一個指標(biāo)，統(tǒng)計一天的訂單金額才是指標(biāo)。指標(biāo)需要維度進行多方面的描述分析，維度可以根據(jù)需要可以無限擴展，例如，月汽車銷量，可以增加城市維度、品牌維度、是否貸款維度等等，就可以變成：城市月汽車銷量，大眾汽車城市月銷量、有貸款的大眾汽車城市月銷量。

通過表格理解指標(biāo)

一維表格

不存在單維表格，單一的值不能是指標(biāo)，例如：

因為上面的表格沒有描述是誰的成交金額，單獨的一個值，無法描述這個值代表的什么事務(wù)、動作，以及在什么時間周期范圍內(nèi)產(chǎn)生的這個聚合度量。

二維表格 時間周期

任何指標(biāo)統(tǒng)計都離不開時間周期，可以說所有的指標(biāo)都會涉及時間。對在一個時間段內(nèi)發(fā)生的業(yè)務(wù)進行統(tǒng)計。例如過去 24 小時，一個自然日、自然周，這一年，從月初到現(xiàn)在，往前推 30 天等等，都是時間周期。

如果在表格中描述指標(biāo)，則一定且必須最少是一個二維表格（至少有兩列），在表格中加入時間周期，就得到了這樣的結(jié)果：

業(yè)務(wù)范圍

如果確定了業(yè)務(wù)范圍，例如業(yè)務(wù)范圍=【短視頻】，度量是播放次數(shù)，并且把播放VV這個度量的時間范圍確定在天這個范圍內(nèi)：

業(yè)務(wù)這一列用于描述這個度量的業(yè)務(wù)范圍，一般稱它為業(yè)務(wù)修飾詞，但通常在表格中，不會這么存放，第二列造成了冗余，一般都簡化掉這一列，收斂成兩列的形式，把業(yè)務(wù)范圍和度量合并：

業(yè)務(wù)范圍和維度的區(qū)別

業(yè)務(wù)范圍也是維度，只不過在指標(biāo)計算的過程中，會從最宏觀的一面開始，習(xí)慣性的會定義一個范圍，要統(tǒng)計哪個業(yè)務(wù)的數(shù)據(jù)？你有 4 家水果店，別人要問你，你的日銷售額是什么？那你可能會問，是哪家門店？或者是我所有的門店？（相當(dāng)于我自己的生意范圍）它本身就是一個維度（視角）來統(tǒng)計的。但把它抽離出來，是方便于對指標(biāo)的管理與認(rèn)知。公司大了，有很多分支業(yè)務(wù)的時候，你問 DAU 是多少，肯定會帶上業(yè)務(wù)前綴的。

多維表格

如果二維表格是最小集，那么加入更多的維度和度量，這個表格就變成多維表格，例如，修飾詞=【短視頻】，加入維度=【終端】和【是否會員】則多維表格是這樣的：

也可以在此基礎(chǔ)之上，增加度量，例如增加度量【播放時長】：

多維表格的表頭樣式就是這樣的：【維度 1】【維度 2】【維度 3】【維度 n…】【度量 1】【度量 2】【度量 3】【度量 n…】。

每一行的維度+單一度量都是一個指標(biāo)

這里有一個很重要的思想統(tǒng)一，上面的多維表中每一行都是一個指標(biāo)，每一行形成了指標(biāo)的基本要求【維度】+【度量】。

經(jīng)常會有一種情況，用戶在相互溝通指標(biāo)時，沒有按照每一行是一個獨立指標(biāo)來看待。

例如，會員在 ios 端的播放 vv 和會員在安卓端播放的 vv 是兩個不同的指標(biāo)，很多人會認(rèn)為指標(biāo)是播放 vv，會員、終端都是描述指標(biāo)的維度。這樣理解沒問題。因為視角不同?！敝笜?biāo)是播放 vv，會員、終端都是描述指標(biāo)的維度“是典型的管理視角。一行一個指標(biāo)是應(yīng)用視角，在描述指標(biāo)的時候，就是確定在這一行的這個數(shù)字上，如果按照管理視角來看，那么指標(biāo)就會有很多行。

如果多個人有多個理解方式，就一定會產(chǎn)生溝通成本。

條件限定

上面的多維表是正確表達指標(biāo)的一種理想狀態(tài)，認(rèn)為每一行都是一個可以解釋的指標(biāo)。但實際使用情況不單單是用【維度】+【時間周期】+【度量】就可以完成指標(biāo)的描述的。

用戶會隨著業(yè)務(wù)的需求，有很多臨時分析需要，隨時對指標(biāo)進行條件的設(shè)定。

例如上面的表中，指標(biāo)【短視頻播放時長】，需要對用戶做分類，就會有一定的條件限制：播放時長大于1小時的用戶，非會員且播放時長大于 1 小時的用戶。

這個例子中，把指標(biāo)【短視頻播放時長】以及維度【是否會員】做了條件限制，用于描述指標(biāo)【短視頻用戶數(shù)】。

這種情況非常常見，例如大于 18 歲的用戶，本科及以上學(xué)歷，用戶登錄次數(shù)大于 3 等等。度量、維度值，都可以當(dāng)做條件作用于其他指標(biāo)。

以上情況我們統(tǒng)稱為條件限定，條件限定擴大了指標(biāo)的靈活性，可以基于實際的業(yè)務(wù)需要對指標(biāo)進行數(shù)據(jù)剪裁。

條件限定和維度值的區(qū)別：

例如像 IOS 端，是一個維度值，單獨來看 IOS 端的短視頻用戶數(shù)，IOS 端可以表達維度，也可以用于條件限定，但是維度值是確定且單一的，它不能組合。

條件限定是靈活的，它可以用度量來限制、也可以組合各種維度值，例如渠道包括：1，系統(tǒng)直播 2，線下門店 3，淘寶 4、外部直播 5、分銷商，每一個數(shù)值都代表一個維度值，他是確定的觀察視角。條件限定可以是他們中任何數(shù)字的組合，比如 1 和 2，2 和 3，1 或者 2，2 或者 3，不是 1 和 2 等等，它是靈活多變的。

總結(jié)

1. 單獨存在的度量、維度都不是指標(biāo)
2. 用表格描述指標(biāo)的最小集是二維表，單獨一列沒有任何意義，不具備可讀性
3. 絕大多數(shù)指標(biāo)都是多維表的形態(tài)：【維度 1】【維度 2】【維度 3】【維度 n…】【度量 1】【度量 2】【度量 3】【度量 n…】

1. 業(yè)務(wù)范圍幫助縮小和明確了處理數(shù)據(jù)和理解指標(biāo)的范圍
2. 如果維度不斷增多，那么數(shù)據(jù)表就是一個很寬的表。也就是常說的“大寬表”
3. 條件限定的加入，產(chǎn)生了更靈活的指標(biāo)形式

 指標(biāo)模型

原子指標(biāo)

原子指標(biāo)是指數(shù)據(jù)分析中最小的可度量單元，通常是一個數(shù)值或一個計數(shù)。原子指標(biāo)是數(shù)據(jù)分析的基礎(chǔ)，它們可以用來描述某個特定的事件、行為或狀態(tài)，如銷售額、訪問量、轉(zhuǎn)化率等。原子指標(biāo)通常是不可再分的，因為它們已經(jīng)是最小的可度量單元了。

按照上面的例子來說，原子指標(biāo)可以理解為是度量，例如【銷售金額】【播放時長】【訪問次數(shù)】等等，這些度量是不可拆解的。

原子指標(biāo)用于明確業(yè)務(wù)的統(tǒng)計口徑及計算邏輯。具備以下特性：

1. 原子指標(biāo)是對指標(biāo)統(tǒng)計口徑算法的一個抽象，等于業(yè)務(wù)過程（原子的業(yè)務(wù)動作）+ 統(tǒng)計方式。例如，支付（事件）金額（度量），曝光（事件）次數(shù)（度量）
2. 原子指標(biāo)不會獨立存在，一定是結(jié)合業(yè)務(wù)范圍，維度進行組合才有意義
3. 原子指標(biāo)加維度可以理解為一個度量在不同視角下的變化

原子指標(biāo)通常是其他指標(biāo)的基礎(chǔ)，可以通過對原子指標(biāo)的分析來得出更高級別的指標(biāo)。理解原子指標(biāo)是整個指標(biāo)管理模型中非常重要的一環(huán)。

派生指標(biāo)

派生指標(biāo)在業(yè)務(wù)限定的范圍內(nèi)，由原子指標(biāo)、時間周期、維度三大要素構(gòu)成，用于統(tǒng)計目標(biāo)指標(biāo)在具體時間、維度、業(yè)務(wù)條件下的數(shù)值表現(xiàn)，反映某一業(yè)務(wù)活動的業(yè)務(wù)狀況。

例如上面講到的多維表中的每一行都是一個派生指標(biāo)，也就是說，業(yè)務(wù)中用到的指標(biāo)都是派生指標(biāo)。

不同的派生指標(biāo)可能具有相同的原子指標(biāo)，這樣派生指標(biāo)就定義了一種等價關(guān)系，而屬于相同的原子指標(biāo)就構(gòu)成了一個對指標(biāo)體系的劃分。在每一個劃分中，存在一個可以派生出其他指標(biāo)的最小派生指標(biāo)，即最細粒度。

復(fù)合指標(biāo)

派生指標(biāo)的另一個類型是復(fù)合指標(biāo)，如果把它單獨獨立出來也可以，如果把它歸類為原子指標(biāo)也可以，取決于我們?nèi)绾巫鰯?shù)據(jù)的開發(fā)以及應(yīng)用。先來看幾個復(fù)合指標(biāo)的例子：

1. 平均銷售價格：派生指標(biāo)是通過銷售額和銷售量計算得出的，它反映了每個產(chǎn)品的平均售價。原子指標(biāo)是銷售額和銷售量。
2. 轉(zhuǎn)化率：派生指標(biāo)是通過訪問量和轉(zhuǎn)化量計算得出的，它反映了每個渠道的轉(zhuǎn)化效果。原子指標(biāo)是訪問量和轉(zhuǎn)化量。
3. 客戶生命周期價值：派生指標(biāo)是通過客戶平均購買金額、購買頻率和客戶保留率計算得出的，它反映了每個客戶對企業(yè)的貢獻價值。原子指標(biāo)是客戶購買金額、購買頻率和客戶保留率。

上面三個例子都是在原子指標(biāo)間進行計算的原子級復(fù)合指標(biāo)。

也可以通過兩個派生指標(biāo)來計算復(fù)合指標(biāo)，例如派生指標(biāo)是：最近7天浙江 iPhone  的平均銷售價格 = 近7天浙江 iPhone 的銷售額 / 近7天浙江 iPhone 的銷售量。

指標(biāo)要素

上面介紹了很多的概念，其實核心思想是統(tǒng)一對指標(biāo)的認(rèn)知和理解，每一個概念單獨去理解可能無法有一個整體的感受?？梢钥聪聢D，來完成對指標(biāo)的整體理解：

我們把【原子指標(biāo)】【時間周期】【業(yè)務(wù)范圍】【維度】【條件限定】統(tǒng)稱為指標(biāo)要素，他們是指標(biāo)的實體組織。

1. 原子指標(biāo)：就是度量，它確定了統(tǒng)計目標(biāo)和聚合方法
2. 時間周期：是一種特殊的維度，它確定了統(tǒng)計的時間范圍，從什么時間開始，從什么時間結(jié)束
3. 業(yè)務(wù)范圍：是一種特殊的維度，它確定了統(tǒng)計目標(biāo)的范圍
4. 【時間周期】和【業(yè)務(wù)范圍】單獨拿出來，是為了更好的表達指標(biāo)的意義
5. 條件限定：是對統(tǒng)計數(shù)據(jù)進行自由剪裁的過程
6. 維度：是用于觀察統(tǒng)計目標(biāo)的視角，可以有”無限個“維度

指標(biāo)要素的SQL表達方式

基于指標(biāo)要素，我們可以把它和 SQL 關(guān)聯(lián)起來理解。便于了解數(shù)據(jù)的加工和實現(xiàn)過程,有益于從技術(shù)的視角理解指標(biāo)要素。

先了解SQL的大結(jié)構(gòu)

SQL 的核心作用就是從數(shù)據(jù)表中提取數(shù)據(jù)。操作對象是表，所以可以理解為：去哪張表里，以什么樣的條件，取哪些數(shù)據(jù)，要以什么樣的方法進行數(shù)據(jù)計算

SQL 的基本操作邏輯：

SELTECT --選取哪些字段：在這里提供字段的各種計算方式，例如SUM，MIX，MIN，IF, ELSE等，對這一列數(shù)據(jù)進行操作
FROM --從哪張表取：在這里提供單表、多表關(guān)聯(lián)（JOIN,不同表提取多列合并成一張表)、多表合并 UNION（不同表，但表結(jié)構(gòu)相同，上下對齊成一張表）
WHERE --以什么樣的條件：在這里和SELECT一樣提供字段的各種計算方式，來限制取值范圍
GROUP BY,ORDER BY --組合與排序。

原子指標(biāo)對應(yīng)select

原子指標(biāo)是度量，它確定了統(tǒng)計目標(biāo)和聚合方法，在 SQL 中，它作用于 SELECT 范圍內(nèi)?？梢赃@么理解，SELECT 范圍內(nèi)的內(nèi)容就是【原子指標(biāo)】。例如：

select count(order_ID)—>計算訂單數(shù)
select sum(order_amount)->計算訂單金額

業(yè)務(wù)范圍對應(yīng)from

數(shù)據(jù)來源于哪張表，一定是確定了業(yè)務(wù)范圍，在數(shù)倉中，一般會對表進行分類，分類的規(guī)則會基于業(yè)務(wù)來進行，便于管理。例如：

select count(order_id) 
from dwd.order_list   --在訂單明細表中計算訂單數(shù)

條件限定對應(yīng)where

條件限定，一般體現(xiàn)在 where 條件語句中。表達以什么樣的條件來看指標(biāo)。例如：

-- 在訂單明細表中計算訂單金額大于100的訂單數(shù)
select count(order_id)
from dwd.order_list
where order_amount > 100

【時間周期】當(dāng)作限定條件出現(xiàn)在where條件中

-- 在訂單明細表中計算2023年5月20日訂單金額大于100的訂單數(shù)
select count(order_id)
from dwd.order_list
where order_amount > 100 AND order_date=‘2023-05-20'

【維度值】當(dāng)作條件出現(xiàn)在where條件中

-- 在訂單明細表中計算2023年5月20日訂單金額大于100且在杭州發(fā)生的訂單數(shù)
select count(order_id)
from dwd.order_list
where order_amount > 100 AND order_date='2023-05-20' AND city_name='北京'

維度對應(yīng)group by

維度會參與 select 過程和 group by 過程。group by 的目的是分組，分組就是為了以不同的視角去看數(shù)據(jù)。

-- 在訂單明細表中計算2023年5月20日訂單金額大于100的訂單數(shù), 按城市分組
select count(order_id)
      ,city_name
from dwd.order_list
where order_amount>100 AND order_date='2023-05-20' 
group by city_name

一張圖看指標(biāo)要素與SQL結(jié)構(gòu)的對應(yīng)關(guān)系

知曉指標(biāo)要素與 SQL 語句的對應(yīng)關(guān)系，能夠?qū)χ笜?biāo)的實現(xiàn)過程有更深層次的理解。這里最重要的意義在于用戶對指標(biāo)的定義能夠映射到技術(shù)方案上。能夠基于這層關(guān)系，對數(shù)據(jù)進行合理的建模、開發(fā)與使用。

指標(biāo)要素管理

上面把指標(biāo)抽象成指標(biāo)要素便于我們統(tǒng)一對指標(biāo)的理解，其實更重要的目的是便于使用與管理。管理上的意義在于能夠做到指標(biāo)開發(fā)使用從無邊界到有邊界的過程，逐步收斂覆蓋，另一層面能夠做好統(tǒng)一的標(biāo)準(zhǔn)，最后由此做基礎(chǔ)，向上放射到不同的系統(tǒng)、環(huán)境中去，形成整體的生態(tài)。

覆蓋與收斂

根據(jù)派生指標(biāo)的概念，通過【原子指標(biāo)】+【維度】+【時間周期】+【條件限定】組成了一個派生指標(biāo)，當(dāng)每一個指標(biāo)元素出現(xiàn)大于1的情況時，就會出現(xiàn)多個派生指標(biāo)，計算方法是它們的乘積。

例如上面的情況，3個【原子指標(biāo)】* 4個【維度值】* 3個【時間周期】* 2個【條件限定】= 72個派生指標(biāo)。

指標(biāo)在使用的過程中，不論是口頭交談還是系統(tǒng)展示，都會以上圖右邊的形式來體現(xiàn)，【視頻業(yè)務(wù)日銷售額】誰都可以讀懂。沒有哪個用戶去把指標(biāo)拆解成這些要素來溝通，除非出現(xiàn)數(shù)據(jù)問題。所以我們在報表、匯報、業(yè)務(wù)溝通的過程中，都是如【視頻業(yè)務(wù)日銷售額】的指標(biāo)形式體現(xiàn)出來的。

這樣對于管理有一個非常大的好處，可以基于指標(biāo)要素的組合進行最大可能的使用覆蓋。

根據(jù)業(yè)務(wù)的實際訴求，完成分析體系的建設(shè)：確定分析框架，確定分析類別，確定分析場景等等，例如用戶行為分析、業(yè)績分析、經(jīng)營分析、安全性分析、競對分析、財務(wù)分析..等多個場景?；谶@些分析框架，可以逐步的抽象出指標(biāo)要素，確定有多少個【原子指標(biāo)】+【維度】，然后就可以大致的得出，能夠覆蓋”多少個“指標(biāo)了。

這樣做的好處在于，業(yè)務(wù)用到的絕大多數(shù)指標(biāo)，都是可以覆蓋在指標(biāo)要素組成的這些結(jié)果之內(nèi)的，指標(biāo)管理者、開發(fā)者只需要關(guān)注指標(biāo)要素的增減即可，不用根據(jù)具體的需求 CASE BY CASE 的去完成任務(wù)，大大減少了管理和開發(fā)成本，從而實現(xiàn)了”收斂“ 。

及時性提升

如果已經(jīng)確定好指標(biāo)要素【原子指標(biāo)】+【維度】+【時間周期】+【條件限定】，這些指標(biāo)就可以提前進行計算：

把指標(biāo)要素組合的指標(biāo)，提前進行預(yù)算，因為是結(jié)果集，即便是組合再多，也能控制在百萬、千萬級別，或者是分塊、分組來存儲，這樣就有數(shù)據(jù)量級小的特性，我們可以把結(jié)果存入到響應(yīng)速度更快的內(nèi)存數(shù)據(jù)庫中，完成”空間換時間“，解決大多數(shù)人無法等待超長時間的計算過程。即便數(shù)據(jù)科技技術(shù)發(fā)展到今天，如 SPARK、clickhouse 等大規(guī)模秒級響應(yīng)的查詢技術(shù)已經(jīng)很成熟了，這種空間換時間的方式依然非常受用。從成本的角度來講，非常劃算。

命名的統(tǒng)一性

如果使用指標(biāo)要素的管理理念來生產(chǎn)、管理指標(biāo)，在用戶使用指標(biāo)的時候，可以做到指標(biāo)名稱的統(tǒng)一性。

回顧來看，所有應(yīng)用的指標(biāo)都可以認(rèn)為是派生指標(biāo)，派生指標(biāo)的指標(biāo)元素中，有哪些可以參與命名，哪些不用參與命名：

指標(biāo)的命名規(guī)范性，直接影響使用者對指標(biāo)的理解，并能夠影響到整個指標(biāo)使用的效果，如果命名不規(guī)范，會導(dǎo)致大家認(rèn)知出現(xiàn)偏差，經(jīng)常會出現(xiàn)不同名稱同一指標(biāo)，甚至還有同一指標(biāo)不同名稱的情況，增加大家的溝通對齊成本。

指標(biāo)命名的基本原則：簡短易懂，便于傳播，不易出現(xiàn)理解偏差。

1. 時間周期：必須參與命名，累計、昨日、月度、周；時間周期最直接的圈定了統(tǒng)計的范圍，需要明確的展示在指標(biāo)名稱上，簡單直接，避免不同人的理解歧義，減少錯誤發(fā)生的幾率。
2. 原子指標(biāo)：必須參與命名，指標(biāo)的核心。
3. 業(yè)務(wù)范圍：可參與命名，如果在系統(tǒng)、使用場景流程做的比較的情況下，可不用參與命名。例如，進入到”視頻業(yè)務(wù)“的專屬分析系統(tǒng)中，系統(tǒng)對業(yè)務(wù)有明確的劃分板塊，例如進入”電影“板塊，指標(biāo)名稱就無需帶上【電影】這個業(yè)務(wù)范圍了，比如昨日電影播放量就可以直接寫成播放量即可。
4. 條件限定：不參與命名。條件限定有量個非常重要的特性，就是很容易變長，二是它出現(xiàn)在指標(biāo)建立之后的靈活應(yīng)用上，是臨時性效果。例如【昨日播放量】這個條件是：大于 18 歲，中國地區(qū)，IOS 端，會員，近 30 天未登錄的，如果參與命名的話就是：【會員 IOS 端中國區(qū)大于 18 歲其近 30 天未登錄的昨日播放量】這樣讀起來就非常別扭。而且組合條件還需要考慮語言的通順性，例如這樣組合【大于 18 歲中國區(qū) IOS 端近 30 天未登錄會員昨日播放量】讀起來就會拗口。另外，很多條件限定都是臨時性提出的，例如年齡大于 18 歲，但是有可能隨時調(diào)整到 16 歲，如果按照人的年齡分布來講，我們可以從 1 歲到 100 歲這 100 個數(shù)字都當(dāng)做限定條件，這樣指標(biāo)就會無限增多膨脹，增大開發(fā)、管理、使用成本。
5. 維度：不參與指標(biāo)命名，維度與條件限定相同，它具有無限擴展的情況，并且無法從語言上讓指標(biāo)變得易于理解。例如【昨日播放量】支持維度：銷售渠道、城市、端、業(yè)務(wù)類型，加入維度后的命名是【昨日播放量銷售渠道城市端業(yè)務(wù)類型】這樣指標(biāo)就變的不可讀。實際情況是維度在分析過程中參與 GROUP BY 過程，例如表格中的分組，報表中的下鉆過程，實際上指標(biāo)命名帶上維度沒有意義，可以在應(yīng)用的過程中，告知用戶支持什么維度。

一致性與生態(tài)

運用指標(biāo)要素的指標(biāo)管理模型，本質(zhì)上是抽象+收斂的過程，確定少量的指標(biāo)要素，覆蓋大多數(shù)的使用指標(biāo)，減少開發(fā)、運維、管理和認(rèn)知成本。一致性問題同樣可以在這個模型中被解決。

業(yè)務(wù)基于這個模型思路，去構(gòu)建指標(biāo)模型，并用系統(tǒng)加以管理，當(dāng)做整個生態(tài)的底層基礎(chǔ)。

建立在這個模型之上，可以對接更上層的應(yīng)用系統(tǒng)，例如報表工具，業(yè)務(wù)分析系統(tǒng)，用戶管理系統(tǒng)，經(jīng)營分析系統(tǒng)等設(shè)計到指標(biāo)應(yīng)用的場景中，從而讓整個業(yè)務(wù)、數(shù)據(jù)分析系統(tǒng)生態(tài)中都利用起這個模型的思想。

五、總結(jié)

上面分享方案是理想的，真正能不能應(yīng)用起來，是另一回事?，F(xiàn)實是，一個小小的指標(biāo)，可能經(jīng)歷多個團隊，多年，多次治理，都達不到好的效果；對用戶來講，指標(biāo)體系建設(shè)以及使用需要一定的學(xué)習(xí)、理解成本。

數(shù)據(jù)指標(biāo)是一個需要認(rèn)準(zhǔn)解決方案（流程、標(biāo)準(zhǔn)、組織）長期持續(xù)做下去的事情，如果出現(xiàn)中斷或者反復(fù)，沉淀的經(jīng)驗不能繼承，則很難達到指標(biāo)準(zhǔn)確、及時好用的狀態(tài)。學(xué)習(xí)成本以及運營同樣是一個非常重要的因素。再簡單的指標(biāo)，也需要讀懂口徑、也需要明確指標(biāo)在哪里看到的最準(zhǔn)，數(shù)據(jù)出現(xiàn)了問題要找誰，需要一個完善指標(biāo)體系建設(shè)。

六、團隊介紹

淘天業(yè)務(wù)技術(shù)用戶運營平臺技術(shù)團隊是一支懂用戶，技術(shù)驅(qū)動的年輕隊伍，以用戶為中心，通過技術(shù)創(chuàng)新提升用戶全生命周期體驗，持續(xù)為用戶創(chuàng)造價值。
團隊立足體系化打造業(yè)界領(lǐng)先的用戶增長基礎(chǔ)設(shè)施，以媒體外投平臺、ABTest平臺、用戶運營平臺為代表的基礎(chǔ)設(shè)施賦能阿里集團用戶增長，日均處理數(shù)據(jù)量千億規(guī)模、調(diào)用QPS千萬級。

本文轉(zhuǎn)載自大淘寶技術(shù)，作者：博通

原文鏈接：??https://mp.weixin.qq.com/s/HLDS3FEHZwoMn--x8mSGCg??