Anthropic發(fā)布Claude3模型文本窗口擴展對RAG影響有限

目錄Claude3技術報告解讀 1RAG：長文本窗口不構成對RAG的100%替代 9投資評價和建議 13風險分析 14請務必閱讀正文之后的免責條款和聲明。Claude3技術報告解讀AnthropicClaude3多模態(tài)能力評估。Claude3的技術報告1首先GPQADiamond是一個研究生級別的問答基準，難題側重于研究生水平的專業(yè)知識和推理，每個問題限時30分鐘，并且可以通過互聯(lián)網搜集信息，Claude3CoT（Temp=12）設置下方差很大，Claude10次評估的平均值為結果，但這一做Diamond81.2%3Claude等模型。Claude3 ClaudeOpus SonnetClaude3HaikuClaude3 ClaudeOpus SonnetClaude3HaikuGPT-4Gemini1.0UltraGemini1.5ProMMLUGeneralreasoning5-shot86.8%79.0%75.2%81.5% 76.7%90.1%Medprompt+——83.7%81.9%5-shotCoT88.2%————MATHMathematicalproblemsolving0-shotMaj@324-shot60.1%43.1%38.9%68.4%53.20%——73.7%55.1%50.3%——————GSM8KGradeschool95.0%0-shotCoT92.3%0-shotCoT88.9%0-shotCoT95.3%0-shotCoT94.4%0-shot91.7%11-shotHumanEvalPythoncodingtasks0-shot84.9%73.0%75.9%87.8%74.4%71.9%GPQA(Diamond)GraduatelevelQ&A0-shotCoT50.4%40.4%33.3%35.7%————MGSMMultilingualmathDROPReadingcomprehensionarithmetic90.7%0-shot83.5%0-shot75.1%0-shot74.5%8-shotF1Score79.0%8-shot82.4Zero-shot+CoT88.7%8-shot78.9Variableshots83.6%BIG-Bench-Hard89.0%Co83.178.978.483.73-shot3-shot3-shotZero-shot+CoTMixedevaluations3-shotCoT86.8%82.9%73.7%Few-shot+ 84.0%Few-shot+CoTCoTARC-Challenge25-shotmmon-sensereasoning96.4%93.2%89.2%96.3%————HellaSwag 10-shot95.4%89.0%85.9%95.3%87.8%92.5%1/de8ba9b01c9ab7cbabf5c33b80b7bbc618857627/Model_Card_Claude_3.pdf2使用Chain-of-Thought技術進行采樣，并將溫度參數（temperature）設置為1。溫度參數在文本生成中用于控制生成文本的多樣性和隨機性。較高的溫度值會產生更多的隨機性和多樣性，而較低的溫度值會產生更加確定性和一致性的文本。3/pdf/2311.12022.pdf請務必閱讀正文之后的免責條款和聲明。Common-sensereasoningPubMedQABiomedicalquestions5-shot75.8%78.3%76.0%74.4%—— ——0-shot74.9%79.7%78.5%75.2%—— ——WinoGrandeCommon-sensereasoning5-shot88.5%75.1%74.2%87.5%RACE-HReadingcomprehension5-shot92.9%88.8%87.0%——APPSPythoncodingtasksO-shot70.2%55.9%54.8%——MBPPCodegenerationPass@186.4%79.4%80.4%——資料來源：Claude4，Promptbase5，注：GPQAGPT-4202311NYU、Cohere、AnthropicGPQA:AGraduate-LevelGoogle-ProofQ&ABenchmark其他測試集方面，Claude3Opus和GPT-4Turbo/GPT-4在代碼、科學計算、通用推理等領域表現基本接近。需要指出的是，由于以上測試結果多為有限測試的平均值，因此兩個模型極小的差異可能被重復測試所改寫，但大體上我們只能認為Claude3Opus和GPT-4Turbo/GPT-4在這些領域處于同一水平。目前基于文本領域的性能，LLM的排序為GPT-4Turbo≈Claude3Opus>Gemini1.0Ultra。長文本方面，Claude進行了QuALITY和Haystack兩種測試，較Claude2/1模型穩(wěn)步提升。QuALITY是一個多項選擇問答數據集，旨在評估語言模型對長格式文檔的理解能力，該數據集中的上下文段落平均長度約為5,000個token。在此基準測試上人類的表現達到93.5%，Claude3Opus在0-shot/1-shot情況下分別達到89.2%/90.5%的準確率，接近人類的準確率。Haystack方面，Claude3系列模型的召回率穩(wěn)定在90%以上。圖1:Claude系列模型在QuALITY測試集的表現數據來源：《TheClaude3ModelFamily:Opus,Sonnet,Haiku》，4https:///news/claude-3-family5/microsoft/promptbase海外行業(yè)動態(tài)報告圖2:Claude3Opus海底撈針測試召回率 圖3:Claude3Sonnet海底撈針測試召回率數據來源：《TheClaude3ModelFamily:Opus,Sonnet,Haiku》，

