从一条需求到一条内容

做内容生成系统以后，我越来越觉得，最麻烦的地方其实不是"让模型写一段内容"。

如果只是让大模型根据一个主题写脚本、写文案，这件事现在已经不稀奇了。真正难的是另一件事：用户给一段需求，再上传一堆视频、图片、文档和零散说明，系统最后要交付的不是一段回答，而是一条能继续剪辑、排版、渲染甚至直接交付的内容产物。

这套系统底层也用了 RAG，但它不是传统意义上的知识库问答。检索只是入口，它负责把和任务相关的材料找出来；后面还要做任务规划、内容生成、素材匹配、格式整理和工程后处理。换句话说，这里要解决的不是"答得对不对"，而是"最后能不能交付"。

下面就按当前系统的实际链路，把这套面向内容生成的 RAG + Agent 架构拆开讲一下。

这套系统到底在做什么

先把定位说清楚：它是一个面向内容生成交付的 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 API。

这三路并行跑，最后再合并。私有库保证内容贴合业务，联网搜索补上知识库覆盖不到的实时信息，用户素材库则提供本次生成必须使用的"原材料"。少了任何一路，结果都会变得单薄。

多模态素材需要先结构化

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

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

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

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

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

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

召回之后：为什么要 Rerank

三路召回解决了"广度"的问题，也会带来新的噪声：不同来源的结果质量不一样，可信度不一样，同一个语义还可能被重复召回。

如果把这些结果直接塞给大模型，问题会很明显：

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

所以召回和组装之间需要插一个 Rerank 重排。

Rerank 做的事情，不是生成任何内容，而是回答一个问题：这一堆候选片段里，哪些最值得放进最终上下文。

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

这一步我用的是 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 系列负责检索增强，代码层负责流程编排和最终交付。

这样拆下来，成本、稳定性和可控性都会比把所有事压在一个模型上更好。旗舰模型主要用在最需要推理和生成质量的地方，前面那些可以批量、可以并发、可以用便宜模型解决的环节，就尽量交给对口的轻量模型。

这套架构真正的难点

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

1. 多模态素材结构化

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

2. 多路召回结果融合

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

3. 上下文控制

不能把所有召回结果都塞给模型。要在 Token 限制内，保留最关键的信息，还要分区和标注来源，让模型能分清哪块是内部知识、哪块是网上搜来的。

4. Agent 工作流稳定性

不同输出类型的流程完全不同。短视频、播客、图文、文章，从规划到后处理的链路都不一样，每一条都要单独打磨。这块的复杂度随着支持的产物类型线性增长。

5. 生成结果工程化交付

模型生成的是内容草稿，还要经过排版、剪辑、格式化、渲染，才能变成用户能用的产物。这一层的工程量，往往比"调通大模型"本身大得多。

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

结语

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

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

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