GPT-3 API 就這樣悄悄的來了！ 是的， GPT-3 是一種由OpenAI提供的語言模型，它可以通過API接口使用。 以下是使用GPT-3 API的基本步驟： 註冊OpenAI帳戶：請訪問OpenAI網站（https://beta.openai.com/signup/），並創建一個帳戶。一旦註冊成功，您就可以訪問OpenAI的API密鑰。 訂閱GPT-3 API：在OpenAI中，您需要訂閱GPT-3 API，以便可以使用它。訂閱後，您可以獲取API密鑰。 安裝API軟件開發套件（SDK）：您可以在Python、Node.js、Ruby、Java和其他語言中使用OpenAI API。您需要安裝相應的SDK，以便使用它。 獲取API密鑰：在獲取API密鑰後，您可以將其保存在環境變數中，或直接將其添加到代碼中。 連接到API：使用SDK中提供的函數和類，您可以連接到GPT-3 API。 發送請求：一旦您已連接到GPT-3 API，您可以通過向API發送HTTP請求來使用GPT-3模型。 當然我們也不是只講這種大家都知道的幹話，上述這些 chatgpt 都可生出來給你， 以下為重點，再次感謝您可以閱讀到這邊 ...本文開始 ChatML 這次 GPT3 API 的釋出，除了這件事情之外，另外還有 ChatML 以及 fine-tuning 這兩個對於自己來說是個大重點。 ChatML 的釋出，讓我們可以使用 api 像是使用 chatgpt 讓整體上下文開始有了連貫，其中官方也有提供完整的描述。 https://github.com/openai/openai-python/blob/main/chatml.md 在這段過程裡面在 OpenAI 的GPT API中，message 中的 role 指定了對話中發言的角色，可以是 system、user、assistant中的任何一個，具體的差異如下： system： 表示對話接下來這段對話的背景，角色分配，情境。 user： 表示用戶輸入的信息。這可以是文字輸入內容。 assistant： 表示對話系統助手生成的訊息，可以是對前一輪對話的回應、應用程式特定的提示或任何其他形式的輸出。 這些角色的目的是區分不同的訊息類型，以幫助GPT模型更好地理解上下
在 目前待領的團隊 ，小弟有幸 參與到 AI 落地的過程 ，之前也參與過幾次 AI 服務導入的和製作出 AI 產品應用的經驗，這邊就提出些簡單分享，跟大家說說，為何 AI 落地有這麼難 ChatGPT 幾乎成為這幾天大家刷版面的資訊，官方網站其實有提到 Chat-GPT 的參考模式是怎麼進行的，也有提供相關的論文參考， https://openai.com/blog/chatgpt/ ChatGPT 幾乎成為現象級的影響 如果你還沒試用過，我建議你真的玩玩看， https://chat.openai.com/chat 在 AI 落地的階段，有許多工程的過程，還有許多現實需要面對，而這煉成的過程都很容易導致 AI 落地失敗， 更不用說像是 ChatGPT 這種十年磨一劍的應用服務，為什麼驚艷， 中英文，簡中繁中等均能 80% 的機率識別問題及主題對話 回應內容，英文的部分不意外的通順，簡中繁中的部分有些詞語是有做過調整的，這實屬難得。 對於資料上下文關聯度，以及變化形式在主題式的發展下均能有效地回應且呈現。 呈現格式可以以『摘要、表格、條列』等方式進行規劃，同時也可以對文字內容進行一定程度的擴張和收斂。 而要做到這些事情，除了大家所熟知的需要不斷的生成模型，訓練模型，不同的模型疊加上去之外。 同時最難也是最複雜的部分， 『資料工程的處理』 AI 工程的開始 在我們使用任何一套 AI 框架 Tensorflow / pytorch 之後，無一例外地就會以特定問題解決方案，開始採用不同的現成 Model 進行驗證，在一開始對於初始的 example data / init data 都會有不錯的反應。 接下來問題開始... 當我們天馬行空的，不斷將例外，將特定領域情境涵蓋進去的時候，你就會發現這 model 的準確率下降，接下來就是一連串調整參數的開始， 或者是開始進行特例發想的部分，哪些資料是需要踢除的，哪些項目是需要先排開的，哪些資料是對於訓練本身是有影響的，在這個過程中就已經進入 data engineering 的環節中。 source from 資料科學家的工作日常 資料工程的處理 大家所想像的，在建立模型的時候似乎就是不斷地調參數，不斷的運作程式，但在這之前，有 『好多好多好多好多』