大模型應用開發進入新階段，微軟、langchain 有了新動作

隨着大模型應用開發熱度越來越高，很多工具框架雨後春筍般的出現。隨着 llama2，chatGLM2 等大模型開始許可商用，讓更多更多中小廠商和工程師背景的開發者可以參與到這場 AI 盛宴，生態上下游開發者的規模將會爆發式增長，大模型應用開發進入第二階段，如何更快，更高效的把大模型應用落地到生產，與現有系統整合或者改造成了聚焦的重點。

在第一階段，以 langchain 和 llama-index 爲代表的集成開發框架，能夠快速構建一個 LLM 原型應用，獲得了大量開發者的青睞。但它們距離生產仍然還有很大的 gap 需要跨越，比如它僅是一個 python 程序，聚焦於大模型任務本身，缺少一些通用性能力，如如何擴展，如何部署，也缺少相關工具配套支持，還有大模型應用通常還需要和傳統應用，特別是大數據應用進行整合，那麼這些框架裏也缺少一體化的能力支持。

如果 langchain 類比 tensorflow 這樣的框架，那麼顯然，在此基礎上，應該還需要更高階，更易用的，能力更全面的集成編排工具將應用粘合起來，高效率的工作。

在目前市面上有大量的 langchain 可視化的工具在嘗試做這樣的工作，如 flowise，langflow 等。還有以 prompt 可視化爲起點後來發展爲 AI app 開發工具 dify，但它們整體開起來還是工業化程度不高，更聚焦於小的大模型 APP 開發，缺乏原型到生產的突破性變化。

今天介紹巨頭和新生代代表在 LLM in Production 領域的兩款代表性產品，一個是微軟 Azure 提供的大模型應用開發方案，第二是 langchain 剛剛（7.18）發佈的大模型應用開發平臺 LangSmith。

1）微軟 llm pipelines

對於 AI 應用來講，數據與應用編排和特徵與模型工程是核心，配套在其之上需要有相關大數據，雲原生等基礎設施的配套。工程師可以基於 pipeline 爲骨架，快速搭建一個可變靈活的 AI 應用。在 AI1.0 時代這種模式可以說是最佳實踐，google，亞馬遜，微軟等都有自己的 pipeline 工具，也有一大堆開源產品支撐。到了 AI2.0 時代，這種實踐經驗對於有了過去基礎的公司來講，繼續沿用這一思路，將能力進行二次擴充，是非常不錯的選項。不僅能力上可以複用，開發者習慣也可以保留，原來的 AI 應用開發者在簡單熟悉後就能夠進行大模型應用開發。

從架構圖上看，微軟提供了離線 pipeline 和異步在線 pipeline，在 pipeline 構件層面增加了諸如 OpenAI Service，Cache 之類的服務組件及 doc 拆分等常見任務模版，以及 langchain，Semantic Kernel 等開發框架的封裝。開發者無須關注底層細節，結合自己的業務流程構建 pipeline 即可。

更多細節：https://learn.microsoft.com/en-us/azure/architecture/guide/ai/language-model-pipelines

2）langsmith

langchain 公司提供的一個用於調試、測試、評估和監控 LLM 應用程序的統一平臺。

在其官方發佈博客提到這麼一句：

langchain 開發的初衷是讓開發者能夠快速的構建一個 LLM 原型應用，langchain 很好的解決了這個問題，可以簡單 5 行代碼就能構建一個 LLM 應用，但是它有一個問題就是，它仍然需要大量工作才能將這個原型變爲生產環境應用。而 langsmith 就是爲了減少原型到生產的 gap 而設計的。

筆者簡單瞭解了一下這個產品，它的設計思路與微軟還是有一些區別，算是爲了達到可以生產化的另一個條路。由於 langchain 本身沒有微軟在 1.0 時代的積累。它在設計上更加圍繞 LLM 應用本身，是一個相對平臺產品的思路來開發。微軟則更多傾向於是一個腳手架工具。前者更簡單，更單一，而後者更靈活，更強大。

另外，langsmith 關注了一個目前大模型的一個投入生產比較棘手的問題，就是大模型 prompt 的可讀性，可調式性以及大模型輸出的不穩定干預。目前微軟等廠商也提供了 guidance，Guardrails 等工具庫來解決，但集成度不高，有使用門檻。

