2萬字長文,如何成為一個“懂”AI 的產(chǎn)品經(jīng)理?
隨著人工智能技術(shù)的快速發(fā)展,大模型已經(jīng)成為推動產(chǎn)品創(chuàng)新和業(yè)務(wù)增長的關(guān)鍵因素。對于產(chǎn)品經(jīng)理而言,理解AI的工程化、局限性以及如何將AI技術(shù)有效融入產(chǎn)品開發(fā)流程,變得尤為重要。本文深入探討了AI產(chǎn)品工程化的理解、大模型的局限性,以及如何成為一個真正“懂”AI的產(chǎn)品經(jīng)理。
注:本文成文與 2024 年 9 月 1 日,隨著時間推移,文章中的結(jié)論可能會發(fā)生變化。
此外,本文面向的讀者是非算法團(tuán)隊(duì)的產(chǎn)品經(jīng)理,為了保障文章的可讀性,可能會省略部分細(xì)節(jié),同時文章重點(diǎn)是工程落地而非學(xué)術(shù)探討,不具備任何辯經(jīng)的價值。
一、理解 AI 產(chǎn)品的工程化
坦率來說 2024 年圍繞大模型,產(chǎn)品的發(fā)展速度比之前預(yù)期的要低一些,比如在 BI 領(lǐng)域,Chat BI 聲量很大,但落地下來效果并不好,這個也很正常,因?yàn)槊總€人總是會在短期內(nèi)高估技術(shù)帶來的價值,而在長期范圍低估技術(shù)帶來的價值。
這里面有客觀的原因,一項(xiàng)技術(shù)基底在真的應(yīng)用到行業(yè)的方方面面本身就是需要過程的,因?yàn)檫@項(xiàng)技術(shù)需要去和原本的實(shí)現(xiàn)方案做競爭,就像俞軍給的知名的需求公式:
用戶價值= 新體驗(yàn)– 舊體驗(yàn)– 替換成本
很多時候即使用了新技術(shù),收益可能也沒有想象的那么大,這是一個事實(shí)。
另一個原因就是從業(yè)者的理解問題,哪怕是在一些大型互聯(lián)網(wǎng)公司內(nèi)部,大部分人對大模型的優(yōu)勢和劣勢分別是什么,這個“事實(shí)”是存在一些理解上的代差的。
因?yàn)楝F(xiàn)在技術(shù)進(jìn)步的很快,各種實(shí)踐路徑五花八門,有的人會覺得這玩意無所不能,有的人會覺得這個東西根本沒法用。
為什么不同的人對這個東西理解的差異這么大?很大程度上是因?yàn)樗麄儧]有理解大模型作為一個接口和大模型作為一個產(chǎn)品的區(qū)別。
大模型可以被視作為是一個函數(shù),一個 API,它本身只能被調(diào)用,而大模型產(chǎn)品才是真正面向用戶的東西。
比如我給大模型的 API一個 Excel,它會告訴我,不好意思我沒辦法讀取這個文件的內(nèi)容。但是我們在 Kimi 的聊天框里面,就可以讓 Kimi 解釋 Excel 內(nèi)的內(nèi)容,為什么有這個差異?
因?yàn)?Kimi 是大模型產(chǎn)品,背后跑的是 Moonshot-v1 的模型,Kimi Chat 會讀取你的 Excel,然后轉(zhuǎn)化成XML 信息給到大模型。(我猜的)
模型在做工程化變成產(chǎn)品的時候往往會添加很多限制,這些限制可能是做在產(chǎn)品層面的, 而不是 API 本身限制的,比如很多產(chǎn)品為了降低成本會限制用戶上傳 PDF 的大小,但是如果用 API,就沒有這個限制,或者限制可以放的很大,但前提是需要首先把 PDF 轉(zhuǎn)化成模型能夠理解的文件形式。
市面上產(chǎn)品做了很多的工程轉(zhuǎn)化,甚至是 Function Recall 的工作,直接使用產(chǎn)品,不利于產(chǎn)品經(jīng)理了解大模型的優(yōu)勢和劣勢,就不利于應(yīng)用大模型,改進(jìn)現(xiàn)有產(chǎn)品。
那么為什么我認(rèn)為產(chǎn)品經(jīng)理比起大模型產(chǎn)品,更應(yīng)該關(guān)注大模型本身(API),因?yàn)閺?API 到產(chǎn)品,這中間的工程轉(zhuǎn)化過程,是產(chǎn)品經(jīng)理們最需要關(guān)注的。
大模型好比是一個大腦,工程師和產(chǎn)品經(jīng)理就需要給大模型設(shè)計(jì)五官,軀干和四肢。腦殘和手殘都是殘,所以工程師和產(chǎn)品經(jīng)理對于決定一個 AI 產(chǎn)品最后好不好用是非常重要的,頭腦發(fā)達(dá)四肢簡單和四肢發(fā)達(dá)頭腦簡單最終都解決不了用戶的產(chǎn)品。
甚至可能前者對于用戶來說會更糟糕一些。
要做出優(yōu)秀的 AI 產(chǎn)品,不僅僅需要優(yōu)秀的大模型,還需要優(yōu)秀的工程師和產(chǎn)品經(jīng)理來輔助大模型。
這就需要產(chǎn)品經(jīng)理非常了解兩件事:
- 現(xiàn)階段的大模型有哪些局限性,這些局限性哪些是可以通過模型迭代得到解決的,哪些是不能的。
- 從更底層的業(yè)務(wù)角度去分析,大模型在商業(yè)意義上真正的價值在哪?注意,這里強(qiáng)調(diào)的是業(yè)務(wù)視角,不是讓產(chǎn)品經(jīng)理去讀論文。
二、大模型的局限性是什么?
2.1 一些可能永遠(yuǎn)都無法被解決的問題
2.1.1 成本、性能與響應(yīng)速度
想要追求性能越強(qiáng)的大模型,就越需要越高的計(jì)算成本。
計(jì)算成本會帶來兩個問題:
- 直接造成的金錢成本;
- 響應(yīng)速度;
下圖是 Apple Intelligence 的架構(gòu)圖,其中在端上有兩個模型,而在云端還有一個基于隱私云計(jì)算的大模型。
為什么蘋果要做這種工程上大小模型的設(shè)計(jì)?
因?yàn)樘O果希望大模型的響應(yīng)速度能夠追上 Siri 現(xiàn)在的性能,同時移動設(shè)備對功耗本身是有要求的,再加上蘋果非常重視隱私,希望 80% 的問題能夠在用戶本地得到解決,所以采用了這樣的架構(gòu)。
運(yùn)行 meta 最新開源的 llama 3.1,70 b 版本需要大概 70 GB 的顯存,405 b 版本可能需要 400 GB 的顯存,可能需要并聯(lián) 100臺 iPhone 才能運(yùn)行這些模型。
這種大小模型的設(shè)計(jì),需不需要產(chǎn)品經(jīng)理,當(dāng)然需要,什么問題適合小模型解決,什么問題適合大模型解決,這顯然不僅僅是 RD 需要去回答的,也需要有產(chǎn)品經(jīng)理參與,負(fù)責(zé)如下部分:
- 收集目前用戶的 Query;
- 從解決難度、隱私、對時效性的要求、對準(zhǔn)確性的要求對 Query 進(jìn)行分類;
- 設(shè)計(jì)基準(zhǔn)測試,獲得大小模型分界的標(biāo)準(zhǔn);
- 持續(xù)追蹤優(yōu)化;
在未來至少很長一段時間,還是會有大量的本地/聯(lián)網(wǎng)之爭的,這個就是產(chǎn)品經(jīng)理的機(jī)會。
2.1.2 窗口大小與不穩(wěn)定
我們經(jīng)常會看到,XXX 大模型支持 128K 上下文了,引來大家的一陣狂歡。
我們又會經(jīng)常看見,XXX 大模型幻覺問題很嚴(yán)重,引來一陣吐槽。
上下文是什么意思?其實(shí)就是大模型在一次請求的過程中,能夠接收的最大的信息的數(shù)量。我們在和 ChatGPT 聊天的時候會發(fā)現(xiàn)有的時候它聊著聊著會忘記之前自己說過的話,其實(shí)就是因?yàn)榱奶煊涗浺呀?jīng)超過了上下文的數(shù)量。
幻覺的意思則是大模型很容易會胡說八道,胡編亂造一些事實(shí)上不存在的東西,尤其是當(dāng)它已經(jīng)忘記前面和你說什么之后,你再問他類似的問題,它就會開始胡說。
很像一個渣男,你們已經(jīng)牽手了。
你問:“我叫什么名字?”
他回答:“當(dāng)然叫親愛的啦?!?/p>
其實(shí)他已經(jīng)不記得名字了,所以就開始胡編亂造了,絕了,這玩意真的很像人類。
根據(jù)英偉達(dá)的論文 《RULER: What’s the Real Context Size of Your Long-Context Language Models?》來看,大部分模型宣傳的上下文窗口基本上就是在扯淡,在極限長度的情況下,各家大模型對正確水平,是沒有保障的。
比如說一個模型宣傳自己支持 128k 的上下文(意思是差不多可以讀一篇 20 萬字的小說),但是實(shí)際上如果你隨機(jī)塞一些句子進(jìn)這篇小說,然后讓大模型回答和這些句子有關(guān)的知識,它是有比較大概率答不出來的,它的性能會隨著上下文窗口的變大而衰減。
如下圖所示,以 GPT4 來說,當(dāng)上下文超過 64k 時,性能就開始驟降:
實(shí)際情況來說,我認(rèn)為這些模型的表現(xiàn)會比你想象的更加糟糕。
我讓 Claude 3.5 Sonnet 模型分析了一段的 SQL,這是一個 700 行的復(fù)雜 SQL,但是總體來說邏輯應(yīng)該是比較簡單的, 而且?guī)缀趺恳恍?SQL 都有注解,在這種情況下,Sonnet 就開始胡說八道了,說了一個 SQL 里面根本不存在的表。
不排除是因?yàn)槲以?Monica 的客戶端里面調(diào)用 Sonnet 造成的,不知道 Monica 調(diào)用的時候是不是加了什么 Prompt 干擾了模型。
如何在保證解決用戶問題的時候,避免受到上下文的影響和干擾呢?
其實(shí)這個事情也需要產(chǎn)品經(jīng)理的干預(yù),比如:
- 研究能否把長文本切成多個段文本,并且不影響最終的結(jié)果;
- 研究怎么給 AI 外掛一些能夠超長時間記憶的記憶庫;
舉例來說,掘金上面有一篇文章《多輪對話中讓AI保持長期記憶的8種優(yōu)化方式(附案例和代碼)》,就講述了 8 種主流的方法,這些方法都應(yīng)該是產(chǎn)品經(jīng)理根據(jù)業(yè)務(wù)場景去選擇的。
文章地址:https://juejin.cn/post/7329732000087736360
最后聊一聊為什么我認(rèn)為上下文窗口與不穩(wěn)定的問題是一個長期內(nèi)很難解決的問題。
在過去的一段時間,上下文窗口大小的問題其實(shí)是的到了一定程度的緩解的,但是根據(jù)英偉達(dá)的論文我們也可以發(fā)現(xiàn),上下文窗口的大小和穩(wěn)定的抽取內(nèi)容避免幻覺這兩個指標(biāo)在很大程度上就是互斥的,就像是推薦系統(tǒng)的準(zhǔn)確率和召回率指標(biāo)一樣。
這也就意味著在很長一段時間我們可能都沒有兩全之策,除非突然出現(xiàn)一個模型一方面解決幻覺問題,一方面能保證巨大的窗口。
而且在實(shí)踐的時候我們往往需要避免極端 Case 的發(fā)生(比如我自己遇到的 700 行 SQL 解析錯誤),減少上下文的規(guī)模是很重要的手段,此外不同的檢測手段下其實(shí)模型的表現(xiàn)并不完全一致,也就是說不同的業(yè)務(wù)場景,幻覺問題的嚴(yán)重程度其實(shí)是不一樣的。
模型能夠容納的最大窗口和有效工作窗口是兩個概念,并且不同的任務(wù)的有效窗口大小可能是非常不一致的。
我當(dāng)然希望我的想法是錯的,目前而言我看不到任何模型能夠在這件事情上有突破的可能性, 有一家公司叫 Magic,推出了一個號稱具備了 1 億 token 上下文窗口的模型,但截止到目前為止(2024.9.1)并沒有發(fā)布任何的論文或者更實(shí)際的東西。
還是那句話,最大窗口和有效工作窗口是兩個概念。
此外,多模態(tài)的發(fā)展某種角度來說會加劇窗口大小不足的問題。
2.1.3 函數(shù)本身不可能被自調(diào)用
有的時候會嘗試在提示詞里面撰寫,比如我給你一個 xml,希望你能夠遍歷。通常來說,大模型是不會執(zhí)行這個要求的。
原因也很簡單,它本身作為一個函數(shù),無法自我調(diào)用,而這個函數(shù)因?yàn)榛糜X的問題,也不可能做到精確回復(fù),甚至?xí)?N 行數(shù)據(jù)混雜在一起去分析,所以這類循環(huán)遍歷的要求,通常得不到滿足。
不支持自調(diào)用的原因也很簡單,一次請求交互內(nèi),如果支持循環(huán),那么就可能在 API 內(nèi)直接調(diào)用大模型成百上千次,這個調(diào)用成本 API 的提供方是不可能承擔(dān)的,
由于大模型本身是高度不穩(wěn)定的,所以我們會非常需要通過一個循環(huán)/條件判斷來去控制它,不支持自調(diào)用就意味著我們必須要在外部通過工程化來實(shí)現(xiàn)哪怕在人類看來最簡單的遍歷操作。
2.2 一些工程上的難點(diǎn)
2.2.1 不再互聯(lián)的互聯(lián)網(wǎng)
Apple 開創(chuàng)了移動互聯(lián)網(wǎng)時代,但是也造成了一個最為人詬病的現(xiàn)象——花園圍墻。
原本大部分網(wǎng)站是面向搜索引擎和人類搭建的,也就是說爬蟲可以很簡單的獲取一個網(wǎng)站超過 90% 的內(nèi)容。
這些對于 AI 來說至關(guān)重要,我舉個例子,就是針對同一個問題,豆包和元寶的回答質(zhì)量差異:
很明顯,豆包的回答質(zhì)量更加差,說一句又臭又長不過分,RAG 領(lǐng)域的最新進(jìn)展確實(shí)是微軟開源的 GraphRAG,這點(diǎn)在豆包的回答里面根本沒有體現(xiàn)。
比較逗的是,騰訊混元引用了火山引擎的資料,但是豆包引用了一個不知道媒體的資料。
豆包的模型能力是比騰訊的混元大模型要強(qiáng)的,混元大模型用騰訊內(nèi)部的話說,狗都不用,為什么從最終的呈現(xiàn)結(jié)果來說,豆包的結(jié)果不如混元呢?
因?yàn)轭^條的數(shù)據(jù)沒有微信公眾號的數(shù)據(jù)好。
為了解決互聯(lián)網(wǎng)不在互聯(lián)的問題,Apple 希望從操作系統(tǒng)層面把 UI 打造的面向大模型更友好,并且發(fā)布了一篇名為《Ferret-UI:基于多模態(tài)大語言模型的移動 UI 理解》(https://arxiv.org/pdf/2404.05719)的論文,但是我覺得更加開放的 API 和內(nèi)容才是根本途徑,因?yàn)樘O果的互聯(lián)互通是僅限于 iOS 生態(tài)的。
而對于產(chǎn)品經(jīng)理來說這些自然也是發(fā)揮的空間:
- 上哪搞到更好的數(shù)據(jù);
- 如何讓 AI 調(diào)用別人家的 API 并且把結(jié)果拿來為自己所用;
- 怎么把蘋果最新的 Ferret-UI 研究明白;
這些都是十分值得研究的命題。
2.2.2 爹味十足的廠商
所有的大模型都自帶安全機(jī)制,而且這個安全機(jī)制是寫死在模型里面的,不是說 API 有個開關(guān)可以把安全機(jī)制關(guān)掉,你可以選擇把安全等級調(diào)低,但是這玩意是沒辦法關(guān)閉的。當(dāng)然市面上會有很多突破安全機(jī)制的方法,但是這些都算是漏洞,被廠商發(fā)現(xiàn)之后很容易被封堵。
比如如果你和大模型說我和別人吵架吵輸了,你教我怎么罵人,大模型會拒絕。就我自己而言,我認(rèn)為把安全機(jī)制做在模型里面并且不給開關(guān)的行為真的很爹味,但是這個沒辦法。
所以市面上有很多的本地部署的模型的賣點(diǎn)就是沒有安全機(jī)制,黃賭毒色情暴力 18+ 怎么黃暴怎么來,但是這玩意就是人性。這也是一個機(jī)會,值得各位 PM 關(guān)注。
此外有一點(diǎn)值得關(guān)注,同樣的內(nèi)容,在不同的語言下面安全的閾值是不一樣的,舉個例子:
通過 Google Gemini Pro 1.5 翻譯西單人肉包子故事,翻譯成英語/西語的時候,模型會報(bào)錯,提示內(nèi)容過于黃暴,模型拒絕生成,但是日語版本就沒有任何問題。
說明什么?說明日語的語料真的很變態(tài),間接可以說明日本人確實(shí)是全世界最變態(tài)的人。
2.3 目前存在,但是未來可能會被解決的問題
2.3.1 較弱的意圖理解/創(chuàng)作/推理能力
大模型的意圖理解,創(chuàng)作和推理能力,目前來看整體和人類的頂尖水平還是有較大差距的。
如果試圖讓大模型做一些“創(chuàng)造性”的工作,就需要非常強(qiáng)的提示詞工程。
不同水平的提示詞下,大模型的水平差異確實(shí)會非常大,但是我認(rèn)為隨著模型的迭代,我們的提示詞對模型生成的結(jié)果質(zhì)量影響會越來越小,主要的作用是提升精確性。
當(dāng)然,如果兩個模型有一些代差,生成的結(jié)果肯定是有質(zhì)量上的差異的:
所以要不要對模型的提示詞做大量優(yōu)化呢?我認(rèn)為這個取決于優(yōu)化提示詞的目的是什么。
如果是為了保證格式和輸出結(jié)果的穩(wěn)定性以及一致性,是很有必要的, 因?yàn)楹芏鄷r候我們的產(chǎn)品業(yè)務(wù)上需要這個一致性,比如要求大模型輸出的格式必須是 Josn,保證下游系統(tǒng)可以正常展示。
如果是為了提升質(zhì)量,我認(rèn)為是沒有必要的,因?yàn)槟P蜁?,升級之后帶來的提升肯定比提示詞工程雕花帶來的提升要多。
https://github.com/Kevin-free/chatgpt-prompt-engineering-for-developers
這是吳恩達(dá)的提示詞工程課程,應(yīng)該是目前市面上最權(quán)威的提示詞工程課程,并且提供中英文雙版本。
此外,長鏈路的 SOP、工作流和推理過程,我建議通過多個 AI Agent 實(shí)現(xiàn),而非試圖在一輪對話里面解決,原因在上面的局限性里面已經(jīng)說的很清楚了。
2.3.2 跨模態(tài)數(shù)據(jù)讀取/生成能力
如果這里有一個視頻,希望 AI 總結(jié)視頻的內(nèi)容,應(yīng)該怎么實(shí)現(xiàn)?
以 5.1K Star 的知名開源項(xiàng)目 BibiGPT 為例子。這個項(xiàng)目最早的一個版本應(yīng)該是只做了一件事情(根據(jù)表現(xiàn)逆向猜測的),用 OCR 識別字幕,同時把視頻轉(zhuǎn)音頻,ASR 出來文字,然后讓 GPT 3.5 去總結(jié)。
項(xiàng)目地址:https://github.com/JimmyLv/BibiGPT-v1
當(dāng)然更新到今天這個項(xiàng)目肯定不是做的這么簡單多了,比如應(yīng)該運(yùn)用了大量的視頻截圖然后要求支持多模態(tài)的模型去識別里面的關(guān)鍵內(nèi)容。
但是讓我們回到 BibiGPT 第一個版本,它其實(shí)還是做了一個視頻轉(zhuǎn)文字的這樣的動作。
這樣的動作理論上來說現(xiàn)在已經(jīng)沒有必要做了,因?yàn)?Google 最新的模型 Gemini 已經(jīng)支持對視頻本身的解析了,只不過用起來很貴,下面是 Google 官方提供的 Gemini 處理視頻、音頻和圖片的文檔。
https://cloud.google.com/vertex-ai/generative-ai/docs/samples/generativeaionvertexai-gemini-all-modalities?hl=zh-cn
我個人并不建議大家在跨模態(tài)這個事情去做一些雕花的工作。因?yàn)橛霉こ淌侄谓鉀Q跨模態(tài)最大的問題是會造成信息的損耗。此外模型迭代一定是會端到端解決跨模態(tài)的問題的,我們應(yīng)該重點(diǎn)解決上面提到的可能永遠(yuǎn)無解的問題,不要去和模型內(nèi)卷,是不可能卷贏的。
但是需要強(qiáng)調(diào)的事,把一個博客網(wǎng)頁的文本去提取出來轉(zhuǎn)化成 MD 格式,或者把一個 PDF 轉(zhuǎn)化成 MD 格式,這個不是跨模態(tài),只是數(shù)據(jù)清洗,需要嚴(yán)格區(qū)分二者的關(guān)系。
數(shù)據(jù)清洗這件事情,最好還是用工程方法解決。
三、從《理解媒介》的角度探討大模型的更底層的長處是什么
注:這一段會對麥克盧漢的《理解媒介》的基礎(chǔ)上做一些發(fā)散;
想要理解大模型以及 AIGC 的商業(yè)價值,私以為最重要的是要能夠首先理解媒介。
因?yàn)榇竽P蜕a(chǎn)的東西本質(zhì)上是內(nèi)容,想要能夠?qū)Υ竽P陀懈羁痰睦斫猓鸵獙?nèi)容以及媒介有比較清楚的認(rèn)識,比起搞清楚大模型的本質(zhì)是什么,我認(rèn)為搞清楚內(nèi)容的一些底層邏輯,其實(shí)對于應(yīng)用大模型更重要。
對于產(chǎn)品經(jīng)理來說,業(yè)務(wù)場景總是比技術(shù)手段更值得深入研究。
在講述一些枯燥的概念之前,我想先講一個關(guān)于媒介的小故事來方便大家理解。
3.1 關(guān)于媒介的小故事
在現(xiàn)實(shí)生活中,我們可能很難理解媒介的概念,但是在藝術(shù)界,媒介這個概念其實(shí)是被解構(gòu)的很徹底,并且被比較赤裸地?cái)[放出來的。
2017 年,知名的 MoMA 為史蒂芬·肖爾舉辦了一場個人攝影作品回顧展。
在回顧展的后半段,照片不存在于相框之中,展廳內(nèi)部是一臺又一臺的 iPad,觀眾需要通過 iPad 觀看肖爾使用 iPhone 拍攝并且發(fā)布到 Ins 上的照片。iPad 就是這些照片的相框。
媒介的作用就如同社會科學(xué)領(lǐng)域的議程設(shè)置一樣,會深刻地影響所有人觀看事物的方式。
肖爾的展覽赤裸裸地把這個命題展現(xiàn)給了所有人。肖爾想通過這樣的方式告訴大家,看一張照片,照片本身可能確實(shí)存在圖像內(nèi)容,但是讓你通過 iPad 看,和讓你通過打印出來的照片看,觀看感受就是不一樣的。
當(dāng)你在博物館看到一張照片,不論這張照片拍的有多屎,只要照片被很精致的打印,放大,掛載一面墻上,旁邊再標(biāo)上一個已經(jīng)被拍賣的標(biāo)簽,看的人可能都會覺得,我靠牛逼,毒德大學(xué)!
當(dāng)你在 Ins 上面刷到一張照片,你會覺得,哦,這就是一張照片。
現(xiàn)在肖爾在博物館里面放一張照片,但是這個照片得用 iPad 看,這種強(qiáng)烈的反差會促使人們?nèi)ニ伎?,媒介對于?nèi)容究竟有多大的影響。
如果站在內(nèi)容創(chuàng)作者的角度來看,現(xiàn)在生產(chǎn)了一個內(nèi)容,希望它的價值被盡可能放大,是不是應(yīng)該把這個內(nèi)容輸出到盡可能多的媒介上面去?
因?yàn)椴煌娜讼矚g的媒介是不同的,同一個人在不同的媒介看到同一個內(nèi)容獲得的感受也是不一樣的,這就是一個商業(yè)機(jī)會。
比如拍了個短視頻,是不是最好抖音、小紅書、B 站都發(fā)一遍?最好微信公眾號再發(fā)一遍文字稿!
但是實(shí)際上只有頭部的內(nèi)容生產(chǎn)者才有資格做的這么細(xì)致,為什么?因?yàn)閮?nèi)容在媒介之間的轉(zhuǎn)換是有成本的。
哪怕一個視頻從抖音發(fā)到 B 站,對觀眾來說其實(shí)已經(jīng)產(chǎn)生不好的觀感了,因?yàn)橐粋€是橫屏一個是豎屏,一個是長視頻一個是短視頻,如果內(nèi)容創(chuàng)作者要保持全平臺最佳觀感,其實(shí)成本是非常高的。
就我自己的體會來說,如果仔細(xì)看同一個內(nèi)容創(chuàng)作者在 B 站和抖音發(fā)的視頻會發(fā)現(xiàn)即使是一模一樣的內(nèi)容,抖音的視頻普遍會被剪輯的更短。
最后,為了方便下文討論,我會按照自己的理解對幾個概念做簡單定義,這些定義并不嚴(yán)格,僅僅作為本文討論時方便使用。
- 模態(tài):人類與現(xiàn)實(shí)世界的交互模式,通常與感知器官有緊密聯(lián)系,常見的模態(tài)有文字、靜態(tài)/動態(tài)圖像、聲音等;
- 內(nèi)容:內(nèi)容是人類通過感知器官對于現(xiàn)實(shí)世界進(jìn)行數(shù)據(jù)采集,處理和再加工的產(chǎn)物;
- 媒介:針對特定內(nèi)容的一種承載、編排與傳播范式,把 10 張照片按照順序放在博物館里面,作為一個展覽展出。在這句話里面,照片是媒介(因?yàn)檎掌旧硎且粡埣?,是物質(zhì)的),10 張是編排方式,博物館和展覽也可以認(rèn)為是一個媒介,只有照片里面的圖像才是內(nèi)容;
- 互聯(lián)網(wǎng)平臺:一種特定媒介,它們的特點(diǎn)就是會通過數(shù)字化手段嚴(yán)格限制媒介的格式、展示方式、分發(fā)邏輯,并且它們通常不會自行生產(chǎn)內(nèi)容;
3.2 內(nèi)容具有原生媒介
每個內(nèi)容在創(chuàng)作時都會自帶一個原生媒介,因?yàn)槿四X能夠容納的上下文是有限的,當(dāng)一個作者在試圖進(jìn)行創(chuàng)作時,他必須要把創(chuàng)作的階段性成果存儲在某個媒介之上,并且這個媒介需要確保內(nèi)容可以被再次輸出以便作者做階段性的回顧與質(zhì)量檢查。脫離了媒介作為存儲介質(zhì),作者本人也無法理解自己曾經(jīng)的創(chuàng)作。
所以我們也可以認(rèn)為,一個內(nèi)容是無法脫離于媒介獨(dú)立存在的。
這種創(chuàng)作過程中就使用的媒介,我們通常稱之為原生媒介,一個內(nèi)容通常有且僅有一個原生媒介,當(dāng)然可能會有輔助的媒介,比如一個廣播演講的原生媒介是音頻,但是會輔以文字稿件作為補(bǔ)充。
一個內(nèi)容只有通過原生媒介展示時才是能做到盡可能還原作者意圖的,反過來也可以說,內(nèi)容被發(fā)布到非原生媒介時會產(chǎn)生大量的信息損耗。
通常來說在一個媒介或者互聯(lián)網(wǎng)平臺內(nèi)最流行的內(nèi)容,幾乎無一例外都是把這類媒介當(dāng)成原生媒介的內(nèi)容。
這也就是為什么抖音和 B 站的內(nèi)容在互相轉(zhuǎn)化的時候這么困難的原因。
B 站最早是一個網(wǎng)站,B 站的視頻也是橫屏的,因?yàn)榭淳W(wǎng)站用的顯示器天然就是橫屏的,而顯示器是橫屏的原因是因?yàn)槿祟惖膬蓚€眼睛是橫著排列而不是縱向排列的。
抖音從誕生的時候就是一個 App,而且搭配了很多手機(jī)拍攝視頻的功能,所以抖音視頻天然就應(yīng)該是豎屏的,因?yàn)槿祟愑檬謾C(jī)就是豎著抓的。
假如我們現(xiàn)在的主流手機(jī)不是 iPhone 定義的,而是日本的夏普定義的,說不定抖音就壓根不會存在。
這種媒介上的區(qū)別就好像是難以逾越的天塹一般。
上面說的這些好像是常識,但是完全可以把這個分析思路套用到其他的內(nèi)容上面去。幾乎所有內(nèi)容產(chǎn)品都可以在這個框架內(nèi)進(jìn)行分析。
一個看逐字稿會覺得是無聊對話的播客節(jié)目,聽感有可能會非常出眾,比如一些以“聊天”和“插科打諢”為賣點(diǎn)的播客節(jié)目,因?yàn)樵诓タ凸?jié)目中有語氣和情感,這是文字稿很難表現(xiàn)的。
反過來說,假使一場廣播演講,演講者根本沒有用心關(guān)注內(nèi)容,也沒有通過演講彩排做階段性回顧,只知道逐字念稿,撰寫演講稿的人過分關(guān)注文字本身,這些就會導(dǎo)致演講聽上去干癟無力,不如把演講稿直接發(fā)給讀者看來的更順暢,因?yàn)檫@場演講在創(chuàng)作時使用的就是文字而非聲音。
在小紅書上面,專業(yè)的脫口秀演員也會表達(dá)類似的觀點(diǎn),這些在道理上都是相通的。
優(yōu)秀的演講者往往會選擇先寫大綱,口播轉(zhuǎn)文字再對文字進(jìn)行調(diào)整,以此保證聽眾體驗(yàn)。
3.3 媒介之間的本質(zhì)區(qū)別
不同媒介之間的根本性差異在哪?
個人目前觀察來看主要有兩點(diǎn),模態(tài)和瞬間性。
媒介=模態(tài)*瞬間性
模態(tài),人類與現(xiàn)實(shí)世界的交互模式,通常與感知器官有緊密聯(lián)系,常見的模態(tài)有文字、靜態(tài)/動態(tài)圖像、聲音等。
這三個基本模態(tài)根植于人類的視覺和聽覺,錐體經(jīng)驗(yàn)理論認(rèn)為人類大部分學(xué)習(xí)過程都依賴于視覺和聽覺,從這個角度來看,這些基本上的模態(tài)恰好被理論所命中。
當(dāng)然這也可能是雞生蛋蛋生雞的關(guān)系。不同的模態(tài)自帶的信息含量是不一樣的,文字是最抽象的,包含的信息含量最低,而圖像是最具象的,包含的信息含量最高。所以人們常說,看小說可以讓人發(fā)揮想象,看電視劇則會被束縛,正是因?yàn)槲淖值男畔⒑康?,所以才有想象的空間。
當(dāng)然,這里的信息含量指的是“絕對信息含量”,比如文本文件就是比圖像文件更小,但是這不代表念書學(xué)習(xí)效率會比看圖效率低,因?yàn)槿祟惸軌驍z取一個內(nèi)容中的信息含量的能力是有限的。
好比和一個人交談一定是比通過電子郵件交流具備更加豐富的信息的,因?yàn)檫@個人有微表情,有神態(tài),但并不每個人都能獲取和接收這些信息。
瞬間性是媒介的另一個根本特征,瞬間性是指對于一個內(nèi)容來說,當(dāng)它被某個媒介承載時,觀看者回顧其中某一個內(nèi)容切片的成本。
下面是一組媒介和他們的瞬間性大小的排布,瞬間性越強(qiáng),回顧成本越高:
單張圖片 = 短文字 < 組圖 < 長圖文 < 流媒體平臺上的視頻 < 播客平臺上的播客 < 電影院電影 < 音樂會的音樂 < 線下脫口秀
為什么線下脫口秀最難復(fù)制,因?yàn)樗膭?chuàng)作過程都是伴隨線下的靈光乍現(xiàn)以及與觀眾的親密互動,人們再也無法踏入同一條河流。
對于單張圖片來說,雖然想要 100% 復(fù)制有困難,但是至少可以基于特定工藝進(jìn)行打印,然后在對應(yīng)亮度和色溫的燈光下觀看,就能獲得近乎于原作的效果。
瞬間性越強(qiáng)的媒介,對于情緒的要求就越高(對創(chuàng)作者和觀眾來說都是這樣),一組文字可以冷冰冰,但是播客不能有氣無力,并且這種媒介越可能要求創(chuàng)作者把創(chuàng)作和傳播本身融為一體。
還是拿脫口秀舉例子,脫口秀本身就是在舞臺上才能實(shí)現(xiàn)作品的完整創(chuàng)作的,所以創(chuàng)作過程和傳播過程本身就是一體的。
同時一個媒介越是強(qiáng)調(diào)編排,瞬間性就會被體現(xiàn)的越強(qiáng),強(qiáng)調(diào)編排意味著讀者如果跳著閱讀或者跳躍回顧,都很難通過上下文獲得相同的體驗(yàn),只有完整的重新按照編排順序閱讀,才能獲得接近于第一次閱讀的體驗(yàn)。
3.4 AIGC 的意義在于降低內(nèi)容跨媒介甚至跨模態(tài)的門檻
在工作中其實(shí)我經(jīng)常會有一個疑惑,為什么文檔寫了,還要問?
其實(shí)原因很簡單,因?yàn)槿俗鳛橐粋€媒介,比文檔作為一個媒介對于人來說更加的友好。在某些場景下面提問者的問題是比較簡單的,看文檔就會很重。但是對于回答者來說,重復(fù)回答問題是不經(jīng)濟(jì)的,這種矛盾就很適合用 AI 來解決。
很多時候我們覺得一個內(nèi)容讀起來不舒服,可能不是內(nèi)容本身的問題,而是這個內(nèi)容的媒介導(dǎo)致的。
在英劇《是,大臣》中,漢弗萊曾經(jīng)表示大臣的演講就是很無聊,因?yàn)閮?nèi)閣大臣演講稿撰寫目標(biāo)不是取悅臺下的聽眾,而是上報(bào)紙。
所以為什么政客們在電視上的演講那么無聊,這下大家都明白了吧,因?yàn)樗麄兇蟛糠衷谀钜恍皶晕淖中问桨l(fā)下去”的材料。
理論上來說我們?nèi)绻屢粋€內(nèi)容盡可能多渠道傳播,我們需要有人去做這個媒介的翻譯,并且這個成本非常高,舉例來說:如果想要把一個以文字作為原生媒介的內(nèi)容轉(zhuǎn)化成播客錄音,這個轉(zhuǎn)化成本就會很高,因?yàn)檫@意味著在轉(zhuǎn)化過程中需要增加額外的信息(比如語氣和情感),這本身近乎于創(chuàng)作。
又比如對于一個公眾人物來說,如果不針對性的做演講訓(xùn)練,拿到一個演講稿直接講的效果一定會很差,因?yàn)樽迦耸腔谖淖置浇樽?,而聽眾則通過聲音這個媒介來接收信息。聲音比干巴巴的文字稿會多出來更多的信息,語氣、語速、抑揚(yáng)頓挫等,這些如果指望演講者臨場發(fā)揮,那對演講者來說要求真的很高。
因?yàn)槿绻粋€內(nèi)容的原生媒介的瞬間性很強(qiáng),大概率意味著它會包含更多的信息,不論是編排層面還是情感層面。
但是現(xiàn)在,AIGC 很大程度上就能替代人去完成其中最枯燥的 80 % 的工作了。比如如何把一個文本轉(zhuǎn)換成語音,可以用豆包 TTS 大模型,深情并茂。
在 AIGC 誕生之前,這是幾乎不可解的問題,一定是需要人類錄音的。
3.5 為什么要從媒介的角度去理解大模型的商業(yè)價值
其實(shí)大概就在 1 年前,我曾經(jīng)嘗試總結(jié)大模型能做什么,當(dāng)時總結(jié)的用途是:
- 總結(jié):根據(jù)特定的要求分析大段的內(nèi)容,并且按照內(nèi)容給出對應(yīng)的結(jié)論;
- 擴(kuò)寫:根據(jù)特定的要求和范式,將少量內(nèi)容擴(kuò)充成大段內(nèi)容;
- 翻譯:根據(jù)特定要求把一段內(nèi)容無損的轉(zhuǎn)化成另一段內(nèi)容;
- 意圖理解:大語言模型有非常強(qiáng)的意圖識別能力,可以非常好的理解用戶的意圖;
這些總結(jié)不能說是錯的,但是有幾個比較致命的問題。
- 僅針對文字模態(tài),沒有考慮多模態(tài)的情況;
- 這更多的是一種歸納,并不能保證從邏輯上是 MECE 的;
如果從歸納法的角度來說,我們會認(rèn)為大模型能干這個,不能干那個,可以舉無窮多的例子,但是如果想要試圖搞清楚這個東西擅長什么,不擅長什么,天花板在哪里,歸納法是沒有那么靠譜的。
如果從媒介的角度去看待大模型,我們可以發(fā)現(xiàn)它具有幾個能力是以前的技術(shù)不具備的:
- 它能夠一定程度上理解內(nèi)容,但是要想憑空創(chuàng)造內(nèi)容還是有難度的;
- 它在理解內(nèi)容的基礎(chǔ)上,可以將一個內(nèi)容修飾成另更適合一個媒介內(nèi)容,也就是我們常說的總結(jié)、擴(kuò)寫、翻譯;
- 它能夠在理解內(nèi)容的基礎(chǔ)上,將一個內(nèi)容轉(zhuǎn)化成另一個模態(tài)的內(nèi)容,也就是我們常說的文生圖;
- 它能夠基于自己對大量素材的學(xué)習(xí),在內(nèi)容進(jìn)行媒介或者模態(tài)轉(zhuǎn)化的時候,補(bǔ)充最合適的信息進(jìn)去;
- 因?yàn)樗M(jìn)行了大量的學(xué)習(xí),所以如果它能夠被精確的控制意圖,它的效果會非常好;
所以讓我們回到上面的小節(jié),回顧一下媒介的瞬間性的排序:
單張圖片 = 短文字 < 組圖 < 長圖文 < 流媒體平臺上的視頻 < 播客平臺上的播客 < 電影院電影 < 音樂會的音樂 < 線下脫口秀
在 AIGC 誕生之前,我們可能只能把右邊的內(nèi)容轉(zhuǎn)化成左邊的內(nèi)容。
在 AIGC 誕生之后,我們是可以把左邊的內(nèi)容轉(zhuǎn)換成右邊的內(nèi)容的,因?yàn)槲覀冇辛藷o中生有的能力!
這就是 AIGC 在媒介層面的意義,這個從生產(chǎn)角度來說是劃時代的。
還是拿上文提到的豎屏與橫屏例子來說,B 站的視頻是橫屏的,抖音是豎屏的,對于創(chuàng)作者來說,如何低成本的轉(zhuǎn)化呢?答案是用 AI 生成,擴(kuò)展畫面。
四、以 RAG 的進(jìn)化來探討圍繞大模型的長處和短處來制作產(chǎn)品
4.1 AI Agent 是什么?
GoogleMind和普林斯頓聯(lián)合發(fā)表了一篇論文《ReAct: Synergizing Reasoning and Acting in Language Models》,被公認(rèn)為基于LLM的智能體的開山之作。
研究人員發(fā)現(xiàn),在問答和事實(shí)驗(yàn)證任務(wù)中,ReAct 通過與簡單的Wikipedia API交互,克服了推理中普遍存在的幻覺和錯誤傳播問題。
這個比去強(qiáng)化模型訓(xùn)練強(qiáng)很多倍,原因是什么,大模型的大腦已經(jīng)很強(qiáng)大了,很多時候再訓(xùn)練下去邊際效用遞減很嚴(yán)重,給他一個 API,相當(dāng)于給這個大腦增加“五官”,它自然就一下子進(jìn)化了。
4.2 Auto GPT,第一個出圈的 AI Agent
AutoGPT 可以說是第一個真正意義上出圈的 AI Agent。
它嘗試設(shè)計(jì)了一個流程,任何問題都有一個通用的元思路去解決,每個負(fù)責(zé)解決問題的模塊都由一個 GPT 4 去驅(qū)動。
AutoGPT 的設(shè)計(jì)者認(rèn)為這世界上幾乎所有的問題解決步驟都是類似的,明確問題,明確解決問題需要的步驟,完成任務(wù),檢查,總結(jié)。
所以按照這個 SOP,他們涉及了一個互相之間傳遞信息的 AI Agent,每個模塊都是獨(dú)立記憶的模型,好像幾個人類在分工,一個專門負(fù)責(zé)明確問題,一個專門負(fù)責(zé)拆解問題。
AutoGPT 是由Significant Ggravitas 于 2023 年 3 月 30 日發(fā)布在 GitHub 上開源的AI代理應(yīng)用程序。它使用 GPT-4 作為驅(qū)動基礎(chǔ),允許 AI 自主行動,完全無需用戶提示每個操作,因其簡單易用在用戶中大受歡迎。上線僅三周,其 GitHub 的 Star 數(shù)量已飆升至接近10萬,早已超越了 Pytorch(65K),可以稱得上開源領(lǐng)域star數(shù)增長最快的現(xiàn)象級項(xiàng)目。
Auto-GPT 是基于 OpenAI API 開發(fā)的,它的核心在于基于最少的人工輸入/提示,利用 GPT-4 的推理能力解決更廣泛、更復(fù)雜的問題。在具體的執(zhí)行上,程序會訪問互聯(lián)網(wǎng)搜索和收集信息,使用 GPT-4 生成文本和代碼,使用 GPT-3.5 存儲和匯總文件。
但是很快大家就發(fā)現(xiàn)這個 AI Agent 是有缺陷的,比如它很容易陷入死循環(huán),或者是不能很好的解決不確定性的,帶有探索性質(zhì)的問題,但是這個思路本身給大家?guī)砹朔浅6嗟奶崾尽?/p>
擴(kuò)展閱讀,Auto GPT 工作原理:
https://www.leewayhertz.com/autogpt
4.3 RAG 和 AutoGPT 的區(qū)別
RAG 其實(shí)就是檢索+生成的縮寫,明確了這個 SOP 主要的作用就是從特定的地方檢索出來信息,然后再以更加友好的形式展現(xiàn)出來。
如果一個產(chǎn)品有十幾篇說明文檔,那么 RAG 就好像是一個熟讀了文檔的客服。
最簡單的 RAG 可以參考 AI 搜索引擎 ThinkAny 第一版的原理:
MVP 版本實(shí)現(xiàn)起來很簡單,使用 NextJs 做全棧開發(fā),一個界面 + 兩個接口。
兩個接口分別是:
/api/rag-search
這個接口調(diào)用 serper.dev 的接口,獲取谷歌的檢索內(nèi)容。輸入用戶的查詢 query,輸出谷歌搜索的前 10 條信息源。
/api/chat
這個接口選擇 OpenAI 的 gpt-3.5-turbo 作為基座模型,把上一步返回的 10 條檢索結(jié)果的 title + snippet 拼接成上下文,設(shè)置提示詞,請求大模型做問答輸出。
以上文字引用自:
https://mp.weixin.qq.com/s/25eXZi1QgGYIPpXeDzkQrg
它 RAG 可以被視為是一種針對特定業(yè)務(wù)場景的 AI Agent,它和 AutoGPT 最大的區(qū)別在于三點(diǎn):
- RAG 的流程是一個串行流而不是一個循環(huán),它沒有所謂的自我檢查然后重新生成的過程,一方面是為了響應(yīng)速度,另一方面也是為了避免自我檢查造成的死循環(huán);
- RAG 的流程中,是檢索+生成,檢索的部分并不是由大模型完成的,而是通過傳統(tǒng)的搜索引擎(向量數(shù)據(jù)庫、關(guān)鍵詞匹配)來完成的,這和 AutoGPT 中幾乎所有關(guān)鍵節(jié)點(diǎn)都是用 GPT 4 完成是有天壤之別的,這意味著大家意識到一個問題,在一些對上下文窗口有要求的,輸出精確排序的場景,GPT 一點(diǎn)也不好用;
- RAG 并不是萬能的,它設(shè)計(jì)出來也不指望自己能解決所有問題,實(shí)際上它更多的是解決“如何快速給答案”這個問題,有 10 篇文檔,怎么快速到找用戶需要的答案;
發(fā)展到這一步,大家已經(jīng)意識到一個事情:這個世界上可能不存在一個萬能的 AI Agent,也就是說并沒有一個萬能的許愿機(jī)。
至少目前工程界很少有人會再嘗試投人力去做萬能的 Agent,學(xué)術(shù)界還在繼續(xù)。
可能有人會糾結(jié)概念,RAG 和 AI Agent 是兩個完全不相關(guān)的東西,而且 RAG 最早可以追溯到 2020 年的一篇論文,歷史比 AI Agent 更為久遠(yuǎn)。但是其實(shí)我認(rèn)為他們在工程落地上是非常相似的,都是強(qiáng)調(diào)基于工具,外部數(shù)據(jù),存儲機(jī)制來彌補(bǔ) AI 的缺陷,唯一的區(qū)別是 RAG 不會強(qiáng)調(diào)要求 AI 具備自我探索自行規(guī)劃任務(wù)的能力。
現(xiàn)在市面上的文章,尤其是面向非技術(shù)的同學(xué)的文章,關(guān)注概念多過關(guān)注落地,這不是一個好現(xiàn)象。工程領(lǐng)域本來就有很多約定俗成的叫法,比如廣告系統(tǒng)的 DMP,全名是 Data management platform,但是實(shí)踐的時候幾乎只管人群數(shù)據(jù),總不能因?yàn)槊趾蛯?shí)際干的事有差別就天天在那辯經(jīng)。
這篇文章在介紹 RAG 的時候,就是希望從實(shí)現(xiàn)思路著手,給 AI 這個大腦一步一步配上了多套工具,乃至到最后替 AI 做了一部分流程設(shè)計(jì)。
希望通過這個文檔去展現(xiàn)一個循序漸進(jìn)的,也是從抽象到具象的具體落地過程,為了保證文檔本身的可讀性,列舉的項(xiàng)目并不是完全一脈相承的,但是我認(rèn)為這樣的寫作順序?qū)τ谧x者來說是最友好也是最具有啟發(fā)性的。
4.4 RAG 的缺陷是什么?
論文《Seven Failure Points When Engineering a Retrieval Augmented Generation System》中列舉了 RAG 的 7 個弱點(diǎn)。
論文地址:https://arxiv.org/abs/2401.05856
通過這些故障點(diǎn),我們可以發(fā)現(xiàn)一個問題,其實(shí)有很多故障點(diǎn)本身和大模型沒有關(guān)系,比如搜索文檔 Top K 的排序不夠精確,比如無法從文檔中讀取信息,因?yàn)槲臋n格式錯誤或者文檔太臟了。
就像我們前面所說的比喻,大模型本質(zhì)是一個大腦,AI 產(chǎn)品才是大腦搭配上五官,軀干和四肢。
不能只優(yōu)化大腦,不優(yōu)化四肢,那是一種偷懶行為,不要把大模型視作為萬能的許愿機(jī)器。
最后讓我用一個兒歌來總結(jié)一下這篇文檔的核心思想:
人有兩個寶,雙手和大腦。
雙手會做工,大腦會思考。
用手又用腦,才能有創(chuàng)造。
4.5 Graph RAG — 一種 RAG 的進(jìn)化版本
Graph RAG 是微軟開放的一個開源的 RAG 框架,可以被視作為是一種進(jìn)一步變化和迭代的 RAG SOP,根據(jù)公開資料參考,我猜測這套技術(shù)實(shí)現(xiàn)思路廣泛地應(yīng)用在了微軟的 Copilot 系統(tǒng)上,當(dāng)然我沒有找到可以證實(shí)的材料。
Graph RAG 和原本的 RAG 的區(qū)別是什么呢?
傳統(tǒng) RAG 的主要工作是這三個步驟:
- 把待搜索的知識做向量化處理(可離線處理);
- 當(dāng)用戶提出來一個關(guān)鍵詞 or 問題,根據(jù)相似性查詢查出來最相關(guān)的內(nèi)容(必須是在線服務(wù));
- 將查詢出來的 Top N 的相關(guān)內(nèi)容作為上下文,和用戶提出的問題一起交給大模型來生成內(nèi)容(必須是在線服務(wù));
相似性查詢的效果其實(shí)是比較不盡如人意的,因?yàn)樗耆歉鶕?jù)文字的相似水平來進(jìn)行檢索,和文本的語義一點(diǎn)關(guān)系都沒有。這就導(dǎo)致最終 RAG 的效果往往會比較糟糕。
當(dāng)然這三個步驟中間出問題的可能性很多,就像上文提到的 RAG 的 7 個待優(yōu)化點(diǎn),但是檢索的準(zhǔn)確性是一個最容易優(yōu)化并且收益也最大的問題,那么微軟是怎么做的呢?
微軟認(rèn)為用戶可能會詞不達(dá)意,同時檢索也需要更加智能,所以微軟將向量化檢索的方法替換成借助知識圖譜的檢索方法。
Graph RAG 的主要工作是下面三個步驟:
- 將待搜索的知識進(jìn)行一個三元組抽?。ㄖ髦^賓),這個抽取的動作需要 LLM 介入,存入圖數(shù)據(jù)庫中(可離線處理);
- 將用戶提出來的關(guān)鍵詞,用 LLM 做一次擴(kuò)散,擴(kuò)散出來同義詞,近義詞等,然后在圖數(shù)據(jù)庫進(jìn)行檢索,找到相關(guān)文檔(必須是在線服務(wù));
- 將查詢出來的相關(guān)內(nèi)容作為上下文,和用戶提出的問題一起交給大模型來生成內(nèi)容(必須是在線服務(wù));
整體的步驟和架構(gòu)其實(shí)沒有更多的變化,但是在關(guān)鍵步驟上引入了大模型,作為兩個獨(dú)立的處理步驟。
注意,這里的獨(dú)立處理步驟是非常關(guān)鍵的。
4.6 RAG 再進(jìn)化(雕花)
在微軟發(fā)布了 GraphRAG 之后,很多人都試用了,然后又發(fā)現(xiàn)一堆問題,于是有人發(fā)了這篇論文:《A Hybrid RAG System with Comprehensive Enhancement on Complex Reasoning》。
論文地址:https://arxiv.org/abs/2408.05141
Hybrid RAG 在原來的基礎(chǔ)上,做了幾件事。
工作 1、Document 在 Loader 之前,先用 LLM 做一輪格式上的處理。
工作 2、問題分類機(jī)器
這個問題分類機(jī)器本身是一個 SVM 分類器,但是這個分類器的訓(xùn)練數(shù)據(jù)不是人工標(biāo)注的,而是用大模型來標(biāo)注的,以此減少成本和開銷。
工作 3、利用大模型調(diào)用外部的計(jì)算庫
當(dāng)然,這篇論文里面還寫了很多思路,感興趣的同學(xué)可以自己去看論文。
這個論文質(zhì)量還是很高的,6 個作者中的 5 個是北京大學(xué)人工智能實(shí)驗(yàn)室的學(xué)者。
五、為什么我們曾經(jīng)高估了大模型的影響力
5.1 我們原本設(shè)想的端到端的場景問題是什么?
現(xiàn)在人類生產(chǎn)視頻的工業(yè)化流程是:
- 看一下市面上熱門視頻的共性,往往依靠標(biāo)簽
- 根據(jù)熱門標(biāo)簽生產(chǎn)一些腳本;
- 拍攝;
- 發(fā)到線上看數(shù)據(jù)反饋,再做迭代;
在大模型剛剛誕生的時候,其實(shí)有一個假設(shè),假如大模型可以直接生成視頻,能不能讓它看抖音上的大部分視頻,訓(xùn)練它,然后讓它生產(chǎn)一部分。
讓用戶給這些大模型生產(chǎn)的視頻點(diǎn)贊,大模型再把高贊的視頻拿來作為正反饋繼續(xù)生成視頻。
如果這條路能走通,對于抖音這樣的內(nèi)容平臺絕對是顛覆性的,現(xiàn)在看這個流程可以說是走不通的,其中自然有視頻生成模型質(zhì)量不好、不可控的原因,但是我認(rèn)為更多的原因在于:
- 模型的上下文窗口限制
- 模型的成本太高
這兩個是幾乎無解的問題,估計(jì)未來相當(dāng)長(10 年)的時間都很難解決,所以我不認(rèn)為這種端到端的場景是可行的。
但是 AI 生成視頻一定會成為視頻工作者未來工作環(huán)節(jié)的重要補(bǔ)充,這點(diǎn)是不需要懷疑的。
5.2 所有應(yīng)用都值得用 AI 重做一遍嗎?
顯然不,因?yàn)檫@個世界上 90% 的事情用規(guī)則就已經(jīng)可以運(yùn)轉(zhuǎn)的很好,模型低效又不穩(wěn)定。
很多時候我們對一個產(chǎn)品的要求就是,簡單、高效、可以依賴,現(xiàn)階段模型的不穩(wěn)定性注定了它在很多場景下是不可依賴的,哪就很難談得上取代原有產(chǎn)品。
還是重讀一遍俞軍給的知名的需求公式:
用戶價值= 新體驗(yàn)– 舊體驗(yàn)– 替換成本
很多時候用了新技術(shù),收益可能也沒有想象的那么大,這是一個事實(shí)。認(rèn)為所有應(yīng)用都值得用 AI 重做一遍的人顯然是高估了 AI,很多人喜歡把 AI 和移動互聯(lián)網(wǎng)類比,這是不恰當(dāng)?shù)摹?/p>
從馮諾依曼計(jì)算機(jī)的架構(gòu)來看,移動互聯(lián)網(wǎng)直接把計(jì)算機(jī)的輸入輸出設(shè)備給改了,這首先帶來了交互上的革命性變化,但這不是最重要的。
從市場上來看移動互聯(lián)網(wǎng)真正的價值并不是交互革命,而是極大的降低了用戶接入互聯(lián)網(wǎng)的成本,使得用戶數(shù)量得到了翻倍,延長了用戶互聯(lián)網(wǎng)的使用時間。
上面這兩個革命性的變革,顯然是這輪 AI 浪潮所不能及的,AI 既不能擴(kuò)大市場,短期內(nèi)也不能改變計(jì)算設(shè)備的形態(tài)。
大模型的變革更多的會體現(xiàn)在生產(chǎn)端,從而影響消費(fèi)端,正如在上文理解媒介一個章節(jié)中提到的,它能帶來的是生產(chǎn)力的極大提升,但我們現(xiàn)在面臨的問題更多的是市場不足,生產(chǎn)過剩問題。
5.3 LUI 是萬能的嗎?
有人說這一輪 AI 會帶來交互革命,從今天起我們只需要一個有聊天框的超級 App 就可以啦!
我現(xiàn)在就可以下這個結(jié)論,說這話的人一定是云玩家,如果這種人在公司里面,我是他的上級,我就要懲罰他晉升答辯不準(zhǔn)寫 PPT 和文檔,只允許口播。
任何一種媒介和交互都是有最佳實(shí)踐和獨(dú)特價值的,LUI 顯然不是萬能的,程序員寫個代碼還會考慮 IDE 的 GUI 好不好使,Language UI 信徒們哪來的自信這玩意可以徹底取代圖形界面?
LUI 最大的問題就是效率低,讓我以企業(yè)級軟件舉例:
Excel 也好,PowerPoint 也好,哪怕是 BI 軟件也好,軟件除了降低門檻之外,還有一個很重要的作用就是「約束」使用者。
在這個場景下約束不是一個貶義詞,是一個褒義詞。這些軟件內(nèi)置的所有功能都是在漫長的時光中迭代出來的,里面凝聚了無數(shù)軟件開發(fā)者與使用軟件的企業(yè)的經(jīng)驗(yàn)和最佳實(shí)踐。
打開 Sensors Analysis(神策數(shù)據(jù)旗下)和 DataFinder (火山引擎旗下)這兩個產(chǎn)出自不同公司的行為分析軟件時,會發(fā)現(xiàn)二者的功能極為相似,事件分析、漏斗(轉(zhuǎn)化)分析、留存分析等等。我甚至懷疑使用這些軟件的企業(yè)客戶們使用習(xí)慣也會高度類似,因?yàn)檫@些軟件里面凝聚的功能本身就是最佳實(shí)踐。
對于一個沒有什么統(tǒng)計(jì)分析能力的運(yùn)營來說,讓他去面對 GPT 的文本框描述清楚自己需要一個漏斗分析實(shí)在是太困難了,還是用神策比較簡單。
GPT 如果能夠獲得關(guān)于漏斗分析的詳細(xì)計(jì)算邏輯,也可以一定程度上的引導(dǎo)用戶,但前提是用戶得能說出來“漏斗分析”這四個字,實(shí)際上脫離了界面很多人都不見得能描述的清楚自己想要的是什么。
LUI 不是萬能的,對 LUI 的過度追求,甚至把 LUI 與 AI native 劃等號這種想法都是錯誤的。LUI 只是在特定范式下才是有意義的。
5.4 復(fù)雜的 UI 是一段彎路嗎?
現(xiàn)在市面上最領(lǐng)先的開源文生圖 UI 叫做 ComfyUI,如下圖所示:
ComfyUI 和我們腦子里面想的敲敲文本就能調(diào)用的文生圖 AI 差異很大,感覺更像是一個低代碼平臺,為什么?
因?yàn)樵诠I(yè)界需要追求精確控制,純粹用提示詞是無法準(zhǔn)確表達(dá)精確控制的語義的,必須得用 GUI 才能表達(dá)出來。
比如上面這個圖,其實(shí)里面做的事情就是把一個建筑物換成另外一個建筑物,并且盡可能不要改變其他東西,這種精確控制對于模型這種本質(zhì)依靠數(shù)學(xué)概率驅(qū)動的東西來說是非常困難的,所以才搞得這么復(fù)雜。
那么問題來了,上面這種 UI 是一段彎路嗎?
其實(shí)我乍一看我也覺得這個太離譜了,如果讓我用 Photoshop 或者醒圖類似的事情應(yīng)該也能做,而且 UI 應(yīng)該沒有復(fù)雜,但是細(xì)想之后我認(rèn)為這個東西非常有價值。
我認(rèn)為如果把這種 UI 給到用戶,這肯定是一段彎路,但是如果我們把上面這個操作包裝成一個場景,給用戶的就是讓用戶上傳兩張圖這樣的動作,這不就是一個最簡單的產(chǎn)品了嗎?
也就是說我上面說的,醒圖和 PhotoShop 的功能,其實(shí)以后完全是可能用這樣的 UI 搭建出來然后包裝給用戶的。
所以上面的 UI 是完全可以提供給專業(yè)用戶的,這樣的 UI 可以變成一個引擎,產(chǎn)品內(nèi)成千上百的功能都可以通過這么一個元引擎被源源不斷地生產(chǎn)出來。
這就是大模型真正的價值,這是生產(chǎn)力成百倍的提升。
5.5 大模型真正的價值是什么?
如果大模型既不能給交互帶來質(zhì)的變化,又不是一個萬能的許愿機(jī),甚至連端到端生成 Feed 流都做不到,那么大模型真正的價值是什么呢?
大模型真正的價值在于給產(chǎn)品經(jīng)理和工程師這樣具備非凡創(chuàng)造力的人一個增幅器。
這是一個不需要訓(xùn)練的萬能模型,而且大概率比專屬模型更強(qiáng)。
這意味著產(chǎn)品經(jīng)理和工程師只要能想清楚 SOP,想清楚哪些問題可以用大模型來解決,就一定能以比較低的成本解決,原本一些需要訓(xùn)練自己私有模型的事,現(xiàn)在依靠公有模型就可以解決了。
很多原本像高山一樣的成本,現(xiàn)在也是可以逾越的,金錢和數(shù)據(jù)量不再是訓(xùn)練模型的攔路虎,你只需要會寫 prompt ,會搭工作流就可以了。
六、對產(chǎn)品經(jīng)理的工作方法啟示是什么?
6.1 業(yè)務(wù)!業(yè)務(wù)!業(yè)務(wù)!數(shù)據(jù)!數(shù)據(jù)!數(shù)據(jù)!
新鮮的數(shù)據(jù)和能持續(xù)產(chǎn)生新鮮數(shù)據(jù)的業(yè)務(wù),是一個大模型的生命力所在。
一個 RAG 做的再牛逼,如果數(shù)據(jù)庫很糟糕,結(jié)果就是很糟糕的。
一個模型再挫,只要數(shù)據(jù)足夠好,照樣是一個好工具。
在 AI 時代,數(shù)據(jù)的問題只會被放的更大,AI 搜索如果在一堆屎山數(shù)據(jù)里面做搜索,充其量不過是又造了一根攪屎棍。
任何時候,能持續(xù)生產(chǎn)真實(shí)交易數(shù)據(jù)和優(yōu)秀內(nèi)容的業(yè)務(wù)都比大模型本身重要。
6.2 看論文不是產(chǎn)品經(jīng)理避免 FOMO 的最佳途徑,動手嘗試可以避免 FOMO
我認(rèn)為一個比較清晰的事實(shí)是,目前工業(yè)界短期內(nèi)一定高估了大模型的作用。
前段時間我寫了一個段子:每一個 App 都值得思考是否能用 AI 重做一遍,然后就會發(fā)現(xiàn)值得重做的只有 10%。
短期內(nèi)的資源投入很大程度上是源自于投資人和大廠決策者的 FOMO 心態(tài),這種心態(tài)某種角度來說是不健康的。這種 FOMO 的心態(tài)也會傳導(dǎo)給產(chǎn)品經(jīng)理,于是很多產(chǎn)品經(jīng)理都開始看論文(比如本文作者),但在我看來產(chǎn)品經(jīng)理看論文其實(shí)沒什么用,圖一樂的作用更大。
論文都是錘子,但是對于 PM 來說更重要的是釘子在哪里。所以與其關(guān)心最新的學(xué)術(shù)界又發(fā)了什么,不如關(guān)心一下 Product Hunt 上面哪些 AI 產(chǎn)品又登上了當(dāng)日第一,并且賺錢了。
與其 FOMO,不如動手多用用,以前移動互聯(lián)網(wǎng)剛剛興起的時候,大部分產(chǎn)品經(jīng)理手機(jī)里面不得裝小幾百個 App,天天研究來研究去的。去用一下市面上最好的應(yīng)用,并且嘗試逆向它,會有多很收獲。
寫這篇文章,寫接近 2 萬字,發(fā)現(xiàn)大模型那么多的坑,而且每個坑都能找到一些關(guān)聯(lián)的論文。不是因?yàn)殚e的蛋疼去看論文,而是因?yàn)橐恢痹趽v鼓 AI,然后發(fā)現(xiàn)這也有問題那也有問題,不得已去搜索,搜到了論文。
原來大家都有這個問題,有的人就是有鉆研精神,發(fā)現(xiàn)了問題還會深入研究,然后寫一篇論文。哎,人比人真的氣死人。
如果仔細(xì)看就會發(fā)現(xiàn)我看的大部分論文都是工程師論文而不是算法論文,因?yàn)榫拖裎覐?qiáng)調(diào)的,大模型的弱點(diǎn)需要工程彌補(bǔ),工程是研發(fā)和產(chǎn)品經(jīng)理共同搭建的,看不懂算法的論文不打緊,看不懂工程師的論文可能真的得反思一下。
6.3 產(chǎn)品經(jīng)理必須要學(xué)會自己調(diào)用 API
正如文提到的,未來 AI 產(chǎn)品團(tuán)隊(duì)的能力,不取決于誰家模型更強(qiáng),反正開源模型一定最終會變得最強(qiáng),而取決于誰家能用好 AI 模型。
而誰能用好 AI 模型,又取決于哪個團(tuán)隊(duì)做實(shí)驗(yàn)的本里強(qiáng),誰能更快的做完更多的實(shí)驗(yàn),誰就牛逼。
有的人可能會問,我用 coze 或者是 KimiChat 行不行,我的答案是不行。
因?yàn)檫@兩個本身就已經(jīng)是 AI 產(chǎn)品了,和 AI 的 API 差距很大,給 KimiChat 傳個 PDF,人家解讀的又快又好,你怎么知道它解讀的好是因?yàn)槟P团1疲€是因?yàn)?PDF 格式轉(zhuǎn) MD 數(shù)據(jù)清理的好呢?
這就需要產(chǎn)品經(jīng)理必須要具備非??焖俚穆阏{(diào)用 API 做實(shí)驗(yàn)的能力。
那么不會寫代碼,怎么快速獲得這種能力?用 Dify 或者 n8n 這樣的低代碼平臺來解決。
就我自己來看,我認(rèn)為 n8n 更靠譜。n8n 是一個 Coze 的開源免費(fèi)上位替代,一個可視化低代碼自動化 Workflow 平臺,能夠方便的讓不會寫代碼的朋友體驗(yàn) AI 開發(fā)的樂趣和效果。
用它可以輕易的創(chuàng)建很多扣子完成不了的復(fù)雜自動化 Workflow。比如 Webhook 觸發(fā),比如 1000 多種第三方接入,比如發(fā)起自定義的 HTTP Request。
并且因?yàn)?n8n 不是從這一輪 AI 浪潮才開始做的,所以它的生態(tài)也比這一輪 AI 后才涌現(xiàn)出的 Workflow 工具(比如 Dify)更完善,官方接入的集成服務(wù)更多,社區(qū)更活躍。
n8n 就是大模型的五官、軀干和四肢,動手又動腦,才能有創(chuàng)造。
在這里我推薦一個 n8n 的中文教程《簡單易懂的現(xiàn)代魔法》,這應(yīng)該是目前市面上最好的 n8n 中文教程。
教程地址:https://n8n.akashio.com/
6.4 幾個 AI Agent 實(shí)踐的建議
6.4.1 設(shè)計(jì) Agent 的關(guān)鍵思路
想象一下 20 個實(shí)習(xí)生幫你干活,你要怎么分配任務(wù)?實(shí)習(xí)生的特點(diǎn)是什么?
- 能執(zhí)行
- 無法拆解復(fù)雜問題
- 執(zhí)行順序可能是有問題的,你如果不規(guī)定執(zhí)行順序,會怎么樣?可能會拖慢項(xiàng)目進(jìn)度
- 記憶力一般,一下子太多任務(wù)記不住,可能會忘記
- 可能會出錯,所以最好有交叉驗(yàn)證
所以如果你把 AI 視作為一個又一個不知疲倦的實(shí)習(xí)生,你認(rèn)為他們能干嘛?當(dāng)然是設(shè)計(jì)好 SOP 和產(chǎn)出物標(biāo)準(zhǔn),讓他們?nèi)プ鲞@些量大且重復(fù)性的工作啦。
當(dāng)然實(shí)習(xí)生和 AI 有一個比較大的差別,就是 AI 確實(shí)比實(shí)習(xí)生,甚至不少正式員工在解決特定問題的時候強(qiáng)很多。
也貴很多,GPT-4 回答一個問題一個來回 API 的定價可能在 3 美分左右。
人比機(jī)器便宜,可能是未來大家不被 AI 淘汰的重要理由(bushi)。
6.4.2 把任務(wù)拆小拆細(xì),避免互相影響
把一個復(fù)雜問題拆成多個簡單問題,然后再讓模型處理有兩個好處:
第一、正如上文所描述,大模型的不穩(wěn)定性和它接收的文本規(guī)模大小完全是呈正相關(guān)的,如果把問題拆小就意味著單詞任務(wù)模型要處理的文本變少。
第二、一些簡單的問題根本沒必要用大模型,甚至可以用簡單的模型或者是純邏輯去判斷,更便宜、速度更快,甚至效果可能會更好。
6.4.3 區(qū)分離線任務(wù)和在線任務(wù)
以 Grpah RAG 架構(gòu)為例子, 它一共分為三個步驟:
- 將待搜索的知識進(jìn)行一個三元組抽取(主謂賓),這個抽取的動作需要 LLM 介入,存入圖數(shù)據(jù)庫中(可離線處理);
- 將用戶提出來的關(guān)鍵詞,用 LLM 做一次擴(kuò)散,擴(kuò)散出來同義詞,近義詞等,然后在圖數(shù)據(jù)庫進(jìn)行檢索,找到相關(guān)文檔(必須是在線服務(wù));
- 將查詢出來的相關(guān)內(nèi)容作為上下文,和用戶提出的問題一起交給大模型來生成內(nèi)容(必須是在線服務(wù));
其中前兩個步驟是離線任務(wù),離線任務(wù)意味著可以花費(fèi)較多的時間對數(shù)據(jù)做精細(xì)化的處理,比如我們可以用一個開源但是性能強(qiáng)悍的大模型,用自己的服務(wù)器去跑任務(wù),以此來在保證質(zhì)量的時候降低成本。
而在線任務(wù)則意味著需要較強(qiáng)的時效性,如果在線任務(wù)本身復(fù)雜度并不高,也可以選擇更加輕量級的模型來保證回復(fù)速度。
同時離線任務(wù)的結(jié)果會被存儲并且反復(fù)調(diào)用,用質(zhì)量更好的模型相當(dāng)于做了一些固定成本的投入,而在線任務(wù)都是和用戶交互直接相關(guān)的,這些本質(zhì)上是邊際成本。
6.4.4 每一個離線任務(wù)都可以考慮用模型來解決
在 Hybrid RAG 中,對 html 轉(zhuǎn) MD 的工作用的是 Python 庫進(jìn)行的,其實(shí)這項(xiàng)工作如果純粹追求效果的話,完全可以考慮直接用大模型來做。
當(dāng)然具體是用 Python 庫還是用大模型,其實(shí)是取決于成本和效果的考量的,這個也需要通過實(shí)驗(yàn)來證明。
我自己的經(jīng)驗(yàn)是這種數(shù)據(jù)清洗的工作適合用 Python 庫做一輪,再用大模型做一輪清洗,效果可能會更好,但是很多時候 Python 庫已經(jīng)足夠干凈了,中間夾雜一些錯誤的格式編碼其實(shí)也不影響后續(xù)大模型的判斷,這種情況下做不做都是無所謂的。
總而言之大模型在特定環(huán)節(jié)的工作能力是非常強(qiáng)的,如果不是考慮成本,其實(shí)幾乎每個環(huán)節(jié)都可以用大模型解決。
6.4.5 成本和效果要做 Trade off
眾所周知,大模型回答有一定的隨機(jī)性,要怎么解決這個問題呢?當(dāng)然是一個問題重復(fù)問幾遍啦。
比如論文《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》中提到的如何測試兩種 RAG 方法的效果,用人力標(biāo)注太麻煩了,所以他們連檢查樣本的工作都交給大模型來做了,真是牛逼(有錢)。
為了保證結(jié)果正確,一個標(biāo)注要重復(fù)做 4-5 遍,成本自然也是 4-5 倍。
對于設(shè)計(jì)產(chǎn)品的同學(xué)來說就非常需要判斷成本和效果之間怎么平衡了。
6.4.6、Agent、微調(diào)、提示詞之間的邊界與最佳實(shí)踐
如果我們把提示詞工程、Agent 的建設(shè)和模型微調(diào)對應(yīng)到我們給一個人布置任務(wù),就可以這么理解。
- 提示詞工程相當(dāng)于你在布置任務(wù)的時候說的很詳細(xì)。
- Agent 建設(shè)相當(dāng)于你給這個人布置任務(wù)的時候,把 SOP 拆清楚,并且告訴他公司里面有哪些工具可以用。
- 模型微調(diào)相當(dāng)于做培訓(xùn)。
所以完成一個任務(wù),可能三種手段都需要用上,但是三種手段的成本是不一樣的。
而為了完成一個任務(wù),應(yīng)該用哪種優(yōu)化手段,這就是目前工程、算法、產(chǎn)品、學(xué)者這幾方面都非常模糊的地方,這個就好像是在航?;蛘咄诘V,又像是臨床醫(yī)學(xué),怎么決定用什么手段,本質(zhì)上是一個“實(shí)驗(yàn)”,而不是一個“推理”。
這也就是為什么上面列出來的每一篇論文都需要列非常多的基準(zhǔn)測試,因?yàn)樵O(shè)計(jì)這些 Agent 的人自己都不知道結(jié)果到底好不好,需要實(shí)驗(yàn)才能驗(yàn)證。
所以我認(rèn)為,未來哪個團(tuán)隊(duì)?wèi)?yīng)用 AI 的能力強(qiáng),哪個團(tuán)隊(duì)?wèi)?yīng)用 AI 的能力弱,其實(shí)就取決于:
- 這個團(tuán)隊(duì)有沒有牛逼的基準(zhǔn)測試參考答案;
- 這個團(tuán)隊(duì)能不能有一個平臺可以更快的驗(yàn)證自己的設(shè)計(jì)是不是合理的;
誰實(shí)驗(yàn)做得快,誰就牛逼,工程化產(chǎn)品化反而是最后一步。
最后我個人建議是能不要微調(diào),就不要微調(diào),因?yàn)槲⒄{(diào)會改變模型的參數(shù)層,成本很高而且無法遷移。而且微調(diào)的本質(zhì)是在和大模型團(tuán)隊(duì)卷算法,卷數(shù)據(jù),內(nèi)卷在長期來看,是沒有意義的。
本文由人人都是產(chǎn)品經(jīng)理作者【汐箋】,微信公眾號:【最小可讀】,原創(chuàng)/授權(quán) 發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于 CC0 協(xié)議。
你的內(nèi)容太長了,而且深淺不一。你可以分別發(fā)布
太強(qiáng)了,學(xué)習(xí),收藏反復(fù)學(xué)習(xí)
厲害!
好文!
深入淺出,手動點(diǎn)贊~
作為產(chǎn)品經(jīng)理,讓AI與我們的工作互相融合是一個非常大的考驗(yàn)
好的,我再多看幾遍
文章說的很明白,看下來已經(jīng)對AI有一個基本的了解了。