百萬級別的長上下文一直是 Gemini 系列相較于其他頭部大模型的領(lǐng)先優(yōu)勢之一。

尤其是最近正式推出的 Gemini 2.5 Pro 模型，在 AI Coding 的實(shí)踐中，能夠直接對整個項(xiàng)目進(jìn)行遍歷和讀取，與其他模型相比，帶來的是完全不同的體驗(yàn)。

更長的上下文，帶來的是可能產(chǎn)品交互的革新和完全不一樣的應(yīng)用落地場景。

長上下文當(dāng)前的痛點(diǎn)，以及未來發(fā)展方向是什么？

谷歌 DeepMind 長上下文預(yù)訓(xùn)練聯(lián)合負(fù)責(zé)人Nikolay Savinov 給出了兩點(diǎn)預(yù)測：一是在當(dāng)前百萬級 token Context 模型質(zhì)量還沒有達(dá)到完美之前，盲目地追求更大規(guī)模地長上下文意義不大；二是隨著成本下降，千萬級別的 token Context 很快會成為標(biāo)準(zhǔn)配置，對于編碼等應(yīng)用場景來說將是革命性的突破。

在近期谷歌的一檔播客中，谷歌 DeepMind 資深研究科學(xué)家、長上下文預(yù)訓(xùn)練聯(lián)合負(fù)責(zé)人Nikolay Savinov 與主持人 Logan Kilpatrick 對談，分享了Gemini 2.5 長上下文技術(shù)的核心、與 RAG 之間的關(guān)系、當(dāng)前的研究瓶頸、以及未來的發(fā)展方向等。

對于開發(fā)者來說，強(qiáng)烈推薦一讀。

TLDR:

• 在當(dāng)前百萬 token 上下文遠(yuǎn)還沒有達(dá)到完美之前，盲目追求更大規(guī)模的長上下文意義不大。

• 理解 in-weights memory 和 in-context memory 這兩者之間的區(qū)別非常重要，in-context memory 更容易修改和更新。當(dāng)前的瓶頸在于，對于短上下文模型來說，提供的額外上下文有限，不同的信息源之間為獲得模型「注意力」會存在競爭；

• 長上下文不會取代 RAG，兩者之間是協(xié)同關(guān)系，RAG 負(fù)責(zé)從海量信息中粗篩，長上下文負(fù)責(zé)精細(xì)處理。真正的限制因素在于應(yīng)用程序的延遲要求，當(dāng)需要實(shí)時交互時，必須使用較短的上下文；當(dāng)?shù)却龝r間更長時，使用長上下文更好，因?yàn)槟軒砀叩恼倩芈省?/p>

• 從理論上講，具備強(qiáng)大長上下文能力的模型，也應(yīng)該在推理方面表現(xiàn)出色。

• 有的開發(fā)者會問：我們應(yīng)該把問題放在上下文的前面還是后面？答案是：應(yīng)該放在后面。因?yàn)槿绻阆肜镁彺鎭砉?jié)省成本，這才是正確的位置。如果你把問題放在開頭，那么每次請求都會導(dǎo)致緩存失效，需要從頭開始處理。

• 不要將長上下文當(dāng)成「數(shù)據(jù)垃圾桶」，不相關(guān)的信息會降低模型表現(xiàn)。不相關(guān)或強(qiáng)干擾信息會與目標(biāo)信息競爭模型的「注意力」，尤其在多關(guān)鍵信息檢索任務(wù)中，反而會降低性能。現(xiàn)階段，精選上下文依然重要。

• 未來，千萬級別的 token 上下文很快會成為標(biāo)準(zhǔn)配置，對于編碼等應(yīng)用場景將是革命性的突破。

超 8000 人的「AI 產(chǎn)品市集」社群！不錯過每一款有價值的 AI 應(yīng)用。

邀請從業(yè)者、開發(fā)人員和創(chuàng)業(yè)者，飛書掃碼加群：

進(jìn)群后，你有機(jī)會得到：

• 最新、最值得關(guān)注的 AI 新品資訊；
  

• 不定期贈送熱門新品的邀請碼、會員碼；
  

• 最精準(zhǔn)的AI產(chǎn)品曝光渠道

01上下文的核心是提供模型不知道的信息

主持人：如何理解上下文窗口？作為使用大語言模型產(chǎn)品的用戶，或者是使用AI模型進(jìn)行開發(fā)的人，為什么需要關(guān)注上下文窗口？

Nikolay：上下文窗口基本上就是我們輸入到大型語言模型中的那些上下文 token。它可以是當(dāng)前的提示（prompt），也可以是之前與用戶的交互內(nèi)容，還可以是用戶上傳的文件，比如視頻或 PDF 文件。