langsmith 團隊結合自己的經驗及訪談，總結當前 LLM 應用開發的幾個痛點。

  1. 瞭解 LLM 調用的最終提示到底是什麼（在所有的提示模板格式化之後，這個最終提示可能會很長，而且會被混淆）

  2. 瞭解 LLM 調用在每一步（在以任何方式進行後處理或轉換之前）返回的具體內容

  3. 瞭解調用 LLM（或其他資源）的確切順序，以及它們是如何串聯在一起的

  4. 跟蹤 Token 使用情況

  5. 管理成本

  6. 跟蹤（和調試）延遲

  7. 沒有良好的數據集來評估其應用程序

  8. 沒有可用於評估其應用程序的良好指標

  9. 瞭解用戶如何與產品互動

langsmith 圍繞這些痛點，提供了從 debug，Testing，Evaluating，Monitoring 的一整套完成功能支持，並且具有低代碼可視化的操作界面，上手門檻比較低。以前來自四個環節介紹來自官方 blog：

Debugging

LangSmith 可讓您全面瞭解事件鏈中每一步的模型輸入和輸出。這使得團隊可以輕鬆嘗試新的鏈和提示模板，並發現意外結果、錯誤或延遲問題的來源。我們還將公開延遲和令牌使用情況，這樣您就可以確定是哪些調用導致了問題。

Testing

我們看到開發人員要解決的一個主要問題是 " 如果我更改了這個鏈 / 提示，會對我的輸出產生什麼影響？要回答這個問題，最有效的方法是策劃一個你所關心的示例數據集，然後在這個數據集上運行任何更改過的提示 / 鏈。首先，LangSmith 可以讓您輕鬆地根據軌跡創建這些數據集，或者上傳您手動策劃的數據集。然後，您就可以在這些數據集上輕鬆運行鏈和提示。

Evaluating

LangSmith 與我們的開源評估模塊集無縫集成。這些模塊有兩種主要的評估類型：啓發式和 LLM。啓發式評估將使用類似於 regexes 的邏輯來評估答案的正確性。LLM 評估將使用 LLM 進行自我評估。從長遠來看，我們非常看好 LLM 輔助評估。這種方法的批評者會說，這種方法概念不清，而且實際成本很高（時間和金錢）。但是，我們已經看到頂級實驗室提出了一些非常令人信服的證據，證明這是一種可行的策略。而且，隨着我們共同對這些模式（包括私有模式和開源模式）進行改進，以及使用變得更加普遍，我們預計成本將大大降低。

Monitoring

雖然調試、測試和評估可以幫助您從原型到生產，但工作並不會在發貨後就停止。開發人員需要積極跟蹤性能，並根據反饋優化性能。我們經常看到開發人員依靠 LangSmith 來跟蹤應用程序的系統級性能（如延遲和成本）、跟蹤模型 / 鏈性能（通過將反饋與運行關聯起來）、調試問題（深入研究出錯的特定運行），並廣泛瞭解用戶如何與其應用程序交互以及他們的體驗如何。

可以看出，langsmith 仍然聚焦於 llm 應用內部，有點類似於一個機器學習平臺，對於一個複合應用來講，涉及並不多，並且也缺少一些生產部署監控層面的能力支持，它需要搭配其它工具來一起使用，換而言之，微軟和 langchain 整合在一起或許是一個很好的點子。LangSmith 現在處於封閉測試階段。想要試用可以點此註冊：https://smith.langchain.com/

更多參考：https://blog.langchain.dev/announcing-langsmith/

小結：

分工，分層是技術普及，效率提高的前奏，筆者相信，未來這類平臺或框架的需求將會爆炸式的增長。web 開發時代有 spring，雲原生時代有 k8s，AI 時代會有 AI 時代的工具鏈支持。這些工具鏈的成熟也將會真正對於 AI 及大模型落地帶來加速。

對於 AI 編排框架感興趣的同學可以聯繫，一起提高和實踐。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/GS-Xmc3u3XqyoZ-mou5J2w

猜你喜歡