譯者 | 布加迪

審校 | 重樓

51CTO讀者成長計劃社群招募，咨詢小助手（微信號：CTOjishuzhan）

微軟的Semantic Kernel SDK讓用戶更容易管理復雜的提示，并從GPT之類的大型語言模型獲得精準的結果。  

乍一看，把GPT-4之類的大型語言模型（LLM）做入到代碼中似乎很簡單。API是單一的REST調用，獲取文本后基于輸入返回響應，但實際情況比這要復雜得多。將API視為域邊界（domain boundary）可能更好，您在其中交付的提示定義了模型用于生成輸出的格式。但這里有一個關鍵點：LLM可以很簡單或很復雜，取決于您想讓它多簡單或多復雜。

當我們將AI模型做入到代碼中時，其實跨越了兩種不同計算方式之間的界限，就像為量子計算機編程酷似設計硬件一樣。在這里，我們描述了模型應該有怎樣的行為，期望它的輸出采用由提示定義的格式。在量子計算中，像Q#語言這樣的構件提供了一座架起傳統計算和量子計算的機梁，我們需要工具來包裝LLM API，并提供管理輸入和輸出的方法，以確保模型始終專注于我們已定義的提示，并確保輸出依然準確。

這是需要強調的重要一點：我們與LLM的互動方式與傳統編程大不相同。我們需要的是Q#對等體，即在不同域之間轉換的高級抽象，從而幫助我們獲取數據后用數據來設計提示，同時提供一種方法來管理調用之間的必要上下文，以免耗盡會話中的可用token，同時仍保持輸出基于源數據。

1、Semantic Kernel介紹

幾周前，我研究了微軟的第一個LLM包裝器：開源的Prompt Engine。此后，微軟發布了一個更龐大更強大的C#工具：Semantic Kernel，用于處理Azure OpenAI（以及處理OpenAI自己的API）。它也是開源的，可以在GitHub上獲得，還有一些示例應用程序可以幫助您入手。Python版本的Semantic Kernel也在開發中。

這個名字的選擇饒有意思，因為它表明對LLM的用途有一番更好的理解。Prompt Engine側重于管理API的輸入，而Semantic Kernel的范圍更廣，專注于自然語言的輸入和輸出。微軟將其方法描述為“面向目標”，使用來自用戶的初始請求（“ask”）來指導模型，協調與模型相關的資源的傳遞以實現請求，并返回請求響應（“get”）。

所以稱Semantic Kernel為內核有其道理。它就像LLM API的操作系統，接受輸入，通過使用模型來處理輸入，然后返回輸出。內核充當協調器的角色是這里的關鍵，因為它不僅能夠處理當前提示及其關聯的token，還能夠處理記憶（鍵值對、本地存儲以及矢量或“語義”搜索）、通向其他信息服務的連接器以及混合提示和傳統代碼的預定義技能（想想LLM函數）。

Semantic Kernel工具提供了更有效的方法來構建和使用包裝Prompt Engine所需的構件類型，從而簡化了可能變得相當復雜的編程任務，尤其是在處理上下文、支持含有LLM API多個調用的操作時。

2、矢量和語義記憶

處理用戶請求的一個關鍵要素是記憶這個概念。這是Semantic Kernel管理上下文的方式，處理熟悉的文件和鍵值存儲。然而，還有第三種選擇：語義記憶（semantic memory）。這種方法接近于LLM處理數據的方式，將內容視為矢量或嵌入，它們是LLM用來表示文本含義的數字數組。相似的文本在與您的模型及其內容相關的整體空間中會有相似的矢量，就像搜索引擎生成排序結果的方式一樣。

像GPT這樣的LLM使用這些嵌入的矢量來提取提示的上下文，幫助底層模型保持相關性和一致性。嵌入越好，模型生成純隨機輸出的可能性就越小。通過將大型提示分解為可由LLM總結的文本塊，我們就可以為每個摘要生成嵌入矢量，然后使用這些矢量創建復雜的提示，而不用耗盡請求的可用token（比如GPT-4對每個輸入的token限制為8192個）。

