不寫代碼也能年薪百萬？Prompt+低代碼開發實戰

導讀

近期 AIGC 狂潮席卷，“前端走向窮途”“低代碼時代終結”的言論甚嚣塵上。事實上 GPT 不僅不會幹掉低代碼，反而會大幅度促進低代碼相關系統的開發。本文會介紹 GPT Prompt Engineering 的基本原理，以及如何幫助低代碼平台相關技術快速開發落地的技術方案。接着往下看吧~

看目錄點收藏，随時漲技術

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 提示工程的總結

1.8 langchain 的介紹

2 低代碼技術

2.1 低代碼技術介紹

2.2 Hello world：AI2SQL

2.3 接口網關：建構 AI 友好的應用

2.4 低代碼搭建：生成知識技術的大規模使用

2.5 低代碼搭建：邏輯編排技術與 GPT

2.6 低代碼搭建：資料可視化技術與 GPT

2.7 文檔系統的 GPT 搭建

2.8 總結

3 GPT 進階使用技巧走馬觀花與總結

01

提示工程

1.1 提示工程基本概念

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

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

在大模型應用的開發過程中，Prompt Engineering 做得好，不僅可以提升回答的品質，也可以限制回答的格式，是以提示工程也能夠幫助大模型傳回的内容更友好地被解讀，這對後續跟其他系統的內建非常重要。

一般來講提示工程包含如下的資訊：

· 指令 —— 希望模型執行的特定任務或指令，文字描述清楚。 · 上下文 —— 可以包含外部資訊或額外的上下文，以引導模型更好地進行響應，在對話類型的 GPT 應用中就是所謂的“聊天記錄”。 · 輸入資料 —— 使用者希望找到響應的輸入或問題。 · 輸出訓示符 —— 訓示輸出的類型或格式，比如可以要求輸出 SQL/JSON。

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

除了直接通路官網之外，各位開發者同時也可以使用 Node.js or Python 直接調用 OpenAI api 。基本思路就是直接引用 OpenAI 的包，然後傳入适當的參數即可。例如 ：

在測試過程中需要關注兩個點。首先是參數 temperature 、top_p。

· temperature（溫度） —— 簡言之，溫度越低，結果越具有确定性，因為總是選擇機率最高的下一個詞。提高溫度可能導緻更多的随機性，鼓勵産生更多樣化或富有創意的輸出對基于事實的問答任務使用較低的溫度值，以鼓勵更加準确和簡潔地回答。對于詩歌生成或其他創意任務，提高溫度值可能會更有益。

· top_p —— 類似的，通過 top_p 調節名為 nucleus sampling 的溫度抽樣技術，可以控制模型在生成回應時的确定性。如果需要準确和事實性的答案，請保持較低的 top_p 值，如果希望獲得更多樣化的回應，請增加到較高的 top_p 值。

另外是模型 text-davinci-003 和 gpt-3.5-turbo 的差別。

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

性能：gpt-3.5-turbo 相對于 text-davinci-003 在性能方面有所提高。根據 OpenAI 的說法，gpt-3.5-turbo 在許多任務中的性能與 text-davinci-003 相當或更好。這意味着，與 text-davinci-003 相比，gpt-3.5-turbo 可以在保持相同品質輸出的同時更有效地完成任務。

1.3 role & token

在調用 OpenAI 的過程中你會看到，消息會傳入一個參數叫做 Role 。

不同 Role 的含義如下：

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

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

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

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

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

另外我們經常說的 Token 是什麼意思呢？

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

在這裡可以很明顯地看到，中文占據了大量 Token，同時換行、标點符号等也會占據 Token。根據 OpenAI 的建議，一個 token 能寫4個字母，或者0.5個漢字。是以4000個 token 可以寫2000字的中文。

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

由于 Token 價格昂貴，是以在一段時間之内，“省 Token ”都是 AI 應用需要關注的重要問題。

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

目前的大語言模型（LLMs）通過大量的資料訓練和指令調整，能夠在零樣本情況下完成任務。

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

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

這樣看，效果就好很多了。這個例子也展現了大模型強大的學習能力。在我們後續要講的低代碼開發中，few shot 技術是非常常用的，如圖：

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

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

可以看出來還是錯誤的。是以 few shot 技術，并不能解決一些數學和推理場景。

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

