Semantic Kernel:架起大型語言模型與代碼的橋梁
譯文譯者 | 布加迪
審校 | 重樓
51CTO讀者成長計劃社群招募,咨詢小助手(微信號:CTOjishuzhan)
微軟的Semantic Kernel SDK讓用戶更容易管理復雜的提示,并從GPT之類的大型語言模型獲得精準的結(jié)果。
乍一看,把GPT-4之類的大型語言模型(LLM)做入到代碼中似乎很簡單。API是單一的REST調(diào)用,獲取文本后基于輸入返回響應,但實際情況比這要復雜得多。將API視為域邊界(domain boundary)可能更好,您在其中交付的提示定義了模型用于生成輸出的格式。但這里有一個關鍵點:LLM可以很簡單或很復雜,取決于您想讓它多簡單或多復雜。
當我們將AI模型做入到代碼中時,其實跨越了兩種不同計算方式之間的界限,就像為量子計算機編程酷似設計硬件一樣。在這里,我們描述了模型應該有怎樣的行為,期望它的輸出采用由提示定義的格式。在量子計算中,像Q#語言這樣的構(gòu)件提供了一座架起傳統(tǒng)計算和量子計算的機梁,我們需要工具來包裝LLM API,并提供管理輸入和輸出的方法,以確保模型始終專注于我們已定義的提示,并確保輸出依然準確。
這是需要強調(diào)的重要一點:我們與LLM的互動方式與傳統(tǒng)編程大不相同。我們需要的是Q#對等體,即在不同域之間轉(zhuǎn)換的高級抽象,從而幫助我們獲取數(shù)據(jù)后用數(shù)據(jù)來設計提示,同時提供一種方法來管理調(diào)用之間的必要上下文,以免耗盡會話中的可用token,同時仍保持輸出基于源數(shù)據(jù)。
1、Semantic Kernel介紹
幾周前,我研究了微軟的第一個LLM包裝器:開源的Prompt Engine。此后,微軟發(fā)布了一個更龐大更強大的C#工具:Semantic Kernel,用于處理Azure OpenAI(以及處理OpenAI自己的API)。它也是開源的,可以在GitHub上獲得,還有一些示例應用程序可以幫助您入手。Python版本的Semantic Kernel也在開發(fā)中。
這個名字的選擇饒有意思,因為它表明對LLM的用途有一番更好的理解。Prompt Engine側(cè)重于管理API的輸入,而Semantic Kernel的范圍更廣,專注于自然語言的輸入和輸出。微軟將其方法描述為“面向目標”,使用來自用戶的初始請求(“ask”)來指導模型,協(xié)調(diào)與模型相關的資源的傳遞以實現(xiàn)請求,并返回請求響應(“get”)。
所以稱Semantic Kernel為內(nèi)核有其道理。它就像LLM API的操作系統(tǒng),接受輸入,通過使用模型來處理輸入,然后返回輸出。內(nèi)核充當協(xié)調(diào)器的角色是這里的關鍵,因為它不僅能夠處理當前提示及其關聯(lián)的token,還能夠處理記憶(鍵值對、本地存儲以及矢量或“語義”搜索)、通向其他信息服務的連接器以及混合提示和傳統(tǒng)代碼的預定義技能(想想LLM函數(shù))。
Semantic Kernel工具提供了更有效的方法來構(gòu)建和使用包裝Prompt Engine所需的構(gòu)件類型,從而簡化了可能變得相當復雜的編程任務,尤其是在處理上下文、支持含有LLM API多個調(diào)用的操作時。
2、矢量和語義記憶
處理用戶請求的一個關鍵要素是記憶這個概念。這是Semantic Kernel管理上下文的方式,處理熟悉的文件和鍵值存儲。然而,還有第三種選擇:語義記憶(semantic memory)。這種方法接近于LLM處理數(shù)據(jù)的方式,將內(nèi)容視為矢量或嵌入,它們是LLM用來表示文本含義的數(shù)字數(shù)組。相似的文本在與您的模型及其內(nèi)容相關的整體空間中會有相似的矢量,就像搜索引擎生成排序結(jié)果的方式一樣。
像GPT這樣的LLM使用這些嵌入的矢量來提取提示的上下文,幫助底層模型保持相關性和一致性。嵌入越好,模型生成純隨機輸出的可能性就越小。通過將大型提示分解為可由LLM總結(jié)的文本塊,我們就可以為每個摘要生成嵌入矢量,然后使用這些矢量創(chuàng)建復雜的提示,而不用耗盡請求的可用token(比如GPT-4對每個輸入的token限制為8192個)。
這些數(shù)據(jù)可以存儲在矢量數(shù)據(jù)庫中,以便快速檢索。可以為專業(yè)知識創(chuàng)建特定的矢量數(shù)據(jù)庫,使用總結(jié)的內(nèi)容來幫助LLM處于正軌。因此比如說,使用GPT-4進行病例筆記摘要的應用程序可以使用矢量數(shù)據(jù)庫(其嵌入來自醫(yī)學論文、適當?shù)哪涿P記及其他相關文本),以確保輸出具有連貫性、符合上下文。這種方法在某種程度上解釋了為什么微軟的第一個基于GPT的大型應用程序是Bing搜索引擎,因為它已經(jīng)擁有適當?shù)目晒┦褂玫氖噶繑?shù)據(jù)庫。
3、連接到外部數(shù)據(jù)源
連接器是Semantic Kernel的一個有意思的特性,因為它們可以將現(xiàn)有API與LLM集成起來。比如說,您可以使用微軟Graph連接器在電子郵件中自動發(fā)送請求的輸出,或者在貴組織結(jié)構(gòu)圖中構(gòu)建關系描述。Semantic Kernel應用程序中沒有設置點來進行調(diào)用,它可能是輸入的一部分,也可能是輸出的一部分,甚至是LLM調(diào)用序列的一部分。您可以利用API調(diào)用來構(gòu)建提示,這些提示本身構(gòu)建進一步的API調(diào)用,可能是通過使用基于Codex代碼的模型將結(jié)果輸出注入到運行時環(huán)境中。
連接器的一個更有趣的特性是,它對LLM運用某種基于角色的訪問控制。如果您使用微軟Graph查詢來構(gòu)建提示,那么這些查詢將在運行該應用程序的用戶上下文中,使用憑據(jù)來提供數(shù)據(jù)。將憑據(jù)傳遞給連接器可以確保基于用戶自己的數(shù)據(jù)為用戶量身定制輸出。
4、構(gòu)建混合提示模板和代碼的技能
Semantic Kernel的第三個主要組件是技能(skills),它們是混合LLM提示和常規(guī)代碼的函數(shù)容器。這些函數(shù)在概念和操作上類似Azure Functions,可用于將專門的提示串聯(lián)起來。應用程序可以有一組使用GPT生成文本的函數(shù),然后使用該文本作為Codex和DALL-E的提示,以便由描述變成原型Web應用程序(類似自然語言編程工具在微軟的低代碼和無代碼Power Platform中的工作方式)。
一旦技能、記憶和連接器落實到位,您就可以開始構(gòu)建基于LLM的應用程序了,使用技能將請求轉(zhuǎn)換成提供給底層模型的提示。這種方法讓您可以構(gòu)建靈活的技能,代碼可以根據(jù)需要選擇和使用這些技能。Semantic Kernel區(qū)分語義函數(shù)、模板提示和原生函數(shù),即處理用于LLM語義函數(shù)中的數(shù)據(jù)的原生計算機代碼。一個函數(shù)的輸出可以鏈接到另一個函數(shù),允許您構(gòu)建一條混合原生處理和LLM操作的函數(shù)管道。
通過對Semantic Kernel的這番簡單介紹,我們可以清楚地看到這是一個強大的工具,但是需要認真考慮和規(guī)劃。您可以使用Semantic Kernel來構(gòu)建和管理復雜的提示以及處理輸入和輸出鏈的管道,以便提供有趣又有用的結(jié)果。很自然,當您適當?shù)厥褂妹總€要素時,將獲得最好的結(jié)果,原生代碼負責處理計算,而模型專注于引導的目標(或者微軟文檔中所稱的“the asks”)。
使用Semantic Kernel之類的工具來編排和協(xié)調(diào)輸入和函數(shù),肯定會比僅僅向輸入傳遞提示更有效地使用LLM。它將允許您凈化輸入,引導LLM生成有用的輸出。為了幫助您入門,微軟提供了一份最佳實踐指南列表(《語義AI的Shillace定律》),這些最佳實踐是從構(gòu)建跨微軟業(yè)務的LLM應用程序中匯總而來的。它們可幫助您了解如何圍繞GPT之類的LLM構(gòu)建代碼,這樣可以幫助您從這些新工具和技術(shù)中獲得盡可能多的價值,同時避免不切實際的期望。
原文鏈接:https://www.infoworld.com/article/3693310/semantic-kernel-a-bridge-between-large-language-models-and-your-code.html