长上下文模型越来越多，RAG 还有必要做吗？这个问题在开发者圈子里被反复提起。本文要解决的是一个工程判断问题：当模型上下文窗口不断变大，什么场景该直接喂长上下文，什么场景仍需要检索前置，以及多模态场景下检索链路该怎么搭。适合正在做 RAG 系统、多模态检索或成本敏感型推理服务的开发者阅读。
先给判断：至少在需要精确定位、需要控制推理成本、需要结果可追溯的场景里，RAG 没有被取代，而是换了形态——从“文本切片检索”走向“多模态任务级检索”。下面用一个公开的工程实践作为反例展开，再给出可复用的方法与步骤。
为什么长上下文没能直接吃掉 RAG
因为“能装下”和“能稳定找到”是两件事。亚马逊 AWS 官方博客的一篇工程实践（来源：亚马逊AWS官方博客《在长视频里“大海捞针”，用多模态RAG构建无人机炸机分析系统》，该页面未标注发布日期）记录了几轮验证：在当时使用的模型、样本和成本约束下，直接把整段视频交给多模态大模型分析，稳定性不足。当关键事件只占整段视频极小比例时，模型容易被大量正常飞行画面干扰，关键坠毁瞬间可能在长上下文中被遗漏，输出未能稳定命中故障点。
这不是模型不够大，而是信噪比问题。一段几十分钟的飞行监控视频，真正有价值的可能只有几秒。上下文窗口再长，注意力也会被稀释。文章由此提出一个核心设计原则：先定位，再理解。先把“炸机瞬间”这几秒切出来，再交给多模态模型精读。检索的对象从文本片段变成了视频片段。
长上下文改变的是 RAG 的成本结构，不是 RAG 的必要性——上下文越长，越需要先检索把信噪比拉回来。
多模态 RAG 的工程链路
一条可复用的四段式管线：分段、向量化、检索定位、多模态精读。每一段都有明确的取舍。
分段粒度是第一个权衡。分段太长，关键瞬间会被无关画面稀释，回到“喂整段视频”的老问题；分段太短，又会丢失动作上下文，比如一次完整的姿态失控。该 PoC 选择 15 秒作为默认粒度，并做成可配置，方便按场景调参。
向量化是地基。要实现“用一句话检索一段视频”，文本查询和视频片段必须落在同一个语义空间里。如果嵌入模型只能处理单一模态，你就被迫在中间插入“视频转文字描述”的环节，既丢信息又增误差。
检索定位的作用是把上下文从分钟级压缩到秒级。用向量近邻检索召回相关片段，后续大模型的处理范围就缩小到少量候选片段，输入规模和推理成本一起降下来。
多模态精读的思路可以概括为“重检索、轻生成”。定位完成后，把合并后的少量候选片段交给多模态大模型做精读和报告生成。
一个容易被忽略的细节：该实践并没有因为托管能力不够才自建管线。文章明确说，Nova Multimodal Embeddings 的异步接口已经支持按用户定义的时长切分长视频；自建的原因是本次场景需要把业务特定的分段策略、运动异常信号、候选合并和任务流程组合在一起，底层的模型推理和向量存储仍交给托管服务。这个边界划得很清楚。
接入时几个真实的坑
第一个坑是向量存储的规模假设。 文章说，这个 PoC 按 missionId 划分索引，使任务级复用和逻辑分组更直观，但它不是无限扩展模型；生产化仍需结合配额、生命周期和查询模式，评估是否改用共享索引。换句话说，PoC 阶段好用的索引策略，上线后可能成为瓶颈。
第二个坑是把“检索”当成一次性动作。 文章提到双路候选合并，说明单一召回路径不够；这和文本 RAG 里 hybrid retrieval 的思路一致——稀疏检索适合关键词、实体和精确匹配，稠密检索适合语义泛化，实际常用混合检索，再用 rerank 弥补向量召回排序不准（来源：GitHub项目WeThinkIn/AIGC-Interview-Book中的字节跳动高频面试题整理，该页面未标注发布日期）。
第三个坑是精读模型的选择。 文章说 Nova 2 Lite 是本次 PoC 在成本和效果之间的折中选择，实际质量与成本仍需结合业务样本持续评估。没有哪个模型是“接上就完事”的，样本和评估集才是长期资产。
给一段通用伪代码示意这条链路的结构，不含任何真实参数：
segments = split(video, granularity=configurable_seconds) vectors = embed_multimodal(segments) # 文本与视频同一语义空间 candidates = vector_search(query, vectors, top_k=...) # 可加metadata过滤 merged = merge(candidates, signals) # 双路候选合并 report = multimodal_model.read(merged) # 只精读少量片段
长上下文和 RAG 该怎么分工
分工取决于任务形态，而不是模型参数。粗略地说：需要通读全文做总结、做风格改写、做长文档问答，长上下文模型直接上更省事；需要在大体量素材里定位少数关键证据、需要每个结论都能追回原文出处、需要把推理成本压到可控区间，检索前置更稳。
这个判断在语音场景同样成立。阿里云百炼的模型更新页面显示，其语音识别方向新增了 Qwen-Audio-3.0-ASR-Flash-Streaming（实时）、Qwen-Audio-3.0-ASR-Flash-Filetrans（非实时）等模型，同一页面对一款高效轻量化 MoE 模型的描述是总参 284B、激活 13B、原生支持百万超长上下文，适合日常对话、内容创作、基础 RAG、批量文案处理等场景（来源：阿里云帮助中心“模型上下架与更新”页面，未标注发布日期）。注意它把“基础 RAG”和“长上下文”并列写在适用场景里——厂商自己也没把两者当成互斥选项。
接下来值得盯的方向
一是任务级索引。 上述 PoC 按 missionId 划分索引，提示了一个方向：检索单元未必是固定长度的切片，可以是业务上的一次任务、一次会话、一次事故。这对索引设计和权限隔离都有影响。
二是“重检索、轻生成”的成本账。 当精读阶段只处理少量候选片段，模型选型空间就大了，贵模型用在刀刃上，便宜模型扛批量。这个结构对预算敏感的团队可能比单纯追长上下文更实际。
三是评估集的建立。 文章反复提到“结合业务样本持续评估”，这句话说起来轻，做起来是长期投入。没有自己的样本集，分段粒度、召回数量、模型选择都只能拍脑袋。
回到开头的问题：长上下文模型越来越多，RAG 还有必要做吗？答案取决于你的场景里，“找得到”和“说得通”哪个更贵。对多数需要证据可追溯的工程系统来说，先检索再生成，仍然是更稳的那条路。
本文由 AI 辅助整理，事实与出处均来自上述公开资料，未做额外实测。
（本文由AI生成，发布前已做事实核对。）