當(dāng)你向模型提供上下文時，模型實(shí)際上有兩個知識來源。一個來源是「權(quán)重內(nèi)記憶（in-weights memory）」或「預(yù)訓(xùn)練記憶」。這是大型語言模型在對一部分互聯(lián)網(wǎng)內(nèi)容進(jìn)行訓(xùn)練時學(xué)到的知識，它不需要額外的上下文知識就能記住一些事實(shí)。所以即使沒有上下文，模型中也已經(jīng)存在某種記憶。

但另一種記憶是你提供給模型的這種顯式的上下文內(nèi)記憶（in-context memory）。理解這兩者之間的區(qū)別非常重要，因?yàn)?strong>上下文內(nèi)記憶比權(quán)重內(nèi)記憶更容易修改和更新。

所以對于某些類型的知識來說，權(quán)重內(nèi)記憶可能就足夠了。比如，如果你需要記住一些簡單的事實(shí)，像物體是往下掉而不是往上飛，這是一種非常基本的常識。如果這個知識來自預(yù)訓(xùn)練，那也沒問題。但有些事實(shí)在預(yù)訓(xùn)練時是正確的，但在推理時就過時了。你需要以某種方式更新這些事實(shí)。而上下文為你提供了一種實(shí)現(xiàn)這種更新的機(jī)制。這不僅僅是關(guān)于最新的知識，還有不同類型的知識，比如私人信息。比如，網(wǎng)絡(luò)對你個人一無所知，它也無法讀懂你的心思。

所以如果你希望模型對你真正有幫助，你應(yīng)該能夠?qū)⒛愕乃饺诵畔⑤斎氲缴舷挛闹校缓竽Ｐ途湍軐?shí)現(xiàn)個性化。如果沒有這種個性化，模型就會給你一個它會給任何人類的通用答案，而不是為你量身定制的答案。

最后一類需要插入到上下文中的知識是一些罕見的事實(shí)。所以基本上就是在互聯(lián)網(wǎng)上很少出現(xiàn)的一些知識。我懷疑這類知識隨著時間的推移可能會消失。也許未來的模型能夠把整個互聯(lián)網(wǎng)的內(nèi)容都牢記于心，那樣我們就不需要擔(dān)心這些了。

但目前的現(xiàn)實(shí)是，如果某件事情在整個互聯(lián)網(wǎng)上只被提到一兩次，模型實(shí)際上不太可能記住這些事實(shí)，并且它們會編造答案（產(chǎn)生幻覺）。所以你可能需要把這些信息顯式地插入到上下文中。我們面臨的一種權(quán)衡是，對于短上下文模型來說，你提供額外上下文的能力有限。基本上，知識來源之間會存在競爭。如果上下文非常大，那么你在插入內(nèi)容時就可以不那么挑剔，并且可以更高程度地召回和覆蓋相關(guān)知識。

如果你在上下文中有更高的覆蓋率，這意味著你將緩解權(quán)重內(nèi)記憶帶來的所有這些問題。

02RAG 暫時不會被淘汰

主持人：我們提到了「權(quán)重內(nèi)」記憶和上下文內(nèi)記憶，還有第三種引入上下文的方式是 RAG（檢索增強(qiáng)生成）系統(tǒng)。請你介紹下 RAG。

Nikolay：RAG 是一種工程技術(shù)，它在信息被送入 LLM 上下文之前增加了一個預(yù)處理步驟。想象一下，你有一個龐大的知識庫，首先將其分割成許多小的文本塊。然后，使用一個特殊的嵌入模型，將每個文本塊轉(zhuǎn)換成一個實(shí)值向量。當(dāng)用戶提出查詢時，這個查詢也會被嵌入為向量。接著，系統(tǒng)會將查詢向量與知識庫中所有文本塊的向量進(jìn)行比較，找出最接近的文本塊，并認(rèn)為這些是相關(guān)內(nèi)容。最后，LLM 會基于這個包含了相關(guān)信息的上下文來生成回答。這就是 RAG 的基本工作原理。

主持人：現(xiàn)在有的的模型上下文已經(jīng)能達(dá)到百萬甚至兩百萬 token，這雖然很長，但與維基百科等動輒數(shù)十億 token 的信息庫相比仍顯不足。RAG 正是用于在這種海量信息中檢索相關(guān)上下文的。

為什么不直接將這種檢索能力內(nèi)置于模型中，讓模型能夠直接處理數(shù)十億 token 的上下文，自行找到所需信息呢？這不是一個更便捷的方案嗎？是這個研究方向本身存在問題，還是說這本就不該是模型的工作？

