這項由南京大學領導的研究成果發表於2026年6月，論文編號為arXiv:2606.21649，題為《EvoEmbedding: Evolvable Representations for Long-Context Retrieval and Agentic Memory》，有興趣深入了解的讀者可以通過該編號在arXiv平台查詢完整論文。
**一個被忽視的老問題**
設想你正在和一位助理一起工作了好幾個月。在第一周，你告訴他下周一上午10點有一個重要會議。後來因為有衝突，你在第三個月某天又專門叮囑他把會議改到下午1點。幾個月後，當你問他"會議幾點開始"，他翻開了最早的記錄本，一臉認真地告訴你：上午10點。
這個令人哭笑不得的場景，恰好是當前主流AI檢索系統面臨的真實困境。這類系統依賴所謂"靜態嵌入"（embedding）技術——把每一段文字單獨變成一串數字，然後根據數字之間的相似度來找到最匹配的資訊。問題在於，這種方式完全不考慮時間順序，不理解"之前說的已經改了"，也看不出"第一次"和"最後一次"之間的差別。於是，當你的問題需要理解"歷史的演變"而不是"文字的相似"，這類系統就會一次次地翻出那份已經過時的日程表。
南京大學的研究團隊正是為了解決這個根本性缺陷，開發了一套名為EvoEmbedding的全新檢索表示體系，讓AI的記憶真正能隨著時間流逝而"進化"。
**一、靜態記憶為何是AI的軟肋**
要理解這項研究的意義，不妨先把現有的檢索系統想像成一個檔案館管理員。每當有新文件進來，他就把文件內容總結成一張標籤卡，然後把標籤卡和文件一起歸檔。之後有人來查詢，他只需要拿著問題去和所有標籤卡對比，找到最像的那張，就取出對應文件。
這套流程非常高效，但有個致命弱點：每張標籤卡都是在文件進來時獨立製作的，完全不知道後續還有什麼文件會進來。如果第一份文件說"會議在上午10點"，第二份文件說"會議改到下午1點"，這兩張標籤卡互不相知，毫無關聯。當有人問"會議幾點"，管理員只會找兩張都沾點邊的卡，然後可能隨機取出任意一張，完全無法判斷哪張是"最新的"。
這就是研究團隊在論文中指出的兩個核心缺陷。其一是文字片段被孤立編碼，天然打斷了資訊之間的時間連續性。其二是現有嵌入模型的訓練方式——通常依靠"對比學習"在大量短文本上進行——只能學到"語義相似不相似"，而完全無法掌握"指代消解"（搞清楚"它"指的是哪個）或"時序推理"（判斷先後關係）這類需要整體上下文才能完成的理解任務。
為了繞開這一根本性弱點，學界此前已經做了大量補救工作。一些方法試圖在建立檔案時就把相關資訊整合起來，比如給文件打摘要標籤、構建知識圖譜、做指代消解預處理。另一些方法則試圖在查詢時更聰明，比如用AI自動改寫查詢語句、加入重排序模型把候選結果重新評分。甚至出現了"智能代理檢索"這樣的複雜流程，讓AI像偵探一樣多輪推理、疊代收集證據。但這些補救措施無一例外地帶來了更高的計算開銷和更慢的響應速度，而且治標不治本——嵌入本身還是靜態的，那個翻錯檔案的管理員還在那裡，只是後來多了幾個輔助人員在幫他糾錯。
EvoEmbedding的思路截然不同：與其給管理員配一群助手，不如徹底改造管理員本身，讓他在給每份文件製作標籤卡時，就能參考此前所有文件的歷史脈絡。
**二、進化的記憶：EvoEmbedding的核心設計**
EvoEmbedding的設計思想可以用一位經驗豐富的讀書筆記專家來理解。這位專家在閱讀一本長篇小說時，不是讀完每章就立刻寫下孤立的摘要，而是同時維護著一本"動態工作手冊"。每讀完一章，他都會先把這章的要點提煉出來，然後對照手冊里的歷史積累，把新內容和舊記錄融合更新。當你問他某個情節時，他給出的答案不僅基於那段原文，還蘊含了他對整本書到目前為止的理解。
EvoEmbedding做的正是這件事。它在依次處理一段長文本時，始終維護著一個"潛在記憶"（latent memory）——可以理解為一組高度壓縮的、持續更新的"理解狀態"。每當新的文字片段進來，模型同時完成兩件事：用新片段結合當前記憶狀態更新記憶，並用新片段結合當前記憶狀態生成這個片段的檢索向量。這兩件事在模型內部並行發生，像兩條流水線同時運轉。
對於記憶部分，模型會從新片段中提煉出K個"潛在token"（可以理解為K個高度濃縮的資訊單元），然後通過一個專門的映射層，把這些資訊寫入記憶儲存中。對於檢索向量部分，模型把歷史記憶和當前片段拼接在一起，讓語言模型讀完後，取最後一個特殊結束符號位置的隱狀態，再經過一個投影層，得到最終的檢索向量。
正是這種設計，使得同一個查詢在不同的上下文階段會生成不同的檢索向量。回到開頭的會議例子：在"會議改期"那段文字被處理之前，系統的記憶狀態反映的是"10點開會"；在改期資訊被處理之後，記憶狀態更新為"1點開會"。此後再來查詢"會議幾點"，系統因為攜帶了最新的記憶狀態，就能準確找到那段改期記錄。這就是"可進化的表示"的含義——同一個查詢，面對不同歷史狀態，會生成不同的檢索向量，從而找到不同的目標內容。
**三、防止記憶"腐化"的巧妙設計**
然而，讓記憶持續更新說起來容易，做起來有個極為棘手的問題：如果記憶一直被自身反覆疊加，會發生什麼？
可以用一張照片的反覆複印來類比。第一次複印質量還不錯，第二次複印複印件會有些模糊，第三次更模糊……如果把複印件當作原件繼續複印幾十次，最後得到的可能是一張完全失真的圖像。在深度學習中，這種現象叫做"表示坍縮"（representation collapse）——模型的輸出越來越趨向於一個無意義的固定值，失去了區分能力。
研究團隊為此設計了一個精妙的"記憶隊列"（Memory Queue）機制。具體來說，記憶不是被永久累積在一個固定的容器里反覆疊加，而是被組織成一個"先進先出"的隊列——就像一列火車，新的車廂從後端加入，最舊的車廂從前端自動脫離。整個隊列的總容量固定為C個槽位，默認設置為512個潛在token的空間，相當於L個歷史步驟的記憶。
這種隊列設計帶來兩個關鍵好處。首先，任何一段歷史記憶最多只會被循環編碼L次，從根本上阻斷了反覆疊加導致的質量退化，徹底避免了表示坍縮。其次，固定的容量上限迫使模型學會在每一步都做出取捨——哪些歷史資訊值得保留，哪些可以讓位給新資訊——這種壓力反而訓練出了更強的資訊篩選能力。此外，由於每一步只需要生成K=16個新token寫入隊列，而不是更新全部512個槽位，計算效率得到了顯著提升，訓練效率提高了3.4倍。
值得一提的是，正因為有了這個記憶隊列，研究團隊可以直接在包含各種長度樣本的混合數據集上訓練，不需要人工設計從短到長的"課程學習"（curriculum learning）漸進計劃。這在同類研究中相當罕見——大多數處理長文本的模型都需要精心設計訓練課程，而EvoEmbedding可以直接"直球訓練"。
**四、讓訓練速度提升3.8倍的分段批處理技術**
除了記憶隊列，研究團隊還解決了另一個工程難題：效率問題。
按照最直覺的做法，EvoEmbedding應該一段一段地順序處理輸入——處理第一段，更新記憶，處理第二段，更新記憶……以此類推。這樣固然在邏輯上完全正確，但速度極慢。現代AI訓練硬體最擅長的是並行處理，一段一段地順序操作就像讓一台挖掘機每次只挖一勺土，大材小用。
更麻煩的是，EvoTrain-180K訓練集裡的樣本長度差異極大——有些只有幾十個token，有些接近一萬兩千個token——這種長度懸殊會導致計算資源嚴重浪費，一批樣本里短的很快處理完，長的還在慢慢跑，大量時間被浪費在等待上。
研究團隊提出的"動態分段批處理"（Dynamic Segment-Batching）巧妙地解決了這個問題。具體來說，不再逐段處理，而是動態地把若干個連續片段打包在一起並行處理——打包的數量根據這批片段的總長度動態調整，確保總長度不超過預設閾值（默認2048個token）。這樣，短的片段可以一次打包多個，長的片段少打包幾個，計算資源得到了充分利用。實驗表明，這種分段批處理技術不僅把訓練時間從101.4小時壓縮到26.6小時，帶來了3.8倍的速度提升，還順帶帶來了1.9%的性能提升。
**五、精心構建的訓練"食材"：EvoTrain-180K數據集**
再好的烹飪方法，也需要優質的食材。EvoEmbedding需要一種特殊的訓練數據——不是普通的"問答對"，而是包含完整上下文演變過程的"動態記憶序列"。為此，研究團隊從零設計並構建了EvoTrain-180K數據集，共包含184,137個高質量訓練樣本。
整個數據構建過程分為三個階段，可以理解為"收集原材料、精心加工、嚴格質檢"。
在原材料收集階段，研究團隊匯集了三類原始文本。第一類是來自FineWeb數據集的多樣化網路文本，使用滑動窗口切分為連續片段。第二類是由強大AI合成的多輪對話，每段對話都有特定的人物設定和主題背景，模擬真實的長期人機交流場景。第三類是從原始文本或對話中提取出的各類"記憶片段"，直接以記憶的形式作為上下文。
在精心加工階段，研究團隊基於這些原始文本生成了配套的問答對。為了讓訓練數據足夠多樣，團隊預定義了40多種問題模板，涵蓋指代消解（搞清楚"那個人"是誰）、時序理解（判斷什麼事情發生在前）、知識更新（識別資訊被修改的情況）等複雜推理類型，同時也包含簡單的語義匹配類問題。此外，團隊還特意使用了不同規模、不同來源的AI來生成問題，確保問題風格的多樣性。
在嚴格質檢階段，研究團隊動用了Google的Gemini-3.1-Pro-Preview來完成兩項關鍵工作：標註正確答案所在的文字片段索引，以及篩查問題質量——剔除那些基於AI幻覺而非真實上下文的問題，以及那些無需歷史記錄、憑常識就能回答的問題。
最終的數據集呈現出高度多樣的長度分布：超過一半的樣本文本不足512個token，但也有相當比例的長文本延伸到12,000個token。每個樣本平均包含約21個文字片段，平均對應約19個負樣本。整個數據集規模僅相當於同類主流嵌入模型所用訓練數據的不足1%，訓練時的最長文本也只有測試時真實場景長度的十分之一左右。
**六、訓練的雙重目標和巧妙的損失函數**
有了數據，還需要一套合適的訓練目標。EvoEmbedding的訓練同時優化兩個相互配合的目標，可以理解為同時在學"記得住"和"找得准"。
"記得住"對應的是記憶生成損失。在這個過程中，模型把當前的潛在記憶狀態和一個查詢問題作為輸入，然後嘗試預測正確答案是什麼。關鍵的設計在於：預測時，語言模型的基礎參數被凍結，專門的記憶參數也被關閉，只有記憶狀態本身參與運算。這意味著，如果記憶狀態質量差，預測就會出錯；要預測正確，記憶狀態必須高質量地壓縮了真正有用的歷史資訊。通過這種方式，訓練信號直接逼迫記憶模組生成有用、準確的潛在狀態，而不是讓它學到一些無意義的特徵。
"找得准"對應的是對比表示損失。在這個過程中，模型需要讓查詢的檢索向量儘量靠近包含正確答案的片段向量，同時遠離無關的負樣本片段向量。由於不同長度的上下文會產生數量差異很大的負樣本——長文本天然有更多候選片段——研究團隊引入了一個"長度加權因子"log(N+1)，讓負樣本越多的樣本對應的損失縮放係數越大，從而確保在短文本和長文本樣本之間保持學習難度的大致均衡，避免模型向短文本偏斜。
在模型架構上，EvoEmbedding採用了"多LoRA"設計。LoRA是一種參數高效的微調技術，可以理解為給一個大型語言模型套上不同的"功能配件"——記憶配件和檢索配件分別獨立，互不干擾。訓練時，記憶任務激活記憶LoRA，檢索任務激活檢索LoRA，兩套配件可以無縫切換。基礎語言模型的參數始終保持凍結，避免了學新技能把舊能力忘光的"災難性遺忘"。最終，研究團隊基於Qwen系列語言模型，分別構建了0.8B、2B和4B參數規模的EvoEmbedding家族，旗艦版本為4B參數。
**七、實驗結果：小身板撐起大場面**
研究團隊在10個涵蓋不同任務類型、不同領域、不同上下文長度的基準測試上進行了系統評估，與十餘個強基線模型進行了全面對比。
在檢索任務方面，EvoEmbedding-4B在8個長文本檢索基準的綜合Recall@10指標上達到了80.5分，比排名第二的KaLM-Embedding-Gemma3-12B（一個參數量是它3倍的模型）高出7.8個百分點，比Qwen3-Embedding-8B高出11.5個百分點。即使是EvoEmbedding-0.8B這個最小版本，綜合得分也達到76.7，超過了所有外部基線。
具體來看各個基準的表現相當有說服力。在LoCoMo（專門評測超長期對話記憶的基準）上，EvoEmbedding-4B的Recall@10達到76.3，而Qwen3-Embedding-8B只有49.6，KaLM-Embedding-Gemma3-12B為58.4。在LongMemEval（評測聊天助手長期互動記憶能力的基準）上，EvoEmbedding-4B達到91.7，僅次於部分基線。在ESG-Reports（長企業文檔檢索）上，EvoEmbedding系列以84.0至86.7的區間大幅領先於其他所有模型。在PeerQA（學術論文檢索）上，EvoEmbedding-4B達到51.7，超過了所有外部基線。
在下游生成任務方面，研究團隊把EvoEmbedding作為檢索器配合一個樸素RAG流程（直接把檢索結果塞給生成模型）來測試最終的回答準確率。這裡包含了LoCoMo、LongMemEval以及PersonaMem-32K和PersonaMME（32K和128K版本）等個性化任務基準。EvoEmbedding-4B在所有檢索預算（Top-k=1到32）下都保持了最佳的綜合表現。
特別值得一提的是PersonaMME-128K測試，這個測試的上下文長度達到128,000個token，而EvoEmbedding的訓練樣本最長只有12,000個token，平均只有1,200個token。也就是說，EvoEmbedding要處理比它見過的最長訓練樣本還長10倍以上的文本，平均而言更是超出訓練長度的100倍。在這種極端外推條件下，EvoEmbedding依然保持了領先表現，充分說明其可進化的表示機制具有強大的泛化能力。
**八、超越專用智能代理系統**
也許最令人印象深刻的實驗結果，來自EvoEmbedding和專用智能代理記憶系統的正面對決。
在LongMemEval基準上，研究團隊把一個極其樸素的RAG流程（檢索Top-8片段直接作為上下文）配合EvoEmbedding-4B，與多個專門設計的智能代理記憶系統進行了比較，包括Mem0、A-MEM、LightMem和MemoryOS。這些智能代理系統通常需要在儲存階段消耗大量計算資源來構建結構化記憶（知識圖譜、摘要、分類標籤等），查詢時也需要多輪推理、重排序等複雜流程。
最終結果是：樸素RAG+EvoEmbedding-4B以77.6%的總體準確率奪冠，而最強的專用系統LightMem為70.2%，A-MEM為65.2%，MemoryOS為49.6%，Mem0僅39.5%。更引人注目的是，EvoEmbedding甚至在77.6%這一成績上超過了把完整上下文直接塞給生成模型的"全文輸入"基準（54.8%）——完整輸入已經足夠噪聲了，而EvoEmbedding的精準檢索反而幫助生成模型排除了干擾，得到了更準確的答案。
與此同時，EvoEmbedding完全不需要在儲存階段消耗額外的token——它的潛在記憶是在編碼階段自然生成的，不依賴生成模型，因此額外的token開銷為零。與那些需要大量token來構建結構化記憶的系統相比，EvoEmbedding提供了一個罕見的"又快又好還省錢"的組合。
在LoCoMo基準上，樸素RAG+EvoEmbedding-4B達到74.3%的總體準確率，與全文輸入的74.9%幾乎持平，大幅超過Qwen3-Embedding-8B的67.9%和KaLM-Embedding-Gemma3的72.3%。在某些子任務（如時序類和開放域類問題）上，EvoEmbedding落後於高度專門化的LightMem，但在單跳推理和多跳推理類問題上均表現出色。
**九、EvoEmbedding還能"為別人做嫁衣"**
除了獨立使用，研究團隊還測試了EvoEmbedding作為"即插即用"模組來提升現有智能代理系統表現的能力——換句話說，用EvoEmbedding替換這些系統原本使用的普通檢索器，看效果如何。
實驗在LoCoMo上重現了A-MEM、LightMem和MemoryOS三個系統，原始檢索器換成了All-MiniLM-L6-v2這個輕量級基線。為了公平比較，所有方法最終提供給生成模型的上下文都被限制在Top-20個片段以內。對比策略包括：不做任何增強的原始系統、使用2輪推理式檢索（免費但慢）、用Qwen3-Reranker-4B做重排序，以及用EvoEmbedding-4B做重排序。
結果顯示，EvoEmbedding在三個系統上都帶來了最顯著的提升：A-MEM從43.57%提升到62.73%，提升了19.16個百分點；LightMem從40.58%提升到54.09%，提升了13.51個百分點；MemoryOS從48.64%提升到69.09%，提升了20.45個百分點。EvoEmbedding在所有子任務類別上都優於Qwen3-Reranker-4B這個重排序專家，而兩者在GPU顯存消耗上相當（EvoEmbedding因為只維護固定大小的潛在記憶，避免了二次複雜度，峰值顯存反而略低）。
**十、時序感知能力的視覺化證明**
為了更直觀地展示EvoEmbedding對時序語義的理解，研究團隊做了一個頗具說服力的分析實驗。他們取了64個長對話測試樣本（每個含256個片段），用三種不同時序含義的查詢模板進行檢索："我在我們對話中firstly（最開始）提到了什麼？"、"我lastly（最後）提到了什麼？"、"我in the middle（中間）提到了什麼？"
對於傳統的靜態嵌入模型（Qwen3-Embedding-8B和KaLM-Embedding-Gemma3），三種查詢產生的相似度曲線幾乎完全重疊——模型根本無法區分"最開始"和"最後"這兩種截然不同的時序意圖，只能靠文字內容來匹配，完全忽視了時間順序資訊。
而對於EvoEmbedding，"firstly"查詢的相似度曲線在最早幾個片段處急劇上升，然後隨著片段序號增大而下降；"lastly"查詢的相似度曲線則呈現出隨片段序號增大而穩步爬升的趨勢，在最後的片段處達到峰值。兩條曲線截然分離，形成了鮮明的對比。
研究團隊還用t-SNE降維可視化了不同時序位置片段的向量分布。在傳統靜態嵌入中，三個時序位置（開始、中間、結束）的片段在向量空間中完全混雜在一起，毫無規律可言。而在EvoEmbedding的向量空間中，三個時序位置的片段形成了清晰分離、幾乎不重疊的三個簇。這直接證明了EvoEmbedding的潛在記憶機製成功地把時間順序資訊編碼進了表示向量，而不僅僅停留在文字語義層面。
**十一、消融實驗：每個設計都不是多餘的**
研究團隊還系統驗證了各個設計組件的獨立貢獻，通過逐一拆除某個設計來觀察性能變化。
拆除記憶隊列（改為讓記憶一直積累疊加）會讓訓練時間從26.6小時暴增到91.3小時，同時在LoCoMo上性能從69.9%斷崖下跌到17.0%，在LongMemEval上從76.6%跌到10.0%。這是徹底的崩潰，驗證了記憶隊列對於防止表示坍縮的決定性作用。
拆除記憶生成損失（只保留對比損失，不訓練記憶的內容質量）同樣導致災難性後果：LoCoMo從69.9%跌至15.2%，LongMemEval從76.6%跌至11.4%。這說明光有記憶結構還不夠，記憶里裝的東西必須是高質量的、對查詢有用的資訊，而這正是記憶生成損失所訓練的能力。
拆除長度加權因子會帶來約1.2%的性能下降，拆除分段批處理技術會帶來1.9%的性能下降，並讓訓練時間延長近4倍。這些相對溫和的下降說明這兩個設計是有益的優化，而非系統的基礎支柱——但在實際應用中，省去3.8倍的訓練時間本身就具有極大的工程價值。
**十二、效率代價與收益的權衡**
EvoEmbedding的設計並非沒有代價，研究團隊對此非常坦誠地在論文中進行了效率分析。
在LongMemEval上進行的對比測試顯示，EvoEmbedding-4B處理文檔片段的平均時間約為22.08秒，而Qwen3-Embedding-4B只需3.80秒，Qwen3-Embedding-8B需要5.52秒，KaLM-Embedding-Gemma3-12B需要9.89秒。這是因為EvoEmbedding必須順序處理文檔片段來維護記憶狀態，而靜態嵌入模型可以把所有片段完全並行編碼。
然而，代價換來了兩方面的回報。在準確率上，EvoEmbedding的77.6%明顯高於三個對比模型的70.0%到72.8%。在峰值GPU顯存上，EvoEmbedding-4B只需20.9GB，而KaLM-Embedding-Gemma3-12B需要69.3GB，Qwen3-Embedding-8B需要43.1GB——這是因為EvoEmbedding只需要維護固定大小的潛在記憶隊列，而不是把所有片段向量都保存在GPU內存中。
對於查詢編碼，EvoEmbedding的速度（0.065秒）也比靜態模型（0.026到0.034秒）慢一些，但差距相對較小，且查詢通常是高頻的單次操作，這點差距在實際場景中影響有限。
**編碼時間較慢這一限制在大多數實際應用場景中是可接受的**——通常情況下，文檔是離線預先處理好的，不需要實時編碼；而查詢是在線的，EvoEmbedding在這方面的速度損失很小。
**說到底，這項研究告訴我們什麼**
歸根結底，EvoEmbedding提出了一個簡潔而有力的觀點：要讓AI真正理解"變化中的上下文"，就必須從表示層面根本性地引入時序意識，而不是在外圍堆砌越來越複雜的補救機制。
這套系統在實際中意味著，凡是需要AI記住一段歷史對話、追蹤一個用戶偏好的演變、理解一個項目進展的時間線，EvoEmbedding都能讓檢索系統變得更準確、更可靠。從智能客服到個人助理，從長期項目管理到個性化推薦，只要涉及"動態變化的上下文"，這種可進化的表示都有其用武之地。
當然，研究團隊在論文中也坦誠地指出了現有局限。由於計算資源和訓練數據規模的限制，EvoEmbedding在某些超出訓練分布的場景下可能表現欠佳。此外，目前的框架只支持文本，尚不支持圖片或音頻等多模態輸入，將記憶機制擴展到多模態長文本場景將需要更大的記憶容量和更複雜的對齊機制，這是研究團隊未來計劃探索的方向。
這項研究的開放性也值得一提——代碼已在GitHub上公開，感興趣的讀者可以通過arXiv編號arXiv:2606.21649找到完整論文，進一步了解技術細節。一個值得思考的問題是：當AI的"記憶"越來越接近人類那種能感知時間流逝、自動權衡新舊資訊的記憶方式，我們和AI的協作邊界將被重新定義成什麼樣？
Q&A
Q1：EvoEmbedding和普通檢索模型在處理"會議時間被修改"這類問題時，有什麼本質區別？
A：普通檢索模型會把"會議在10點"和"會議改到1點"這兩段文字分別獨立編碼，查詢時只能靠文字相似度匹配，完全不知道哪個是最新的。EvoEmbedding在處理"會議改到1點"這段話時，已經把"之前說過10點"的記憶狀態納入了當前的編碼過程，因此生成的檢索向量攜帶了時序感知，查詢時會自然偏向最新的那條記錄。
Q2：EvoTrain-180K數據集為什麼只用了18萬條數據，卻能超過用上億條數據訓練的模型？
A：關鍵在於數據類型而非數量。普通嵌入模型的訓練數據大多是短文本問答對，只能學到語義相似度。EvoTrain-180K專門構造了包含時序演變的長文本上下文，每個樣本都要求模型理解"哪條資訊是更新過的""時間順序是什麼"。這種針對性的訓練讓模型掌握了靜態模型根本無法學到的能力，所以用少量高質量數據反而超越了用海量通用數據訓練的大模型。
Q3：EvoEmbedding的記憶隊列大小設置為512有什麼依據，換成更大的會更好嗎？
A：研究團隊做了專門的消融實驗，測試了從16到2048不同容量的隊列。結果顯示，性能從16隨容量增大穩步提升，在512時達到峰值並趨於飽和——再往上NDCG指標不再增長，而內存消耗卻繼續上升。因此512是一個在"歷史覆蓋範圍"和"計算效率"之間取得最優平衡的設定點，盲目增大容量帶來的邊際收益很低。
