SA-K-11 检索会消失吗与四个未解问题

检索会消失吗：Agent 知识工程的下一程与四个未解问题

系列导航：00 系列导航 · 01 四类知识 · 02A 解析五环 · 02B 断裂修复 · 03 切分标定 · 04 查询理解 · 05 混合检索与重排 · 06 引用验证 · 07 知识新鲜度 · 08 多源一致性 · 09 管道门禁 · 10 全簇总结 · 本篇（11）
小提一句 ：由于平台每日发布笔记数量限制，目前系列笔记还没全部上传。后续内容会持续更新，大家可以先点个关注、收藏，以免错过。 谢谢！

引子：窗口越做越大，"全塞进去"是不是终局？

上下文窗口这两年涨得很快，从几千 token 到几十万，个别模型报到百万级。于是常有同一个判断：既然一次能把整库塞进去，前面九篇讲的解析、切分、混合检索、重排、门禁，是不是迟早一起进博物馆？

这个判断值得认真算一遍，而不是跟着参数表走。它至少混了三件事：塞不塞得下、塞进去质量会不会掉、塞进去的账划不划算。三件事的答案不一样，合起来才是"检索会不会消失"。

一、"检索会消失"这句话，拆开是哪三个前提？

把这句口号拆成可判定的前提，才谈得上验。它其实同时假设了三件事：

前提	字面意思	现状	判定口径
装得下	整库 token 不超过窗口	12k 页约 600 万 token，超当前最长窗口	窗口上限 vs 语料规模
划得来	全塞成本不高于检索	随规模线性涨，检索几乎不涨	成本交叉点（第二节）
用得好	全塞不损失答案质量	中间位置信息会被稀释	质量对照（第四节）

三条里只要有一条不成立，"取代"就只是局部成立。装得下这条最先露馅：topo_docs 一万两千条目加上 runbook，按每页约 500 token 估，是 600 万 token 量级，比当前任何模型的窗口都长一到两个数量级。全塞在这套语料上压根不是"贵不贵"，是"根本塞不进"。

后两条更值得算。先把比较口径固定下来，避免各说各话：

json 复制代码

{
  "corpus_pages": 12000,
  "tokens_per_page": 500,
  "queries_per_day": 4000,
  "topk_tokens": 2000,
  "price_input_usd_per_m": 3.00,
  "price_embed_usd_per_m": 0.02,
  "price_output_usd_per_m": 15.00,
  "output_tokens": 300,
  "retrieve_overhead_usd": 0.0001,
  "note": "单价为经验值，非公开报价；embedding 与输出单价沿用全簇统一口径"
}

1.1 为什么用"单次成本"而不是"总拥有成本"

全塞没有索引，成本全在每次查询的输入上；检索要先花一次性的索引费，之后每次只把取回的小块送进模型。两种成本结构不同，直接比一次性的总数不公平，得放到同一个"查询次数"坐标上比。下面的脚本就是干这件事：给定规模，算单次成本，再算打平点。
#mermaid-svg-6ZPSblgqzy2w6Hl6{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .error-icon{fill:#552222;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .marker.cross{stroke:#333333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 p{margin:0;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .cluster-label text{fill:#333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .cluster-label span{color:#333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .cluster-label span p{background-color:transparent;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .label text,#mermaid-svg-6ZPSblgqzy2w6Hl6 span{fill:#333;color:#333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .node rect,#mermaid-svg-6ZPSblgqzy2w6Hl6 .node circle,#mermaid-svg-6ZPSblgqzy2w6Hl6 .node ellipse,#mermaid-svg-6ZPSblgqzy2w6Hl6 .node polygon,#mermaid-svg-6ZPSblgqzy2w6Hl6 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .rough-node .label text,#mermaid-svg-6ZPSblgqzy2w6Hl6 .node .label text,#mermaid-svg-6ZPSblgqzy2w6Hl6 .image-shape .label,#mermaid-svg-6ZPSblgqzy2w6Hl6 .icon-shape .label{text-anchor:middle;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .rough-node .label,#mermaid-svg-6ZPSblgqzy2w6Hl6 .node .label,#mermaid-svg-6ZPSblgqzy2w6Hl6 .image-shape .label,#mermaid-svg-6ZPSblgqzy2w6Hl6 .icon-shape .label{text-align:center;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .node.clickable{cursor:pointer;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .arrowheadPath{fill:#333333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-6ZPSblgqzy2w6Hl6 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-6ZPSblgqzy2w6Hl6 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-6ZPSblgqzy2w6Hl6 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .cluster text{fill:#333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .cluster span{color:#333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-6ZPSblgqzy2w6Hl6 rect.text{fill:none;stroke-width:0;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .icon-shape,#mermaid-svg-6ZPSblgqzy2w6Hl6 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .icon-shape p,#mermaid-svg-6ZPSblgqzy2w6Hl6 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .icon-shape .label rect,#mermaid-svg-6ZPSblgqzy2w6Hl6 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-6ZPSblgqzy2w6Hl6 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-6ZPSblgqzy2w6Hl6 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-6ZPSblgqzy2w6Hl6 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 检索会消失？
装得下吗

