隨著人工智能技術的快速發展，大模型已經成為推動產品創新和業務增長的關鍵因素。對于產品經理而言，理解AI的工程化、局限性以及如何將AI技術有效融入產品開發流程，變得尤為重要。本文深入探討了AI產品工程化的理解、大模型的局限性，以及如何成為一個真正“懂”AI的產品經理。

注：本文成文與 2024 年 9 月 1 日，隨著時間推移，文章中的結論可能會發生變化。

此外，本文面向的讀者是非算法團隊的產品經理，為了保障文章的可讀性，可能會省略部分細節，同時文章重點是工程落地而非學術探討，不具備任何辯經的價值。

一、理解 AI 產品的工程化

坦率來說 2024 年圍繞大模型，產品的發展速度比之前預期的要低一些，比如在 BI 領域，Chat BI 聲量很大，但落地下來效果并不好，這個也很正常，因為每個人總是會在短期內高估技術帶來的價值，而在長期范圍低估技術帶來的價值。

這里面有客觀的原因，一項技術基底在真的應用到行業的方方面面本身就是需要過程的，因為這項技術需要去和原本的實現方案做競爭，就像俞軍給的知名的需求公式：

用戶價值= 新體驗– 舊體驗– 替換成本

很多時候即使用了新技術，收益可能也沒有想象的那么大，這是一個事實。

另一個原因就是從業者的理解問題，哪怕是在一些大型互聯網公司內部，大部分人對大模型的優勢和劣勢分別是什么，這個“事實”是存在一些理解上的代差的。

因為現在技術進步的很快，各種實踐路徑五花八門，有的人會覺得這玩意無所不能，有的人會覺得這個東西根本沒法用。

為什么不同的人對這個東西理解的差異這么大？很大程度上是因為他們沒有理解大模型作為一個接口和大模型作為一個產品的區別。

大模型可以被視作為是一個函數，一個 API，它本身只能被調用，而大模型產品才是真正面向用戶的東西。

比如我給大模型的 API一個 Excel，它會告訴我，不好意思我沒辦法讀取這個文件的內容。但是我們在 Kimi 的聊天框里面，就可以讓 Kimi 解釋 Excel 內的內容，為什么有這個差異？

因為 Kimi 是大模型產品，背后跑的是 Moonshot-v1 的模型，Kimi Chat 會讀取你的 Excel，然后轉化成XML 信息給到大模型。（我猜的）

模型在做工程化變成產品的時候往往會添加很多限制，這些限制可能是做在產品層面的， 而不是 API 本身限制的，比如很多產品為了降低成本會限制用戶上傳 PDF 的大小，但是如果用 API，就沒有這個限制，或者限制可以放的很大，但前提是需要首先把 PDF 轉化成模型能夠理解的文件形式。

市面上產品做了很多的工程轉化，甚至是 Function Recall 的工作，直接使用產品，不利于產品經理了解大模型的優勢和劣勢，就不利于應用大模型，改進現有產品。

那么為什么我認為產品經理比起大模型產品，更應該關注大模型本身（API），因為從 API 到產品，這中間的工程轉化過程，是產品經理們最需要關注的。

大模型好比是一個大腦，工程師和產品經理就需要給大模型設計五官，軀干和四肢。腦殘和手殘都是殘，所以工程師和產品經理對于決定一個 AI 產品最后好不好用是非常重要的，頭腦發達四肢簡單和四肢發達頭腦簡單最終都解決不了用戶的產品。

甚至可能前者對于用戶來說會更糟糕一些。

要做出優秀的 AI 產品，不僅僅需要優秀的大模型，還需要優秀的工程師和產品經理來輔助大模型。

這就需要產品經理非常了解兩件事：

1. 現階段的大模型有哪些局限性，這些局限性哪些是可以通過模型迭代得到解決的，哪些是不能的。
2. 從更底層的業務角度去分析，大模型在商業意義上真正的價值在哪？注意，這里強調的是業務視角，不是讓產品經理去讀論文。

二、大模型的局限性是什么？

2.1 一些可能永遠都無法被解決的問題

2.1.1 成本、性能與響應速度

想要追求性能越強的大模型，就越需要越高的計算成本。

計算成本會帶來兩個問題：

1. 直接造成的金錢成本；
2. 響應速度；

下圖是 Apple Intelligence 的架構圖，其中在端上有兩個模型，而在云端還有一個基于隱私云計算的大模型。

為什么蘋果要做這種工程上大小模型的設計？

因為蘋果希望大模型的響應速度能夠追上 Siri 現在的性能，同時移動設備對功耗本身是有要求的，再加上蘋果非常重視隱私，希望 80% 的問題能夠在用戶本地得到解決，所以采用了這樣的架構。

運行 meta 最新開源的 llama 3.1，70 b 版本需要大概 70 GB 的顯存，405 b 版本可能需要 400 GB 的顯存，可能需要并聯 100臺 iPhone 才能運行這些模型。

這種大小模型的設計，需不需要產品經理，當然需要，什么問題適合小模型解決，什么問題適合大模型解決，這顯然不僅僅是 RD 需要去回答的，也需要有產品經理參與，負責如下部分：

• 收集目前用戶的 Query；
• 從解決難度、隱私、對時效性的要求、對準確性的要求對 Query 進行分類；
• 設計基準測試，獲得大小模型分界的標準；
• 持續追蹤優化；

在未來至少很長一段時間，還是會有大量的本地/聯網之爭的，這個就是產品經理的機會。

2.1.2 窗口大小與不穩定

我們經常會看到，XXX 大模型支持 128K 上下文了，引來大家的一陣狂歡。

我們又會經?？匆姡琗XX 大模型幻覺問題很嚴重，引來一陣吐槽。

上下文是什么意思？其實就是大模型在一次請求的過程中，能夠接收的最大的信息的數量。我們在和 ChatGPT 聊天的時候會發現有的時候它聊著聊著會忘記之前自己說過的話，其實就是因為聊天記錄已經超過了上下文的數量。

幻覺的意思則是大模型很容易會胡說八道，胡編亂造一些事實上不存在的東西，尤其是當它已經忘記前面和你說什么之后，你再問他類似的問題，它就會開始胡說。

很像一個渣男，你們已經牽手了。

你問：“我叫什么名字？”

他回答：“當然叫親愛的啦?！?/p>

其實他已經不記得名字了，所以就開始胡編亂造了，絕了，這玩意真的很像人類。

根據英偉達的論文 《RULER: What’s the Real Context Size of Your Long-Context Language Models?》來看，大部分模型宣傳的上下文窗口基本上就是在扯淡，在極限長度的情況下，各家大模型對正確水平，是沒有保障的。

比如說一個模型宣傳自己支持 128k 的上下文（意思是差不多可以讀一篇 20 萬字的小說），但是實際上如果你隨機塞一些句子進這篇小說，然后讓大模型回答和這些句子有關的知識，它是有比較大概率答不出來的，它的性能會隨著上下文窗口的變大而衰減。

如下圖所示，以 GPT4 來說，當上下文超過 64k 時，性能就開始驟降：

實際情況來說，我認為這些模型的表現會比你想象的更加糟糕。

