我用幾道測試題,發現這家公司把大模型RAG能力卷出了新高度!

我最近跟一位百度的老朋友吃飯聊起來,我很好奇的問他,你覺得大模型最重要的能力是哪個?
他說,RAG
這個回答的乾淨程度還是讓我愣了一下。
在他看來,大模型可以炫技,可以聰明,但從落地的角度來看,要先解決基本問題:真實、可靠、及時。
大模型在各行各業蘊含著變革機會,依賴了一項大模型核心技能——檢索輔助增強(RAG)能力。
簡單來說,RAG 就是讓大模型不再僅僅依賴自身訓練時學習到的知識,而是能夠即時地從外部知識庫(如網際網路)檢索相關資訊,並將其融入到自身的回答中,從而提供更準確、更全面、更及時的答案。
這個技能點,在 AI 產品上,就是大家常說的「聯網搜尋」 功能。
顧名思義,RAG 能力強不強,核心可以拆解為以下三個維度的測評:
  1. 時效性:判斷 AI 回答中的資訊是否已過時,尤其是近日的資訊
  2. 權威性:判斷 AI 的回答是否存在事實性錯誤
  3. 全面性:當問題的答案需要包含多個方面時,判斷 AI 回答的資訊是否儘可能全面、無遺漏
因此,我準備從這三個維度出發,透過一些典型的使用者 case,幫大家感受以 RAG 技術見長的大模型能力。
我收集了一波身邊朋友的反饋,文心、Kimi 和豆包是大家談及搜尋能力時最有印象的幾個大模型。因此,本文就從真實 case 出發,一起來從微觀視角感受下這三個大模型的 RAG 能力表現!

澳網比賽最新進度(時效性 + 全面性)

1 月 26 日剛剛結束的 25 年澳網比賽,男單決賽比賽是北京時間 1 月 26 日 16:30。
本題測試時間:2025 年 1 月 26 日 21 點 04 分
先看引發本文寫作靈感的百度文心,這裡我用的是付費版文心大模型4.0 Turbo——
實話說,這測的第一個 case 有點驚豔到我,因為不僅時效性滿分,而且實在太詳細了,細節資訊到位,而且我對著這個比賽官網檢查了每一個數字,都準確無誤。唯一的瑕疵是全面性,遺漏了男雙和混雙比賽結果,但產品自己回答說主要比賽結果,也理解。
這種強時效問題,不可能在模型訓練階段見過,所以這個回答,我覺得如果是純 RAG 技術主導的,那確實相當不錯了。
接下來是Kimi——
Kimi 回答的結構化組織不錯,但可惜沒有檢索到最新 1 月 26 日的決賽資訊。
再看看豆包——
豆包正確給出了男單比賽的結果,雖然沒有全面列出各個比賽的進度,但單從“最新進度“上來說,這個回答也是沒毛病的。

楊冪的近況(時效性 + 事實性 + 全面性)

上一題是體育資訊,本題則為娛樂資訊,都是非常注重時效性的領域。
題目:我想知道楊冪的近況,請給我每個事件的具體時間,用表格回答
ps:雖說關注明星動態可以去刷微博,但如果未來,你隨時問一嘴某個 AI,他就告訴你愛豆的即時動態,這對於追星來說,也算是成功實現了效率提升。
文心:
楊冪近期事件不少,整體上來說,這個回答的時效性和全面性都是不錯的。
Kimi:
Kimi 本題的回答有些意外,看起來是出幻覺了。我進一步看了下,發現主要是出在參考資料的時效性問題上——排在前面的參考資料不是最新新聞。
豆包:
豆包挖出的楊冪動態,從事件來看,與文心挖出的事件存在互補性。
我做了更多測試後,發現這種娛樂資訊對於大模型六小龍來說,確實比較難與傳統搜尋大廠的 ChatBot 產品抗衡。要解這種 case,需要強時效的資訊源/內容生態建設,百度文心這方面的參考資料大量來自百家號,位元組豆包則大量來自今日頭條,而大模型六小龍,很難為解這一類 Case 去投入做內容平臺。

春運人流情況(時效性 + 全面性)

