從2022年12月以來，chatGPT 的橫空出世掀起了新一波的 AI 浪潮，熱度一直居高不下直到現(xiàn)在。半年時間里，從底層模型 API 到上層應用的生態(tài)逐漸建立，經(jīng)過一輪輪迭代不斷完善創(chuàng)新。本文將結合開源框架和應用程序，從工程師的角度，與大家討論如何對大語言模型進行封裝和應用，并從工程層面解決現(xiàn)有問題，搭建完整可商用的 AI 應用程序。

LLM，Large Language Model，即大語言模型。這個“大”是說參數(shù)量大（通常數(shù)十億個權重或更多），是一種語言模型的概念。為了更深入理解，我們選用OpenAI 公司的 GPT 模型進行討論。本文實驗都在 GPT3.5 的模型上進行（GPT4 太貴了）。

目錄

• GPT 技能點分析
• 如何克服 GPT 現(xiàn)有短板
• 構建完整 AI 應用

SOHU

一、GPT技能點分析

開始之前，先科普一下：GPT 是 OpenAI 訓練的模型，chatGPT 是在 GPT 基礎上構建的聊天應用程序，有很大的區(qū)別。

01

事實

要對 GPT 進行應用，首先要了解清楚 GPT 提供給我們什么。GPT 對外暴露的內容非常簡單清晰：一個聊天接口（https://platform.openai.com/docs/api-reference/chat/create）。當然實際不止一個接口，還包含了一些指定場景，如文本補全、文本編輯。但是我們常用的就是最為通用的聊天接口。

如下圖所示，接口入?yún)⒈靥顓?shù)包括應用的模型名稱、消息列表。消息列表是一個 jsonArray，可以包括歷史消息。模型區(qū)分了消息文本的角色，分為系統(tǒng)、用戶和 AI 三個角色。以便于區(qū)分歷史上下文和設定統(tǒng)一背景。還有一些其他可選字段：比如 temprature 可以控制返回的隨機性，0代表最不隨機，如果完全相同的輸入，大概率給出完全相同的輸出。1代表最隨機；stream 表示是否需要以流的形式返回，就像 chatGPT 逐個文本進行返回；max_token 規(guī)定了單次請求的 token 數(shù)量限制，畢竟 token 就代表了成本。

返回的結果也很簡單：一句 AI 的回復 content ，和本次對話的 token 消耗值。API 如下圖所示：

02

優(yōu)勢

首先來看 GPT 的優(yōu)勢。作為開發(fā)工程師，從應用的視角看，總結出如下幾點：

1. 無與倫比的自然語言掌握能力，在某些角度是超越了我們普通人的。相信大家或多或少領略過，可以很強大地做文本生成、文本理解和文本翻譯等。
2. 某些領域有推理和抽象思維的能力，尤其寫代碼方面。也通過了各種人類的考試，如SAT、美國醫(yī)學執(zhí)照考試、律師資格考試等。注意是某些領域，不完全。
3. 他還有強大的泛化能力，在新的樣本上表現(xiàn)很好，支持了跨各個垂直領域的對話。
4. GPT 有對人類的“理解能力”。心智理論（Theory of Mind, ToM）是指通過將心理狀態(tài)歸因于他人來理解他人的能力，或者更簡單的說，是推測其他人心里在想什么的能力。GPT 在心智理論測試中表現(xiàn)出色。
5. 多樣性和可控性，GPT 模型提供了一些參數(shù)，增強它的多樣性，比如Temprature。
   
   
   

實際上，在人工智能領域是有很多分支的。比如推薦、模式識別、自然語言、計算機視覺等方向。但是 GPT 都能解決嗎？并不是。那么一個主要在自然語言領域的模型，為什么讓大家都有驚艷的感覺呢？我認為歸功于以下兩點：

1. 語言是人類與外部世界交互的主要方式，尤其是在信息時代。盡管 GPT 只是一個語言模型，但這個它在各種領域和任務上展現(xiàn)的能力，讓你覺得他真的“懂”。
2. 原有用到人工智能的領域，大多需要專有的模型。每一種專有的模型之間都有比較大的鴻溝，成本很高，包括學習成本和訓練成本。GPT 如此通用的模型加上如此方便的交互方式，給一些需要 AI 但是沒有能力搞AI的公司或個人，實現(xiàn)了技術的普惠。在很快的產(chǎn)品周期里，就可以將人工智能的進步轉化為真正投入使用的實際產(chǎn)品。對于我們純開發(fā)工程師來說，是“彎道超車”的重要機會。

