0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

我們能否擴(kuò)展現(xiàn)有的預(yù)訓(xùn)練 LLM 的上下文窗口

深度學(xué)習(xí)自然語言處理 ? 來源:深度學(xué)習(xí)自然語言處理 ? 2023-06-30 11:09 ? 次閱讀

在大家不斷升級迭代自家大模型的時(shí)候,LLM(大語言模型)對上下文窗口的處理能力,也成為一個(gè)重要評估指標(biāo)。 比如 OpenAI 的 gpt-3.5-turbo 提供 16k token 的上下文窗口選項(xiàng),AnthropicAI 的更是將 Claude 處理 token 能力提升到 100k。大模型處理上下文窗口是個(gè)什么概念,就拿 GPT-4 支持 32k token 來說,這相當(dāng)于 50 頁的文字,意味著在對話或生成文本時(shí),GPT-4 最多可以記住 50 頁左右內(nèi)容。 一般來講,大語言模型處理上下文窗口大小的能力是預(yù)定好的。例如,Meta AI 發(fā)布的 LLaMA 模型,其輸入 token 大小必須少于 2048。 然而,在進(jìn)行長對話、總結(jié)長文檔或執(zhí)行長期計(jì)劃等應(yīng)用程序中,經(jīng)常會(huì)超過預(yù)先設(shè)置的上下文窗口限制,因而,能夠處理更長上下文窗口的 LLM 更受歡迎。 但這又面臨一個(gè)新的問題,從頭開始訓(xùn)練具有較長上下文窗口的 LLM 需要很大的投入。這自然引出一個(gè)疑問:我們能否擴(kuò)展現(xiàn)有的預(yù)訓(xùn)練 LLM 的上下文窗口? 一種直接的方法是對現(xiàn)有的預(yù)訓(xùn)練 Transformer 進(jìn)行微調(diào),以獲得更長的上下文窗口。然而,實(shí)證結(jié)果表明,使用這種方式訓(xùn)練的模型對長上下文窗口的適應(yīng)速度非常慢。經(jīng)過 10000 個(gè)批次的訓(xùn)練后,有效上下文窗口的增加仍然非常小,僅從 2048 增加到 2560(實(shí)驗(yàn)部分的表 4 可以看出)。這表明這種方法在擴(kuò)展到更長的上下文窗口上效率低下。 本文中,來自 Meta 的研究者引入了位置插值(Position Interpolation,PI)來對某些現(xiàn)有的預(yù)訓(xùn)練 LLM(包括 LLaMA)的上下文窗口進(jìn)行擴(kuò)展。結(jié)果表明,LLaMA 上下文窗口從 2k 擴(kuò)展到 32k,只需要小于 1000 步的微調(diào)。 b8fa05e0-1692-11ee-962d-dac502259ad0.png ? 論文地址:https://arxiv.org/pdf/2306.15595.pdf ? 該研究的關(guān)鍵思想不是進(jìn)行外推(extrapolation),而是直接縮小位置索引,使得最大位置索引與預(yù)訓(xùn)練階段的上下文窗口限制相匹配。換句話說,為了容納更多的輸入 token,該研究在相鄰的整數(shù)位置上插值位置編碼,利用了位置編碼可以應(yīng)用于非整數(shù)位置的事實(shí),與在訓(xùn)練過的位置之外進(jìn)行外推相比,后者可能導(dǎo)致災(zāi)難性的數(shù)值。 ? b902b38e-1692-11ee-962d-dac502259ad0.png ? PI 方法將基于 RoPE(旋轉(zhuǎn)位置編碼)的預(yù)訓(xùn)練 LLM(如 LLaMA)的上下文窗口大小擴(kuò)展到最多 32768,只需進(jìn)行最小的微調(diào)(在 1000 個(gè)步驟內(nèi)),這一研究在需要長上下文的各種任務(wù)上性能較好,包括密碼檢索、語言建模以及從 LLaMA 7B 到 65B 的長文檔摘要。與此同時(shí),通過 PI 擴(kuò)展的模型在其原始上下文窗口內(nèi)相對保持了較好的質(zhì)量。 ? 方法 在我們比較熟悉的 LLaMA、ChatGLM-6B、PaLM 等大語言模型中,都有 RoPE 身影,該方法由追一科技蘇劍林等人提出,RoPE 通過絕對編碼的方式實(shí)現(xiàn)了相對位置編碼。 雖然 RoPE 中的注意力得分只取決于相對位置,但它的外推性能并不好。特別是,當(dāng)直接擴(kuò)展到更大的上下文窗口時(shí),困惑度可能會(huì)飆升到非常高的數(shù)字 (即 > 10^3)。 本文采用位置插值的方法,其與外推方法的比較如下。由于基函數(shù) ?_j 的平滑性,插值更加穩(wěn)定,不會(huì)導(dǎo)致野值。 b91dd984-1692-11ee-962d-dac502259ad0.png ? ?該研究將 RoPE f 替換為 f ′,得到如下公式 ? b931949c-1692-11ee-962d-dac502259ad0.png ? 該研究將在位置編碼上的轉(zhuǎn)換稱為位置插值。這一步將位置索引從 [0, L′ ) 縮減到 [0, L) ,以匹配計(jì)算 RoPE 前的原始索引范圍。因此,作為 RoPE 的輸入,任意兩個(gè) token 之間的最大相對距離已從 L ′ 縮減到 L。通過在擴(kuò)展前后對位置索引和相對距離的范圍進(jìn)行對齊,減輕了由于上下文窗口擴(kuò)展而對注意力分?jǐn)?shù)計(jì)算產(chǎn)生的影響,這使得模型更容易適應(yīng)。 ? 值得注意的是,重新縮放位置索引方法不會(huì)引入額外的權(quán)重,也不會(huì)以任何方式修改模型架構(gòu)。 ? 實(shí)驗(yàn) 該研究展示了位置插值可以有效地將上下文窗口擴(kuò)展到原始大小的 32 倍,并且這種擴(kuò)展只需進(jìn)行幾百個(gè)訓(xùn)練步驟即可完成。 表 1 和表 2 報(bào)告了 PI 模型和基線模型在 PG-19 、 Arxiv Math Proof-pile 數(shù)據(jù)集上的困惑度。結(jié)果表明使用 PI 方法擴(kuò)展的模型在較長的上下文窗口大小下顯著改善了困惑度。 b93f2968-1692-11ee-962d-dac502259ad0.png ? b95104bc-1692-11ee-962d-dac502259ad0.png ? ? 表 3 報(bào)告了在 PG19 數(shù)據(jù)集上使用 PI 方法,將 LLaMA 7B 模型擴(kuò)展到 8192 和 16384 上下文窗口大小時(shí)的困惑度與微調(diào)步數(shù)之間的關(guān)系。 ? 由結(jié)果可得,在沒有微調(diào)的情況下(步數(shù)為 0),模型可以展現(xiàn)出一定的語言建模能力,如將上下文窗口擴(kuò)展到 8192 時(shí)的困惑度小于 20(相比之下,直接外推方法的困惑度大于 10^3)。在 200 個(gè)步驟時(shí),模型的困惑度超過了 2048 上下文窗口大小下原始模型的困惑度,表明模型能夠有效利用比預(yù)訓(xùn)練設(shè)置更長的序列進(jìn)行語言建模。在 1000 個(gè)步驟時(shí)可以看到模型穩(wěn)步改進(jìn),并取得了更好的困惑度。 ? b9692ba0-1692-11ee-962d-dac502259ad0.png ? ? 下表表明,通過 PI 擴(kuò)展的模型在有效上下文窗口大小方面都成功地實(shí)現(xiàn)了擴(kuò)展目標(biāo),即僅通過微調(diào) 200 個(gè)步驟后,有效上下文窗口大小達(dá)到最大值,在 7B 和 33B 模型大小以及最高 32768 上下文窗口的情況下保持一致。相比之下,僅通過直接微調(diào)擴(kuò)展的 LLaMA 模型的有效上下文窗口大小僅從 2048 增加到 2560,即使經(jīng)過 10000 多個(gè)步驟的微調(diào),也沒有明顯加速窗口大小增加的跡象。 ? b97bdb88-1692-11ee-962d-dac502259ad0.png ? ? 表 5 顯示擴(kuò)展到 8192 的模型在原始基準(zhǔn)任務(wù)上產(chǎn)生了可比較的結(jié)果,而該基準(zhǔn)任務(wù)是針對更小的上下文窗口設(shè)計(jì)的,對于 7B 和 33B 模型大小,在基準(zhǔn)任務(wù)中的退化最多達(dá)到 2%。 ? b994d2d2-1692-11ee-962d-dac502259ad0.png ? 表 6 表明,具有 16384 上下文窗口的 PI 模型,可以有效地處理長文本摘要任務(wù)。 ? b9b040e4-1692-11ee-962d-dac502259ad0.png

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • 編碼
    +關(guān)注

    關(guān)注

    6

    文章

    933

    瀏覽量

    54731
  • 窗口
    +關(guān)注

    關(guān)注

    0

    文章

    66

    瀏覽量

    10832
  • 模型
    +關(guān)注

    關(guān)注

    1

    文章

    3116

    瀏覽量

    48661
  • LLM
    LLM
    +關(guān)注

    關(guān)注

    0

    文章

    264

    瀏覽量

    297

