你需要的不是智能體,而是工作流
大聰明:
本篇內容由「寶玉」創作(歡迎文末打賞),非常有見地的洞察,適合每一個 AI 從業者來學習。在落地產品的時候,核心是解決你的問題:至於是不是智能體,是不是大語言模型,是不是 AI 幫你決策,都不是最重要的。
現在 AI 智能體(AI Agent)的概念很火,似乎智能體是用 AI 解決問題的銀彈,有了智能體就可以解決很多問題。但也有很多人有不同意見,認為智能體不過是噱頭,並沒有看到可靠的應用場景。
一個被提及很多的是吳恩達老師寫的多智能體翻譯的例子,簡單來說就是用三個智能體:一個直譯智能體、一個審查智能體、一個意譯潤色智能體,確實可以大幅提升翻譯質量。但並非一定要三個智能體才能提升翻譯質量,我以前也提出過基於 Prompt 的翻譯方法,讓 LLM 在翻譯時,使用直譯 + 反思 + 意譯三個步驟輸出,也可以得到高質量的翻譯結果。
本質上,使用大語言模型(LLM)來解決問題,思維鏈(COT, Chain of Thought)是一種有效提升生成質量的方法,也就是說,之所以翻譯質量能提升,不是因為有了智能體,而是因為有了思維鏈。至於思維鏈的每個環節是用一個獨立的智能體,還是輸出的一個步驟,並沒有太本質的差別。
其實大部分 AI 應用場景都類似:要用 AI 解決問題,核心不在於智能體,而在於設計出一個適合 AI 的工作流。
那麼怎麼才能設計一個適合 AI 的工作流呢?我認為有幾個因素需要考慮:
一、不要局限於人類現有方案
有時候我們過於將 AI 擬人化,會不自覺的用人類解決問題的方式來套用在 AI 上,有時候確實有效,但很多時候並不一定是最優解。就像專業的翻譯員,他們並不需要直譯反思意譯三個步驟,他們可以一步到位,直接輸出高質量的翻譯結果,所以最開始讓 AI 翻譯,Prompt 都是直接一步輸出翻譯結果,而不是分步驟輸出,結果翻譯出來的比較生硬。而當我們發現思維鏈是大語言模型的一種有效提升方法後,就可以設計出更適合 AI 的工作流,分成幾步來解決問題。
包括我看到一些智能體項目,嘗試模擬人類軟件開發的分工,使用項目經理、產品經理、架構師、程序員、測試等等智能體角色去嘗試解決複雜的軟件項目,同樣也是一個過於擬人化而不一定適合 AI 解決問題的思路,所以也只能出現在論文中,而無法在實際項目中落地。相反像 GitHub Copilot 這樣輔助生成代碼的工具倒是真正適合當前 AI 編程的工作流,能實實在在提升開發效率。
二、不必完全依賴 AI 做決策
去年有一個超級火爆的項目叫 AutoGPT,就是你輸入一個任務,GPT-4 會將任務分解,製定計劃,調用外部工具,比如 Google 搜索,甚至執行代碼,最終完成任務。這也算是 AI 智能體的先驅項目之一,但現在已經很少有人提及了,因為以現在 AI 的智能程度,還不足以對開放性的任務做出可靠的決策,最終除了幫 OpenAI 賣了大量的 Token 外,並沒有解決什麼實際問題。所以現在 AI 應用的主流是把 AI 當「副駕駛(Copilot)」,只是讓 AI 輔助人類完成任務,主要還是人在做決策。
另外就是自己設計工作流,讓 AI 在工作流中完成一部分工作,並不過於依賴 AI 做決策,或者只需要做簡單的決策。比如說商家借助 AI 處理差評的工作流:
-
程序抓取評論信息
-
AI 分析每一條評論的情感,篩選出差評
-
AI 生成回覆(可能需要人工審核)
這是一個典型的設計好流程的適合 AI 的工作流,AI 只需要做簡單的情感分析和回覆生成,而不需要做複雜的決策,這樣的工作流可以很好的提升效率,並且結果也相對可靠。
三、可以結合多種 AI或工具
去年起 AI 大熱,一個很重要的原因是大語言模型的出現,這些模型一方面確實能力強大,有一定的通用性,有簡單的推理能力,另一方面使用也簡單,無論是通過聊天機器人,還是通過 API 調用,都能很方便的使用。即使像我這樣不是人工智能專業的人,也能很容易的使用這些模型。而在以前,人工智能相對來說是個高門檻的領域,需要篩選數據、需要訓練,還需要調參,對於非專業人士來說是很難使用的。
但這也導致一個問題,就是很多解決方案過於依賴大語言模型,而不知道或者不會使用其他領域的 AI 模型,但當你能夠根據任務,將不同領域的 AI 模型或者工具結合起來,設計出合適的工作流,就能夠得到更好的解決方案。
四、回歸問題本質,AI 只是錘子
上面提的幾點都是容易犯的一些錯誤,之所以容易犯這些錯誤,恰恰是因為我們有時候過於關注一些流行的概念或技術,而忽略了要解決的根本問題是什麼,將 AI 變成了目的而不是手段。如果你有瞭解馬斯克的第一性原理思維,其強調的就是回歸事物最基本的條件,把其解構成各種要素進行分析,從而找到實現目標最優路徑的方法。
而運用第一性原理通常有三個步驟:
-
第 1 步:定義清楚你要解決的根本問題。
-
第 2 步:拆解問題。
-
第 3 步:從頭開始創建解決方案。
而這也個思路也適用於我們去借助 AI 解決問題,設計出適合 AI 的工作流。
舉兩個設計合適 AI 工作流解決問題的例子
一個例子是 PDF 轉 Markdown
做過 PDF 翻譯的有經驗,要得到好的翻譯結果,將 PDF 的內容整理成 Markdown,再讓大語言翻譯,效果是相當好的。但這個不好做,因為 PDF 是用來打印的格式,並不是結構化的數據,很難直接提取成 Markdown,再加上各種圖表、表格等,更是複雜。
最近看到一個項目叫 PDFGPT,它就做的很巧秒,本質上是基於 GPT-4o 和 PyMuPDF 設計了一個工作流:
-
用一個 PDF 操作庫 PyMuPDF 檢測 PDF 中的圖片、圖表、表格等,提取成圖片並保存
-
每一頁 PDF 生成一張圖片,將圖片、圖表、表格等位置用紅框標記出來,並附上對應的圖片名稱
-
借助 GPT-4o 的視覺能力,解析標註後的圖片,生成對應的 Markdown
如果你純粹依賴大語言模型,恐怕無法完成這樣的任務,一方面受限於上下文窗口的長度限制,一次無法處理多頁 PDF,另一方面對於圖片、圖表、表格等內容無法嵌入 Markdown 中。如果結合 PyMuPDF 這樣的庫和一個簡單的工作流,就可以方便的實現 PDF 轉 Markdown,生成的結果也挺不錯。
另一個例子是漫畫的翻譯
有很多那種氣泡文字的漫畫,如果要翻譯成其他語言,就需要將氣泡文字提取出來,翻譯後再放回去。漫畫翻譯的難點在於:
-
因為漫畫的氣泡文字位置不固定,有時候還會有重疊,不好提取;
-
翻譯的時候,如果只是把提取出來的文字按字面翻譯,但不知道當前畫面的內容,翻譯的結果可能會不通順;
-
翻譯後要對圖片進行處理,抹掉原來的文字,將翻譯後的文字放回到原來的位置。
如果人工做會怎麼做?可能是讀懂漫畫,翻譯,然後用 Photoshop 這個樣的工具抹掉原來的文字,再放上翻譯後的文字。可以想像這樣的工作量還是不小的。
有一個開源項目 comic-translate,就做的很好,它也是設計了一個適合漫畫翻譯的工作流:
-
用一個專業模型做氣泡檢測,找出文字氣泡的位置
-
用 OCR 做氣泡尼雲字的提取
-
用一個專業模型移除氣泡內的文字
-
借助 GPT-4o 的視覺能力,根據漫畫內容,翻譯氣泡內的文字
-
用程序將翻譯後的文字繪製到原來的氣泡位置
如果不考慮翻譯質量的話,這幾乎是一個全自動的工作流,效率相當高,成本也很低,最貴的部分是 GPT-4o 的 API,一頁也才 $0.02 左右。就算加上人工審核對翻譯結果和圖片生成結果的處理,也是能比以前的人工翻譯效率高很多。
從上面的例子可以看出,真正要用好 AI,讓 AI 發揮最大效能,核心是還是要基於你要解決的問題,重新設計一個適合 AI 的工作流,讓 AI 在工作流中完成它最擅長的工作,至於是不是智能體,是不是大語言模型,是不是 AI 幫你決策,都不是最重要的。