導(dǎo)讀

近期 AIGC 狂潮席卷，“前端走向窮途”“低代碼時代終結(jié)”的言論甚囂塵上。事實上 GPT 不僅不會干掉低代碼，反而會大幅度促進低代碼相關(guān)系統(tǒng)的開發(fā)。本文會介紹 GPT Prompt Engineering 的基本原理，以及如何幫助低代碼平臺相關(guān)技術(shù)快速開發(fā)落地的技術(shù)方案。接著往下看吧~

看目錄點收藏，隨時漲技術(shù)

1 提示工程

1.1 提示工程基本概念

1.2 如何使用 OpenAI/ChatGPT 做提示工程測試

1.3 role & token

1.4 提示工程技巧-少樣本提示（few shot）

1.5 提示工程技巧-思維鏈提示（Chain-of-Thought，CoT）

1.6 提示工程技巧-生成知識（knowledge generation)

1.7 提示工程的總結(jié)

1.8 langchain 的介紹

2 低代碼技術(shù)

2.1 低代碼技術(shù)介紹

2.2 Hello world：AI2SQL

2.3 接口網(wǎng)關(guān)：構(gòu)建 AI 友好的應(yīng)用

2.4 低代碼搭建：生成知識技術(shù)的大規(guī)模使用

2.5 低代碼搭建：邏輯編排技術(shù)與 GPT

2.6 低代碼搭建：數(shù)據(jù)可視化技術(shù)與 GPT

2.7 文檔系統(tǒng)的 GPT 搭建

2.8 總結(jié)

3 GPT 高級使用技巧走馬觀花與總結(jié)

01

提示工程

1.1 提示工程基本概念

提示工程是什么？如圖所示。你同大模型的交談就是所謂的 Prompt， 而如何設(shè)計、組織、優(yōu)化則稱為提示工程（Prompt Engineering）。

提示工程是通用技術(shù)，適合于幾乎所有大語言模型（Large Language Models，簡稱LLMs）。

在大模型應(yīng)用的開發(fā)過程中，Prompt Engineering 做得好，不僅可以提升回答的質(zhì)量，也可以限制回答的格式，因此提示工程也能夠幫助大模型返回的內(nèi)容更友好地被解讀，這對后續(xù)跟其他系統(tǒng)的集成非常重要。

一般來講提示工程包含如下的信息：

· 指令 —— 希望模型執(zhí)行的特定任務(wù)或指令，文字描述清楚。 · 上下文 —— 可以包含外部信息或額外的上下文，以引導(dǎo)模型更好地進行響應(yīng)，在對話類型的 GPT 應(yīng)用中就是所謂的“聊天記錄”。 · 輸入數(shù)據(jù) —— 用戶希望找到響應(yīng)的輸入或問題。 · 輸出指示符 —— 指示輸出的類型或格式，比如可以要求輸出 SQL/JSON。

1.2 如何使用 OpenAI/Chatgpt 做提示工程測試

除了直接訪問官網(wǎng)之外，各位開發(fā)者同時也可以使用 Node.js or Python 直接調(diào)用 OpenAI api ?；舅悸肪褪侵苯右?OpenAI 的包，然后傳入適當(dāng)?shù)膮?shù)即可。例如 ：

在測試過程中需要關(guān)注兩個點。首先是參數(shù) temperature 、top_p。

· temperature（溫度） —— 簡言之，溫度越低，結(jié)果越具有確定性，因為總是選擇概率最高的下一個詞。提高溫度可能導(dǎo)致更多的隨機性，鼓勵產(chǎn)生更多樣化或富有創(chuàng)意的輸出對基于事實的問答任務(wù)使用較低的溫度值，以鼓勵更加準(zhǔn)確和簡潔地回答。對于詩歌生成或其他創(chuàng)意任務(wù)，提高溫度值可能會更有益。

· top_p —— 類似的，通過 top_p 調(diào)節(jié)名為 nucleus sampling 的溫度抽樣技術(shù)，可以控制模型在生成回應(yīng)時的確定性。如果需要準(zhǔn)確和事實性的答案，請保持較低的 top_p 值，如果希望獲得更多樣化的回應(yīng)，請增加到較高的 top_p 值。

另外是模型 text-davinci-003 和 gpt-3.5-turbo 的區(qū)別。

text-davinci-003 和 gpt-3.5-turbo 都是 OpenAI GPT-3 系列中的兩個模型，區(qū)別在于性能和價格，此處我們著重講下性能的對比。

性能：gpt-3.5-turbo 相對于 text-davinci-003 在性能方面有所提高。根據(jù) OpenAI 的說法，gpt-3.5-turbo 在許多任務(wù)中的性能與 text-davinci-003 相當(dāng)或更好。這意味著，與 text-davinci-003 相比，gpt-3.5-turbo 可以在保持相同質(zhì)量輸出的同時更有效地完成任務(wù)。

1.3 role & token

在調(diào)用 OpenAI 的過程中你會看到，消息會傳入一個參數(shù)叫做 Role 。

不同 Role 的含義如下：

系統(tǒng)消息(role = system)：一般用于定義 GPT 對話的行為，比如：你是一個 SQL 工程師，擅長寫 SQL。gpt-3.5-turbo-0301 并不會把這個系統(tǒng)消息做很高的優(yōu)先度關(guān)注。未來的模型將被訓(xùn)練為更加關(guān)注系統(tǒng)消息。

用戶消息(rule=user)：一般是用戶自己的輸入以及開發(fā)者給 GPT 的一些指令。

助手消息(rule=assistant) ：可以幫助存 GPT 自己的響應(yīng)。

