許多 Gemini 模型都提供 100 萬個以上詞元的大型脈絡窗口。以往，大型語言模型 (LLM) 會受到一次可傳送至模型的文字 (或符記) 數量限制。Gemini 長脈絡窗口可發掘許多新用途和開發人員模式。
您已在 文字產生或多模輸入等情況下使用程式碼，在長時間的背景下，這些程式碼將繼續運作，無須進行任何變更。
這份文件將概略說明您可以使用脈絡窗口為 100 萬個以上符號的模型，達成哪些成就。本頁面簡要介紹脈絡視窗，並探討開發人員應如何思考長脈絡、長脈絡的各種實際用途，以及如何最佳化長脈絡的使用方式。
如要瞭解特定型號的內容視窗大小，請參閱「型號」頁面。
什麼是脈絡窗口？
使用 Gemini 模型的基本方式，就是將資訊 (脈絡) 傳遞至模型，讓模型隨後產生回應。將情境視窗比喻為短期記憶。人類的短期記憶容量有限，生成式模型也是如此。
如要進一步瞭解模型的運作方式，請參閱生成式模型指南。
開始使用長時間內容
舊版生成式模型一次只能處理 8,000 個符記。新款型號則進一步接受 32,000 甚至 128,000 個符記。Gemini 是第一個可接受 100 萬個符號的模型。
實際上，100 萬個符記會如下所示：
- 50,000 行程式碼 (每行標準 80 個半形字元)
- 過去 5 年內傳送的所有簡訊
- 8 本平均長度的英文小說
- 超過 200 份平均長度的 Podcast 節目轉錄稿
許多其他模型的脈絡視窗較為受限，因此通常需要採用策略，例如任意捨棄舊訊息、摘要內容、搭配向量資料庫使用 RAG，或是篩除提示訊息來儲存符記。
雖然這些技巧在特定情況下仍有其價值，但 Gemini 的廣泛脈絡窗口採用更直接的方式：預先提供所有相關資訊。由於 Gemini 模型是專門設計用於處理大量的上下文功能，因此可提供強大的上下文學習功能。舉例來說，Gemini 只使用情境內的教材 (500 頁的參考文法、字典和約 400 個平行句子)，學會翻譯從英文翻譯成 Kalamang 的內容，而 Kalamang 是一種使用者不到 200 人的巴布亞語言，翻譯品質與使用相同教材的人工學習者相似。這說明瞭 Gemini 的長篇脈絡資料可帶來的典範轉變，透過強大的使用過程教學功能，開啟全新可能性。
長脈絡用途
雖然大多數生成式模型的標準用途仍是文字輸入，但 Gemini 模型系列可支援多模態用途的新典範。這些模型可原生解讀文字、影片、音訊和圖片。為了方便使用者，這些模型會搭配 Gemini API，可處理多模態檔案類型。
長篇文字
文字已證明是 LLM 的動力來源之一，為其提供智慧層支援。如前文所述，LLM 的實際限制大多是因為沒有足夠大的背景資訊視窗來執行特定工作。因此，我們迅速採用檢索增強生成 (RAG) 和其他技術，以動態方式為模型提供相關的背景資訊。如今，隨著脈絡視窗越來越大，我們也推出了可發掘新用途的新技術。
文字型長篇幅背景資訊的部分新興和標準用途包括：
- 摘錄大量文字的語料庫
- 先前的摘要選項採用較小的脈絡模型，因此需要使用滑動視窗或其他技巧，在將新符記傳遞至模型時，保留先前部分的狀態
- 問與答
- 以往，由於背景資訊有限，且模型的事實回憶率偏低，因此只有 RAG 能夠做到這一點
- 代理工作流程
- 文字是代理程式記錄自身所做及需要做的事的基礎；如果沒有足夠的資訊，代理程式就無法瞭解環境和自身目標，這會影響代理程式的可靠性
多樣本情境學習是長篇幅情境模型最獨特的功能之一。研究顯示，採用常見的「單樣本」或「多樣本」示例模式，也就是向模型提供一或數個任務範例，並將範例數量擴大至數百、數千或數十萬個，可帶來新穎的模型功能。這項多鏡頭方法的效能也與針對特定任務精細調整的模型相似。如果 Gemini 模型的效能尚不足以在實際工作環境中推廣，您可以嘗試多拍法。稍後您將在長時間背景資訊最佳化部分中瞭解，背景資訊快取可讓這類高輸入符記工作負載的經濟效益更高，在某些情況下甚至可縮短延遲時間。
長篇影片
長期以來，影片內容的實用性一直受到媒體本身缺乏無障礙性的問題所限制。內容難以瀏覽、轉錄稿通常無法捕捉影片的細微差異，而且大多數工具不會同時處理圖片、文字和音訊。有了 Gemini，長文字內容功能就能轉換為推理能力，並持續以多模態輸入內容回答問題。
以下是一些新興和標準的長篇影片背景資訊用途：
- 影片問題與解答
- Google Project Astra 顯示的影片記憶體
- 影片字幕
- 影片推薦系統，透過新多模態理解功能豐富現有中繼資料
- 影片客製化功能：查看資料集和相關影片中繼資料，然後移除與觀眾不相關的影片片段
- 影片內容審查
- 即時處理影片
處理影片時，請務必考量影片如何轉換為符記，這會影響帳單和使用限制。如要進一步瞭解如何使用影片檔案提示，請參閱提示指南。
長篇音訊
Gemini 模型是第一個可理解音訊的本機多模態大型語言模型。以往，開發人員為了處理音訊，通常會將多個特定領域模型 (例如語音轉文字模型和文字轉文字模型) 串連在一起。這會導致執行多個往返要求所需的延遲時間增加，並降低效能，這通常是因為多個模型設定的架構未連結。
音訊背景資訊的一些新興和標準用途包括：
- 即時語音轉錄和翻譯
- Podcast / 影片問答
- 會議語音轉錄和摘要
- 語音助理
如要進一步瞭解如何使用音訊檔案提示，請參閱提示指南。
長文字背景最佳化
使用長脈絡和 Gemini 模型時，主要的最佳化方式是使用脈絡快取。除了先前提到的在單一要求中處理大量符記的可能性之外，成本也是另一個主要限制。如果您有一個「與資料對話」應用程式，使用者上傳 10 個 PDF、一個影片和一些工作文件，過去您必須使用更複雜的檢索增強生成 (RAG) 工具/架構，才能處理這些要求，並為移至內容視窗的符記支付大量費用。您現在可以將使用者上傳的檔案快取，並以每小時付費的方式儲存檔案。舉例來說，Gemini Flash 每個要求的輸入 / 輸出成本約為標準輸入 / 輸出成本的 4 倍，因此如果使用者與自己的資料進行對話，開發人員就能節省大量成本。
長脈絡限制
在本指南的各個部分，我們討論了 Gemini 模型如何在各種針尖上的芝麻疹擷取評估中，達成高效能。這些測試會考量最基本的設定，也就是您要尋找單一針狀物體。如果您可能有多個「針」或特定資訊，模型的準確度就不會相同。成效可能會因脈絡而有極大差異。這點相當重要，因為取得正確的擷取資訊與成本之間存在著天生的權衡。您可以透過單一查詢取得約 99% 的結果，但每次傳送該查詢時，都必須支付輸入符記費用。因此，如果要擷取 100 個資訊，如果您需要 99% 的成效，可能就需要傳送 100 個要求。這就是一個很好的例子，說明在使用 Gemini 模型時，內容快取功能可大幅降低相關成本，同時維持高效能。
常見問題
在脈絡視窗中，哪裡是放置查詢的最佳位置？
在大多數情況下，尤其是在總背景資訊很長的情況下，如果將查詢 / 問題放在提示訊息的結尾 (所有其他背景資訊之後)，模型的效能會更好。
在查詢中加入更多符記會降低模型效能嗎？
一般來說，如果您不需要將符記傳遞至模型，最好避免傳遞符記。不過，如果您有大量含有部分資訊的符記，且想針對該資訊提出問題，模型就能有效地擷取該資訊 (在許多情況下，準確度可達 99%)。
如何透過長式內容查詢降低成本？
如果您有要多次重複使用的類似符號 / 內容，內容快取功能可協助降低與該資訊相關的查詢成本。
背景資訊長度會影響模型延遲時間嗎？
無論大小為何，任何指定要求都會產生固定延遲時間，但一般來說，查詢越長，延遲時間就越長 (到達第一個符記的時間)。