想象你要去环球旅行，面前是一整面墙的衣柜。十年前你只带一个小挎包，装得下证件和手机（对应 4K 上下文）；后来换上 28 寸托运箱，能塞下大半个衣柜（对应 128K 窗口）；如今甚至有人开着集装箱来搬家（对应 1M 窗口）。箱子确实越做越大，但聪明的旅行者都知道：把整个衣柜倒进箱子，拉链会崩、超重要罚钱、衣服会被压皱，最惨的是——你想找那件最爱穿的衬衫时，它正埋在箱子正中央，怎么都翻不到。这篇要讲的，就是大模型面对超长文档时同样的困境：上下文窗口再大，要不要把文档全塞进去？检索和重排还有没有存在价值？怎么控制昂贵的 token 账单？我们会用“收拾行李箱”这条线索，把长上下文 RAG 的取舍之道一次讲透。

岗位关联

掌握长上下文下的存亡抉择与重排策略，能让你的 RAG 系统既省钱又提准——这是大模型应用架构师最值钱的核心判断力。

目录
  1. 可视化演示
  2. 上下文窗口演进
  3. 全量塞入的代价
  4. 检索拼接的优势
  5. 重排层的价值
  6. Token 成本控制
  7. 长文本取舍策略
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示长文档RAG混合架构：全量塞入→长上下文粗读→Cross-Encoder重排→精读输出，对比成本、精度和遗漏率，直观呈现混合架构优势。

本节配有交互动效（进入视口后自动加载，约 3KB）。

全量塞入：80k Token直接输入LLM 200页法律文书约80000 tokens全量塞入200K上下文窗口 准确率82%但单次成本1.6美元，中间条款遗漏率18% 全量塞入成本高且有Lost-in-the-Middle问题

上下文窗口演进

出门旅行前，我们总要面对衣柜叹息。十年前的旅行只带一个小挎包，恰好装下证件、手机、钱包——对应 4K 的上下文窗口，塞一段话就满了；后来换成 24 寸登机箱，能装一周换洗——对应 32K 到 128K 的窗口；再后来有人推出托运大箱，甚至传说中能搬家的集装箱——对应 1M 的百万级窗口。箱子确实一代比一代大，但老旅行者都知道一个朴素道理：能装下一个家，不代表搬家就轻松。

上下文窗口（context window）就是大模型的行李箱，装的货物叫 token——一段文本被切碎后的最小计算单位。窗口越大，模型一次能“看到”的文本越多。从 GPT-3 时代的 4K，到 GPT-4 系列的 128K，再到 Gemini 1.5 的 1M 和各类超长窗口模型，数字一路狂飙。

但窗口变大伴随三笔隐藏账单。第一笔，注意力机制的计算量随长度近似平方级上涨，塞得越满，推理越慢；第二笔，API 费用按 token 线性计费，装得越多钱包越疼；第三笔，多家机构的实验都发现，超长上下文存在“中间迷失”（Lost in the Middle）：模型对开头和结尾的内容记忆最好，中间部分最容易当耳边风。也就是说，窗口变大只改变了“装得下”的可能性，“用得好”是另一回事。

所以，把“窗口巨大”等同于“检索已死”，是旅行新手才会犯的错。箱子变大只代表可能性变大，真正决定旅途体验的，是你如何规划箱子里的每一寸空间——这正是接下来要聊的取舍。

Ln=L0×2n\displaystyle L_n = L_0 \times 2^n
公式说白了：行李箱容量 = 出厂容量 × 翻倍的次数。窗口在指数级增长，但我们的打包智慧并没有跟上。
  1. 起始窗口 $L_0$模型初始的上下文容量，比如 GPT-3 时代普遍的 4K token。
    L0=4096L_0 = 4096
  2. 翻倍次数 $n$每一代模型容量翻倍的数量级，$n$ 越大代表窗口越新越大。
    n=0,1,2,…n = 0, 1, 2, \dots
  3. 容量结果 $L_n$翻倍之后的窗口大小，例如 $L_0=4096$、$n=5$ 时约为 131072，也就是 128K。
    Ln=4096×25=131072L_n = 4096 \times 2^{5} = 131072

全量塞入的代价

