企业官网建设流程全解析

做视频问答、视频摘要这类多模态任务时，最容易低估的环节是抽帧。很多人以为，只要把视频转成图片，再交给多模态 LLM，任务就算完成了一半。等结果不对时，第一反应往往是换一个更强的模型，或者反复改提示词。但真正的问题常常发生在更早的位置：模型看到的那几帧，是不是恰好捕捉到了视频里最关键的信息？我最近整理“如何让 LLM 看视频”的相关经验时，得到一个很直接的结论：frame selection is the whole game，帧选择就是整个游戏。

这句话听起来有点绝对，但它点破了一个被大量教程跳过的事实。多模态模型虽然叫“视频理解”，实际处理时大多数情况并不是真的在连续流式地看视频，而是接收有限数量的帧序列。给定同样的模型、同样的提示词，不同的抽帧方式会产生完全不同的回答。你可以让模型读十段提示词，都比不上给它一帧真正包含答案的画面。

这篇文章不打算铺开讲所有视频理解技术，我只想围绕一个核心问题展开：当你需要 LLM 理解一段视频时，到底应该选择哪些帧，怎么选，选完怎么组织，以及选错时怎么排查。这个过程看起来是“预处理”，实际上是整个任务的胜负手。

1. 先把“让 LLM 看视频”翻译成一个具体的输入问题

1.1 多模态模型不是真的在看视频

首先要明确一个事实：绝大多数多模态模型并不会直接吃原始视频文件。视频是一个连续的高帧率信号，比如常见视频是 25 到 30 帧每秒，一个 10 秒的视频就有 250 到 300 帧。如果每一帧都送进模型，token 数量会迅速爆炸，视觉特征计算量也不现实。

所以，工程上最常见的做法是先把视频解码成若干帧图像，再把图像作为多模态模型的输入。听起来很直接，但这带来一个关键转变：模型看到的“视频”已经不再是视频，而是一组离散的图片。它看不到帧与帧之间的运动轨迹，看不到镜头切换时的动态过程，也看不到被跳过的那些瞬间发生了什么。

这就解释了为什么很多视频理解任务表现不好。不是模型不够聪明，而是模型被“喂”的帧集合本身是残缺的。如果关键动作发生在两帧之间，那模型根本没有机会看到它。你要求模型回答“这个人什么时候推倒杯子”，但恰好推倒杯子的那一帧没有被抽到，模型就只能靠前后帧去猜，答案自然不可靠。

1.2 帧选择决定模型能获得哪些信息

从信息论角度看，帧选择本质上是降采样。原始视频的信息量极大，但模型能接收的信息量有限。你需要做的是在被选中的少量帧里，保留对当前任务最重要的信息。

一个 10 秒、30fps 的视频，理论上包含 300 个瞬间。如果只选 3 帧，相当于用 1% 的信息量来回答 100% 的问题。那这 3 帧应该怎么分布？是均匀分布在 0s、5s、10s？还是在第 3 秒和第 7 秒各多抽一帧？这完全取决于任务。

• 如果任务是“描述视频的整体场景”，均匀采样可能就够了。
• 如果任务是“数清视频里出现过几个人”，可能需要场景切换时各抽一帧，避免同一镜头下重复计数。
• 如果任务是“判断视频里某个动作是否符合规范”，那关键动作发生的瞬间必须被覆盖。

所以，帧选择从来不是一个“随便抽几张图”的步骤，而是一个信息取舍的决策过程。它决定了模型的“视野”，而视野决定了答案的上限。

2. 三种主流的帧选择思路：均匀采样、关键帧、语义筛选

2.1 均匀采样最容易，但也会漏掉关键动作

均匀采样是很多教程最先教的方法：每隔固定时间抽一帧。比如每 2 秒一帧、每 30 帧一帧，或者直接指定抽帧总数。优点是简单、稳定、可预测，也容易对比不同参数的效果。

但它的问题也很明显：它不了解视频内容。如果视频里最重要的信息恰好出现在第 4.5 秒，而你的抽帧节奏是每 5 秒抽一帧，那这个信息就只可能落在 0 秒或 5 秒的帧附近。如果动作持续时间极短，甚至根本不会被任何一帧捕获。