這些數據可以存儲在矢量數據庫中，以便快速檢索。可以為專業知識創建特定的矢量數據庫，使用總結的內容來幫助LLM處于正軌。因此比如說，使用GPT-4進行病例筆記摘要的應用程序可以使用矢量數據庫（其嵌入來自醫學論文、適當的匿名筆記及其他相關文本），以確保輸出具有連貫性、符合上下文。這種方法在某種程度上解釋了為什么微軟的第一個基于GPT的大型應用程序是Bing搜索引擎，因為它已經擁有適當的可供使用的矢量數據庫。

3、連接到外部數據源

連接器是Semantic Kernel的一個有意思的特性，因為它們可以將現有API與LLM集成起來。比如說，您可以使用微軟Graph連接器在電子郵件中自動發送請求的輸出，或者在貴組織結構圖中構建關系描述。Semantic Kernel應用程序中沒有設置點來進行調用，它可能是輸入的一部分，也可能是輸出的一部分，甚至是LLM調用序列的一部分。您可以利用API調用來構建提示，這些提示本身構建進一步的API調用，可能是通過使用基于Codex代碼的模型將結果輸出注入到運行時環境中。

連接器的一個更有趣的特性是，它對LLM運用某種基于角色的訪問控制。如果您使用微軟Graph查詢來構建提示，那么這些查詢將在運行該應用程序的用戶上下文中，使用憑據來提供數據。將憑據傳遞給連接器可以確保基于用戶自己的數據為用戶量身定制輸出。

4、構建混合提示模板和代碼的技能

Semantic Kernel的第三個主要組件是技能（skills），它們是混合LLM提示和常規代碼的函數容器。這些函數在概念和操作上類似Azure Functions，可用于將專門的提示串聯起來。應用程序可以有一組使用GPT生成文本的函數，然后使用該文本作為Codex和DALL-E的提示，以便由描述變成原型Web應用程序（類似自然語言編程工具在微軟的低代碼和無代碼Power Platform中的工作方式）。

一旦技能、記憶和連接器落實到位，您就可以開始構建基于LLM的應用程序了，使用技能將請求轉換成提供給底層模型的提示。這種方法讓您可以構建靈活的技能，代碼可以根據需要選擇和使用這些技能。Semantic Kernel區分語義函數、模板提示和原生函數，即處理用于LLM語義函數中的數據的原生計算機代碼。一個函數的輸出可以鏈接到另一個函數，允許您構建一條混合原生處理和LLM操作的函數管道。

通過對Semantic Kernel的這番簡單介紹，我們可以清楚地看到這是一個強大的工具，但是需要認真考慮和規劃。您可以使用Semantic Kernel來構建和管理復雜的提示以及處理輸入和輸出鏈的管道，以便提供有趣又有用的結果。很自然，當您適當地使用每個要素時，將獲得最好的結果，原生代碼負責處理計算，而模型專注于引導的目標（或者微軟文檔中所稱的“the asks”）。

使用Semantic Kernel之類的工具來編排和協調輸入和函數，肯定會比僅僅向輸入傳遞提示更有效地使用LLM。它將允許您凈化輸入，引導LLM生成有用的輸出。為了幫助您入門，微軟提供了一份最佳實踐指南列表（《語義AI的Shillace定律》)，這些最佳實踐是從構建跨微軟業務的LLM應用程序中匯總而來的。它們可幫助您了解如何圍繞GPT之類的LLM構建代碼，這樣可以幫助您從這些新工具和技術中獲得盡可能多的價值，同時避免不切實際的期望。

原文鏈接：https://www.infoworld.com/article/3693310/semantic-kernel-a-bridge-between-large-language-models-and-your-code.html