图省事的旅行者会怎么做？把整个衣柜哗啦一声倒进箱子：秋冬大衣、六双鞋、三条围巾、床单被套……拉链崩了两个齿，托运称重超了八公斤，柜台小姐面无表情地开出超重罚单。在长文档场景里，这种“全量塞入”就是把整篇超长文档原封不动地拼进提示词，让大模型自己在一堆 text 里大海捞针。

成本账算起来朴素到残忍。大模型的费用和行李箱超重费一样，按“重量”计费——这个重量就是 token 数。假设某模型的输入单价是每百万 token 2 美元，一篇 100 万 token 的年度财报全量塞进去，光输入就烧掉 2 美元；如果这个问答服务每天被调用一万次，一天就是 2 万美元，一个月 60 万美元——很多创业公司的全部家当都不够烧。

比钱更隐蔽的是能力下滑。多家大模型厂商公开过那条经典的 U 型准确率曲线：把关键信息放在上下文开头，模型答得很好；放在结尾，也还行；一旦沉到中部，准确率常常断崖式下跌 20 到 40 个百分点。这就是“中间迷失”。它很像塞满的箱子——你能摸到顶上的帽子和底下的鞋，但中间那件最爱穿的衬衫怎么都翻不到，只能把所有衣服一件件掏出来，摊一地。

全量塞入像极了“搬家式旅行”：省去了取舍的思考，却付出了超重罚款、找东西困难、时间翻倍的三重代价。箱子大，是用来提醒你规划，而不是引诱你挥霍。

C=T×p\displaystyle C = T \times p
公式说白了：行李托运费 = 重量 × 每公斤单价。文档越长、调用越多，账单就线性膨胀。
  1. $T$（输入总 token 数）全量塞入时，等于整篇文档的 token 数加上用户问题。
    T=Tdoc+TqT = T_{\text{doc}} + T_{q}
  2. $p$（单位价格）模型按每千 token 或每百万 token 收取的输入费用，由供应商定价。
    p=美元千 tokenp = \frac{\text{美元}}{\text{千 token}}
  3. $C$（单次成本）两者相乘得到一次请求的花费，$T$ 越大，费用线性上涨，没有折扣。
    C=T×pC = T \times p

检索拼接的优势

老练的旅行者不会搬家。他先看一眼行程单（用户问题）：三天商务会议、两天海边、一晚露营。于是他精准地从衣柜里挑出几件百搭单品：一件西装外套、两件白 T、一条牛仔裤、一双好走又上镜的鞋。箱子只用了一小角，却覆盖了全部行程。这就是检索拼接（RAG）的灵魂——不搬衣柜，只取所需。

具体流程是：先把长文档切成一格格“衣物”（chunk），用向量模型把每一块转成索引；用户提问时，先用向量检索挑出最相关的 top-k 块；最后把这些块和问题拼接在一起，交给大模型生成答案。原来的输入从“整篇 200K 文档”缩成“问题 + 几个小块”，常常只有 2K 到 5K token。

省下多少钱？直接看压缩率：200K 压到 3K，只剩 1.5%。成本也跟着掉到 1/60 左右。更妙的是，检索拼接天然绕开了“中间迷失”——因为送进模型的全是重点，几乎没有无关内容来稀释注意力。但它也有代价：如果检索漏掉了关键块，模型就会“巧妇难为无米之炊”，只能靠编，幻觉概率上升；此外，切块会把跨段落的因果论证拦腰截断，出现“断章取义”——就像管家只给你塞了西装上衣，却忘了配套的西裤。

检索像一位记性不太好的管家：帮你省下搬家的力气，但可能漏装东西。为了对付管家的疏忽，我们在登机口前加了一道最终核验——这就是重排。

CRAG=(Tq+k×Tc+Ta)×p\displaystyle C_{\text{RAG}} = (T_{q} + k \times T_{c} + T_{a}) \times p
公式说白了：检索后的账单 =（问题 + k 个候选块 + 答案）× 单价。比起全文，省了一个数量级还不止。
  1. $T_{q}$（问题 token 数）用户问题通常很短，几十个 token，几乎可以忽略。
    Tq≈50T_{q} \approx 50
  2. $k \times T_{c}$（检索块）取回 $k$ 个候选块，每块平均 $T_{c}$ 个 token，这是输入的主力。
    k×Tck \times T_{c}
  3. $T_{a}$（答案输出）模型生成的答案，长短取决于问题难度，与文档总长度无关。
    TaT_{a}
  4. 累加后乘以单价 $p$三项相加才是这次请求的全部计费输入，再乘单位价格。
    CRAG=(Tq+k Tc+Ta)×pC_{\text{RAG}} = (T_{q} + k\,T_{c} + T_{a}) \times p

