大規(guī)模語言模型 (LLM) 擁有大量的數(shù)據(jù)來源，能針對用戶提出的問題提供不同形式的回答，但其回答形式僅限于“文本”。盡管文本內(nèi)容清晰，但在包含復(fù)雜邏輯或需要向外展示的場景下，文本表達(dá)存在局限性?？梢韵胂螅瑢ⅰ拔谋尽?轉(zhuǎn)換為“可視化” 分析模型甚至UI界面將具有更出色的效果。本文將匯總關(guān)于這種場景的探索和實現(xiàn)思路。

效果展示

AI 可視化分析模型是結(jié)合了 LLM 的能力，依據(jù)用戶的需求生成互動式、直觀且適用于交互設(shè)計師、視覺設(shè)計師和產(chǎn)品設(shè)計師的常用模型，如用戶旅程地圖、用戶畫像等。同時，也滿足產(chǎn)品經(jīng)理所需的商業(yè)畫布、SWOT 分析等常用分析模型。效果如下:

功能分析與拆解

實現(xiàn)思路

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

從上面的流程可以看出，整個過程需要與 LLM 產(chǎn)生兩次對話：

• 第一次調(diào)用進行模版篩選，對于 LLM 來說是非常簡單的，只需要寫好簡單的 Prompt 即可。

• 第二次調(diào)用為生產(chǎn)模版數(shù)據(jù)，也就是最關(guān)鍵的一步。那這個模版數(shù)據(jù)怎么生產(chǎn)呢？

理想的AI

理想中的 AI 當(dāng)然是編寫提示詞通過 LLM 直接輸出設(shè)計稿數(shù)據(jù)，再通過圖形數(shù)據(jù)解析器在圖形編輯器中創(chuàng)建出設(shè)計稿。按這個思路可以分以下幾步來做：

• 了解設(shè)計稿數(shù)據(jù)格式

• 讓 LLM 學(xué)習(xí)設(shè)計稿數(shù)據(jù)

• 針對每個模型編寫 Prompt 讓 LLM 生產(chǎn)出設(shè)計稿數(shù)據(jù)

• 通過圖形數(shù)據(jù)解析器解析設(shè)計稿數(shù)據(jù)插入圖形編輯器中

了解設(shè)計稿數(shù)據(jù)格式

選定 Figma 作為圖形編輯器。所以要了解 Figma 設(shè)計稿的數(shù)據(jù)結(jié)構(gòu)。我們可以從在這個網(wǎng)站?Figma Api Live?中獲取到 Figma 設(shè)計稿的源數(shù)據(jù)?？梢钥吹揭粋€設(shè)計稿的數(shù)據(jù)是非常復(fù)雜的。包含：層級關(guān)系，坐標(biāo)，矩陣，填充，文字，邊框等等。這樣一個簡單的畫板設(shè)計稿數(shù)據(jù)足有 6.8k。由于 LLM 存在最大返回 Token 限制。所以這個思路從第一步就證明是行不通的。

現(xiàn)實中的AI

上圖是用戶畫像模型的設(shè)計稿到最終產(chǎn)物的對比?？梢钥闯觯麄€過程中設(shè)計稿的基礎(chǔ)輪廓并不會改變，只有便簽的創(chuàng)建和特定區(qū)塊內(nèi)文字的變化。再重新回過頭來看這個需求的本質(zhì)，其實就是 LLM 輸出文本到設(shè)計稿中文本的替換。

最終思路

只需要利用 LLM 輸出的結(jié)構(gòu)化文本，再進行設(shè)計稿的文本替換。按照這個思路可以分以下幾步來做：

• 單個模型的設(shè)計稿數(shù)據(jù)

• 定義該模型的 LLM 文本輸出的數(shù)據(jù)結(jié)構(gòu)

• 組合 LLM 文本數(shù)據(jù)結(jié)構(gòu)和設(shè)計稿數(shù)據(jù)，生產(chǎn)出設(shè)計稿數(shù)據(jù)

• 編寫解析器解析設(shè)計稿數(shù)據(jù)插入圖形編輯器