馬上過年了,測一測今年春運人流的情況。這個就更不可能提前訓練了。
題目:馬上過年了,最近 7 天的春運人員流動量是多少
本題測試時間:2025 年 1 月 26 日 21 點 04 分
文心:
查證了一下,7 天的數字都正確。而且讓我覺得比較好的一點是,點開參考文獻,我發現有不少資料來源是中國交通運輸部官網。
這種對問題關聯官網的檢索能力,對於後面要測的事實性來說,也是非常重要的技能點。
Kimi:
Kimi 的回答也非常清晰,唯一的瑕疵是,其 20 號的資料與運輸部公佈的略有出入。以下是運輸部公佈的正確資料:
豆包:
23~26 號的資訊都給到了,並且沒有錯誤。而且還給到鐵路公路水路這些具體出行方式的資料,這個補充資訊給的好,瑕疵是 21 日和 22 日這兩天資訊沒有檢索到。
實話說,我覺得在搜尋賽道上,百度一支獨大了二十年,我雖然預期它大模型 RAG 會做的不錯,但在這個 case 上的表現是超出我預期的。實戰派的小夥伴,記得將更多實測 case 打到評論區!

查詢社保和納稅證明(事實性 + 全面性測試向)

這道題的回答,需要模型對事實有非常準確的把控,只要有一個操作環節出現了幻覺,使用者就無法完成社保和納稅證明的查詢操作。
此外,真實的使用者搜尋 query,往往非常口語化、不遵循書面語法規範,因此本題進一步加大難度——
題目:我想北京社保連續納稅證明,怎麼操作
文心:
這個回答,沒啥大問題,線上線下注意事項都有了。
Kimi:
Kimi 回答非常詳細,但發現其只給出了北京社保的流程,沒有給到納稅證明的開具流程。
豆包:
豆包也不錯,給出了線上網站、APP 和微信公眾號、線下三種方法。

茶褐素解酒效果(事實性 + 全面性)

這次,來點有難度的專業問題!不僅要檢索網際網路,而且要檢索網際網路中的專業文獻內容了。這些文獻內容,很多都是長而艱深。
題目:茶褐素可以解酒嗎,可以的話提供出一些專業文獻材料
文心:
文心提供了 4 篇專業文獻,並綜合多篇專業文獻中的作用機理,給出了最終結論,無可挑剔。
Kimi:
Kimi 在回答中給到了兩篇專業文獻,而第二篇《茶褐素解酒,科學依據是什麼?一文為你揭曉!》嚴格來說不能算作專業文獻,只能算是科普文。
豆包:
豆包在回答中,專業文獻只提供了一篇專利。
對於本題的結果來看,我倒是毫不意外。百度學術是國內最大的學術資源搜尋平臺,收錄的文獻夠多,再加上足夠強的 RAG 技術,對於落地這種專業問題來說再合適不過了。

北京春節廟會(時效性 + 事實性 + 全面性)

本題測試大模型對地域資訊的檢索能力,需要大模型能同時做到時效 + 事實 + 全面。
題目:今年北京過年哪裡有廟會活動啊,給到具體的地點和時間
以前這些活動資訊,我常常是在小紅書等內容平臺上去搜索的,每個帖子都能覆蓋一些資訊。但如果 AI 能替我彙總這些地域、活動資訊,這對於使用者日常生活中獲取資訊的效率,也將會是肉眼可見的提升。
文心:
百度給出了 12 個,全面性沒的說,著實能省去不少手動搜內容的時間。
Kimi:
Kimi 本題跟百度一樣給出 12 個。
豆包:
豆包雖然給出的地點數量比其他倆的少,但答案具備一定的互補性。

明朝皇帝史(全面性 + 事實性)

最後,來一道表面難度不大,但極度考察大模型 RAG 在資訊全面性方面的題目——
題目:我想了解下明朝的歷史,明朝歷代皇帝都有什麼貢獻和標誌性事件
對於這道題而言,參考資料較為充足,相對而言,更容易拋開語料因素,去看大模型 RAG 技術層面的能力。
文心:
文心回答完整度很高了,更有意思的是,竟然在回答中內嵌了影片卡片。
Kimi:
Kimi 的回答也非常全面,文字層面可以跟百度打平,但沒有補充影片。
豆包:
豆包在本題發動了生態能力,文末掛載了一系列相關影片。美中不足的是回答文字中缺失了時間資訊。
篇幅原因,本文的 case 體感測試環節就到這裡了。還是老話,雖然受限篇幅壓力,case 數量不具備統計顯著性,但可以從微觀視角上一窺大模型的能力特色。
從我個人的體感上來說,文心、Kimi 和豆包的聯網檢索能力確實都很強,各有各自的能力優勢和生態優勢。
但從技術視角出發,拆解上述 case 後發現,文心在硬依賴 RAG 技術能力的問題上,經常跑出非常驚豔的回答。能從 case 形態上感知到百度文心的 RAG 技術優勢。
因為去年年初的時候,我們編輯部嘗試過用大模型檢索時效資訊,來輔助 AI 資訊文章創作,但玩遍國內外產品,發現無論時效性、事實性還是全面性上,全都存在很大的問題。而一年過去了,實測下來文心在 RAG 方面的表現確實有了跨越式的提升。

