中文(繁體)
中文(繁體)
Manus邀請碼申請攻略
Character.AI 推出AvatarFX：AI 視頻生成模型讓靜態圖片“開口說話”
Manychat完成1.4億美元B輪融資，借AI加速全球社交電商佈局
谷歌AI概覽嚴重衝擊SEO點擊率：Ahrefs研究顯示流量下降超34%
Gemini 2.0 Flash 和Gemini 1.5 Flash 配備一個100 萬個詞元的上下文窗口，而Gemini 1.5 Pro 則配備一個200 萬個詞元的上下文窗口。過去，大語言模型(LLM) 受到一次可傳遞給模型的文本（或詞元）數量的極大限制。 Gemini 1.5 的長上下文窗口具有近乎完美的檢索能力(>99%)，發掘了許多新的應用場景和開發者模式。
您已用於文本生成或多模態輸入等場景的代碼可以直接用於長上下文。
使用Gemini 模型的基本方法是將信息（上下文）傳遞給模型，模型隨後會生成回答。上下文窗口可以比作短期記憶。人們的短期記憶可以存儲有限的信息量，生成模型也是如此。
過去幾年中創建的大多數生成模型一次只能處理8,000 個詞元。較新的模型進一步提高了此數字，可接受32,000 個詞元或128,000 個詞元。 Gemini 1.5 是第一個能夠接受100 萬個詞元的模型，並且現在Gemini 1.5 Pro 可接受200 萬個詞元。
在實際中，100 萬個詞元相當於：
1. 50,000 行代碼（標準為每行80 個字符）
2. 您在過去5 年內發送的所有短信
3. 8 部平均長度的英語小說
4. 200 多個平均時長播客劇集的轉寫內容
雖然模型可以接受的上下文越來越多，但關於使用大語言模型的大部分傳統觀點都假設模型存在這種固有限制，而從2024 年開始，情況不再如此。
應對上下文窗口較小這一限制的一些常見策略包括：
1. 在新文本進入時，從上下文窗口任意刪除舊消息/文本
2. 在上下文窗口接近已滿時，總結以前的內容並將其替換為摘要
3. 將RAG 與語義搜索搭配使用，以將數據移出上下文窗口並移入矢量數據庫
4. 使用確定性過濾條件或生成式過濾條件從提示中移除某些文本/字符以保存詞元
雖然其中許多內容在某些場景下仍然相關，但現在的默認起始操作只是將所有詞元放入上下文窗口中。由於Gemini 模型是使用長上下文窗口專門構建的，因此它們具有更強的上下文學習能力。例如，僅憑提供的所有教學材料（500 頁的參考語法書、一本字典和約400 個額外的平行句子），Gemini 1.5 Pro 和Gemini 1.5 Flash 就能學會從英語翻譯成Kalamang ，翻譯質量與使用相同材料學習的人相似。 Kalamang 是一種巴布亞新幾內亞語言，使用人數不到200 人，因此幾乎沒有在線存在。
此示例強調瞭如何開始思考借助Gemini 模型的長上下文和上下文學習能力可實現哪些功能。
雖然大多數生成模型的標準應用場景仍然是文本輸入，但Gemini 1.5 模型系列可實現多模態應用場景的新模式。這些模型可採用原生方式理解文本、視頻、音頻和圖片。它們附帶可接受多模態文件類型的Gemini API，以方便使用。
事實證明，文本是支撐LLM 大部分發展勢頭的智能層。如前所述，LLM 的很多實際限制是因為沒有足夠大的上下文窗口來執行某些任務。這導致了檢索增強生成(RAG) 和其他技術的快速採用，這些技術可為模型動態提供相關的上下文信息。現在，隨著上下文窗口越來越大（目前在Gemini 1.5 Pro 上高達200 萬），出現了一些新技術可用於發掘新的應用場景。
基於文本的長上下文的一些新興和標準應用場景包括：
1. 總結大型文本語料庫
之前使用較小上下文模型的總結方法需要使用滑動窗口或其他技術，以便在新詞元傳遞給模型時保留之前部分的狀態
2. 問答
過去在上下文數量有限且模型的真實召回率較低的情況下，只有使用RAG 才能實現這一目的
3. 智能體工作流
文本是智能體如何保存已完成的操作和需要執行的操作的狀態的基礎；如果沒有關於實際世界和智能體目標的足夠信息，會限制智能體的可靠性
多樣本上下文學習是長上下文模型發掘的最獨特功能之一。研究表明，採用常見的“單樣本”或“多樣本”示例模式，在其中向模型提供一個或幾個任務示例，然後擴展到多達數百個、數千個甚至數十萬個示例，這可能形成全新的模型功能。事實證明，這種多樣本方法的性能與針對特定任務進行了微調的模型類似。對於Gemini 模型的性能尚不足以滿足生產發布的應用場景，您可以嘗試多樣本方法。正如您稍後將在長上下文優化部分中所了解的那樣，上下文緩存使這種高輸入詞元工作負載類型在經濟上更加可行，在某些場景中甚至可降低延遲。
無法訪問媒體本身長期以來一直限制著視頻內容的實用性。瀏覽內容並非易事，轉寫通常無法捕獲視頻的細微差別，而且大多數工具無法同時處理圖片、文本和音頻。在Gemini 1.5 中，長上下文文本功能可轉換為以持續的性能推理和回答有關多模態輸入的問題的能力。在具有100 萬個詞元的“大海撈針”視頻問題中進行測試時，Gemini 1.5 Flash 對上下文窗口中的視頻召回率超過99.8%，而1.5 Pro 在Video-MME 基準上達到了領先的性能。
視頻長上下文的一些新興和標準應用場景包括：
1.視頻問答
2.視頻內存，如Google 的Project Astra 所示
3.視頻字幕
4.視頻推薦系統，通過新的多模態理解來豐富現有元數據
5.視頻自定義，可查看數據以及關聯視頻元數據的語料庫，然後移除與觀看者無關的視頻部分
6.視頻內容審核
7.實時視頻處理
8.處理視頻時，重要的是考慮如何將視頻處理為詞元，這會影響結算和用量限額。如需詳細了解如何使用視頻文件進行提示，請參閱提示指南。
Gemini 1.5 模型是首批能夠理解音頻的原生多模態大語言模型。傳統上，典型的開發者工作流涉及將多個特定於領域的模型（例如語音轉文字模型和文本到文本模型）串聯起來，以便處理音頻。這會導致執行多次往返請求所需的延遲時間增加並且性能下降，這通常歸因於多模型設置的分離架構。
在標準音頻海量評估中，Gemini 1.5 Pro 能夠在100% 的測試中發現隱藏音頻，而Gemini 1.5 Flash 能夠在98.7% 的測試中發現隱藏音頻。 Gemini 1.5 Flash 可在單個請求中接受長達9.5 小時的音頻，而Gemini 1.5 Pro 使用200 萬詞元上下文窗口可以接受長達19 小時的音頻。此外，對於由15 分鐘音頻片段組成的測試集，Gemini 1.5 Pro 歸檔的字詞錯誤率(WER) 大約為5.5%，遠低於專用語音轉文字模型，而且不會由於額外的輸入細分和預處理而提高複雜性。
音頻上下文的一些新興和標準應用場景包括：
1. 實時轉寫和翻譯
2. 播客/視頻問答
3. 會議轉寫和總結
4. 語音助理
如需詳細了解如何使用音頻文件進行提示，請參閱提示指南。
使用長上下文和Gemini 1.5 模型時，主要優化方法是使用上下文緩存。除了以前無法在單個請求中處理大量詞元之外，另一個主要限制是費用。如果您有一個“與數據聊天”應用，用戶在其中上傳了10 個PDF 文件、一個視頻和一些工作文檔，那麼過去您必須使用更複雜的檢索增強生成(RAG) 工具/框架來處理這些請求，並為移入上下文窗口的詞元支付大量費用。現在，您可以緩存用戶上傳的文件，並按小時為存儲這些文件付費。例如，使用Gemini 1.5 Flash 時，每個請求的輸入/輸出費用約為標準輸入/輸出費用的1/4，因此如果用戶與其數據進行足夠多的聊天，便可為作為開發者的您節省大量費用。
在本指南的各個部分中，我們討論了Gemini 1.5 模型如何在各種“大海撈針”檢索評估中實現高性能。這些測試考慮了最基本的設置，您在其中只需尋找一根“針”。如果您要尋找多根“針”或特定信息，模型執行的準確率會有所不同。性能可能會因上下文而變化很大。考慮這一點很重要，因為在檢索到正確信息與費用之間存在固有的權衡。您在單個查詢中可獲得大約99% 的準確率，但每次發送該查詢時，您都必須支付輸入詞元費用。因此，要檢索100 條信息，如果您需要99% 的性能，則可能需要發送100 個請求。這是一個很好的示例，上下文緩存在其中可顯著降低與使用Gemini 模型關聯的費用，同時保持高性能。
通常，如果您不需要將令牌傳遞給模型，最好避免傳遞令牌。不過，如果您有大量包含某些信息的令牌，並且想要詢問這些信息，該模型非常擅長提取這些信息（在許多情況下，準確率高達99%）。
Gemini 1.5 Pro 在53 萬個令牌的召回率達到100%，在多達100 萬個令牌的召回率超過99.7%。
如果您有一組類似的令牌/ 上下文，並且希望多次重複使用，上下文緩存可以幫助您降低與詢問此類信息相關的費用。
現在，所有開發者都可以使用Gemini 1.5 Pro 訪問200 萬個token 的上下文窗口。
任何給定請求（無論大小）都會存在一定的延遲時間，但通常，查詢越長，延遲時間（首次獲取令牌的時間）就越長。
是的，本指南的不同部分中提到了一些數據，但總的來說，Gemini 1.5 Pro 在大多數長上下文應用場景中的性能更出色。