窗口 vs 语料
划得来吗

成本交叉点
用得好吗

质量对照
当前最长窗口

仍小于大库规模
第二节算账
第四节质量

二、全塞与检索的成本交叉点，算出来是多少？

数据结构约定：两个成本函数吃同一组参数------full_context_cost(pages, queries) 每次查询都把整库 pages × tokens_per_page 个 token 送进模型；retrieval_cost(pages, queries) 先付一次性的 pages × tokens_per_page × price_embed，之后每次只送 topk_tokens 个取回块。两者的输出 token 相同，会在比较时约掉。

参数含义：tokens_per_page=500 与 topk_tokens=2000 是这套语料的经验量纲------检索取回约八个块。price_input=3.00 是输入单价经验值，price_embed=0.02 与 price_output=15.00 沿用全簇统一口径，避免各篇各报一套。retrieve_overhead 是每次检索的固定开销，量级很小，留着是为了让公式不退化。

建模取舍：交叉点用"固定查询次数、解语料页数"，而不是反过来解查询次数。因为真正要回答的是"多大的库该检索"，不是"查几次才回本"。另外 critical_pages 里刻意把输出成本两边都扣掉------两边都要生成同样长度的答案，这项不影响谁更贵。

python 复制代码

# cost_crossover.py ------ 算「全塞长上下文」与「检索」的成本交叉点
import sys
sys.stdout.reconfigure(encoding="utf-8")

TOKENS_PER_PAGE = 500        # 每页约 500 token（工程经验值）
TOPK_TOKENS = 2000           # 检索只取 top-8 块，约 2000 token
PRICE_INPUT = 3.00           # 输入单价 USD/M token（经验值）
PRICE_EMBED = 0.02           # embedding 单价 USD/M token（簇内统一口径）
PRICE_OUTPUT = 15.00         # 生成输出单价 USD/M token（簇内统一口径）
OUTPUT_TOKENS = 300          # 每次答案约 300 token
RETRIEVE_OVERHEAD = 0.0001   # 每次检索的固定开销 USD（经验值）

def full_context_cost(pages, queries):
    """全塞：每次查询都把整库作为输入，无索引成本；成本随规模×频次线性涨。"""
    input_tok = pages * TOKENS_PER_PAGE * queries
    out_tok = queries * OUTPUT_TOKENS
    return input_tok / 1e6 * PRICE_INPUT + out_tok / 1e6 * PRICE_OUTPUT

def retrieval_cost(pages, queries):
    """检索：一次性建索引 + 每次只把 top-k 块作为输入，成本与语料规模弱相关。"""
    index_cost = pages * TOKENS_PER_PAGE / 1e6 * PRICE_EMBED
    input_tok = queries * TOPK_TOKENS
    out_tok = queries * OUTPUT_TOKENS
    return (index_cost + input_tok / 1e6 * PRICE_INPUT
            + out_tok / 1e6 * PRICE_OUTPUT + queries * RETRIEVE_OVERHEAD)

