RAG 多取文档的成本应与效果一起评估

把文档问答机器人的检索数量从 5 调到 20，测试题答对了，账单也可能涨到原来的 2.7 倍。问题在于，top_k 写在检索配置里，费用却发生在模型调用时，很容易被当成纯粹的搜索参数。

作者用一组假设演算提醒我们：RAG 的上下文长度也是成本配置。控制费用不能只靠换便宜模型，还要决定哪些检索结果值得送进去。不过，标题里的倍数来自固定条件下的计算，并非线上实测。

为什么多取 15 段，费用会涨到 2.7 倍

RAG（检索增强生成）会先搜索自己的文档，再把相关内容拼进提示词。文档预先切成若干片段，也就是 chunk；检索器为片段打分，top_k 决定取排名靠前的多少段。

模型按 token 收费。作者用一个 token 约等于四分之三个英文单词帮助理解，这个比例不能直接套到中文。

演算设定是：指令加问题共 400 tokens，每段文档 500 tokens，回答固定为 250 tokens。作者明确说，这些是典型默认值的假设，不是测量结果。

价格采用作者所参与的 LLM gateway 在 2026 年 11 月 6 日读取的目录：GPT-5.6 每百万输入 tokens 为 2 美元，输出为 12 美元。以下金额都依赖这一价格口径。

top_k	输入 tokens	每次回答费用
3	1,900	0.0068 美元
5	2,900	0.0088 美元
10	5,400	0.0138 美元
20	10,400	0.0238 美元

从 5 到 20，费用约为原来的 2.70 倍。按每天 10,000 个问题、每月 30 天计算，每多放一段就增加 0.001 美元，每月增加 300 美元；多放 15 段，就是每月增加 4,500 美元。

用户读到的回答仍然只有 250 tokens。那个约十几个 tokens 的简短问题，在 top_k = 5 时只占账单约 0.3%。

换便宜模型，为什么还要管检索数量

作者把相同 token 数量代入五个模型的价格：GPT-5.6 和 GPT-5.6-mini 的费用比都是 2.70 倍；Claude Haiku 5.5、Claude Sonnet 5.5 和 Gemini 3.8 Flash 则是 2.81 倍。

GPT-5.6-mini 的月费从 264 美元升到 714 美元。绝对金额小了，增长比例仍然接近。

原因是输入规模没有改变。只要文档片段已经占据主要开销，多塞上下文就会持续增加费用。

换模型降低单价，少放文档减少用量，两件事可以同时做。

不过，「倍数与供应商无关」不能理解为任何模型都精确上涨 2.7 倍。输入、输出单价的比例仍然影响结果，原文的 2.70 和 2.81 已经体现了这种差异。

比固定取几段更实用的，是上下文预算

固定 top_k 不关心前两段是否已经够用，也不区分一段是 300 tokens 还是 900 tokens。作者建议设置两道限制：相关性分数低于阈值就停止，累计上下文超过 token 预算也停止。

下面这段代码放在搜索结果与提示词拼装之间，用来挑选最终发送给模型的片段：

import tiktoken
enc = tiktoken.get_encoding("o200k_base")   # an OpenAI tokenizer; others count a bit differently

def pick_chunks(ranked, budget=2_000, min_score=0.5):
    """ranked: (text, score) pairs from your search, best match first."""
    picked, used = [], 0
    for text, score in ranked:
        n = len(enc.encode(text))
        if score < min_score or used + n > budget:
            break
        picked.append(text)
        used += n
    return picked

要看清 break 那一行：遇到装不下的片段会直接结束，不会继续寻找后面更短的片段。输入 ranked 也必须按相关性从高到低排列。

检索器仍可取 20 个候选，再从中筛选。作者认为搜索便宜，主要支出在于把文本送进模型；原文没有进一步量化搜索费用。

在前述 400 tokens 固定输入、250 tokens 输出不变的条件下，把文档预算设为 2,000 tokens，GPT-5.6 每次费用最高约为 0.0078 美元。这个上限依赖回答长度等假设。

min_score=0.5 只是占位值。不同 embedding 模型的分数含义不同，不能照抄。o200k_base 是 OpenAI tokenizer，其他模型的计数也可能有差异。

我的判断

我认同把 top_k 当成价格参数来管理。它会改变模型输入长度，配置调整时就应该同时看答案质量和费用。

但文章提供的是成本演算，没有给出回答准确率的对照实验。它证明了特定输入规模下会多花多少钱，没有证明减少上下文后质量一定不变。

如果正确段落排在第 12 位，预算可能把它挡掉。作者因此建议先用几十个真实问题，检查有用片段进入前三或前五的频率，再考虑收紧预算。改进切分和搜索通常比继续堆上下文更合理，这是作者的经验判断，原文没有提供比较数据。

固定 top_k 实现简单，适合片段大小接近的场景；token 预算更贴近计费方式，但需要计数和阈值校准。两者也可以搭配使用。至于 gateway，它只看到拼好的提示词，无法替业务判断哪些片段真正有用。

能拿来做什么

• 给文档问答或客服机器人增加输入 tokens、输出 tokens 和单次费用记录，调整 top_k 时一起比较，别只检查那道失败题是否答对。
• 在检索与提示词拼装之间加入上下文预算，可以先参考原文的 2,000 tokens，但应根据真实问题校准，不能把 min_score=0.5 当成通用配置。
• 收紧预算前，用几十个真实问题检查有效段落的排名；如果经常排在后面，优先排查文档切分与搜索效果，再决定是否增加上下文。