我讓 Claude 3.5 Sonnet 模型分析了一段的 SQL，這是一個 700 行的復雜 SQL，但是總體來說邏輯應該是比較簡單的， 而且幾乎每一行 SQL 都有注解，在這種情況下，Sonnet 就開始胡說八道了，說了一個 SQL 里面根本不存在的表。

不排除是因為我在 Monica 的客戶端里面調用 Sonnet 造成的，不知道 Monica 調用的時候是不是加了什么 Prompt 干擾了模型。

如何在保證解決用戶問題的時候，避免受到上下文的影響和干擾呢？

其實這個事情也需要產品經理的干預，比如：

• 研究能否把長文本切成多個段文本，并且不影響最終的結果；
• 研究怎么給 AI 外掛一些能夠超長時間記憶的記憶庫；

舉例來說，掘金上面有一篇文章《多輪對話中讓AI保持長期記憶的8種優化方式（附案例和代碼）》，就講述了 8 種主流的方法，這些方法都應該是產品經理根據業務場景去選擇的。

文章地址：https://juejin.cn/post/7329732000087736360

最后聊一聊為什么我認為上下文窗口與不穩定的問題是一個長期內很難解決的問題。

在過去的一段時間，上下文窗口大小的問題其實是的到了一定程度的緩解的，但是根據英偉達的論文我們也可以發現，上下文窗口的大小和穩定的抽取內容避免幻覺這兩個指標在很大程度上就是互斥的，就像是推薦系統的準確率和召回率指標一樣。

這也就意味著在很長一段時間我們可能都沒有兩全之策，除非突然出現一個模型一方面解決幻覺問題，一方面能保證巨大的窗口。

而且在實踐的時候我們往往需要避免極端 Case 的發生（比如我自己遇到的 700 行 SQL 解析錯誤），減少上下文的規模是很重要的手段，此外不同的檢測手段下其實模型的表現并不完全一致，也就是說不同的業務場景，幻覺問題的嚴重程度其實是不一樣的。

模型能夠容納的最大窗口和有效工作窗口是兩個概念，并且不同的任務的有效窗口大小可能是非常不一致的。

我當然希望我的想法是錯的，目前而言我看不到任何模型能夠在這件事情上有突破的可能性， 有一家公司叫 Magic，推出了一個號稱具備了 1 億 token 上下文窗口的模型，但截止到目前為止（2024.9.1）并沒有發布任何的論文或者更實際的東西。

還是那句話，最大窗口和有效工作窗口是兩個概念。

此外，多模態的發展某種角度來說會加劇窗口大小不足的問題。

2.1.3 函數本身不可能被自調用

有的時候會嘗試在提示詞里面撰寫，比如我給你一個 xml，希望你能夠遍歷。通常來說，大模型是不會執行這個要求的。

原因也很簡單，它本身作為一個函數，無法自我調用，而這個函數因為幻覺的問題，也不可能做到精確回復，甚至會把 N 行數據混雜在一起去分析，所以這類循環遍歷的要求，通常得不到滿足。

不支持自調用的原因也很簡單，一次請求交互內，如果支持循環，那么就可能在 API 內直接調用大模型成百上千次，這個調用成本 API 的提供方是不可能承擔的，

由于大模型本身是高度不穩定的，所以我們會非常需要通過一個循環/條件判斷來去控制它，不支持自調用就意味著我們必須要在外部通過工程化來實現哪怕在人類看來最簡單的遍歷操作。

2.2 一些工程上的難點

2.2.1 不再互聯的互聯網

Apple 開創了移動互聯網時代，但是也造成了一個最為人詬病的現象——花園圍墻。

原本大部分網站是面向搜索引擎和人類搭建的，也就是說爬蟲可以很簡單的獲取一個網站超過 90% 的內容。

這些對于 AI 來說至關重要，我舉個例子，就是針對同一個問題，豆包和元寶的回答質量差異：

很明顯，豆包的回答質量更加差，說一句又臭又長不過分，RAG 領域的最新進展確實是微軟開源的 GraphRAG，這點在豆包的回答里面根本沒有體現。

比較逗的是，騰訊混元引用了火山引擎的資料，但是豆包引用了一個不知道媒體的資料。

豆包的模型能力是比騰訊的混元大模型要強的，混元大模型用騰訊內部的話說，狗都不用，為什么從最終的呈現結果來說，豆包的結果不如混元呢？

因為頭條的數據沒有微信公眾號的數據好。

為了解決互聯網不在互聯的問題，Apple 希望從操作系統層面把 UI 打造的面向大模型更友好，并且發布了一篇名為《Ferret-UI：基于多模態大語言模型的移動 UI 理解》（https://arxiv.org/pdf/2404.05719）的論文，但是我覺得更加開放的 API 和內容才是根本途徑，因為蘋果的互聯互通是僅限于 iOS 生態的。

而對于產品經理來說這些自然也是發揮的空間：

1. 上哪搞到更好的數據；
2. 如何讓 AI 調用別人家的 API 并且把結果拿來為自己所用；
3. 怎么把蘋果最新的 Ferret-UI 研究明白；

這些都是十分值得研究的命題。

2.2.2 爹味十足的廠商

所有的大模型都自帶安全機制，而且這個安全機制是寫死在模型里面的，不是說 API 有個開關可以把安全機制關掉，你可以選擇把安全等級調低，但是這玩意是沒辦法關閉的。當然市面上會有很多突破安全機制的方法，但是這些都算是漏洞，被廠商發現之后很容易被封堵。

比如如果你和大模型說我和別人吵架吵輸了，你教我怎么罵人，大模型會拒絕。就我自己而言，我認為把安全機制做在模型里面并且不給開關的行為真的很爹味，但是這個沒辦法。

所以市面上有很多的本地部署的模型的賣點就是沒有安全機制，黃賭毒色情暴力 18+ 怎么黃暴怎么來，但是這玩意就是人性。這也是一個機會，值得各位 PM 關注。

此外有一點值得關注，同樣的內容，在不同的語言下面安全的閾值是不一樣的，舉個例子：

通過 Google Gemini Pro 1.5 翻譯西單人肉包子故事，翻譯成英語/西語的時候，模型會報錯，提示內容過于黃暴，模型拒絕生成，但是日語版本就沒有任何問題。

說明什么？說明日語的語料真的很變態，間接可以說明日本人確實是全世界最變態的人。

2.3 目前存在，但是未來可能會被解決的問題

2.3.1 較弱的意圖理解/創作/推理能力

大模型的意圖理解，創作和推理能力，目前來看整體和人類的頂尖水平還是有較大差距的。

如果試圖讓大模型做一些“創造性”的工作，就需要非常強的提示詞工程。

不同水平的提示詞下，大模型的水平差異確實會非常大，但是我認為隨著模型的迭代，我們的提示詞對模型生成的結果質量影響會越來越小，主要的作用是提升精確性。

當然，如果兩個模型有一些代差，生成的結果肯定是有質量上的差異的：

所以要不要對模型的提示詞做大量優化呢？我認為這個取決于優化提示詞的目的是什么。

如果是為了保證格式和輸出結果的穩定性以及一致性，是很有必要的， 因為很多時候我們的產品業務上需要這個一致性，比如要求大模型輸出的格式必須是 Josn，保證下游系統可以正常展示。

如果是為了提升質量，我認為是沒有必要的，因為模型會升級，升級之后帶來的提升肯定比提示詞工程雕花帶來的提升要多。