def critical_pages(queries):
    """固定查询次数，求全塞与检索成本打平时的语料页数；低于它全塞省，高于则检索省。"""
    pi = PRICE_INPUT / 1e6
    pe = PRICE_EMBED / 1e6
    per_q_retrieve = TOPK_TOKENS * pi + RETRIEVE_OVERHEAD
    denom = TOKENS_PER_PAGE * (queries * pi - pe)
    if denom <= 0:
        return None
    return queries * per_q_retrieve / denom

def main():
    print("规模(页)  全塞单次USD  检索单次USD  全塞/检索")
    rt1 = (TOPK_TOKENS / 1e6 * PRICE_INPUT + RETRIEVE_OVERHEAD
           + OUTPUT_TOKENS / 1e6 * PRICE_OUTPUT)
    for pages in (4, 20, 200, 2000, 12000):
        fc1 = full_context_cost(pages, 1)
        print("%-9d %-12.4f %-12.4f %.1f 倍"
              % (pages, fc1, rt1, fc1 / rt1))
    print("\n临界语料页数（超过它就该检索）：")
    for q in (1, 10, 100, 1000, 10000):
        print("  查询 %-6d 次 → %.2f 页" % (q, critical_pages(q)))
    pages, per_day, days = 12000, 4000, 30
    queries = per_day * days
    fc = full_context_cost(pages, queries)
    rt = retrieval_cost(pages, queries)
    print("\n%d 页 / %d 次查询每月：全塞 %.0f USD，检索 %.0f USD，相差 %.0f 倍"
          % (pages, queries, fc, rt, fc / rt if rt else 0))

if __name__ == "__main__":
    main()

2.1 逐段读这份脚本

full_context_cost 只有一个乘积：规模乘频次再乘输入单价。它没有任何与查询次数无关的固定项，所以查询越多、库越大，成本同比往上走，没有摊薄效应。

retrieval_cost 拆成三段：一次性索引、每次取回块的输入、生成输出。关键在第二段------输入量是常数 TOPK_TOKENS，不随 pages 变。库从两百页涨到一万两千页，这一分钱都不多花。

critical_pages 解的是 full_context_cost == retrieval_cost 这个方程。输出项在两边相同，被约掉；剩下的式子里，输入单价同时出现在两边。这正是下一节要展开的那个反直觉结论。

两处已知偏差。其一，tokens_per_page=500 是粗估，PDF 表格密集的页会明显超出，交叉点会随之下移。其二，脚本没有给"全塞"记一笔质量损失，只算钱------那是第四节要补的账，不能混进成本里假装它不存在。

运行结果（本机实跑，Python 3.13）：

text 复制代码

规模(页)  全塞单次USD  检索单次USD  全塞/检索
4         0.0105       0.0106       1.0 倍
20        0.0345       0.0106       3.3 倍
200       0.3045       0.0106       28.7 倍
2000      3.0045       0.0106       283.4 倍
12000     18.0045      0.0106       1698.5 倍

临界语料页数（超过它就该检索）：
  查询 1      次 → 4.09 页
  查询 10     次 → 4.07 页
  查询 100    次 → 4.07 页
  查询 1000   次 → 4.07 页
  查询 10000  次 → 4.07 页

12000 页 / 120000 次查询每月：全塞 2160540 USD，检索 1272 USD，相差 1698 倍

一万两千页、每天四千次查询，一个月下来全塞要两百多万美元，检索一千多美元，差约一千七百倍。这个数字大到不用讨论"要不要省"，但真正有意思的是下面那组页数。

三、临界页数为什么和上下文单价无关？

把打平方程写出来，结论会自己浮出来。设语料 N 页、查询 q 次、每页 t 个 token、输入单价 π、检索取回 k 个 token：

text 复制代码

全塞侧：q × N × t × π
检索侧：N × t × pe + q × k × π        （pe 为 embedding 单价，输出项两边相同已约掉）
打平时：q × N × t × π ≈ q × k × π     （pe 与固定开销相对极小）
两边约去 q × π：N × t ≈ k
         → N ≈ k / t = 2000 / 500 = 4 页

