作者：ivring

大規模語言模型 (LLM) 擁有大量的資料來源，能針對使用者提出的問題提供不同形式的回答，但其回答形式僅限于“文本”。盡管文本内容清晰，但在包含複雜邏輯或需要向外展示的場景下，文本表達存在局限性。可以想象，将“文本” 轉換為“可視化” 分析模型甚至UI界面将具有更出色的效果。本文将彙總關于這種場景的探索和實作思路。

效果展示

AI 可視化分析模型是結合了 LLM 的能力，依據使用者的需求生成互動式、直覺且适用于互動設計師、視覺設計師和産品設計師的常用模型，如使用者旅程地圖、使用者畫像等。同時，也滿足産品經理所需的商業畫布、SWOT 分析等常用分析模型。效果如下:

功能分析與拆解

實作思路

站在使用者的角度來看這個需求由以下幾個階段組成：

從上面的流程可以看出，整個過程需要與 LLM 産生兩次對話：

第一次調用進行模版篩選，對于 LLM 來說是非常簡單的，隻需要寫好簡單的 Prompt 即可。
第二次調用為生産模版資料，也就是最關鍵的一步。那這個模版資料怎麼生産呢？

理想的AI

理想中的 AI 當然是編寫提示詞通過 LLM 直接輸出設計稿資料，再通過圖形資料解析器在圖形編輯器中建立出設計稿。按這個思路可以分以下幾步來做：

了解設計稿資料格式
讓 LLM 學習設計稿資料
針對每個模型編寫 Prompt 讓 LLM 生産出設計稿資料
通過圖形資料解析器解析設計稿資料插入圖形編輯器中

了解設計稿資料格式

標明 Figma 作為圖形編輯器。是以要了解 Figma 設計稿的資料結構。我們可以從在這個網站 Figma Api Live 中擷取到 Figma 設計稿的源資料。可以看到一個設計稿的資料是非常複雜的。包含：層級關系，坐标，矩陣，填充，文字，邊框等等。這樣一個簡單的畫闆設計稿資料足有 6.8k。由于 LLM 存在最大傳回 Token 限制。是以這個思路從第一步就證明是行不通的。

現實中的AI

上圖是使用者畫像模型的設計稿到最終産物的對比。可以看出，整個過程中設計稿的基礎輪廓并不會改變，隻有便簽的建立和特定區塊内文字的變化。再重新回過頭來看這個需求的本質，其實就是 LLM 輸出文本到設計稿中文本的替換。

最終思路

隻需要利用 LLM 輸出的結構化文本，再進行設計稿的文本替換。按照這個思路可以分以下幾步來做：

單個模型的設計稿資料
定義該模型的 LLM 文本輸出的資料結構
組合 LLM 文本資料結構和設計稿資料，生産出設計稿資料
編寫解析器解析設計稿資料插入圖形編輯器

提示詞開發

上文說到整個需求會存在跟 LLM 的兩次對話，跟 LLM 相關的對話 Prompt 調試是必不可少的一部分。在 AIGC 時代，成為 Prompt 工程師似乎是無法避免的宿命。

模型推薦

模型推薦這一塊相對來說比較簡單，Prompt 如下：

我想讓你做一個模版推薦，我會把你精通的模版都告訴你，請你根據我輸入的問題給我推薦适合的模版。你現在精通：使用者旅程地圖、使用者畫像、精益畫布、使用者故事、SWOT分析、幹系人地圖。推薦模闆要求：1.如果問題内含有模闆相關的詞彙，請優先推薦對應模闆。2.如果沒有适合的模闆，請回複：暫無适合的模闆。3.推薦模闆最多5個，最少1個，按推薦優先級排序。注意：隻要推薦模闆名稱，不要回答問題，也不要對模闆進行解釋。

隻需要對 LLM 輸出的文本用正則提取即可。

export const getRecommends = (txt) => {
  return txt.match(/(使用者旅程地圖|使用者畫像|精益畫布|使用者故事|SWOT分析|幹系人地圖)/g);
};

模型的結構化文本

以上是根據産品同學在進行需求調研時的提示語跟 LLM 産生的對話, 可以看到 LLM 可以生成結構化的資料，那如何去解析這些資料呢？

不如試試讓 LLM 直接輸出 JSON 資料吧

從上圖可以看出，隻要告訴 LLM 一個固定的 JSON 輸出格式。則在對話可以生成定義好的 JSON 資料格式，隻需要通過正則提取出該 JSON 即可。

export const parseGptJson = (txt) => {
  const data = txt.match(/'([^']*)'/g); // 提取json字元串片段
  const res = JSON.parse(txt);
}