當(dāng)對話場景需要引用之前的消息時，就需要維護好這個 message 數(shù)組，這就是所謂 GPT 對話的上下文 or 歷史記錄。

大模型對過去的請求沒有記憶，所以你如果想保持這個上下文，必須維護好這個 message，然后在每次對話過程中，把完整的 message 傳過去。因此，如果這些記錄超過了模型的 token 限制，就需要以某種方式縮短它。

另外我們經(jīng)常說的 Token 是什么意思呢？

GPT 家族的大語言模型會使用 Token 作為處理文本的標(biāo)識，用來標(biāo)識一段文本中的“詞”。大語言模型會理解這些 Token 之間的關(guān)系，并能夠預(yù)測一系列 token 中的下一個。文本占據(jù)多少 Token 我們可以通過 https://platform.openai.com/tokenizer or tiktoken 來計算 ，如圖：

在這里可以很明顯地看到，中文占據(jù)了大量 Token，同時換行、標(biāo)點符號等也會占據(jù) Token。根據(jù) OpenAI 的建議，一個 token 能寫4個字母，或者0.5個漢字。因此4000個 token 可以寫2000字的中文。

下圖是輸入和輸出都會計算 Token 。比如 API 調(diào)用在消息輸入中使用了 10 個 Token，而您在消息輸出中收到了 20 個 Token，則需要支付 30 個 Token 的費用。如果在調(diào)用時候超了，會調(diào)用失敗。輸出的時候超了，會被截斷。因此你自己的 GPT 應(yīng)用， 一定要實現(xiàn)“試算 Token”的功能。不同模型支持的 Token 最大值參考 。

由于 Token 價格昂貴，因此在一段時間之內(nèi)，“省 Token ”都是 AI 應(yīng)用需要關(guān)注的重要問題。

1.4 提示工程技巧-少樣本提示(few shot)

目前的大語言模型（LLMs）通過大量的數(shù)據(jù)訓(xùn)練和指令調(diào)整，能夠在零樣本情況下完成任務(wù)。

以上例子中我們直接向大模型提問，并沒有添加任何需要示范的例子，就可以得到很好的回復(fù)，這便是零樣本能力。但事實上很多場景零樣本是無法得到我們想要的結(jié)果的：

這時候我們就可以通過少樣本提示技術(shù)，給 GPT 舉幾個例子，幫助它學(xué)習(xí)思考：

這樣看，效果就好很多了。這個例子也體現(xiàn)了大模型強大的學(xué)習(xí)能力。在我們后續(xù)要講的低代碼開發(fā)中，few shot 技術(shù)是非常常用的，如圖：

我們通過 few shot，讓 GPT 學(xué)會了我們自己定義的圖表 DSL 。但零樣本提示是萬能的嗎？比如我們看以下例子。零樣本提示：

這明顯是錯誤的，我們使用 few shot 技術(shù)：

可以看出來還是錯誤的。因此 few shot 技術(shù)，并不能解決一些數(shù)學(xué)和推理場景。

1.5 提示工程技巧-思維鏈提示（Chain-of-Thought，CoT）

思維鏈提示（Chain-of-Thought，CoT）是一種用于提高大語言模型推理能力的技術(shù)，通過提示模型生成一系列推理步驟來解決多步驟的問題。研究表明，這種技術(shù)可以顯著提高模型在數(shù)學(xué)、常識、推理等方面的準(zhǔn)確性。該技術(shù)的應(yīng)用使得模型能夠?qū)⒍嗖襟E的問題分解成中間步驟，從而更好地理解和解決問題。

比如一個簡單的例子 ：

我們發(fā)現(xiàn) GPT 已經(jīng)完全懵了。但如果我們加入一句“請一步步思考下”，引導(dǎo) GPT 按照步驟思考呢？

效果非常驚人。同樣我們在之前的例子中使用魔法咒語：

效果也非常好。事實上思維鏈的“觸發(fā)”方式，就是在原始提示中添加“逐步思考”"請一步步思考問題"，但它能夠起到非常驚人的效果。在去年 google io 中還專門演示了這個技術(shù) 。

事實上，思維鏈遠(yuǎn)遠(yuǎn)不止“讓我們逐步思考”這一魔法咒語，它可以僅僅通過 Prompt 就可以讓 GPT 完成非常復(fù)雜的任務(wù)。下面我們來舉個例子：

假設(shè)今天我需要送給一個朋友禮物，希望有一個機器人能告訴你。如果我們考慮下自己的思考過程，可能會這么想：

· 我這個朋友是男生。 · 男生可能會喜歡一些高達、手辦、相機等等。 · 那我就在其中選擇一個。

可以看出，人們在得到一個問題的最終答案前，通常是會有若干個「中間步驟（intermediate steps）」的。因此我們可以把這些“中間步驟”明確出來，引導(dǎo) GPT 進行思考，prompt 設(shè)計如下：

這個 Prompt 中，首先我提供了兩個工具，告訴這兩個工具可以幫助 GPT 獲得答案。之后特別指出，GPT 每次思考都要返回 Thought、Action、Action Input，它要先去我的工具庫中尋找工具，調(diào)用適合的工具，并返回答案，同時要一直不停地做，直到得到答案。那我們看下實際使用時，GPT 是如何思考的：

可以看到 GPT 像人一樣，一步步地思考問題，它首先理解了這個問題，并從工具庫中取出了性別判斷工具，進行判斷后，它又在工具庫中取出了禮物推薦工具，并進一步得到結(jié)論。其實這個思路就是非常流行的 Reasoning Acting ：React 技術(shù)，每次讓 LLM 輸出一個當(dāng)前的【思考】和【要做的動作】，這個動作并不只限于檢索信息，可以是調(diào)用任何工具，類似 ChatGPT plugin。LLM 通過 few shot 的例子和工具自帶的描述，還有它自己學(xué)到的常識來決定何時調(diào)用工具以及如何調(diào)用工具。