思維鍊提示（Chain-of-Thought，CoT）是一種用于提高大語言模型推理能力的技術，通過提示模型生成一系列推理步驟來解決多步驟的問題。研究表明，這種技術可以顯著提高模型在數學、常識、推理等方面的準确性。該技術的應用使得模型能夠将多步驟的問題分解成中間步驟，進而更好地了解和解決問題。

比如一個簡單的例子 ：

我們發現 GPT 已經完全懵了。但如果我們加入一句“請一步步思考下”，引導 GPT 按照步驟思考呢？

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

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

事實上，思維鍊遠遠不止“讓我們逐漸思考”這一魔法咒語，它可以僅僅通過 Prompt 就可以讓 GPT 完成非常複雜的任務。下面我們來舉個例子：

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

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

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

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

可以看到 GPT 像人一樣，一步步地思考問題，它首先了解了這個問題，并從工具庫中取出了性别判斷工具，進行判斷後，它又在工具庫中取出了禮物推薦工具，并進一步得到結論。其實這個思路就是非常流行的 Reasoning + Acting ：ReAct 技術，每次讓 LLM 輸出一個目前的【思考】和【要做的動作】，這個動作并不隻限于檢索資訊，可以是調用任何工具，類似 ChatGPT plugin。LLM 通過 few shot 的例子和工具自帶的描述，還有它自己學到的常識來決定何時調用工具以及如何調用工具。

這樣 ReAct 引入了外部工具的概念，讓 LLM 能夠通過這種步進式的方式逐漸思考并調用外部工具，根據結果進一步思考循環。同時也可以僅僅是輸出一步思考，并繼續下去，類似 CoT。在流行的開發架構 Langchain 中就封裝了幫助實作這個思路的一系列工具。

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

生成知識提示是一種利用語言模型自動生成知識并整合到常識推理中的方法。這種方法利用了大語言模型的優勢，将其作為改進常識推理的、靈活的外部知識來源。通過使用通用的提示格式直接從語言模型中生成知識陳述，然後選擇與給定任務相關的知識，可以提高常識推理的準确性。這種方法在語言生成、自然語言推理和問答系統等領域具有廣泛的應用前景。

舉例來講：

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

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

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

當我們有自己的 DSL 想讓 GPT 傳回，這樣就可以借助生成知識+ few shot 技術：

可以看到 GPT 傳回了我們想要的邏輯編排的 DSL。是以生成知識技術結合 few shot 是很多 AI +低代碼技術的基石。後續我們的文章也會大面積地使用生成知識技術。

1.7 提示工程的總結

基本原則：

· 從最基本，最原子的任務做起，将大任務分解成多個子任務。 · 提示内容最好包含：指令、上下文、輸入、輸出格式。 · 對于希望模型執行的指令和任務要非常具體。提示越具有描述性和詳細性，結果越好。最好帶上例子。 · 不要寫太多沒有意義的話。盡量精煉，不要帶前後沖突的提示。

同樣我們也可以使用以下的進階技巧：

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

1.8 langchain 的介紹

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

langchain 的子產品大緻如上所示，簡單介紹一下就是：

· 針對各種 LLM 調用的封裝和緩存。 · 基于文本的處理，包括各種文檔的加載方式（本地/雲），文檔的處理方式，以及各類向量資料庫的連接配接工具。 · 提示詞 prompt 管理，其實可以了解為一個模闆引擎，可以友善地管理我們的各種提示詞模闆、few shot的例子等等，也可以幫助解析 OpenAI 傳回的内容。 · Chains 是 LangChain 中最重要的概念，其實可以了解為一個個有明确輸入/輸出的獨立任務，可以使用 Chain 建構完成某個特定任務的應用程式。例如，我們可以建立一個鍊，它接收使用者輸入，使用 Prompts 相關元件格式化輸入，然後将格式化後的結果傳遞給 LLM，然後将 LLM 的輸出傳遞給後端元件或者其他鍊。我們也可以通過将多個鍊組合在一起，或将鍊與其他元件組合來建構更複雜的鍊。LangChain 實作了很多現成的鍊，比如用于對文章進行總結的 Summarization 鍊，用于對指定文本進行問答的 Question Answering/Question Answering with Sources 鍊，用于對指定知識庫問答的 Retrieval Question Answering/Retrieval Question Answering with Sources 鍊，用于擷取并解析網頁的 LLMRequestsChain 鍊，用于操作關系型資料庫的 SQLDatabaseChain 鍊等。

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

結果如下：

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

02

低代碼技術

2.1 低代碼技術介紹

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