在工程实践中，我一般会把均匀采样当作“基线方案”，而不是最终方案。先用它快速跑通流程，确认模型能够理解基本场景，再根据效果决定是否需要换用更聪明的抽帧方式。它适合的场景包括：监控视频的静态环境描述、风景镜头、PPT 讲解类视频的整体概括、会议录像的段落划分。

2.2 场景切换和关键帧提取适合连续事件

比均匀采样更进一步的做法是检测场景切换。当画面内容发生剧烈变化——镜头切换、人物进出、画面亮度跳变、字幕出现——就抽取该时刻的帧。这类方法通常使用帧间差异、直方图变化，或者现成的场景检测库（例如 PySceneDetect 这类工具）。

场景切换抽帧的优点是能用更少的帧覆盖更多不同场景，非常适合镜头频繁切换的短视频、电影片段、新闻视频。它解决了均匀采样最大的痛点：不会因为某个镜头持续了 10 秒就疯狂重复抽帧，也不会因为某个镜头只有 0.5 秒就被完全漏掉。

但需要注意一个概念混淆：视频编码中的“关键帧”（I 帧）和内容理解中的“关键帧”不是一回事。I 帧是编码时为了压缩引入的完整图像帧，它不代表语义上重要。如果你用 ffprobe 查看视频流里的关键帧列表，得到的可能只是每 2 到 5 秒一个的编码锚点，和内容重要性没有必然关系。所以，做帧选择时不要直接依赖 I 帧列表，需要额外做内容分析。

场景切换也有盲区：在一个连续长镜头里，人物可能在做细微动作，没有任何镜头切换，但信息密度并不低。比如一个教学视频里，老师在镜头前写板书，画面没有切换，但板书内容逐步变化。此时场景检测默认不抽帧，容易漏掉关键信息。这种情况下，均匀采样反而更稳。

2.3 基于任务语义的筛选才是终局方案

如果要追求更高的准确率，就要让帧选择跟着任务走。思路是：先抽一批候选帧，再用一个辅助模型或规则打分，选出和任务描述最相关的帧。

举例来说，任务要找到视频里“红色的车出现的时间”。先均匀抽帧，得到 50 张候选图；再让一个轻量级图像分类模型或 CLIP 类模型计算每张图和“红色汽车”的相似度；最后挑出分数最高的几张送到 LLM。这样做的好处是，最终输入给大模型的每一帧都离答案更近。

这种“候选帧 + 语义筛选”的两段式结构，在实际项目中非常实用。它不见得需要多么复杂的模型。如果你想判断视频中是否有人举起手，可以先用人体关键点检测给出候选区间，再抽取该区间附近的帧；如果你想读取 PPT 上的文字，可以用 OCR 先定位标题和正文，再抽对应帧。

不过要清楚，语义筛选不是免费的。它多了一次模型推理，增加了计算延迟。如果视频很短、场景简单，均匀采样可能已经足够；如果视频很长、答案依赖细节，语义筛选的收益会非常明显。不同的视频理解任务，需要不同的取舍。

下表可以直观看出三种思路的差异：

3. 从视频文件到 LLM：一整套可以落地的帧选择流程

3.1 准备环境和依赖

要开始实操，至少需要这么几样东西：

• 视频解码工具，最常见的是 FFmpeg。
• 图像处理脚本，一般用 Python + OpenCV。
• 多模态模型接口，支持图片输入。
• 如果需要场景检测或语义筛选，安装对应库，例如 PySceneDetect、transformers 等。

建议先在一个干净的 Python 虚拟环境里验证脚本，再搬到服务器或工作流里。如果只是学习和小规模实验，默认安装通常够用；如果要进入生产环境，就需要锁依赖版本、输出目录、日志策略和异常处理。

我一般会先用一个非常短的示例视频测试整条链路，确认 FFmpeg 抽帧命令没有写错，图片能正常生成，模型接口能正常接收。不要一上来就批量处理几十个视频。