這樣 ReAct 引入了外部工具的概念，讓 LLM 能夠通過這種步進式的方式逐步思考并調(diào)用外部工具，根據(jù)結(jié)果進一步思考循環(huán)。同時也可以僅僅是輸出一步思考，并繼續(xù)下去，類似 CoT。在流行的開發(fā)框架 Langchain 中就封裝了幫助實現(xiàn)這個思路的一系列工具。

1.6 提示工程技巧-生成知識(knowledge generation)

生成知識提示是一種利用語言模型自動生成知識并整合到常識推理中的方法。這種方法利用了大語言模型的優(yōu)勢，將其作為改進常識推理的、靈活的外部知識來源。通過使用通用的提示格式直接從語言模型中生成知識陳述，然后選擇與給定任務(wù)相關(guān)的知識，可以提高常識推理的準(zhǔn)確性。這種方法在語言生成、自然語言推理和問答系統(tǒng)等領(lǐng)域具有廣泛的應(yīng)用前景。

舉例來講：

事實上高爾夫球應(yīng)該是總分越低越好，GPT 對高爾夫球的理解一知半解。但我們在 prompt 的時候傳入高爾夫球知識呢？

可以看到回答就很準(zhǔn)確了。因此生成知識可以幫助 GPT 掌握并加深已有知識的理解。同樣我們從低代碼角度來考慮一下這個問題。

在這個 prompt 中，我們要求 GPT 給我們一個流程描述的 DSL，GPT 給了，事實上這也是一種常用的 DSL 叫做 mermaid 。

當(dāng)我們有自己的 DSL 想讓 GPT 返回，這樣就可以借助生成知識 few shot 技術(shù)：

可以看到 GPT 返回了我們想要的邏輯編排的 DSL。因此生成知識技術(shù)結(jié)合 few shot 是很多 AI 低代碼技術(shù)的基石。后續(xù)我們的文章也會大面積地使用生成知識技術(shù)。

1.7 提示工程的總結(jié)

基本原則：

· 從最基本，最原子的任務(wù)做起，將大任務(wù)分解成多個子任務(wù)。 · 提示內(nèi)容最好包含：指令、上下文、輸入、輸出格式。 · 對于希望模型執(zhí)行的指令和任務(wù)要非常具體。提示越具有描述性和詳細(xì)性，結(jié)果越好。最好帶上例子。 · 不要寫太多沒有意義的話。盡量精煉，不要帶前后矛盾的提示。

同樣我們也可以使用以下的高級技巧：

· 少樣本提示（Few-Shot Learners）。給出一些樣例，引導(dǎo)模型按照樣例回答。 · 思維鏈（Chain-of-Thought（CoT）prompting）。通過提供推理步驟，讓大語言模型具備分析能力。過程中也提到了（Zero-Shot CoT），引導(dǎo)模型在回答的時候，給出推理步驟，會更容易獲得理想的結(jié)果。 · 生成知識（Generated Knowledge Prompting）。對于一些大模型不掌握的知識。我們可以通過提示的形式輸入進去，從而獲得更準(zhǔn)確的答案。

1.8 langchain 的介紹

langchain 是一個非常好用的框架，能夠幫助我們快速構(gòu)建基于大模型的應(yīng)用程序。它提供了很多工具、組件和接口。對于前端來講甚至可以把它類比成 lodash/jquery 一樣的基礎(chǔ)庫。

langchain 的模塊大致如上所示，簡單介紹一下就是：

· 針對各種 LLM 調(diào)用的封裝和緩存。 · 基于文本的處理，包括各種文檔的加載方式（本地/云），文檔的處理方式，以及各類向量數(shù)據(jù)庫的連接工具。 · 提示詞 prompt 管理，其實可以理解為一個模板引擎，可以方便地管理我們的各種提示詞模板、few shot的例子等等，也可以幫助解析 OpenAI 返回的內(nèi)容。 · Chains 是 LangChain 中最重要的概念，其實可以理解為一個個有明確輸入/輸出的獨立任務(wù)，可以使用 Chain 構(gòu)建完成某個特定任務(wù)的應(yīng)用程序。例如，我們可以創(chuàng)建一個鏈，它接收用戶輸入，使用 Prompts 相關(guān)組件格式化輸入，然后將格式化后的結(jié)果傳遞給 LLM，然后將 LLM 的輸出傳遞給后端組件或者其他鏈。我們也可以通過將多個鏈組合在一起，或?qū)㈡溑c其他組件組合來構(gòu)建更復(fù)雜的鏈。LangChain 實現(xiàn)了很多現(xiàn)成的鏈，比如用于對文章進行總結(jié)的 Summarization 鏈，用于對指定文本進行問答的 Question Answering/Question Answering with Sources 鏈，用于對指定知識庫問答的 Retrieval Question Answering/Retrieval Question Answering with Sources 鏈，用于獲取并解析網(wǎng)頁的 LLMRequestsChain 鏈，用于操作關(guān)系型數(shù)據(jù)庫的 SQLDatabaseChain 鏈等。

我們可以看下如何使用 langchain 快速搭建一個基于 GPT 的爬蟲應(yīng)用：

結(jié)果如下：

可以看到，我們結(jié)合 langchain 簡單的 prompt 就完成了一個爬蟲的編寫。

02

低代碼技術(shù)

2.1 低代碼技術(shù)介紹