但在開發過程中也發現了如下幾點問題：

雖然可以生成結構化資料，但整體生成的結果内容仍然有些“泛”，資料的品質不高，對使用者參考價值不大。
LLM 輸出的資料不夠穩定，通過正則提取加 JSON.parse 的方式錯誤率很高。
LLM 輸出完整資料的時間長，需要很長的等待時間，會造成使用者的等待焦慮。

提示詞增強

在探索過程中，對提示詞進行了多次調整，始終無法生成穩定，高品質的内容。以精益畫布的提示詞：

你現在是一個創業專家，能夠熟練的使用精益畫布，精益畫布分成：1.問題&使用者痛點。2.使用者細分。3.獨特賣點。4.解決方案。5.管道。6.關鍵名額。7.競争壁壘。8.成本結構。9.收入分析。現在有使用者向你詢問如何進行創業，你需要用精益畫布的方式分點（不少于4個點）給出解答，解答内容務必非常詳細。固定回答格式如下：xxx

為提高穩定性，做了以下措施：

加了各種定語如：盡可能詳細、每個點不少于 4 個等限制條件。
增加示例資料：從 LLM 的原理上來看，它的模式是通過推理來生成回答。那我們可以直接告訴它你理想的資料例子，提高其推理效率。

最終整個提示語的由以下幾部分組成：

設計稿拆解

設計稿最小母版

以使用者旅程地圖為例，對設計稿進行拆解，縮減内容則可以得出一個最小的設計稿母版。通過這個最小模闆再組合 LLM 輸出的資料可以輸出最終的設計稿。整個模型由以下幾大類組成：

列的頭部（固定内容）
旅程子產品：旅程一，旅程二，旅程三（表格）
名稱，使用者目标與期望

模型的預定義資料

結合上文，我們可以歸納出一個模型需要做以下的資料準備：

通過 Figma Api Live 可以拿到最小母版的設計稿資料
模型關聯的 schema.json 按每個模型的特點進行定制
模型提示詞由不同的模型特性決定
示例資料用于增強提示詞

設計稿資料組裝

輸出資料結構定義

通過歸納分析各個模型，可以總結出模型設計稿存在大量的共性，設計稿内可以分為以下三種子產品：

固定輸出子產品

如表頭，标題，分割線。用于定義使用者不會修改的子產品，這類子產品不需要做文本替換。

表格型子產品

如使用者旅程地圖中的每個階段，這種類表格需要通過以 schema.json 來做内容的資料描述。

"ths": ["階段一","階段二"],
"data": {
  "階段一": {
    "欄目一": ["内容", "内容"],
    "欄目二": ["内容", "内容"]
  },
  "階段二": {
    "欄目一": ["内容", "内容"],
    "欄目二": ["内容", "内容"]
  }
}

分塊型子產品

如 SWOTA 分析，該模型的每一個區塊都固定的，隻需要進行文本内容塊的處理即可。則其 schema.json 如下：

"data": {
  "優勢": ["xx","xx"],
  "劣勢": ["xx","xx"],
  "機會": ["xx","xx"],
  "威脅": ["xx","xx"],
  "通過優勢利用機會的政策": ["xx","xx"],
  "利用優勢防止威脅的政策": ["xx","xx"],
  "通過機會最小化弱點的政策": ["xx","xx"],
  "将其潛在威脅最小化的政策": ["xx","xx"]
}

設計稿資料生産

下一步就是針對各個模型進行設計稿的資料生産了，上圖可以是設計稿中的畫闆清單，會按這個畫闆結構與資料建立索引關系。

以使用者旅程地圖為例，其 schema.json 如下

"schema": {
    "user": {
      "使用者資訊": "x",
      "使用者目标與期望": "x"
    },
    "ths": ["旅程一"],
    "data": {
      "旅程一": {
        "使用者行為": ["1"],
        "服務觸點": ["1"],
        "使用者預期": ["1"],
        "情緒曲線": "中",
        "使用者痛點": ["1"],
        "機會點": ["1"]
      }
    }
  },

要根據 schema.json 生産出設計稿需要做以下幾件事情：

設計稿建立圖層名稱與 scheme.json 中 key 的索引關系
固定子產品直接從設計稿主機闆資料中輸出對應的資料即可
名稱和使用者目标與期望找到索引并替換文本
根據旅程建立出對應的旅程子產品。以母版中的旅程一為基準，拷貝後，進行位置偏移，并計算出最外層的寬度。
每一列根據傳回文本數量，如旅程一中的使用者行為裡有 4 個文本。則建立出四個便簽。并處理好每一個便簽的位置關系即可。

