平時(shí)做大模型選型或者版本升級最頭疼的往往不是模型跑不起來而是“不知道哪個(gè)模型更適合自己的業(yè)務(wù)”。跑分榜翻來覆去就那么幾個(gè)通用指標(biāo)到了真實(shí)場景里卻發(fā)現(xiàn)分?jǐn)?shù)高不代表好用。最近 Andrej Karpathy 在社交平臺(tái)上轉(zhuǎn)推了一個(gè)很有意思的評測新方向直接用《指環(huán)王》這類長篇文學(xué)作品作為評測材料考察大模型在超長上下文下的理解、記憶和檢索能力。這個(gè)思路看起來“很文科”但背后其實(shí)踩中了當(dāng)前大模型評測體系的一個(gè)核心盲區(qū)。這篇文章會(huì)圍繞這個(gè)新評測基準(zhǔn)展開聊聊它到底在測什么、為什么用《指環(huán)王》而不是傳統(tǒng)問答集并且給出一個(gè)可以在本地復(fù)現(xiàn)的超長上下文評測腳本。無論你是在做大模型選型、RAG 方案對比還是單純想驗(yàn)證手里的模型“是不是真的能讀長文”這篇文章都能給你一套可以落地的思路。1. 為什么大模型評測基準(zhǔn)需要一次“換血”1.1 傳統(tǒng)評測基準(zhǔn)的局限大模型評測基準(zhǔn)Benchmark是衡量模型能力的一把尺子。早期的 MMLU、C-Eval、GLUE 等基準(zhǔn)本質(zhì)上都是“單選題 知識問答”的組合模型通過選擇題的形式被評估知識覆蓋面。這類評測有一個(gè)共同特點(diǎn)每個(gè)問題都是獨(dú)立的上下文很短模型不需要跨段落記憶和推理。但真實(shí)業(yè)務(wù)場景遠(yuǎn)不是這樣。比如讓模型總結(jié)一份 50 頁的產(chǎn)品文檔。讓模型基于一份長期合同回答“第 12 章第 3 條和第 8 章第 5 條之間有沒有矛盾”。讓模型閱讀整本小說后分析人物關(guān)系變化。這些任務(wù)要求模型具備長上下文理解能力和跨區(qū)間信息關(guān)聯(lián)能力而傳統(tǒng)基準(zhǔn)幾乎測不到這兩點(diǎn)。1.2 長上下文評測為什么難做長上下文評測難難在三個(gè)地方難點(diǎn)說明語料不好找需要長度足夠、內(nèi)容有邏輯連貫性的文本不是簡單拼接幾條新聞問題不好出不能只問“某個(gè)人物是誰”要設(shè)計(jì)能體現(xiàn)“理解”而非“檢索”的問題答案不好判長文任務(wù)往往沒有唯一標(biāo)準(zhǔn)答案自動(dòng)評估困難這也是為什么過去很多“長上下文評測”看起來像閱讀理解題的簡單版給一段 3000 字的文章問一個(gè)答案就在原文里的問題。這種評測模型很容易“作弊”——靠局部匹配就能回答根本不需要真正讀完上下文。1.3 卡帕西轉(zhuǎn)推背后的信號Karpathy 是前特斯拉 AI 總監(jiān)、OpenAI 創(chuàng)始成員之一在業(yè)界有很強(qiáng)的影響力。他轉(zhuǎn)推這個(gè)《指環(huán)王》評測方向本質(zhì)上是在提醒大家大模型的評測重點(diǎn)正在從“知識廣度”轉(zhuǎn)向“上下文深度”。換句話說下一階段的大模型競爭不只是比“誰記住的知識多”而是比“誰能在一篇長文里保持對細(xì)節(jié)的持續(xù)跟蹤”。這對 RAG、Agent、長文檔處理類應(yīng)用尤其重要。2. 拆解新評測基準(zhǔn)《指環(huán)王》到底在測什么2.1 為什么選《指環(huán)王》《指環(huán)王》The Lord of the Rings作為評測材料有以下幾個(gè)天然優(yōu)勢長度夠長。三部曲總字?jǐn)?shù)巨大單卷也有幾十萬詞天然適合測試模型的上下文窗口上限。人物多、關(guān)系復(fù)雜。佛羅多、山姆、甘道夫、阿拉貢等角色分布在多條故事線上模型要回答“誰在哪條線做了什么”必須跟蹤全局。伏筆和呼應(yīng)密集。很多細(xì)節(jié)在書的前半部分埋下、后半部分呼應(yīng)模型要關(guān)聯(lián)到這種跨卷信息不是簡單檢索能做到的。沒有版權(quán)障礙的替代方案不好找。當(dāng)然《指環(huán)王》本身有版權(quán)評測使用時(shí)應(yīng)考慮合理引用范圍更推薦用公開摘要或自建問題集的方式。2.2 評測的核心能力維度這類評測基準(zhǔn)主要考察四個(gè)維度1. 長程記憶能力模型能否記住幾千甚至幾萬 token 之前出現(xiàn)的細(xì)節(jié)。例如“阿拉貢第一次見到阿爾玟是在哪里這個(gè)地點(diǎn)在第三部里有沒有再次出現(xiàn)”2. 跨段落推理能力需要把分散在多個(gè)章節(jié)的信息組合起來才能回答。例如“甘道夫從灰袍變白袍之后他對佛羅多說的第一句話是什么這句話和第一部里的哪句臺(tái)詞形成了呼應(yīng)”3. 抗干擾能力長文中包含大量無關(guān)信息模型需要區(qū)分“重要線索”和“背景描寫”。例如“在莫瑞亞礦坑的遭遇中真正導(dǎo)致甘道夫墜落的直接原因是什么” 這個(gè)問題的干擾信息很多必須抓到關(guān)鍵事件鏈。4. 位置偏差抵抗能力很多模型對輸入中間位置的信息記憶較差這是長上下文模型常見問題。評測設(shè)計(jì)者會(huì)把關(guān)鍵信息放在長文的不同位置驗(yàn)證模型是否對位置不敏感。2.3 和傳統(tǒng) RAG 評測的區(qū)別這里要特別區(qū)分一下。RAG檢索增強(qiáng)生成評測通常給模型一個(gè)檢索出來的片段模型只需要基于片段回答。而《指環(huán)王》這類評測是直接把整本書塞進(jìn)上下文不依賴外部檢索。這意味著它測的是模型原生上下文窗口的“實(shí)際可用長度”模型在長輸入下的注意力分配效率模型綜合全文信息的能力如果你的業(yè)務(wù)打算“把整份文檔直接丟給模型”而不是“先檢索再回答”那這個(gè)評測方向就更貼近你的真實(shí)場景。3. 環(huán)境準(zhǔn)備搭建本地長上下文評測環(huán)境3.1 版本說明本節(jié)示例側(cè)重演示評測思路你可以根據(jù)自己的環(huán)境和模型版本進(jìn)行調(diào)整Python 3.10一個(gè)支持長上下文的模型接口可以是 OpenAI 兼容接口、vLLM 部署的本地模型或者 Ollama 本地部署的模型文本語料可以先用任意一本公版長篇小說代替《指環(huán)王》驗(yàn)證流程3.2 安裝依賴pip install openai tiktoken pandas如果你使用本地 Ollama 部署的模型也需要確認(rèn) Ollama 的服務(wù)地址和模型名稱。3.3 項(xiàng)目結(jié)構(gòu)llm-long-context-eval/ ├── data/ │ └── book.txt # 測試語料建議使用公版長篇小說 ├── questions.json # 評測問題集 ├── evaluate.py # 評測主腳本 └── results/ └── output.csv # 評測結(jié)果輸出4. 核心實(shí)現(xiàn)設(shè)計(jì)并運(yùn)行長上下文評測4.1 準(zhǔn)備評測材料由于《指環(huán)王》原文存在版權(quán)限制本文演示使用公版文本。你可以把任意 txt 格式的長篇小說放入data/book.txt注意保持章節(jié)結(jié)構(gòu)完整。# 讀取并預(yù)處理語料 def load_book(file_path): with open(file_path, r, encodingutf-8) as f: text f.read() # 清理多余空白符 text .join(text.split()) return text這里有一個(gè)設(shè)計(jì)要點(diǎn)評測語料最好保留原始章節(jié)結(jié)構(gòu)不要過度清洗。因?yàn)檎鎸?shí)業(yè)務(wù)場景里的長文檔也不會(huì)是“清洗干凈”的保留標(biāo)點(diǎn)、段落、對話格式評測結(jié)果才更接近實(shí)際。4.2 設(shè)計(jì)評測問題集評測問題的質(zhì)量直接決定評測結(jié)果的可信度。為了體現(xiàn)“理解而不只是檢索”問題應(yīng)該分為幾類事實(shí)檢索型答案在原文中有明確出處但需要找到正確位置?？缍侮P(guān)聯(lián)型需要結(jié)合兩處及以上信息才能回答。推理綜合型原文沒有直接答案需要模型基于通篇內(nèi)容推斷。{ questions: [ { id: q1, type: fact_retrieval, question: 主角團(tuán)隊(duì)第一次遇到戒靈時(shí)他們正在前往哪個(gè)村莊的路上, answer: 布理, context_range: chapter_1_3 }, { id: q2, type: cross_reference, question: 開篇提到的“夏爾”在哪里在后續(xù)章節(jié)中這個(gè)地點(diǎn)和哪條主線任務(wù)直接相關(guān), answer: 中土大陸的西北部魔戒毀滅任務(wù), context_range: full_book }, { id: q3, type: inference, question: 從佛羅多主動(dòng)承擔(dān)攜帶魔戒的任務(wù)可以看出他具有哪些性格特點(diǎn)請結(jié)合至少兩處情節(jié)說明。, answer: 勇敢、責(zé)任感強(qiáng)、為朋友考慮, context_range: full_book } ] }4.3 編寫評測主腳本核心邏輯分為三步把整本書文本拼進(jìn) prompt調(diào)用模型接口生成回答對比模型輸出與標(biāo)準(zhǔn)答案import json import time import csv from openai import OpenAI def call_model(client, model_name, system_prompt, user_prompt): 調(diào)用模型接口返回回答文本 response client.chat.completions.create( modelmodel_name, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt} ], temperature0.2, # 評測場景使用較低溫度提高可重復(fù)性 max_tokens1024 ) return response.choices[0].message.content def build_prompt(book_text, question): 拼接完整 prompt return f請閱讀下面提供的小說全文然后回答一個(gè)問題。 【小說全文】 {book_text} 【問題】 {question} 請只輸出你的答案不需要解釋過程。如果問題需要結(jié)合多處情節(jié)回答請分別列出依據(jù)。 def evaluate(client, model_name, book_text, questions): results [] for q in questions: prompt build_prompt(book_text[:60000], q[question]) try: answer call_model(client, model_name, 你是一名嚴(yán)謹(jǐn)?shù)奈膶W(xué)研究者擅長結(jié)合原文細(xì)節(jié)回答問題。, prompt) results.append({ id: q[id], question: q[question], expected: q[answer], actual: answer[:500], status: success }) except Exception as e: results.append({ id: q[id], question: q[question], expected: q[answer], actual: str(e), status: error }) time.sleep(1) # 避免請求頻率過高 return results if __name__ __main__: client OpenAI( base_urlhttp://localhost:8000/v1, # vLLM 默認(rèn)地址 api_keyEMPTY ) model_name your-model-name book_text load_book(data/book.txt) with open(questions.json, r, encodingutf-8) as f: data json.load(f) questions data[questions] results evaluate(client, model_name, book_text, questions) with open(results/output.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[id, question, expected, actual, status]) writer.writeheader() writer.writerows(results) print(評測完成結(jié)果已保存到 results/output.csv)4.4 結(jié)果評估策略自動(dòng)評測長文回答最常用的方法是關(guān)鍵詞覆蓋率 語義相似度但不能完全依賴。def simple_score(expected, actual): 基于關(guān)鍵詞覆蓋的簡單評分 expected expected.strip() actual actual.strip() # 精確匹配 if expected in actual: return 1.0 # 關(guān)鍵詞匹配 keywords [w for w in expected if len(w) 1] hit sum(1 for k in keywords if k in actual) return hit / len(keywords) if keywords else 0.0更嚴(yán)謹(jǐn)?shù)淖龇ㄊ且胍粋€(gè)“裁判模型”Judge Model對回答打分判定標(biāo)準(zhǔn)包括事實(shí)準(zhǔn)確性、邏輯一致性、是否引用原文依據(jù)。這種方式成本更高但比關(guān)鍵詞匹配可靠得多。5. 用 vLLM 部署一個(gè)被評測的長上下文模型要跑上面的評測腳本需要先有一個(gè)“被測模型”的接口。5.1 用 vLLM 啟動(dòng)本地模型vLLM 是目前比較主流的大模型推理框架支持高吞吐推理和長上下文。vllm serve your-model-path \ --max-model-len 65536 \ --gpu-memory-utilization 0.9 \ --trust-remote-code這里的關(guān)鍵參數(shù)--max-model-len模型最大輸入長度不同模型支持的上限不同不能隨便設(shè)否則會(huì)報(bào)上下文超限錯(cuò)誤。--gpu-memory-utilization控制顯存利用率值太高容易 OOM。--trust-remote-code部分模型倉庫需要加載自定義代碼按需開啟。5.2 模型上下文長度確認(rèn)在評測前建議先確認(rèn)模型 tokenizer 把長文本編碼成多少 tokenimport tiktoken text load_book(data/book.txt) encoder tiktoken.get_encoding(cl100k_base) tokens encoder.encode(text) print(f全書 token 數(shù): {len(tokens)})如果測試文本 token 數(shù)超過了模型上下文限制評測就沒有意義了。要學(xué)會(huì)切片控制比如只截取前 60k token 做部分章節(jié)評測或者換用更短的長文。6. 常見問題與排查思路跑長上下文評測時(shí)容易出現(xiàn)下面幾類問題問題現(xiàn)象常見原因解決思路請求報(bào) 400 context length exceeded輸入文本超過模型上下文上限用 tokenizer 統(tǒng)計(jì) token 數(shù)按比例截?cái)辔谋净驌Q窗口更大的模型生成結(jié)果明顯偏離原文prompt 中沒有強(qiáng)調(diào)“結(jié)合原文”模型自由發(fā)揮在 system prompt 中強(qiáng)制要求“引用原文依據(jù)”或開啟 json 結(jié)構(gòu)化輸出同一個(gè)問題多次評測結(jié)果不一致temperature 設(shè)置偏高評測場景把 temperature 降到 0 或 0.2長文本輸入時(shí)速度極慢模型 prefill 階段計(jì)算量大使用 vLLM、TensorRT-LLM 等推理框架或啟用 prompt caching模型“記住了”開頭和結(jié)尾但忘記中間內(nèi)容長上下文位置偏差調(diào)整關(guān)鍵信息在文本中的位置做 A/B 測試換用位置編碼更強(qiáng)的模型另外有一個(gè)非常常見的誤判模型輸出“看起來合理”但其實(shí)是錯(cuò)的。長上下文評測里模型很容易生成流暢但不符合原文的“幻覺內(nèi)容”。這也是為什么不能只看“能不能生成一段話”要用事實(shí)型問題來約束驗(yàn)證。7. 長上下文評測的最佳實(shí)踐與工程建議7.1 評測集設(shè)計(jì)建議問題必須可驗(yàn)證。每個(gè)問題都要有原文依據(jù)不能開放式發(fā)問?；旌想y度梯度。既有直接檢索題也有跨章推理題才能區(qū)分不同模型的能力層次?？刂崎L度變量。同一組問題分別測試輸入 8k、32k、64k token 的表現(xiàn)能畫出模型的“長上下文衰減曲線”。避免數(shù)據(jù)污染。如果模型在訓(xùn)練階段已經(jīng)見過這些文學(xué)作品的問答對評測結(jié)果會(huì)虛高。盡量使用新編的、不常見的問題。7.2 評測執(zhí)行建議固定隨機(jī)種子和溫度確?？蓮?fù)現(xiàn)。多次運(yùn)行取平均。長文本生成的隨機(jī)性比短文本更大至少跑 3 次。記錄 token 消耗和時(shí)間。長上下文評測不僅要看回答質(zhì)量還要看成本因?yàn)檩斎?token 越多推理成本和延遲越高。同一個(gè)任務(wù)在 Llama 和 Qwen 上可能答案接近但時(shí)間差異明顯。7.3 業(yè)務(wù)落地建議能用 RAG 就別硬塞全文。如果業(yè)務(wù)只關(guān)心文檔里的幾個(gè)片段RAG 的成本和延遲遠(yuǎn)低于全文輸入。長上下文能力更適合“必須理解全局”的場景。長上下文模型不是越長越好。上下文窗口的上限和“有效使用率”是兩回事。很多模型聲稱支持 128k但實(shí)際在 32k 之后表現(xiàn)急劇下滑。建議用上述評測腳本測出“有效長度”。生產(chǎn)環(huán)境加入回歸評測。模型升級時(shí)跑一遍同樣的長上下文評測防止“換模型后長文能力反而退化”的情況。7.4 一個(gè)務(wù)實(shí)的選型思路結(jié)合當(dāng)前大模型評測趨勢建議團(tuán)隊(duì)建立“兩份榜單”通用能力榜單用 MMLU、C-Eval 等傳統(tǒng)基準(zhǔn)快速篩掉明顯不合格的模型。長上下文專項(xiàng)榜單用類似《指環(huán)王》評測方案的自建問題集測出模型在你業(yè)務(wù)場景下的真實(shí)長文表現(xiàn)。兩張榜單交叉對比才能選到“知識廣”和“讀得懂長文”兼顧的模型。8. 寫在后面卡帕西轉(zhuǎn)推《指環(huán)王》評測新基準(zhǔn)給行業(yè)提了個(gè)醒大模型的評測重心正在從“背知識”轉(zhuǎn)向“讀長文”。對做 LLM 應(yīng)用的開發(fā)者來說這意味著選型邏輯要跟著變——不要只看排行榜總分要用自己的真實(shí)業(yè)務(wù)數(shù)據(jù)去測。本文給出的評測腳本只是一個(gè)起點(diǎn)你可以把自己的業(yè)務(wù)文檔、行業(yè)資料替換進(jìn)去生成屬于自己團(tuán)隊(duì)的“長上下文評測集”。如果手頭有用長文檔場景的同學(xué)建議現(xiàn)在就把這套流程跑一遍至少能知道當(dāng)前模型的長文能力底線在哪里。后續(xù)想深入了解的話可以從這幾個(gè)方向繼續(xù)學(xué)習(xí)模型位置編碼RoPE、ALiBi對長上下文的影響vLLM 的 PagedAttention 和 prefix caching 原理RAG 與長上下文模型的成本對比用 LLM-as-a-Judge 做自動(dòng)評測的可靠性討論評測這件事只有結(jié)合自己的業(yè)務(wù)場景動(dòng)手做才有真正的參考價(jià)值。希望這篇文章能幫你少走一些彎路。如果覺得有啟發(fā)歡迎收藏備用也歡迎在評論區(qū)交流你的長上下文評測經(jīng)驗(yàn)。