近年來，低代碼開發(fā)熱潮又一次襲來，業(yè)界對“降本、增效、提質(zhì)”的聲音越來越強。騰訊的微搭等大量低代碼產(chǎn)品相繼而至，在業(yè)界引發(fā)關(guān)注。目前的低代碼產(chǎn)品，大部分偏重于 “UI 界面可視化編排”，但低代碼這個概念其實涵蓋范圍非常廣。如圖所示，在國外，低代碼類產(chǎn)品矩陣非常龐大。某站點將低代碼類產(chǎn)品按照功能分為以下幾類：

· BI 數(shù)據(jù)可視化圖表搭建 · CRM 類應(yīng)用搭建 · 機器學(xué)習(xí)類應(yīng)用搭建 · 企業(yè)應(yīng)用搭建 · 店鋪裝修工具 · 物聯(lián)網(wǎng)、IOT 構(gòu)建工具 · Web、Mobile 應(yīng)用開發(fā) · 工作流系統(tǒng)

同時對于一個完整的 web 應(yīng)用來講，它會經(jīng)過用戶界面-接口服務(wù)-數(shù)據(jù)服務(wù)等多個模塊，因此這次的低代碼與 GPT 結(jié)合，我們也會在整個鏈路上進行嘗試：

我們的思路簡單拆解就分為以下三步：

2.2 Hello world：AI2SQL

寫 SQL 是接口/數(shù)據(jù)工程師極其頭疼的問題，以這個為開場的原因是 AI2SQL 的場景足夠明確，Prompt 也比較好設(shè)計。

分解任務(wù)：

· 目標(biāo)：希望能夠根據(jù)需求自動生成 SQL。 · 我需要獲取目前的庫表信息，之后根據(jù) SQL 知識構(gòu)建 SQL。

構(gòu)造 prompt：

· 指令 —— 希望模型輸出 SQL · 上下文 —— 當(dāng)前在哪個庫，哪個表 · 輸入數(shù)據(jù) —— 表結(jié)構(gòu) – DDL · 輸出指示符 —— 我希望輸出純正 sql，不想解析一堆內(nèi)容

于是我們就有如下構(gòu)造方式：

其思路就是把表結(jié)構(gòu)和用戶輸入傳給 GPT 由 GPT 去編寫。我們目前的可能產(chǎn)品形態(tài)如下：

用戶輸入復(fù)雜的描述，其中甚至帶有很多對 SQL 語法的要求，GPT 也能快速準(zhǔn)確地返回。

在這個例子中，我們發(fā)現(xiàn)構(gòu)建 GPT 產(chǎn)品時，主要的工作都在組織 prompt 上，因此對 prompt 進行設(shè)計可以有效達到目的。同時 SQL 是 GPT 非常擅長編寫的語言。注意我在這里特別強調(diào)了“非常擅長”，后面還會講這個的重要性。最后為了讓 GPT 感知到我們的表結(jié)構(gòu)，我們利用生成知識（Generated Knowledge Prompting） 這一技巧，讓 GPT 掌握了它不知道的東西。

AI2SQL 這一類系統(tǒng)的架構(gòu)設(shè)計如下：

在實際產(chǎn)品中，我們把 GPT 當(dāng)作是一個服務(wù)，人機交互由產(chǎn)品進行處理，同時通過代理訪問 GPT。系統(tǒng)的表結(jié)構(gòu)、元數(shù)據(jù)可以“喂給”GPT 當(dāng)作語料，但單純傳入 DDL 會嚴(yán)重超出 Token， 所以也可以通過對元數(shù)據(jù)的縮減可以減少 Token：

目前這一類的開源產(chǎn)品有 https://github.com/sqlchat/sqlchat 大家可以看看其產(chǎn)品形態(tài)。

同樣，langchain 在開發(fā)這一類應(yīng)用時也具有天然的優(yōu)勢，因為各種包都是現(xiàn)成的，甚至有一個現(xiàn)成的 AI2SQL 的 chain，如圖所示：

我們可以看到利用 langchain 開發(fā) AI 應(yīng)用的基本思路：選擇一個合適的 chain， 初始化需要的參數(shù)模塊，之后 run 即可。

2.3 接口網(wǎng)關(guān)：構(gòu)建 AI 友好的應(yīng)用

低代碼繞不開的就是接口服務(wù)網(wǎng)關(guān)了。通常來講，用戶希望能夠通過服務(wù)直接獲取需要的數(shù)據(jù) /API ，而不是對著一堆接口列表進行開發(fā)，因此我們的思路是這樣的：

分解任務(wù)：

· 通過目前系統(tǒng)的接口如何獲得數(shù)據(jù) · 需要返回接口或者數(shù)據(jù) · GPT 是不知道我的接口的

構(gòu)造 prompt：

· 指令 —— 希望告訴我如何組裝接口，獲取有效的數(shù)據(jù) · 上下文 —— 當(dāng)前的接口數(shù)據(jù) · 輸入數(shù)據(jù) —— 用戶需要的字段 · 輸出指示符 —— 指示輸出的類型或格式

我們給 GPT 添加一套寵物管理系統(tǒng)，之后看一下效果：

首先我們獲取系統(tǒng)內(nèi)的接口：

GPT 可以正常返回并構(gòu)造好系統(tǒng) API 給我們。之后我們直接請求數(shù)據(jù)：

GPT 也可以把數(shù)據(jù)加工好給到我們。那如何才能讓 GPT 了解系統(tǒng)內(nèi)的接口呢？答案是使用 Swagger API，因此這類系統(tǒng)可以這樣設(shè)計：