數據來源：《TheClaude3ModelFamily:Opus,Sonnet,Haiku》，圖4:Claude3/2.1模型在Haystack測試集的表現（召回率%）數據來源：《TheClaude3ModelFamily:Opus,Sonnet,Haiku》，由于長文本測試的結果對實驗設置高度敏感，我們這里展開討論該~99%召回率的真實意義。TheNeedleinaHaystackLLMRAG系統(tǒng)在不同規(guī)模環(huán)境下的性能。它的工作原理是將特定的、有針對性的信息（Needle）嵌入到更大、更復雜的內容（Haystack）中。ANeedleintheHaystackLLM在大量數據中識別和利用特定信息的能力。進行測試時，實驗團隊將一個外部創(chuàng)建的內容（Needle）放置在一本書/文章（Haystack）的不同位置/LLMNeedle相關的問題（whatisthebestthingtodoinSanFrancisco?），并在文檔不同深度（1K2Ktoken）LLM的表現，3-4的召回率圖像。圖5:在PaulGraham的文章中插入一段不相關的話數據來源：海外行業(yè)動態(tài)報告海底撈針測試對Prompt高度敏感。通過觀察Claude2.1的測試結果，我們注意到靠近文檔底部的內容召回率總體較高，而靠近文檔頂部的內容召回率則較低，且這與Anthropic官方發(fā)布的Claude2.1測試結果有較大差異。根據Anthropic，若調整Prompt（添加了一句提示“Hereisthemostrelevantsentenceinthecontext:”），Claude2.1的總體召回率從27%提升至98%。圖6:左圖為Claude-2.1200K的海底撈針測試結果（2024年2月），右圖為Claude官方測試結果（2023年12月）數據來源：Anthropic6，6https:///news/claude-2-1-prompting海外行業(yè)動態(tài)報告圖7:Claude2.1對海底撈針測試的Prompt進行更新數據來源：Anthropic7，海底撈針測試對實驗內容高度敏感。Arize團隊對海底撈針測試進行了調整，將針設置為一個隨機數字，LLMPrompt進行測試。結果表明，ArizeClaude2.198%Prompt修改后召回率有所提升（164次下74次）。Claude/GPT/Gemini等模型的長文本性能上，需要仔細考慮其實驗設置（本/數字，是否隨機，prompt是否微調），再進行橫向比較。另外，更具現實意義的問題是，長文本下人們通常的需求是取出相關內容，并進行推理，尤其是一些復雜問題的推理，過于簡單的實驗設置8可能高估模型的性能。圖8:Claude2.1在有無Prompt精調下的召回率對比（從87%提升至94%）數據來源：Arize，7https:///news/claude-2-1-prompting8現有的測試主要是取出內容，幾乎不涉及復雜推理，Needle的內容高度一致可能導致緩存，因此引入隨機Needle非常重要，且提問應該涉及一定難度的推理，更貼近現實需求。海外行業(yè)動態(tài)報告圖9:GregKamradt使用的ClaudePrompt模板數據來源：Arize，圖10:Anthropic修訂后的Prompt模板數據來源：Arize，多模態(tài)能力上，Claude3與Gemini1.0Ultra相比仍有一定差距，但略好于GPT-4V。海外行業(yè)動態(tài)報告圖11:Claude3與GPT-4V、Gemini系列模型多模態(tài)能力對比數據來源：《TheClaude3ModelFamily:Opus,Sonnet,Haiku》，圖12:AnthropicClaude3系列模型輸入/輸出API價格數據來源：Anthropic9，圖13:GPT-4輸入/輸出價格數據來源：OpenAI10，9https:///api#pricing10/pricingRAG：長文本窗口不構成對RAG的100%替代11LLMasaOS調整注意力計算機制。當前符堯等12upsampling（上采樣）LLM處理長文本的能力，可以將LLM128K。UCB研究團隊13則提出通過層次訓練高效擴展上下文窗口。Google團隊14提出通過在不損失太多精度的情況下快速近似注意力矩陣的輸出，從而實現長文本下的計算速度提升。圖14:Gemini1.5Pro宣布將contextwindow拓展至1Mtokens數據來源：Google15，Gemini/Claude3/GPT-4Turbo~99%1）Prompt的精細調整，這意味如果抽取的內容從固定模式的文本/數字切換為隨機的文本/數字，召回率表現可能受到影響；2）當前的TheNeedleinaHaystackLLM不需要做太多額外推理，但實際應用場景中XX規(guī)定，員工是否允許攜帶寵物上班”、“XX設計方案是否符合現行居民住宅的建筑標準”等問題，這類問題可以拆分為兩部分，1）問題相關的背景材料，如現行民用住宅的建筑標準；2）匹配，設計方案分解后與建筑標準相匹配。Haystack測試的評估一定程度上存在“誤導性”，該90%+的表現不意味著模型在長文本中取出和結合上下文做復雜推理的能力。1611/blog/2024/02/18/compound-ai-systems/，根據UCB轉引Databricks信息，目前LLM的應用中60%采用RAG，30%采用CoT。12《DataEngineeringforScalingLanguageModelsto128KContext》。13《WorldModelOnMillion-LevelVideoAndLanguageWithRingAttention》。14《HyperAttention:Long-contextAttentioninNear-LinearTime》。15https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/16LLMPR的一面是，AnthropicClaude3GPQALLM在長文本、復雜問題等場景下的表現提升，促進社會生產力進步。請務必閱讀正文之后的免責條款和聲明。通過長文本窗口替代RAG的核心瓶頸在于成本，本質原因是內存瓶頸。前述問題都可以通過對注意力機Anthropic/OpenAI1Mtoken的定價在GPUGPU（將內容切分后分別放在不同GPU上計算后傳輸，這導致延遲。圖15:GPU架構示意圖 圖16:SM架構示意圖數據來源：《Towards100xSpeedup:FullStackTransformerInferenceOptimization》，

