導讀 ChatGPT4 橫空出世，其強大的語義泛化能力以及針對 Zero-Shot、Few-Shot 等場景的特性讓 AI 的使用門檻進一步降低，也為各行各業帶來了更多想象空間。本文将分享海南數造科技對 DataOps 加大模型驅動資料創新的思考與實踐。
主要内容包括以下五大部分：
1. 傳統資料管理面臨的挑戰
2. DataOps 與大模型的結合驅動資料工程創新
3. DataOps+大模型産品落地實踐
4. 未來展望
5. 問答環節
分享嘉賓｜楊明皓 海南數造科技有限公司 進階大資料技術專家
編輯整理｜彭爽
内容校對｜李瑤
出品社群｜DataFun
01
傳統資料管理面臨的挑戰
企業做數字化轉型會制定自己的數字戰略，在數字戰略與業務戰略對齊的過程中，企業也完成了資料從收集、管理到分析的流程，這個流程就是企業數字化轉型的展現。
企業數字化轉型呈現出三大戰略趨勢：
- 首先是資料分析民主化。資料分析不再隻是少數人的工作，各個崗位都會去看報表，也會用一些統計算法，以實時支撐業務決策。
- 第二是資料技術多元化。現在資訊系統多元化，資料開發同學面臨着各種多元異構的資料。在複雜的資料環境下，我們需要多元化的一些技術元件來支撐，比如 Flink、Spark 等計算元件和存儲元件。又比如在很多金融反欺詐場景中，會用到知識圖譜模組化和分析的資料元件。整體上變成了一個很龐大的、複雜的系統化工程。
- 第三是業務價值精益化。對于業務部門來說，也希望資料能實作快速變現。
在上述趨勢下，我們面臨着供需不平衡的痛點。現在市場變化很快，業務同學需要快速響應市場變化，是以經常會有大量的、臨時的，且有高時效性要求的資料需求。開發在早期會面臨開發環境與測試環境不一緻，部署和內建需要大量人工介入，系統之間存在資料孤島問題。導緻調研資料口徑要耗費大量時間，資料開發從傳遞到上線往往超過一周，甚至更長時間。同時也存在資料語義缺失、業務用數困難等其它一些問題。
資料開發工作也像軟體工程一樣，不應該是瀑布式的流程，即所有事情都要先計劃好、設計好才去開發，而是要實作靈活傳遞，能夠實時地響應需求。目前研發進度是落後于市場需求的。
02
DataOps 與大模型的結合驅動資料工程創新
在數字化轉型的趨勢下，也是在上述痛點的驅動下，企業亟需新的資料研發範式，需要滿足以下要求：
- 形成靈活資料研發流水線；
- 建構高效的跨域協同機制；
- 打造自助的用數體驗；
- 建立精細化的營運體系。
這樣才能實作快速傳遞資料的目的。
在這樣的背景下，我們提出了 DataOps 的理念。DataOps 是在 DevOps 的基礎上發展而來的，其本質是資料工作流的編排、資料的開發、測試、部署上線、回歸這套機制需要達到持續內建的效果，有标準化的體系，實作自動化部署，同時優化整個資料釋出的流程，優化資源達到靈活開發傳遞的效果。
從 2018 年開始，DataOps 的理念度被 Gartner 列入了技術成熟度曲線，并有着逐年上升的趨勢。數造科技在 2022 年與信通院聯合成立了一個專家工作小組，制定了 DataOps 的能力标準。
介紹了 DataOps 的背景後，讓我們再回到 AI。從 AlphaGo 為代表的深度學習技術的發展，到去年 ChatGPT 大語言模型技術的出現，AI 使用門檻越來越低，我們的資訊化系統越來越智能化。
僅僅一年時間裡，出現了很多基于大語言模型的 AI 工具。我們團隊使用了一款名為 Bito 的代碼自動生成和檢查的開源插件，使得工作效率提升了 20% 以上。
上圖展示了我們 DataOps 的标準化流程，在資料的開發、釋出的過程中，使用大模型支援代碼生成、代碼解釋以及代碼審查的工作，讓整個流程更加智能化。
上圖中對比了傳統資料開發模式和“DataOps+大模型”模式。傳統資料開發模式，從資料模組化、資料開發到測試、部署、回歸，步驟繁雜，需要大量的人力介入。在最早的時候，我們有開發環境、測試環境和準生産環境，不同的環境中會有不同的開發人員維系其參數配置檔案。當部署的時候，就要手動改配置檔案，往往會引入潛在的風險。
有了 DataOps 這一套靈活資料開發釋出的标準後，就能達到自動化的效果。這些配置檔案會被統一、自動化地管理起來，達到一套資料開發，一套資料模組化的腳本，能在多套環境裡面去使用，配置參數會自動替換。同時還具備資料沙箱的功能，測試資料可能無法展現生産環境的情況，是以可以使用準生産環境的資料去驗證腳本。在這種自動化的體系下，加入了一些大模型的能力，可以幫助我們生成一些資料指令，比如自動生成 SQL 或者加入注釋，以及自動審查等等。是以“DataOps+大模型”就是在 DataOps 這套标準化流程的體系上，加入自動化和智能化，讓資料的開發和傳遞更加高效。
03
DataOps+大模型産品實踐探索
大模型有很多有趣的應用場景，例如文案生成、數字人、知識檢索增強等等。還有一個比較熱門的場景就是 Text2SQL，讓大模型去生成指令，接下來将介紹我們在這一方向上的探索與實踐。
Text2SQL 就是基于以自然語言描述的問題，結合表的中繼資料資訊（包括表名、列名以及表之間的關聯關系），生成一個準确的 SQL 語句。2022 年，在大模型出現之前，Text2SQL 基于預訓練模型的準确率能夠做到 75-77% 左右。這一資料來自 Spider 的評測榜單，這是一個跨域的，在 Text2SQL 領域比較權威的榜單。大模型出現後，每兩個月榜單會更新一次，GPT4 做的 Text2SQL 任務，準确率也從原來的 78% 一路飙升到 91%。
而 Text2SQL 任務，産生正确的 SQL 隻實作了其一半的價值，對于資料開發人員來說，另一半的價值是快速找到想要的資料。現實的生産環境中有大量的資料庫、表，要基于自然語言的提問，找到準确的表和列，也就是準确資料口徑。是以我們認為 Text2SQL 的定義還要包括在不同 schema 下面能産生正确 SQL 的任務。
在大模型出現之前的做法，是用 Seq2Seq 的模型。對于提問，表的中繼資料資訊做嵌入，基于嵌入的向量資訊，生成 SQL 語句，這裡會有 mismatch problem in literature 的問題。我們做文本時，中文轉英文或者中文轉德文，詞語表述不一樣，文法結構不一樣，但可能語義是一樣的。而對于 Text2SQL 的任務來說，語義是不一樣的，問題用 SQL 是沒辦法準确表述的，比如 SQL 中的 group by、intersect、union 是不會在自然語言裡面出現的，你不會說：“幫我查這個季度的總銷售額，用 group by 這個語句”，是以就會存在語義不對等的問題。
基于這個問題，在模型架構上，比如 Encoder Decoder 上做了很多優化政策。在大模型出來之前，我們常用的就是谷歌 T5-3B、Electra 或者 RoBERTa 這些預訓練模型作為模型底座，不斷優化其 Encoder，一開始隻是簡單的 input representation，一個簡單的嵌入的任務，但是會發現有 schema-linking 不準确的問題。為了更好地将問題與需要用到的表或者列關聯起來，後面有了更複雜的 Structure Modeling 的模組化，會對問題模組化，對中繼資料采用更複雜模組化的政策，以找到問題相關的表和列。
近幾年比較流行的一種方法是基于知識圖譜的模組化方式，一開始大家會用 GNN 圖神經網絡的方法去做模組化，但存在一個問題，模型更多的是對節點的模組化，沒辦法泛化到兩度以上深度的資訊。是以後面又提出了 RAT-SQL、RASAT 模型，本質是在知識圖譜上去定義 meta-path，把中繼資料的關聯關系定義出來，在 Encoder 會去做多頭注意力，把關系的向量資訊嵌入到裡面，加強問題跟本地中繼資料的關聯性。
Encoder 的優化政策解決完，就到 Decoder，怎麼把 encoder 的編碼生成 SQL 語句，開始大家會用 Sketch-based 的方法，把生成 SQL 語句拆解成一個個的子部分，生成 select，生成 where，生成 from，基于小的語句去做詞槽，把之前 encoder 識别到的表名、列名填到這個詞槽裡，但實際上效果并不好，會産生很多錯誤的、不符合文法的 SQL 語句，是以我們用 Generation-based method 的方法，最經典的就是 AST 文法樹的結構，讓它遵循一定的文法樹來生成 SQL，還有 PICARD，在 search 的時候不斷地去一個記憶空間檢查生成的 SQL 跟前面的 Encoder 的 schema-linking 内容是不是對等的、是不是合文法的，包括 RESDSQL，這樣的優化政策，讓它生成更加準确的 SQL。
但是仍然不夠準确，經過分析，還是存在語義不比對的問題，于是我們又加入了 Intermediate representation 的架構，發明了基于自然語言跟 SQL 之間的中間語言，NatureSQL、SemQL，先生成中間語言，再基于中間語言生成 SQL，準确率又進一步得到了提升。
大模型出現後，其生成 SQL 的準确度，尤其是 GPT4 基于政策的生成，準确度越來越高。大模型目前主要使用有兩種方法，一種是提示工程，一個是基于指令的監督微調，讓大模型産生對應的 SQL。
今年這篇論文來自 SQL，也是大模型生成 SQL 任務的常用方法，即基于思維鍊的方法。在傳統 Seq2Seq 的方法中，輸入自然語言和 schema 資訊，讓它去生成 SQL，結果發現這種端到端的方法效果很差，是以才有了 Encoder Decoder 的優化政策。大模型其實也一樣，一開始通過 prompt 把自然語言、schema 喂給它，讓它生成 SQL，發現準确率有問題，是以後面把大模型的任務拆解成一個個子任務，比如先用一個 schema-linking 的 prompt 的模闆，找關聯的表、列，再基于表、列，根據問題的複雜性來進行分類，是簡單的一個單表查詢的 SQL，還是有一些 join 語句的 SQL，還是在 join 的基礎上有一些複雜子查詢的 SQL。為什麼這樣分類呢？因為對于很簡單的單表查詢的 SQL，如果用複雜的 prompt 模闆去生成，效果反而會下降，是以加了一個分類的 prompt。在這篇論文裡，還加了 self-correction 的 prompt 的模闆，告訴大模型再幫我優化一下 SQL。基于這一系列子任務，還有思維鍊的工程，最終才能讓 GPT4 生成比較準确的 SQL 語句。
實踐過程中發現，無論是傳統的預訓練模型還是大模型，都面臨着很多挑戰。傳統預訓練模型的語義泛化能力肯定比大模型弱，它的生成能力也不一定比大模型強，容易出現 missmatch 的問題，複雜查詢語句的生成能力也比較弱，加上 Encoder、Decoder 采用了大量複雜的優化政策，尤其是基于 graph based 方法，還要人工先生成 meta-path，維護這些 meta-path 也需要大量的工作，相比于大模型的 zero-shot、few-shot 能力，還要準備一些标注語料，工作量也是很大的。比如 T53B 模型用的顯示卡資源并不比大模型少。
大模型也同樣面臨一些挑戰，最近發表的所有的 Text2SQL 論文全部集中在 GPT4 的研究，對于本地化、私有化的大模型研究偏少。Prompt 的良好實踐，比較依賴于思維鍊，還有 in-context learning，也就是要給大模型一些樣例資料去引導它生成更加準确的 SQL，但對于複雜的 schema，就會超出大模型的 token。是以有一種做法是先把表預處理成寬表，生成的 SQL 就沒那麼複雜了，就變成了基于寬表去生成查詢語句，不用做 join 操作。但生成寬表的時候，面臨着 schema 非常大的問題，很容易超出它的 token。基于私有化大模型的微調也是非常少的。
我們認為傳統預訓練模型和大模型都面臨着一個共同的挑戰，使用者在實際使用過程中其實不知道資料是在哪一個資料庫中，怎麼去從大量的庫、表、幾千行的 schema 中找到問題對應的列和表，高效的完成 schema-linking 是非常困難的。現在很多 Text2SQL 的評測任務是已經假定了要用哪個庫，這個庫中的表和列往往是非常少的，是以沒有遇到複雜的 schema 中找數的問題。
我們提出了一些實踐和方法，先建構一個中繼資料的語義圖譜，語義就是問題加上表名加列名，這就是生成 SQL 需要用到的所有語義。當我們去生成一個語義圖譜的時候，有更多的 label 資訊，還有名額的描述，能補充到這個語義裡，讓 prompt 生成的準确率更高。生成語義圖譜，需要一套完備的資料治理工具。我們在資料模組化的時候，有一套自動化的資料标準工具，把這套資料标準落到資料模型中，稱為模型落标的過程。基于資料标準完成資料模型的時候，會把邏輯層、概念層的中繼資料，還有管理中繼資料共同落到中繼資料目錄上，再基于中繼資料目錄最終生成語義圖譜，這個是生成中繼資料血緣的過程。
另外有些客戶在搭建數倉的過程中，會抄一些事實表、次元表，這種數倉模組化的形式，整個數倉模組化直接做成從邏輯層開始模組化，但是當模組化完成後，資料開發人員不知道這個表對應到什麼業務口徑，而業務口徑也不知道這個業務名額需要用到哪些表，有哪些工作流，這也導緻了語義不對等的問題。更多業務口徑的語義在哪裡？其實是在概念層上面，現在大家做概念層的語義其實全部是用知識圖譜去做的，是以這個血緣圖譜在 Text2SQL 的任務上是非常重要的。很多論文中的資料預處理的工作是在做語義轉換，比如表名叫 department，其實就用 DEPT 簡稱來縮寫，DEPT 是一個沒有任何意義的列名，SQL 模型怎麼能識别得到呢？是以需要一些資料治理的前期準備工作。
現在業界都是基于 GPT4 去做 Text2SQL 任務，我們與一些國産大模型開展生态合作，接入了它們的一些接口去做測試。現在所有測試是基于特定場景、特定資料、特定私有化的大模型去做的，僅供參考，不一定是具有很高的代表性。我們發現私有化大模型的指令微調在 Text2SQL 任務上的效果是有限的，這個問題相信很快會得到解決。另外基于 schema-linking 所選取出來的中繼資料資訊，再去生成 prompt，在私有化的大模型上，Text2SQL 任務有 5% 到 10% 的提升。先用一個 schema-linking 的模型，先找出和問題相關的表名、列名，再基于表名、列名去做prompt 模闆，模型的準确率會有提升，而不是直接把所有中繼資料資訊喂給大模型。基于預訓練模型 schema-linking 的效果是好于大模型的。In-context learning 對私有化大模型的提升效果是最明顯的，大概有 10% 的提升。我們之前 Text2SQL 經常用的 Intermediate Representation 的方法，生成自然語言和 SQL 語句的一種中間語言政策在部分大模型上沒有化學反應，甚至效果更差。Self-correction 對私有化大模型有小幅提升。相比于私有化大模型，目前 GPT4 的效果還是遙遙領先的。
這就是我們提出的方法，schema-linking 是基于預訓練模型去找到問題相關的表和列名，再基于 prompt 去做大模型，現在很多評測，尤其榜單的評測資料，用到的表名和列名非常少，是以在做 schema-linking 的時候，也加大了難度，給它更多不同的資料庫、不同的表、不同的列名，其 AUC 并沒有明顯的下降。
這是我們基于人大今年發表的一篇 RESDSQL 的論文所做的 schema-linking。其底層是 RoBERTa，基于 RoBERTa 做 Pooling Module，把切的詞對應到完整的表名或者列名上，在做多頭注意力的時候，對列名做多頭注意力，把一些列的資訊嵌入到表名上來提升它對問題相關的表名、列名做排序。我們是基于這個模型做的 schema-linking。
我們也參考了阿裡發表的 Dail SQL 這篇論文，其中提出了 prompt 模闆的一個标準方法，基于 prompt 模闆，再加上 GPT4，準确率能達到 85-86%。一開始用了 Code Representation 來表示 schema，然後用了 Intermediate Representation，同時最重要的是加入了 in-context learning。這篇論文中，同時使用了相似的問題和相似的 SQL 去組成 prompt 模闆中的示例，提示大模型去生成正确的 SQL。其實這裡缺失了 schema 結構的相似性，很多時候sql語句的結構不光取決于問題，還取決于對應的資料庫 schema 結構，如何在相似問題和相似 SQL 的基礎上引入相似 schema 的判斷，我們認為是大模型生成SQL下一個可以探索的方向。
上圖中列出了一些 Prompt 的成功實踐。比如分割符的應用和結構設計，可以讓大模型知道哪一個部分是在提問，哪一個部分是在講 schema，哪一部分是講 in-context learning。另外我們會加入一些輸出字首，能讓大模型在生成答案的時候更加穩定。這就涉及到大模型的魯棒性，以及指定遵從性的問題，因為測試的過程中，我們會用大模型去嘗試做 schema-linking，讓它按 JSON 格式輸出問題相關的列名和表名，可能 10 次中會有 1 次報錯，比如 JSON 裡有個反括号漏掉了，是以魯棒性還是有一定問題的。
接下來介紹數造科技的産品是如何實作 DataOps 與大模型融合的。
上圖是數造科技的産品體系架構。對 DataOps 的整個過程，包括資料內建、開發，提供了标準化的流程和方法，同時基于資料湖倉适配了不同的私有化大模型，基于私有化大模型去完成代碼生成、代碼解釋的工作，幫助 DataOps 提效。同時有統一進制資料的服務，對于 Text2SQL 任務來說，語義就在表名、列名和問題上，是以要提供更多的語義資訊，建構中繼資料血緣圖譜。
開發治理一體化的資料管道包括管理域、開發域、治理域。其中，治理域包括一套自動化的資料标準和工具，幫助我們在資料模組化的時候落地資料标準，不允許生成毫無意義的表名、列名，這些會嚴重影響 Text2SQL 任務效果。開發域會基于大模型做代碼生成、代碼解析，還有注釋标注的工作。
最後，産品會有持續內建與釋出的能力，包括一套代碼在多套環境運作的這種多環境建立和管理的能力。
上圖展示了我們産品的部分功能界面。有些企業采用 Altas 等開源的圖資料血緣工具，它有一個最大的問題是一張表可能有幾十個列，一展開就是爆炸式的、很多的點，讀起來非常困難。是以我們在資料血緣方面做了很多優化的工作，不光是把底層中繼資料的資料血緣管理起來，也做了一些可視化的優化，讓資料開發人員能真正的基于可視化的界面去探查整個資料血緣。
上圖展示的是資料自動落标、工作流編排等功能。
這是我們做的初版 Text2SQL 的智能小助手，基于輸入的問題可以找出相關的中繼資料資訊，如果不準，還能根據之前的資料治理标準，手動修正相關的主題域，再去喂給大模型生成 SQL。
生成的 SQL 不單單隻是看，有一個比較友善的富文本編輯器，直接在編輯器上標明 SQL 運作，可以檢視報表。
最後是持續內建和持續釋出的功能。
04
未來展望
最後分享一些對未來的展望。
我們建構中繼資料的語義圖譜，尤其是名額層，包含了更多的業務語義、業務口徑等。如何把每個資料标準自動化工具嵌入到模型中，這是我們未來要做的工作，基于更多的語義，看模型的提升效果怎麼樣，現在需要一些人工去給 Spider 資料去做語義的補充。
知識圖譜有很多子圖檢索增強問答的方法，我們也在思考，把語義元素去圖譜後，能不能借鑒知識圖譜基于子圖檢索增強的方法去嵌入子圖的資訊，基于子圖去提升 schema-linking 的效果，這也是我們未來想要探索的方向。
另外我們看到大模型，把整個 SQL 任務拆成不同的子任務，基于這些子任務的 Prompt 模闆，引導模型生成正确的 SQL，那麼能否基于大模型去做一個 agent，用不同的子模型去完成各個階段的 SQL 生成任務，這也是我們目前的一種設想。
近幾個月來我們看到了很多 long-context 大模型的出現，現在的大模型可能就是 2k、4k，有一些長文本的大模型已經輸入到了 200k。現在 Text2SQL 最大的問題就是怎麼把大量的生産環境的中繼資料喂給模型，是以我們也在想 long-context 的大模型能不能直接把所有的中繼資料喂給它，不需要再做中繼資料分片的工作，讓它去生成 SQL。當然，關于 long-context 大模型的效果，大家也還在觀望中，這種大模型的注意力在于頭尾，中間的資訊可能會缺失，是以這也是我們關注的一個點。
數造科技專注于資料治理、DataOps、資料開發，是新一代靈活資料管理平台的供應商，具有大資料賦能能力。
我們的産品是一站式的資料開發管控平台，包括資料治理、血緣圖譜的建構，還有自動化标準資料治理的工具，以及行業大資料解決方案。
以上就是本次分享的内容，謝謝大家。
05
問答環節
Q1：我們現在的實作方案，首先在找數、找表是單獨請求了一些模型，可能在找表的時候有一些表的字段翻譯，通過翻譯之後，确定哪些表可用，然後再去生成 SQL，因為這個環節有一個召回的過程，前幾位的表并不是我們想要的表，這方面該如何實作？
A1：如果是表名的翻譯召回，還是得看模型底座的能力。
Q2：在測評模型的時候，對 SQL 複雜度的評級，按照 group by 或者列的數量，對 SQL 複雜度做評級，我們現在測出來複雜度較低的，比如說單表、沒有 join 的這種成功率比較高，但是複雜度一旦提高，SQL 就可能有一部分沒法執行，也有些 SQL 執行出來的數不是我們想看的數。想請教一下，如何解決這類問題？
A2：我們也遇到同樣的問題，比如帶 wikisql 這種單表的查詢，效果是确實不錯。但是對于有 join，又有子查詢嵌套的 SQL，效果也是不太理想，哪怕基于大模型做了一些監督微調，尤其是我們基于 spider 資料去測，很多問題也遇到過。
Q3：您剛剛有提到關于 Text2SQL，有落地到業務方開始用了嗎？
A3：業務方還在嘗試中，因為準确率有一定限制。
Q4：我們在實際落地的時候遇到了一個問題，因為其背後是個機率模型，是以它每一次的召回可能是不一樣的。第二個就是 meta-data 可能品質很差，需要大量資料治理，比如我們面對的是分析師或者開發工程師，他就覺得我如果要用上 CHAT 的能力，代價非常大，如何去平衡這個問題？如果他不來用，那模型就沒有辦法繼續調優，因為我們沒有真實的資料來訓練它，如果一直都是預訓練模型的話，其實在實際落地場景的時候就會存在問題。
A4：對，這個問題很經典。比如冷啟動的問題，預訓練的資料或評測的資料中沒有過多你自己掌握的語料或在裡面。另外很多語義資訊，包括表名、列名，需要做資料治理。對于我們本身就是做資料治理的廠商，我們認為不光是為了 Text2SQL，其實下遊的所有的業務系統、模型，如果不去做資料治理的話，一樣會産生非常多的問題。是以對于我們來說這個不是一個選擇題，資料治理這件事是必須要做的。
但是這就會面臨一個問題，不能快速變現，業務方希望從幫我更好地管理資産到更快地發現生産價值，周期會非常長。我們目前也沒有很好的答案。
Q5：中繼資料資訊是通過什麼方式喂給大模型的？
A5：我們輸入給大模型，其實還是自然語言的表述，我們的 Prompt 就是一個自然語言的表述，并不是一個向量化的方法，模型内部會有 embedding 層，去做向量化的事情。
Q6：喂給大模型是以一種什麼樣的形式，包含哪些内容？
A6：中繼資料 Prompt 模闆是看不同的政策，有一些會把它全部拼裝成一個序列，表名：列名，列可能有個括号代表它是主鍵、外鍵。也有些就把一個 DDL 的語句直接放到 Prompt 上面，這也是一種方法。如果 schema 用 DDL 語句的形式，可能它對大模型的效果會更好一些。
Q7：關于寫 SQL 過程 Prompt 的設定，這個設定是有在智能助理裡面有做一些提前的設定，還是這些設定都得讓使用者來寫？比如一個場景中，我們有一些枚舉的字段，性别這個字段在資料表裡面存的是 0 和 1，業務的問題是請統計這個表裡面所有男性玩遊戲的時間，那麼怎樣讓 GPT 了解到性别的那個字段 0 表示的就是男性，同時在 SQL 裡面顯示出來。
A7：我們的智能小助手背後已經有一套标準化的模闆，基于接入的不同的模型，比如 GPT4 或者私有化部署的大模型，我們會定義一個預設模闆，後面我們會考慮可能使用者希望自己去探索他的 Prompt 的模闆，我們可能會開放 Prompt 編輯的功能，目前是系統内置好的。
如果它是一些枚舉值，在你的問題中，你告訴大模型，要找出性别等于男的，可能大模型不一定能 get 到這個資訊，有可能會報錯。
Q8：你剛剛是說背景有一個 Prompt 模闆，相當于使用者在登入在對話框裡去輸入一個問題，其實是會和那個模闆結合起來，一起給 GPT 來回答，然後生成 SQL 的？
A8：是的，沒錯。
以上就是本次分享的内容，謝謝大家。