我們?nèi)匀焕萌f能的“生成知識”，首先把 Swagger API 加載到系統(tǒng)中，并首先傳給 GPT 作為知識和上下文。之后用戶的詢問會經(jīng)過代理服務(wù)傳給 GPT，GPT 的學(xué)習(xí)能力能夠理解很多接口操作，因此 GPT 會首先返回符合要求的接口以及相關(guān)的參數(shù)。由于用戶可能需要直接獲取數(shù)據(jù)，因此我們可以讓系統(tǒng)自己去請求數(shù)據(jù)，之后可以把返回數(shù)據(jù)再給到 GPT， GPT 會幫你加工成“人話”，最終給到用戶，這樣就完成了一個接口網(wǎng)關(guān)的 GPT 實現(xiàn)。

但這樣的設(shè)計還存在不少問題，如：

· 接口數(shù)據(jù)仍然占據(jù)大量的 Token，Swagger API 體積巨大，冗余信息很多。 · 接口的能力會限制服務(wù)能力，用戶的需求是枚舉不完的，比如寵物管理系統(tǒng)中，沒有用戶和寵物的關(guān)聯(lián)接口，提問后 GPT 的反應(yīng)就很懵了。

因此可以考慮這個思路：在縮減 Token 的基礎(chǔ)上，能夠讓 GPT 提供的接口服務(wù)更加靈活。

舉例來講 ，一個通常的 RBAC 模型，它的設(shè)計是這樣的：

如果我們使用 restful 接口開發(fā)一個權(quán)限管理系統(tǒng)，需要至少實現(xiàn)以下的接口：

可以看到仍然會陷入無盡的接口開發(fā)工作中。但我們?nèi)绻麚Q個思路，通過另一種對數(shù)據(jù)模型描述性很強的語言 graphql 來實現(xiàn)呢？首先我們轉(zhuǎn)換成 graphql 模型，即使不會寫也沒關(guān)系，GPT 可以幫助你把 DDL 轉(zhuǎn)換為 graphql ：

之后我們就可以自由地進行查詢：

注意，我們并沒有做任何的接口開發(fā)工作，僅僅是定義好模型，就可以自由地通過 GQL 做查詢。為什么我們換一個技術(shù)棧，GPT 就變得更加絲滑了，其中有以下幾個原因：

· restful 接口在進行一些復(fù)雜查詢時需要多輪，而 GQL可能一輪 query 就搞定了。 · AI 對 GQL，SQL 的知識掌握，是遠(yuǎn)遠(yuǎn)比我們喂給它的現(xiàn)成接口要多的！

因此，AI 可以認(rèn)為是一個很成熟的 SQL/GQL/React 等的開發(fā)者，卻并不是一個好的 http 接口的開發(fā)者。

AI 友好，即在可以使用各種 prompt engineer 各種技術(shù)棧的基礎(chǔ)上， 你仍然可以選擇 AI 最會的技能。

2.4 低代碼搭建：生成知識技術(shù)的大規(guī)模使用

首先我們來看一個 Demo， 這是來自騰訊揭光發(fā)老師的精彩分享，通過自然語言生成頁面，并支持二次編輯

經(jīng)過上面的實戰(zhàn)，實現(xiàn)此系統(tǒng)的基本思路：

· 利用生成知識技術(shù)，設(shè)計一個 prompt，使 GPT 返回自己的 DSL。 · 利用相關(guān)的系統(tǒng) API，將頁面依賴的數(shù)據(jù)源，系統(tǒng)的組件等信息加載進來。

利用生成知識技術(shù)，設(shè)計一個 prompt，使 GPT 返回自己的 DSL。

但通過生成知識，存在以下問題：

· 組件層面：組件很多，屬性很多，如何全部丟到 prompt 中？ · 大部分的 AIGC 類需求，都以一次生成為主，但低代碼這種高頻編輯（需求高頻變動的）如何解決更新問題？

首先我們來構(gòu)造 prompt：

大部分的 AIGC 類需求，都以一次生成為主，但低代碼這種高頻編輯（需求高頻變動的）如何解決更新問題？

可以看出跟我們想要的預(yù)期是一致的。但一般低代碼產(chǎn)品有幾十上百個組件，把所有的組件文檔塞進去很不現(xiàn)實，因此我們可以前置提供一個組件路由的模塊，根據(jù)用戶輸入來判斷需要哪些組件：

這樣我們就可以根據(jù)用戶的需求選擇對應(yīng)組件，整體的系統(tǒng)架構(gòu)如圖所示：

第二個問題，如何實現(xiàn)根據(jù)需求二次編輯 DSL 呢，我們當(dāng)然可以每次都生成一份新的 DSL，但這樣很容易浪費 Token。由此我們使用了一個有意思的技術(shù)叫 JSON Patch：

JSON Path 可以描述 JSON 文檔變化. 使用它可以避免在只需要修改某一部分的時候發(fā)送整個文檔內(nèi)容. 補丁(Patch)內(nèi)容的格式也是 JSON.JSON Patch 由 IETF 在 RFC 6902 – JavaScript Object Notation (JSON) Patch 中規(guī)范。

舉例來講：

可以看到，JSON patch 能夠比較準(zhǔn)確的描述對 JSON 這一 DSL 的操作。由此我們可以設(shè)計 prompt 讓 GPT 返回 JSON patch 和相關(guān)修改后的 DSL：

同樣我們也可以限制 GPT 只返回 Patch。

2.5 低代碼搭建：邏輯編排技術(shù)與 GPT