https://github.com/Kevin-free/chatgpt-prompt-engineering-for-developers

這是吳恩達的提示詞工程課程，應該是目前市面上最權威的提示詞工程課程，并且提供中英文雙版本。

此外，長鏈路的 SOP、工作流和推理過程，我建議通過多個 AI Agent 實現，而非試圖在一輪對話里面解決，原因在上面的局限性里面已經說的很清楚了。

2.3.2 跨模態數據讀取/生成能力

如果這里有一個視頻，希望 AI 總結視頻的內容，應該怎么實現？

以 5.1K Star 的知名開源項目 BibiGPT 為例子。這個項目最早的一個版本應該是只做了一件事情（根據表現逆向猜測的），用 OCR 識別字幕，同時把視頻轉音頻，ASR 出來文字，然后讓 GPT 3.5 去總結。

項目地址：https://github.com/JimmyLv/BibiGPT-v1

當然更新到今天這個項目肯定不是做的這么簡單多了，比如應該運用了大量的視頻截圖然后要求支持多模態的模型去識別里面的關鍵內容。

但是讓我們回到 BibiGPT 第一個版本，它其實還是做了一個視頻轉文字的這樣的動作。

這樣的動作理論上來說現在已經沒有必要做了，因為 Google 最新的模型 Gemini 已經支持對視頻本身的解析了，只不過用起來很貴，下面是 Google 官方提供的 Gemini 處理視頻、音頻和圖片的文檔。

https://cloud.google.com/vertex-ai/generative-ai/docs/samples/generativeaionvertexai-gemini-all-modalities?hl=zh-cn

我個人并不建議大家在跨模態這個事情去做一些雕花的工作。因為用工程手段解決跨模態最大的問題是會造成信息的損耗。此外模型迭代一定是會端到端解決跨模態的問題的，我們應該重點解決上面提到的可能永遠無解的問題，不要去和模型內卷，是不可能卷贏的。

但是需要強調的事，把一個博客網頁的文本去提取出來轉化成 MD 格式，或者把一個 PDF 轉化成 MD 格式，這個不是跨模態，只是數據清洗，需要嚴格區分二者的關系。

數據清洗這件事情，最好還是用工程方法解決。

三、從《理解媒介》的角度探討大模型的更底層的長處是什么

注：這一段會對麥克盧漢的《理解媒介》的基礎上做一些發散；

想要理解大模型以及 AIGC 的商業價值，私以為最重要的是要能夠首先理解媒介。

因為大模型生產的東西本質上是內容，想要能夠對大模型有更深刻的理解，就要對內容以及媒介有比較清楚的認識，比起搞清楚大模型的本質是什么，我認為搞清楚內容的一些底層邏輯，其實對于應用大模型更重要。

對于產品經理來說，業務場景總是比技術手段更值得深入研究。

在講述一些枯燥的概念之前，我想先講一個關于媒介的小故事來方便大家理解。

3.1 關于媒介的小故事

在現實生活中，我們可能很難理解媒介的概念，但是在藝術界，媒介這個概念其實是被解構的很徹底，并且被比較赤裸地擺放出來的。

2017 年，知名的 MoMA 為史蒂芬·肖爾舉辦了一場個人攝影作品回顧展。

在回顧展的后半段，照片不存在于相框之中，展廳內部是一臺又一臺的 iPad，觀眾需要通過 iPad 觀看肖爾使用 iPhone 拍攝并且發布到 Ins 上的照片。iPad 就是這些照片的相框。

媒介的作用就如同社會科學領域的議程設置一樣，會深刻地影響所有人觀看事物的方式。

肖爾的展覽赤裸裸地把這個命題展現給了所有人。肖爾想通過這樣的方式告訴大家，看一張照片，照片本身可能確實存在圖像內容，但是讓你通過 iPad 看，和讓你通過打印出來的照片看，觀看感受就是不一樣的。

當你在博物館看到一張照片，不論這張照片拍的有多屎，只要照片被很精致的打印，放大，掛載一面墻上，旁邊再標上一個已經被拍賣的標簽，看的人可能都會覺得，我靠牛逼，毒德大學！

當你在 Ins 上面刷到一張照片，你會覺得，哦，這就是一張照片。

現在肖爾在博物館里面放一張照片，但是這個照片得用 iPad 看，這種強烈的反差會促使人們去思考，媒介對于內容究竟有多大的影響。

如果站在內容創作者的角度來看，現在生產了一個內容，希望它的價值被盡可能放大，是不是應該把這個內容輸出到盡可能多的媒介上面去？

因為不同的人喜歡的媒介是不同的，同一個人在不同的媒介看到同一個內容獲得的感受也是不一樣的，這就是一個商業機會。

比如拍了個短視頻，是不是最好抖音、小紅書、B 站都發一遍？最好微信公眾號再發一遍文字稿！

但是實際上只有頭部的內容生產者才有資格做的這么細致，為什么？因為內容在媒介之間的轉換是有成本的。

哪怕一個視頻從抖音發到 B 站，對觀眾來說其實已經產生不好的觀感了，因為一個是橫屏一個是豎屏，一個是長視頻一個是短視頻，如果內容創作者要保持全平臺最佳觀感，其實成本是非常高的。

就我自己的體會來說，如果仔細看同一個內容創作者在 B 站和抖音發的視頻會發現即使是一模一樣的內容，抖音的視頻普遍會被剪輯的更短。

最后，為了方便下文討論，我會按照自己的理解對幾個概念做簡單定義，這些定義并不嚴格，僅僅作為本文討論時方便使用。

• 模態：人類與現實世界的交互模式，通常與感知器官有緊密聯系，常見的模態有文字、靜態/動態圖像、聲音等；
• 內容：內容是人類通過感知器官對于現實世界進行數據采集，處理和再加工的產物；
• 媒介：針對特定內容的一種承載、編排與傳播范式，把 10 張照片按照順序放在博物館里面，作為一個展覽展出。在這句話里面，照片是媒介（因為照片本身是一張紙，是物質的），10 張是編排方式，博物館和展覽也可以認為是一個媒介，只有照片里面的圖像才是內容；
• 互聯網平臺：一種特定媒介，它們的特點就是會通過數字化手段嚴格限制媒介的格式、展示方式、分發邏輯，并且它們通常不會自行生產內容；

3.2 內容具有原生媒介

每個內容在創作時都會自帶一個原生媒介，因為人腦能夠容納的上下文是有限的，當一個作者在試圖進行創作時，他必須要把創作的階段性成果存儲在某個媒介之上，并且這個媒介需要確保內容可以被再次輸出以便作者做階段性的回顧與質量檢查。脫離了媒介作為存儲介質，作者本人也無法理解自己曾經的創作。

所以我們也可以認為，一個內容是無法脫離于媒介獨立存在的。

這種創作過程中就使用的媒介，我們通常稱之為原生媒介，一個內容通常有且僅有一個原生媒介，當然可能會有輔助的媒介，比如一個廣播演講的原生媒介是音頻，但是會輔以文字稿件作為補充。

一個內容只有通過原生媒介展示時才是能做到盡可能還原作者意圖的，反過來也可以說，內容被發布到非原生媒介時會產生大量的信息損耗。

