Z Highlights
LLMs的魔力在于,它們非常靈活,可以適應許多不同的情境,并且擁有基本的智能。
我們認為,隨著時間的推移,UI和UX將變得越來越自然語言化,因為這就是Agent系統的思維方式,或者說這基本上是大語言模型(LLMs)訓練的基礎。
如果你要讓某人接受AI Agent,他們實際上是在進行某種程度的“信任飛躍”,因為對很多人來說,這是一個非常陌生的領域。
AI Agent重塑客戶體驗
Jesse Zhang:如何實際構建一個Agent?我們的觀點是,隨著時間的推移,它將越來越像基于自然語言的Agent,因為這就是大語言模型(LLMs)訓練的方式。
從長遠來看,如果你擁有一個超級智能的Agent,它實際上就像一個人類一樣,你可以向它展示東西,向它解釋,給它反饋,它會在腦海中更新信息。
你可以想象有一個非常能干的人類團隊成員,他們剛加入時,你教他們一些東西,他們開始工作,然后你給他們反饋,并向他們展示新的資料。
最終,它會朝這個方向發展——變得更加對話化,更加基于自然語言,人與人之間的交流方式將變得更自然。而且人們不再使用那些復雜的決策樹來捕捉需求,這種決策樹雖然可以起作用,但容易崩潰。
過去我們不得不這樣做,因為我們沒有大語言模型。但現在,隨著Agent的不斷進步,用戶體驗(UX)和用戶界面(UI)將變得更加對話化。
Derrick Harris:大家好,歡迎收聽A16z AI播客。我是Derrick Harris,今天的節目中,我將與Decagon的聯合創始人兼首席執行官Jesse Zhang以及a16z的合伙人Kimberly Tan一起討論。Kimberly將主持討論,Jesse將分享他在構建Decagon公司及其產品方面的經驗。
如果你不太了解,Decagon是一家為企業提供AI Agent以協助客戶支持的初創公司。這些Agent既不是聊天機器人,也不是單一API調用的LLM封裝,而是經過高度定制的先進Agent,能夠根據公司的具體需求處理復雜的工作流程。
除了解釋為什么他們創建Decagon以及它是如何架構以處理不同的LLM和客戶環境之外,Jesse還談到了按每次對話收費的商業模式的好處,以及AI Agent將如何改變客戶支持負責人所需的技能。
還值得一提的是,Kimberly最近寫了一篇博客文章,標題是《RIP to RPA, The Rise of Intelligent Automation》,我們在本期節目中也簡要討論了這篇文章。
這篇文章是了解自動化在商業流程中如何起飛的一個很好的起點,我們將在節目說明中提供鏈接。最后提醒一下,本文內容僅供參考,不應被視為法律、商業、稅務或投資建議,也不應用于評估任何投資或證券,且不針對任何a16z基金的投資者或潛在投資者。
Jesse Zhang:簡要介紹一下我自己。我出生并成長在博爾德,從小參加了很多數學競賽之類的活動。在哈佛學習計算機科學,之后創辦了一家公司,也得到了a16z的支持。我們最終被Niantic收購。
然后我們開始打造Decagon。我們的業務是為客戶服務構建AI Agent。最開始,我們做這件事,是因為我們希望做一些對我們自己來說非常貼近的事情。
當然,大家都不需要被教導AI Agent在客戶服務中的作用,對吧?我們都曾經在與航空公司、酒店等的電話中等待過。所以這個想法就從這里產生了。
我們與很多客戶進行了交流,具體了解應該構建什么樣的產品。對我們來說,特別突出的一個點是,隨著我們對AI Agent的了解加深,我們開始思考未來當有很多AI Agent時,情況會是怎樣。我認為每個人都相信未來會有很多AI Agent。
對我們來說,值得思考的是,那些圍繞?AI?代理工作的員工會做些什么?他們會有什么樣的工具?他們會如何控制或查看與他們合作或管理的Agent?
所以這就是我們圍繞這個問題來構建公司的核心。我認為,這也是我們目前與眾不同的地方,因為我們為這些AI Agent提供了各種工具,幫助我們合作的人員構建、配置這些Agent,讓它們不再是一個“黑箱”。這就是我們打造品牌的方式。
Derrick Harris:是什么激發了你的靈感,因為你上一家公司是一個面向消費者的視頻公司,是什么促使你轉向企業軟件領域的?
Jesse Zhang:很好的問題。我認為,在選擇話題時,創始人通常會比較“話題無關”,因為實際上,當你接觸到一個新領域時,你通常是比較天真的。因此,從一個全新的視角看待事物有其優勢。所以當我們在構思時,幾乎沒有什么話題是限制的。
我認為,對于更多量化背景的人來說,這是一個很常見的模式,包括我自己。試過了消費產品之后,你會更多地傾向于企業軟件,因為企業軟件的問題更具體。
你有實際的客戶,他們有實際的需求和預算之類的東西,你可以針對這些進行優化并解決問題。而消費者市場雖然也很有吸引力,但它更多是基于直覺的,而不是通過實驗來推動。對我個人而言,企業軟件更適合我。
Kimberly Tan:首先,我們可以從這個問題開始,Decagon今天處理的最常見的支持類別是什么?能否詳細講一下你們是如何利用大語言模型(LLMs)來解決這些問題的,以及現在可能做得到的,而以前做不到的事情?
Jesse Zhang:如果你回顧一下之前的自動化,你可能會使用決策樹來做一些簡單的事情,確定要走哪條路徑。但我們都用過聊天機器人,那是相當讓人沮喪的體驗。
通常你的問題無法通過決策樹完全解決。所以你最終會被引導走一條與問題相關,但并不完全符合的問題路徑。現在,我們有了大語言模型(LLMs)。LLMs的魔力在于,它們非常靈活,可以適應許多不同的情境,并且擁有基本的智能。
當你將這一點應用于客戶支持時,或者說客戶提問時,你就能夠提供更個性化的服務。這是第一點,個性化的程度大大提升。這就解鎖了更高的指標。你能夠解決更多的問題,客戶更滿意,客戶滿意度提高。
接下來的自然步驟是:如果你有了這種智能,你應該能夠做更多人類能夠做的事情。人類能做的事情是,他們可以實時拉取數據,可以采取行動,可以通過多個步驟進行推理。如果客戶提出一個相對復雜的問題,可能是“我想做這個和那個”,而AI只準備好處理第一個問題。LLM足夠智能,能夠識別出這里有兩個問題。首先,它會解決第一個問題,然后幫助你解決第二個問題。
在LLM出現之前,這基本上是不可能做到的。所以我們現在看到,技術在能夠做的事情上有了一個階躍式的提升,這就是因為LLM的出現。
Kimberly Tan:在這個背景下,你是如何定義AI Agent的?因為“Agent”這個詞被廣泛使用,我很好奇在Decagon的上下文中,它究竟意味著什么?
Jesse Zhang:我會說,Agent更多是指多個LLM(大語言模型)系統協同工作的一個系統。你有一個LLM調用,基本上是通過發送一個提示,然后得到一個回應。對于一個Agent來說,你希望能夠將多個這樣的調用連接起來,甚至可能是遞歸的。
比如說,你有一個LLM調用,它決定如何處理這個消息,然后它可能引發其他調用,這些調用會拉取更多的數據,執行行動,并迭代用戶所說的內容,甚至可能提出后續問題。所以對我們來說,Agent可以理解為它幾乎是一個LLM調用、API調用或者其他邏輯的網絡,它們共同工作以提供更好的體驗。
Kimberly Tan:在這個話題上,或許我們可以多談談你們實際構建的Agent基礎設施。我覺得有一個非常有趣的點是,市面上有很多關于AI Agent的演示,但我認為很少有真正能夠在生產環境中穩定運行的例子。而且從外部很難知道,什么是真實的,什么不是。
所以在你看來,今天的AI Agent在哪些方面做得很好,而在哪些方面仍然需要技術突破才能讓它們變得更加穩健和可靠?
Jesse Zhang:我的看法實際上有些不同,判斷一個AI Agent是僅僅是一個演示,還是“真正工作”的區別,并不完全在于技術棧,因為我認為大多數人可能使用的是大致相同的技術。我認為一旦你在公司發展的過程中走得更遠,比如像我們公司已經成立了一年多,你就會創造出一些非常具體的、符合你用例的東西。
但歸根結底,大家都可以訪問相同的模型,也能使用相似的技術。我認為一個AI Agent能否有效工作的最大區分因素,其實在于用例的形態。一開始很難知道這一點,但回過頭來看,你會發現有兩個屬性對一個AI Agent能夠超越演示,進入實際應用非常重要。
第一個是你解決的用例,ROI(投資回報率)必須是可以量化的。這非常重要,因為如果ROI無法量化,那么就很難說服人們真正使用你的產品并為此付費。以我們為例,量化的指標就是:你解決了多少比例的支持請求?因為這個數字是明確的,人們就能理解——哦,好吧,如果你解決得更多,我可以將這個結果和我目前的支出、花費的時間進行對比。所以,如果有了這個指標,另一個對我們來說非常重要的指標是客戶滿意度。因為能夠輕松量化ROI,人們才會真正去采納它。
第二個因素是,用例必須是逐步遞增的。如果你需要一個Agent在一開始就能達到超人水平,解決幾乎100%的用例,那也非常困難。因為正如我們所知道的,LLMs是非確定性的,你必須有某種應急方案。幸運的是,支持用例有一個很好的特點,那就是你總是可以將問題升級給人工客服。即使你只能解決一半的問題,對人們來說,這也是非常有價值的。
所以我認為,支持這個用例具有這樣一個特點,使得它非常適合AI Agent。我認為還有很多其他領域,人們可以創建令人印象深刻的演示,你甚至不需要仔細看,就能理解為什么AI Agent會有用。但如果需要一開始就完美無缺,那就很困難了。如果是這種情況,幾乎沒有人愿意嘗試或使用它,因為它不完美的后果可能非常嚴重——比如安全問題。
比如說,人們做模擬時,總會有這樣的經典想法:“哦,如果LLMs能讀取這個就太好了。”但很難想象有人會說:“好吧,AI Agent,去做吧。我相信你能做到。”因為如果它犯一個錯誤,后果可能非常嚴重。
Jesse Zhang:這個通常由我們的客戶來決定,實際上我們看到差異性非常大。在一個極端的情況下,有些人真的會讓他們的Agent看起來像人類,因此會有一個人類頭像、一個人類名字,回應也很自然。另一方面,Agent則直接表明自己是AI,明確告訴用戶這一點。我認為我們合作的不同公司對此有不同的立場。
通常情況下,如果你處在一個受監管的行業,你必須明確說明這一點。我覺得現在很有意思的是,客戶的行為正在發生變化。因為我們的許多客戶收到了大量社交媒體的反饋,比如“天哪,這是我試過的第一個聊天體驗,竟然感覺如此真實”或者“這簡直是魔法”。這對他們來說非常好,因為現在他們的客戶也在學到,嘿,如果是AI體驗,實際上可能比人類更好。過去并不是這樣的,因為過去我們大多數人都經歷過那種電話客服體驗:“好吧,AI,AI,AI…”
Kimberly Tan:你提到過幾次個性化的概念,大家在底層使用相同的技術架構,但在支持服務方面有不同的個性化需求。你能談一談這個問題嗎?具體來說,你們是如何實現個性化的,以至于能夠讓人們在線上說“天哪,這是我經歷過的最好的支持體驗”?
Jesse Zhang:對我們來說,個性化來源于對用戶的定制。你需要了解用戶的背景信息,這就是額外需要的上下文。其次,你還需要了解我們客戶的業務邏輯。如果將這兩者結合起來,你就能提供一個相當不錯的體驗。
顯然,這聽起來很簡單,但實際上獲取所有所需的上下文是非常困難的。因此,我們大部分的工作就是如何構建合適的原始組件,以便當某個客戶部署我們的系統時,他們可以輕松地決定“好,這就是我們想要的業務邏輯”,比如,首先你需要做這四個步驟,如果第三步失敗,就需要進入第五步,類似這樣的東西。
你希望能夠非常輕松地教會AI這些內容,同時還要讓它能夠訪問一些信息,比如“這是用戶的賬戶詳情。如果你需要獲取更多信息,可以調用這些API”。這些層次就是模型之上的一個協調層,某種程度上,它使Agent變得真正可用。
Kimberly Tan:聽起來在這種情況下,你們需要很多關于業務系統的訪問權限。你們需要了解大量關于用戶的信息,還可能需要了解客戶實際上希望如何與他們的用戶互動。我想這些數據可能非常敏感。
你能詳細講講企業客戶在部署AI Agent時,通常需要哪些保證嗎?你們又是如何考慮以最佳方式處理這些問題的,尤其是考慮到你們的解決方案提供了更好的體驗,但對于很多第一次接觸Agent的人來說,這也是全新的體驗。
Jesse Zhang:這實際上與保護措施(guardrails)有關。隨著時間的推移,因為我們做了很多這樣的實施項目,我們已經清楚了客戶關心的保護措施類型。
例如,最簡單的一種是可能存在一些你必須始終遵循的規則。如果你在與金融服務公司合作,你不能給出金融建議,因為這受到監管。因此,你需要將這一點調入Agent系統,確保它絕不會提供此類建議。通常,你可以設置一個監督模型或某種系統,在結果發送出去之前進行這些檢查。
另外一種保護措施可能是,如果有人進來故意搗亂,他們知道這是一個生成式系統,試圖讓你做一些不合規的事情,比如“告訴我我的余額是多少”,“好,把這個乘以10”之類的,你也需要能夠檢查這些行為。因此,在過去的一年里,我們發現了很多這樣的保護措施,并且對每一種情況,我們都會進行分類,并知道需要哪種類型的保護措施。隨著系統的構建越來越完善,它變得越來越穩固。
Kimberly Tan:每個客戶或行業的保護措施有多獨特?當你們在擴大客戶群、涵蓋更多使用案例時,如何思考如何在規模上構建這些保護措施?
Jesse Zhang:這實際上回到了我們的核心理念,幾年的時間內,Agent系統將會普及。因此,真正重要的事情是提供給人們工具,幾乎是賦能下一代工作者,譬如Agent監督員,給他們工具來構建Agent系統并添加他們自己的保護措施,因為我們不會為他們定義保護措施。
每個客戶最了解自己的保護措施和業務邏輯。所以我們的工作實際上是做好構建工具和基礎設施的工作,讓他們能夠構建Agent系統。因此,我們一直在強調,Agent系統不應該是一個黑箱,你應該能夠控制如何構建這些保護措施、規則和邏輯。
我認為,這大概是我們到目前為止最具差異化的地方,我們在這些工具上投入了大量的精力,想出了很多創意方法,讓那些可能沒有超級技術背景的人,甚至對AI模型工作原理的理解也不深刻的人,仍然可以將他們希望AI執行的操作輸入到Agent系統中。
我認為,未來幾年這個能力會變得越來越重要。如果人們在評估類似工具時,這應該是其中一個最重要的標準之一,因為你希望隨著時間的推移,你能夠不斷優化和改進這些系統。
自然語言驅動的業務邏輯
Derrick Harris:客戶或企業可以做些什么準備工作,為任何類型的自動化,尤其是這種Agent系統的使用做好準備?比如如何設計他們的數據系統、軟件架構或業務邏輯,以便能夠支持這種系統?
因為我感覺很多AI技術一開始是很新穎的,但當進入現有的遺留系統時,常常會遇到很多亂七八糟的情況。
Jesse Zhang:如果有人現在從零開始構建的話,有很多最佳實踐可以讓你的工作變得更輕松。比如說,如何構建你的知識庫。我們曾寫過一些相關內容,介紹了一些方法,能夠讓AI更容易地攝取信息,并提高其準確性。其中一個具體建議是,將知識庫劃分為模塊化的部分,而不是用一大篇文章包含多個答案。
在設置API時,可以使它們更適合Agent系統,并以一種方式設置權限和輸出,使得Agent系統能夠輕松地攝取信息,而不需要進行大量計算來尋找答案。這些是一些可以采取的戰術性措施,但我不會說有什么是必須做的,才能使用Agent系統。
Derrick?Harris:良好的文檔總是很重要的,本質上就是在有效組織信息。
Kimberly Tan:聽起來,如果你們試圖教人們如何引導Agent系統以最符合其客戶或具體用例的方式進行操作,那么在UI和UX的設計上可能需要大量的實驗,或者說是要在這個全新的領域開辟新天地,因為這和傳統軟件非常不同。
我很好奇,你們是如何思考這個問題的?在Agent優先的世界中,UI和UX應該是什么樣的?你們認為未來幾年它會如何變化?
Jesse Zhang:我不會說我們已經解決了這個問題。我認為我們可能找到了一個適合當前客戶的局部最優解,但這仍然是一個持續的研究領域,對我們和許多其他人來說都是如此。
核心問題回到我們之前提到的,就是你有一個Agent系統。首先,如何能清楚看到它正在做什么,它是如何做決策的?然后,如何利用這些信息來決定需要更新什么,以及應該給AI什么反饋。這些就是UI元素匯聚的地方,尤其是第二部分。
我們認為,隨著時間的推移,UI和UX將變得越來越自然語言化,因為這就是Agent系統的思維方式,或者說這基本上是大語言模型(LLMs)訓練的基礎。
從極限角度看,如果你有一個超智能的Agent,它基本上就像一個人一樣,你可以向它展示東西,向它解釋,給它反饋,它就會在自己的“腦海”中更新。你可以想象一下有一個非常能干的人加入你的團隊,你教給他一些東西,他開始工作,然后你不斷給他反饋,可以向他展示新的東西,新的文檔、圖表等等。
我認為在極限情況下,它會朝著這個方向發展:事情變得更加對話化,變得更加基于自然語言,人們不再像過去那樣用復雜的決策樹來構建系統,捕捉你想要的東西,但這種方法很容易崩潰。我們過去不得不這樣做,因為那時沒有LLMs,但現在隨著Agent系統越來越強大,UI和UX將變得更加對話化。
Kimberly Tan:大約一年多前,也就是Decagon剛開始的時候,人們普遍認為,LLM非常適用的很多用例,實際上也只是一些所謂的“GPT封裝器”,即公司只需要通過一個API調用一個基礎模型,就能立即解決他們的支持問題。
但顯然,隨著公司選擇使用像Decagon這樣的解決方案,而不是直接采用那種方式,事實證明情況并非如此。我想知道你能否解釋一下,為什么情況會這樣?究竟是什么讓人們在內部構建時遇到的挑戰比預期的更復雜?他們對這個概念理解有何誤區?
Jesse Zhang:作為“GPT封裝器”并沒有錯,你可以說Purcell就是一個AWS封裝器之類的。通常,當人們使用這個術語時,意味著貶義的意思。
我個人的看法是,我認為如果你正在構建一個Agent系統,按定義,你肯定會利用LLMs作為工具。所以你實際上是基于現有的東西來構建,就像你通常基于AWS或GCP來構建一樣。
但真正遇到麻煩的地方是,如果你在LLM上構建的軟件不夠“厚重”或不夠復雜,以至于沒有讓人感覺到存在差異化,那就會有問題。
對我們來說,回顧一下,我們賣的東西基本上是軟件。我們其實就像一個普通的軟件公司,只不過我們把LLMs作為軟件的一部分和工具之一來使用。但當人們購買這種產品時,他們主要是想要軟件本身。他們想要能夠監控AI的工具,想要能夠深入挖掘AI每一場對話的細節,想要能夠給反饋,能夠不斷構建和調整系統。
所以,這就是我們的軟件的核心內容。即使是Agent系統本身,人們遇到的問題是,做一個演示很酷,但如果要把它變得適合生產并真正面向客戶,你就得解決很多長期存在的問題,比如防止“幻覺”現象、應對那些試圖搞破壞的不良行為者。我們還得確保延遲足夠低,語氣合適等等。
我們和很多團隊談過,他們做了一些實驗,構建了初步版本,然后他們會發現:“哦,確實,我們不想成為那些在后期不斷構建這些細節的人。”他們也不想成為不斷為客戶服務團隊添加新邏輯的人。所以,這時候,選擇和別人合作似乎更合適。
Kimberly Tan:你提到了一些長期存在的問題,比如需要應對不良行為者等等。我相信很多聽眾在考慮使用AI Agent時,都會擔心引入LLMs后會出現新的安全攻擊路徑,或者引入Agent系統后可能帶來新的安全風險。你們是如何看待這些問題的?以及在處理Agent時,確保依然具備頂級企業安全的最佳實踐是什么?
Jesse Zhang:在安全方面,有一些顯而易見的措施可以采取,這些我之前提到過,比如你需要有保護措施。核心問題是,人們對LLMs的擔憂是它們不是確定性的。
但好消息是,你實際上可以將大部分的敏感和復雜操作放在一個確定性的墻后面,當它調用API時,計算就在那發生。所以你并不會完全依賴LLM來處理,這樣就能避免很多核心問題。
但是,依然會有一些情況,比如,不良行為者的干擾或者有人試圖讓系統產生幻覺等。我們觀察到,在很多我們合作的大客戶中,他們的安全團隊會進入,基本上就是對我們的產品進行“紅隊”測試,花幾周時間不斷地向系統發起各種可能的攻擊,試圖找出漏洞。隨著AI Agent變得越來越普及,我們可能會看到這種情況越來越多,因為這是測試系統是否有效的最佳方法之一,就是通過紅隊測試,給它丟一些東西,看看能否突破防線。
現在也有一些初創公司在開發紅隊工具,或者讓人們能夠自己進行這類測試,這也是我們目前看到的一種趨勢。很多我們合作的公司,在銷售周期的后期階段,他們會讓自己的安全團隊,或者是與外部團隊合作,對系統進行壓力測試。對于我們來說,能夠通過這樣的測試是必須的。所以,最終歸結起來就是這樣。
Derrick Harris:這是你們鼓勵客戶做的嗎?因為在我們討論AI政策時,我們提到過一個重要的方面,就是應用層,強調將責任放在LLM的使用者和運行應用的人身上,而不是單純把責任歸咎于模型本身。就是說,客戶應該進行紅隊測試,識別具體的用例和攻擊路徑,確定哪些漏洞需要保護,而不是僅僅依賴OpenAI或其他公司已經設置好的安全防護。
Jesse Zhang:完全贊同。我還認為,可能會有一波新的通知需求出現,類似于現在大家都在做SOC 2認證、HIPAA認證之類的,不同行業都有要求。通常,當你銷售普通的SaaS產品時,客戶會要求滲透測試,我們也必須提供我們的滲透測試報告。對于AI Agent來說,未來可能會有類似的需求,可能會有人為其命名,但這基本上是測試Agent系統是否足夠強大的新方式。
Kimberly Tan:有一件事很有趣,顯然大家對所有大型實驗室推出的新模型突破和技術突破都非常興奮。作為一家應用AI公司,你們顯然沒有自己做研究,而是利用這些研究并圍繞它構建大量軟件,以便交付給最終客戶。
但你們的工作建立在迅速變化的技術基礎之上,我很好奇,作為一家應用AI公司,你們是如何在能夠預測自己的產品路線圖、構建用戶需求的同時,又能保持對新技術變化的關注,并理解它們如何影響公司的?更廣泛來說,面對類似情況的應用AI公司,應該采取什么樣的戰略?
Jesse Zhang:其實你可以把整個堆棧分成不同的部分。比如LLMs,如果從應用層來看,LLMs就位于底層。你可能會有一些工具位于中間,幫助你管理LLMs,或者做一些評估之類的工作。然后,最上層的部分基本上就是我們構建的,實際上它也像標準的SaaS一樣。
所以,我們的大部分工作其實跟普通軟件沒太大區別,除了我們有一個額外的研究組件——LLMs變化太快了。我們需要研究它們能做什么,它們擅長什么,應該用哪個模型來執行某個任務。這是一個很大的問題,因為OpenAI和Anthropic都在推出新技術,Gemini也在逐漸進步。
因此,你必須有自己的評估機制,了解哪個模型適合在哪種情況下使用。有時候你還需要進行微調,但問題是:何時進行微調?什么時候微調才是值得的?這些大概是我們主要關注的與LLMs相關的研究問題。但至少到目前為止,我們并沒有感到SaaS在快速變化,因為我們現在并不依賴于中間層。所以,基本上是LLMs在發生變化。它們變化的頻率并不高,即使發生變化,通常也是一次升級。比如Claude 3.5 sonnet幾個月前更新了一次,那時我們就想:“好吧,我們要不要換成新的模型而不是繼續用舊的?”
我們只需要運行一系列的評估,一旦換成了新的模型,就不再去想它了,因為你已經在使用新模型了。然后,o1版本出來了,情況也是類似的,想想它能用在哪些方面。在我們的案例中,o1對大多數面向客戶的使用場景來說有點慢,所以我們可以把它用于一些后臺工作。歸根結底,我們只需要有好的系統來做模型的研究。
Kimberly Tan:你們多久評估一次新的模型,決定是否更換?
Jesse Zhang:每次有新模型出來時,我們都會評估。你必須確保即使新的模型更智能,也不會破壞你已經建立的某些用例。這是有可能發生的。比如,新的模型整體上可能更智能,但在某些極端情況下,它在你某個工作流程中的A/B選擇上表現不佳。這就是我們進行評估的目的。
我認為總的來說,我們最關心的智能類型,應該是我所說的“指令跟隨能力”,我們希望模型能夠越來越擅長執行指令。如果是這種情況,那對我們來說是絕對有利的,非常好。
看起來最近的研究更多集中在推理類型的智能上,比如更好地進行編程、更好地進行數學運算等。這對我們也有幫助,但沒有指令跟隨能力的提升那么重要。
Kimberly Tan:你提到的一個非常有趣的點,我也認為對于Decagon來說非常獨特,那就是你們在內部建立了大量的評估基礎設施,以確保你們確切知道每個模型在你們提供的一組測試下的表現。
你能詳細講講這個嗎?這個內部評估基礎設施有多重要,具體是如何讓你們和你們的客戶都對Agent的表現充滿信心的?因為其中一些評估也是面向客戶的。
Jesse Zhang:我認為這非常重要,因為如果沒有這些評估基礎設施,我們很難快速迭代。
如果你覺得每次更改都有很大可能性會破壞某些東西,那么你就不會快速做出改變。但是,如果你有了評估機制,那么,當有大的變化、模型更新或者有新的東西出現時,你可以直接將它與所有的評估測試對比。如果評估結果良好,你就可以感覺到:好,我們做出了改進,或者可以放心發布而不必太擔心了。
所以,在我們的領域,評估需要客戶的輸入,因為客戶才是決定某些東西是否正確的人。當然,我們可以檢查一些高層次的問題,但通常是客戶提供具體的用例,并告訴我們正確的答案是什么,或者它必須怎樣,必須保持什么樣的語氣,必須說什么。
評估就是基于這些來進行的。所以,我們必須確保我們的評估系統足夠穩健。最開始我們是自己構建的,它的維護并沒有那么困難。我們也知道有一些評估公司,曾經探索過其中一些,也許在某個時刻,我們會考慮是否采用它們,但目前來說,評估系統已經不再是我們的痛點。
Kimberly Tan:今天一個很流行的話題是多模態,意思是AI Agent應該能夠跨越所有人類今天使用的形式進行互動,不論是文本、視頻、語音等。我知道Decagon最初是以文本為主的。從你的角度來看,多模態對AI Agent有多重要?你認為它成為主流甚至是標準的時間框架是什么時候?
Jesse Zhang:它很重要,從公司的角度來看,添加一種新的模態并不是特別困難。雖然并不簡單,但核心是:如果你解決了其他問題,比如我提到的那些——例如構建AI、監控它并且有適當的邏輯,那么添加一種新的模態并不是最難的事情。因此,對我們來說,擁有所有模態是非常有意義的,它能擴展我們的市場。我們基本上是模態不可知的,我們為每種模態都構建了自己的Agent。
一般來說,限制因素有兩個:第一,客戶是否準備好采用新模態?我認為從文本開始非常有意義,因為這是人們最積極采納的方式,而且對于他們來說風險較低,容易監控,也更容易理解。另一個大模態是語音。顯然,我認為市場中仍然有空間,用戶對語音的接受度還需要提高。目前,我們看到一些早期的嘗試者已經開始采用語音Agent,這很令人興奮。另外一方面是技術上的挑戰。大多數人都會同意,語音的標準更高。如果你和某人在電話中交談,你需要語音延遲非常短。如果你打斷對方,他們需要自然地回應。
由于語音的延遲更低,你必須在計算方式上更加巧妙。如果你是在聊天中,回應時間是五到八秒,你幾乎不會注意到,感覺非常自然。但是如果在電話中,回應時間也需要五到八秒,那么就會顯得有點不自然了。因此,語音的技術挑戰會更多。隨著這些技術挑戰的解決,以及市場對于采用語音的興趣增加,語音作為一種新模態才會變得主流。
飛躍信任的商業模式
Kimberly Tan:在我們繼續之前,我想再談一下AI Agent的商業模式。在你們第一次構建AI Agent或與客戶討論他們使用的系統、處理的數據和他們的顧慮時,有沒有什么讓你感到意外的事情?有哪些非直觀的或者令人驚訝的事情是Decagon為了更好地服務企業客戶所必須做的?
Jesse Zhang:我認為最令人驚訝的是,當我們剛開始時,人們愿意和我們聊的程度。畢竟我們當時只是兩個人。我們倆之前都創辦過公司,所以認識了很多人,但即便如此,對于每一個創業者來說,想要獲得引薦對話時,如果你說的內容并不特別吸引人,那對話通常都比較冷淡。
但當我們開始談論這個用例時,實際上我覺得挺令人驚訝的,人們對于談論這個話題的興奮程度。因為這個想法看起來是如此顯而易見。你可能會想,既然這是一個顯而易見的想法,應該已經有別人做了,或者已經有解決方案,或者別人已經想出了某種解決方案。但我認為我們趕上了一個好時機,那個用例確實很大,大家真的很關心。正如我之前提到的,那個用例非常適合采用AI Agent并將其推向生產環境,因為你可以逐步實施,能夠追蹤投資回報率。
這讓我感到很驚喜,但顯然,在此之后還有很多工作要做,你必須與客戶合作,必須建立產品,必須弄清楚該走哪條路。在最初的階段,這確實是一個令人驚訝的發現。
Derrick Harris:Kimberly,我覺得我應該提到你寫的那篇《RIP to RPA》的博文,里面涉及了很多自動化任務和創業公司的內容。你認為在這些自動化任務中,或者說解決方案沒有那么理想,所以大家總是在尋找更好的方法,是否有這樣的現象呢?
Kimberly Tan:是的我確實這么認為。我想說幾件事。首先,如果一個想法對大家來說顯而易見,但沒有明確的公司來解決它,或者沒有人指著某個公司說“你應該用這個”,那么這意味著這個問題實際上沒有得到解決。
從某種意義上說,它是一個完全開放的機會,適合公司去開發解決方案。因為,正如你所說,我們從一開始就作為投資者關注Decagon。我們看著他們走過了創意迷宮,當他們確定了支持這個方向并開始和客戶溝通時,很明顯,所有客戶都迫切希望能有某種原生的AI支持解決方案。這也是我之前提到的問題之一,很多人認為這只是一個GPT的包裝而已。但是Decagon從一開始就獲得的客戶興趣讓我們很早就意識到,很多這些問題比人們預期的要復雜得多。
我認為這種現象在各個行業中都有出現,無論是客戶服務,還是某些垂直行業中的專業自動化。我認為有一個被低估的點是,正如Jesse之前提到的,能夠明確衡量自動化任務的投資回報率(ROI)。因為,如果你要讓某人接受AI Agent,他們實際上是在進行某種程度的“信任飛躍”,因為對很多人來說,這是一個非常陌生的領域。
如果你能夠自動化一個非常具體的流程,而且這個流程要么是顯而易見的盈利生成流程,要么是以前在業務中構成瓶頸的流程,或者是一個隨著客戶增長或收入增長而線性增加的主要成本中心,那么就會更容易讓AI Agent被接受。能夠將這樣的問題轉化為一個更加產品化的過程,使其能夠像傳統軟件一樣進行規模化,這是非常有吸引力的。
Kimberly Tan:在我們繼續之前,我有最后一個問題。我記得Jesse,之前我們討論時,總是認為企業在采納軟件或AI Agent時,最大的挑戰會是“幻覺”(hallucinations)。但你曾告訴我,這實際上并不是最主要的問題。你能否詳細闡述一下,為什么關于幻覺的看法有些誤解,實際上人們更關心的是什么?
Jesse Zhang:我認為人們確實關心幻覺問題,但他們更關心的是能夠提供的價值。幾乎所有我們合作的企業都關注相同的幾個問題,幾乎是完全一樣的:你能解決多少比例的對話?我的客戶有多滿意?然后,幻覺問題可能會歸入第三類,即準確性如何。一般來說,在評估時前兩個因素更為重要。
假設你正在與一個新的企業對話,并且在前兩個方面做得非常好,那么公司領導層和團隊中的每個人都會非常支持,這時候你就能得到很多支持。他們會覺得,“天哪,我們的客戶體驗不一樣了,每個客戶現在都有自己的個人助理,可以隨時聯系我們,我們給他們提供了很好的答案,他們非常滿意,且支持多語言,全天候服務。”這只是其中一部分,同時你還節省了大量成本。
所以,一旦達成這些目標,就會得到很多支持,并且在推動工作時也會有很多順風。當然,幻覺問題最終還是需要解決,但這并不是他們最關注的事情。解決幻覺的方式就是我之前提到的那些方法——人們會對你進行測試。可能會有一個概念驗證的階段,你實際上會運行真實的對話,他們會有團隊成員在進行監控和檢查準確性。如果這個環節沒有問題,那么通常就可以順利通過。
此外,正如我之前提到的,針對敏感信息,你可以設立一些嚴格的保護措施,比如你不一定需要讓敏感內容生成化。所以,幻覺問題是大多數交易中的一個討論點,它并不是不重要的議題,你會經歷這個過程,但它從來都不是對話的重點。
Kimberly Tan:現在轉到AI Agent的商業模式,今天有一個大話題,就是如何為這些AI Agent定價。
歷史上,很多SaaS軟件是按座位數定價,因為它們是針對單個員工的工作流軟件,用來提高員工的生產力。但AI Agent并不像傳統軟件那樣與單個員工的生產力掛鉤。
所以很多人認為,按座位數定價的方式可能不再適用。我很好奇你們在早期是如何思考這個困境的,最終是如何決定為Decagon定價的,同時,你們認為隨著AI Agent變得越來越普遍,未來軟件定價的趨勢會如何發展?
Jesse Zhang:我們對這個問題的看法是,過去軟件按座位定價,因為它的規模大致是基于可以使用軟件的人數。但對于大多數AI Agent來說,你提供的價值并不依賴于維護它的人數,而是取決于工作的產出量。這與我之前提到的觀點一致,如果投資回報率(ROI)非常可衡量,那么工作產出的水平也是非常清晰的。
我們的看法是,按座位數定價肯定不適用。你可能會基于工作產出定價。所以,你提供的定價模型應該是,工作做得越多,付出的費用就越多。
對我們來說,有兩個明顯的定價方式。你可以按對話計費,或者按AI實際解決的對話計費。我認為我們的一個有趣的經驗是,大多數人選擇了按對話計費模型。原因是,按解決方案計費的主要優勢是,你為AI所做的事情付費。
但隨之而來的問題是,什么才算是“解決方案”?首先,沒人愿意深入探討這個問題,因為這就變成了“如果有人進來很生氣,而你把他們打發走了,為什么我們要為此付費?”
這就形成了一個尷尬的局面,而且也讓AI供應商的激勵機制變得有些奇怪,因為按解決方案計費就意味著,“我們只需要解決盡可能多的對話,推掉一些人”。但有很多情況下,最好的做法是將問題升級處理,而不是直接推掉,客戶并不喜歡這種處理方式。因此,按對話計費會帶來更多的簡潔性和可預測性。
Kimberly Tan:你認為未來定價模式會持續多久?因為現在你提到ROI時,通常是基于過去可能用來支付勞動力成本的支出。隨著AI Agent變得越來越普遍,你認為長期來看,AI會被與勞動力成本進行比較,且這是一個合適的基準嗎?如果不是,你如何看待超越勞動力成本的長期定價?
Jesse Zhang:我認為長期來看AI Agent的定價可能仍會主要與勞動力成本掛鉤,因為這正是Agent的魅力所在——你以前在服務方面的支出現在可以轉移到軟件上。
這部分支出可能是軟件支出的10到100倍,所以很多費用將轉向軟件。因此,勞動力成本自然會成為一個基準。對我們的客戶來說,ROI非常明確。如果你能節省X百萬的勞動力成本,那么采用這種解決方案就有意義。但長期來看,這可能會處于中間地帶。
因為即便是一些不如我們的Agent產品,也會接受較低的定價。這就像經典的SaaS情形,大家都在爭奪市場份額。
Kimberly Tan:你認為當前的SaaS公司,特別是那些產品可能沒有為AI原生構建,或者它們按座位定價,因而無法適應以結果為導向的定價模式,在AI領域的未來會怎樣?
Jesse Zhang:對于一些傳統公司來說,如果它們試圖推出AI Agent產品,確實會有些棘手,因為它們無法用座位數模型來定價。如果你不再需要那么多Agent,那就很難再通過現有產品維持收入。這是傳統公司的一個問題,但也不好說。傳統公司始終擁有分銷渠道的優勢。即使產品不如新興公司好,人們也不愿意花費精力去接受一個質量只有80%的新供應商。
所以,第一,如果你像我們一樣是一家初創公司,就必須確保你的產品比傳統產品優秀三倍。第二,這是典型的傳統公司與初創公司之間的競爭。傳統公司天然具有較低的風險容忍度,因為它們有大量的客戶。如果它們在快速迭代中出了問題,那會造成巨大的損失。而初創公司可以更快迭代,因此,迭代過程本身就能帶來更好的產品,這就是常規的循環。對于我們來說,我們始終以交付速度、產品質量和團隊的執行力為傲。這就是我們贏得當前交易的原因。
Kimberly Tan:你能否對AI在職場中的未來做一些預測?比如,它將如何改變員工需求或能力,或者人類員工與AI Agent如何互動?你認為隨著AI Agent的普及,會有哪些新的最佳實踐或規范成為職場常態?
Jesse Zhang:第一個最重要的變化是,我們深信,未來在職場中,員工花費在構建和管理AI Agent的時間,類似于AI監督員的角色,將會大幅增加。即使你的職位沒有正式是“AI監督員”,但過去你所做的工作中,很多時間將轉向管理這些Agent,因為Agent能給你帶來極大的杠桿效應。
我們在許多部署中已經看到這一點,那些曾經是團隊領導的人,現在花了大量時間在監控AI上,比如確保它沒有問題,或者進行調整,監控整體表現,看是否有特定領域需要關注,是否有知識庫的空白可以幫助AI變得更好,AI能否填補這些空缺。
與Agent合作所帶來的工作內容讓人感覺,未來員工花費在與AI Agent互動上的工作時間將大幅增加。這是我們公司核心的理念,正如我之前提到的。因此,我們的整個產品是圍繞著給人們提供工具、可視化、可解釋性和控制能力來構建的。我認為在一年內,這將成為一個巨大的趨勢。
Kimberly Tan:這很有道理。你認為AI監督員未來需要哪些能力?這種角色的技能集是什么?
Jesse Zhang:這有兩個方面。一方面是可觀察性、可解釋性,是否能夠快速理解AI在做什么,以及它是如何做出決策的。另一方面是決策能力,或者說是構建部分,如何給予反饋,如何構建新的邏輯。我認為這兩者是一個硬幣的兩面。
Kimberly Tan:你認為在中期或長期內,有哪些工作是AI Agent無法處理的,仍然需要由人類來管理和正確執行?
Jesse Zhang:我認為這將主要取決于我之前提到的,“完美度”的要求。有很多工作,其錯誤容忍度非常低。在這些情況下,任何AI工具更像是一個輔助工具,而不是完全的Agent。
比如在一些更敏感的行業,如醫療保健或安全等,你必須幾乎做到完美,那么在這些領域,AI Agent可能會變得不那么自主,但這并不意味著它們就沒用。我認為這種風格會有所不同,在像我們這樣的平臺中,你實際上是在部署這些Agent讓它們自動完成整個工作。
Derrick Harris:這就是本期節目的全部內容。如果你覺得這個話題有趣或有啟發,請給我們的播客打分并分享給更多人。我們預計在年底前發布最后一集,并且會在新的一年重新調整內容。感謝您的收聽,祝大家假期愉快(如果你聽到這個時正值假期)。
原視頻:Can Al Agents Finally Fix Customer Support?
https://a16z.com/podcast/can-ai-agents-finally-fix-customer-support/