3.2 第一遍先抽帧，把视频变成候选图片集

抽帧最常用的工具就是 FFmpeg。最简单的均匀采样命令类似这样：

# 每 2 秒抽一帧，输出到 frames/ 目录 ffmpeg -i input.mp4 -vf "fps=1/2" -q:v 2 frames/out_%04d.jpg

说明一下参数含义：-vf fps=1/2表示每 2 秒输出一帧；-q:v 2是 JPEG 质量参数，数值越小质量越高；输出文件名里的%04d会被替换成四位序号。如果不想全视频抽帧，可以用-ss指定开始时间，-t指定时长。

如果你需要更精确的控制，可以用 OpenCV 写脚本：

import cv2 video_path = "input.mp4" cap = cv2.VideoCapture(video_path) fps = cap.get(cv2.CAP_PROP_FPS) total_frames = int(cap.get(cv2.CAP_PROP_FRAME_COUNT)) duration = total_frames / fps # 每 2 秒抽一帧 interval = int(fps * 2) frame_count = 0 saved_count = 0 while True: ret, frame = cap.read() if not ret: break if frame_count % interval == 0: out_path = f"frames/frame_{saved_count:04d}.jpg" cv2.imwrite(out_path, frame) saved_count += 1 frame_count += 1 cap.release()

这段脚本是常见的教学结构，不是唯一写法。实际生产时建议用流式方式逐帧读取，而不是一次性把整个视频读入内存。高清视频单帧分辨率很大，长时间运行会占用不少资源。

3.3 再按任务策略挑帧，组装成模型输入

第一步产生的候选帧，可能还是太多。如果任务只需要 5 张图，你就需要决定怎么从候选帧里挑出这 5 张。

如果使用场景检测，可以先检测出所有镜头边界，再从每个镜头内选择一帧画面变化最平稳的帧。如果使用语义筛选，可以用一个轻量模型给候选帧打分。这里要记住，挑完帧之后，最好把每帧的时间信息保留下来，而不是只给模型一堆无标注的图片。

一个常见的组装方式是：把图片按时间顺序编号，并在提示词里标注对应的时间戳。

下面是一段视频中抽出的 5 帧，分别位于 0s、2s、4s、6s、8s。 请根据这些帧回答：视频里一共出现过几个人？他们在做什么？

如果你使用的是 API 接口，常见的做法是把图片转为 base64 字符串，或者上传到临时存储后传 URL。具体格式取决于平台文档。建议先跑通一张图片，再扩展到多张，避免接口限制造成的困惑。

4. 帧顺序、时间戳和上下文组织：比想象中更影响结果

4.1 模型经常分不清先后顺序，时间戳要显式给

很多人以为，只要把帧按时间顺序传给模型，模型自然知道先后。但实际测试中，模型对多张图片的“顺序感”并没有想象中那么强。尤其当两帧画面内容相似时，模型可能无法判断哪一帧在前，哪一帧在后。

更麻烦的是时间间隔。两帧相隔 0.1 秒，代表一个“瞬间动作”；两帧相隔 10 秒，代表一个“过程变化”。如果模型不知道真实间隔，它只能按顺序理解，无法判断动作发生的快慢。

所以，在构造输入时，我建议显式地提供时间戳信息。可以写在提示词里，也可以把时间戳叠加到图片上。对于“这个事件是突然发生还是逐渐变化”这类问题，时间戳是必要信息。

4.2 多图输入和视频网格：各有取舍

输入多张独立图片，和把所有帧拼成一张网格图，是两种不同的常见组织方式。

多图输入的优点是每张图保留原始分辨率，细节不容易丢，适合要看小物体、人脸、文字的场景。缺点是一张图会消耗大量视觉 token，如果帧数较多，可能超过单次请求的上限，也会让推理变慢。

视频网格则把多帧缩略图拼成一张 2x3 或 3x3 的图片，整体作为一张图输入。优点是减少请求数量，适合“全局摘要”类任务。缺点是每一帧的分辨率被压缩得很低，细节信息容易被磨掉。