多提一句，各種優(yōu)勢的來源，就是大語言模型的“涌現(xiàn)”能力。涌現(xiàn)可以用一句經(jīng)典的話來概括：量變引起質變。很多方面的測試任務表明，模型量級在大于10的22次方之后，能力的增幅得到了大幅度的提升。（論文來源：Emergent Abilities of Large Language Models, https://arxiv.org/abs/2206.07682）

03短板

了解了 GPT 的優(yōu)勢，但是作為工程師在應用落地過程中更要關心它不足的地方，并給出解決方案。我總結了幾個主要的點，下面和大家一一分析。

對prompt要求較高

GPT 對 prompt 的要求體現(xiàn)在兩個方面：其一是對于 prompt 表達的敏感性，其二是對 token 的數(shù)量限制。

1. 對于 prompt 表達的敏感性
   prompt 就是提示，也可以簡單理解為向 GPT 輸入的問題。GPT 對于提示的措辭很敏感。這意味著在與 GPT 進行對話時，用戶需要非常準確地表達自己的意圖，并且對 GPT 的思考范圍和返回方式作出明確的規(guī)定。否則 GPT 會天馬行空，無法滿足落地應用確定性的要求。
2. token 的數(shù)量限制
   對于 GPT 模型來說，有很強的 token 數(shù)量限制，輸入和輸出都會算 token 。GPT3.5 的 token 上限是4096，GPT4 是8000或32000，且根據(jù) token 數(shù)計費。具體 token 的計算涉及到 NLP 領域的分詞相關算法，大家可以根據(jù) OpenAI 提供的工具進行查詢：https://platform.openai.com/tokenizer。這個規(guī)定大大限制了我們和 GPT 交流的方式，比如上下文的篇幅限制。下圖是實驗的時候 token 超出限制的報錯。

缺乏規(guī)劃性和工作記憶

首先解釋規(guī)劃性。我們應該都知道貪心法和動態(tài)規(guī)劃的區(qū)別，GPT 模型依賴于生成下一個詞的局部和貪心過程，沒有對任務或輸出進行全局或深入的理解。因此，該模型擅長產(chǎn)生流暢和連貫的文本，但在解決無法按照順序方式處理的復雜或創(chuàng)造性問題方面存在局限性。

比如生成回文詩，嘗試了很多遍都無法正確生成：

再比如經(jīng)典的漢諾塔問題，如果問 GPT 通用解決方案是什么，甚至寫代碼他都可以。但是如果具體提問有三根柱子，五個盤子，如何挪動，很大概率會出錯。

再來看工作記憶，其實就類似人類打草稿，只不過人類的心算就是在心里打草稿。工作記憶關系到模型對于一個整體任務的拆解，和對于中間步驟的處理，所以影響到了復雜任務的處理結果。

這兩個短板其實和人很像，我們人腦很多情況下也是無法用動態(tài)規(guī)劃的思路來解決問題的。我們心算個位數(shù)的加減乘除還可以，但是三位數(shù)及以上的乘除法對一般人的心算難度同樣很大，出錯率會變高。只不過我們的上限比現(xiàn)階段的 GPT 高一些。

沒有記憶能力 : 短期記憶 + 長期記憶

注意這里的記憶和剛才所說的工作記憶不是一回事兒。工作記憶有點類似于內存或者草稿，是模型內部處理問題。而這里的記憶我們分為了短期記憶和長期記憶。

• 短期記憶：因為 GPT 模型是無狀態(tài)的，每次我們調用 OpenAI 的接口它都不知道前后的上下文。所以短期記憶是指單個用戶同一個會話的歷史上下文。下圖是直接調用 OpenAI 接口，并不能產(chǎn)生短期記憶。
  
• 長期記憶：是指一些特定領域的常識和專業(yè)的知識等，需要長期存儲在模型中，影響所有用戶的每一次會話請求。由于 GPT 是一個通用的大語言模型，所以并沒有深入地學習各個垂直領域的專業(yè)知識，在應對專業(yè)問題的時候力不從心。可以從感性上理解為，這是模型的知識盲區(qū)。

無法與外界交互

GPT 是一個語言模型，訓練的數(shù)據(jù)知識截止到2021年。同時現(xiàn)階段他無法使用外部工具，不能建立與外部新知識的連接。如果問 GPT 最近發(fā)生的新聞，他肯定不知道。如果強制要求一定要返回，就算說了回答也不一定正確，這很大程度上造成了對于事實性問題的謬誤。

