本文根據神策數據智能業務負責人郭榮鋒《AIGC 驅動高績效商業的實踐》的主題演講整理所得，主要圍繞神策對 AIGC （即 AI-Generated Content，人工智能生成內容）業務應用的理解、AIGC 的落地實踐及心得體會等方面展開。

以下為本文的要點：

· 懂業務并且能夠與 AI 進行對話的人，將成為公司的超級個體，發揮更大的價值

(相關資料圖)

· 神策數據通過構建數據分析 copilot 和用戶運營 copilot，為公司的關鍵角色提供支持，使其成為超級個體

· 提升 AIGC 應用效果的關鍵點是企業數據，AIGC 時代下，企業數據愈發重要

一、對 AIGC 業務應用的理解

關于 AIGC 的范式，我們認為一方面是LUI （即 Language User Interface，自然語言用戶界面），另一方面是專家模型。比如畫畫，我們想畫一幅“美麗的清晨”，LUI 理解需求「美麗的清晨」，畫畫模型把圖畫出來；比如讓 AI 模仿孫燕姿的嗓音演唱 XX 歌曲，LUI 理解需求「演唱 XX 歌曲」，唱歌模型完成演唱。現在的大模型能比較好地理解自然語言，LUI 相對比較成熟；但目前并不是所有行業或場景都有對應的 AI 專家模型，也有一些通過傳統方法來實現。隨著 AIGC 能力的發展，各種 AI 專家模型會越來越成熟。引用陸奇博士的話，現在正處于「模型」無處不在的新范式拐點上，接下來的時代就是模型的世界。

從企業經營的角度看， LUI + 專家模型將帶來什么樣的影響？確實，它可以提升員工在特定場景下的工作效率，比如自動寫會議紀要等；但從其他的視角看，有沒有可能有更大的價值？

我先分享一個故事。我有個出版行業的朋友，主要給書做插畫，她是自己這個小公司的 CEO，沒有經過一天畫畫訓練的她，應用 AIGC 以后成為公司里最有創造力、最有生產力的人。我問她為什么，她說：畫畫分成兩個環節，第一個環節是設計，即要畫成什么樣，第二步是畫出來，利用訓練有素的肌肉記憶把想要的畫畫出來。她雖然不懂畫畫技巧，但多年的行業經驗讓她很懂客戶需求和插畫設計，又因為她擁有豐富的繪畫知識，因此她能清晰地把設計需求表達出來給 AI，然后由 AI 完成具體創作。既懂業務又具備和 AI 對話的能力，讓她變成了最厲害的生產力和最棒的創作人員。

在這個故事里，LUI + 專家模型代替了只能提供基礎技能價值的畫師，懂業務 & 懂得和 AI 對話的業務負責人或者資深畫師和 AI 互通，直接開展業務，發揮了更大價值，成為公司內的超級個體，公司業務的效率和質量自然也有了提升。因此，從企業經營角度看，可以通過構建 LUI + 專家模型來服務公司內關鍵角色，打造企業內超級個體，提升業務經營效率和質量。

二、AIGC 的落地實踐

關于 AIGC 業務的落地，一方面是在普通場景下如何提升工作人效？另一方面是如何賦能公司中有業務能力的人，發揮其價值，讓他們成為公司的超級個體，驅動業務發展。

在感知、決策、行動、反饋構成的業務閉環中，業務負責人員作為關鍵角色比較關注和能發揮價值的是感知和決策，我們將這兩個環節設為 AIGC 應用的重點，以幫助他們發揮價值，成就超級個體。

當前企業的工作流程大多是由分析師產出數據報表和報告，業務負責人看到數據報表，針對異常數據表現，數據分析師再進行分析和匯報，業務人員難以直接接觸數據，從而限制了他們對業務全局的洞察力。此外，洞察數據后進行用戶運營決策時，如何更好地理解過往策略，并基于當下目標制定新的運營策略，也有較高的門檻。針對這些情況，我們可以通過 AIGC 去賦能業務負責人。

在感知環節，重點是數據分析模型與 AI 深度融合，構建數據分析專家模型，支持對話式指標查詢，在一問一答中快速查看想要的數據，幫助超級個體便捷獲取數據，理解業務現狀（what）；支持對話式數據分析，專家模型對指標及形成進行解讀，幫助進行業務歸因（why）。在決策環節，重點是營銷模型和 AI 融合，構建營銷專家模型，支持會話式受眾圈選和營銷策略生成。

我們構建了一個智能助手，目前是 Demo 階段，從數據分析場景開始，現在是瀏覽器插件的形式。以事件分析場景為例，在輸入框中用自然語言輸入要獲取的數據指標，比如最近 7 天搜索點擊的用戶數，GPT 模型將自然語言轉化為請求查詢 JSON 并發起查詢，并進行圖形化展示。我們為什么采用 text2json 而不是 text2sql？因為這樣有兩個好處，一方面更容易理解，便于業務人員判斷查詢；另一方面更容易進行人為干預，比如生成的查詢 JSON 不對，或者想換種計算方式或者查詢條件看看指標怎么樣，都可以快速調整。