我的选择标准是：

• 需要读文字、车牌号、人脸表情变化时，优先用多图独立输入。
• 只需要理解整体氛围、镜头顺序、场景分布时，可以用视频网格。
• 如果 API 限制一次只能传一张图，也可以考虑网格，但要提前验证分辨率是否足够。

如果条件允许，可以两种方式都试一次，对比模型输出质量。很多时候，模型“看起来变聪明了”，其实只是输入的组织方式更合理了。

4.3 ASR/OCR 是帧选择之外的另一条信息通道

帧选择很重要，但它不是唯一的信息来源。很多视频里有语音、字幕、背景音乐和音效，这些信息无法从一帧画面里直接读出来。如果任务涉及对话内容、旁白、字幕，那么 ASR 语音转写和 OCR 字幕识别往往比画面更有效。

处理方法也很简单：先用 FFmpeg 从视频里提取音频轨道，再交给 ASR 系统转成文本；对于压硬字幕的视频，可以用 OCR 抽取字幕文字；然后把这些文本和帧一起作为模型输入。

这样做的收益非常大。比如教学视频里，老师说的内容很可能就是答案本身；“视频里宣布了什么事项”这类问题，通过 ASR 文本就能直接得到，不需要从帧画面里猜。你也可以先把文本给模型做一次摘要，再决定还需要看哪些时间点的帧。这样能进一步缩小帧选择范围。

5. 成本、延迟和批量的边界：帧选择也是在选预算

5.1 图片数量直接决定 token 和费用

多模态模型处理图片是有成本的，图片越多、分辨率越高，token 开销越大，响应时间越长。不同平台的定价公式不同，但总体趋势一致：图片数量是成本的关键变量。

实际落地时，我建议先建立一个简单的估算表。假设一次任务最多允许 10 张图，那么每张图大约对应多少 token，算一下最终成本是否可接受。不要凭感觉决定帧数，要把它当作预算来控制。

初期原型阶段，先用 5 张图跑通流程；如果答案质量不够，再逐步增加到 10 张、20 张。这种从小到大的方式可以快速定位“问题到底是不是帧数不够”。

5.2 增量式和多阶段策略：先全局粗看，再局部放大

帧选择不一定要一次性完成。更高效的方式是分成多轮：

• 第一轮：用低分辨率、少量帧获取视频的全局结构，例如 5 张均匀采样的缩略图。
• 第二轮：根据第一轮的摘要，找出需要重点关注的时间区间。
• 第三轮：对重点区间做更密集的抽帧，或者对帧中的特定区域做裁剪放大。

这种“由粗到细”的策略很像人的观察方式。先扫一眼全局，再聚焦细节。它能够用更少的 token 获得更高的准确率，因为最终的模型输入里，大部分帧都是和任务相关的。

如果你有足够长的上下文和更大的成本预算，当然可以一次性传 50 帧。但在大多数项目里，成本都是有限资源，增量式处理往往更可持续。

5.3 从原型到生产的长期维护

如果只是做实验，一个脚本就够了。但如果你要把“让 LLM 看视频”变成一个正式服务，还需要考虑：

• 视频上传和解码的异步队列，避免阻塞接口。
• 抽帧结果缓存策略：同一段视频不必每次都重新抽帧。
• 存储策略：如果帧图片很多，需要考虑磁盘占用和清理策略。
• 失败重试：某一张图片解码失败，或者模型请求超时，不能影响整个任务。
• 日志：记录每一条请求用了哪些帧、什么时间、模型输出什么，方便后续复盘。

这些都不是帧选择本身，但会直接决定一个方案能不能长期使用。很多人把注意力放在模型参数和提示词上，忽略了抽帧环节的工程化，结果上线后到处踩坑。

6. 当模型答错时，先别急着换模型，先排查帧选择

6.1 排查顺序：现象、输入、策略、输出、边界

在实际调试中，模型答错有无数种原因。我习惯于按固定顺序排查，先把帧选择问题排除掉，再考虑模型本身。