邏輯編排主要解決能夠通過 FLOW（流程）或有向圖來描述的業(yè)務(wù)形態(tài)，如業(yè)務(wù)流程編排，接口服務(wù)編排，UI 復(fù)雜聯(lián)動，微服務(wù)（FAAS）編排，大數(shù)據(jù)/機器學(xué)習(xí) pipleline 等 。一般來講它的基礎(chǔ)思路基于 FBP，所以我們需要根據(jù) FBP 的思路設(shè)計 DSL。

Flow Based Programing (https://github.com/flowbased)是 J. Paul Rodker Morrison 很早以前提出的一種編程范式。FBP 把應(yīng)用看作一個黑盒子，它能夠看到的是一張進程（processes）組成的網(wǎng)，而進程間通過連接（connection）進行通信，進程通過端口（port）來訪問連接（這種抽象類似網(wǎng)絡(luò)編程）。

FBP 有三大概念，支撐整個架構(gòu)：

· 進程：組件（component）的一個實例，可以跟其他進程并行運行。其他進程可以是同個組件的其他實例。 · 網(wǎng)絡(luò)：表示為一個有向圖，其中進程作為節(jié)點，而連接作為邊。 · 組件：對于應(yīng)用開發(fā)者，通常可以看作黑盒；當(dāng)要使用傳統(tǒng)高級語言來創(chuàng)建組件或者組件本身是個子圖時，它就是白盒。

基于此類場景，我們設(shè)計一個 schema 來存儲“圖“，兼顧繪圖和邏輯：

Logic schema 由三個主要的實體結(jié)構(gòu)構(gòu)成：

Flow 流程主體， Node 節(jié)點描述，Link 節(jié)點關(guān)系描述：

之后我們對 GPT 的 Prompt 也從這個角度切入 ：

這里我們?nèi)匀皇褂蒙芍R few shot 的方式對 GPT 進行 Prompt，可見低代碼自定義 DSL 這類場景，這種解決方案堪稱萬金油。最終將 DSL 接入一個流程編排工具或引擎，即可完成整個系統(tǒng)的構(gòu)建。

同樣的實踐也可以直接在其他成熟的邏輯編排平臺完成，如 Node-red ，sequence Diagrams 等 。

2.6 低代碼搭建：數(shù)據(jù)可視化技術(shù)與 GPT

數(shù)據(jù)可視化的繪制部分相對比較簡單。按照通常的思路，我們?nèi)匀环治?Prompt 要求：

分解任務(wù)：

· 生成一個柱狀圖，橫軸是 year，縱軸是 count，數(shù)據(jù)是 XXX 。

構(gòu)造 Prompt：

· 指令 —— 生成一段圖表的描述 · 上下文 —— 圖表 DSL 的規(guī)范 · 輸入數(shù)據(jù) —— 當(dāng)前的數(shù)據(jù) · 輸出指示符 —— 輸出一段描述圖表的 DSL

由于 echarts 在互聯(lián)網(wǎng)內(nèi)的流行，GPT 對 echarts 的掌握很好。一般來講低代碼系統(tǒng)都會對其做一定的封裝，所以我們?nèi)匀豢梢允褂蒙芍R few shot 技術(shù)對 GPT 進行 Prompt：

在這里我們使用了自己定義的一個簡單圖表 dsl，可以看出 GPT 毫不費力地就返回過來了。這一類系統(tǒng)在設(shè)計時也基本遵循類似架構(gòu)：

GPT 仍然作為一個服務(wù)，同時當(dāng)前的數(shù)據(jù)以及圖表組件的描述作為生成知識一起傳給 GPT。此類創(chuàng)業(yè)產(chǎn)品也非常多，感興趣的開發(fā)者可以自行搜索。

但 AI 時代，這樣的可視化真的有用嗎？事實上，對于一個能夠使用自然語言接觸 BI 產(chǎn)品的工程師，它的訴求絕對不只是說一句話制作一個圖表那么簡單，它需要讓 AI 輔助它發(fā)現(xiàn)數(shù)據(jù)的異常，并智能地可視化出來，也就是所謂“增強分析”技術(shù)。因此我們對 Prompt 的分解會變成這樣：

分解任務(wù)：

· 展示襪子每年的銷量數(shù)據(jù)趨勢，并分析其中的異常，標(biāo)注在圖表上。

構(gòu)造 Prompt：

· 指令 —— 生成圖表描述 · 上下文 —— 當(dāng)前的庫表字段，趨勢要用什么圖表，如何分析異常 · 輸入數(shù)據(jù) —— 當(dāng)前的圖表數(shù)據(jù) · 輸出指示符 —— 輸出一段描述圖表的 DSL

其中就有兩個難點需要解決：

· 如何判斷數(shù)據(jù)的問題； · 如何根據(jù)數(shù)據(jù)選擇合適的可視化圖表。

幸好之前正好做過相關(guān)的研究這次有了 GPT，很多東西就變得簡單起來。

首先我們可以選擇能夠發(fā)現(xiàn)圖表異常的算法，告訴 GPT， 可以參考：

我們將對應(yīng)的數(shù)據(jù)，以及異常檢測算法 Prompt 給 GPT：

可以看到 GPT 有強大的編程能力，直接就將異常數(shù)據(jù)返回了。因此在可視化之前，可以先讓 GPT 基于內(nèi)置的算法做一次自動化分析，檢測數(shù)據(jù)中的問題。

之后我們需要選擇合適的圖表，此時我們可以接入一個圖表選擇模塊，這個模塊的功能叫“自動化可視化”，自動可視化的概念非常簡單，就是根據(jù)你的數(shù)據(jù)結(jié)果自動選擇合適的可視化方式進行展示，以提升報表整體的可讀性，自動化報表與自然語言查詢、自然語言生成等技術(shù)配合，將大大加快整個分析流程，降低從業(yè)者制作報表的成本。簡單來講自動化可視化就是這張圖的技術(shù)實現(xiàn)：

