超越「提示與祈禱」- O’Reilly

重點摘要：

企業的人工智慧（AI）團隊發現，單純依賴代理的方法（動態鏈接大型語言模型（LLM）調用）無法提供生產系統所需的可靠性。完全依賴提示的模型—商業邏輯完全存在於提示中—會導致系統不可靠、效率低下，且無法在大規模下維護。需要轉向結構化自動化，將對話能力與商業邏輯執行分開，以達到企業級的可靠性。這種方法帶來了顯著的好處：一致的執行、更低的成本、更好的安全性，以及可以像傳統軟體一樣維護的系統。

想像一下：當前的對話AI狀態就像是希羅尼穆斯·博斯（Hieronymus Bosch）的《人間樂園》中的一幕。乍看之下，它令人著迷—潛力無窮的樂園。AI系統承諾無縫的對話、智慧的代理和輕鬆的整合。但仔細一看，混亂卻浮現出來：這一直是一個虛假的樂園。

你的公司的AI助理自信地告訴客戶它已處理了他們的緊急提款請求—但實際上它並沒有，因為它誤解了API文檔。或者它愉快地告訴你的CEO它已將那些敏感的董事會文件歸檔—卻放到了完全錯誤的資料夾。這些並不是假設的情境；它們是那些將運營押注於提示和祈禱方法的組織的日常現實。

期望的演變

多年來，AI世界受到規模法則的驅動：這是一種經驗觀察，較大的模型和更大的數據集會導致性能的比例提升。這促使人們相信，僅僅增大模型的規模就能解決準確性、理解和推理等更深層次的問題。然而，越來越多的共識認為，規模法則的時代即將結束。增量的提升變得越來越難以實現，而押注於越來越強大的LLM的組織開始看到收益遞減。

在這種背景下，對話AI的期望急劇上升。還記得昨天那些簡單的聊天機器人嗎？它們用預先編程的回答處理基本的常見問題。如今的企業希望AI系統能夠：

在多個部門之間導航複雜的工作流程

與數百個內部API和服務進行交互

在考慮安全性和合規性的情況下處理敏感操作

在數千名用戶和數百萬次交互中可靠地擴展

然而，重要的是要明確這些系統是什麼—以及不是什麼。當我們談論對話AI時，我們指的是設計用來進行對話、協調工作流程和實時做出決策的系統。這些系統參與對話並與API集成，但不創建獨立的內容，如電子郵件、簡報或文件。像“為我寫這封電子郵件”和“為我創建一個簡報”這樣的用例屬於內容生成，這超出了這一範疇。這一區別至關重要，因為對話AI的挑戰和解決方案對於在互動、實時環境中運作的系統是獨特的。

我們被告知2025年將是代理的年份，但同時來自Anthropic、Hugging Face和其他領先聲音的共識越來越強烈，複雜的工作流程需要比單純信任LLM來解決一切更多的控制。

提示和祈禱的問題

當前許多對話AI實施的標準操作手冊大致如下：

收集相關的上下文和文檔

編寫一個解釋任務的提示

請求LLM生成計劃或回應

信任它能如預期運作

這種方法—我們稱之為提示和祈禱—乍看之下似乎很有吸引力。它實施迅速，演示效果良好。但在大規模運作時，它隱藏著嚴重的問題：

不可靠性

每次互動都成為出錯的新機會。相同的查詢可能根據模型當天如何解讀上下文而產生不同的結果。在處理企業工作流程時，這種變異性是不可接受的。

為了感受提示和祈禱方法的不可靠性，考慮一下Hugging Face報告的功能調用的最新狀態準確度不到90%。對於軟體來說，90%的準確性通常會成為交易的破壞者，但代理的承諾在於能夠將它們鏈接在一起：即使連續五次也會有超過40%的失敗率！

低效率

動態生成回應和計劃的計算成本很高。每次互動都需要多次API調用、標記處理和運行時決策。這轉化為更高的成本和更慢的回應時間。

複雜性

調試這些系統簡直是一場噩夢。當LLM沒有按照你的要求運作時，你的主要對策是改變輸入。但唯一知道你的改變會產生什麼影響的方法就是反覆試驗。當你的應用程序由許多步驟組成，每一步都使用一個LLM調用的輸出作為另一個的輸入時，你只能在LLM推理的鏈條中篩選，試圖理解為什麼模型做出了某些決策。開發速度因此停滯不前。

安全性

讓LLM在商業邏輯上做出運行時決策會帶來不必要的風險。OWASP AI安全與隱私指南特別警告“過度自主”——給AI系統過多的自主決策權。然而，許多當前的實施恰恰如此，這使組織面臨潛在的違規和意外後果。