提示詞開發(fā)

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

模型推薦

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

我想讓你做一個模版推薦，我會把你精通的模版都告訴你，請你根據(jù)我輸入的問題給我推薦適合的模版。
你現(xiàn)在精通：用戶旅程地圖、用戶畫像、精益畫布、用戶故事、SWOT分析、干系人地圖。
推薦模板要求：
1.如果問題內(nèi)含有模板相關(guān)的詞匯，請優(yōu)先推薦對應(yīng)模板。
2.如果沒有適合的模板，請回復(fù)：暫無適合的模板。
3.推薦模板最多5個，最少1個，按推薦優(yōu)先級排序。
注意：只要推薦模板名稱，不要回答問題，也不要對模板進行解釋。

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

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

模型的結(jié)構(gòu)化文本

以上是根據(jù)產(chǎn)品同學(xué)在進行需求調(diào)研時的提示語跟 LLM 產(chǎn)生的對話, 可以看到 LLM 可以生成結(jié)構(gòu)化的數(shù)據(jù)，那如何去解析這些數(shù)據(jù)呢？

不如試試讓 LLM 直接輸出 JSON 數(shù)據(jù)吧

從上圖可以看出，只要告訴 LLM 一個固定的 JSON 輸出格式。則在對話可以生成定義好的 JSON 數(shù)據(jù)格式，只需要通過正則提取出該 JSON 即可。

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

但在開發(fā)過程中也發(fā)現(xiàn)了如下幾點問題：

• 雖然可以生成結(jié)構(gòu)化數(shù)據(jù)，但整體生成的結(jié)果內(nèi)容仍然有些“泛”，數(shù)據(jù)的質(zhì)量不高，對用戶參考價值不大。

• LLM 輸出的數(shù)據(jù)不夠穩(wěn)定，通過正則提取加 JSON.parse 的方式錯誤率很高。

• LLM 輸出完整數(shù)據(jù)的時間長，需要很長的等待時間，會造成用戶的等待焦慮。

提示詞增強

在探索過程中，對提示詞進行了多次調(diào)整，始終無法生成穩(wěn)定，高質(zhì)量的內(nèi)容。以精益畫布的提示詞：

你現(xiàn)在是一個創(chuàng)業(yè)專家，能夠熟練的使用精益畫布，精益畫布分成：
1.問題&用戶痛點。
2.用戶細(xì)分。
3.獨特賣點。
4.解決方案。
5.渠道。
6.關(guān)鍵指標(biāo)。
7.競爭壁壘。
8.成本結(jié)構(gòu)。
9.收入分析。
現(xiàn)在有用戶向你詢問如何進行創(chuàng)業(yè)，你需要用精益畫布的方式分點（不少于4個點）給出解答，解答內(nèi)容務(wù)必非常詳細(xì)。固定回答格式如下：xxx

為提高穩(wěn)定性，做了以下措施：

• 加了各種定語如：盡可能詳細(xì)、每個點不少于 4 個等限制條件。

• 增加示例數(shù)據(jù)：從 LLM 的原理上來看，它的模式是通過推理來生成回答。那我們可以直接告訴它你理想的數(shù)據(jù)例子，提高其推理效率。

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

設(shè)計稿拆解

設(shè)計稿最小母版

以用戶旅程地圖為例，對設(shè)計稿進行拆解，縮減內(nèi)容則可以得出一個最小的設(shè)計稿母版。通過這個最小模板再組合 LLM 輸出的數(shù)據(jù)可以輸出最終的設(shè)計稿。整個模型由以下幾大類組成：

• 列的頭部（固定內(nèi)容）

• 旅程模塊：旅程一，旅程二，旅程三（表格）

• 名稱，用戶目標(biāo)與期望

模型的預(yù)定義數(shù)據(jù)

結(jié)合上文，我們可以歸納出一個模型需要做以下的數(shù)據(jù)準(zhǔn)備：

• 通過?Figma Api Live?可以拿到最小母版的設(shè)計稿數(shù)據(jù)