其 Prompt 方法示例：

最終結(jié)合所有模塊，當(dāng)我們輸入 “ 展示襪子每年的銷量數(shù)據(jù)趨勢，并分析其中的異常，標(biāo)注在圖表上 ” 時， GPT 直接生成了完整的頁面，顯示如下 ：

完美！所以完全不用擔(dān)心 GPT 會干掉你。在這個場景中，我用 GPT 我之前的可視化知識，成功快速實現(xiàn)了當(dāng)時要做幾個月才能實現(xiàn)的增強分析效果，因此當(dāng) GPT 配合工作的經(jīng)驗，將是一把非常好用的利器。

2.7 文檔系統(tǒng)的 GPT 搭建

對于一個開放系統(tǒng)來講，文檔永遠(yuǎn)是最令人頭疼的事情。但我在使用 GPT 的過程中發(fā)現(xiàn)，有一款向量數(shù)據(jù)庫的文檔及其強大：

我第一反應(yīng)，這是怎么實現(xiàn)的？使用 ChatGPT 應(yīng)該如何實現(xiàn)？因此仍然回到原來的思考模式上：

分解任務(wù)：

· 提問：平臺如何支持在線打包發(fā)布

構(gòu)造 Prompt：

· 指令 —— 返回打包發(fā)布的文檔 · 上下文 —— 全部文檔 · 輸入數(shù)據(jù) —— 我需要哪方面的文檔 · 輸出指示符 —— 輸出一段文檔內(nèi)容

但顯然，以上 Prompt 方案有很大的問題：

· token 不夠，把全部文檔喂給 GPT 需要大量 Token。 · 如何判斷用戶的提問跟你的文檔內(nèi)容吻合？ · 我輸入的是中文，這文檔是英文啊，如何搜索？

這里我們就有一種思路，如果我們可以提前把跟用戶提問內(nèi)容有相關(guān)性的文章摘錄出來，讓 GPT 判斷，是不是就可以既節(jié)省 token， 又不需要逐字閱讀？這里就回到一個本質(zhì)問題：如何判斷兩段文字。于是我們可以使用 embedding 技術(shù)。

在自然語言處理和機器學(xué)習(xí)領(lǐng)域，"embeddings" 是指將單詞、短語或文本轉(zhuǎn)換成連續(xù)向量空間的過程。這個向量空間通常被稱為嵌入空間（embedding space），而生成的向量則稱為嵌入向量（embedding vector）或向量嵌入（vector embedding）。

嵌入向量可以捕獲單詞、短語或文本的語義信息，使得它們可以在數(shù)學(xué)上進行比較和計算。這種比較和計算在自然語言處理和機器學(xué)習(xí)中經(jīng)常被用于各種任務(wù)，例如文本分類、語義搜索、詞語相似性計算等。

在中文語境下，"embeddings" 通常被翻譯為 "詞向量" 或者 "向量表示"。這些翻譯強調(diào)了嵌入向量的特點，即將詞匯轉(zhuǎn)換成向量，并表示為嵌入空間中的點。embedding 其實來源于 word2vec 技術(shù)。

舉例來講，你是無法通過像字符串匹配，編輯距離等方式判斷以下三個表達的相似性的。

· "狗咬耗子" · "犬類捕食嚙齒動物" · "我家養(yǎng)了只狗"

但我們?nèi)绻D(zhuǎn)換為向量，如圖所示：

圖片來源：微博@寶玉 xp

可以看到"狗咬耗子"，"犬類捕食嚙齒動物"在向量空間上，通過數(shù)學(xué)計算能夠發(fā)現(xiàn)一定的相似性。因此 embedding 就解決了我們尋找相似文本的訴求。OpenAI 官方也提供了 embedding 工具，官方推薦使用 ada-002。

接下來繼續(xù)考慮，除了數(shù)學(xué)計算與內(nèi)存之外，我們?nèi)绾慰焖儆嬎悴⒋鎯Υ蠖挝臋n的向量呢？這里就需要借助向量數(shù)據(jù)庫技術(shù)。向量數(shù)據(jù)庫能夠存儲文本轉(zhuǎn)換后的向量，并能夠幫助你進行查詢。向量數(shù)據(jù)庫技術(shù)如圖所示：

向量數(shù)據(jù)庫一般工作方式為三個步驟：

索引：向量數(shù)據(jù)庫使用 PQ、LSH 或 HNSW 等算法對矢量進行索引

查詢：向量數(shù)據(jù)庫將索引查詢向量與數(shù)據(jù)集中的索引向量進行比較，找到最相近的結(jié)果

后處理：某些場景下向量數(shù)據(jù)庫從數(shù)據(jù)集中檢索最相近的結(jié)果后，對其進行后處理以返回最終結(jié)果。比如通過使用不同的相似性算法重新排列所有結(jié)果。如圖所示。

在實際使用場景中，我們可以選擇類似 supabase 這一類開源向量數(shù)據(jù)。

庫 https://supabase.com/docs/guides/database/extensions/pgvector

一般來講，查詢向量數(shù)據(jù)庫的內(nèi)容跟 SQL 非常類似，比如尋找跟某段文本向量最相似的五段文本。

SELECT * FROM items WHERE id != 1 ORDER BY embedding <-> (SELECT embedding FROM items WHERE id = 1) LIMIT 5;