更好的前進方向：結構化自動化

替代方案不是放棄AI的能力，而是通過結構化自動化更智能地利用它們。結構化自動化是一種開發方法，將對話AI的自然語言理解與確定性工作流程執行分開。這意味著使用LLM來解釋用戶輸入並澄清他們的需求，同時依賴預定義的、可測試的工作流程來處理關鍵操作。通過分開這些關注點，結構化自動化確保AI驅動的系統可靠、高效且可維護。

這種方法分開了在提示和祈禱系統中經常混淆的關注點：

理解用戶的需求：利用LLM在理解、操作和生成自然語言方面的優勢

商業邏輯執行：依賴預定義、經過測試的工作流程來處理關鍵操作

狀態管理：保持對系統狀態和轉換的清晰控制

關鍵原則很簡單：生成一次，可靠運行永遠。與其讓LLM在商業邏輯上做出運行時決策，不如利用它們來幫助創建穩健、可重用的工作流程，這些工作流程可以像傳統軟體一樣進行測試、版本控制和維護。

通過將商業邏輯與對話能力分開，結構化自動化確保系統保持可靠、高效和安全。這種方法還強化了生成對話任務（LLM擅長的地方）與操作決策（最適合由確定性、類似軟體的過程處理）之間的界限。

所謂的“預定義、經過測試的工作流程”，是指在設計階段創建工作流程，利用AI協助構思和模式。這些工作流程然後作為傳統軟體實施，可以進行測試、版本控制和維護。這種方法在軟體工程中是廣為人知的，與依賴運行時決策的代理構建形成鮮明對比—這是一種本質上不可靠且難以維護的模型。

Alex Strick van Linschoten和ZenML團隊最近編制了一個400多個（並且在增長中！）企業LLM部署的數據庫。不出所料，他們發現結構化自動化在各方面提供的價值顯著高於提示和祈禱的方法：

完全自主代理的承諾與其在面向客戶的部署中的存在之間存在明顯的脫節。當我們檢查涉及的複雜性時，這一差距並不令人驚訝。現實是，成功的部署往往偏向於更受限的方法，原因令人深思……以Lindy.ai的旅程為例：他們最初使用開放式提示，夢想著完全自主的代理。然而，他們發現當轉向結構化工作流程時，可靠性顯著提高。同樣，Rexera通過實施決策樹進行質量控制而獲得成功，有效地限制了其代理的決策空間，以提高可預測性和可靠性。

提示和祈禱的方法因其演示效果良好且感覺快速而具誘惑力。但在表面之下，它是一個脆弱的即興創作和失控成本的拼湊。解藥不是放棄AI的承諾，而是設計具有明確關注點分離的系統：由LLM處理的對話流利性，通過結構化工作流程驅動的商業邏輯。

結構化自動化在實踐中是什麼樣的？

考慮一個典型的客戶支持場景：一位客戶給你的AI助理發消息說：“嘿，你搞錯我的訂單了！”

LLM解釋用戶的消息，詢問澄清問題，如“你的訂單缺少什麼？”

在收到相關細節後，結構化工作流程查詢後端數據以確定問題：物品是否分開發貨？它們還在運輸中嗎？是否缺貨？

根據這些信息，結構化工作流程確定適當的選項：退款、重新發貨或其他解決方案。如果需要，它會向客戶請求更多信息，利用LLM來處理對話。

在這裡，LLM在導航人類語言和對話的複雜性方面表現出色。但關鍵的商業邏輯—如查詢數據庫、檢查庫存和確定解決方案—則存在於預定義的工作流程中。

這種方法確保：

可靠性：相同的邏輯在所有用戶中一致適用。

安全性：敏感操作受到嚴格控制。

效率：開發人員可以像傳統軟體一樣測試、版本控制和改進工作流程。

結構化自動化橋接了兩者的優勢：由LLM驅動的對話流利性和由工作流程處理的可靠執行。

那麼長尾呢？

對結構化自動化的一個常見反對意見是，它無法擴展以處理“長尾”任務—那些稀有的、不可預測的情況，似乎不可能預先定義。但事實是，結構化自動化通過使LLM的即興創作安全且可測量，簡化了邊緣案例的管理。

這是如何運作的：低風險或稀有任務可以在短期內由LLM靈活處理。每次互動都會被記錄，模式會被分析，並為變得頻繁或關鍵的任務創建工作流程。如今的LLM非常擅長根據成功對話的示例生成結構化工作流程的代碼。這種迭代方法將長尾轉變為可管理的新功能管道，並且知道通過將這些任務提升為結構化工作流程，我們可以獲得可靠性、可解釋性和效率。