• 模型關(guān)聯(lián)的 schema.json 按每個模型的特點進行定制

• 模型提示詞由不同的模型特性決定

• 示例數(shù)據(jù)用于增強提示詞

設(shè)計稿數(shù)據(jù)組裝

輸出數(shù)據(jù)結(jié)構(gòu)定義

通過歸納分析各個模型，可以總結(jié)出模型設(shè)計稿存在大量的共性，設(shè)計稿內(nèi)可以分為以下三種模塊：

固定輸出模塊

如表頭，標(biāo)題，分割線。用于定義用戶不會修改的模塊，這類模塊不需要做文本替換。

表格型模塊

如用戶旅程地圖中的每個階段，這種類表格需要通過以 schema.json 來做內(nèi)容的數(shù)據(jù)描述。

"ths":?["階段一","階段二"],
"data":?{
??"階段一":?{
????"欄目一":?["內(nèi)容",?"內(nèi)容"],
????"欄目二":?["內(nèi)容",?"內(nèi)容"]
??},
??"階段二":?{
????"欄目一":?["內(nèi)容",?"內(nèi)容"],
????"欄目二":?["內(nèi)容",?"內(nèi)容"]
??}
}

分塊型模塊

如 SWOTA 分析，該模型的每一個區(qū)塊都固定的，只需要進行文本內(nèi)容塊的處理即可。則其 schema.json 如下：

"data":?{
??"優(yōu)勢":?["xx","xx"],
??"劣勢":?["xx","xx"],
??"機會":?["xx","xx"],
??"威脅":?["xx","xx"],
??"通過優(yōu)勢利用機會的策略":?["xx","xx"],
??"利用優(yōu)勢防止威脅的策略":?["xx","xx"],
??"通過機會最小化弱點的策略":?["xx","xx"],
??"將其潛在威脅最小化的策略":?["xx","xx"]
}

設(shè)計稿數(shù)據(jù)生產(chǎn)

下一步就是針對各個模型進行設(shè)計稿的數(shù)據(jù)生產(chǎn)了，上圖可以是設(shè)計稿中的畫板列表，會按這個畫板結(jié)構(gòu)與數(shù)據(jù)建立索引關(guān)系。

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

"schema":?{
????"user":?{
??????"用戶信息":?"x",
??????"用戶目標(biāo)與期望":?"x"
????},
????"ths":?["旅程一"],
????"data":?{
??????"旅程一":?{
????????"用戶行為":?["1"],
????????"服務(wù)觸點":?["1"],
????????"用戶預(yù)期":?["1"],
????????"情緒曲線":?"中",
????????"用戶痛點":?["1"],
????????"機會點":?["1"]
??????}
????}
??},

要根據(jù) schema.json 生產(chǎn)出設(shè)計稿需要做以下幾件事情：

• 設(shè)計稿建立圖層 名稱與 scheme.json 中 key 的索引關(guān)系

• 固定模塊直接從設(shè)計稿母板數(shù)據(jù)中輸出對應(yīng)的數(shù)據(jù)即可

• 名稱和用戶目標(biāo)與期望找到索引并替換文本

• 根據(jù)旅程創(chuàng)建出對應(yīng)的旅程模塊。以母版中的旅程一為基準(zhǔn)，拷貝后，進行位置偏移，并計算出最外層的寬度。

• 每一列根據(jù)返回文本數(shù)量，如旅程一中的用戶行為里有 4 個文本。則創(chuàng)建出四個便簽。并處理好每一個便簽的位置關(guān)系即可。

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

Figma 數(shù)據(jù)解析

上圖是設(shè)計稿數(shù)據(jù)到 Figma 的解析流程圖，核心流程如下：

• 輸入設(shè)計稿數(shù)據(jù)

• 節(jié)點樹深度優(yōu)先遍歷

• 節(jié)點類型判斷并創(chuàng)建節(jié)點

• 節(jié)點屬性設(shè)置：位置，尺寸，填充，邊框等

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

?

解決用戶等待焦慮