1. 看现象：模型是“完全没提到某个关键信息”，还是“描述顺序颠倒”，还是“对物体位置判断错误”。
2. 看输入帧：抽出来的帧是否足够清晰？画面是否过暗？目标物体是否被遮挡？帧是否重复？
3. 看抽帧策略：关键动作发生在什么时间？你选的时间点是否覆盖了它？间隔是否太大？
4. 看上下文组织：时间戳有没有给？帧顺序是否正确？图片是否被压缩成网格导致细节丢失？
5. 看模型能力：以上都没问题，再考虑是否换模型、调提示词、增加更多帧。

一个常见误区是：模型给出了一个看似合理的错误答案，你以为它是“推理错了”，于是疯狂调提示词。但实际上模型根本没有看到关键帧，它是在“缺信息”的前提下，用常识脑补了一个答案。这种情况下，提示词优化解决不了问题。

6.2 一个最小调试模板

为了快速定位是帧选择问题还是模型问题，可以做一个最小化实验：

• 准备一段包含明确答案的短视频。
• 用三种方式生成输入：均匀采样、场景切换、手工挑选关键帧。
• 保持相同提示词，分别让模型回答。
• 比较三种输入下答案的差异。

如果三种方式答案都错，可能是模型能力或提示词问题。如果只有均匀采样错，而手工挑选关键帧对，说明问题就出在帧选择策略上。

还可以让模型输出“每帧你看到了什么”，来检查模型是否真的看到了你期望的内容。比如你选了一张有明显红车的帧，模型却描述成“路边停着一辆白色车”，那可能是图片压缩、光线、角度或模型识别能力的问题。这个反馈能帮你判断下一步该调整哪里。

7. 帧选择不是预处理，而是任务设计

7.1 把帧选择当成可复用的决策框架

我把多次实验后沉淀出来的步骤总结成一个小框架，适合大多数视频理解任务：

1. 定义任务目标：你希望模型回答什么？需要全局信息还是局部细节？
2. 拆解信息维度：时间范围、空间区域、文字字幕、动作事件、物体位置。
3. 生成候选帧：先均匀抽帧或场景切换，得到候选图集。
4. 筛选相关帧：结合语义模型、OCR、ASR、规则，选出少量关键帧。
5. 验证并迭代：记录输出不达标的样例，回到第 2 步调整策略。

这个框架的核心是：不要一开始就跳进“用什么模型”的讨论，而是先想清楚“模型需要看到什么信息”。很多任务失败，是因为我们没有给够信息，或者是给了太多无关信息，模糊了关键内容。

7.2 适合谁、不适合谁

帧选择这套方法论，适合视频问答、视频摘要、内容审核、教学视频检索、多模态 Agent 的视觉感知等场景。这些任务通常对时间精度要求不极端，画面里包含清晰的语义信息，且可以通过少量帧表达。

但它也有明确边界。如果任务需要逐帧理解，比如判断 1 秒内挥拳动作的角度变化、高速运动物体的轨迹、精密仪器的微小位移，那基于大模型 + 抽帧的方案不是最佳选择。此时更应该用传统 CV 算法或专门的动作识别模型，而不是勉强让 LLM 从稀疏帧里推理。

另外，如果对实时性要求极高，每一帧都要处理，抽帧反而变成瓶颈。这些场景需要专门的视频理解 pipeline。帧选择是“用有限信息做整体理解”的思路，它强调取舍和效率，不是无限制地追求完整。

7.3 长期值得关注的原因

即使未来多模态模型的上下文窗口越来越大，帧选择也不会消失。模型的推理能力和成本始终是有限资源，而视频信息量永远远大于模型能一次吃下的量。关键问题永远是：如何在有限的输入预算里，保留对任务最有价值的信息。

这也是我在文章开头说“frame selection is the whole game”的原因。它不是一次简单的抽帧操作，而是决定了模型能看什么、不能看什么，最终决定了系统的理解上限。下次再做“让 LLM 看视频”的任务时，不妨多花时间研究视频内容、任务目标和帧策略。先搞定帧选择，再去谈提示词和模型选型，你会发现很多问题其实早已有了答案。