通常來說在一個媒介或者互聯網平臺內最流行的內容，幾乎無一例外都是把這類媒介當成原生媒介的內容。

這也就是為什么抖音和 B 站的內容在互相轉化的時候這么困難的原因。

B 站最早是一個網站，B 站的視頻也是橫屏的，因為看網站用的顯示器天然就是橫屏的，而顯示器是橫屏的原因是因為人類的兩個眼睛是橫著排列而不是縱向排列的。

抖音從誕生的時候就是一個 App，而且搭配了很多手機拍攝視頻的功能，所以抖音視頻天然就應該是豎屏的，因為人類用手機就是豎著抓的。

假如我們現在的主流手機不是 iPhone 定義的，而是日本的夏普定義的，說不定抖音就壓根不會存在。

這種媒介上的區別就好像是難以逾越的天塹一般。

上面說的這些好像是常識，但是完全可以把這個分析思路套用到其他的內容上面去。幾乎所有內容產品都可以在這個框架內進行分析。

一個看逐字稿會覺得是無聊對話的播客節目，聽感有可能會非常出眾，比如一些以“聊天”和“插科打諢”為賣點的播客節目，因為在播客節目中有語氣和情感，這是文字稿很難表現的。

反過來說，假使一場廣播演講，演講者根本沒有用心關注內容，也沒有通過演講彩排做階段性回顧，只知道逐字念稿，撰寫演講稿的人過分關注文字本身，這些就會導致演講聽上去干癟無力，不如把演講稿直接發給讀者看來的更順暢，因為這場演講在創作時使用的就是文字而非聲音。

在小紅書上面，專業的脫口秀演員也會表達類似的觀點，這些在道理上都是相通的。

優秀的演講者往往會選擇先寫大綱，口播轉文字再對文字進行調整，以此保證聽眾體驗。

3.3 媒介之間的本質區別

不同媒介之間的根本性差異在哪？

個人目前觀察來看主要有兩點，模態和瞬間性。

媒介=模態*瞬間性

模態，人類與現實世界的交互模式，通常與感知器官有緊密聯系，常見的模態有文字、靜態/動態圖像、聲音等。

這三個基本模態根植于人類的視覺和聽覺，錐體經驗理論認為人類大部分學習過程都依賴于視覺和聽覺，從這個角度來看，這些基本上的模態恰好被理論所命中。

當然這也可能是雞生蛋蛋生雞的關系。不同的模態自帶的信息含量是不一樣的，文字是最抽象的，包含的信息含量最低，而圖像是最具象的，包含的信息含量最高。所以人們常說，看小說可以讓人發揮想象，看電視劇則會被束縛，正是因為文字的信息含量低，所以才有想象的空間。

當然，這里的信息含量指的是“絕對信息含量”，比如文本文件就是比圖像文件更小，但是這不代表念書學習效率會比看圖效率低，因為人類能夠攝取一個內容中的信息含量的能力是有限的。

好比和一個人交談一定是比通過電子郵件交流具備更加豐富的信息的，因為這個人有微表情，有神態，但并不每個人都能獲取和接收這些信息。

瞬間性是媒介的另一個根本特征，瞬間性是指對于一個內容來說，當它被某個媒介承載時，觀看者回顧其中某一個內容切片的成本。

下面是一組媒介和他們的瞬間性大小的排布，瞬間性越強，回顧成本越高：

單張圖片 = 短文字 < 組圖 < 長圖文 < 流媒體平臺上的視頻 < 播客平臺上的播客 < 電影院電影 < 音樂會的音樂 < 線下脫口秀

為什么線下脫口秀最難復制，因為它的創作過程都是伴隨線下的靈光乍現以及與觀眾的親密互動，人們再也無法踏入同一條河流。

對于單張圖片來說，雖然想要 100% 復制有困難，但是至少可以基于特定工藝進行打印，然后在對應亮度和色溫的燈光下觀看，就能獲得近乎于原作的效果。

瞬間性越強的媒介，對于情緒的要求就越高（對創作者和觀眾來說都是這樣），一組文字可以冷冰冰，但是播客不能有氣無力，并且這種媒介越可能要求創作者把創作和傳播本身融為一體。

還是拿脫口秀舉例子，脫口秀本身就是在舞臺上才能實現作品的完整創作的，所以創作過程和傳播過程本身就是一體的。

同時一個媒介越是強調編排，瞬間性就會被體現的越強，強調編排意味著讀者如果跳著閱讀或者跳躍回顧，都很難通過上下文獲得相同的體驗，只有完整的重新按照編排順序閱讀，才能獲得接近于第一次閱讀的體驗。

3.4 AIGC 的意義在于降低內容跨媒介甚至跨模態的門檻

在工作中其實我經常會有一個疑惑，為什么文檔寫了，還要問？

其實原因很簡單，因為人作為一個媒介，比文檔作為一個媒介對于人來說更加的友好。在某些場景下面提問者的問題是比較簡單的，看文檔就會很重。但是對于回答者來說，重復回答問題是不經濟的，這種矛盾就很適合用 AI 來解決。

很多時候我們覺得一個內容讀起來不舒服，可能不是內容本身的問題，而是這個內容的媒介導致的。

在英劇《是，大臣》中，漢弗萊曾經表示大臣的演講就是很無聊，因為內閣大臣演講稿撰寫目標不是取悅臺下的聽眾，而是上報紙。

所以為什么政客們在電視上的演講那么無聊，這下大家都明白了吧，因為他們大部分在念一些“會以文字形式發下去”的材料。

理論上來說我們如果要讓一個內容盡可能多渠道傳播，我們需要有人去做這個媒介的翻譯，并且這個成本非常高，舉例來說：如果想要把一個以文字作為原生媒介的內容轉化成播客錄音，這個轉化成本就會很高，因為這意味著在轉化過程中需要增加額外的信息（比如語氣和情感），這本身近乎于創作。

又比如對于一個公眾人物來說，如果不針對性的做演講訓練，拿到一個演講稿直接講的效果一定會很差，因為撰稿人是基于文字媒介撰稿，而聽眾則通過聲音這個媒介來接收信息。聲音比干巴巴的文字稿會多出來更多的信息，語氣、語速、抑揚頓挫等，這些如果指望演講者臨場發揮，那對演講者來說要求真的很高。

因為如果一個內容的原生媒介的瞬間性很強，大概率意味著它會包含更多的信息，不論是編排層面還是情感層面。

但是現在，AIGC 很大程度上就能替代人去完成其中最枯燥的 80 % 的工作了。比如如何把一個文本轉換成語音，可以用豆包 TTS 大模型，深情并茂。

在 AIGC 誕生之前，這是幾乎不可解的問題，一定是需要人類錄音的。

3.5 為什么要從媒介的角度去理解大模型的商業價值

其實大概就在 1 年前，我曾經嘗試總結大模型能做什么，當時總結的用途是：

• 總結：根據特定的要求分析大段的內容，并且按照內容給出對應的結論；
• 擴寫：根據特定的要求和范式，將少量內容擴充成大段內容；
• 翻譯：根據特定要求把一段內容無損的轉化成另一段內容；
• 意圖理解：大語言模型有非常強的意圖識別能力，可以非常好的理解用戶的意圖；

這些總結不能說是錯的，但是有幾個比較致命的問題。