組裝器需要針對每一個模版編寫組裝邏輯。但邏輯大部分是通用的，如在後續增加模版，此處的開發成本很低。

Figma 資料解析

上圖是設計稿資料到 Figma 的解析流程圖，核心流程如下：

輸入設計稿資料
節點樹深度優先周遊
節點類型判斷并建立節點
節點屬性設定：位置，尺寸，填充，邊框等

Figma 提供的圖形建立能力可以 https://www.figma.com/plugin-docs/api/api-reference/文檔中了解。

解決使用者等待焦慮

跟傳統的 webAPI 不同，LLM 接口完整資料的響應時長根據資料量大小決定，本應用會輸出大量文本，模型需要 40-60 秒的時間完成所有資料響應，是以會造成使用者等待時間焦慮。

對話式互動

最初的設計是将文本展示給使用者，這種方式是目前主流的LLM對話式應用的互動形式。實作這種方式隻需要将LLM流式輸出的文本展示出來即可。然而，這種方式的缺點也非常明顯，畫布中并沒有實質性的圖形渲染，且使用者無法通過對話進行互動。是以，以文本作為主要的使用者互動方式體驗是不完整和不夠理想的，不是最佳的解決方案。

漸進式渲染

那能不能像打字機效果一樣，在流式資料傳輸過程中，一邊生成一遍是渲染内容呢？

難點在于在組裝模版和渲染過程中，我們是拿到标準化的資料結構再一次性插入畫布。而在流式資料傳輸過程中傳回的資料，隻是整個最終結構化資料的某一個片段。如下所示：

// 最終的json資料
const data = '你好，以下是頭腦風暴/n {"data":{"使用者擷取":["1","2","3","4","5"],"使用者活躍":["1","2","3","4","5"],"使用者留存":["1","2","3","4","5"],"獲得收益":["1","2","3","4","5"],"推薦傳播":["1","2","3","4","5"]}}'

// 流式傳輸過程中資料示例1
const process1 = '你好，以下是頭腦風暴/n {"data":{"使用者擷取":["1","2","3","4","5"],"使用者活躍":["1","2","3","4","5"],"使用者留存":["1","2","3","4","5"],"獲得收益":["1","2","3","4'

// 流式傳輸過程中資料示例2
const process2 = '你好，以下是頭腦風暴/n {"data":{"使用者擷取":["1","2","3","4","5"],"使用者活躍":["1","2","3","4","5"],"使用者留存":["1","2","3","4","5"],"獲得收益":[,'

如上面的資料示例所示，在流式傳輸過程中，需要把 process1 和 process 的資料轉為下面的标準化 JSON 資料:

// 過程中資料示例1
const process1Filling = '{"data":{"使用者擷取":["1","2","3","4","5"],"使用者活躍":["1","2","3","4","5"],"使用者留存":["1","2","3","4","5"],"獲得收益":["1","2","3","4"]}}'

const process2Filling = '{"data":{"使用者擷取":["1","2","3","4","5"],"使用者活躍":["1","2","3","4","5"],"使用者留存":["1","2","3","4","5"]}}'

前文提到了通過正則提取加 JSON.parse 的方式錯誤率很高。要實作上面的提取和補全，我們需要把 LLM 傳回的内容提取和補全成标準的 JSON 資料，實作 JSON 資料提取的可控。然後在流式輸出過程中寫一個定時器，每隔一段時間走設計稿組裝+渲染流程即可。

如下圖所示，将整個渲染過程簡化為五幀：

JSON 提取與補全算法

上圖展示了整個算法的運作流程，其核心是實作一個有限狀态自動機，通過逐個解析字元串并進行拼裝和補充進而生成标準化的 JSON 資料格式。

分析模型示例

總結

在本文中，我們詳細總結了實作 AI 可視化分析模型的過程中所需進行的功能拆解和實作思路。在此基礎上，還分享了在利用 LLM 生成結構化資料時所遇到的問題及其相應解決方案。我們相信這些經驗總結能夠為在此領域工作的同行提供有價值的幫助，幫助大家更好地了解和掌握這些技術。同時，這些經驗也能為後續的研究工作提供有益參考。我們希望這些總結能夠為讀者提供一個清晰詳盡的指導和實踐思路。

作者:ivring

來源:微信公衆号:騰訊技術工程

出處:https://mp.weixin.qq.com/s/HrxQtfc8j-zD9kMRGhTn6w

面向AI程式設計：探索可視化分析模型