制定藍圖：什么樣的API策略能夠確保未來的成功？
如上圖所示，自 2017 年 Transformer 誕生以來，在這個架構的基礎上，以 BERT 為代表的模型和以 GPT 為代表的模型便以極快的速度向前發展。在 2018 年 BERT 誕生后，語言模型便開始重塑 NLP 領域，快速在市場中得到廣泛應用，時至今日這些語言模型依然是 NLP 領域中最被廣泛應用的模型，我們今天看到以 GPT 為代表的各類大模型也是其中之一。
從 GPT 的發展來看，我們可以大致劃分為4個階段，” GPT1 – GPT2 – GPT3 – ChatGPT “，我們可以從這個發展過程中了解到 Prompt 是如何誕生的，以此更好的了解 Prompt。
階段1：GPT-1 誕生在 Transformer 初期，是最早期基于 Transformer 架構打造的模型之一，其采用了和 BERT 相同的范式，通過 “pretrain + finetune” 的方式，首先讓模型在大量未標注的數據上自監督的進行學習，完成預訓練，隨后在應用時再使用有監督數據進行微調，以此讓模型可以適用于各種任務。在這種范式下 BERT 作為雙向模型，可以充分的獲取上下文信息，這讓他在各類任務中都展現出了更精準更穩定的效果，而 GPT 作為單向模型，更擅長生成任務，而由于在這個階段還處于大模型發展的早期，模型規模和效果還沒有成長起來，因此生成的不穩定性使得 GPT 并沒有被大規模應用。時至今日，即便 GPT 已經展現出了令人驚艷的效果，但目前 BERT 類的模型依然是各個業務使用更多的模型。
階段2：相比 GPT-1，GPT-2 第一次提出了全新的范式，當我們擴大模型規模增加訓練數據，讓模型在一個稱為 WebText 的由數百萬個網頁組成的數據集上完成預訓練后，模型不再需要任何監督數據，就可以完成各類任務。在 OpenAI 的 Blog 中我們可以看到，團隊在研究過程中發現，提升模型規模及訓練數據的體量，可以讓模型在 zero-shot 任務中的效果明顯提升，這也在今天被認為是對 scaling law 的第一次發現，雖然當時還沒有誕生智能涌現的現象。也有人解讀，由于 BERT 在各個領域展現出的優異效果，GPT 被迫找到了新的發展方向，也為如今的智能涌現奠定了基礎。由此，GPT 開啟了與 BERT 截然不同的范式，并在新的范式下進行研發，專注模型在 zero-shot 中的效果。
階段3：沿著 GPT-2 增大模型體量和訓練數據規模的思路，GPT-3 使用了 570G 的訓練數據，達到了 GPT-2 的15倍，參數量更是達到了驚人的 1750B，是 GPT-2 的 116 倍。參數量的提升讓 scaling law 大顯神威，讓模型在各個領域中都展現出了令人驚艷的效果，尤其是在 zero-shot 方面，發布會上通過手繪 UI 圖生成前端代碼的例子至今讓人印象深刻。GPT-3 在 2020 年底發布，當時 Transformer 已經經過了4年的發展，BERT 類模型已經在各類應用中被廣泛使用，成為了絕對的主流。然而在這種情況下，GPT-3 的發布也依然成為了領域中最矚目的事件，即便還是有很多問題，但其遠超預期的效果依然令人震撼。
階段4：之后的故事大家都非常熟悉了，OpenAI 在 GPT-3 的基礎上針對不同場景進行了優化，在“多輪對話”的優化中誕生了“ChatGPT”，隨后成為了世界上最火熱的話題，也被認為是 AI 市場化的起點。GPT-3 后的模型不再開源，也沒有論文公開發表，我們只能在 Blog 中獲取一些信息，此處不再進行展開。
最后我們來做個總結，從領域發展的角度我們可以看到 3 種不同的研發范式：
我們可以清晰的看到其中的不同，模型能力的研發越來越不依賴 “訓練” 的過程，而是更大程度的依賴 “預訓練”，依賴 “模型” 本身的能力。在 BERT 所代表的范式下，我們還可以通過 “微調” 在參數層面影響模型。而到了以 “GPT3” 為代表的范式下，也就是我們現在用的大模型，我們不再借助 “微調” 的方式調試模型，而是通過 “輸入” 直接影響 “輸出” 的質量，而如何在應用中得到一個好的 “輸入” 就是 “Prompt 工程” 需要做的事。
以上，我從發展的角度談論了 Prompt 的前世今生，Prompt 是從何而來，為什么我們需要 “Prompt 工程”，希望可以更好的幫助大家了解 Prompt，下面我就來具體談談 Prompt 是什么。
Prompt 譯為 “提示”，與 “zero-shot” 的概念相輔相成，“zero-shot” 就是不通過訓練直接向模型提問的應用方式，而 Prompt 就是指提問的方式。從這個概念上看 “模版” 可能是更合適的稱呼，為什么要用 “提示” 這個單詞呢？
實際上，在剛剛出現這個概念時并沒有 “Prompt” 這樣的稱呼，在早期的論文中其往往會被稱為 “輸入形式（format）” 或 “輸入模版（template）”，但隨著領域的發展，尤其是在 GPT-3 之后，Prompt 的叫法才被逐步確定，大家認同 “提示” 的概念與其作用更加貼切，尤其是在大語言模型的語境下尤為合適，因此逐漸成為了公認的稱呼。
那 Prompt 到底在提示什么呢？從前文中對范式的解讀來看，模型能力的應用越來越向 “預訓練” 的部分傾斜，絕大多數能力應當是在 “預訓練” 階段就構成的，而非通過進一步的訓練構建。而在這種思想的基礎上，Prompt 則像一把解鎖模型能力的鑰匙，讓這些 “預訓練” 階段構成的能力唯我所用。因此，Prompt 就是在提示模型回憶起自己在預訓練時學習到的能力。
我們可以把 “知識” 和 “能力” 進行更進一步的分解，我們更多的是希望使用大模型的能力（理解，總結，生成，推理，e.t.c.），而非知識。與現在越來越火熱的 RAG 技術一樣，我們更傾向于將知識通過外部注入的方式讓模型試用，而能力則完全需要依賴預訓練階段。我們要做的是通過 Prompt 調用大模型的能力去解決問題，讓這些能力表現的更精準，而并非把他當成一個知識庫。如果與人做對比也一樣能得到這個結論，人可以從外部收集信息，并利用自身的智能進行決策，而不是把知識都裝到自己腦子里。Sam Altman 在早期采訪中也提到，把大模型當成搜索引擎的應用方式是錯誤的，智能的體現才是大模型的關鍵。
總結而言，Prompt 就是在提示大模型 “回憶” 起自己的某些能力，在合適的場景下為我們解決問題，這也是 Prompt 工程最核心的理念之一。
除了閉源大模型外，現在小型的開源模型也是應用的主流，也隨之誕生了 LoRa 這樣的訓練技術，可以在較小的成本下完成訓練，那是否就意味著我們可以不再依賴 Prompt，而是像以前一樣通過 “微調” 的范式調試模型呢？
首先是成本問題，Prompt 這種新范式的誕生是由于大模型超大的體量，導致我們無法在較小的成本下對參數產生足夠的影響，即便是開源的較小的模型我們也大多采用 LoRa 這類 “附加參數” 的方式進行微調。因此，對于大模型應用而言，考慮到成本，我們實際上根本無法完成 “訓練” 的過程。
其次是效果問題，如果我們利用 LoRa 這樣的技術進行微調，對于模型參數的影響是很有限的，目前更傾向認為這是一種“對齊”的過程，且還很有可能引發“遺忘”的問題。而如果你希望通過微調讓模型掌握 “知識”，這也不是一個好的思路，這意味著你需要不斷的通過訓練來保持知識的更新，且需要針對不同領域訓練多個不同的模型，同時訓練也并不是一個可靠的過程，相比之下現在“超長上下文的模型” 加 “RAG” 被認為是更可靠的方式。
最后，這也不是一個長期可靠的研發思路，大模型現在驚艷的效果是基于 “scaling law” 的智能涌現，本質還是在應用大模型預訓練階段的能力。無論是“開源”還是“閉源”模型，一定是通過參數量的增加或其他方式，讓模型本身的能力不斷提升，且目前看依然保持指數級的增長。在這種情況下，過于依賴基于任務的訓練是不長久的，因為大模型的本質不是通過訓練構建能力，而是通過輸入調度能力，并在任務維度進行對齊。即便是開源模型的應用，長期來看也不會是以任務維度進行訓練。
因此，訓練與微調并不能取代 Prompt 的作用，且這種范式在眾多方面都展現出了弊端，這也證明了 Prompt 工程的重要性，Prompt 是新范式下應用模型能力的關鍵。
自大模型橫空出世依賴變成為了世界最大的熱點，而 “Prompt 工程” 一直是其中最為火熱的方向之一，早在大模型發展之初很多人便開始呼吁設立 “Prompt 工程師” 的職位，似乎在新的時代下寫好 Prompt，用好大模型，是各個領域最重要的事情之一。在這樣的背景下，Prompt 相關的研究已經積累的十分充足，無論是公司內外都積累了眾多的文章和課程，其中最火的 《Prompt Engineering Guide》，和吳恩達老師的《ChatGPT Prompt Engineering for Developers》，都對 “Prompt 工程” 作出了詳細的介紹，是非常重要的學習資料。那為什么我還要寫這篇文章呢？
這些文章和教程都有一個共通的問題，他們大多是對技巧的羅列，例如《Prompt Engineering Guide》中就羅列了大量技巧，告訴你可以在 Prompt 中 “增加示例”，“增加角色” 等等。但并沒有一個體系化的結構，一個標準化的工作流，告訴大家如何一步步的完成一個 “Prompt”，如何從0開始完成 “Prompt 工程” 的工作。
因此本文嘗試結合我們的研發經驗，體系化的對 “Prompt 工程” 的工作進行總結，得到一些標準化的工作流程，并通過這樣結構化的整理，可以更好的對 “Prompt” 進行管理，讓“Prompt”作為大模型應用的基石，更加可靠有效可擴展。具體而言，我們把從0到1完成一個 Prompt 的過程拆分為了5個步驟。我們利用一套統一的模版，解決最困難的初始 Prompt 書寫的問題，并結合實際應用一步步的進行優化，從而體系化的完成 “Prompt 工程” 的工作。
我們希望通過我們的方法，可以提升 Prompt 工程的工作效率，降低 Prompt 技術的應用成本，并解決 Prompt 難以管理的問題。讓大家都可以從0到1的完成大模型的調試，并讓大模型在各個領域中被更好的應用。
在編寫 Prompt 時，從0到1的編寫出第一版 Prompt 往往是最難的，而基于已有 Prompt 利用各種技巧進行優化則相對簡單。善于解決 “數理問題” 的我們在面對這樣一個偏 “文理問題” 的任務時，就像小時候寫作文一樣難以提筆。如上圖所示，為了解決這個問題，我們使用了一套 “萬能模版”，把一個 Prompt 拆分成了 “立角色 + 述問題 + 定目標 + 補要求” 這四個部分，希望通過結構化的拆分完成這最困難的一步，無論面對什么任務，利用這個模版都可以得到一個“及格”的 Prompt。下面我就具體和大家闡述一下這個模版是如何得到的，為什么他是有效的。
對與 Prompt 的作用和定位已經在第一章中進行了詳細的討論，Prompt 的作用就是根據我們的問題調用模型的能力，我們要通過提問的方式，明確的讓模型知道我們想要什么，我們的目標是什么，從這個基本思想出發，Prompt 應該包含以下幾點：
通這 3 部分的描述我們就把 “要大模型做什么” 描述清楚了，這個想法十分自然，即便不是大模型，而是希望其他人為你完成某項任務，往往也需要通過這 3 部分把問題描述清楚。由于這僅僅是第一版 Prompt，你不需要描述的過于詳細，也不需要使用技巧，只需要用簡練的語言把這幾部分描述清晰即可。以下是幾個示例：
例1：生成產品摘要
問題是什么：你的任務是幫我生成一個產品的簡短摘要。
你要做什么：我會給你產品的需求文檔，及用戶對產品的評價，請結合這些信息概括產品的功能及現狀，為我生成一份產品摘要。
有什么要求：請盡量概括產品的特點，并用輕松幽默的語言風格進行編寫，摘要的字數不要超過50個字。
例2：生成代碼注釋
問題是什么：你的任務是幫我的代碼生成注釋。
你要做什么：我有一段 python 代碼，需要你對代碼的內容進行分析，并為代碼添加注釋。
有什么要求：請結合代碼內容，盡量詳細的補充注釋，不要遺漏，每條注釋請以 “comment:” 作為前綴。
例3：生成測試用例
問題是什么：你的任務是幫我設計一款產品的測試用例。
你要做什么：我會提供給你產品的需求文檔，需要你結合需求的功能描述進行測試用例的編寫。
有什么要求：請結合需求中功能的結構，對測試點進行梳理，并有層級的輸出測試用例，請保證每一個功能的測試點沒有遺漏。
以上是3個簡單的示例，讓大家更直觀的感受這 3 部分的含義，在實際應用中這 3 部分的內容會比例子中復雜的多，此處僅僅為了說明框架的結構，實際內容沒有參考價值，各部分內容的細化會在第三章中詳細展開。
在描述清楚任務后，我們就需要調度模型的能力去完成我們的任務，不同的任務需要用到不同的能力，這往往依賴認為的拆分。我們可以想像，當我們讓一個小白幫我們完成一項任務時，我們需要對任務進行分解，并告訴他每一步需要怎么做，以此來讓他完成一項復雜的任務。對于大模型而言，這當然也是試用的，甚至十分好用，這在第5章的 “CoT” 中還會再次提到。
你當然可以人為的完成這種拆分，再一條條的解釋給大模型，但這種做法并不通用，每個領域都有自己獨特的專項能力，每個任務都有自己的工作流程，因此這種方案并不適合放到一個通用的框架當中。好在大模型能力的調用還存在一條捷徑，那就是“角色”，他就像大模型里自帶一個“能力包”，可以很容易的對模型能力進行調用。每一個角色，都對應著該角色包含的若干能力，我們可以通過設定角色，“提示”大模型使用該角色對應的能力，這與前文“Prompt 到底是什么” 中介紹的想法極其匹配，充分說明是“Prompt” 提示的作用，通過簡單的“提示”調用出大模型預先訓練的能力，這也就是“角色”如此有用的原因。
由此我們就最終得到了我們的 “Prompt 模版”，通過這個統一的框架我們可以完成絕大多數 Prompt 初版的編寫，讓大家在面對各類任務時可以高效的完成從0到1的嘗試，而不必陷入無從下筆的困境。
除了效果之外，對 Prompt 結構化的拆分也對 Prompt 管理提供了很大幫助，我們的 Prompt 庫不再是大段的文本，而是拆分成了4張表“角色表”，“問題表”，“目標表”，“要求表”。通過這種方式我們可以很大的提升 Prompt 的靈活性，并通過動態組合4個元素的方式完成各類任務，這在面對復雜任務，或通過多模型解決問題時，會提供穩定有效的支撐。
在第二章中我們已經明確了 “Prompt 工程” 的第一步，通過我們的框架，在任何任務中我們都可以完成 Prompt 從 0 到 1 的編寫，而這個初版的 Prompt 還只是一個雛形，由于各部分信息還不完整，往往不能達到我們的預期，框架提供了 Prompt 的骨架，還需要我們進一步補充血肉，下面我會對框架的每一部分進行更詳細的分解，通過內容的補全一步步的提升模型的效果。
與第二章中對 “角色” 的理解一致，“角色” 可以被當作大模型的“能力包”或“語法糖”，我們不再需要對每一項能力進行詳細的描述，對任務進行更細節的分解，而是可以通過 import “角色” 的方式，使用這個 “角色” 背后對應的各項能力。那我們該如何設立角色，才是這個“能力包”的正確使用方式呢？
大家都有招聘的經歷，我們可以想象，大模型就是我們要招的人，我們需要設定一個能力模型，來完成我們指定的工作。我們在招聘時通常都會有明確的要求，在JD中要有清晰的描述，這樣才能找到最合適的人選。這與大模型的角色設置一樣，我們要清晰明確的描述這個角色，才能充分 “提示” 大模型，讓大模型知道該調用哪些能力。
我們不妨試想一下在招聘 JD 中，我們會要求哪些內容。通常會包含：工作年份，教育水平，項目經歷，工作技能，榮譽獎項等等。我們完全可以按照這個思路，創建一個語言模版，幫助我們創立角色。
以下是我在使用的角色模版，當然 Prompt 的構造十分靈活，展示的示例僅供參考：
角色模版：
現在你是一位優秀的{{你想要的身份}}，擁有{{你想要的教育水平}}，并且具備{{你想要的工作年份及工作經歷}}，你的工作內容是{{與問題相關的工作內容}}，同時你具備以下能力{{你需要的能力}}
例：心理咨詢師
現在你是一位優秀的 {{心理咨詢師}}，擁有 {{心理咨詢、臨床心理學等專業的碩士或博士學位}}，并且具備 {{多年的心理咨詢工作經驗，在不同類型的心理咨詢機構、診所或醫院積累了豐富的臨床實踐經驗}}，你的工作內容是 {{為咨詢者處理各種心理問題，并幫助你的咨詢者找到合適的解決方案}}，同時你具備以下能力：{{
}}
以上是一個簡單的示例，角色的設置往往需要編寫者對角色有一定的了解，這可以更好的幫助你補全你的模版，但如果你不了解你要設置的角色，不知道這些信息該如何填寫，我們如何可以獲取到這部分信息呢？
其實，我們可以沿著 “招聘 JD” 的思路，通過招聘網站上的招聘信息補全我們的數據。例如，我要讓大模型幫我完成一個 “財務分析” 相關的任務，而我此前對這個領域毫無了解，此時就可以通過招聘網站的職位信息，完成角色的設置：
例：財務分析
現在你是一位優秀的{{財務分析顧問}}，擁有{{財務學、經濟學等專業的碩士或博士學位}}，并且具備{{八年以上的財務分析工作經驗，在不同類型的公司進行過一線基金財務分析，財務報告產出等工作，積累了豐富的實踐經驗}}，你的工作內容是{{對投融資數據進行分析，從管理層的視角設計數據分析框架和匯報體系}}，同時你具備以下能力：{{
}}
以上，就是借助 “招聘 JD” 完成一個完全陌生領域角色的示例，而通常而言角色與任務的關聯性很大，我們對角色的了解越深入，就越能設定出符合預期的角色，即便我們可以采用這種方案進行兜底，但在 “Prompt 工程” 中人的先驗經驗依然十分重要。
對問題的描述由 “述問題” 和 “定目標” 兩部分組成，是 Prompt 中信息含量最大的部分，也是和任務最相關的部分，我們要明確的描述我們希望大模型做的工作，才能讓大模型輸出最符合預期的結果。
除了要描述的清晰明確外，此部分值得強調的就是對任務的分解，這在復雜任務上尤為重要。如果我們需要大模型完成的任務過于復雜，我們則需要先人工對任務進行拆分，并盡量詳細的描述任務中包含的各個部分，這與常用的 “CoT” 的優化方式類似，通過把復雜任務拆分成若干個子部分的方式提升模型的效果。
我們也可以把這種拆分當作一個任務維度的對齊，當我們用概括的語言描述一項任務時，隱含了大量的背景知識和預期。例如，當我們希望大模型幫我們 “制作一份旅游攻略” 時，我們希望他能幫我們 “規劃行程”，“收集信息”，“預定酒店” 等等，而這些信息往往都被包含在 “旅游攻略” 當中。如果我們不明確的對任務進行拆分，大模型就不知道我們的任務具體需要包含哪些部分，因此這個任務維度的對齊十分重要。下面我舉幾個例子：
例1：請幫我制作一份深圳的旅游攻略
請幫我制作一份深圳的旅游攻略，以下是一些基本步驟和思考方式：
例2：請根據需求幫我設計測試用例
請根據需求幫助我設計測試用例，測試用例的設計是一個系統化的過程，以下是一些基本步驟和思考方式：
復雜任務的拆解往往十分有效，不僅可以提升大模型的推理能力，也可以讓大模型的輸出更加貼合你的要求（對齊），但這需要你對當前任務有一定的理解，才可以完成這樣的拆分。但如果你并不熟悉你要處理的任務，如何完成這一步呢。正如前文中表達的觀念，我們希望得出一套通用的方法，讓每個人在面對每個任務時都可以完成 Prompt 的編寫，因此一定需要找到更加通用的方法。
其實，這個步驟你完全可以讓大模型幫助你完成，這類似 Agent 中的 Planning 的思想，讓大模型幫助你拆分一項復雜任務。你可以使用這樣簡單的 Prompt 完成這個任務：
任務拆分 Prompt：
{{你要做的任務}}，需要哪些步驟，該如何思考？
例：希望大模型幫我寫一份基金財務分析報告
輸入：
制作一份基金財務分析報告，需要哪些步驟，該如何思考？
輸出：
制作一份基金財務分析報告是一個涉及多個步驟的過程，需要對基金的財務狀況、投資策略、市場環境等進行深入的研究和理解。以下是一些主要步驟和思考方式：
在進行這些步驟時，你需要保持客觀和批判性的思考。不要只看基金的過去表現，而要嘗試理解基金的表現背后的原因。此外，你還需要考慮到市場的不確定性，因此在做出預測時要謹慎。
以上我們已經通過 “述問題&定目標” 描述清楚了我們的任務，下面我們往往還需要對我們的任務提出一些要求，告訴大模型希望他做什么以及不做什么，這往往與模型在應用中的準確率息息相關。我們常用的要求可能有如下幾種：
讓大模型遵循我們的要求，尤其是在“格式”層面讓大模型的輸出符合我們的規定，對大模型的工業應用十分重要。如何讓大模型更聽話，讓其遵循我們的要求呢？
首先，我們可以把要求放在 Prompt 的最后。大語言模型的本質是在做文本補全，后文的輸出會更傾向于依據距離更近的語境，如果利用 “LIME” 這樣的模型解釋算法分析，距離更近的文本間權重往往更大，這在 Transofrmer 中的 Attention 權重 上也可以清晰的看到。同時，這與大模型在預訓練階段中完成的任務也更加匹配，雖然現在的大模型在 SFT 階段會進行多種任務的訓練，但其本質上還是建立在自監督“文本補全”任務上被訓練出來的，因此其天然的更加遵從離得更近的文本。因此，把要求放在 Prompt 的最后可以很有效的幫助大模型變得更“聽話”。
其次，我們還可以利用大模型的“編程”能力巧妙的讓他更“聽話”。在“立角色”的部分中，我們說“角色”時大模型的能力包，我們可以通過設定角色調用大模型的能力，那有什么能力可以讓大模型更“聽話”呢？我們都知道“大模型”在“編程”方面也展現出了驚人的能力，而這個能力恰好可以將“模糊的文理問題”變成“準確的數理問題”，以此讓大模型更加遵守我們的要求。
具體而言，就是把我們的要求轉換為一個 “編碼” 任務，例如：
請列出10個國家，并以列表形式返回
請列出10個國家，并以列表形式返回。我需要將這個列表引入到 python 代碼中，請嚴格遵守 python 列表的格式進行輸出。
例2：請輸出10個國家，并包含這10個國家的“名稱”，“人口”，“位置”。
請列出10個國家，并包含這10個國家的“名稱”，“人口”，“位置”。我需要將這份數據引入到 python 代碼中，因此請以 Json 格式進行輸出，Json 格式如下：”'{“name”: 名稱, “population”: 人口, “position”: 位置, }”’
例3：請為我輸出一份產品摘要，字數不要超過50個字。
請為我輸出一份產品摘要。我需要將這個摘要引入到 python 代碼中，該變量的大小為50，因此摘要內容不要超過50個字符通過這樣引入大模型“編程”能力的方式，我們可以對模型提出更加精準的要求，并通過將我們的任務轉換為更加準確的編程問題的方式，讓大模型更 “聽話”。
除了輸入的內容外，輸入的格式也很重要，清晰的結構對大模型的效果有很大的影響。除了增加合適的 “空行” 讓結構變的清晰外，我們還可以增加一些“標識符”來區分各個部分，例如：#,<>,```,[],-。同時大模型也具備 MarkDown 解析的能力，我們也可以借助 MarkDown 語法進行 Prompt 結構的整理。
由于“格式”對模型效果的影響，越來越多研究聚焦在了這個方向上，其中 “LangGPT” 得到了廣泛的應用。LangGPT 提出了一種結構化的 Prompt 模式，可以通過一套結構化的模版構造出格式清晰的 Prompt。
例：LangGPT 示例
# Role: 設置角色名稱，一級標題，作用范圍為全局
## Profile: 設置角色簡介，二級標題，作用范圍為段落
– Author: yzfly 設置 Prompt 作者名，保護 Prompt 原作權益 – Version: 1.0 設置 Prompt 版本號，記錄迭代版本 – Language: 中文 設置語言，中文還是 English – Description: 一兩句話簡要描述角色設定，背景，技能等
### Skill: 設置技能，下面分點仔細描述1. xxx 2. xxx
## Rules 設置規則，下面分點描述細節1. xxx 2. xxx
##Workflow 設置工作流程，如何和用戶交流，交互1. 讓用戶以 “形式：[], 主題：[]” 的方式指定詩歌形式，主題。 2. 針對用戶給定的主題，創作詩歌，包括題目和詩句。
##Initialization 設置初始化步驟，強調 prompt 各內容之間的作用和聯系，定義初始化行為。 作為角色 <Role>, 嚴格遵守 <Rules>, 使用默認 <Language> 與用戶對話。然后介紹自己，并告訴用戶 <Workflow>。
我們從 “LangGPT” 的示例中可以看到，他用各種分隔符對 Prompt 內容進行了整理，可以很清晰的看到每部分的作用與區分。我們可以借鑒 “LangGPT” 對分隔符的使用，通過對格式的整理讓同樣的 Prompt 展現出更好的效果。
我們把 “框架細化” 分成了4步，并在每一步中都提出了通用的實踐方法：
至此，我們已經完成了 Prompt 主體部分的編寫，面對任何一個任務都可以通過這套統一的方法完成一個還不錯的 Prompt，并且通過我們對 Prompt 結構化的拆分，我們現在也可以更好的管理我們的 Prompt，并為上層應用提供更好的支撐。
上文中我們已經通過 “Prompt 框架” 和 “框架的細化” 完成了 Prompt 主體部分的編寫，如果我們要在這基礎上進一步優化我們的 Prompt，我們還能怎么做呢？
大模型的推理，根本上還是基于用戶輸入的信息進行推理，我們提供的信息越充分，大模型就能越好的完成推進。因此，要想讓模型的效果更好，我們就需要提供更多的輸入信息。前兩章介紹的“框架”，僅僅包含了 Prompt 中“靜態”的信息，再進一步擴充這部分信息的同時，我們還需要增加因任務而異的“動態”信息，這兩部分信息的補充就是進一步優化 Prompt 的核心思想。
“增加更多信息，讓效果變得更好” 這個想法十分自然，但我們要增加什么信息？如何增加這些信息呢？
為了能在合適的場景下增加合適的信息，勢必要包含 “檢索” 的工作，來根據需要找到合適的信息，而說到 “檢索” 就不得不提名聲大噪的 “RAG” 了。
RAG 技術在近期得到了大量的關注，也漸漸的在各種實際場景中得到了應用。早在 ChatGPT 爆發之初，RAG 就已經得到了不少的關注，大家很早就意識到，想要依賴模型參數注入知識不是可行的做法，要讓模型擁有動態獲取知識的能力，不光對大模型在專業領域中的應用十分重要，對知識的擴展性和時效性在通用領域中也同樣重要。
與人類智能類比，人腦也并不需要把所有知識都放在大腦中，而是可以通過檢索的方式獲取知識，再利用自身的智能進行推理，最終得到結論。當你使用各大廠商的大模型時，你都會發現其包含檢索的步驟，通過檢索獲取的知識對大模型效果十分重要。
而這個檢索背后的技術就是 “RAG”，他可以利用大模型能力通過語義相似度的方式，高效的在文本數據上完成檢索，并把其增加到大模型的輸入當中。
從技術角度看，上圖是 RAG 最原始的結構，也是 RAG 最核心的部分，通過 “Embedding+向量數據庫” 的方式，RAG 可以無監督的對文本數據進行語義維度的匹配，這個思想早在 Word2Vec 時代就已經得到了應用，詞向量就已經可以進行“詞”維度的匹配，而如今大模型則是把這個維度提升到了所有文本數據。
現在已經有了許多可以直接使用的RAG框架，如：LangChain, Milvus, LlamaIndex, Pincone 都提供了開箱即用的方案。而真的要讓 RAG 變得準確好用，還是有很多值得優化的地方，RAG 框架也已經有了多種優化版本。
如今的 RAG 技術已經得到了充分的發展，已經不僅僅局限于語義匹配本身，而誕生出了多種優化版本，也增加了例如 “Rewrite”, “Memory” 這樣的模塊，對于 RAG 技術感興趣的同學可以閱讀此篇survey：https://arxiv.org/pdf/2312.10997
如果我們從應用角度重新看看 RAG ，不難發現其本質就是檢索技術，只是 RAG 利用大模型能力實現了更強的語義維度的檢索。而如果我們不知道怎么做 Embedding，也沒有向量數據庫，不會使用 RAG，我們還可以完成檢索嗎？
答案顯然是肯定的 ，檢索依然是十分成熟的技術模塊了，即便利用最傳統的 “關鍵詞匹配” 也可以計算文本間的相似度，實現檢索的效果。因此，RAG 并不是唯一的技術方案，我們不必困在此處，在條件不足的情況下，我們可以結合場景找到最合適的檢索模式，踐行 RAG 的思想，在輸入中增加更多信息才是最核心的思想。
以上，我結合 RAG 介紹了 “如何增加信息？”，下面我就具體展開 “我們要增加什么信息？”
Few-shot 是無監督學習的一種基本范式，相較于直接提問的方式，One-shot 會提供一條示例，Few-shot 會提供多條量示例再進行提問，以此提升模型的效果。這種提供示例的方法，在不進行專項訓練的情況下可以很好的提升模型的準確性和穩定性，在各類大模型的論文中也可以看到這樣的對比，在各類任務中均可以表現出更好的效果。
對于 Few-shot 而言，最為人詬病的一點就是，當你提供示例后，模型會更多的參照示例回答，而在某種程度上降低了模型本身的思考能力。Few-shot中的示例很大程度提升了模型結果的確定性，而確定性會影響模型展現出的智能水平，特別是對于基于表征學習的大語言模型（Certainty or Intelligence: Pick One!，Yann Le Cun）。
我們應該如何緩解這個弊端呢？除了通過Prompt對模型進行引導外，讓示例變得 “少而有效” 也是很好的方式，通過提供更具參考性的示例，提升每條示例的價值，同時降低示例的數量，可以有效的減少大模型的確定性，并通過這種方式盡量減少示例帶來的負面影響。
為了達到 “少而有效” 的效果就需要借助 “RAG” 的方式完成。通過提升檢索的效果，我們可以更精準的找到與當前任務最相近的示例（或反例），相比靜態的示例而言，這可以很大的增強模型對當前任務的理解，以此提升模型在專項任務中的效果。
除了在輸入中增加 “示例” 外，我們還可以增加“歷史記錄”，為大模型增加 “記憶（memory）” 。“記憶” 可以彌補大模型在知識整合和長期記憶方面存在的明顯短板，而這恰恰是人腦的強項。人腦能持續不斷地整合知識，形成強大的長期記憶，為我們的思考和決策提供支持。
在一次對話內的上下為可以被稱作“短期記憶”，而對于歷史的對話內容則可以被稱為“長期記憶”，在適當的場景調用這些記憶，可以為當前的對話補充必要的上下文，讓模型了解更多必要的背景信息，已在當前任務中表現的更好。這種打破 “上下文長度限制” 的方式，不光在專項任務中發揮效果，在更長的生命周期上，讓模型可以調度歷史的“對話內容”也被認為是模型不斷進化的方式之一。
例如，在上圖的例子中，當大模型進行電影推薦任務時，會調取歷史記憶，確定用戶傾向的電影類型和看電影的時間，這些信息會在模型推理的過程中被加入到輸入中，以此推薦出更符合預期的結果。
我們可以根據每一輪對話的輸入，利用“RAG”技術，動態的從記憶庫中獲取合適的內容加入到輸入中，讓大模型可以跨任務，跨周期的進行歷史數據的獲取。這在通用領域可以進行知識的打通，建立知識間的關聯，在專業領域中面對 “專業概念/專業詞匯” 時，除了依賴人工對專業知識的整理，歷史數據中沉淀的專業知識也是十分有效的信息，通過歷史數據的引入排除對人工的依賴，在使用過程中不斷提升模型對專業知識的理解，這也是很多論文中提到的“通過長期記憶讓模型自我進化”的思想。
“記憶” 是十分重要的大模型推理模塊之一，在 Agent 建設中也扮演了重要的角色，相關的研究還在不斷發展，記憶管理框架（MemGPT）也在工業中得到了越來越廣泛的應用，誕生了許多令人印象深刻的記憶框架。
例如，來自俄亥俄州立大學和斯坦福大學的科學家們給出了一項有趣的研究，希望讓人工智能擁有一個類似人類海馬體的”記憶大腦”。從神經科學的角度出發，模仿人腦海馬體在長期記憶中的作用，設計出一個名為 HippoRAG 的模型，能夠像人腦一樣高效地整合和搜索知識。
他們利用大語言模型處理信息，并用一個知識圖譜來充當“記憶索引”，引入了檢索模型來連接語言模型和知識圖譜。當模型接收到一個新的查詢時，它先從查詢中提取關鍵概念,然后在知識圖譜上應用 “Personalized PageRank” 算法進行概念擴展和檢索，模擬海馬體的聯想記憶能力。最后，模型根據節點的重要性對 passage 進行排序和檢索，進行“模式補全”。實驗表明，這個“記憶大腦”能夠在多跳問答等需要 “知識整合” 的任務上取得大幅提升。
大模型擅長回答通用的知識，但對于專業領域內的知識就顯得沒那么擅長，而對于大模型的工業應用而言，我們往往要處理某個專業領域內的專項任務，這需要大模型理解必要的專業知識和專業方法，并在合適的時候調度它們，以此在工業應用中取得穩定的效果，這也成為了大模型應用最大的問題之一。
專業領域知識的增加對大模型在專業領域上的應用效果至關重要，以我們近一年應用大模型在“測試領域”的實踐為例，我們希望大模型幫助測試同學完成測試工作，例如 “編寫/檢查” 測試用例。
要完成這樣一個相對專業的領域任務，就需要大模型了解足夠的領域知識，例如測試用例的檢查標準，常用的測試方法，各類用例設計方法，以及必要的業務背景知識。為了能讓大模型具備這些支持，我們首先需要與領域專家協作，對測試域相關的知識進行整理，管理好這些知識是大模型應用的基礎。
同時，專業領域的知識與具體任務息息相關。例如，對 “用例檢查” 任務而言，我們的目的是通過用例檢查發現用例中存在的問題，以此減少用例原因導致的漏測問題。因此，我們從目的出發，對漏測問題進行分析，在確定檢查點的同時，結合用例現狀和專業知識進行了問題定義的梳理，通過明確問題定義讓大模型更好的貼合我們的專業領域。
除了上述這些對專業知識的整理，我們還希望動態的增加這些信息，利用 RAG 的方法，結合具體任務動態的從知識庫中引入必要的知識。例如，當用戶的輸入中包含某些專業詞匯或業務概念時，我們需要動態的識別到他們，并對他們進行解釋和補充，這可能需要利用 “插件” 完成，關于“插件”的相關內容我會在“Agent”相關的文章中具體展開，此處不再贅。
無論是 “靜態知識” 還是 “動態知識”，都是通過對專業知識的整理，彌補大模型在專業領域上的不足，我們要將”專業知識“翻譯成”通用知識“ 告訴模型大模型，讓大模型更好的應對專業領域。這一步往往需要領域專家的介入以及對知識的人工整理，這往往是決定大模型效果上限最重要的因素之一。
本章，我們通過進一步增加信息的方式提升模型的效果，并通過兩個問題分析了增加信息的方式：
我們通過框架和額外信息的增加，在輸入層面上完成了 Prompt 的調試，接下來就需要讓模型根據我們的輸入進行推理，而推理本身的效果也是影響模型效果很重要的因此，下面就來展開談談，如何在輸入的基礎上提升模型的推理能力。
2022 年，在 Google 發布的論文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中首次提出，通過讓大模型逐步推理，將一個復雜問題分解為若干個子問題，并一步一步的進行推理，通過這種方式可以顯著提升大模型的性能。這種推理方法就被稱為思維鏈（Chain of Thought）。
區別于傳統 Prompt 通過控制輸入直接端到端的得到輸出，即input ——> output 的方式，CoT 完成了從輸入到思維鏈再到輸出的映射，即input——> reasoning chain ——> output。
自 CoT 問世以來，CoT 的能力已經被無數工作所驗證，如下圖所示，可以看到，相較于直接 Prompt， CoT 對所有的推理任務都帶來了顯著的提升
上圖展示了幾種不同范式下對CoT的實現。對于 Zero-Shot 而言只需要簡單的一句 “Let’s think step by step” 就可以讓模型一步步思考；對于 Few-Shot 而言，除了在提問時引入分步的思想，還提供了逐步思考的示例，不僅可以讓大模型分步思考，還可以通過示例告訴大模型應該如何分步；對于 Agent 而言，我們不光通過修改輸入的方式實現 CoT，而是人為的對任務進行拆分，并通過多輪對話的方式將 CoT 引入到建模過程當中，實現整體任務維度的 CoT。
如上圖所示，CoT 的構造主要以線性為主，對任務進行線性拆分，并按先后順序以此執行。而隨著 CoT 相關研究的不斷發展，思維鏈的形式不僅僅局限在線性的形式，而是衍生出了樹狀，表狀，圖狀等多種類型，其中代表工作有 PoT，Tab-CoT，ToT，GoT-Rationale 等等，下圖清晰的展示了這幾種方法的異同：
CoT 的本質是將一個高度不確定的復雜任務，拆分成若干個確定性較高的子任務，以此提升整個系統的效果和確定性。從 “zero-shot” 和 “few-shot” 范式中，CoT 這是一種推理技巧，而從 “Agent” 范式看，CoT 則更像一種建模思路，這也是 CoT 更核心的思想。當我們面對一個復雜任務時，僅對輸入進行改造是不夠的，我們還需要進行任務維度的分解，用 CoT 的方式進行建模。
例如，如果我需要大模型幫我完成一篇文章，我有兩種做法：
這個例子只是一個簡單的拆分，但也能在效果上得到很大提升。下面舉一個我們實際工作中的例子，我們希望大模型幫助測試同學編寫“測試用例”，對于這個任務而言，最直觀的做法就是把 “需求” 做為輸入，讓大模型根據需求進行測試設計，生成“測試用例”，而需求的復雜程度和不確定性對任務造成了極大的阻礙，因此我們引入 CoT 的思想對任務進行了拆分。
如上圖所示，我們將這個復雜任務拆分成了3個階段（實際上每一階段又會拆分正若干個子步驟）。首先對需求進行分析，整理需求內容，并從需求中抽取功能點及測試對象；然后基于這些功能點進行用例設計，編寫用例集的整體結構，以及每條用例的測試點，即用例標題；最后對用例進行補全，根據需求和用例標題編寫用例的步驟和預期結果。我們通過這種方式，將任務分為了3個階段，無論是從“研發”還是從“應用”角度都為我們的任務帶來了極大的幫助。
從“研發”角度看，當我們把一個任務分解為多個階段后，我們很容易的可以找到其中 “最簡單” 的階段。例如，在上圖的鏈路中，對需求的分析相對困難，而 “根據標題生成步驟” 則相對簡單，以此做為切入點可以在前期為我們避免最復雜的“需求”數據，讓我們可以快速達到可應用的效果。這種研發思路并非僅對這個任務有效，對于前文中提到的 “文章編寫” 的例子，“輸出大綱” 和 “依據要求進行調整” 顯然是更簡單的子任務，率先在從這些點切入，也可以幫我們更快的取得成效。
從“應用”角度看，即便大模型展現出了極為驚艷的效果，但在應用中的短板也十分明顯，大家也逐漸看到了大模型能力的限制。基于對現有模型能力的判斷，“人機協同（copilot）” 被越來越多人認為是更好的方式。而 “人機協同” 是一個共同生產的過程，如果大模型僅僅是端到端的完成一個任務，人很難介入的，而當我們進行了任務維度的拆分后，每一個子任務都可以與人協同。例如，在“用例生成”中，人可以先對需求進行分析，再讓大模型進行用例設計，通過這種人機協同的應用模式，我們可以讓大模型在應用中更快速的落地。
前文中，我們已經介紹了 Prompt 調試的主要步驟，也是一條標準的工作流，可以幫助我們從 0 到 1 的完成 Prompt 的編寫和調試：“Prompt 框架” - “細化框架” - “增加更多信息” - “CoT”。而正如開篇時提到的，Prompt 相關的技巧已多如牛毛，并且一直隨著模型的迭代而不斷更新，我們前文中講的是 “Prompt 工程” 的主要步驟和思想，而在其之上，還是有不少技巧可以進行進一步的優化，下面我選擇其中最重要的幾點展開聊聊。
除了調整模型的輸入外，大家一定注意到了大模型還有2個參數可以調節：溫度（Temperature),Top-P。這兩個參數也與大模型效果息息相關，控制著大模型輸出的確定性。大模型的本質是在 Token 的概率空間中進行選擇，依據概率選擇接下來要輸出的 Token，而這 2 個參數就是在控制這個過程。
Temperature（溫度）是一個正實數，用于控制生成文本的隨機性和多樣性。在生成過程中，模型會為每個可能的下一個詞分配一個概率，而調整溫度，則可以影響這些概率分布的形狀。當溫度接近 0 時，輸出文本會變得更加確定，模型更傾向于選擇具有較高概率的詞，這可能導致生成的文本質量較高，但多樣性較低。當溫度接近 1 時，輸出文本的隨機性增加，模型會更平衡地從概率分布中選擇詞匯，這可能使生成的文本具有更高的多樣性，但質量可能不如較低溫度時的輸出。溫度大于 1 時，輸出文本的隨機性會進一步增加，模型更可能選擇具有較低概率的詞。
Top-p 是一個 0 到 1 之間的實數，表示另一種生成策略，它根據概率分布的累積概率來選擇候選詞。具體來說，模型將根據詞匯的概率對其進行排序，然后選擇一個子集，使得這個子集的累積概率至少為 p。當 p 接近 1 時，生成的文本將包含幾乎所有可能的詞匯，導致較高的隨機性和多樣性。當 p 較小時，生成的文本將僅包含具有較高概率的詞匯，降低隨機性并提高輸出質量。然而，過低的 p 值可能導致模型過于保守，生成的文本過于重復或單調。
為了了便于理解，我們可以舉一個抽象的例子，幫助大家理解。假設我們有一個語言模型，它正在預測句子中的下一個單詞。我們輸入的句子是我喜歡吃蘋果和____，那么模型可能會為香蕉分配 0.4 的概率，為橙子分配 0.2 的概率，為鴨梨分配 0.2 的概率，為白菜分配 0.1 的概率，為蘿卜分配 0.1 的概率。
假如我們設定Top-P = 0.8，則我們會按照概率大小選擇盡可能多的詞，并讓概率的總和小于0.8。因此我們會選擇 “香蕉”，“橙子”，“鴨梨”，而如果再加上 “白菜” 則累計概率會超過閾值 0.8。
最后模型會在 “香蕉”，“橙子”，“鴨梨” 中隨機選擇一個單詞。在這個例子中，我們有 50% 的幾率會選擇 “香蕉”，25% 的幾率選擇 “橙子”，25% 的幾率選擇 “鴨梨”。這一步中的概率還會被 “Temperature（溫度）” 所影響。
總結而言，溫度（Temperature）和 Top-p 是對模型輸出確定性的控制，我們可以根據具體的應用場景進行調試，當我們需要模型確定穩定的產出結果是，我們可以設置更高的確定性，以提升模型應用的穩定性。但當我們需要模型提供多種結果，或希望讓模型更具想象力時，我們則需要設置更高的多樣性。
我們可以使用各種技巧優化我們的 Prompt，那大模型可不可以幫我們自動優化我們的 Prompt 呢？這個研究方向自 ChatGPT 以來就一直得到大量關注，且在大模型時代得到了越來越多的應用，他不光可以對已有的 Prompt 進行優化，還可以自動找到一些 Prompt 語句，神奇的產生通用的效果。例如，在 “Zero-Shot COT” 里的那句 “Let’s think step by step”，谷歌就曾通過這種方式找到了更好的一句：“Take a deep breath and work on this problem step-by-step”，讓GSM8K的結果直接從 71.8% 上升到了 80.2%。這個研究方向還在快速的發展當中，已經誕生了多種算法，下文將挑選其中最經典的幾個算法，希望可以讓大家更好的了解這個領域。
APE 是其中最經典的算法，核心思路是：從候選集中選出若干較好的 Prompt，再在這些 Prompt 附近進行 “試探性搜索”。其過程為，先通過大模型生成若干 Prompt，再在訓練集上打分，保留較好若干條的 Prompt，最后在這些高分 Prompt 附近進行采樣，模擬 “Monte-Carlo Search” 的過程，優化得到最理想的 Prompt。
APO 算法則是引入了 “梯度下降” 的方法，通過訓練集得到當前 Prompt 的梯度，在應用“梯度下降”的方式得到新的 Prompt，最后與 APE 一樣進行采樣，得到最終的 Prompt。
OPRO 算法則是更復雜的利用 LLMs 作為優化器。與傳統的迭代優化技術不同，OPRO 采用自然語言描述和指引優化任務，通過 LLMs 的指導，結合先前找到的解決方案，不斷生成更新的策略。
如本文開篇提到的，本文嘗試結合我們的研發經驗，體系化的梳理 “Prompt” 相關工作，嘗試用一套通用的框架，對 Prompt 工程的相關工作進行梳理和總結。但也正如本章的用意，在統一的框架之外還有各種技巧，可以起到錦上添花的作用，這部分技巧無論是公司內外都積累了很多文章，且由于技巧過多，因此在本文沒有展開討論，此處總結其中的 3 個重要方法，在我們的實踐中起到了不小的作用：
對于這部分技巧，如果有機會將用一篇單獨的文章介紹，本篇文章不再展開，如果大家對這些方法感興趣可以學習傳播最廣的 Prompt 知識庫，Prompt Engineering Guid。
本文一直在是希望向大家介紹 “Prompt” 調試的方法，而 “Prompt 調試” 本質上是為了讓模型在任務中有更好的效果，而這就涉及到效果的評估，當我們對 “Prompt” 進行了一次更新，我如何判斷模型效果是不是變好了呢？對 AI 技術有所了解的同學想必對這部分十分熟悉，但對于沒有接觸過 AI 技術的同學，還是有必要補充一些和模型調試相關的基本知識，輔助大家更好的完成模型調試的工作。
要判斷大模型的效果，首先需要有數據作為支撐，其次還需要確定衡量效果的指標。計算大模型在測試數據上的指標是判斷大模型效果的依據，這里我提供一些常用的指標，用來衡量大模型在各類任務中的效果。
分類問題
生成問題
對于專項任務而言，每個任務在調試前都需要準備自己獨立的數據集，包含與每一個輸入對應的預期結果，不同的指標代表用不同方式評估 “預期結果” 和 “實際結果” 的相似度。而對于一些通用的 NLP 能力而言，業內也有一些開源數據集，被用于衡量模型各項通用能力的效果（文本摘要，語義理解，對話，e.t.c.），如果你正在調試一項通用能力，或沒有足夠的任務數據，就可以利用這些數據集，我在這里也挑選其中一部分做一個簡單的介紹：
英文數據集
中文數據集
本文嘗試結合我們的研發經驗，體系化的對 “Prompt 工程” 的相關工作進行了梳理，得到了一個標準化的工作流，幫助大家可以從0到1的完成一個 Prompt 的書寫和調試，并通過這樣結構化的拆分，增強對 Prompt 的管理。我們的工作流可以分為 5 步，對應于文章 “第2節-第6節” 的 5 個章節：
我們認為在一個大模型工程中，“Prompt”應該起到基石般的作用，有效穩定可擴展。對于一個大模型工程師而言，“Prompt” 也是必備的基礎技能，希望可以通過這篇文章幫助大家更簡單的上手 Prompt 的相關工作，讓每個人都能編寫 Prompt，人人都能成為 Prompt 工程師。
本文通過對 “Prompt” 工作的拆分和總結，體系化的介紹了 “Prompt 工程” 的工作方法，提出了一套通用的框架和工作流，幫助大家完成 “Prompt” 的編寫和調試工作，這套方法也已經在我們的實際工作中應用落地。
從技術角度講，大模型相關的研發工作可以大體分為3部分 “輸入” – “推理” – “訓練”，本文聚焦在單模型的 “輸入” 部分，對 “Prompt 工程” 相關的技巧進行了探討。但僅僅在輸入層面進行調試是遠遠不夠的，推理部分也是影響大模型效果的關鍵一環，“Agent 技術”，“多模型協作”，“模型調度” 等等話題對大模型效果有著至關重要的影響。
因此，后續我會聚焦在模型推理的部分，以 “Agent 技術” 作為重點，展開討論“模型推理”，“模型調度” 相關的話題，對“LangChain”，“Dify” 等推理框架，以及 “Agent” 常用框架進行探討，依然從應用角度出發，探討我對這些技術的思考，以及如何在應用中快速落地。
以下是一些大模型API可以幫助開發者快速應用AI功能：
作者｜劉琮瑋
原文轉自 微信公眾號@騰訊云開發者