重排层的价值

登机前，管家把候选的衣服摊了一床：白 T、碎花裙、冲锋衣、牛仔裤、晚礼服……他按衣架上的标签粗略分了类，可标签太粗糙了——“白 T”和“商务衬衫”都写着“上衣”，但你要见客户，白 T 明显差点意思。这时候，就需要一位眼神更毒的老管家，把每件衣服和行程单仔细比对，再按合适程度重新排队。这件“二次精挑”就是 Reranking（重排）。

为什么需要重排？因为第一阶段的向量检索“快但糙”：它对问题和文档分别编码，再用余弦相似度粗粗比划一下，像按标签分类，没有真正“读懂”。而重排模型（通常是 cross-encoder 架构）会把问题和每个候选块同时喂进模型，逐字比对相关性打分——慢许多，但准得多。工程上典型的漏斗是：向量检索先召回 1000 个候选块，重排精筛出 50 个，最后取前 10 个喂给大模型。

重排的价值不止于打分。它还有一个隐藏杀招——位置优化。既然实验证明模型对上下文开头和结尾的记忆最好、中间最差，那我们就把最相关的块放到提示词最前面，让大模型第一眼就看到重点。公开评测里，加入重排后 P@10 常常上涨 10 到 20 个百分点，性价比极高。

重排就是登机口那位最后把关的安检员：把最合适的穿搭放到最顺手的位置，让大模型一眼就看到重点。多花一次精排的调用费，换来准确率肉眼可见的回升——这笔买卖，精明。

P@k=∣Rk∩Rrel∣k\displaystyle \text{P}@k = \frac{|R_{k} \cap R_{\text{rel}}|}{k}
公式说白了：精排的命中率 = 前 k 个候选里真正相关的个数 ÷ k。重排就是让“真正相关”的人混进前排。
  1. $R_k$（前 k 个候选）重排打分后取出的前 $k$ 个块，它们是最终要被模型看到的“幸运儿”。
    Rk={d1,d2,…,dk}R_{k} = \{d_{1}, d_{2}, \dots, d_{k}\}
  2. $R_{\text{rel}}$（真正相关集合）人工标注或事后验证中真正和问题相关的块。
    RrelR_{\text{rel}}
  3. 交集与除法前 $k$ 个里真正相关的占比越高，说明你的挑选越准，模型被噪音带偏的概率越小。
    P@k=∣Rk∩Rrel∣k\text{P}@k = \frac{|R_{k} \cap R_{\text{rel}}|}{k}

Token 成本控制

旅行预算就像托运限额：随身行李规定 7 公斤，超一公斤收一公斤的钱。新手只会祈祷别超重，老手却在出发前就定死规则：买一个行李秤、每件东西上称、超了就往外拿。控制 token 成本也是同样的思路——不是事后看账单流泪，而是事前给每次请求戴上“紧箍咒”。

第一板斧是输入预算上限：给单次请求设一个硬顶，比如 30K token，超了就强制走检索或摘要，绝不允许把 200K 文档原样塞进去。第二板斧是摘要压缩：对超长文档先做分层摘要（MapReduce 式：每章出摘要，摘要再汇成总摘要），把 200K 压到 5K，再让模型基于大纲精读关键章节。第三板斧是缓存复用：把相似问题的高质量答案存进语义缓存，命中就直接返回，不重新调模型。

这三板斧合起来，成本曲线就被按住了。特别要强调缓存：生产环境里用户问题高度重复，比如“发票怎么报销”这类高频咨询，命中率可以达到三四成。命中率越高，单次均摊成本越低，就像同一个目的地飞多了，直接用上次的装箱清单，五分钟收工。

省钱的本质不是少用模型，而是让每分钱都花在刀刃上。就像经验丰富的旅行者，路线走熟了直接抄旧装箱单，把省下来的力气留给真正陌生的目的地。