這個要怎么實現？首先要讓 GPT 理解我們數據的 schema 以及任務，所以我們要做的事情是把我們 schema 傳給 GPT，但因為存在長度限制，我們要解決的第一個問題就是如何讓 prompt 更短，我們先從報表的上千個字段中篩選出進入到 prompt 的字段。其次，篩選出來的 schema 會有很多的字段，字段多了也會影響 GPT 的正確率和精準度，因此需要跟 GPT 進行交互，讓它挑選出哪些字段與產品有關。最后再通過 GPT 進行 JSON 的生成，而對于復雜的查詢，可以先讓它生成一個結構，在這個結構下把內容填充進去。因此，這個查詢的過程相對比較復雜。

此外，還可以輔助進行 SQL 的編寫，有些分析用 JSON 查詢不好做，就用 SQL 來做自定義查詢。在輸入框中用自然語言寫入想要的查詢，GPT 模型將自然語言轉化為 SQL，并發起查詢。如果 SQL 不對的話，還可以做修改，或是通過多輪對話的方式對其進行優化。

在分析模型外，我們還做了幫助問答助手，幫助業務人員更快速學會用產品。用戶可以用自然語言問一些產品問題，GPT 基于我們的產品幫助手冊來回答問題。比如輸入 Session 分析可以做什么，上面就列出了回答，并引用了我們產品幫助文檔的參考。GPT 做查詢并基于查詢做摘要生成，摘要效果和相關性比傳統的搜索效果要好。比如：查詢「概覽和書簽有什么關系」，在這個場景中，GPT 摘要詳細對比描述了概覽和書簽的定義以及關系，而普通的搜索沒有這樣的能力。

三、關于 AIGC 實踐的認知總結

上面介紹了我們圍繞 AIGC 開展的一些應用，接下來探討一下我們遇到的問題和實踐過程中得到的認知。

首先來談談模型精準性。相比于摘要生成模型、圖片生成模型，數據分析模型非常要求精準性。摘要生成的好壞、圖片生成的好壞可以直觀判斷，而數據指標的對錯難以直觀判斷，因此對精準性要求很高。而影響模型精準性的因素有哪些呢？

第一，模型的應用方式，我們要知道 prompt 怎么寫影響性能和效果，比如要不要 step by step，要不要自我校準，JSON 生成要不要先生成結構等。

第二，模型的推理能力。最常見的有最近 7 天、同比、環比以及一些聚合統計的邏輯不對，比如「在過去 7 天做過成功拍照事件行為且次數超過 10 次的用戶數」這一類的查詢。

第三，prompt 長度約束問題。我們的事件、屬性等組合起來可能有大幾百，甚至上千個字段，不能將所有的表信息塞到 prompt 中，要先進行一次事件和屬性的選擇。

第四，字段理解問題。要讓 GPT 理解事件和屬性，就要給模型足夠的信息，比如事件 show_take_photo_guide_popup，我們要讓模型知道這是「首次拍照后彈窗引導」。

第五，業務理解問題。業務理解有兩類，一類是業務指標的理解，比如轉化率，不同公司的轉化率定義（分子、分母）不一樣，需要讓模型知道業務指標的含義；另一方面是具體字段和屬性的選擇，有些元數據的描述很相近，比如統計照片上傳成功數量，需要確定用「照片上傳成功」事件還是用「服務端照片上傳成功」事件。

如何解決以上問題？一方面我們需要等大模型能力的提升，或是自己去做某個領域的模型。另一方面關于字段理解和業務理解，如何積累數據變得很關鍵。在 LUI 的情況下，數據完備性非常重要。除了更多的數據積累，還需要知識，比如語義相近的兩個字段到底選哪一個？這不是數據，而是需要知識才能解決的問題，因此要構建企業的元數據知識圖譜。比如企業中已有的 1000 張報表，到底哪些字段和屬性已經用過，這些字段、屬性、指標之間構成了什么關系？這些可以構建出來，并用來做事件和屬性的選擇推理。

我們再來看看產品的設計與評估。LUI 之后，產品的設計將從場景和功能驅動，變成用戶問題驅動。這隨之帶來兩方面的影響，一方面是用戶引導的方式發生改變，需要引導用戶變得會問問題、正確地問問題，用戶引導貫穿提問前、提問中、提問后；另一方面產品的評估方式發生變化，由「有沒有某個功能」變成「能否正確回答某些問題」。這些問題的解決一方面要提高對用戶的引導能力，另一方面需要建設行業問題以及相關問題的知識庫。

基于前面的討論，我們總結了 AIGC 應用方法。企業在進行決策時，是由技術可行性和業務需求雙向決定的。從業務上來說，不能因為要做 AIGC 而做 AIGC，一定要有業務上的抓手，需從場景和業務應用出發。從技術上來說，數據是重要的，它可以提升大模型在特定場景下的精準性。總結起來就是：應用場景是抓手，數據是核心，大模型是支撐。