Nikolay：在我們發(fā)布 1.5 Pro 后，社交媒體上涌現(xiàn)了許多關(guān)于 RAG 是否會過時的討論。我的看法是，RAG 不會過時。以企業(yè)知識庫為例，信息量往往能達(dá)到數(shù)十億 token，遠(yuǎn)超百萬級別。對于這種規(guī)模的應(yīng)用，RAG 依然是必需的。因此，我認(rèn)為在實(shí)際應(yīng)用中，RAG 不會迅速被淘汰，而是會與長上下文來協(xié)同工作。長上下文對 RAG 的好處在于，它允許 RAG 檢索并容納更多可能相關(guān)的文本片段，從而提高有用信息的召回率。如果過去為了確保相關(guān)性，設(shè)定了非常嚴(yán)格的篩選閾值，排除了許多潛在有用的信息，現(xiàn)在有了長上下文，就可以放寬標(biāo)準(zhǔn)，納入更多事實(shí)。我認(rèn)為這兩者之間存在著非常好的協(xié)同效應(yīng)。真正的限制因素在于應(yīng)用程序的延遲要求。如果需要實(shí)時交互，就必須使用較短的上下文；但如果可以接受稍長的等待時間，那么長上下文無疑是更好的選擇，因?yàn)樗軒砀叩恼倩芈省?/p>

在我剛開始從事長上下文研究時，競爭對手的水平大約在 12.8 萬（128k）或 20 萬 token。當(dāng)時，這個項(xiàng)目只是谷歌 Gemini 大項(xiàng)目中的一小部分。我最初的想法是，僅追平競爭對手的水平遠(yuǎn)遠(yuǎn)不夠，不如設(shè)定一個宏偉的目標(biāo)。100 萬 token，聽起來是一個足夠有挑戰(zhàn)性的進(jìn)步。相較于 20 萬 token，這幾乎是 5 倍的提升。在我們發(fā)布了百萬級 token 模型后，又推出了兩百萬 token 的版本，再次擴(kuò)大了規(guī)模，這比當(dāng)時最先進(jìn)的水平高出了一個數(shù)量級。這是一個很好的目標(biāo)，也激發(fā)了團(tuán)隊(duì)的研發(fā)熱情。

03長上下文對推理模型和 Agent 很重要

主持人：為什么更強(qiáng)的推理能力能讓長上下文發(fā)揮更大的作用，這是自然而然的結(jié)果嗎？是因?yàn)槟Ｐ汀杆伎肌沟酶茫€是兩者之間存在更深層次的聯(lián)系？

Nikolay：我認(rèn)為推理和長上下文之間存在著更深層次的聯(lián)系。當(dāng)增加上下文長度能改善下一個 token 的預(yù)測任務(wù)時，我們可以從兩個角度理解。第一，向輸入端加載更多上下文，可以提升對簡短答案的預(yù)測準(zhǔn)確性。第二，由于輸出的 token 與輸入的 token 在形式上是相似的，如果我們允許模型將自己的輸出再反饋回輸入端，那么輸出在某種意義上就轉(zhuǎn)化為了新的輸入。從理論上講，具備強(qiáng)大長上下文能力的模型，也應(yīng)該在推理方面表現(xiàn)出色。

此外，長上下文對推理至關(guān)重要。以決策任務(wù)為例，即便答案在二選一的情況下只需要生成一個 token，先生成完整的推理過程往往能得到更好的結(jié)果。因?yàn)閺哪Ｐ图軜?gòu)角度，在進(jìn)行下一個 token 預(yù)測時，如果需要在上下文中進(jìn)行多次邏輯推導(dǎo)，會受到「網(wǎng)絡(luò)深度」的限制。「網(wǎng)絡(luò)深度」類似于注意力層的數(shù)量，限制了模型在一次前向傳播中邏輯跳躍的次數(shù)。但如果能將輸出反饋回輸入，模型就突破了這一限制，相當(dāng)于擁有了可供寫入的「記憶」，從而能夠處理比單純依賴網(wǎng)絡(luò)深度時更復(fù)雜的任務(wù)。

主持人：你怎么看 Agent 應(yīng)用場景和長上下文的關(guān)系？長上下文是實(shí)現(xiàn)優(yōu)質(zhì) Agent 體驗(yàn)的關(guān)鍵因素嗎？二者相互作用是怎樣的？

Nikolay：這確實(shí)是個有趣的問題。我覺得Agent 既能作為長上下文的使用者，也能充當(dāng)長上下文的提供者。Agent 要想高效運(yùn)行，就得追蹤上一個狀態(tài)，比如之前采取過的行動、進(jìn)行過的觀察等，當(dāng)然還有當(dāng)前的狀態(tài)。因此，為了記住之前所有這些交互信息，就需要更長的上下文，這就是長上下文對 Agent 的助力，也就是 Agent 作為長上下文使用者的情形。