安全性合規(guī)性問題

人是會被接收到的信息影響的，所以作為涉及到自然語言領域的應用，一定要考慮安全性和合規(guī)性的問題。對于 AI 應用來說分為兩個方面：一方面是對輸入的判定，非法或不合規(guī)的輸入不應該進行響應。另一個方面是對輸出的判定，雖然 OpenAI 已經(jīng)對 GPT 模型本身做了很多安全性的管控，但是畢竟是機器自動生成的，包括國內外規(guī)定不盡相同，所以需要對輸出進行合法合規(guī)的校驗。

非多模態(tài)、不可解釋等問題

GPT 起碼 GPT3.5 目前還是一個專注于自然領域的模型，對多模態(tài)的信息并沒有很好的支持。同時，GPT 模型對于問題解決和對話輸出的內在邏輯并不可解釋，還處于黑盒狀態(tài)，這對應用者控制 GPT 有一定阻礙。

04結論

總體來說，GPT 模型在許多任務中的能力，是可以與人類相媲美的。尤其是自然語言方面，可以說是 unparalleled。但是也存在上述各種實際問題。但是在現(xiàn)在的水平上，已經(jīng)可以作為部分 AI 應用的底層依賴。我們的使命就是通過工程的手段盡可能解決上述各種問題。

二、如何克服GPT現(xiàn)有短板

針對第一章節(jié)所說的問題，我們從工程的角度盡可能地提出解決方案，并結合 langChain 框架現(xiàn)有的功能，展示作為黑盒模型的封裝，應該從哪些方向著手。

01

對prompt要求較高的問題 —— 系統(tǒng)性prompt工程

首先給出一個錯誤的 prompt 示例：

這樣一句簡單的提示，并沒有對 GPT 的思考和返回做任何約束，具有極大的不確定性，對于落地的應用程序是不可接受的。這句話可以作為 chatGPT 的用戶輸入，但是 chatGPT 也已經(jīng)是成熟的產(chǎn)品，用戶的輸入一定不是最終與 OpenAI 交互的 prompt 。

筆者認為，系統(tǒng)性的 prompt 工程要注意以下三點：

1. 必須有清晰明確的指令。
   接下來給出在實驗中用到的真實 prompt ：
   
   如上圖所示，標出了對應的注意點，主要有以下幾點：
   
   

• 要區(qū)分消息角色，system /assistant / user。在 system 中給出整體背景和限定，其他角色可以加入上下文；
• 對輸入輸出格式進行結構化，嚴格限定，便于 GPT 區(qū)分，也便于前置輸入和后續(xù)提取模型返回值并向用戶展示；
• 對任務的具體內容進行清晰詳細的表述；
• 如果必要，給出特殊情況的處理方案；
• 如果必要，限定模型思考的步驟和范圍；
• 給出適當示例；
• 盡可能用英文，因為 GPT 對英文的理解能力還是強于中文的。

2. 要注意 token 的限制，包括最大數(shù)量限制和成本控制。
   token 數(shù)量限制是作為工程必須考慮的問題，甚至是需要優(yōu)先考慮的問題，因為涉及到產(chǎn)品的成本。
   
   
3. 不斷調整 prompt ，并持久化為固定資產(chǎn)。
   實際開發(fā)工程中，不可能一次就確定完美的 prompt ，或者說沒有完美的 prompt 。只有在不斷試錯的過程中不斷調整，并通過各種測試反饋，形成“極優(yōu)解”而不是“最優(yōu)解”。確定 prompt 后，即成為這個應用的固定資產(chǎn)，和應用的代碼一樣，是核心價值與競爭力所在。
   
   

下面挑幾個封裝來看，在系統(tǒng)性 prompt 工程方面， langChain 做了哪些努力。更詳細的請見：https://python.langchain.com/docs/modules/model_io/prompts/

1. langChain 封裝了 prompt 的生成方式，封裝為 PromptTemplate。

1. 實現(xiàn)了參數(shù)的解析，可以手動指定參數(shù)，也可以自動識別 {} 提取參數(shù)
   
   
2. 區(qū)分了不同的角色，分為 SystemMessagePromptTemplate、 AIMessagePromptTemplate、 HumanMessagePromptTemplate，都屬于 MessagePromptTemplate
   
3. 多個 MessagePromptTemplate 可以封裝成為 ChatMessagePromptTemplate ，其中包含了多輪 AI 和 Human 的對話歷史，也是我們最常用的 PromptTemplate

