瞭解大型語言模型 (LLM)
大型語言模型（LLM）是一種人工智慧（AI）演算法，它使用深度學習技術和海量資料集來理解、總結、生成和預測新內容。憑藉合成大量資訊的能力，LLM 可以提高以前需要人類專家的業務流程的效率、規模和一致性。
沃頓商學院商學教授 Ethan Mollick 表示，在早期的對照實驗中，使用 LLM 可以讓寫程式碼、寫作、營銷和商業材料等單項任務的效能提高 30% 到 80%。隨著 OpenAI 的 ChatGPT、GitHub 的 Copilot 和 Google 的 Bard 等多種免費模型的出現，企業比以往任何時候都更容易獲得 LLM 的強大功能。同時 LLM 價格的下降和市場上新產品的出現，各種規模的企業現在也可以購買更復雜、更安全的預訓練 LLM，而不必投入大量資源從頭開始訓練一個模型。
利用 LLM 開展平臺工程
平臺工程是一門設計和構建內部開發人員平臺（IDP）的學科，目的是在雲原生時代為軟體工程組織提供開發人員自助服務和標準化設計。IDP 由許多不同的技術和工具組成，這些技術和工具以一種降低開發人員認知負荷的方式粘合在一起，而不會抽象掉上下文和底層技術。
LLM 可以幫助平臺團隊構建更具吸引力的 IDP。雖然個人開發人員和平臺工程師可以在沒有組織支援的情況下使用 ChatGPT，但有意將 LLM 整合到平臺中的組織可以以標準化的方式進一步自動化重複性任務，提高可發現性，併為開發人員、平臺工程師和管理人員提供支援。
下表列出了平臺工程領域的一些潛在使用案例：
有些用例很容易實現，它們可以獨立實施或與第三方解決方案一起實施，在幾周內至少 95% 的時間是可靠的，使用可用資料，並且需要結合上下文的知識。另一部分則是難以實施的用例，要求使用者需要有 LLM 方面的專業知識，經過更多的時間才能達到可接受的可靠性；同時還需要企業建立自己的資料集，改進現有模型，或根據需求自行訓練一個新模型。
重要的是，不僅要考慮 LLM 如何增強當前的平臺工程，還要考慮未來的發展趨勢。更長遠的考慮可以幫助企業更好地理解是否以及何時值得對 LLM 進行投資。根據我們目前對 LLM 的瞭解，我認為值得考慮利用 LLM 來實現這些潛在優勢：
減少重複性工作
LLM 可以最大限度地減輕枯燥和重複性工作的負擔。將他們視為助手，你可以將最乏味的工作委託給他們：建立配置檔案、識別配置檔案、文件、資源定義、報告等中的錯誤。無論您是開發人員、平臺工程師還是經理，LLM 都能讓您騰出更多時間，專注於創造性的高價值任務。這不僅能提高工作效率，還有可能降低單調工作中經常出現的人為錯誤風險。透過加快完成以前需要花費大量時間和精力的任務，LLM 可以使使用者獲得更高效、更愉快的 IDP 體驗。
這裡我們採訪過一位開發人員 Manuel Odendahl，他描述了 LLM 如何改變了他的工作，我認為這是一個特別有說服力的例子，說明了為什麼值得考慮利用 LLM：
這可能是較為微妙的轉變，但也是使用 LLM 給我帶來的最深刻的變化。經過一天專注於正確處理“乏味的事情”（比如使用正確的 API，檢查正確的工作，正確呼叫 API X，為 Y 實現單元測試和模擬，為 Z 編寫 API 包裝器），為了避免出錯，我的大量精力需要集中在工作細節上。所以我習慣在工作後透過玩遊戲和看電影的方式來放鬆自己。
在使用 Copilot 和 ChatGPT 後，這種認知疲憊感基本神奇地消失了。每天工作結束後，我就覺得自己好像和在朋友聊天，但是已經合併了 5 個 PR，編寫了單元測試，改進了兩個工具，程式碼也已經發布。
不難理解，大量重複性的工作會導致開發人員倦怠。除了幫助開發人員提高工作效率外，LLM 還有可能讓他們在工作時的體驗更佳。
Odendahl 在同一篇文章中寫道，他從 Copilot 的測試版開始就使用該工具進行程式設計。他從 LLM 中獲得的好處，在很大程度上可能是他渴望學習和完善使用該技術的結果。而其他開發人員可能缺乏熟練使用 LLM 進行編碼的經驗或動力。如果沒有將 LLM 有意義地整合到平臺的黃金路徑中，平臺團隊就不應該假設企業的開發人員會使用 LLM。此外，平臺團隊應避免依賴未經訓練或未根據企業特定平臺進行微調的模型，因為這會增加 LLM 生成錯誤答案的風險。因此，透過將 LLM 與 IDP 相結合，企業的平臺團隊可以更好地確保 LLM 在提高開發人員體驗的同時，實現更大程度的標準化。
更容易上手使用
LLM 的自然語言處理能力可以讓開發人員使用自然語言查詢來探索平臺的功能、應用示例或示例程式碼以及命令語法。它們還可以將大量文件綜合為與上下文相關的建議或指導教程，從而簡化對平臺資源的理解。
提供更好的支援
如果在企業的 IDP 中對 LLM 進行適當的特定培訓，LLM 可以充當平臺的技術助手，回答開發人員的詢問，解決技術問題，並提供實時指導。透過將 LLM 整合到 IDP 中，平臺團隊可以提供更高效、反應更迅速的支援，確保開發人員獲得所需的協助，從而順利開展工作並及時解決問題。使用 LLM 為使用者提供支援，意味著平臺團隊可以減少處理工單的時間，能夠更加專注於複雜而有意義的工作。
這還可以最大限度地減少管理人員對平臺團隊的依賴，來去生成最新的、易讀懂的報告，去衡量 IDP 的表現。LLM 在本質上可以充當工程師和高管之間的翻譯，從而減少溝通的成本，提高溝通效率。
將 LLM 納入平臺工程的重要因素
當然，企業在如何將 LLM 納入其平臺時應該慎之又慎。作為一項新興技術，LLM 並不完美，如果被誤用，可能會造成嚴重後果。最好的策略就是從開始使用就設定正確的防護。
謹慎對待 LLM 回覆
與其他技術一樣，LLM 的使用也存在潛在的安全風險。漏洞和風險管理公司 Vulcan Cyber 進行的研究發現，ChatGPT 有時會推薦目前並不存在的程式碼庫。研究人員警告說，威脅行為者可能會收集 ChatGPT 推薦的不存在的庫名稱，並建立惡意版本供開發人員下載。
開放式全球應用安全專案（OWASP）是一個致力於提高軟體安全性的非營利性基金會，它與數百名專家合作開發了一份十大關鍵的 LLM 漏洞列表。Kainos 高階安全架構師、OWASP 十大 LLM 核心小組成員 John Sotireopolous 解釋瞭如何確定每個漏洞的相對危險性，例如，Prompt Injection（LLM01）是一種透過特定的、難以檢測的指令來影響語言模型輸出的能力，它是最重要的漏洞，因為無論你使用什麼模型以及如何使用它，你都將無法避免該風險。
LLM 不可免於安全威脅，同時在執行任務時也存在一定風險。這些語言模型有時可能會產生錯誤的回覆，類似於"幻覺"。因此使用者需要對 LLM 生成的任何內容進行檢查，以確保內容的正確性和合規性。理想情況下，平臺團隊也會對整合到 IDP 中的 LLM 進行測試，以更好地瞭解它能最可靠地協助完成哪些任務。
如之前所提到，LLM 的功能的確能夠有效消除重複性工作對開發人員帶來的倦怠。例如，LLM 可以根據自然語言提示為基於 AWS 的設定，開發人員可能不需要了解配置的細節。但實際上，使用者在使用 LLM 作為輔助工具時需要具備驗證 LLM 輸出的專業知識。也就是說專家可以使用 LLM 更快地執行簡單任務。反之，不熟練的使用者可能只是使用 LLM 更快地生成錯誤程式碼。
平臺團隊應瞭解將 LLM 整合到 IDP 中的風險，並決定相應的策略，確保在平臺設定中建立正確的檢查和平衡機制。
投資於特定領域的 LLM 提示工程或培訓
利用 LLM 輔助 IDP 的企業也可以考慮訓練自己的模型。或者對預先訓練好的模型進行微調，以提高 LLM 的可靠性，使其更適合組織的工作流。這樣做的成本會更高，但也能提高 LLM 的可用性和可靠性。
如果 LLM 在企業的 IDP 中非常普遍，則需要專業人員為使用者設計提示，並促進對模型的進一步培訓。平臺團隊應像對待其他型別的平臺功能開發一樣對待提示和培訓。
LLM 與未來就業
很多人擔心 LLM 會取代他們的工作。就目前而言技術還不成熟，因為 LLM 的產出仍然需要人工驗證其準確性。理想的情況是，LLM 可以繼續消除枯燥和重複性的工作，而不會消除工作崗位。
不過 LLM 的普及和使用可能會威脅到不願接受 AI 技術的專業人員。David Eastman 認為："Copilot 是一種工具，它能夠與開發人員定義小段功能程式碼、使用慣例以及在上下文環境中工作的能力協同工作。它所做的有效工作就是去掉了在 Stack Overflow 上查詢的步驟"。他建議初級開發人員合理地使用像 Copilot 這樣的 LLM，來獲得更多的優勢。同樣的情況也適用於平臺工程師。
顯而易見的是，LLM 的早期採用者在程式碼輸出的質量和數量方面遙遙領先。軟體工程的每個領域都是如此，平臺工程也不例外。
LLM 與平臺工程的未來
LLM 將會徹底改變技術領域的世界，最有能力的團隊將會找到如何利用它們的潛力來塑造未來的 IDP 版本。理性地看待這一點，並積極擁抱新技術，只有當我們探索其深度時，我們才能真正理解其重要性。
歸根結底，LLM 與之前的技術革新浪潮並無區別。當然任何工具的使用都有利弊，LLM 既能夠讓開發人員工作效率提高 10 倍，也可以讓企業 IDP 變得更加混亂和不安全。因此在引入和使用前需要制定相應的策略，確保在平臺設定中建立和實施適當的檢查和平衡機制。