不寫代碼也能年薪百萬?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 當作自己手裏最鋒利的武器。

-End-

原創作者|姜天意

技術責編|loyluo

AIGC 時代,前端等技術從業者如何提升自己的不可替代性?歡迎在騰訊雲開發者公衆號評論區討論。我們將選取1則最有意義的分享,送出騰訊雲開發者-手腕墊1個(見下圖)。6月14日中午12點開獎。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章