八月上旬 Qwen 团队放了 Qwen3.8-Max：2.4T 总参、约 95B 激活，云上先用，并放话会开源同级权重。博客里反复强调的不是又刷一条榜，而是 Hybrid Agent——代码改仓库和 GUI 操作电脑两条通路绑在一起，长任务要能交出「可验收的交付物」。
同一时期，RAG 圈的主流说法几乎收敛成一句：纯向量检索不够用，Hybrid（向量 + BM25/关键词）+ 融合（常见是 RRF） 才是默认。两件事看起来一个在模型、一个在检索，其实卡在同一个工程问题上：系统什么时候该「算」，什么时候该「查」，查完又怎么合并。
模型变强，不会自动修好检索
我见过太多这样的升级路径：换更大模型 → 提示词加长 → 幻觉换了一种文风继续出现。根因经常是上下文里根本没有那条 SKU、那条法规编号、那个内部函数名。语义近邻找得到「类似退货政策」，找不到 POL-17-B 这种必须精确命中的符号。
BM25 / 关键词通道就是干这个的。向量负责「意思靠近」，词法通道负责「字符串就该在」。2026 年还把「只 embed 切一刀」当生产默认，属于主动给自己挖坑。
RRF：懒而稳的融合
Reciprocal Rank Fusion 不碰原始分值，只看各通道里的名次：
[
\mathrm{RRF}(d)=\sum_{r\in R}\frac{1}{k+\mathrm{rank}_r(d)}
]
k 一般取 60 左右。好处是向量和 BM25 的分数量纲可以完全不同，你不用先做一场玄学标定。坏处也明显：它不理解业务权重。若合规场景「标题命中法条」必须压过「语义很像的旧解读」，你要在 RRF 之前加过滤，或在之后用业务规则重排，别指望一个公式通吃。
query
├─ dense retriever → top 50
├─ bm25 / keyword → top 50
└─ (可选) 元数据过滤：租户 / 时间 / ACL
↓
RRF merge → top 20
↓
cross-encoder / 小模型 rerank → top 6
↓
拼进 prompt（带引用锚点）
Qdrant、OpenSearch、各类自建方案都在把这条链路当模板。重点不是选哪个 logo，而是两路召回是否真的在线、融合是否可观测。
Hybrid Agent 和 Hybrid Search 是同一类分层
Qwen3.8-Max 讲的 Hybrid Agent，是 coding channel 和 GUI channel 互补：该改文件就改文件，该点界面就点界面。工程上我会把它映射成和检索一样的门禁：
| 层 | 检索侧 | Agent 侧 |
|---|---|---|
| 路由 | 要不要检索、检索哪些库 | 用代码工具还是电脑操作 |
| 并行召回 | dense + lexical | 多工具同时试探 |
| 融合 | RRF / 加权 | 以可验证结果为准，不看谁先说话 |
| 重排 | rerank、引用 | 测试、截图、diff、人工门禁 |
| 降级 | 检索失败就拒答或追问 | 工具失败就停，不编造「已完成」 |
模型参数再大，也不该拥有「跳过证据」的特权。Agent 写完代码如果没有测试输出或 GUI 前后对比，那只是散文，不是交付。
我会怎么改现有 RAG
1. 召回日志先于 prompt 调优。 每次回答留下：两路 topK、RRF 后列表、最终进上下文的 chunk id。用户说「答错了」时，先看是没召回还是召回了但模型没用。
2. 符号字段单独建词法索引。 订单号、错误码、类名、配置键，别只靠 embedding。必要的话查询前做一次正则/词典抽出，强制走 keyword 通道。
3. chunk 策略按文档类型分。 API 文档按 endpoint 切；政策按条款切；代码按符号+调用邻域切。统一 512 tokens 一切，是最省事也最容易在关键处切断的办法。
4. 引用是产品，不是装饰。 前端把 doc_id + 锚点 点得开。模型被要求「无引用则说不知道」，比「请尽量准确」有用。
图：两路召回合并后再重排，比单路把 topK 开到 100 更可控
和「开源同级权重」一起想的运维问题
Qwen 放话开源 Max 级权重，会让更多团队把强模型抱回私有集群。那时候贵的不是卡，是错误的自动化：
- 夜间 Agent 改配置，没有 diff 审查
- RAG 索引日更，没有查询回归集
- GUI 操作跑在真实工单系统上，没有 shadow 环境
我的最低配法：固定 50～100 条「必须答对 / 必须拒答」的题；每次改 embedding、改融合参数、换模型，先跑这套。Agent 写权限和检索写权限一样，默认只读，显式提升。
一个最小可上线的 Hybrid 骨架
不必一上来上图数据库。很多业务先这样跑就够：
- 文档入湖时同时写：向量索引 + 全文索引（同一
doc_id） - 查询时两路各取 30～50，RRF 合成 15，再重排到 4～8 段
- Prompt 里强制：
依据 [n] …；若依据不足则说明缺什么 - 在线打点：
hit_dense/hit_bm25/used_citations/user_feedback
跑两周你会看到一类刺眼的数据：dense 命中很高、bm25 命中很低，但差评集中在「编号/型号说错」。那不是模型笨，是词法通道权重或分词器有问题。另一类相反：bm25 很猛，回答像关键词堆砌——该加语义通道或重排模型了。
Hybrid Agent 同理。只给 coding 工具时，它会用脚本硬刚本该点的后台按钮；只给 GUI 时，它会在页面上慢慢点本该一行 API 解决的事。路由层要根据「是否有稳定 API / 是否有测试钩子」做偏向，而不是让模型自由发挥酷炫操作。
小结
Qwen3.8-Max 把 Hybrid Agent 推到台前，RAG 实践把 Hybrid Search 写成默认。两边都在说：单一通道不可信，合并规则要显式，输出要能验收。
如果你这周只能做一件事，别先追新模型。把现有向量检索旁边加一条 BM25，用 RRF 融一下，把召回列表打进日志。模型和 Agent 再怎么 Hybrid，也得踩在还能被你看见的证据上。