Cavg=(1−h) Cmiss+h Chit\displaystyle C_{\text{avg}} = (1 - h) \, C_{\text{miss}} + h \, C_{\text{hit}}
公式说白了：平均账单 = 没命中时的高价 × 比例 + 命中时的低价 × 比例。命中率越高，均价越便宜。
  1. $h$（缓存命中率）相同或相似问题直接命中缓存的比例，取值范围 0 到 1。
    h=NhitNtotalh = \frac{N_{\text{hit}}}{N_{\text{total}}}
  2. $C_{\text{miss}}$ 与 $C_{\text{hit}}$未命中时要支付完整推理费用，命中时几乎接近零成本。
    Chit≈0C_{\text{hit}} \approx 0
  3. 加权平均命中占比越高，整体均摊成本越被拉低，这是缓存省钱的全部秘密。
    Cavg=(1−h) Cmiss+h ChitC_{\text{avg}} = (1 - h)\,C_{\text{miss}} + h\,C_{\text{hit}}

长文本取舍策略

选箱子也是一门学问。下楼买个菜，拎个环保袋就够了——对应短文本直接全量塞入，零检索开销，又快又准；七天的商务出差，用 20 寸登机箱让管家提前挑选——对应中长文档走“检索 + 重排”；环球搬家，才动用集装箱——对应超长文档先分层摘要再检索精读。没有最好的方案，只有最合适的方案。

判定标准通常有四个输入：文档长度与窗口的比例（超过窗口一半就得警惕）、问题对精确性的要求（法律、医疗场景宁慢勿错）、预算额度（每千次请求的成本红线）、时延容忍度（全量塞入的响应时间可能让用户等成雕像）。把这四个输入代入下面的分段决策，答案往往不言自明。

还有一个务实的选择——混合方案：短文档全量直出，中长文档先检索 + 重排，如果检索置信度不足，就降级为摘要兜底，形成“全量 — 检索 — 摘要”三级阶梯。上线前务必准备一组带标注的评测集，盯住四个指标：答案召回率、P@k、单请求平均成本、端到端时延。用数据做决定，而不是用感觉。

“行李箱再大，也别把整个衣柜塞进去”——这句话应该贴在每个 RAG 系统机房的墙上。上下文窗口还在长大，但取舍的智慧永远不会过时：全量是选项，检索是常态，重排是杠杆，成本是红线。