· BI 資料可視化圖表搭建 · CRM 類應用搭建 · 機器學習類應用搭建 · 企業應用搭建 · 店鋪裝修工具 · 物聯網、IOT 建構工具 · Web、Mobile 應用開發 · 工作流系統

同時對于一個完整的 web 應用來講，它會經過使用者界面-接口服務-資料服務等多個子產品，是以這次的低代碼與 GPT 結合，我們也會在整個鍊路上進行嘗試：

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

2.2 Hello world：AI2SQL

寫 SQL 是接口/資料工程師極其頭疼的問題，以這個為開場的原因是 AI2SQL 的場景足夠明确，Prompt 也比較好設計。

分解任務：

· 目标：希望能夠根據需求自動生成 SQL。 · 我需要擷取目前的庫表資訊，之後根據 SQL 知識建構 SQL。

構造 prompt：

· 指令 —— 希望模型輸出 SQL · 上下文 —— 目前在哪個庫，哪個表 · 輸入資料 —— 表結構 - DDL · 輸出訓示符 —— 我希望輸出純正 sql，不想解析一堆内容

于是我們就有如下構造方式：

其思路就是把表結構和使用者輸入傳給 GPT 由 GPT 去編寫。我們目前的可能産品形态如下：

使用者輸入複雜的描述，其中甚至帶有很多對 SQL 文法的要求，GPT 也能快速準确地傳回。

在這個例子中，我們發現建構 GPT 産品時，主要的工作都在組織 prompt 上，是以對 prompt 進行設計可以有效達到目的。同時 SQL 是 GPT 非常擅長編寫的語言。注意我在這裡特别強調了“非常擅長”，後面還會講這個的重要性。最後為了讓 GPT 感覺到我們的表結構，我們利用生成知識（Generated Knowledge Prompting） 這一技巧，讓 GPT 掌握了它不知道的東西。

AI2SQL 這一類系統的架構設計如下：

在實際産品中，我們把 GPT 當作是一個服務，人機互動由産品進行處理，同時通過代理通路 GPT。系統的表結構、中繼資料可以“喂給”GPT 當作語料，但單純傳入 DDL 會嚴重超出 Token， 是以也可以通過對中繼資料的縮減可以減少 Token：

目前這一類的開源産品有 https://github.com/sqlchat/sqlchat 大家可以看看其産品形态。

同樣，langchain 在開發這一類應用時也具有天然的優勢，因為各種包都是現成的，甚至有一個現成的 AI2SQL 的 chain，如圖所示：

我們可以看到利用 langchain 開發 AI 應用的基本思路：選擇一個合适的 chain， 初始化需要的參數子產品，之後 run 即可。

2.3 接口網關：建構 AI 友好的應用

低代碼繞不開的就是接口服務網關了。通常來講，使用者希望能夠通過服務直接擷取需要的資料 /API ，而不是對着一堆接口清單進行開發，是以我們的思路是這樣的：

分解任務：

· 通過目前系統的接口如何獲得資料 · 需要傳回接口或者資料 · GPT 是不知道我的接口的

構造 prompt：

· 指令 —— 希望告訴我如何組裝接口，擷取有效的資料 · 上下文 —— 目前的接口資料 · 輸入資料 —— 使用者需要的字段 · 輸出訓示符 —— 訓示輸出的類型或格式

我們給 GPT 添加一套寵物管理系統，之後看一下效果：

首先我們擷取系統内的接口：

GPT 可以正常傳回并構造好系統 API 給我們。之後我們直接請求資料：

GPT 也可以把資料加工好給到我們。那如何才能讓 GPT 了解系統内的接口呢？答案是使用 Swagger API，是以這類系統可以這樣設計：

我們仍然利用萬能的“生成知識”，首先把 Swagger API 加載到系統中，并首先傳給 GPT 作為知識和上下文。之後使用者的詢問會經過代理服務傳給 GPT，GPT 的學習能力能夠了解很多接口操作，是以 GPT 會首先傳回符合要求的接口以及相關的參數。由于使用者可能需要直接擷取資料，是以我們可以讓系統自己去請求資料，之後可以把傳回資料再給到 GPT， GPT 會幫你加工成“人話”，最終給到使用者，這樣就完成了一個接口網關的 GPT 實作。

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

· 接口資料仍然占據大量的 Token，Swagger API 體積巨大，備援資訊很多。 · 接口的能力會限制服務能力，使用者的需求是枚舉不完的，比如寵物管理系統中，沒有使用者和寵物的關聯接口，提問後 GPT 的反應就很懵了。