输入单价 π 在两侧同现，被约掉了。"等上下文再便宜一点就不用检索了"于是成了算错的账：降价同时压低全塞和检索的输入成本，交叉点不跟着动。 能移动交叉点的只有两样------检索每次取回多少 token（k），以及每页实际多少 token（t）。k 与 t 都是这套语料和这个任务的属性，不是模型厂商能靠降价改的。

那组 4.07 页就是这么来的：它几乎等于"一个 top-k 窗口能装下几页"。查询次数从 1 涨到 10000，临界页数只从 4.09 挪到 4.07，因为决定它的是 k/t，不是 q。

一句话判断：只要检索仍然是"取一个远小于全库的子集"，全塞的成本就必然在语料超过那个子集规模时反超，而且这个反超点与上下文单价的涨跌无关。 要让一万两千页的库变成"全塞更省"，检索得取回接近整整一个库的量------那已经不叫检索了，只是换了个名字的全塞。

这还只是成本账。第一节那条"装得下"的前提，在这套语料上本来就不成立，所以上面的对照其实是给全塞开了一个物理上做不到的优惠：假设窗口能装下六百万 token。放宽到这个程度它都输了，真实约束只会更严。

这个约法有三处会失效。其一，若检索不再是取一个小子集------多跳、多路各取一大把、或反复取回重排------k 会显著变大，交叉点右移，全塞的相对劣势收窄。其二，约掉 π 的前提是 embedding 单价 pe 相对输入单价可忽略；若索引要频繁重建、要维护多版本快照，pe 项不再能丢，近似就不成立。其三，答案生成得很长时输出成本占比上升，而它在两侧相同、本就被约掉，省钱的主战场会从输入转移到别处。三处都不推翻主结论，只框定它的适用宽度。
#mermaid-svg-6AI3ob5PzmzNaWQC{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-6AI3ob5PzmzNaWQC .error-icon{fill:#552222;}#mermaid-svg-6AI3ob5PzmzNaWQC .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-6AI3ob5PzmzNaWQC .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-6AI3ob5PzmzNaWQC .marker{fill:#333333;stroke:#333333;}#mermaid-svg-6AI3ob5PzmzNaWQC .marker.cross{stroke:#333333;}#mermaid-svg-6AI3ob5PzmzNaWQC svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-6AI3ob5PzmzNaWQC p{margin:0;}#mermaid-svg-6AI3ob5PzmzNaWQC .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-6AI3ob5PzmzNaWQC .cluster-label text{fill:#333;}#mermaid-svg-6AI3ob5PzmzNaWQC .cluster-label span{color:#333;}#mermaid-svg-6AI3ob5PzmzNaWQC .cluster-label span p{background-color:transparent;}#mermaid-svg-6AI3ob5PzmzNaWQC .label text,#mermaid-svg-6AI3ob5PzmzNaWQC span{fill:#333;color:#333;}#mermaid-svg-6AI3ob5PzmzNaWQC .node rect,#mermaid-svg-6AI3ob5PzmzNaWQC .node circle,#mermaid-svg-6AI3ob5PzmzNaWQC .node ellipse,#mermaid-svg-6AI3ob5PzmzNaWQC .node polygon,#mermaid-svg-6AI3ob5PzmzNaWQC .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-6AI3ob5PzmzNaWQC .rough-node .label text,#mermaid-svg-6AI3ob5PzmzNaWQC .node .label text,#mermaid-svg-6AI3ob5PzmzNaWQC .image-shape .label,#mermaid-svg-6AI3ob5PzmzNaWQC .icon-shape .label{text-anchor:middle;}#mermaid-svg-6AI3ob5PzmzNaWQC .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-6AI3ob5PzmzNaWQC .rough-node .label,#mermaid-svg-6AI3ob5PzmzNaWQC .node .label,#mermaid-svg-6AI3ob5PzmzNaWQC .image-shape .label,#mermaid-svg-6AI3ob5PzmzNaWQC .icon-shape .label{text-align:center;}#mermaid-svg-6AI3ob5PzmzNaWQC .node.clickable{cursor:pointer;}#mermaid-svg-6AI3ob5PzmzNaWQC .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-6AI3ob5PzmzNaWQC .arrowheadPath{fill:#333333;}#mermaid-svg-6AI3ob5PzmzNaWQC .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-6AI3ob5PzmzNaWQC .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-6AI3ob5PzmzNaWQC .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-6AI3ob5PzmzNaWQC .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-6AI3ob5PzmzNaWQC .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-6AI3ob5PzmzNaWQC .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-6AI3ob5PzmzNaWQC .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-6AI3ob5PzmzNaWQC .cluster text{fill:#333;}#mermaid-svg-6AI3ob5PzmzNaWQC .cluster span{color:#333;}#mermaid-svg-6AI3ob5PzmzNaWQC div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-6AI3ob5PzmzNaWQC .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-6AI3ob5PzmzNaWQC rect.text{fill:none;stroke-width:0;}#mermaid-svg-6AI3ob5PzmzNaWQC .icon-shape,#mermaid-svg-6AI3ob5PzmzNaWQC .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-6AI3ob5PzmzNaWQC .icon-shape p,#mermaid-svg-6AI3ob5PzmzNaWQC .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-6AI3ob5PzmzNaWQC .icon-shape .label rect,#mermaid-svg-6AI3ob5PzmzNaWQC .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-6AI3ob5PzmzNaWQC .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-6AI3ob5PzmzNaWQC .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-6AI3ob5PzmzNaWQC :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 全塞成本

