做内容生成系统以后，我发现最麻烦的其实不是“让模型写一段内容”。这个早就不是问题了，大模型写脚本、写文案都很顺。难的是用户给一段需求，再传一堆视频、图片、文档和零散说明，最后系统要交付的不是一段回答，而是一条能继续剪辑、排版、渲染甚至直接交付的成品。

这套系统底层也用了 RAG，但和那种知识库问答不是一回事。检索只是入口，负责把和任务相关的材料捞出来；后面还要做任务规划、内容生成、素材匹配、格式整理和工程后处理。所以我更关心的不是“答得对不对”，而是“最后能不能交付”。

下面按现在系统的实际链路，把面向内容生成的 RAG + Agent 架构拆开讲讲。

它和普通 RAG 差别在哪

先给个定位：这是一个面向内容生成交付的 RAG + Agent 系统。

传统 RAG 更像问答：用户提问，系统从知识库捞片段，拼进 Prompt，让模型回答。大家盯的指标基本是检索准不准、答案对不对。

内容生成系统要处理的任务麻烦得多。比如用户说“帮我做一条介绍储能产品出海的短视频”，同时传了几个视频片段和产品文档。这时候系统不能只回一段泛泛的营销文案，至少要生成脚本、分镜规划、素材使用建议，最好再给一份能直接剪的方案。

输入输出都比问答复杂：

• 输入不只有文本，还有视频、图片、文档、纯文本素材
• 输出不是一段文字，而是面向业务交付的内容产物

所以链路不能停在“检索 + 回答”。得先判断用户要生成什么，再从多个来源召回上下文，让模型做规划和生成，最后由工程代码把结果加工成稳定交付物。

压缩成一条链路就是：

用户输入需求和素材 → 系统识别任务意图 → 多路召回上下文 → 重排组装 → 大模型规划生成 → 工程后处理 → 交付内容。

完整链路

展开以后长这样：

如果按职责分，我把它拆成四层：

层级	作用	代表能力
代码编排层	任务识别、流程控制、上下文组装、后处理	业务服务、Agent 调度、工具链
检索链路层	查询改写、召回、合并、重排	Qwen 系列、Embedding、Reranker
大模型生成层	Agent 规划、内容生成	Gemini Pro 级
工具与素材层	向量化、多模态素材理解、联网搜索	Gemini Flash 级、Qwen Embedding、Bing / Serper

这四层里，最费时间的其实不是调模型，而是检索链路和工程编排。模型能力是公开的，谁都能调；真正影响效果的是前面能不能把材料整理成模型能用的上下文，后面能不能把模型输出变成可控产物。

检索：为什么不能一把搜

很多 RAG demo 的检索链路就一句“用户输入 → 向量检索 → 取 topK”。问答场景里能跑，放到内容生成里，召回质量会很不稳定。

用户原句不适合直接检索

用户输入通常是任务型描述，不是检索型描述。

比如“帮我做一条介绍储能产品出海的短视频脚本”，这句话里没有行业维度、卖点维度，也没有结构维度。直接拿去做向量检索，结果通常很散：搜到一堆“短视频怎么做”的泛泛内容，搜不到“储能出海的海外用户痛点”这种能支撑内容的材料。

所以第一步是 Multi-Query 查询改写：用一个中小尺寸生成模型，把用户原始需求改写成多组检索 Query，从不同角度扩大召回范围。

上面那句话会被改写成类似这样：

储能产品出海市场趋势
海外储能用户痛点
储能产品短视频脚本结构
新能源品牌出海营销文案
储能产品应用场景案例

这样一次检索能同时覆盖行业背景、用户痛点、内容结构、表达风格和应用案例。内容生成要的不是单一证据，而是一组能支撑创作的材料包。

这一步我用 Qwen 系列中小尺寸模型，它只做改写、不做复杂推理，便宜、快、够用。

上下文分散在不同来源

能撑起一次内容生成的上下文，通常不在一个库里。我们做了三路并行召回：

• 私有知识库向量检索：查企业内部知识、产品资料、方法论，最核心的一路，用 Qwen Embedding 建向量索引。
• 用户素材库检索：查用户这次上传的视频、图片、文档、文本，下面单独讲。
• 联网搜索：补实时信息和公开资料，比如行业数据、竞品动态，走 Bing 或 Serper。

三路并行，最后合并。私有库保证内容贴业务，联网搜索补知识库没有的实时信息，用户素材库提供这次必须用的原材料。少一路，结果就单薄。

多模态素材要先结构化

这是我觉得这套系统和普通文本 RAG 最大的区别。

用户传的视频和图片没法直接做文本检索。为了让后面能召回这些素材，入库前要先做多模态预处理：

• 视频生成摘要、场景标签、关键帧描述
• 图片生成标签、主体描述、风格描述
• 文档抽标题、段落、摘要、关键词
• 文本直接分块

处理完再用 Embedding 写进向量库，之后才能在线检索。

这一步用 Gemini Flash 级视觉语言模型，吞吐高、成本低，适合打标和摘要。它和后面负责生成的 Gemini Pro 级同属一个家族，API 统一，工程上省不少适配成本。

所以这里不是简单取 topK，而是先改写查询、多路召回，同时把多模态素材提前变成可检索的文本。

召回之后：Rerank 和上下文组装

三路召回解决了广度，也带来噪声：不同来源质量不一样、可信度不一样，同一个语义还可能被重复召回。直接塞给大模型会有三个问题：