淺拆百度文心 RAG 技術

說起 RAG,首先要提的關鍵點就是——檢索質量的優劣在很大程度上影響了生成模型的最終生成結果的優劣。
因此,技術人在聊 RAG 的時候,經常會進一步聊起語義檢索、ANN、向量資料庫這些名詞,甚至常會認為語義檢索能力是保證大模型 RAG 效果的關鍵。而 2023 年,也是向量資料庫大火的一年。
但很多人不知道的是,語義檢索,卻是一個早在四、五年前,就在百度搜索大範圍落地的技術。
語義檢索的代表性論文,可以參考 2020 年陳丹琦發表的 "Dense Passage Retrieval for Open-Domain Question Answering"。
而這篇論文,還只是模型效果層面的建模方法論。實際搭建過語義檢索/ANN 系統的小夥伴,一定深知,語義檢索更大的難點是在於工程能力上。
如果我們追根溯源,把檢索增強用到大模型上,也是百度 2023 年 3 月釋出文心一言的時候就已經提出來。現在將近兩年時間過去了,檢索增強的價值,從百度最早推出到現在已經成為業界共識。百度檢索增強技術深度融合大模型能力和搜尋系統,構建了“理解-檢索-生成”的協同最佳化技術。
簡單來看,理解階段,基於大模型理解使用者需求,對知識點進行拆解;檢索階段,面向大模型進行搜尋排序最佳化,並將搜尋返回的異構資訊統一表示,送給大模型;生成階段,綜合不同來源的資訊做出判斷,並基於大模型邏輯推理能力,解決資訊衝突等問題,從而生成準確率高、時效性好的答案。
另外講個冷知識:百度已收錄千億級別的網際網路內容,核心內容都達到了十億級別。
如何用極低的成本、極低的延遲去支援數以億計甚至十億級別的向量檢索,將延遲控制在毫秒級別,並支援高併發,這個難度要比模型效果提升 1 個點大得多。
而在語義檢索系統的召回結果之上,還要構建更為複雜的排序系統,兼顧相關性、時效性和權威性,這裡面的每一壺,都夠一個創業公司喝一年的。比如搜尋 query 遇到“楊冪最新新聞”時,時鮮的網頁內容就要大幅度被提權,否則就會出現下游的大模型“找不到有效參考文獻”的窘境。
而這還不夠,為了更加契合大模型 RAG 的低 First Token 延遲、低成本、結構化等特徵,百度還迭代了一套稱為“AIAPI”的「AI 原生檢索系統」。
在這個架構裡,中間的 R 流量庫通道,就是給文心大模型提供檢索資訊的通道,而兩側的 P 流量庫通道,則是給傳統的百度搜索業務用的。
做過網際網路規模 RAG 系統的小夥伴都知道,獲取高質量的搜尋結果(URL)雖然難,但毫秒級的獲取問題關聯的網頁內容片段/摘要資訊更難
對這項技術感興趣的小夥伴,可以看這篇文章《AIAPI – 轉向 AI 原生檢索》。
與此同時,2024 年,百度又將最下游的文心大模型,與上游檢索系統做了深度整合和鏈路級最佳化,這不僅讓文心大模型整合了豐富的知識庫與時鮮資料,而且使得其在垂直、長冷領域的表現因此大幅提升,甚至還具備了多模態檢索能力。這些,無一例外都成為了百度在大模型賽道競爭的壁壘。
2024,全世界都在追 AI 熱點,但百度卻默默聯合最佳化大模型 + 搜尋,靜下心來把大模型的 RAG 能力卷出了新高度。這讓我覺得有必要重新審視百度的大模型打法了。
剩下的,則交給時間。

相關文章