2. langChain 封裝了 prompt 中示例的輸入，封裝為 ExampleSelector。

3. 可以自定義 ExampleSelector ，并添加多個示例

4. 可以根據(jù) token 長度的限制，自適應示例個數(shù)和選擇示例

   如下圖，創(chuàng)建了 LengthBasedExampleSelector ，并規(guī)定最大長度是25。如果輸入很簡短的“big”，則自動附加了很多個示例。如果輸入一個長字符串，則只選擇了一個示例加入 prompt 。

   

   

   

5. 可以根據(jù)本輪輸入內容的相似性匹配，在 prompt 中添加示例

   如下圖所示，在同樣的示例集合中，輸入“worried”一詞 SemanticSimilarityExampleSelector  給出的是 happy 和 sad 作為示例，因為都屬于一種情緒。

   具體的實現(xiàn)方式，是在 SemanticSimilarityExampleSelector 中傳入了用于生成測量語義相似性的文本嵌入，和用于存儲文本嵌入并進行相似性搜索的向量數(shù)據(jù)庫。

   向量數(shù)據(jù)庫的原理，簡單來講。文本添加的時候，通過分詞，再通過特定的神經(jīng)網(wǎng)絡，將文本轉化為一個維數(shù)很高的向量。搜索的時候經(jīng)過同樣處理，通過比較目標詞轉換成的向量與已有向量之間的余弦距離等計算方式，得出最為相近的文本。這是省略了很多細節(jié)的版本，由于不是本文主題，就不過多介紹。但是向量數(shù)據(jù)庫對 LLM 的助力是極大的。

   

02

缺乏規(guī)劃性和工作記憶的問題 —— 思維鏈模式

思維鏈：Chain of Thought，簡稱CoT。是一種推理模式，就是主動要求 GPT 去思考，把一個復雜的問題用推理的方法拆分成多個。實踐上就是我們就是要告訴 GPT，把任務分解。如果模型不能主動分解為正確的步驟，就需要人幫他把步驟顯示地加到 prompt 里去。

比如下圖的示例，提問有多少個質數(shù)，他會先把所有質數(shù)列出來，再進行計數(shù)。而且整個過程是顯式地打印出來的，這會比直接給出答案正確率高很多。

再比如下圖，提問哪種更快，他會先計算出總數(shù)再進行比較。

思維鏈模式是大語言模型應用的一大利器，大大增加了返回的可靠性。

03

沒有短期記憶和長期記憶的問題 —— 外掛記憶

對于沒有記憶能力這個問題來說，我們可以給它外掛記憶。

•  短期記憶
  我們可以用內存或者數(shù)據(jù)庫，將一段會話中的歷史內容放到 prompt 里。這樣回答最新的問題的時候就知道上下文了。有很多種方式，比如多輪記憶都放進去；比如使用 FIFO 避免 token 限制；再比如進行摘要提取，提取的方法有很多，讓 GPT 自己提取就不錯；同樣也可以做基于向量的相似度優(yōu)先記憶。圖示如下：
  
• 長期記憶
  最好的方式是對模型進行微調訓練，讓他真正學習到我們想讓他了解的數(shù)據(jù)或知識。是有幾個問題，首先是數(shù)據(jù)量和數(shù)據(jù)質量的要求都很高，其次是價格太貴，訓練和調用都要根據(jù) token 算錢，還比正常的調用要貴。而且 OpenAI 現(xiàn)在只開放了下圖這四種模型：
  

其他還有辦法嗎？向量數(shù)據(jù)庫又登場了。可以將專業(yè)的數(shù)據(jù)存儲在向量數(shù)據(jù)庫中，在生成最終的 prompt 之前，先從向量數(shù)據(jù)庫找出與原本問題最相近的數(shù)據(jù)，拼接成 prompt 一起投喂給 GPT ，模型會根據(jù) prompt 中包含的信息，給出與私有數(shù)據(jù)或專業(yè)知識更貼近的回答。這是工程角度可以解決的最簡便的方法，類似一個“乞丐版”的小模型。

在基于 LLM 的應用中，向量過于重要，所以最近做向量數(shù)據(jù)庫的項目或公司都有很多資金在投。

04

無法與外界交互的問題 —— 代理擴展工具

與外界交互的問題是最容易想到解決方案的。和計算機相關的事情都可以通過代碼和網(wǎng)絡來完成，只要 GPT 生成命令，我們就可以使用工具幫助它控制。可以進行谷歌搜索，可以與 MySQL 等各種數(shù)據(jù)庫進行操作，可以讀寫文件和操作命令行等。