數據來源：《Towards100xSpeedup:FullStackTransformerInferenceOptimization》，圖17:A100內存結構 圖18:長文本推理面臨內存瓶頸 數據來源：《EfficientMemoryManagementforLargeLanguageModelServingwithPagedAttention》，

數據來源：《Towards100xSpeedup:FullStackTransformerInferenceOptimization》，符堯17提出利用KV緩存存儲內容，但其占據大量內存且一旦切換文檔需要重新緩存。根據LLaMAIndex，1Mtoken100GB3A1002H100A100/H100的價格及有限存儲空間，大量占用內存的代價可能過高。PierreLienhart18（AWSGenAI解決方案架構師）KV緩存token長度的關系從指數級增長轉化為線性增長，LLMtoken17《Towards100xSpeedup:FullStackTransformerInferenceOptimization》。18/@plienhar/llm-inference-series-3-kv-caching-unveiled-048152e461c8請務必閱讀正文之后的免責條款和聲明。海外行業(yè)動態(tài)報告數級增長，因此KV緩存策略本質平衡GPU帶寬和內存以及計算量的問題。圖19:Transformer輸入序列長度為3的雙頭（自）注意力層的詳細視圖數據來源：《LLMInferenceSeries:3.KVcachingunveiled》，圖20:KV緩存策略后的注意力計算機制數據來源：《LLMInferenceSeries:3.KVcachingunveiled》，方法論上，Transformer模型在計算注意力分數時，需要查詢向量(Q)與所有鍵向量(K)做點積，獲得未縮放的注意力分數。但是對于帶有掩碼(mask)的位置，不論它們的注意力分數是多少，最后都會被遮擋為0，這部分計算就是冗余計算。KV緩存策略通過預先計算好所有鍵值對(K,V)的注意力分數和加權值，并緩存起來。在實際推理時，只需從