∝ 规模 × 频次 × 单价
比较交叉点
检索成本

∝ 频次 × 取回量 × 单价
单价 π 两边约掉
临界页数 ≈ 取回量 ÷ 每页密度
≈ 4 页

与单价无关

四、成本账之外，全塞的质量真的一定更好吗？

成本模型默认了全塞和检索给出一样好的上下文，这个默认本身可疑。一个方向是"全塞信息全，所以更准"，另一个方向是"信息太多，关键的被淹了"。后者有公开证据：长上下文里，模型对开头和结尾的位置利用得更好，落在中间的内容更容易被忽略。

这件事对 Agent 知识尤其要命。处置一个告警要的证据往往就一两条，塞进整库之后，这一两条从"排在最前的候选"变成"几百万 token 中间的某一处"。检索做的排序、去噪、符号保底，本质都是在跟这个稀释效应抢位置。

维度	全塞	检索	谁占优
信息完整性	理论全在窗口	取决于召回，会漏	全塞（若装得下）
关键证据位置	淹没在中部	重排到前列	检索
时效	构建时快照，会过期	每次可查最新	检索
冲突处理	两个说法并排塞入	可显式仲裁	检索
可溯源	难定位到具体片段	天生带片段 id	检索

所以"全塞更准"只在两类任务上比较站得住：需要跨全文归纳的问题，以及库小到确实塞得下、且答案本来就没有单一证据点的问题。

结论要收窄一点说：在"从大库里定位少数证据"这类任务上，全塞既装不下、也更贵，质量还不见得更好；在"通读全文做归纳"这类任务上，全塞才可能对。 取代不会整体发生，会按任务类型分层发生。

五、还有哪四个问题没解开？

"检索不会整体消失"这个判断，靠的是成本结构和任务类型；但下一代知识工程长什么样，还有四处是真空。列出来不是为了凑数，是标出哪些地方现在给不出可靠答案。

5.1 有效窗口怎么度量和计价

标称窗口一百万 token，不等于一百万 token 都被有效利用。中间位置的信息会被稀释，可稀释多少随任务、随位置、随文档结构变化，目前没有一个统一口径能把"标称窗口"折算成"有效窗口"。折算不出来，第一节那张成本表里的"装得下"就只能按最乐观的物理上限填，真实可用量更小。可证伪的进展信号是：出现一个跨任务稳定、能预测答案质量随位置衰减的度量。

5.2 全塞与检索的质量边界能不能先验判定