策略(Tdoc)={全量塞入,Tdoc≤λW检索加重排,λW<Tdoc≤μW分层摘要加检索,Tdoc>μW\displaystyle \text{策略}(T_{\text{doc}}) = \begin{cases} \text{全量塞入}, & T_{\text{doc}} \le \lambda W \\ \text{检索加重排}, & \lambda W < T_{\text{doc}} \le \mu W \\ \text{分层摘要加检索}, & T_{\text{doc}} > \mu W \end{cases}
公式说白了：文档重量不同，选不同的箱子。短到一定程度直接拎着走，长到一定程度就得先压缩再装箱。
  1. $\lambda W$（下阈值）$W$ 是上下文窗口，$\lambda$ 常取 0.3 到 0.5，文档小于这个比例时全量最划算。
    λW\lambda W
  2. $\mu W$（上阈值）$\mu$ 常取 1 到 3，文档超过窗口数倍时，全量已不可能，必须分层摘要。
    μW\mu W
  3. 分段决策$T_{\text{doc}}$ 落在哪个区间，就执行对应的策略，形成一个三档可解释的决策规则。
    策略(Tdoc)={全量,Tdoc≤λW检索加重排,λW<Tdoc≤μW摘要加检索,Tdoc>μW\text{策略}(T_{\text{doc}}) = \begin{cases} \text{全量}, & T_{\text{doc}} \le \lambda W \\ \text{检索加重排}, & \lambda W < T_{\text{doc}} \le \mu W \\ \text{摘要加检索}, & T_{\text{doc}} > \mu W \end{cases}

AI 应用场景

合同条款问答系统

阶段：检索与重排阶段

解决的问题：法务团队常要审数百页合同，过去把整份合同塞进 128K 窗口，单次请求烧掉大量 token，且免责条款、违约条款一旦沉在文档中部就被大模型忽略。改用“按条款切块 + 向量检索 + cross-encoder 重排”后，只取 top 10 相关条款进提示词，中间段的关键条款不再漏看。

具体案例：某律所的合同问答机器人，对一份 500 页的并购协议，全量塞入单次成本约 2.5 美元且经常答错中部条款；加入检索与重排后，单次成本降到 0.15 美元以内，针对“违约金计算方式”“保密义务期限”这类问题的准确率从 71% 提升到 93%。

企业知识库智能客服

阶段：在线推理与缓存优化阶段

解决的问题：中大型企业的知识库有上万篇 SOP 和 FAQ，即使用 1M 窗口也装不下，且高频问题大量重复调用 API 造成账单失控。保留检索环节，用重排把候选从 500 缩到 5，再叠加语义缓存命中高频问题，均摊成本大幅下降。

具体案例：某电商平台的售后客服机器人，每天约 20 万次咨询，缓存命中率 35%，配合检索 + 重排把单次推理成本压到原来的 1/40，同时“退款时效”这类问题答案准确率从 82% 提升到 96%。

论文批量综述分析

阶段：离线分析与摘要压缩阶段

解决的问题：研究员做文献综述，要消化几十上百篇论文，逐篇全文精读既慢又贵。采用“分层摘要 + 检索 + 重排”：每篇论文先出结构化摘要，摘要再汇总成综述框架；遇到具体问题（如“哪些工作用了重排”）时，只检索相关章节并重排，保证引用准确、结论有据。

具体案例：某 AI 实验室用该管线对 100 篇 RAG 相关论文做综述，原先估计的 50 小时人工阅读量压缩到半天，单篇成本约 0.1 美元，综述中每条结论都能回溯到原文段落。

Python 演示

python73 行
# -*- coding: utf-8 -*-"""模拟长上下文RAG: 切块 -> 粗检索 -> 重排 -> token成本估算"""  def tokenize(text):    # 中文按单字切分, 作为玩具级分词    return [ch for ch in text if ch.strip()]  def chunk_text(text, size=20, overlap=5):    chars = tokenize(text)    chunks = []    i = 0    while i < len(chars):        chunks.append(chars[i:i + size])        i += size - overlap    return chunks  def coarse_retrieve(query, chunks):    q = set(tokenize(query))    scored = []    for idx, c in enumerate(chunks):        hit = sum(1 for w in q if w in c)        scored.append((hit, idx))    scored.sort(key=lambda x: (-x[0], x[1]))    return scored  def rerank(scored, chunks, query):    q = set(tokenize(query))    n = len(chunks)    mid = n / 2.0    out = []    for hit, idx in scored[:20]:        if hit == 0:            continue        chunk = chunks[idx]        precision = sum(1 for w in q if w in chunk) / float(len(chunk))        penalty = 1.0 - min(abs(idx - mid) / mid, 0.8)        out.append((idx, precision * penalty))    out.sort(key=lambda x: -x[1])    return out[:3]  def estimate_cost(tokens, price_per_1k=0.005):    return tokens / 1000.0 * price_per_1k  def main():    doc = ("公司引入智能客服系统, 系统依赖检索增强生成技术. "           "用户提问时先从知识库检索相关段落, 再用重排模型排序候选, "           "最后交给大模型生成答案. 长上下文虽支持超大窗口, "           "但全量塞入费用高昂, 超长文档仍需保留检索, "           "重排让相关片段排前面避免中部迷失.") * 60    query = "重排如何降低长文档问答成本"    chunks = chunk_text(doc, size=20, overlap=5)    candidates = coarse_retrieve(query, chunks)    final_last = candidates[0][1]    top = rerank(candidates, chunks, query)     full_tokens = len(tokenize(doc))    rag_tokens = sum(len(chunks[i]) for i, _ in top) + len(tokenize(query))    print("全文tokens:", full_tokens)    print("重排前第1位编号:", final_last)    print("重排后前3位编号:", [i for i, _ in top])    print("压缩率: %.1f%%" % (rag_tokens * 100.0 / full_tokens))    print("全量成本: $%.4f" % estimate_cost(full_tokens))    print("RAG成本: $%.4f" % estimate_cost(rag_tokens))  if __name__ == "__main__":    main()
目的：用一个纯 Python 的迷你管线，演示“全文切块 → 粗检索 → 重排（含中部位置惩罚）→ 成本对比”，让你直观看到检索 + 重排如何把 token 消耗压到只剩零头。
  1. def chunk_text(text, size=20, overlap=5)把长文档切成有重叠的小块，重叠是为了减少跨块断章。
  2. hit = sum(1 for w in q if w in c)玩具版粗检索：统计问题里的字出现在每个块中的次数。
  3. scored.sort(key=lambda x: (-x[0], x[1]))按命中数从高到低排序，得到初始候选队列。
  4. penalty = 1.0 - min(abs(idx - mid) / mid, 0.8)重排的位置惩罚：越靠近文档中部的块，被扣的分越多，模拟“中间迷失”。
  5. precision = sum(1 for w in q if w in chunk) / float(len(chunk))用候选块内的问题命中密度作为精排分数。
  6. rag_tokens = sum(len(chunks[i]) for i, _ in top) + len(tokenize(query))RAG 实际只送进模型的 token 数：3 个块 + 问题。

常见误区

误区现在模型都支持 128K、1M 了，整本书都能塞进去，检索和重排纯粹是历史包袱，直接全量塞入不就行了？

正解窗口大只代表“装得下”，不等于“记得住”。全量塞入 100 万 token，账单线性爆炸，而且中间段落会被“Lost in the Middle“效应吞掉。就像 28 寸箱子确实装得下整个衣柜，但超重罚款和翻找时间会让你悔不当初。RAG 的价值不是”装不下“，而是”没必要装”。

为何常见：厂商发布会都在吹捧超长窗口，给人“上下文越长越聪明”的错觉，忽略了成本与注意力分布这两笔真实的账。

误区既然检索能省钱，那我 top-k 取 50 个、100 个块全塞给模型，召回总该更全吧？

正解候选块越多，噪音越多，反而稀释模型对真正关键内容的注意力。实验和公式都指向同一个结论：输入 token 和成本线性挂钩，而准确率在某个 k 值达到峰值后不升反降。正确姿势是小步粗召回、大步精排——向量召回大池子，重排精选小池子。

为何常见：把“召回率”和“准确率”混为一谈，以为给模型喂得越多它就懂得越多，忘了大模型也会被海量无关信息带偏。

误区向量检索出来的相似度最高的块，不就是最相关的吗？再花一次钱做重排，纯属浪费。

正解向量检索是双塔结构，问题和文档各编各的码，只算个粗糙的余弦相似度——好比按衣架标签分类，标签写“上衣”的白 T 和商务衬衫会被混在一起。重排用 cross-encoder 把问题和候选块同时读一遍，才能真正对齐语义。公开评测里 P@10 提升 10~20 个百分点是常态，这钱花得非常值。

为何常见：只看到重排的额外延迟和费用，没看到它能把“看似相关”和“真正相关”区分开，也没看到它顺带解决了相关块排位靠后的问题。

误区成本控制就是减少 API 调用次数，把能合并的问题合并，少调模型就等于省钱。

正解API 账单按 token 计费，输入 token 才是大头。一次全量塞入 200K 文档，比调用二十次只塞 1K 文档贵得多。省钱的关键是压缩单次输入：设输入预算上限、分层摘要、复用缓存、重排精选块数。盯着调用次数不看 token 长度，就像只数行李件数不看重量，照样被超重费教育。

为何常见：很多人按“次数”理解计费，忽略了 token 这个真正的计费单位，导致把优化方向完全搞反。

面试题

Q1. 长上下文模型（如 128K 窗口）出现后，关于 RAG 的说法正确的是？

单选题 · easy

  • A.RAG 已被完全淘汰
  • B.RAG 依然很有价值← 正确答案
  • C.大窗口无需检索
  • D.小窗口才需检索

答案：B。窗口变大只解决“装得下”，没解决“记得住”和“付得起”。全量塞入会带来线性膨胀的 token 费用和中间迷失问题，RAG 在超长文档场景下依然能大幅降本并提升有效性，所以 B 对。

Q2. "Lost in the Middle" 指的是什么？

单选题 · easy

  • A.模型读不了中间内容
  • B.模型最爱中间位置
  • C.中间信息最易被忽略← 正确答案
  • D.中间 token 更昂贵

答案：C。实验发现的 U 型准确率曲线表明，模型对上下文开头和结尾的信息利用最好，中间位置的信息最容易被忽略，像行李箱最中间被压皱的衣服。注意它不是“读不了”，而是“利用差”。

Q3. 全量塞入超长文档的主要代价是？

单选题 · easy

  • A.模型参数变大
  • B.词表容量不足
  • C.断网风险变高
  • D.token 成本线性增长← 正确答案

答案：D。全量塞入的代价是输入 token 数随文档长度线性增长，费用也线性上涨；同时注意力在长输入上退化，产生中间迷失。模型参数、词表和断网都与塞入文档无关。

Q4. RAG 流程中，重排（Reranking）的核心作用是什么？

单选题 · mid

  • A.对候选按相关性精排← 正确答案
  • B.压缩输入图片大小
  • C.提升训练数据质量
  • D.减少模型输出长度

答案：A。重排是用 cross-encoder 对检索出的候选块逐块精打分，按相关性重新排序，把最相关的块排到模型最容易注意的位置。它不处理图片、不碰训练数据，也不限制输出长度。

Q5. 向量检索“快但糙”，重排“慢但准”，工程上正确的组合是？

单选题 · mid

  • A.检索层精排重排层粗筛
  • B.只留重排不要检索
  • C.检索层召回再重排精选← 正确答案
  • D.两者互斥不可组合

答案：C。标准漏斗是向量检索先快速召回大池子（如 1000 个），重排再精筛出小池子（如 10 个）喂给模型。A 把两者分工搞反了；B 和 D 都是错误的二选一思维。

Q6. 控制 RAG token 开销最有效的手段是？

单选题 · mid

  • A.用重排缩小精读块数← 正确答案
  • B.加大 top-k 候选数量
  • C.延长模型输出长度
  • D.提高向量维度

答案：A。输入 token 是成本大头，用重排把精读块数从几十个压到几个，直接砍掉一大半输入。加大 top-k 会让输入更长、成本更高；延长输出、提高向量维度和输入成本没有直接关系。

Q7. 某文档共 200K token，预算限制单次输入最多 30K，最合理的策略是？

单选题 · hard

  • A.分层摘要加检索拼接← 正确答案
  • B.全部塞入忽略预算
  • C.只取前 30K 开头的块
  • D.强制截断为单一块

答案：A。200K 远超 30K 硬顶，正确做法是先分层摘要压缩全局，再对关键章节做检索 + 重排，既控预算又保精度。B 违反预算；C、D 的粗暴截断会把关键信息丢在尾部，重蹈中间迷失的覆辙。

Q8. 长上下文场景下，保留检索与重排的价值包括哪些？

多选题 · mid

  • A.降低单次输入 token 数← 正确答案
  • B.缓解中间位置信息丢失← 正确答案
  • C.彻底消除模型幻觉
  • D.缩小候选聚焦注意力← 正确答案

答案：ABD。检索只取相关块，输入 token 大降；重排把相关块排到开头，避开中间迷失；候选从 1000 缩到 10，噪音减少让注意力聚焦。但任何技术都无法彻底消除幻觉，C 是绝对化表述，排除。

Q9. 关于 Reranking 提升长文档问答准确率的机制，正确的是？

多选题 · hard

  • A.用交叉编码器对齐问文档← 正确答案
  • B.把相关块排在易受注意位置← 正确答案
  • C.减少候选数量抑制噪音干扰← 正确答案
  • D.直接改写大模型参数

答案：ABC。重排模型把问题和候选块同时编码，语义对齐更准；它还能利用开头/结尾注意力高的特点做位置优化；候选池缩小后噪音更少。但重排只是“挑材料”，不修改大模型本身的参数，D 错。

Q10. 某团队把 100 篇论文全量塞入 1M 窗口做综述，评估发现中部论文的关键结论大量丢失。合理的改进方案是？

多选题 · extreme

  • A.按主题分层摘要后再喂入← 正确答案
  • B.对关键章节做检索并重排← 正确答案
  • C.对结果做位置敏感评估← 正确答案
  • D.放弃所有检索只用全文

答案：ABC。分层摘要压缩全局、检索 + 重排聚焦关键章节、评测时按信息所在位置分层统计，三者都能直击“中间迷失”。D 是回到全量塞入的老路，只会让问题复发。