是以可以考慮這個思路：在縮減 Token 的基礎上，能夠讓 GPT 提供的接口服務更加靈活。

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

如果我們使用 restful 接口開發一個權限管理系統，需要至少實作以下的接口：

可以看到仍然會陷入無盡的接口開發工作中。但我們如果換個思路，通過另一種對資料模型描述性很強的語言 graphql 來實作呢？首先我們轉換成 graphql 模型，即使不會寫也沒關系，GPT 可以幫助你把 DDL 轉換為 graphql ：

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

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

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

是以，AI 可以認為是一個很成熟的 SQL/GQL/React 等的開發者，卻并不是一個好的 http 接口的開發者。

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

2.4 低代碼搭建：生成知識技術的大規模使用

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

經過上面的實戰，實作此系統的基本思路：

· 利用生成知識技術，設計一個 prompt，使 GPT 傳回自己的 DSL。 · 利用相關的系統 API，将頁面依賴的資料源，系統的元件等資訊加載進來。

利用生成知識技術，設計一個 prompt，使 GPT 傳回自己的 DSL。

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

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

首先我們來構造 prompt：

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

可以看出跟我們想要的預期是一緻的。但一般低代碼産品有幾十上百個元件，把所有的元件文檔塞進去很不現實，是以我們可以前置提供一個元件路由的子產品，根據使用者輸入來判斷需要哪些元件：

這樣我們就可以根據使用者的需求選擇對應元件，整體的系統架構如圖所示：

第二個問題，如何實作根據需求二次編輯 DSL 呢，我們當然可以每次都生成一份新的 DSL，但這樣很容易浪費 Token。由此我們使用了一個有意思的技術叫 JSON patch：

JSON Path 可以描述 JSON 文檔變化. 使用它可以避免在隻需要修改某一部分的時候發送整個文檔内容. 更新檔(Patch)内容的格式也是 JSON.JSON Patch 由 IETF 在 RFC 6902 - JavaScript Object Notation (JSON) Patch 中規範。

舉例來講：

可以看到，JSON patch 能夠比較準确的描述對 JSON 這一 DSL 的操作。由此我們可以設計 prompt 讓 GPT 傳回 JSON patch 和相關修改後的 DSL：

同樣我們也可以限制 GPT 隻傳回 Patch。

2.5 低代碼搭建：邏輯編排技術與 GPT

邏輯編排主要解決能夠通過 FLOW（流程）或有向圖來描述的業務形态，如業務流程編排，接口服務編排，UI 複雜關聯，微服務（FAAS）編排，大資料/機器學習 pipleline 等 。一般來講它的基礎思路基于 FBP，是以我們需要根據 FBP 的思路設計 DSL。

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

FBP 有三大概念，支撐整個架構：

· 程序：元件（component）的一個執行個體，可以跟其他程序并行運作。其他程序可以是同個元件的其他執行個體。 · 網絡：表示為一個有向圖，其中程序作為節點，而連接配接作為邊。 · 元件：對于應用開發者，通常可以看作黑盒；當要使用傳統進階語言來建立元件或者元件本身是個子圖時，它就是白盒。

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

Logic schema 由三個主要的實體結構構成：

Flow 流程主體， Node 節點描述，Link 節點關系描述：

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

這裡我們仍然使用生成知識 + few shot 的方式對 GPT 進行 Prompt，可見低代碼自定義 DSL 這類場景，這種解決方案堪稱萬金油。最終将 DSL 接入一個流程編排工具或引擎，即可完成整個系統的建構。

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

2.6 低代碼搭建：資料可視化技術與 GPT

資料可視化的繪制部分相對比較簡單。按照通常的思路，我們仍然分析 Prompt 要求：

分解任務：

· 生成一個柱狀圖，橫軸是 year，縱軸是 count，資料是 XXX 。

構造 Prompt：

· 指令 —— 生成一段圖表的描述 · 上下文 —— 圖表 DSL 的規範 · 輸入資料 —— 目前的資料 · 輸出訓示符 —— 輸出一段描述圖表的 DSL

由于 echarts 在網際網路内的流行，GPT 對 echarts 的掌握很好。一般來講低代碼系統都會對其做一定的封裝，是以我們仍然可以使用生成知識 + few shot 技術對 GPT 進行 Prompt：

在這裡我們使用了自己定義的一個簡單圖表 dsl，可以看出 GPT 毫不費力地就傳回過來了。這一類系統在設計時也基本遵循類似架構：