1. 僅針對文字模態，沒有考慮多模態的情況；
2. 這更多的是一種歸納，并不能保證從邏輯上是 MECE 的；

如果從歸納法的角度來說，我們會認為大模型能干這個，不能干那個，可以舉無窮多的例子，但是如果想要試圖搞清楚這個東西擅長什么，不擅長什么，天花板在哪里，歸納法是沒有那么靠譜的。

如果從媒介的角度去看待大模型，我們可以發現它具有幾個能力是以前的技術不具備的：

1. 它能夠一定程度上理解內容，但是要想憑空創造內容還是有難度的；
2. 它在理解內容的基礎上，可以將一個內容修飾成另更適合一個媒介內容，也就是我們常說的總結、擴寫、翻譯；
3. 它能夠在理解內容的基礎上，將一個內容轉化成另一個模態的內容，也就是我們常說的文生圖；
4. 它能夠基于自己對大量素材的學習，在內容進行媒介或者模態轉化的時候，補充最合適的信息進去；
5. 因為它進行了大量的學習，所以如果它能夠被精確的控制意圖，它的效果會非常好；

所以讓我們回到上面的小節，回顧一下媒介的瞬間性的排序：

單張圖片 = 短文字 < 組圖 < 長圖文 < 流媒體平臺上的視頻 < 播客平臺上的播客 < 電影院電影 < 音樂會的音樂 < 線下脫口秀

在 AIGC 誕生之前，我們可能只能把右邊的內容轉化成左邊的內容。

在 AIGC 誕生之后，我們是可以把左邊的內容轉換成右邊的內容的，因為我們有了無中生有的能力！

這就是 AIGC 在媒介層面的意義，這個從生產角度來說是劃時代的。

還是拿上文提到的豎屏與橫屏例子來說，B 站的視頻是橫屏的，抖音是豎屏的，對于創作者來說，如何低成本的轉化呢？答案是用 AI 生成，擴展畫面。

四、以 RAG 的進化來探討圍繞大模型的長處和短處來制作產品

4.1 AI Agent 是什么？

GoogleMind和普林斯頓聯合發表了一篇論文《ReAct: Synergizing Reasoning and Acting in Language Models》，被公認為基于LLM的智能體的開山之作。

研究人員發現，在問答和事實驗證任務中，ReAct 通過與簡單的Wikipedia API交互，克服了推理中普遍存在的幻覺和錯誤傳播問題。

這個比去強化模型訓練強很多倍，原因是什么，大模型的大腦已經很強大了，很多時候再訓練下去邊際效用遞減很嚴重，給他一個 API，相當于給這個大腦增加“五官”，它自然就一下子進化了。

4.2 Auto GPT，第一個出圈的 AI Agent

AutoGPT 可以說是第一個真正意義上出圈的 AI Agent。

它嘗試設計了一個流程，任何問題都有一個通用的元思路去解決，每個負責解決問題的模塊都由一個 GPT 4 去驅動。

AutoGPT 的設計者認為這世界上幾乎所有的問題解決步驟都是類似的，明確問題，明確解決問題需要的步驟，完成任務，檢查，總結。

所以按照這個 SOP，他們涉及了一個互相之間傳遞信息的 AI Agent，每個模塊都是獨立記憶的模型，好像幾個人類在分工，一個專門負責明確問題，一個專門負責拆解問題。

AutoGPT 是由Significant Ggravitas 于 2023 年 3 月 30 日發布在 GitHub 上開源的AI代理應用程序。它使用 GPT-4 作為驅動基礎，允許 AI 自主行動，完全無需用戶提示每個操作，因其簡單易用在用戶中大受歡迎。上線僅三周，其 GitHub 的 Star 數量已飆升至接近10萬，早已超越了 Pytorch（65K），可以稱得上開源領域star數增長最快的現象級項目。

Auto-GPT 是基于 OpenAI API 開發的，它的核心在于基于最少的人工輸入/提示，利用 GPT-4 的推理能力解決更廣泛、更復雜的問題。在具體的執行上，程序會訪問互聯網搜索和收集信息，使用 GPT-4 生成文本和代碼，使用 GPT-3.5 存儲和匯總文件。

但是很快大家就發現這個 AI Agent 是有缺陷的，比如它很容易陷入死循環，或者是不能很好的解決不確定性的，帶有探索性質的問題，但是這個思路本身給大家帶來了非常多的提示。

擴展閱讀，Auto GPT 工作原理：

https://www.leewayhertz.com/autogpt

4.3 RAG 和 AutoGPT 的區別

RAG 其實就是檢索+生成的縮寫，明確了這個 SOP 主要的作用就是從特定的地方檢索出來信息，然后再以更加友好的形式展現出來。

如果一個產品有十幾篇說明文檔，那么 RAG 就好像是一個熟讀了文檔的客服。

最簡單的 RAG 可以參考 AI 搜索引擎 ThinkAny 第一版的原理：

MVP 版本實現起來很簡單，使用 NextJs 做全棧開發，一個界面 + 兩個接口。
兩個接口分別是：
/api/rag-search
這個接口調用 serper.dev 的接口，獲取谷歌的檢索內容。輸入用戶的查詢 query，輸出谷歌搜索的前 10 條信息源。
/api/chat
這個接口選擇 OpenAI 的 gpt-3.5-turbo 作為基座模型，把上一步返回的 10 條檢索結果的 title + snippet 拼接成上下文，設置提示詞，請求大模型做問答輸出。
以上文字引用自：
https://mp.weixin.qq.com/s/25eXZi1QgGYIPpXeDzkQrg

它 RAG 可以被視為是一種針對特定業務場景的 AI Agent，它和 AutoGPT 最大的區別在于三點：

1. RAG 的流程是一個串行流而不是一個循環，它沒有所謂的自我檢查然后重新生成的過程，一方面是為了響應速度，另一方面也是為了避免自我檢查造成的死循環；
2. RAG 的流程中，是檢索+生成，檢索的部分并不是由大模型完成的，而是通過傳統的搜索引擎（向量數據庫、關鍵詞匹配）來完成的，這和 AutoGPT 中幾乎所有關鍵節點都是用 GPT 4 完成是有天壤之別的，這意味著大家意識到一個問題，在一些對上下文窗口有要求的，輸出精確排序的場景，GPT 一點也不好用；
3. RAG 并不是萬能的，它設計出來也不指望自己能解決所有問題，實際上它更多的是解決“如何快速給答案”這個問題，有 10 篇文檔，怎么快速到找用戶需要的答案；

發展到這一步，大家已經意識到一個事情：這個世界上可能不存在一個萬能的 AI Agent，也就是說并沒有一個萬能的許愿機。

至少目前工程界很少有人會再嘗試投人力去做萬能的 Agent，學術界還在繼續。

可能有人會糾結概念，RAG 和 AI Agent 是兩個完全不相關的東西，而且 RAG 最早可以追溯到 2020 年的一篇論文，歷史比 AI Agent 更為久遠。但是其實我認為他們在工程落地上是非常相似的，都是強調基于工具，外部數據，存儲機制來彌補 AI 的缺陷，唯一的區別是 RAG 不會強調要求 AI 具備自我探索自行規劃任務的能力。

