AIGenOps：生成式人工智能和平臺工程

隨着生成式人工智能（ai）的興起，我們與金融客戶探討了將其融入受監管軟件領域的可能性。受監管環境下的約束，如安全性、質量和網絡限制，以及 devops 和平臺工程師的需求，促使我們定義了受監管軟件領域中採用生成式 ai 的真實場景需求和解決方案。

不久以前...

我們與一位金融客戶合作已有一段時間了，在閒暇之餘，我們開始討論生成式人工智能。因此，我們沉浸在興奮之中，就像置身於一個積極的回溯系統中一樣，開始勾勒出如何將其整合並應用於我們所處的現實場景中的想法。 

將DevOps工程師的 LLM/AI 技能和知識與平臺工程師的願景相結合，我們開始定義受監管軟件領域的真實場景的需求、約束和負載，然後定義可能的流程和解決方案。 

但在哪種情況下呢？

在受監管的軟件領域，尤其是在我們工作的銀行環境中，存在安全性、質量和網絡限制等制約因素。除此之外，還有數量可能非常多的 CI/CD 負載、已經超負荷的開發人員和成本管理。以下是初始要求的列表：  

• 本地系統或託管虛擬機或私有云，可能存在隔離 
• CI 和 CD 管道的性能沒有下降 
• 獲得開發人員批准的零信任模型 
• 選擇受影響的組件 
• 生成對象的限制 

最後兩點並非是強有力的約束，而是爲了更好地解決問題而採取的常識性做法。

詳細來說...

在受監管的軟件領域以及網絡可達性限制（處理可能的商業機密）方面，您不希望您的數據和代碼在未受保護或未經驗證的系統上被髮送到外部。因此，系統應託管在隔離良好的網絡中的私人機器上。生成式 AI 流程對資源消耗有很大影響，並且可能需要很長的處理時間。因此，爲了限制時間和性能影響，它們不能被引入 CI/CD 週期：我們假設一個異步且獨立的“連續生成循環”。 

作爲一個需要認證和驗證的系統，並且必須嘗試限制不當引入，因此必須採用零信任模型，其中“連續生成循環”會提出拉取請求（以下也稱爲 PR），經理必須驗證和批准這些請求。基於這些假設，記住平臺工程背後的原則之一是“從開發開始”，並且想要限制處理成本和時間，因此不可能在所有應用程序中生成數千行代碼。生成部分應該：

僅選擇並優先處理那些需要採取行動的應用程序

例如，如果有 3 個申請

1. 覆蓋率約爲 85% 且存在一些代碼異味，
2. 覆蓋率約爲 80%，存在許多代碼異味和一些小錯誤
3. 覆蓋率達 60%，且存在嚴重漏洞

系統應該優先考慮最後一個應用程序，並對其進行處理，以平衡應用程序池的總體水平。

限制生成的對象

如果我們要求經理或開發人員驗證拉取請求，以防它包含大量可交付成果，那麼最糟糕的情況是 PR 要麼被完全拒絕，要麼被草草地檢查，並且有引入錯誤的風險。  

爲了確保生成活動與開發人員的日常工作協同，必須通過選擇和確定活動的優先級來採取行動，尋找少數（希望如此！）影響最大的錯誤/漏洞，或通過測試覆蓋影響最大、未覆蓋的類別。 

選擇和優先排序方法可以實現更快的處理、更低的成本，並且只對真正需要外部幫助的應用程序採取行動，但最重要的是不會影響開發人員的工作。

接下來是什麼？

接下來的步驟是： 

• 定義應用程序優先級和選擇算法 
• 定義質量/漏洞解決方案和代碼覆蓋率的選擇和優先級算法 
• 根據創新管理和平臺工程的原則，確定早期採用者和先驅者，在熟練的開發人員的幫助下，以可用的方式在現實環境中實施解決方案，以便爲最終用戶進行最佳開發

綜上所述

可以在受監管的環境中將生成性 AI 引入IDP，同時尊重環境的所有約束和要求，同時不忽視最終用戶及其對系統的用戶體驗。

以上就是AIGenOps：生成式人工智能和平臺工程的詳細內容，更多請關注本站其它相關文章！