GPT 仍然作為一個服務，同時目前的資料以及圖表元件的描述作為生成知識一起傳給 GPT。此類創業産品也非常多，感興趣的開發者可以自行搜尋。

但 AI 時代，這樣的可視化真的有用嗎？事實上，對于一個能夠使用自然語言接觸 BI 産品的工程師，它的訴求絕對不隻是說一句話制作一個圖表那麼簡單，它需要讓 AI 輔助它發現資料的異常，并智能地可視化出來，也就是所謂“增強分析”技術。是以我們對 Prompt 的分解會變成這樣：

分解任務：

· 展示襪子每年的銷量資料趨勢，并分析其中的異常，标注在圖表上。

構造 Prompt：

· 指令 —— 生成圖表描述 · 上下文 —— 目前的庫表字段，趨勢要用什麼圖表，如何分析異常 · 輸入資料 —— 目前的圖表資料 · 輸出訓示符 —— 輸出一段描述圖表的 DSL

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

· 如何判斷資料的問題； · 如何根據資料選擇合适的可視化圖表。

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

首先我們可以選擇能夠發現圖表異常的算法，告訴 GPT， 可以參考：

我們将對應的資料，以及異常檢測算法 Prompt 給 GPT：

可以看到 GPT 有強大的程式設計能力，直接就将異常資料傳回了。是以在可視化之前，可以先讓 GPT 基于内置的算法做一次自動化分析，檢測資料中的問題。

之後我們需要選擇合适的圖表，此時我們可以接入一個圖表選擇子產品，這個子產品的功能叫“自動化可視化”，自動可視化的概念非常簡單，就是根據你的資料結果自動選擇合适的可視化方式進行展示，以提升報表整體的可讀性，自動化報表與自然語言查詢、自然語言生成等技術配合，将大大加快整個分析流程，降低從業者制作報表的成本。簡單來講自動化可視化就是這張圖的技術實作：

其 Prompt 方法示例：

最終結合所有子產品，當我們輸入 “ 展示襪子每年的銷量資料趨勢，并分析其中的異常，标注在圖表上 ” 時， GPT 直接生成了完整的頁面，顯示如下 ：

完美！是以完全不用擔心 GPT 會幹掉你。在這個場景中，我用 GPT + 我之前的可視化知識，成功快速實作了當時要做幾個月才能實作的增強分析效果，是以當 GPT 配合工作的經驗，将是一把非常好用的利器。

2.7 文檔系統的 GPT 搭建

對于一個開放系統來講，文檔永遠是最令人頭疼的事情。但我在使用 GPT 的過程中發現，有一款向量資料庫的文檔及其強大：

我第一反應，這是怎麼實作的？使用 ChatGPT 應該如何實作？是以仍然回到原來的思考模式上：

分解任務：

· 提問：平台如何支援線上打包釋出

構造 Prompt：

· 指令 —— 傳回打包釋出的文檔 · 上下文 —— 全部文檔 · 輸入資料 —— 我需要哪方面的文檔 · 輸出訓示符 —— 輸出一段文檔内容

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

· token 不夠，把全部文檔喂給 GPT 需要大量 Token。 · 如何判斷使用者的提問跟你的文檔内容吻合？ · 我輸入的是中文，這文檔是英文啊，如何搜尋？

這裡我們就有一種思路，如果我們可以提前把跟使用者提問内容有相關性的文章摘錄出來，讓 GPT 判斷，是不是就可以既節省 token， 又不需要逐字閱讀？這裡就回到一個本質問題：如何判斷兩段文字。于是我們可以使用 embedding 技術。

在自然語言處理和機器學習領域，"embeddings" 是指将單詞、短語或文本轉換成連續向量空間的過程。這個向量空間通常被稱為嵌入空間（embedding space），而生成的向量則稱為嵌入向量（embedding vector）或向量嵌入（vector embedding）。

嵌入向量可以捕獲單詞、短語或文本的語義資訊，使得它們可以在數學上進行比較和計算。這種比較和計算在自然語言處理和機器學習中經常被用于各種任務，例如文本分類、語義搜尋、詞語相似性計算等。

在中文語境下，"embeddings" 通常被翻譯為 "詞向量" 或者 "向量表示"。這些翻譯強調了嵌入向量的特點，即将詞彙轉換成向量，并表示為嵌入空間中的點。embedding 其實來源于 word2vec 技術。

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

· "狗咬耗子" · "犬類捕食齧齒動物" · "我家養了隻狗"

