動手點關注
幹貨不迷路
随着大模型應用開發熱度越來越高，很多工具架構雨後春筍般的出現。随着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編排架構感興趣的同學可以聯系，一起提高和實踐。