不過，還有另一個視角。實(shí)際上，Agent 也是長上下文的提供者。因?yàn)槭謩诱黹L上下文非常麻煩。舉個例子，要是每次都得手動上傳想要的所有文檔，或者上傳一個視頻，又或者從網(wǎng)上復(fù)制粘貼一些內(nèi)容，這實(shí)在太繁瑣，沒人愿意這么做，大家都希望模型能自動完成這些操作。而實(shí)現(xiàn)這一點(diǎn)的一種方式就是通過 Agent 的工具調(diào)用。所以，如果模型能在某個時刻做出判斷：「嘿，現(xiàn)在我要獲取更多信息了」，然后它就能自行整理上下文。從這個層面來講，Agent 就是長上下文的提供者。

主持人：是的，這是個非常好的例子。我認(rèn)為這實(shí)際上是人們與 AI 系統(tǒng)交互時的主要限制之一，就像你舉的例子那樣，真的很繁瑣。做任何與 AI 相關(guān)的事情最糟糕的部分就是我必須去找到所有可能與模型相關(guān)的上下文，然后親自把這些上下文輸入進(jìn)去。在很多情況下，這些上下文可能已經(jīng)在我的屏幕上或者我的電腦里了，我知道上下文在哪里，但我卻不得不做所有這些繁重的工作。所以我很期待我們應(yīng)該構(gòu)建一些長上下文 Agent 系統(tǒng)，它可以自動從各個地方獲取你的上下文。我覺得那會非常有趣，而且我認(rèn)為這解決了一個非常基本的問題，不僅對開發(fā)者來說是這樣，從 AI 系統(tǒng)終端用戶的角度來看也是如此。我希望模型能夠自己去獲取我的上下文，而不是我必須親自去做。

Nikolay：是的，確實(shí)是這樣。

04怎么用好上下文：多用上下文緩存

主持人：我們發(fā)現(xiàn)開發(fā)者對長輸出的需求非常強(qiáng)烈，而不僅僅是長輸入。所以我想問，長上下文的輸入能力和輸出能力有多大關(guān)聯(lián)？從研究角度看，這兩種能力是同一回事，最終會趨于一致，還是說它們在本質(zhì)上是截然不同的？

Nikolay：我認(rèn)為長上下文的輸入和輸出能力在本質(zhì)上沒有不同。重要的是要理解，僅從預(yù)訓(xùn)練的角度看，模型在生成大量 token 方面其實(shí)沒有真正的限制。例如，你輸入 50 萬 token，讓模型執(zhí)行復(fù)制任務(wù)，它是能夠做到的，我們也通過實(shí)驗(yàn)驗(yàn)證了這一點(diǎn)。然而，這種能力在預(yù)訓(xùn)練之后需要被謹(jǐn)慎地引導(dǎo)。這是因?yàn)槟Ｐ驮诤罄m(xù)階段會接觸到一個特殊的序列結(jié)束 token（end-of-sequence token）。如果在監(jiān)督微調(diào)（SFT）階段使用的數(shù)據(jù)都很短，模型就會頻繁地在序列早期看到這個結(jié)束 token。久而久之，模型就會學(xué)到：「在 X 長度的上下文中，你總是向我展示這個 token，所以我會生成它并停止輸出，這是你教給我的規(guī)則。」這其實(shí)是一個模型對齊（alignment）的問題。但我想強(qiáng)調(diào)的是，推理只是長輸出任務(wù)的一種。例如，翻譯也是一種長輸出任務(wù)。推理有其獨(dú)特的格式，它會將思考過程用特定的分隔符包裹起來，模型能識別出這是在讓它進(jìn)行鏈?zhǔn)剿伎肌６鴮τ诜g任務(wù)，整個輸出內(nèi)容都會很長。這也是我們期望模型能夠具備并展現(xiàn)的能力。所以，這歸根結(jié)底是一個如何正確校準(zhǔn)模型的問題。我們目前也正在積極進(jìn)行模型長輸出方面的研究。

主持人：開發(fā)者如何更好地利用長上下文及 RAG？你對他們?nèi)绾斡行У乩瞄L上下文有什么建議？

Nikolay：我的第一個建議是，盡量多地利用上下文緩存（context caching）。讓我解釋一下這個概念，當(dāng)你首次向模型提供長上下文并提問時，處理時間會更長，成本也更高。然而，如果你在同一個上下文的基礎(chǔ)上提出第二個問題，就可以利用上下文緩存，使后續(xù)的問答更經(jīng)濟(jì)、更快捷。這是我們目前為部分模型提供的功能。所以，盡量利用它，嘗試緩存用戶上傳的文件，因?yàn)檫@不僅能加快處理速度，還能將平均輸入成本降低到原來的約四分之一。