• 私有知识库的精准结论和联网搜索的泛泛文章混在一起，模型分不清轻重
• 重复信息浪费 token
• 无关资料稀释注意力

所以召回和组装之间要插一个 Rerank 重排。Rerank 不生成内容，只回答一个问题：这堆候选片段里，哪些最值得放进最终上下文。

它和向量检索的分工是：向量检索做粗召回，追求快和全；Rerank 做精排，拿 Query 和每个候选片段做更细的相关性判断，把高相关片段排前面。

Rerank 我用 Qwen 系列的 Reranker。专门的 reranker 比拿生成模型临时打分便宜、稳，也不容易自由发挥。

Rerank 之后还有一步容易被低估：上下文组装。这步在代码层做，目标是把检索片段整理成模型能理解和使用的 Prompt。我会注意几点：

• 去重，别让重复信息浪费 token
• 分区，内部知识、用户素材、联网资料分开摆
• 标注来源，让模型知道内部知识库和网上内容的可信度不一样
• 控长，别超上下文窗口，在限制内留最关键证据

模型最终看到的是代码层整理完的 Prompt，不是原始数据库。这步做得糙，后面生成再强也容易跑偏。

生成与交付：模型只出草稿

上下文组装好，才进入大模型生成。分两个阶段。

Agent 规划阶段，把“生成一条短视频”拆成可执行结构：

• 选题规划：内容讲什么角度
• 脚本结构：开头、主体、结尾怎么组织
• 内容拆分：分几段、几个镜头
• 分镜规划：每个镜头讲什么、用什么素材
• 输出形态：短视频、播客、图文还是文章

内容生成阶段，把规划落到具体文字：

• 正文和文案
• 短视频脚本
• 分镜描述
• 播客口播稿
• 图文内容

这两步用 Gemini Pro 级，复杂规划、长上下文理解、多模态生成都靠它。

但这套系统里，大模型的输出不会直接当最终产物，它更像一份高质量草稿。生成的脚本、分镜、文案还要再走一层工程后处理：

• 短视频编排：把分镜、素材、字幕组合成剪辑方案甚至成片
• 图文排版：套模板、调格式
• 播客剪辑：把口播稿切成可用段落
• 文章格式化：统一结构、清理冗余
• 工具链渲染：最终输出成用户能用的文件

这层是整套架构里最工程化的部分。模型负责生成核心内容，业务代码负责把内容变成稳定、可控、可交付的产物。没有这层，模型写得再好也只是一段 markdown，离用户要的东西还差一截。

模型分工

旗舰模型确实能多扛几个环节，但生产系统得同时看质量、成本、速度和稳定性，不同环节适合的模型不一样。当前分工是这样：

模型家族	主要职责	所在阶段
Qwen 系列（中小尺寸）	Multi-Query 查询改写	检索前
Qwen 系列 Embedding	知识库 / 素材库向量化与检索	向量检索
Qwen 系列 Reranker	召回结果重排	Rerank
Gemini Flash 级	多模态素材预处理（视频 / 图片打标摘要）	素材理解
Gemini Pro 级	Agent 规划与最终内容生成	生成
Bing / Serper	联网搜索补充外部信息	外部检索

取舍很直接：Embedding 必须用专门向量模型，生成模型不是为检索设计的，拿来向量化又贵召回又差；Rerank 用生成模型做又贵又慢，Reranker 专门干这个；多模态素材理解交给视觉语言模型，吞吐高成本低，打个标签用不上旗舰；真正复杂的规划和最终生成才上旗舰，把贵的算力花在刀刃上。

一句话概括：

Gemini 家族负责多模态理解与生成，Qwen 系列负责检索增强，代码层负责流程编排和最终交付。

这么拆下来，成本、稳定性、可控性都比把所有事压在一个模型上好。

真正难的地方

只看架构图，这条链路好像就是把几个模块串起来。实际做下来，难点基本都在工程细节上。

多模态素材结构化。 视频、图片不能直接做文本检索，得先生成标签、摘要、关键帧描述和场景信息。预处理质量直接决定后面能不能召回正确素材。

多路召回结果融合。 私有知识、用户素材、联网搜索，质量和可信度完全不同。怎么合并、去重、标注来源、排序，每一步都影响最终上下文。

上下文控制。 不能把所有召回结果都塞给模型。得在 token 限制内留最关键信息，还要分区、标注来源，让模型分清内部知识和网上内容。

Agent 工作流稳定性。 短视频、播客、图文、文章的流程完全不一样，从规划到后处理的链路都要单独打磨，复杂度随产物类型线性涨。

生成结果工程化交付。 模型出的是草稿，还要经过排版、剪辑、格式化、渲染才能交付。这层工程量往往比“调通大模型”大得多。

这些问题基本不可能靠“换个更强的模型”一次性解决，更多是在链路、数据结构、提示词组织和后处理规则里一点点磨。

结语

这套系统做下来，我对 AI 内容生成的看法变得工程化了一点。

大模型是核心，但它只负责中间那段：理解上下文、规划、生成内容。前面要把素材、知识和实时信息整理成可用上下文，后面要把生成结果变成可交付的短视频、播客、图文或文章。系统能不能稳定工作，往往看这些模型之外的部分。

我现在更愿意把它看成一条内容生产流水线：检索备料，上下文组装把材料摆到模型面前，Agent 负责规划和生成，工程后处理把草稿做成产物。模型还会继续变强，但把流水线理顺、把每个交接点做稳，才是这类系统更长期的价值。