1. 多通道召回后到底该给模型几条一个被低估的工程决策多通道检索返回多条结果最终给模型几条这是 RAG 和 Agent 工具链里最容易被拍脑袋决定的参数。我见过不少项目向量通道召回 10 条、BM25 召回 10 条、元数据过滤再来 10 条三路一合并 30 条候选然后有人图省事直接把 30 条全拼进 prompt理由是“上下文窗口够大让模型自己挑”。实测下来这种做法在真实业务里几乎必然翻车Token 成本翻几倍、首字延迟明显上升模型还会被半相关的旧版本内容带偏答出前后矛盾的结果。多通道的价值在于互补向量通道擅长语义泛化能把“怎么申请报销”匹配到“差旅费用申领指引”BM25 擅长精确命中专有代号、错误码、零件号这类低频词只有它能兜住元数据或图谱通道负责结构化约束比如限定部门、年份、文档类型。三路各自召回 10 条是为了保证召回率宁可多带一些候选也不能漏掉正确答案。但“召回宽”不等于“喂给模型也要宽”中间必须有一道精炼漏斗把 30 条收敛到 5 条左右的高信噪比上下文。这篇就围绕这个决策展开多通道返回多条结果后怎么用去重、RRF 融合、重排序、多样性过滤这几步把最终送入模型的条数稳定控制在预期范围内并给出一套可复制的配置骨架和验证动作。适合正在搭 RAG 检索链路、或者被“召回一堆但答不准”困扰的开发者。2. 用 TaoToken 做多通道链路的统一模型出口多通道检索本身不依赖特定平台但检索完之后要调用大模型做生成或做重排序打分就需要一个稳定的模型出口。TaoToken 在这里的角色是统一 API 网关你可以在同一套配置里切换不同模型用来做重排序打分、做最终生成或者做 Agent 工具链里的中间推理。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。接入前先在控制台创建 API Key控制台地址 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。如果你只是想先验证“多通道召回后给模型几条”这个链路可以直接用模型对话页做小样本测试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。需要说明的是TaoToken 不替代你的向量库、BM25 引擎或图数据库它只负责模型调用这一段。检索通道、去重、融合、重排这些逻辑仍然在你的应用代码里完成。把模型出口统一之后你才能稳定地做“条数实验”同一批候选分别喂 3 条、5 条、8 条观察回答质量和延迟的变化而不是每次换模型都要重写一遍调用代码。3. 可复制的配置骨架config.toml 与 settings.json下面给出一套配置骨架覆盖多通道召回条数、去重策略、RRF 参数、重排序截断和最终送入模型的条数。你可以按自己的技术栈选 TOML 或 JSON 版本字段含义一致。3.1 config.toml 版本[retrieval] # 每个通道各自召回的候选条数 dense_top_k 10 sparse_top_k 10 metadata_top_k 10 # 三路合并后的原始候选上限用于防止某一路异常放大 max_raw_candidates 40 [dedup] # 去重策略doc_id 优先其次内容哈希 strategy doc_id_then_hash # 内容哈希算法用于识别不同 ID 但内容几乎一致的切片 hash_algo simhash # SimHash 汉明距离阈值小于等于该值视为重复 hamming_threshold 3 [fusion] # 倒数排名融合的平滑常数业界常用 60 rrf_k 60 # 参与融合的通道权重可按业务调整 dense_weight 1.0 sparse_weight 1.0 metadata_weight 0.8 [rerank] # 送入交叉编码重排序的候选上限去重后通常 15~25 条 max_candidates 25 # 重排序模型标识 model bge-reranker-base # 最低置信度阈值低于该值直接丢弃 score_threshold 0.35 [final_context] # 最终送入模型的条数这是本篇的核心参数 top_n 5 # 是否启用 MMR 多样性过滤 mmr_enabled true # MMR 中相关性权重1.0 表示纯相关性0.7 表示兼顾多样性 mmr_lambda 0.7 # 单条上下文最大字符数超出截断 max_chars_per_chunk 12003.2 settings.json 版本{ retrieval: { dense_top_k: 10, sparse_top_k: 10, metadata_top_k: 10, max_raw_candidates: 40 }, dedup: { strategy: doc_id_then_hash, hash_algo: simhash, hamming_threshold: 3 }, fusion: { rrf_k: 60, dense_weight: 1.0, sparse_weight: 1.0, metadata_weight: 0.8 }, rerank: { max_candidates: 25, model: bge-reranker-base, score_threshold: 0.35 }, final_context: { top_n: 5, mmr_enabled: true, mmr_lambda: 0.7, max_chars_per_chunk: 1200 } }几个参数需要重点解释。rrf_k取 60 是为了避免排名第一和第二的文档得分差距过大让多通道都靠前的文档获得复合优势。score_threshold是防止“知识库里根本没有答案却硬凑 5 条”的关键如果重排后最高分都低于阈值应该直接返回“未检索到相关内容”而不是强行调用模型。mmr_lambda控制多样性当 Top 3 内容高度重复时调低这个值能让最终 5 条覆盖更多信息维度。3.3 去重与截断的核心逻辑去重分两层先用 doc_id 去掉同一文档块被多个通道重复召回的情况再用 SimHash 去掉不同 ID 但内容几乎一致的冗余切片。30 条原始候选经过这两层通常会收敛到 15 到 25 条。截断则分两次重排序前用max_candidates控制送入重排模型的规模避免交叉编码器算力爆炸重排序后用top_n严格控制最终条数。import hashlib from typing import List, Dict def dedup_by_doc_id(candidates: List[Dict]) - List[Dict]: seen {} for item in candidates: doc_id item[doc_id] if doc_id not in seen: seen[doc_id] item else: # 保留原始分数更高的那条同时累加通道命中信息 if item.get(raw_score, 0) seen[doc_id].get(raw_score, 0): seen[doc_id] item return list(seen.values()) def content_hash(text: str) - str: return hashlib.md5(text.strip().encode(utf-8)).hexdigest() def dedup_by_content(candidates: List[Dict]) - List[Dict]: seen_hashes set() result [] for item in candidates: h content_hash(item[content]) if h not in seen_hashes: seen_hashes.add(h) result.append(item) return result4. 验证动作构造多通道返回样例检查最终 prompt 实际条数配置写完不算完必须验证“最终 prompt 里实际有几条”和“预期条数”一致。下面构造一个三通道各返回若干条的样例跑完整链路打印最终上下文条数。4.1 构造样例数据# 模拟三通道返回故意制造重复和冗余 dense_results [ {doc_id: d1, content: 华东区2025年差旅住宿标准每日不超过450元, raw_score: 0.91, channel: dense, rank: 1}, {doc_id: d2, content: 差旅交通报销细则高铁二等座全额报销, raw_score: 0.88, channel: dense, rank: 2}, {doc_id: d3, content: 华东区2024年旧版住宿上限400元, raw_score: 0.85, channel: dense, rank: 3}, ] sparse_results [ {doc_id: d1, content: 华东区2025年差旅住宿标准每日不超过450元, raw_score: 12.4, channel: sparse, rank: 1}, {doc_id: d4, content: 错误码 ERR-4091-B 代表发票流水号重复, raw_score: 9.8, channel: sparse, rank: 2}, {doc_id: d5, content: 采购审批超过5万元需双签核准, raw_score: 7.2, channel: sparse, rank: 3}, ] metadata_results [ {doc_id: d1, content: 华东区2025年差旅住宿标准每日不超过450元, raw_score: 1.0, channel: metadata, rank: 1}, {doc_id: d6, content: 员工年度体检安排在Q4费用公司承担, raw_score: 0.9, channel: metadata, rank: 2}, ]4.2 跑融合与截断并断言条数def rrf_fuse(all_candidates, k60, weightsNone): weights weights or {dense: 1.0, sparse: 1.0, metadata: 0.8} score_map {} item_map {} for item in all_candidates: doc_id item[doc_id] w weights.get(item[channel], 1.0) contribution w * (1.0 / (k item[rank])) score_map[doc_id] score_map.get(doc_id, 0.0) contribution item_map[doc_id] item fused [] for doc_id, score in score_map.items(): entry dict(item_map[doc_id]) entry[rrf_score] score fused.append(entry) fused.sort(keylambda x: x[rrf_score], reverseTrue) return fused def build_final_context(candidates, top_n5): return candidates[:top_n] # 全链路 raw dense_results sparse_results metadata_results print(f原始候选条数: {len(raw)}) deduped dedup_by_doc_id(raw) deduped dedup_by_content(deduped) print(f去重后条数: {len(deduped)}) fused rrf_fuse(deduped) final build_final_context(fused, top_n5) print(f最终送入模型条数: {len(final)}) assert len(final) 5, 最终条数超过预期 for i, item in enumerate(final, 1): print(f[{i}] {item[doc_id]} rrf{item[rrf_score]:.4f} | {item[content][:30]})运行后你会看到原始 8 条去重后 6 条d1 被三通道重复召回合并为一条最终截断为 5 条。断言通过说明“最终 prompt 实际条数”和配置里的top_n一致。这个验证动作应该固化到 CI 里每次改检索参数都跑一遍。4.3 用 TaoToken 验证模型侧行为检索链路验证完之后把最终 5 条拼成 prompt通过 TaoToken 的 API 发一次真实请求确认模型确实只看到 5 条。API 地址是 https://taotoken.net/api 调用方式兼容常见 SDK 格式。如果你在做长期编码或 Agent 工具链可以了解 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入细节参考文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。import requests API_URL https://taotoken.net/api/v1/chat/completions API_KEY 你的_API_Key context_blocks [f[片段{i}] {item[content]} for i, item in enumerate(final, 1)] prompt 请严格根据以下资料回答资料未提及则回答未提供。\n\n \n.join(context_blocks) \n\n问题华东区2025年差旅住宿一晚最多报销多少 resp requests.post( API_URL, headers{Authorization: fBearer {API_KEY}, Content-Type: application/json}, json{ model: gpt-4o-mini, messages: [{role: user, content: prompt}], temperature: 0.1, }, timeout30, ) print(resp.json()[choices][0][message][content])5. 本篇常见错排查5.1 最终条数超过 top_n最常见的原因是截断发生在去重之前或者去重后没有重新排序就截断。正确顺序是合并 → 去重 → RRF 融合排序 → 重排序 → 截断。任何一步顺序错了都可能让重复内容占满名额导致实际有效条数不足或超出。5.2 三通道分数直接相加向量通道是 0 到 1 的余弦值BM25 是未归一化的几十甚至上百的分值元数据通道可能是跳数权重。直接相加会让 BM25 通道完全主导排序。必须用 RRF 这种基于排名的融合方式或者先做归一化再加权。RRF 的好处是不依赖分数分布跨通道稳定。5.3 重排序模型成为延迟瓶颈交叉编码器对候选数量敏感30 条和 100 条的耗时差距可能是数倍。配置里的max_candidates 25就是控制这个规模。如果延迟仍然高可以先用轻量模型粗排到 15 条再送入重排。另外注意给每个检索通道设超时某个通道抖动时用asyncio.gather的降级逻辑兜住不要让整条链路被一个慢通道拖死。5.4 阈值缺失导致强行凑数如果知识库里没有答案重排后最高分可能只有 0.2但代码仍然截取前 5 条喂给模型模型就会强行编造。加上score_threshold判断最高分低于阈值时直接返回“未检索到相关内容”既省 Token 又避免幻觉。5.5 上下文条数与字符数双重失控只控制条数不够单条切片如果长达 3000 字5 条就是 15000 字。配置里的max_chars_per_chunk要在切片阶段就生效或者在拼 prompt 前做二次截断。建议单条控制在 800 到 1200 字5 条总量在 5000 字以内兼顾信息密度和延迟。6. 把条数决策固化进你的检索链路多通道返回多条结果最终给模型几条本质上是在召回率、精确率、Token 成本和推理延迟之间找平衡点。3 路各召回 10 条、去重融合后 15 到 25 条、重排序后取 Top 5这套骨架在多数 RAG 和 Agent 场景里是稳妥的起点。但起点不等于终点你需要用第 4 节的验证动作在自己的数据上跑一遍看 3 条、5 条、8 条分别对回答质量的影响再决定最终值。配置骨架可以直接复制验证脚本建议放进 CI。模型出口统一到 TaoToken 之后换模型做对比实验的成本会低很多。先把条数这个参数管住再去调切片大小、重排序模型、RRF 权重链路才会一步步收敛到稳定可用的状态。