现在是事后 A/B：同一个任务两套都跑，看哪个好。缺的是一个拿到问题就能判断"这题该通读还是该定位"的先验判据，比如依据问题的信息跨度、证据点数量、是否要跨文档归纳。判据做不出来，工程上就只能两套都备着、按查询类型硬分流，这正是查询理解那一层在做的事，只是分流规则仍是经验值。

5.3 时效与冲突在全塞范式下怎么等价实现

检索能每次查最新、能对两个冲突源显式仲裁；全塞是构建时的一张快照，天然会过期，冲突的两个说法还会并排进窗口。若未来某个任务真的走全塞，前面讲的时效巡检与冲突仲裁要怎么等价地做------增量重灌？重灌频率一高，成本账又翻回去。这块目前没有干净的答案。

5.4 知识质量能不能脱离下游任务单独度量

整个簇都在用"处置动作准确率"倒推知识质量，这是间接的、被模型能力混淆的：模型变强会抬准确率，跟知识有没有变好无关。检索层有 recall@k 这种直接指标，可它与最终答案质量的相关性又不稳定。缺的是一个直接度量知识质量、且与答案质量强相关的量。它做不出来，"这个改动到底是不是知识变好了"就只能一直靠下游实验间接猜。可证伪的进展信号是：出现一个不依赖具体下游任务、却与答案质量稳定相关的知识侧指标------像检索层的 recall@k 那样直接，又不像它那样与答案质量若即若离。

四个问题的共同点：都不是"再调调参数"，而是缺一个可复用的度量或判据。度量没补上之前，展望只能是方向，落不成路线图。

六、下一程会变成什么样？

把成本结构和四个未解问题放一起，能给出一个收窄的预测：知识工程的重心会从"怎么把库索引好、取回准"，往"Agent 自己决定要不要取、取几次、取回来信不信"移动。检索不会消失，但会从一条固定的被动管道，变成一个被调度的动作。

这个变化其实在簇内已经有苗头：查询理解在做分流，引用验证在做"取回来之后敢不敢信"，门禁在做"改动之后会不会退化"。把它们连起来看，是一条从"检索作为一步"到"检索作为被 Agent 调度的能力"的线。
#mermaid-svg-RXl5p2d8uqIDmHFU{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-RXl5p2d8uqIDmHFU .error-icon{fill:#552222;}#mermaid-svg-RXl5p2d8uqIDmHFU .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-RXl5p2d8uqIDmHFU .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-RXl5p2d8uqIDmHFU .marker{fill:#333333;stroke:#333333;}#mermaid-svg-RXl5p2d8uqIDmHFU .marker.cross{stroke:#333333;}#mermaid-svg-RXl5p2d8uqIDmHFU svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-RXl5p2d8uqIDmHFU p{margin:0;}#mermaid-svg-RXl5p2d8uqIDmHFU .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-RXl5p2d8uqIDmHFU .cluster-label text{fill:#333;}#mermaid-svg-RXl5p2d8uqIDmHFU .cluster-label span{color:#333;}#mermaid-svg-RXl5p2d8uqIDmHFU .cluster-label span p{background-color:transparent;}#mermaid-svg-RXl5p2d8uqIDmHFU .label text,#mermaid-svg-RXl5p2d8uqIDmHFU span{fill:#333;color:#333;}#mermaid-svg-RXl5p2d8uqIDmHFU .node rect,#mermaid-svg-RXl5p2d8uqIDmHFU .node circle,#mermaid-svg-RXl5p2d8uqIDmHFU .node ellipse,#mermaid-svg-RXl5p2d8uqIDmHFU .node polygon,#mermaid-svg-RXl5p2d8uqIDmHFU .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-RXl5p2d8uqIDmHFU .rough-node .label text,#mermaid-svg-RXl5p2d8uqIDmHFU .node .label text,#mermaid-svg-RXl5p2d8uqIDmHFU .image-shape .label,#mermaid-svg-RXl5p2d8uqIDmHFU .icon-shape .label{text-anchor:middle;}#mermaid-svg-RXl5p2d8uqIDmHFU .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-RXl5p2d8uqIDmHFU .rough-node .label,#mermaid-svg-RXl5p2d8uqIDmHFU .node .label,#mermaid-svg-RXl5p2d8uqIDmHFU .image-shape .label,#mermaid-svg-RXl5p2d8uqIDmHFU .icon-shape .label{text-align:center;}#mermaid-svg-RXl5p2d8uqIDmHFU .node.clickable{cursor:pointer;}#mermaid-svg-RXl5p2d8uqIDmHFU .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-RXl5p2d8uqIDmHFU .arrowheadPath{fill:#333333;}#mermaid-svg-RXl5p2d8uqIDmHFU .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-RXl5p2d8uqIDmHFU .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-RXl5p2d8uqIDmHFU .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-RXl5p2d8uqIDmHFU .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-RXl5p2d8uqIDmHFU .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-RXl5p2d8uqIDmHFU .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-RXl5p2d8uqIDmHFU .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-RXl5p2d8uqIDmHFU .cluster text{fill:#333;}#mermaid-svg-RXl5p2d8uqIDmHFU .cluster span{color:#333;}#mermaid-svg-RXl5p2d8uqIDmHFU div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-RXl5p2d8uqIDmHFU .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-RXl5p2d8uqIDmHFU rect.text{fill:none;stroke-width:0;}#mermaid-svg-RXl5p2d8uqIDmHFU .icon-shape,#mermaid-svg-RXl5p2d8uqIDmHFU .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-RXl5p2d8uqIDmHFU .icon-shape p,#mermaid-svg-RXl5p2d8uqIDmHFU .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-RXl5p2d8uqIDmHFU .icon-shape .label rect,#mermaid-svg-RXl5p2d8uqIDmHFU .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-RXl5p2d8uqIDmHFU .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-RXl5p2d8uqIDmHFU .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-RXl5p2d8uqIDmHFU :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 固定检索管道