向量數(shù)據(jù)庫搜索，本質(zhì)是以向量作為索引，在同義詞/近義詞搜索中有很好的表現(xiàn)，但它不能完全代替普通基于字符串索引的普通搜索技術(shù)，普通搜索和向量搜索的異同。對于這塊知識點，感興趣的用戶可以訪問騰訊云開發(fā)者社區(qū)進一步了解：https://cloud.tencent.com/developer/article/1941250?

基于以上的技術(shù)，我們就可以搭建一個文檔機器人：

整個過程非常簡單，首先將大文本按照一定規(guī)則切開成小塊（換行/字?jǐn)?shù)），之后批量轉(zhuǎn)換為向量存儲起來。之后在用戶搜索時，先在向量數(shù)據(jù)庫中查出相似的文本，然后將這些文本 用戶的 query 發(fā)給 GPT，GPT 來判斷分析并生成回答即可。

同樣我們也可以基于 langchain 快速搭建：

在這里訓(xùn)練了一個生物學(xué)家 GPT 給它灌入了蜜蜂相關(guān)的知識，之后在提問環(huán)節(jié)可以看到它返回了準(zhǔn)確的回答：

以上講的 embedding 向量數(shù)據(jù)庫組合的技術(shù)，本質(zhì)還是生成知識 knowledge generation 技術(shù) ，同樣可以用于以下場景：

· 搜索（結(jié)果按查詢字符串的相關(guān)性進行排序） · 聚類（將文本字符串按相似性分組） · 推薦（推薦具有相關(guān)文本字符串的項目） · 異常檢測（識別相關(guān)性較小的異常值） · 多樣性測量（分析相似度分布） · 分類（文本字符串按其最相似的標(biāo)簽進行分類）

2.8 總結(jié)

我們可以看到，低代碼類系統(tǒng)，大部分都可以使用 GPT prompting 幫助快速構(gòu)建完成，大大加快了低代碼系統(tǒng)的開發(fā)速度，但同時我們發(fā)現(xiàn)，很多技術(shù)仍然是之前使用的，AIGC 只是建立了一個從自然語言到 DSL 的橋梁。AIGC 技術(shù)，一定是建立在一個好的 DSL 上才會實現(xiàn)開發(fā)者層面與機器交互。從 sql 到 gql/swagger 到 ui schema 到 logic schema 一直到 chart，DSL 是人機交互的橋梁，DSL 的編寫才是提效的關(guān)鍵技術(shù)。

· 在使用 GPT 實現(xiàn)低代碼能力時，仍要遵循基本 Prompt 原則：指令、上下文、輸入輸出，其中輸出的格式記得明確。 · GPT 具有強大的學(xué)習(xí)能力，可以降低代碼方方面面的知識都灌輸給它，給它提供完善的knowledge，甚至可以“教”它一些它不懂的專業(yè)知識。 · 對于搭建場景，設(shè)計一個完善的 DSL 是重中之重，Prompt 技巧只是補充，DSL 設(shè)計得好，使用簡單的 few shot 就可以實現(xiàn)大多數(shù)場景。 · 可以通過向量數(shù)據(jù)庫 embedding 的方式，突破 token 的限制，從而實現(xiàn)大規(guī)模文本搜索的功能。 · langchain 是實戰(zhàn)利器，推薦所有想跟自己系統(tǒng)集成 GPT 能力的開發(fā)者使用。

03

GPT 高級使用技巧走馬觀花與總結(jié)

langchain 是不是很簡單，我能不能把 langchain 也低代碼，做 AI 系統(tǒng)的低代碼化？當(dāng)然可以！

之前有個產(chǎn)品叫 ChatPDF，可以快速解析用戶的 PDF 并總結(jié)。根據(jù)上一節(jié)的內(nèi)容我們很容易就可以想到可以通過向量數(shù)據(jù)庫 embedding 解決此類問題。感興趣的用戶可以訪問 GitHub – FlowiseAI/Flowise: Drag & drop UI to build your customized LLM flow using LangchainJS 查看演示 flowwise 如何三分鐘實現(xiàn)一個 ChatPDF 系統(tǒng)。

之前走馬觀花講了那么多 GPT 和低代碼結(jié)合的部分，都沒有離開系統(tǒng)設(shè)計，只是把 OpenAI 作為服務(wù)，那如果我不想用你那一套老舊的系統(tǒng)設(shè)計，用 AI 驅(qū)動整個系統(tǒng)可以嗎，當(dāng)然可以！

如果大家對前沿技術(shù)比較關(guān)注，就可以看到這是 AutoGPT 的實現(xiàn)原理，雖然代碼寫得非常面條，但是實現(xiàn)了匪夷所思的功能，圈內(nèi)也有不少人進行了分析。

AutoGPT 創(chuàng)新的靈感 待完善的代碼的矛盾組合，稱之為 ai-based system，可能未來完全會顛覆傳統(tǒng)的系統(tǒng)設(shè)計。

在本篇中，我們詳細(xì)介紹 Prompt Engineering 的技巧，并為各位分享了如何與低代碼結(jié)合進行開發(fā)實戰(zhàn)。整體來說：GPT 絕不是無所不能，通過 DSL 和 Prompt 的構(gòu)建才能發(fā)揮價值。

而通過工程能力可以大幅度提升 GPT 的效果，因此我們絕對不是“無事可做”。GPT 擁有令人“匪夷所思”的強大的學(xué)習(xí)理解等等能力。工欲善其事 ，君子善假于物也，一個工程師應(yīng)該把 GPT 當(dāng)作自己手里最鋒利的武器。

作者:姜天意

來源:微信公眾號:騰訊云開發(fā)者

出處:https://mp.weixin.qq.com/s/RnBlzFG5F3MTqX8ObF9ivA