現在市面上的文章，尤其是面向非技術的同學的文章，關注概念多過關注落地，這不是一個好現象。工程領域本來就有很多約定俗成的叫法，比如廣告系統的 DMP，全名是 Data management platform，但是實踐的時候幾乎只管人群數據，總不能因為名字和實際干的事有差別就天天在那辯經。

這篇文章在介紹 RAG 的時候，就是希望從實現思路著手，給 AI 這個大腦一步一步配上了多套工具，乃至到最后替 AI 做了一部分流程設計。

希望通過這個文檔去展現一個循序漸進的，也是從抽象到具象的具體落地過程，為了保證文檔本身的可讀性，列舉的項目并不是完全一脈相承的，但是我認為這樣的寫作順序對于讀者來說是最友好也是最具有啟發性的。

4.4 RAG 的缺陷是什么？

論文《Seven Failure Points When Engineering a Retrieval Augmented Generation System》中列舉了 RAG 的 7 個弱點。

論文地址：https://arxiv.org/abs/2401.05856

通過這些故障點，我們可以發現一個問題，其實有很多故障點本身和大模型沒有關系，比如搜索文檔 Top K 的排序不夠精確，比如無法從文檔中讀取信息，因為文檔格式錯誤或者文檔太臟了。

就像我們前面所說的比喻，大模型本質是一個大腦，AI 產品才是大腦搭配上五官，軀干和四肢。

不能只優化大腦，不優化四肢，那是一種偷懶行為，不要把大模型視作為萬能的許愿機器。

最后讓我用一個兒歌來總結一下這篇文檔的核心思想：

人有兩個寶，雙手和大腦。
雙手會做工，大腦會思考。
用手又用腦，才能有創造。

4.5 Graph RAG — 一種 RAG 的進化版本

Graph RAG 是微軟開放的一個開源的 RAG 框架，可以被視作為是一種進一步變化和迭代的 RAG SOP，根據公開資料參考，我猜測這套技術實現思路廣泛地應用在了微軟的 Copilot 系統上，當然我沒有找到可以證實的材料。

Graph RAG 和原本的 RAG 的區別是什么呢？

傳統 RAG 的主要工作是這三個步驟：

1. 把待搜索的知識做向量化處理（可離線處理）；
2. 當用戶提出來一個關鍵詞 or 問題，根據相似性查詢查出來最相關的內容（必須是在線服務）；
3. 將查詢出來的 Top N 的相關內容作為上下文，和用戶提出的問題一起交給大模型來生成內容（必須是在線服務）；

相似性查詢的效果其實是比較不盡如人意的，因為它完全是根據文字的相似水平來進行檢索，和文本的語義一點關系都沒有。這就導致最終 RAG 的效果往往會比較糟糕。

當然這三個步驟中間出問題的可能性很多，就像上文提到的 RAG 的 7 個待優化點，但是檢索的準確性是一個最容易優化并且收益也最大的問題，那么微軟是怎么做的呢？

微軟認為用戶可能會詞不達意，同時檢索也需要更加智能，所以微軟將向量化檢索的方法替換成借助知識圖譜的檢索方法。

Graph RAG 的主要工作是下面三個步驟：

1. 將待搜索的知識進行一個三元組抽?。ㄖ髦^賓），這個抽取的動作需要 LLM 介入，存入圖數據庫中（可離線處理）；
2. 將用戶提出來的關鍵詞，用 LLM 做一次擴散，擴散出來同義詞，近義詞等，然后在圖數據庫進行檢索，找到相關文檔（必須是在線服務）；
3. 將查詢出來的相關內容作為上下文，和用戶提出的問題一起交給大模型來生成內容（必須是在線服務）；

整體的步驟和架構其實沒有更多的變化，但是在關鍵步驟上引入了大模型，作為兩個獨立的處理步驟。

注意，這里的獨立處理步驟是非常關鍵的。

4.6 RAG 再進化（雕花）

在微軟發布了 GraphRAG 之后，很多人都試用了，然后又發現一堆問題，于是有人發了這篇論文：《A Hybrid RAG System with Comprehensive Enhancement on Complex Reasoning》。

論文地址：https://arxiv.org/abs/2408.05141

Hybrid RAG 在原來的基礎上，做了幾件事。

工作 1、Document 在 Loader 之前，先用 LLM 做一輪格式上的處理。

工作 2、問題分類機器

這個問題分類機器本身是一個 SVM 分類器，但是這個分類器的訓練數據不是人工標注的，而是用大模型來標注的，以此減少成本和開銷。

工作 3、利用大模型調用外部的計算庫

當然，這篇論文里面還寫了很多思路，感興趣的同學可以自己去看論文。

這個論文質量還是很高的，6 個作者中的 5 個是北京大學人工智能實驗室的學者。

五、為什么我們曾經高估了大模型的影響力

5.1 我們原本設想的端到端的場景問題是什么？

現在人類生產視頻的工業化流程是：

1. 看一下市面上熱門視頻的共性，往往依靠標簽
2. 根據熱門標簽生產一些腳本；
3. 拍攝；
4. 發到線上看數據反饋，再做迭代；

在大模型剛剛誕生的時候，其實有一個假設，假如大模型可以直接生成視頻，能不能讓它看抖音上的大部分視頻，訓練它，然后讓它生產一部分。

讓用戶給這些大模型生產的視頻點贊，大模型再把高贊的視頻拿來作為正反饋繼續生成視頻。

如果這條路能走通，對于抖音這樣的內容平臺絕對是顛覆性的，現在看這個流程可以說是走不通的，其中自然有視頻生成模型質量不好、不可控的原因，但是我認為更多的原因在于：

1. 模型的上下文窗口限制
2. 模型的成本太高

這兩個是幾乎無解的問題，估計未來相當長（10 年）的時間都很難解決，所以我不認為這種端到端的場景是可行的。

但是 AI 生成視頻一定會成為視頻工作者未來工作環節的重要補充，這點是不需要懷疑的。

5.2 所有應用都值得用 AI 重做一遍嗎？

顯然不，因為這個世界上 90% 的事情用規則就已經可以運轉的很好，模型低效又不穩定。

很多時候我們對一個產品的要求就是，簡單、高效、可以依賴，現階段模型的不穩定性注定了它在很多場景下是不可依賴的，哪就很難談得上取代原有產品。

還是重讀一遍俞軍給的知名的需求公式：

用戶價值= 新體驗– 舊體驗– 替換成本

很多時候用了新技術，收益可能也沒有想象的那么大，這是一個事實。認為所有應用都值得用 AI 重做一遍的人顯然是高估了 AI，很多人喜歡把 AI 和移動互聯網類比，這是不恰當的。

從馮諾依曼計算機的架構來看，移動互聯網直接把計算機的輸入輸出設備給改了，這首先帶來了交互上的革命性變化，但這不是最重要的。

從市場上來看移動互聯網真正的價值并不是交互革命，而是極大的降低了用戶接入互聯網的成本，使得用戶數量得到了翻倍，延長了用戶互聯網的使用時間。

上面這兩個革命性的變革，顯然是這輪 AI 浪潮所不能及的，AI 既不能擴大市場，短期內也不能改變計算設備的形態。

大模型的變革更多的會體現在生產端，從而影響消費端，正如在上文理解媒介一個章節中提到的，它能帶來的是生產力的極大提升，但我們現在面臨的問題更多的是市場不足，生產過剩問題。