解析→切分→召回→重排
加验证与门禁

引用·时效·冲突·回归
按查询类型分流

该取才取
Agent 主动调度

决定取不取·取几次
失血点重新分布

从取不取到信不信

值得留个警觉：调度权交给模型之后，前面九处失血点不会消失，只会换位置。取不取、取几次的决策本身会变成新的失血面------该取没取就是漏召，取太多又是噪声和成本。这也是为什么"检索会消失"这个问法本身有点偏：它假设失血能被消灭，而实际发生的是失血从管道迁移到决策。

落到工程上，这个转变要补两样东西：

给检索调用本身上门禁和预算：模型可以决定取零次、一次或多次，就得有人管住「最多几次、单次多少 token、超预算怎么降级」，否则一个爱取的模型能把检索的成本优势亲手花光------这正是管道门禁那一层要迁移过去的东西。
让新失血点可度量：该取没取就是漏召，取太多就是噪声加成本，两个数恰好是混合检索那篇已经在采的指标。

换范式不换指标，是这次迁移里少见的便宜事。

七、小结

检索不会消失，因为成本交叉点与单价无关、只由"取回量相对全库有多小"决定；只要还要从大库里定位少数证据，检索就一直比全塞划算。

四个未解问题留给下一程------有效窗口的度量、全塞与检索的先验判据、时效与冲突的等价实现、知识质量的直接度量。它们都不是调参能解的，缺的是可复用的尺子。

全系列从"知识放错了层"走到"管道也要发版"，再到这里算清"这条路会不会被取代"，到此收束。九处失血点的落地顺序回看 10 篇，三条阅读路线与全簇存疑清单回看【00 系列导航】。若只带走一件事，那就是：先把要修的东西量出来，再决定先修哪一处。

参考

Retrieval Augmented Generation or Long-Context LLMs?（全塞与检索成本、质量对照的直接依据）
Lost in the Middle: How Language Models Use Long Contexts（第四节"关键证据被中部稀释"的公开证据）
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（检索作为知识注入路径的立论起点）
Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection（检索从被动管道转向主动调度的代表工作）