主持人：我來舉個例子。在「與我的文檔聊天」或「與 PDF 聊天」這類常見應(yīng)用中，原始輸入上下文是固定的，這是上下文緩存發(fā)揮作用的場景。使用上下文緩存的前提是，每次請求提供的原始上下文必須保持一致。如果輸入上下文每次都在變化，緩存效果就會大打折扣。

Nikolay：是的，你說的完全正確。對于與一組固定文檔聊天、針對某個長視頻提問或?qū)σ粋€代碼庫進(jìn)行操作等場景，上下文緩存都非常重要。你提到知識不應(yīng)改變這一點(diǎn)也是對的。如果知識確實(shí)需要更新，最好是在上下文的末尾進(jìn)行追加，因?yàn)榈讓訉?shí)現(xiàn)會匹配緩存中的最長公共前綴，然后只處理新增的部分。有的開發(fā)者會問：我們應(yīng)該把問題放在上下文的前面還是后面？答案是：應(yīng)該放在后面。因?yàn)槿绻阆肜镁彺鎭砉?jié)省成本，這才是正確的位置。如果你把問題放在開頭，那么每次請求都會導(dǎo)致緩存失效，需要從頭開始處理。

主持人：這個建議非常實(shí)用。除了上下文緩存，從開發(fā)者角度看，還有其他需要注意的地方嗎？

Nikolay：有一點(diǎn)我們之前提到過，與 RAG 的結(jié)合。如果你需要處理數(shù)十億 token 的上下文，那么結(jié)合 RAG 是必然選擇。即使上下文規(guī)模小得多，在一些需要檢索多個關(guān)鍵信息的場景中，結(jié)合 RAG 可能仍然是有效的。另一點(diǎn)是，避免在上下文中包含不相關(guān)的內(nèi)容，因?yàn)樗鼤绊懚嚓P(guān)鍵信息的檢索效果。還有一個有趣的細(xì)節(jié)，是「權(quán)重內(nèi)」記憶和上下文內(nèi)記憶的相互作用。如果你想利用上下文內(nèi)記憶來更新「權(quán)重內(nèi)」的知識，那么模型必然會同時依賴這兩種知識來源，它們之間可能會產(chǎn)生矛盾。我認(rèn)為，通過精心設(shè)計提示詞來明確解決這種矛盾是很有幫助的。例如，你可以在提問時加上「基于以上提供的信息……」這樣的前綴。當(dāng)你這樣說時，你就給了模型一個明確的信號，讓它優(yōu)先依賴上下文內(nèi)記憶，而非「權(quán)重內(nèi)」記憶，從而為模型消除了這種模糊性。

主持人：如何看待在特定知識庫上進(jìn)行長上下文微調(diào)，這種方法能否帶來更好的通用結(jié)果？

Nikolay：我先來詳細(xì)解釋一下在知識庫上進(jìn)行微調(diào)是如何操作的。有時人們會獲取額外的知識，比如一個龐大的企業(yè)知識庫，像我們進(jìn)行預(yù)訓(xùn)練一樣，會在這個語料庫上訓(xùn)練網(wǎng)絡(luò)，通過語言建模損失函數(shù)讓模型學(xué)習(xí)預(yù)測下一個 token。這種整合信息的方式雖然有效，但也存在局限。首先，因?yàn)槭窃谟?xùn)練一個網(wǎng)絡(luò)，而不是簡單地提供上下文，所以需要處理各種問題，比如調(diào)整超參數(shù)、確定停止訓(xùn)練的時機(jī)、以及應(yīng)對模型過擬合等情況。盡管這種微調(diào)技術(shù)在推理時速度快、成本低，因?yàn)樗鼘⒅R直接編碼進(jìn)了模型權(quán)重，但其弊端也十分突出。有研究指出，這種「硬編碼」式的知識注入方式，不僅可能加劇模型的幻覺問題，還帶來了兩個后續(xù)的難題：一是隱私風(fēng)險，敏感信息一旦嵌入權(quán)重便難以剝離；二是更新困境，固化的知識難以修改，一旦過時，最終還是需要通過上下文來提供新信息，這便形成了一個悖論。

05大海撈針做評測已經(jīng)過時了

主持人：模型質(zhì)量會隨著上下文規(guī)模而變化嗎？例如，token 數(shù)從 5 萬增加到 10 萬，再到 12.8 萬，模型質(zhì)量的提升是線性的，還是在不同規(guī)模下基本保持一致？是否會存在異常情況，比如在特定規(guī)模下性能下降？