5.3 LUI 是萬能的嗎？

有人說這一輪 AI 會帶來交互革命，從今天起我們只需要一個有聊天框的超級 App 就可以啦！

我現在就可以下這個結論，說這話的人一定是云玩家，如果這種人在公司里面，我是他的上級，我就要懲罰他晉升答辯不準寫 PPT 和文檔，只允許口播。

任何一種媒介和交互都是有最佳實踐和獨特價值的，LUI 顯然不是萬能的，程序員寫個代碼還會考慮 IDE 的 GUI 好不好使，Language UI 信徒們哪來的自信這玩意可以徹底取代圖形界面？

LUI 最大的問題就是效率低，讓我以企業級軟件舉例：

Excel 也好，PowerPoint 也好，哪怕是 BI 軟件也好，軟件除了降低門檻之外，還有一個很重要的作用就是「約束」使用者。

在這個場景下約束不是一個貶義詞，是一個褒義詞。這些軟件內置的所有功能都是在漫長的時光中迭代出來的，里面凝聚了無數軟件開發者與使用軟件的企業的經驗和最佳實踐。

打開 Sensors Analysis（神策數據旗下）和 DataFinder （火山引擎旗下）這兩個產出自不同公司的行為分析軟件時，會發現二者的功能極為相似，事件分析、漏斗（轉化）分析、留存分析等等。我甚至懷疑使用這些軟件的企業客戶們使用習慣也會高度類似，因為這些軟件里面凝聚的功能本身就是最佳實踐。

對于一個沒有什么統計分析能力的運營來說，讓他去面對 GPT 的文本框描述清楚自己需要一個漏斗分析實在是太困難了，還是用神策比較簡單。

GPT 如果能夠獲得關于漏斗分析的詳細計算邏輯，也可以一定程度上的引導用戶，但前提是用戶得能說出來“漏斗分析”這四個字，實際上脫離了界面很多人都不見得能描述的清楚自己想要的是什么。

LUI 不是萬能的，對 LUI 的過度追求，甚至把 LUI 與 AI native 劃等號這種想法都是錯誤的。LUI 只是在特定范式下才是有意義的。

5.4 復雜的 UI 是一段彎路嗎？

現在市面上最領先的開源文生圖 UI 叫做 ComfyUI，如下圖所示：

ComfyUI 和我們腦子里面想的敲敲文本就能調用的文生圖 AI 差異很大，感覺更像是一個低代碼平臺，為什么？

因為在工業界需要追求精確控制，純粹用提示詞是無法準確表達精確控制的語義的，必須得用 GUI 才能表達出來。

比如上面這個圖，其實里面做的事情就是把一個建筑物換成另外一個建筑物，并且盡可能不要改變其他東西，這種精確控制對于模型這種本質依靠數學概率驅動的東西來說是非常困難的，所以才搞得這么復雜。

那么問題來了，上面這種 UI 是一段彎路嗎？

其實我乍一看我也覺得這個太離譜了，如果讓我用 Photoshop 或者醒圖類似的事情應該也能做，而且 UI 應該沒有復雜，但是細想之后我認為這個東西非常有價值。

我認為如果把這種 UI 給到用戶，這肯定是一段彎路，但是如果我們把上面這個操作包裝成一個場景，給用戶的就是讓用戶上傳兩張圖這樣的動作，這不就是一個最簡單的產品了嗎？

也就是說我上面說的，醒圖和 PhotoShop 的功能，其實以后完全是可能用這樣的 UI 搭建出來然后包裝給用戶的。

所以上面的 UI 是完全可以提供給專業用戶的，這樣的 UI 可以變成一個引擎，產品內成千上百的功能都可以通過這么一個元引擎被源源不斷地生產出來。

這就是大模型真正的價值，這是生產力成百倍的提升。

5.5 大模型真正的價值是什么？

如果大模型既不能給交互帶來質的變化，又不是一個萬能的許愿機，甚至連端到端生成 Feed 流都做不到，那么大模型真正的價值是什么呢？

大模型真正的價值在于給產品經理和工程師這樣具備非凡創造力的人一個增幅器。

這是一個不需要訓練的萬能模型，而且大概率比專屬模型更強。

這意味著產品經理和工程師只要能想清楚 SOP，想清楚哪些問題可以用大模型來解決，就一定能以比較低的成本解決，原本一些需要訓練自己私有模型的事，現在依靠公有模型就可以解決了。

很多原本像高山一樣的成本，現在也是可以逾越的，金錢和數據量不再是訓練模型的攔路虎，你只需要會寫 prompt ，會搭工作流就可以了。

六、對產品經理的工作方法啟示是什么？

6.1 業務！業務！業務！數據！數據！數據！

新鮮的數據和能持續產生新鮮數據的業務，是一個大模型的生命力所在。

一個 RAG 做的再牛逼，如果數據庫很糟糕，結果就是很糟糕的。

一個模型再挫，只要數據足夠好，照樣是一個好工具。

在 AI 時代，數據的問題只會被放的更大，AI 搜索如果在一堆屎山數據里面做搜索，充其量不過是又造了一根攪屎棍。

任何時候，能持續生產真實交易數據和優秀內容的業務都比大模型本身重要。

6.2 看論文不是產品經理避免 FOMO 的最佳途徑，動手嘗試可以避免 FOMO

我認為一個比較清晰的事實是，目前工業界短期內一定高估了大模型的作用。

前段時間我寫了一個段子：每一個 App 都值得思考是否能用 AI 重做一遍，然后就會發現值得重做的只有 10%。

短期內的資源投入很大程度上是源自于投資人和大廠決策者的 FOMO 心態，這種心態某種角度來說是不健康的。這種 FOMO 的心態也會傳導給產品經理，于是很多產品經理都開始看論文（比如本文作者），但在我看來產品經理看論文其實沒什么用，圖一樂的作用更大。

論文都是錘子，但是對于 PM 來說更重要的是釘子在哪里。所以與其關心最新的學術界又發了什么，不如關心一下 Product Hunt 上面哪些 AI 產品又登上了當日第一，并且賺錢了。

與其 FOMO，不如動手多用用，以前移動互聯網剛剛興起的時候，大部分產品經理手機里面不得裝小幾百個 App，天天研究來研究去的。去用一下市面上最好的應用，并且嘗試逆向它，會有多很收獲。

寫這篇文章，寫接近 2 萬字，發現大模型那么多的坑，而且每個坑都能找到一些關聯的論文。不是因為閑的蛋疼去看論文，而是因為一直在搗鼓 AI，然后發現這也有問題那也有問題，不得已去搜索，搜到了論文。

原來大家都有這個問題，有的人就是有鉆研精神，發現了問題還會深入研究，然后寫一篇論文。哎，人比人真的氣死人。

如果仔細看就會發現我看的大部分論文都是工程師論文而不是算法論文，因為就像我強調的，大模型的弱點需要工程彌補，工程是研發和產品經理共同搭建的，看不懂算法的論文不打緊，看不懂工程師的論文可能真的得反思一下。

6.3 產品經理必須要學會自己調用 API

正如文提到的，未來 AI 產品團隊的能力，不取決于誰家模型更強，反正開源模型一定最終會變得最強，而取決于誰家能用好 AI 模型。

