Prova
返回網誌
/證據

當市場推廣中的 AI workflow 失敗:實際發生了什麼

市場推廣中 AI workflow 失敗最常見的方式是不一致的輸入數據加上在發佈前沒有人工輸出審核。解決方案不是更好的 AI——而是內置於 workflow 設計中的審核檢查點。

簡短回答

市場推廣中 AI workflow 失敗最常見的方式是不一致的輸入數據加上在發佈前沒有人工輸出審核。解決方案不是更好的 AI——而是內置於 workflow 設計中的審核檢查點。

Prova 為檢視市場推廣中 AI workflow 為何失敗以及如何修復底層設計問題製作的編輯配圖。

我要告訴你 Prova 的衝刺審核系統以一種具體而令人尷尬的方式崩潰的經歷,因為我認為這比抽象的失敗模式列表更有用。

Prova 的衝刺審核是程序運作方式的核心。學習者提交成果物—— workflow 規範、可運行的原型——AI 審核員根據該衝刺的標準對其進行評估。審核員提供結構化反饋。學習者修改或通過。這就是「我讀過這個」和「我構建了被評估的東西」之間的區別。

早期版本中發生的事情是:AI 審核員收到的關於用戶當前所在衝刺的上下文不一致。系統正在將衝刺資訊傳遞到審核提示詞中,但數據有時是過時的——來自上一個會話的緩存值,或者用戶在沒有正確更新狀態的情況下在衝刺之間導航的會話。

結果是審核員有時會根據錯誤衝刺的標準來評估提交內容。提交衝刺 3 作品的用戶會收到根據衝刺 1 校準的反饋——在那裡,標準更簡單,預期的成果物發展程度更低。反饋聽起來很有把握。它前後一致。它只是在評估錯誤的東西。

用戶收到了矛盾的信號。一些人在應該需要更多工作的提交上輕鬆通過了。一些人收到了指出另一個衝刺的缺失元素的反饋。最糟糕的是,反饋在兩種情況下聽起來都很權威。

我沒有立即發現它,因為審核沒有明顯破損——它們是微妙地出錯了。語言流暢。結構正確。被應用的標準只是屬於不同衝刺的。

真正是什麼原因導致的

不是模型。是上下文。

AI 審核員被給予了調用時提示詞中的任何衝刺資訊。當該資訊不正確時——過時、路由錯誤或被會話錯誤覆蓋——審核員用它擁有的東西工作。它沒有辦法知道上下文是錯誤的,因為提示詞中沒有任何內容告訴它要根據用戶的當前狀態驗證衝刺 ID。

系統信任輸入而不驗證它。輸入有時是錯誤的。輸出總是以與輸入相同的方向自信地出錯。

這是市場推廣中 AI workflow 失敗最常見的方式,不僅僅是我構建的東西:不一致的輸入數據流入聽起來自信的 AI 輸出,中間沒有審核。

為什麼解決方案不是更好的模型

當這種失敗發生時,直覺是看向 AI。也許模型不夠聰明。也許不同的工具會發現它。

它不會。模型無法驗證它沒有被給予的上下文。更有能力的模型會產生更流暢的錯誤答案,實際上更難發現。

真正的解決方案在 workflow 設計中:這個提示詞的每次調用需要什麼上下文,以及你如何確保該上下文始終是最新和正確的?

在 Prova,解決方案是在每個審核提示詞的開頭添加一個結構化的上下文塊,明確包含衝刺 ID、當前標準集和用戶針對該衝刺的以前提交歷史。不從緩存獲取。在調用時新鮮獲取。提示詞還包括一條明確的指令:「如果衝刺 ID 或標準集丟失或被標記為未知,不要繼續審核——返回請求正確上下文的錯誤。」

最後那行是重要的。它給了審核員對不確定輸入的定義行為,而不是預設基於錯誤數據產生自信的輸出。

一般模式

按順序,導致市場推廣中 AI workflow 失敗的四件事:

  1. **輸入不一致。**workflow 在不同時間收到不同的數據結構,提示詞無法處理變化。模型用它收到的東西盡力而為。
  2. 發佈前沒有輸出審核。 有人自動化了生成步驟但沒有自動化審核步驟。輸出在沒有人工閱讀的情況下到達客戶、領導報告或已發佈頁面。
  3. 提示詞漂移。 原始提示詞對它設計的用例有效。六個月後,輸入略有變化,用例演變,但提示詞沒有變化。它仍在運行。它不再根據它接收到的內容進行校準。
  4. 沒有失敗文檔。 出了什麼問題,它被悄悄修復了。團隊不記錄發生了什麼、原因是什麼或修復是什麼。三個月後,另一個人將相同的錯誤構建到不同的 workflow 中。

如何構建有效的審核檢查點

審核檢查點不是讓人工閱讀每個輸出——那會破壞自動化的目的。它是一個關於哪些輸出會被審核以及某些東西失敗時會發生什麼的定義決策規則。

對於任何產生觸達客戶或領導層輸出的 AI workflow,定義:可疑輸出是什麼樣的?什麼觸發人工審核?如果審核失敗,後備方案是什麼?這些答案在系統上線之前屬於 workflow 設計文檔。

根據我的經驗,檢查點捕獲失敗的頻率大約是實際問題觸發它的兩倍。大多數時候,輸出沒問題。但檢查點的存在是使團隊願意信任 workflow 的東西——因為他們知道失敗模式被覆蓋了。

這對構建意味著什麼

AI 構建者的現實檢驗 文章涵蓋了開始構建時比看起來更難的事情的更廣泛模式。本文是關於一個特定機制的:不一致的輸入數據流入聽起來自信的 AI 輸出,它們之間沒有審核。

寫這篇文章的不適感就是重點。我構建了它。它以我應該更早設計規避的具體且可預測的方式崩潰了。來自具體失敗的教訓比來自假設性警告的更可信。

當你為市場推廣設計第一個 AI workflow 時,審核檢查點不是可選的。從一開始就把它內置進去。無論收到什麼,模型都會產生自信的輸出。檢查點是系統中唯一知道差異的部分。

Cheers, Chandler

相關閱讀

繼續閱讀相鄰的 sprint、成果物或營運問題。

/構建者

AI 構建的現實檢查

給想建立 AI 產品或內部工具的市場推廣人一個現實檢查:不要略過成本、合規、QA、復原和真實用戶。

/構建者

如何為市場推廣 workflow 編寫一致的 AI 提示詞

一致的 AI 提示詞有四個組成部分:固定的角色定義、有界限的任務描述、必需的輸出格式和明確的約束。缺少任何一個,輸出變化就會太大,無法成為可重複的 workflow。