Nikolay：我們內(nèi)部確實(shí)做過這類評估。你的問題可能與過去觀察到的一些現(xiàn)象有關(guān)，比如一個非常常見的「中間信息丟失效應(yīng)」（lost in the middle effect）。就我們的模型而言，我們沒有明顯觀察到這種上下文中間部分信息丟失的情況。但我們確實(shí)發(fā)現(xiàn)，在處理包含強(qiáng)干擾因素的復(fù)雜任務(wù)時，隨著上下文規(guī)模的增加，模型質(zhì)量會出現(xiàn)輕微下降。這也是我們希望改進(jìn)的方向。

主持人：當(dāng)我向模型的上下文窗口輸入 10 萬 token 的信息時，作為開發(fā)者或用戶，我是否可以假設(shè)模型會關(guān)注所有上下文內(nèi)容？我知道模型能準(zhǔn)確提取單個關(guān)鍵信息，但會對所有 token 進(jìn)行推理嗎？

Nikolay：這是一個很好的問題。注意力機(jī)制存在一個固有的特點(diǎn)，即 token 之間存在競爭關(guān)系。如果一個 token 獲得了更多的注意力，那么其他 token 獲得的注意力就會相應(yīng)減少。問題在于，如果上下文中存在強(qiáng)干擾因素，比如某個干擾項(xiàng)與您要查找的目標(biāo)信息非常相似，它就可能吸引大量的注意力，從而導(dǎo)致目標(biāo)信息獲得的注意力減少。上下文中的 token 越多，這種競爭就越激烈。所以，模型的表現(xiàn)取決于干擾因素的難度和上下文的規(guī)模。

主持人：注意力機(jī)制的總量是固定的嗎，能否增加？還是一個固定值（比如 1），被分散到所有 token 上，導(dǎo)致 token 越多，每個 token 分得的注意力就越少，且無法改變？

Nikolay：通常情況下是這樣的，注意力的總量是有限的。

主持人：「大海撈針」測試是長上下文的質(zhì)量評估中我們熟知的一種方法，它驗(yàn)證了模型在海量信息中定位具體事實(shí)的能力。除此之外，還有沒有其他標(biāo)準(zhǔn)的評估方法或基準(zhǔn)測試？

Nikolay：我認(rèn)為評估是 LLM 研究的基石。尤其在大型團(tuán)隊(duì)中，高質(zhì)量的評估能讓整個團(tuán)隊(duì)目標(biāo)一致、協(xié)同發(fā)力，這在長上下文研究中同樣重要。首先，像「大海撈針」這類從大量文本中檢索單個關(guān)鍵信息的任務(wù)，如果只是基于 Paul Graham（YC 創(chuàng)始人） 的某一篇文章提問「巴塞羅那的神奇數(shù)字是多少？」，現(xiàn)在的模型已經(jīng)能很好地解決。當(dāng)前研究的前沿在于處理包含強(qiáng)干擾因素的場景。例如，用成千上萬個「某個城市的神奇數(shù)字是 y」這樣的鍵值對填滿上下文，任務(wù)難度會急劇增加，因?yàn)楦蓴_信息與目標(biāo)信息高度相似。此外，同時檢索多個關(guān)鍵信息對大語言模型來說也是一個挑戰(zhàn)。因此，處理強(qiáng)干擾和多關(guān)鍵信息檢索是目前的研究重點(diǎn)。

其次，評估時還有其他需要權(quán)衡的因素。即便是加入了強(qiáng)干擾因素，「大海撈針」式評估在某種程度上仍是人為設(shè)計的。有人希望評估能更貼近現(xiàn)實(shí)應(yīng)用，這個想法是正確的。但需要注意的是，一旦評估過于「現(xiàn)實(shí)」，它可能就無法有效衡量模型真正的長上下文處理能力。例如，在一個超大型代碼庫中提問，答案可能只存在于某個文件中，但任務(wù)本身卻要求模型完成一系列復(fù)雜操作。這種情況下，測試的更多是模型的編碼能力而非長上下文能力，這會誤導(dǎo)研究方向，讓我們最終優(yōu)化了錯誤的重點(diǎn)。

最后，還有一個值得關(guān)注的方向是「檢索與合成評估」。理論上，檢索單個關(guān)鍵信息的「大海撈針」任務(wù)，用 RAG 就能解決。但我們真正應(yīng)該關(guān)注的是那些需要模型整合整個上下文信息才能完成的任務(wù)，比如文本總結(jié)，RAG 在處理這類任務(wù)時就顯得力不從心。但這類任務(wù)的方向雖然正確，但自動化評估充滿挑戰(zhàn)。因?yàn)橄?ROUGE（大模型評估指標(biāo)） 這類指標(biāo)難以完全捕捉人類對質(zhì)量的主觀判斷。所以，在優(yōu)化模型時，更明智的做法是依據(jù)那些評判標(biāo)準(zhǔn)明確、反饋信號清晰的指標(biāo)。