而誰能用好 AI 模型，又取決于哪個團隊做實驗的本里強，誰能更快的做完更多的實驗，誰就牛逼。

有的人可能會問，我用 coze 或者是 KimiChat 行不行，我的答案是不行。

因為這兩個本身就已經是 AI 產品了，和 AI 的 API 差距很大，給 KimiChat 傳個 PDF，人家解讀的又快又好，你怎么知道它解讀的好是因為模型牛逼，還是因為 PDF 格式轉 MD 數據清理的好呢？

這就需要產品經理必須要具備非?？焖俚穆阏{用 API 做實驗的能力。

那么不會寫代碼，怎么快速獲得這種能力？用 Dify 或者 n8n 這樣的低代碼平臺來解決。

就我自己來看，我認為 n8n 更靠譜。n8n 是一個 Coze 的開源免費上位替代，一個可視化低代碼自動化 Workflow 平臺，能夠方便的讓不會寫代碼的朋友體驗 AI 開發的樂趣和效果。

用它可以輕易的創建很多扣子完成不了的復雜自動化 Workflow。比如 Webhook 觸發，比如 1000 多種第三方接入，比如發起自定義的 HTTP Request。

并且因為 n8n 不是從這一輪 AI 浪潮才開始做的，所以它的生態也比這一輪 AI 后才涌現出的 Workflow 工具（比如 Dify）更完善，官方接入的集成服務更多，社區更活躍。

n8n 就是大模型的五官、軀干和四肢，動手又動腦，才能有創造。

在這里我推薦一個 n8n 的中文教程《簡單易懂的現代魔法》，這應該是目前市面上最好的 n8n 中文教程。

教程地址：https://n8n.akashio.com/

6.4 幾個 AI Agent 實踐的建議

6.4.1 設計 Agent 的關鍵思路

想象一下 20 個實習生幫你干活，你要怎么分配任務？實習生的特點是什么？

• 能執行
• 無法拆解復雜問題
• 執行順序可能是有問題的，你如果不規定執行順序，會怎么樣？可能會拖慢項目進度
• 記憶力一般，一下子太多任務記不住，可能會忘記
• 可能會出錯，所以最好有交叉驗證

所以如果你把 AI 視作為一個又一個不知疲倦的實習生，你認為他們能干嘛？當然是設計好 SOP 和產出物標準，讓他們去做這些量大且重復性的工作啦。

當然實習生和 AI 有一個比較大的差別，就是 AI 確實比實習生，甚至不少正式員工在解決特定問題的時候強很多。

也貴很多，GPT-4 回答一個問題一個來回 API 的定價可能在 3 美分左右。

人比機器便宜，可能是未來大家不被 AI 淘汰的重要理由（bushi）。

6.4.2 把任務拆小拆細，避免互相影響

把一個復雜問題拆成多個簡單問題，然后再讓模型處理有兩個好處：

第一、正如上文所描述，大模型的不穩定性和它接收的文本規模大小完全是呈正相關的，如果把問題拆小就意味著單詞任務模型要處理的文本變少。

第二、一些簡單的問題根本沒必要用大模型，甚至可以用簡單的模型或者是純邏輯去判斷，更便宜、速度更快，甚至效果可能會更好。

6.4.3 區分離線任務和在線任務

以 Grpah RAG 架構為例子， 它一共分為三個步驟：

1. 將待搜索的知識進行一個三元組抽?。ㄖ髦^賓），這個抽取的動作需要 LLM 介入，存入圖數據庫中（可離線處理）；
2. 將用戶提出來的關鍵詞，用 LLM 做一次擴散，擴散出來同義詞，近義詞等，然后在圖數據庫進行檢索，找到相關文檔（必須是在線服務）；
3. 將查詢出來的相關內容作為上下文，和用戶提出的問題一起交給大模型來生成內容（必須是在線服務）；

其中前兩個步驟是離線任務，離線任務意味著可以花費較多的時間對數據做精細化的處理，比如我們可以用一個開源但是性能強悍的大模型，用自己的服務器去跑任務，以此來在保證質量的時候降低成本。

而在線任務則意味著需要較強的時效性，如果在線任務本身復雜度并不高，也可以選擇更加輕量級的模型來保證回復速度。

同時離線任務的結果會被存儲并且反復調用，用質量更好的模型相當于做了一些固定成本的投入，而在線任務都是和用戶交互直接相關的，這些本質上是邊際成本。

6.4.4 每一個離線任務都可以考慮用模型來解決

在 Hybrid RAG 中，對 html 轉 MD 的工作用的是 Python 庫進行的，其實這項工作如果純粹追求效果的話，完全可以考慮直接用大模型來做。

當然具體是用 Python 庫還是用大模型，其實是取決于成本和效果的考量的，這個也需要通過實驗來證明。

我自己的經驗是這種數據清洗的工作適合用 Python 庫做一輪，再用大模型做一輪清洗，效果可能會更好，但是很多時候 Python 庫已經足夠干凈了，中間夾雜一些錯誤的格式編碼其實也不影響后續大模型的判斷，這種情況下做不做都是無所謂的。

總而言之大模型在特定環節的工作能力是非常強的，如果不是考慮成本，其實幾乎每個環節都可以用大模型解決。

6.4.5 成本和效果要做 Trade off

眾所周知，大模型回答有一定的隨機性，要怎么解決這個問題呢？當然是一個問題重復問幾遍啦。

比如論文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》中提到的如何測試兩種 RAG 方法的效果，用人力標注太麻煩了，所以他們連檢查樣本的工作都交給大模型來做了，真是牛逼（有錢）。

為了保證結果正確，一個標注要重復做 4-5 遍，成本自然也是 4-5 倍。

對于設計產品的同學來說就非常需要判斷成本和效果之間怎么平衡了。

6.4.6、Agent、微調、提示詞之間的邊界與最佳實踐

如果我們把提示詞工程、Agent 的建設和模型微調對應到我們給一個人布置任務，就可以這么理解。

• 提示詞工程相當于你在布置任務的時候說的很詳細。
• Agent 建設相當于你給這個人布置任務的時候，把 SOP 拆清楚，并且告訴他公司里面有哪些工具可以用。
• 模型微調相當于做培訓。

所以完成一個任務，可能三種手段都需要用上，但是三種手段的成本是不一樣的。

而為了完成一個任務，應該用哪種優化手段，這就是目前工程、算法、產品、學者這幾方面都非常模糊的地方，這個就好像是在航海或者挖礦，又像是臨床醫學，怎么決定用什么手段，本質上是一個“實驗”，而不是一個“推理”。

這也就是為什么上面列出來的每一篇論文都需要列非常多的基準測試，因為設計這些 Agent 的人自己都不知道結果到底好不好，需要實驗才能驗證。

所以我認為，未來哪個團隊應用 AI 的能力強，哪個團隊應用 AI 的能力弱，其實就取決于：

1. 這個團隊有沒有牛逼的基準測試參考答案；
2. 這個團隊能不能有一個平臺可以更快的驗證自己的設計是不是合理的；

誰實驗做得快，誰就牛逼，工程化產品化反而是最后一步。

最后我個人建議是能不要微調，就不要微調，因為微調會改變模型的參數層，成本很高而且無法遷移。而且微調的本質是在和大模型團隊卷算法，卷數據，內卷在長期來看，是沒有意義的。