可以和外界交互之后，GPT 的能力得到了一個非常大的提升。以前很多解決不了的問題，現(xiàn)在都可以解決了，所以我們又有了新的處理問題的范式：ReAct 。注意，這個和前端的 react 沒有任何關系，意思是 Reason + Action。每一次動作要先思考，形成 Thought ，再行動進行 Action，最后觀察形成 Observation。上一輪的觀察結果再去支持下一輪的思考，直至結束。

ReAct 的優(yōu)勢有兩點：

• ReAct 提示語言模型以交錯的方式產(chǎn)生與任務相關的語言推理軌跡和動作，這使得模型能夠動作態(tài)推理，以創(chuàng)建、維護和調整動作的高級計劃（推理到動作），同時也與外部環(huán)境互動，將額外信息納入推理（動作到推理）。總結成一句話就像：“學而不思則罔，思而不學則殆”。
• 除了普遍適用性和性能提升外，推理和動作的結合也有助于提高模型的可解釋性、可信度和所有領域的可診斷性，因為人類可以很容易地區(qū)分來自模型內部知識和外部環(huán)境的信息，以及檢查推理軌跡以了解模型動作的決策基礎。在過程中也可以對模型的想法進行糾偏。

有研究人員對 ReAct 和 CoT 兩種范式進行了對比。總體而言，最好的方法是 ReAct 和 CoT 的結合，允許在推理過程中使用內部知識和外部獲得的信息。通過實驗得出了各種模式下的有效性分析：

ReAct 和 CoT 的區(qū)別是什么呢？基于以上研究，主要表現(xiàn)為以下幾點：

• 幻覺是 CoT 的一個嚴重問題，即錯誤步驟和結論。相比之下， ReAct 的問題解決軌跡更接地氣，以事實為導向，并且值得信賴，這要歸功于外部知識庫的訪問。
• 雖然交錯推理、動作和觀察步驟提高了 ReAct 的基礎性和可信度，但這樣的結構約束也降低了其制定推理步驟的靈活性，導致推理錯誤率高于 CoT 。有一種 ReAct 特有的頻繁錯誤模式，即模型重復生成之前的想法和動作，我們將其歸為 "推理錯誤 "的一部分，因為模型未能推理到合適的下一步動作并跳出循環(huán)。
• 對于 ReAct 來說，通過搜索獲得有效信息是至關重要的。非信息性搜索，占錯誤案例的23%，這使得模型推理脫軌，使其很難恢復和重新表述思想。這也許是事實性和靈活性之間的預期權衡，促使我們使用結合兩種方法的策略。

05

安全性合規(guī)性問題 —— 各階段校驗

對于合規(guī)性問題，我們可以從三個步驟考慮。

1. OpenAI 本身提供了用于校驗的 moderation 接口，而且此接口是免費的，不消耗 token 。如下圖，輸入“I want to kill them”，返回數(shù)據(jù)中 flagged 為 true ，表示這個輸入觸發(fā)了安全規(guī)則。 category_score 中給出了各個方面的詳細打分，violence 最高，表示這個輸入有很強的暴力傾向。
   
2. 由于國內外規(guī)定不盡相同，對于國內的合規(guī)性要求，我們要經(jīng)過嚴格的國內權威平臺校驗。
3. 同時，我們也可以使用 GPT 本身的文本理解能力進行其他方面的判別，如情感傾向等。

06

其他通用工程問題 —— 工程實踐解決

實際應用落地過程中，還會有很多其他的工程實踐問題。比如并發(fā)、不同模塊之間連接、各個環(huán)節(jié)的 mock 、各種測試驗證等，像 langChain 這樣的框架都給出了解決方案。

這里提一個比較有意思的：緩存問題。因為 GPT 響應時間比較長，而且如果相同問題每次都請求， token 消耗也比較貴，所以比如智能客服等場景，建立緩存很有必要。但都是自然語言，比如用戶說“這個房子怎么樣”和“這個樓盤怎么樣”，實際是很相近的問題，但是通過 equals 等判斷是不能命中的。怎么建立自然語言的映射呢？向量！

07

GPT發(fā)展方向及應用工程調整