主持人：為什么文本總結(jié)任務(wù)的指標(biāo)效果不佳？是因?yàn)閷Α负谩古c「壞」的總結(jié)更具主觀性，缺乏標(biāo)準(zhǔn)答案，還是有其他原因?qū)е逻@類應(yīng)用場景難以評估？

Nikolay：是的，這類評估存在很大的不確定性，即便是人類評估員之間的一致性也相對較低。當(dāng)然，這并不是說我們不應(yīng)該研究或衡量總結(jié)任務(wù)，它們本身非常重要。我只是想表達(dá)，作為一名研究員，我個人更傾向于在有明確信號反饋的方向上進(jìn)行優(yōu)化。

06千萬級別上下文的瓶頸是成本

主持人：如果繼續(xù)將上下文擴(kuò)展到百萬甚至兩百萬 token 以上，存在哪些限制？是服務(wù)成本過高，還是支撐當(dāng)前規(guī)模的模型架構(gòu)在更大 token 規(guī)模下會失效？長上下文技術(shù)的前沿為什么遲遲還沒有新的突破？

Nikolay：實(shí)際上，在發(fā)布 Gemini 1.5 Pro 時，我們曾在千萬級別的 token 規(guī)模上進(jìn)行過一些推理測試，并獲得了不錯的質(zhì)量數(shù)據(jù)。對于在千萬 token 上下文中檢索單個關(guān)鍵信息這類任務(wù)，模型表現(xiàn)近乎完美。我們本來是可以發(fā)布這個模型的，但運(yùn)行這種規(guī)模推理的成本非常高昂。我們當(dāng)時并不確定用戶是否愿意為此支付高昂的費(fèi)用，所以先從一個在價格上更合理的規(guī)模起步。但你提的問題很關(guān)鍵，因?yàn)檫\(yùn)行這類測試的成本非常高，所以我們沒能進(jìn)行大規(guī)模的驗(yàn)證。僅僅是啟動一次服務(wù)器的成本就相當(dāng)可觀，除非我們準(zhǔn)備好向大量客戶開放，否則我們沒有足夠的芯片資源來支持。

主持人：這種現(xiàn)狀會持續(xù)下去嗎？推進(jìn)長上下文研究時，模型能力的增長是否會遇到瓶頸？我們需要重大的研究突破才能進(jìn)一步擴(kuò)大上下文規(guī)模，還是說百萬到兩百萬 token 已經(jīng)是上限，未來的擴(kuò)展只能依賴 RAG 這類在模型外部優(yōu)化上下文管理的方案？

Nikolay：我們確實(shí)需要更多的創(chuàng)新。要實(shí)現(xiàn)近乎完美的千萬級 token 上下文，單純擴(kuò)大規(guī)模是不夠的，還需要技術(shù)上的新突破。至于 RAG 和長上下文哪種范式未來會更占主導(dǎo)，我認(rèn)為隨著時間推移，模型成本會下降，我們會嘗試將更多通過 RAG 檢索到的信息整合到模型上下文中。并且，由于模型質(zhì)量也在提升，這樣做的收益會越來越大。

主持人：你此前提到強(qiáng)干擾信息會分散模型注意力。從這個角度看，團(tuán)隊(duì)是否研究過預(yù)過濾機(jī)制？理想情況下，長上下文窗口內(nèi)的數(shù)據(jù)差異越大越好。如果數(shù)據(jù)高度相似，且問題與這些數(shù)據(jù)都相關(guān)，性能反而可能下降。這個問題是否只能由開發(fā)者在應(yīng)用層面解決？

Nikolay：作為一名研究員，我認(rèn)為依賴過濾技巧可能并不是一個正確的方向。我們應(yīng)該將更多精力投入到提升模型的質(zhì)量和穩(wěn)健性上。不過，從實(shí)踐角度出發(fā)，一個可行的建議是：盡量避免在上下文中包含完全不相關(guān)的內(nèi)容。如果明知道某些信息毫無用處，就沒必要放進(jìn)來，至少會增加成本。