跟傳統(tǒng)的 webAPI 不同，LLM 接口完整數(shù)據(jù)的響應(yīng)時長根據(jù)數(shù)據(jù)量大小決定，本應(yīng)用會輸出大量文本，模型需要 40-60 秒的時間完成所有數(shù)據(jù)響應(yīng)，因此會造成用戶等待時間焦慮。

對話式交互

最初的設(shè)計是將文本展示給用戶，這種方式是當(dāng)前主流的LLM對話式應(yīng)用的交互形式。實現(xiàn)這種方式只需要將LLM流式輸出的文本展示出來即可。然而，這種方式的缺點也非常明顯，畫布中并沒有實質(zhì)性的圖形渲染，且用戶無法通過對話進行互動。因此，以文本作為主要的用戶交互方式體驗是不完整和不夠理想的，不是最佳的解決方案。

?

漸進式渲染

那能不能像打字機效果一樣，在流式數(shù)據(jù)傳輸過程中，一邊生成一遍是渲染內(nèi)容呢？

難點在于在組裝模版和渲染過程中，我們是拿到標(biāo)準(zhǔn)化的數(shù)據(jù)結(jié)構(gòu)再一次性插入畫布。而在流式數(shù)據(jù)傳輸過程中返回的數(shù)據(jù)，只是整個最終結(jié)構(gòu)化數(shù)據(jù)的某一個片段。如下所示：

//?最終的json數(shù)據(jù)
const?data?=?'你好，以下是頭腦風(fēng)暴/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"]}}'

//?流式傳輸過程中數(shù)據(jù)示例1
const?process1?=?'你好，以下是頭腦風(fēng)暴/n?{"data":{"用戶獲取":["1","2","3","4","5"],"用戶活躍":["1","2","3","4","5"],"用戶留存":["1","2","3","4","5"],"獲得收益":["1","2","3","4'

//?流式傳輸過程中數(shù)據(jù)示例2
const?process2?=?'你好，以下是頭腦風(fēng)暴/n?{"data":{"用戶獲取":["1","2","3","4","5"],"用戶活躍":["1","2","3","4","5"],"用戶留存":["1","2","3","4","5"],"獲得收益":[,'

如上面的數(shù)據(jù)示例所示，在流式傳輸過程中，需要把 process1 和 process 的數(shù)據(jù)轉(zhuǎn)為下面的標(biāo)準(zhǔn)化 JSON 數(shù)據(jù):

//?過程中數(shù)據(jù)示例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 的方式錯誤率很高。要實現(xiàn)上面的提取和補全，我們需要把 LLM 返回的內(nèi)容提取和補全成標(biāo)準(zhǔn)的 JSON 數(shù)據(jù)，實現(xiàn) JSON 數(shù)據(jù)提取的可控。然后在流式輸出過程中寫一個定時器，每隔一段時間走設(shè)計稿組裝+渲染流程即可。

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

JSON 提取與補全算法

上圖展示了整個算法的運行流程，其核心是實現(xiàn)一個有限狀態(tài)自動機，通過逐個解析字符串并進行拼裝和補充從而生成標(biāo)準(zhǔn)化的 JSON 數(shù)據(jù)格式。

分析模型示例

總結(jié)

在本文中，我們詳細(xì)總結(jié)了實現(xiàn) AI 可視化分析模型的過程中所需進行的功能拆解和實現(xiàn)思路。在此基礎(chǔ)上，還分享了在利用 LLM 生成結(jié)構(gòu)化數(shù)據(jù)時所遇到的問題及其相應(yīng)解決方案。我們相信這些經(jīng)驗總結(jié)能夠為在此領(lǐng)域工作的同行提供有價值的幫助，幫助大家更好地理解和掌握這些技術(shù)。同時，這些經(jīng)驗也能為后續(xù)的研究工作提供有益參考。我們希望這些總結(jié)能夠為讀者提供一個清晰詳盡的指導(dǎo)和實踐思路。

?

作者：ivring文章來源地址http://www.zghlxwxcb.cn/news/detail-580847.html

到了這里，關(guān)于面向AI編程：探索可視化分析模型的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！