GPT 等模型是在不斷發(fā)展的，面對他的發(fā)展方向，我們需要不斷調整。比如， token 數(shù)量一定是會放寬的，而且速度會非常快；對于多模態(tài)的支持非常關鍵，科學家們正在不斷努力；外部工具使用的支持，模型本身也在做，而且在 GPT4 上已經(jīng)有部分可以應用了。還有很多方面，在模型本身做了這些之后，上述的一些策略就會失去作用，也需要針對新的特性去進行加強。當然不能說因為會失效所以現(xiàn)在就不做了，工程師就是要在現(xiàn)有工具的基礎上爭分奪秒地為應用到業(yè)務落地而服務。

三、構建完整AI應用

01

我們應該用GPT來做什么

基于剛才的分析和工程優(yōu)化，筆者得出一個思考：GPT 是“人”，不是機器。這涉及到一個很關鍵的問題——我們應該用 GPT 來做什么？

• 首先，它擅長做自然語言相關的 AI 應用；
• 其次，它可以做某些人類做的推理的事情；
• 但是，它難以做人類做的過于復雜和創(chuàng)造性的事情；
• 最后，不應該讓 GPT 做機器做的事情。什么叫機器做的事情？機器的執(zhí)行是嚴密的，是不能出錯的。如果出錯，大概率是寫代碼的人的錯誤。但是人是可能出錯的， AI 也是可能出錯的。舉個例子：一個公司想做數(shù)據(jù)分析，但是沒有 BI 工程師。如果他想向 GPT 尋求幫助，是要直接把所有數(shù)據(jù)塞給 GPT 然后問他具體的問題嗎。當然不是，這樣做 token 數(shù)量會爆炸性增長，且放不下所有數(shù)據(jù)。何況 GPT 的計算能力本來就很差。正確的做法是將數(shù)據(jù)庫的表結構輸入給 GPT ，用一些清晰明了的示例表達清楚訴求，然后讓 GPT 寫好 SQL ，在自己的數(shù)據(jù)庫服務器中運行。這里的數(shù)據(jù)庫就是機器，但寫 SQL 的是 GPT （也就是應該人做的工作）。

02

構建一個AI應用的全流程

最后整理一下，構建一個 AI 應用的全流程。其實整個過程都圍繞著提高確定性。

1. UI 層：用戶界面層，接收輸入返回輸出。
2. 會話處理層：包括對用戶輸入的格式化解析、對話管理等功能。如果要用向量數(shù)據(jù)庫做緩存，就應該在這一層。
3. 數(shù)據(jù)審計層：負責對用戶數(shù)據(jù)進行審計和保護，同時對出入的自然語言的安全性和合規(guī)性進行評估。注意，不僅要評估用戶的輸入，也要評估模型的輸出。
4. 操作編排層：這個層級可以管理和協(xié)調多個語言模型、工具。比如 langChain 對外部工具的使用等。
5. LLM 增強層：這個層級可以對語言模型進行額外的優(yōu)化和增強，比如長期記憶、短期記憶相關的各種操作。
6. LLM 層：最底層是語言模型本身，其實就是對OpenAI 的接口請求。

最后總結下來，在一個完整應用中，GPT 這個黑盒模型就只是右下角的底層依賴，其他全是工程相關的設計和實現(xiàn)。

03

現(xiàn)階段的生態(tài)

如上圖，雖然 GPT3.5 橫空出世并沒有多久，但是已經(jīng)形成了較為完善的生態(tài)體系。最底層模型層，是黑盒模型的 API 調用。上層框架層，各個主流語言都有類似 langChain 的封裝。再上層應用層，搭建了各個實際需求場景下的應用程序。我們做 AI 應用時，可以直接依賴 OpenAI 的模型接口，也可以在框架的基礎上方便地操作，甚至在類似 autoGPT 這種通用應用基礎上搭建。筆者推薦基于 langChain 等框架，既屏蔽了底層通用的工程細節(jié)，相對也有更高的靈活度。

04

對待GPT的正確態(tài)度

最后呢，想明確我們對待 GPT 等大語言模型的態(tài)度：

• 不夸大 GPT 作為一種 AI 模型的效果
• 更不輕視 GPT 幫助 AI 工程應用的能力

祝作為工程師的大家都能產(chǎn)出優(yōu)秀的 AI 應用。

參考資料

1. Emergent Abilities of Large Language Models（https://arxiv.org/abs/2206.07682）
2. Sparks of Artificial General Intelligence: Early experiments with GPT-4（https://arxiv.org/abs/2303.12712）
3. LLM 應用參考架構：ArchGuard Co-mate 實踐示例（https://www.phodal.com/blog/llm-reference-architecture/）
4. ChatGPT 實用指南（ChatGPT 實用指南（二））