但我們如果轉換為向量，如圖所示：

圖檔來源：微網誌@寶玉 xp

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

接下來繼續考慮，除了數學計算與記憶體之外，我們如何快速計算并存儲大段文檔的向量呢？這裡就需要借助向量資料庫技術。向量資料庫能夠存儲文本轉換後的向量，并能夠幫助你進行查詢。向量資料庫技術如圖所示：

向量資料庫一般工作方式為三個步驟：

索引：向量資料庫使用 PQ、LSH 或 HNSW 等算法對矢量進行索引

查詢：向量資料庫将索引查詢向量與資料集中的索引向量進行比較，找到最相近的結果

後處理：某些場景下向量資料庫從資料集中檢索最相近的結果後，對其進行後處理以傳回最終結果。比如通過使用不同的相似性算法重新排列所有結果。如圖所示。

在實際使用場景中，我們可以選擇類似 supabase 這一類開源向量資料。

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

一般來講，查詢向量資料庫的内容跟 SQL 非常類似，比如尋找跟某段文本向量最相似的五段文本。

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

向量資料庫搜尋，本質是以向量作為索引，在同義詞/近義詞搜尋中有很好的表現，但它不能完全代替普通基于字元串索引的普通搜尋技術，普通搜尋和向量搜尋的異同。對于這塊知識點，感興趣的使用者可以通路騰訊雲開發者社群進一步了解：https://cloud.tencent.com/developer/article/1941250?

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

整個過程非常簡單，首先将大文本按照一定規則切開成小塊（換行/字數），之後批量轉換為向量存儲起來。之後在使用者搜尋時，先在向量資料庫中查出相似的文本，然後将這些文本 + 使用者的 query 發給 GPT，GPT 來判斷分析并生成回答即可。

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

在這裡訓練了一個生物學家 GPT 給它灌入了蜜蜂相關的知識，之後在提問環節可以看到它傳回了準确的回答：

以上講的 embedding + 向量資料庫組合的技術，本質還是生成知識 knowledge generation 技術 ，同樣可以用于以下場景：

· 搜尋（結果按查詢字元串的相關性進行排序） · 聚類（将文本字元串按相似性分組） · 推薦（推薦具有相關文本字元串的項目） · 異常檢測（識别相關性較小的異常值） · 多樣性測量（分析相似度分布） · 分類（文本字元串按其最相似的标簽進行分類）

2.8 總結

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

· 在使用 GPT 實作低代碼能力時，仍要遵循基本 Prompt 原則：指令、上下文、輸入輸出，其中輸出的格式記得明确。 · GPT 具有強大的學習能力，可以降低代碼方方面面的知識都灌輸給它，給它提供完善的knowledge，甚至可以“教”它一些它不懂的專業知識。 · 對于搭建場景，設計一個完善的 DSL 是重中之重，Prompt 技巧隻是補充，DSL 設計得好，使用簡單的 few shot 就可以實作大多數場景。 · 可以通過向量資料庫+ embedding 的方式，突破 token 的限制，進而實作大規模文本搜尋的功能。 · langchain 是實戰利器，推薦所有想跟自己系統內建 GPT 能力的開發者使用。

03

GPT 進階使用技巧走馬觀花與總結

langchain 是不是很簡單，我能不能把 langchain 也低代碼，做 AI 系統的低代碼化？當然可以！

之前有個産品叫 ChatPDF，可以快速解析使用者的 PDF 并總結。根據上一節的内容我們很容易就可以想到可以通過向量資料庫 + embedding 解決此類問題。感興趣的使用者可以通路 GitHub - FlowiseAI/Flowise: Drag & drop UI to build your customized LLM flow using LangchainJS 檢視示範 flowwise 如何三分鐘實作一個 ChatPDF 系統。

之前走馬觀花講了那麼多 GPT 和低代碼結合的部分，都沒有離開系統設計，隻是把 OpenAI 作為服務，那如果我不想用你那一套老舊的系統設計，用 AI 驅動整個系統可以嗎，當然可以！

如果大家對前沿技術比較關注，就可以看到這是 AutoGPT 的實作原理，雖然代碼寫得非常面條，但是實作了匪夷所思的功能，圈内也有不少人進行了分析。

AutoGPT 創新的靈感+ 待完善的代碼的沖突組合，稱之為 ai-based system，可能未來完全會颠覆傳統的系統設計。

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

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

作者:姜天意

來源:微信公衆号:騰訊雲開發者

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