主持人：這很有趣，某種程度上，這與人們使用長上下文的初衷相悖。網(wǎng)絡(luò)上常見的用法是，將各種數(shù)據(jù)一股腦地丟給模型，期望它能自行篩選出有用信息。考慮到剔除無關(guān)內(nèi)容的重要性，人們似乎期待模型能自帶預(yù)過濾功能。畢竟，長上下文的一大賣點(diǎn)就是讓用戶無需費(fèi)心篩選輸入數(shù)據(jù)。那么，模型是否有可能發(fā)展成一個多模塊系統(tǒng)，能根據(jù)用戶查詢自動過濾無關(guān)數(shù)據(jù)，從而簡化后續(xù)處理？

Nikolay：隨著時間的推移，當(dāng)模型質(zhì)量提升、成本降低后，就不需要為這個問題所考慮了。在現(xiàn)階段，如果希望充分利用長上下文，那么從現(xiàn)實(shí)角度出發(fā)，最好不要引入不相關(guān)的內(nèi)容。當(dāng)然我也同意你的觀點(diǎn)，如果花費(fèi)大量時間手動過濾或精心挑選上下文，會非常繁瑣。我認(rèn)為需要在這兩者之間找到一個平衡點(diǎn)。上下文的意義在于簡化用戶的工作流程，使其更加自動化，而不是增加手動操作的負(fù)擔(dān)。

07百萬級上下文質(zhì)量還不完美時，
更長上下文意義不大

主持人：長上下文的長期發(fā)展方向是什么？未來三年，用戶可以期待什么？

Nikolay：我來做一些預(yù)測。首先，當(dāng)前百萬或兩百萬 token 上下文的質(zhì)量將大幅提升，很快我們就能在幾乎所有檢索任務(wù)上達(dá)到近乎完美的效果。之所以說這是第一步，是因?yàn)?strong>在當(dāng)前百萬 token 上下文遠(yuǎn)還沒有達(dá)到完美之前，盲目追求更大規(guī)模的意義不大。我相信，一旦我們實(shí)現(xiàn)了近乎完美的百萬 token 上下文，將會開啟一些我們今天難以想象的應(yīng)用場景，模型處理和關(guān)聯(lián)信息的能力將得到質(zhì)的飛躍。實(shí)際上，模型已經(jīng)能夠同時處理遠(yuǎn)超人類極限的信息量。例如，讓人類在觀看一小時視頻后，精確回答某個細(xì)節(jié)問題（比如「視頻的第幾秒有人掉落了一張紙」），這是非常困難的。我認(rèn)為，這種超越人類的能力會變得更加普遍，而更強(qiáng)的長上下文能力將解鎖更多我們未曾預(yù)想過的應(yīng)用。這是第一步：提升質(zhì)量。

第二步，是長上下文的成本降低。這可能需要更長的時間，但一定會實(shí)現(xiàn)。隨著成本的下降，更長的上下文也將成為可能。我認(rèn)為，千萬級別的 token 上下文很快會成為標(biāo)準(zhǔn)配置，對于編碼等應(yīng)用場景將是革命性的突破。目前百萬級別的上下文僅能容納中小型代碼庫，而千萬 token 可以將大型項(xiàng)目完整地置于其中。到那時，我們將擁有能夠?qū)崿F(xiàn)對整個上下文近乎完美召回的創(chuàng)新技術(shù)。目前，人類程序員需要記住大量信息才能高效工作，并且不得不在不同文件間頻繁切換，注意力總是有限的。而 LLM 將徹底解決這些問題，它能一次性記住所有信息，精確重現(xiàn)任何部分，還能真正關(guān)聯(lián)不同文件之間的信息，成為極其高效的編碼助手。很快就會出現(xiàn)超越人類能力的編碼 AI 助手，將成為世界上每個程序員的新標(biāo)配。這是千萬 token 上下文實(shí)現(xiàn)時會發(fā)生的第二步。

至于達(dá)到一億 token 上下文，那將更具挑戰(zhàn)性。我認(rèn)為最終能夠?qū)崿F(xiàn)，但不確定速度有多快，而且可能需要更多深度學(xué)習(xí)領(lǐng)域的根本性創(chuàng)新才能達(dá)成這一目標(biāo)。

主持人：在推動長上下文發(fā)展的過程中，硬件的限制和算法的創(chuàng)新，哪個是當(dāng)前更大的瓶頸？我們作為研究者，是應(yīng)該等待硬件成熟，還是說算法本身就有更大的突破空間？

Nikolay：僅有芯片是不夠的，還需要非常有才華的推理工程師。我們的推理團(tuán)隊(duì)在處理百萬級 token 上下文方面取得了優(yōu)異的成就，沒有他們，我們根本無法向客戶提供這項(xiàng)服務(wù)。所以，這需要在推理工程方面持續(xù)投入，我不認(rèn)為這個問題會自行解決。

轉(zhuǎn)載原創(chuàng)文章請?zhí)砑游⑿牛篺ounderparker