機器之心報道

機器之心編輯部

谷歌回歸搜索老本行，這一次，它要讓 AI 能像人一樣「看見」網(wǎng)頁。

這是谷歌前不久在 Gemini API 全面上線的URL Context功能（5 月 28 日已在Google AI Studio 中推出），它使 Gemini 模型能夠訪問并處理來自 URL 的內(nèi)容，包括網(wǎng)頁、PDF 和圖像。

Google 產(chǎn)品負責人 Logan Kilpatrick 表示這是他最喜歡的 Gemini API 工具，并推薦大家把這個工具設(shè)置為默認開啟的「無腦選項」。

那么靈魂一問：這和我平時把鏈接扔給 AI 對話框里有什么本質(zhì)區(qū)別？感覺我一直在這么做。

區(qū)別在于處理深度和工作方式。你平時扔鏈接，AI 通常會通過一個通用的瀏覽工具或搜索引擎插件來「看」這個網(wǎng)頁，AI 很可能只讀取了網(wǎng)頁的摘要或部分文本。

而 URL Context 則完全不同。它是一個專為開發(fā)者設(shè)計的編程接口（API），當開發(fā)者在他的程序里調(diào)用這個功能時，他是明確地指令 Gemini「把這個 URL 里的全部內(nèi)容（上限高達 34MB）作為你回答下一個問題的唯一、權(quán)威的上下文」，Gemini 會進行深度、完整的文檔解析，理解整個文檔的結(jié)構(gòu)、內(nèi)容和數(shù)據(jù)。

以下是它的能力清單：

深度解析 PDF：能深刻理解 PDF 中的表格、文本結(jié)構(gòu)甚至腳注。多模態(tài)理解：能處理 PNG、JPEG 等圖片，并理解其中的圖表和圖示。支持多種網(wǎng)頁文件：HTML、JSON、CSV 等常見格式均不在話下。

官方 API 文檔提供詳細的配置教程，除此之外，還可以在 Google AI Studio 直接體驗。

Towards Data Science上的一篇文章詳細介紹了 URL Context Grounding，作者 Thomas Reid 犀利地將 URL Context Grounding 評價為「RAG的又一顆棺材釘」。

文章地址：https://towardsdatascience.com/googles-url-context-grounding-another-nail-in-rags-coffin/

RAG 是過去幾年中用于提升大語言模型回答準確性、時效性和可靠性的主流技術(shù)。由于大模型的知識截止于其訓練數(shù)據(jù)，RAG 通過一個外部知識庫來為其提供最新的、特定性的信息。

傳統(tǒng)的 RAG 流程相對復雜，通常包括以下步驟：

提取內(nèi)容：從數(shù)據(jù)源（如網(wǎng)站、文檔）中抓取文本。分塊：將長文本切分成更小、更易于處理的片段。矢量化：使用嵌入模型（Embedding Model）將文本塊轉(zhuǎn)換為數(shù)字向量，捕捉其語義信息。存儲：將這些向量存儲在專門的向量數(shù)據(jù)庫中。檢索：當用戶提問時，系統(tǒng)首先在向量數(shù)據(jù)庫中搜索與問題最相關(guān)的文本塊。增強與生成：將檢索到的相關(guān)文本塊作為上下文信息，與原始問題一同輸入給大語言模型，從而生成更準確、更具針對性的回答。

RAG 架構(gòu)。圖源：Mindful Matrix

Thomas Reid 指出，使用 URL Context Grounding「無需提取 URL 文本和內(nèi)容、分塊、矢量化、存儲等」。對于處理公開網(wǎng)絡(luò)內(nèi)容這個非常普遍的場景，它提供了一個極其簡單的替代方案。

開發(fā)者不再需要花費大量時間和精力去搭建和維護一個由多個組件（數(shù)據(jù)提取、向量數(shù)據(jù)庫等）組成的復雜管道，只需幾行代碼就能實現(xiàn)更精準的效果。

在 Thomas Reid 提供的示例中，Gemini 僅憑一個指向特斯拉 50 頁財報 PDF 的 URL，就準確無誤地提取出了位于第 4 頁表格中的「總資產(chǎn)」和「總負債」數(shù)據(jù)，這是僅靠摘要絕無可能完成的任務(wù)。

自特斯拉 SEC 10-Q 申報文件第 4 頁內(nèi)容。

以下是我們在 Google AI Studio 中的測試結(jié)果。

作者接著測試了 URL Context 挑選其他信息的能力。在 PDF 的末尾，有一封寫給即將離開公司的員工的信，概述了他們的遣散條款。

信中提到的退出日期用星號（***）標記，屏蔽退出日期的原因在腳注中給出。

URL Context 準確識別出了腳注中的內(nèi)容。

根據(jù)所提供的文件，員工離職協(xié)議中的離職日期被標記為「***」，原因在于某些公司視為隱私或機密的特定非關(guān)鍵信息，已在公開文件中被有意略去。
該文件包含一條對此做法的澄清說明：「本文檔中某些已識別的信息已被略去，因為這些信息并非關(guān)鍵信息，且屬于公司視為隱私或機密的信息類型，并已用「***」標記以示省略之處。

根據(jù)官網(wǎng)介紹，URL Context 采用一個兩步檢索流程，以平衡速度、成本和對最新數(shù)據(jù)的訪問。

當用戶提供一個 URL 時，該工具首先嘗試從內(nèi)部索引緩存中獲取內(nèi)容，以提高速度和成本效益。如果 URL 不在緩存中（比如一個剛剛發(fā)布的頁面），它會進行實時抓取。

那它的能力邊界在哪里呢？官方介紹中也有明確說明。

無法翻越「付費墻」：需要登錄或付費才能訪問的內(nèi)容，它無能為力。專用工具優(yōu)先：YouTube 視頻、Google Docs等有專門 API 處理的內(nèi)容，它不會涉足。有明確的容量限制：單次請求最多處理20 個 URL，且單個 URL 內(nèi)容上限為34MB。

價格方面，它的計費方式非常直觀：按處理的內(nèi)容 Token 數(shù)量計費。你提供的 URL 內(nèi)容越多，被轉(zhuǎn)換成輸入 Token 的數(shù)量就越多，成本也相應增加。這可能會間接引導開發(fā)者進行更高效的應用設(shè)計，即精確地提供所需的信息源，而非寬泛地投喂大量不相關(guān)的 URL，從而優(yōu)化成本。

不過話說回來，URL Context Grounding 的出現(xiàn)并非宣告 RAG 的終結(jié)，而是對其應用場景的重新劃分。對于處理企業(yè)內(nèi)網(wǎng)的海量私有文檔、需要復雜檢索邏輯和極致安全性的場景，構(gòu)建一套自主可控的 RAG 系統(tǒng)依然是不可或缺的。

URL Context 揭示了一個行業(yè)趨勢：基礎(chǔ)模型正在將越來越多的「外部能力」內(nèi)置化。過去需要由應用層開發(fā)者承擔的復雜數(shù)據(jù)處理工作，正在被逐步吸收到底層模型的服務(wù)中。