原文標(biāo)題:不到1000步微調(diào),將LLaMA上下文擴(kuò)展到32K,田淵棟團(tuán)隊(duì)最新研究

文章出處:【微信號:zenRRan,微信公眾號:深度學(xué)習(xí)自然語言處理】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    關(guān)于進(jìn)程上下文、中斷上下文及原子上下文的一些概念理解

    開講之前,咱們有必要看看這兩個(gè)概念:a -- 上下文 上下文是從英文context翻譯過來,指的是一種環(huán)境。相對于進(jìn)程而言,就是進(jìn)程執(zhí)行時(shí)的環(huán)境; 具體來說就是各個(gè)變量和數(shù)據(jù),包括所有的寄存器變量
    發(fā)表于 09-06 09:58

    進(jìn)程上下文與中斷上下文的理解

    來源 網(wǎng)絡(luò)一.什么是內(nèi)核態(tài)和用戶態(tài)內(nèi)核態(tài):在內(nèi)核空間執(zhí)行,通常是驅(qū)動(dòng)程序,中斷相關(guān)程序,內(nèi)核調(diào)度程序,內(nèi)存管理及其操作程序。用戶態(tài):用戶程序運(yùn)行空間。 二.什么是進(jìn)程上下文與中斷上下文1.進(jìn)程上下文
    發(fā)表于 12-11 19:45

    JavaScript的執(zhí)行上下文

    JavaScript執(zhí)行上下文之執(zhí)行上下文
    發(fā)表于 05-29 16:12

    進(jìn)程上下文/中斷上下文及原子上下文的概念

    為什么會(huì)有上下文這種概念進(jìn)程上下文/中斷上下文及原子上下文的概念
    發(fā)表于 01-13 07:17

    基于多Agent的用戶上下文自適應(yīng)站點(diǎn)構(gòu)架

    自適應(yīng)站點(diǎn)很少考慮對用戶環(huán)境的自適應(yīng)。為此,提出用戶上下文自適應(yīng)站點(diǎn)的概念,給出基于多Agent技術(shù)的用戶上下文自適應(yīng)站點(diǎn)構(gòu)架模型。闡述用戶上下文獲取、挖掘過程以及站
    發(fā)表于 04-11 08:49 ?13次下載

    基于交互上下文的預(yù)測方法

    傳統(tǒng)的上下文預(yù)測是在單用戶的上下文基礎(chǔ)上進(jìn)行的,忽視了實(shí)際普適計(jì)算環(huán)境中由于用戶交互活動(dòng)導(dǎo)致的上下文變化因素。為了合理、有效地解決上述局限性問題,該文提出基
    發(fā)表于 10-04 14:08 ?7次下載

    終端業(yè)務(wù)上下文的定義方法及業(yè)務(wù)模型

    該文針對業(yè)務(wù)上下文僅關(guān)注業(yè)務(wù)質(zhì)量較少考慮用戶終端環(huán)境的現(xiàn)狀,提出終端業(yè)務(wù)上下文的概念,為普適業(yè)務(wù)的開展提供必要的信息支撐。給出一種終端業(yè)務(wù)上下文的通用定義方法
    發(fā)表于 03-06 11:06 ?11次下載

    基于Pocket PC的上下文菜單實(shí)現(xiàn)

    介紹了基于 Pocket PC 中的點(diǎn)按操作概念, 論述了在Pocket PC 中上下文菜單的實(shí)現(xiàn)原理及方法, 并給出了基于MFC 下的Windows CE 應(yīng)用程序?qū)崿F(xiàn)上下文菜單的步驟和代碼實(shí)例。
    發(fā)表于 07-25 18:26 ?17次下載

    基于Pocket PC的上下文菜單實(shí)現(xiàn)

    本文介紹了基于 Pocket PC 中的“點(diǎn)按”操作概念 論述了在 Pocket PC 中上下文菜單的實(shí)現(xiàn)原理及方法 并給出了基于 MFC 下的 Windows CE 應(yīng)用程序?qū)崿F(xiàn)上下文菜單的步驟和代碼實(shí)例 。
    發(fā)表于 04-18 10:46 ?0次下載

    基于上下文相似度的分解推薦算法

    針對移動(dòng)服務(wù)推薦中用戶上下文環(huán)境復(fù)雜多變和數(shù)據(jù)稀疏性問題,提出一種基于移動(dòng)用戶上下文相似度的張量分解推薦算法-UCS-TF。該算法組合用戶間的多維上下文相似度和上下文相似可信度,建立用
    發(fā)表于 11-27 17:42 ?0次下載

    初學(xué)OpenGL:什么是繪制上下文

    初學(xué)OpenGL,打開紅寶書,會(huì)告訴你OpenGL是個(gè)狀態(tài)機(jī),OpenGL采用了客戶端-服務(wù)器模式,那時(shí)覺得好抽象,直到后來了解了繪制上下文才把這些聯(lián)系起來。我們可以認(rèn)為每一個(gè)硬件GPU是個(gè)服務(wù)器
    發(fā)表于 04-28 11:47 ?2434次閱讀

    如何分析Linux CPU上下文切換問題

    在我的上一篇文章:《探討 Linux CPU 的上下文切換》中,我談到了 CPU 上下文切換的工作原理。快速回顧一下,CPU 上下文切換是保證 Linux 系統(tǒng)正常運(yùn)行的核心功能。可分為進(jìn)程
    的頭像 發(fā)表于 05-05 20:11 ?1901次閱讀

    谷歌新作SPAE:GPT等大語言模型可以通過上下文學(xué)習(xí)解決視覺任務(wù)

    這篇論文揭示了 PaLM 或 GPT 在通過上下文學(xué)習(xí)解決視覺任務(wù)方面的能力,并提出了新方法 SPAE(Semantic Pyramid AutoEncoder)。這種新方法使得 LLM 能夠執(zhí)行圖像生成任務(wù),而無需進(jìn)行任何參數(shù)更新。這也是使用
    的頭像 發(fā)表于 07-09 15:35 ?1216次閱讀
    谷歌新作SPAE:GPT等大語言模型可以通過<b class='flag-5'>上下文</b>學(xué)習(xí)解決視覺任務(wù)

    Linux技術(shù):什么是cpu上下文切換

    過多的上下文切換會(huì)消耗 CPU 的時(shí)間來保存和恢復(fù)寄存器、程序計(jì)數(shù)器、內(nèi)核棧和虛擬內(nèi)存等數(shù)據(jù),從而導(dǎo)致系統(tǒng)性能顯著下降。 既然上下文切換對系統(tǒng)性能的影響如此之大,那么我們如何檢查它呢?好了,你可以使用 vmstat 工具來查詢你
    發(fā)表于 09-01 09:31 ?431次閱讀
    Linux技術(shù):什么是cpu<b class='flag-5'>上下文</b>切換

    SystemView上下文統(tǒng)計(jì)窗口識(shí)別阻塞原因

    SystemView工具可以記錄嵌入式系統(tǒng)的運(yùn)行時(shí)行為,實(shí)現(xiàn)可視化的深入分析。在新發(fā)布的v3.54版本中,增加了一項(xiàng)新功能:上下文統(tǒng)計(jì)窗口,提供了對任務(wù)運(yùn)行時(shí)統(tǒng)計(jì)信息的深入分析,使用戶能夠徹底檢查每個(gè)任務(wù),幫助開發(fā)人員識(shí)別阻塞原因。
    的頭像 發(fā)表于 08-20 11:31 ?363次閱讀