做智能视频分析这两年最大的变化是单靠YOLO扛不住事了。YOLO检测速度快、部署便宜但它只能回答“这里有什么”一旦问到“这个行为是否合规”“这个事件和上周那起有什么关系”这类问题它就没辙了。VLM能看懂画面并给出推理可你也不可能拿7B以上的视觉大模型去逐帧分析全天候的监控视频——算力和延迟都吃不消。所以圈里逐步达成了一个共识用YOLO做眼睛用VLM做大脑用RAG做记忆三者拼成一套智能视频分析系统。这篇文章我把自己在实际项目里验证过的7种大小模型视频协同分析方案拆开讲清楚每种方案的适用场景、链路设计、成本陷阱和落地难点都会说透。如果你是做安防监控、工业质检、智慧园区、视频检索相关开发的或者正在纠结“大模型到底怎么落到视频场景里”这篇应该能帮你省不少试错时间。1. 内容整体设计与思路拆解1.1 为什么是YOLOVLMRAG这个组合先理清楚三个组件各自的角色。YOLO这一层负责“看见”它输出的是目标框、类别、置信度还有跟踪ID这些信息实时性极高单帧推理在消费级显卡上也就几毫秒到十几毫秒非常适合做第一道实时感知。VLM负责“看懂”它接收图像或视频片段后能输出自然语言描述、判断场景语义甚至能做多轮对话推理但代价是推理速度慢、显存占用高直接逐帧跑不现实。RAG负责“记住”它把YOLO的结构化结果和VLM生成的语义描述统一存成向量用检索的方式实现跨时间的“记忆召回”这样用户不需要训练任何模型就能用自然语言查询历史视频里发生过的事件。这个组合的本质是拿性能换语义拿检索换记忆。没有YOLOVLM在长视频上根本跑不动没有VLMYOLO检测结果只是一堆坐标和类别非技术用户根本没法用没有RAG所有分析结果都是“一次性”的你今天查完明天就丢了。三者合起来才构成一个能落地、能问答、能溯源的完整系统。1.2 大小模型协同的核心逻辑谁的活谁干大小模型协同的关键不是“把模型拼在一起”而是“把任务按代价拆开”。我习惯用三层分工来理解感知层、语义层、记忆层。感知层要求快必须用轻量模型在靠近摄像头的地方完成YOLO系列就是这层的首选语义层要求准只在关键时刻、关键区域启动VLM在这里做深度理解记忆层要求全所有关键事件的描述都要留存RAG负责组织和召回。这套逻辑里最容易犯的错是让大模型干了小模型的活。有人为了“智能”直接拿VLM逐帧识别画面里的行人和车辆结果4090跑起来都烫手延迟还根本没法看。反过来也有人非要YOLO去识别“员工有没有戴安全帽”其实YOLO能识别“人”但“安全帽”这种细粒度属性得靠VLM对裁剪区域做二次确认。所以我在设计系统时第一件事永远是画一张“任务-代价”对照表把每类需求标记为“实时检测”“事件理解”“跨时查询”三个级别再决定它们分别交给谁。2. 七种协同方案逐一拆解2.1 方案一YOLO做检测、VLM做问答的双通道方案这是最直观也最容易起步的方案。YOLO持续跑视频流把检测结果时间戳、类别、坐标、置信度转成文本写入数据库用户发起自然语言查询时先通过RAG检索相关文本片段再把上下文交给VLM生成最终回答。相当于YOLO负责“记录”RAG负责“找档”VLM负责“答复”。这个方案的优点是架构简单链路短任何一个模块都能独立替换最适合先跑通业务闭环。比如我在一个园区访客系统里用YOLOv8检测人、车、闸机状态把数据写进PostgreSQL查询侧用向量库召回“前一天下午有没有货车进入3号门”这类问题。实际跑下来检测部分实时性完全没问题VLM只处理单条文本成本非常低。缺点也很明显VLM读不到画面只能看文字描述所以它回答不了“那个人的衣服颜色是什么”这类需要视觉证据的问题。它的视角被YOLO的输出格式限死了“看见什么才记录什么”是这套方案的天花板。适合对语义深度要求不高的场景比如客流统计、车辆计数、区域入侵告警。2.2 方案二YOLO粗检 ROI裁剪 VLM细粒度识别这个方案是目前工程上用得最多的。YOLO先做全图检测找到“可疑目标”所在的区域然后把这些区域按坐标裁剪成小块单独交给VLM做细粒度识别。这样做的好处是VLM只看被裁剪出来的局部图输入分辨率可以放大计算量却比全图分析小一个数量级。举个实际案例仓库托盘货品盘点。YOLO检测出托盘和叉车但货品包装上的品名、批次、破损状态YOLO是识别不了的。我把每个托盘区域裁剪成512x512的小图批量送给Qwen2.5-VL让它输出“货物破损”“外箱变形”“批次号BN20250318”这样的结构化结果。一次采样周期约30秒7B量级的VLM处理8个托盘区域大概需要3到5秒在产线上完全能接受。这个方案的难点在于窗口大小怎么定。YOLO框得紧了会把关键上下文裁掉框得松了多余的背景会干扰VLM判断。我后来在检测框的基础上按1.3到1.5倍率向外扩效果明显比紧贴框裁剪稳定。另外裁剪出来的是JPEG小图建议直接存入本地缓存方便后续重新送VLM复查避免重新解码整段视频。2.3 方案三YOLO骨干特征 VLM跨模态对齐的紧耦合到了这个方案就不是“两个模型各自跑完再接起来”了而是把YOLO的骨干网络当作特征提取器把提取出的中间特征图直接送给VLM的视觉编码器。这样YOLO学到的空间位置信息、多尺度特征能和VLM的语义空间对齐理论上比裁剪拼接更“聪明”因为模型能看到全图的上下文而不是被裁出来的碎片。但我必须说这个方案的工程代价相当大。你要么改VLM前向代码把原本读图片的入口改成读特征张量要么用自定义模型并行把YOLO的neck输出和VLM的encoder串起来。两条路都涉及大量自定义算子而且很难用现成的推理框架直接上线。我做实验验证时发现在公开数据集上它确实比方案二的效果平均好2到4个点但部署成本和调试难度同样翻倍。所以我的建议是除非你的场景确实需要“全图空间依赖”比如要判断“人有没有靠近危险区域”这种必须结合整体布局的任务否则方案三更适合留给实验室研究。生产环境里如果实在需要这种能力可以退一步用方案二加“上下文小图目标大图”的拼接输入效果接近工程量少很多。2.4 方案四RAG语义先验驱动YOLO的自适应检测顺着“RAG只是记忆模块”的思路往前伸展一点RAG还能反过来指导YOLO干活。这套方案的核心是先把场景的类型、摄像头的位置、常见目标的语义本体存入RAG库当某一帧被判定为场景A时RAG检索出场景A对应的“检测偏好配置”动态调整YOLO的类别过滤、置信度阈值甚至辅助提示词。举个例子园区里有一个监控点位对着交叉路口另一个对着装卸区。对路边摄像头车辆检测的置信度阈值可以放到0.5关注的是“小车通过”对装卸区阈值降到0.3并且优先关注“货车”“叉车”“托盘”这三类。传统做法是人工为每个点位写死一套参数RAG方式则是从Ontology RAG库里自动检索出场景对应的语义规则然后下发给YOLO执行。这样做的好处是新增一个点位时运营人员只需描述摄像头场景系统会自动匹配检测策略不用再手调参数。实际开发时语义本体我建议用JSON组织类别名、阈值、优先级、联动动作都有固定字段。检索出来之后通过一个轻量配置引擎转成YOLO的输入参数即可。这个方案本身不改变YOLO的能力但显著提升了多场景部署时的运维效率特别适合监控点数量多的项目。2.5 方案五关键帧提取 场景摘要 时序RAG前面几个方案基本都在做“单帧或局部区域”的分析这套方案的野心更大一点让系统具备“时间线记忆”。核心流程是视频流先经过YOLO做运动目标检测当画面里目标出现明显变化时截取关键帧这些关键帧被分批送入VLM生成场景摘要摘要里包含“谁、在哪、什么时间、做了什么”摘要文本经过结构化处理后写入RAG索引库查询时用户可以用完整的自然语言比如“今天上午九点到十点3号门有没有叉车卸货”。这套方案的关键在于“关键帧怎么挑”。我试过固定间隔采样、帧差法、光流法、YOLO目标面积变化率判断综合下来最简单稳定的是“运动量评估目标出现/消失事件”组合。YOLO在跟踪过程中如果目标的IOU、类别、置信度发生显著变化或者目标进入/离开画面就触发关键帧。这种方法比固定间隔采样减少约70%的冗余帧比光流法快得多也无需额外算力。时序RAG的实现需要注意时间维度。常规文本RAG只按相似度检索但视频事件查询极依赖时间条件。我的做法是每个事件Entry里单独存一列时间戳检索时先用时间过滤再做向量召回同时支持倒序输出。这样“上午九点到十点”这种时间范围查询就能精确命中而不是靠向量相似度“猜”。2.6 方案六视频事件检索的Hybrid RAG视频事件检索里最让开发头疼的问题是“相似但不相关”的误召回。比如用户问“电瓶车进电梯”向量检索可能会把“自行车停在楼道”也召回因为语义距离很近。这里就需要Hybrid RAG出场稠密向量负责语义召回稀疏检索负责关键词精确匹配最后再接一个重排序模型。在工程实现上我用Milvus作为向量库同时启用了Dense和Sparse两种索引。Dense部分用bge-m3输出1024维向量Sparse部分用BM25概率权重表征关键词。查询阶段两边各召回TopK合并后输入Reranker模型可以选bge-reranker-base重新排序。实验下来混合检索的Recall10比纯Dense高出约15%到20%尤其对事件类查询——它们大多包含明确的目标词比如“叉车”“托盘”“门禁”——效果提升特别明显。这套方案的定位更偏“事后取证”而不是“实时告警”。视频保留7到30天的行业里用户经常需要回查某个具体事件Hybrid RAG基本成了标配。需要注意Reranker是按单卡算力计费的长视频项目如果每日新增片段多建议离线批量重排把重排结果存储下来在线只查已经排好序的TopK即可。2.7 方案七Agentic RAG自主编排最后一个方案是最近半年特别火的方向Agentic RAG。它不再把RAG当作一个被动的“检索接口”而是把YOLO、VLM、向量库统统暴露成工具让一个大模型Agent根据用户意图自主规划调用链。比如用户问“昨晚监控里有没有异常情况”Agent会自己决定先调YOLO统计目标数量再调VLM分析几个关键帧的画面最后调RAG查询一下历史事件记录作为上下文。这背后的核心变化是决策权转移。传统方案里“用什么模型、按什么顺序”是开发写死的Agentic方案里模型自己判断“该用哪个工具”。我在实验里用LangGraph搭了一个简单的编排框架定义了“视频分析Agent”“图像理解Agent”“检索Agent”三个节点用户查询进入后由调度模型决定走哪个分支。实测下来对复杂查询效果很好比如“帮我找一下昨天下午最混乱的十分钟”这种模糊意图它能自动分解成“检测目标密度→生成算力消耗曲线→检索相关事件→汇总描述”四步最终输出结构化报告。但这个方案的最大问题是不稳定。Agent偶尔会组合出无效调用链而且当工具数量超过5个时决策准确率显著下降。我的经验是限制Agent的工具数量不超过4个且每个工具输入输出都用严格的JSON Schema约束同时增加一层“计划审核”机制如果Agent生成的调用链明显不合理就退回套用标准流程。生产环境建议把这个方案定位为“高级分析模式”默认系统走前面提到的固定链路只有用户发起复杂时再切换Agent模式。2.8 七种方案怎么选对比速查表方案核心链路实时性语义深度时序能力工程难度典型用途方案一YOLO→文本→RAG→VLM问答高低中低客流统计、车辆计数方案二YOLO裁剪→VLM细识别中中低中工业质检、属性识别方案三YOLO特征→VLM对齐低高低很高空间感知、复杂行为方案四RAG语义→YOLO配置高中低中多监控点位自适应方案五关键帧→VLM摘要→时序RAG中高高中高园区事件回溯方案六YOLOVLM混合检索→重排低高高中历史视频检索方案七Agent编排所有工具低很高高高复杂意图理解选型时我一般先问三个问题能不能容忍几秒延迟要不要时间线查询有没有专门的GPU跑VLM全都不满足就只能走方案一大部分满足就选方案五或六需要极致语义就上方案七。3. 核心细节解析与实操要点3.1 YOLO选型与部署这么多版本怎么挑很多人问“yolo第几代了”目前社区里主流的是YOLOv5、YOLOv8、YOLOv9、YOLOv10和YOLOv11。YOLOv5虽然“年龄”偏大但生态最成熟插件、教程、训练平台都最全YOLOv8是工程化标杆Ultralytics官方维护支持检测、实例分割、姿态估计、跟踪目前最推荐作为基线YOLOv9引入了可编程梯度信息小模型精度有一定提升YOLOv10主打无NMS设计推理时省掉了一部分后处理但配套生态还没有v8丰富YOLOv11是最新发布速度更快精度更高在边缘设备上表现很亮眼。部署时考虑的往往不是模型精度而是推理框架和硬件。NVIDIA卡上我优先用TensorRTYOLOv8n导成FP16在一张RTX 3060上单帧只要2到3毫秒Jetson Orin上也就10毫秒上下完全满足实时需求。AMD显卡跑YOLO这几年轻松了不少主要靠ROCm和ONNX Runtime的ROCm EP我自己在RX 7800 XT上试过YOLOv8s性能大约是同级别N卡的八成能用但要注意驱动版本。纯CPU部署的话YOLOv5s在i5-12400上大约能跑15到20帧足够低分辨率视频流。训练自己的数据集时标注环节容易卡人。数据标注我推荐用CVAT开源自托管支持视频帧标注和多边形标注如果手上已经有KITTI标注转YOLO格式需要用Python脚本把3D框投影到2D图像平面或者直接用现成的“kitti_to_yolo”开源转换脚本。标注完成后每个类别建议至少准备2000到5000个实例小模型YOLO11n可以适当少一些但要特别注意类别不均衡问题。训练超参里最容易影响结果的是学习率和损失函数YOLO的损失由分类损失BCE、框回归损失CIoU和DFL组成初期建议保持默认的CIoU权重而分类损失的weight偏大时容易导致误检我通常会调小一点。整个目标检测流程除了“模型前向推理”之外后处理同样是关键环节。后处理包含阈值过滤、NMS非极大值抑制和类别映射。很多初学者只改置信度阈值NMS的IoU阈值却没动实际上人的阈值和框的IoU阈值要配合调整检出目标太密时优先调低NMS阈值0.45到0.5漏检多时调低置信度阈值而不是硬调NMS。实测下来这两个参数对检测效果的调节作用往往比换一个模型版本还明显。如果是做多目标跟踪还需要在意yolo多目标跟踪的指标怎么得到。业界常用的指标是MOTA、IDSWID Switch和IDF1MOTA衡量整体跟踪准确率IDF1则更关注身份保持能力。要计算这些指标需要把你的跟踪结果和真实轨迹按帧对齐然后用py-motmetrics库算MOTA这一步要特别注意时间戳对齐否则id错位会导致IDSW骤然增加指标数值很难看。3.2 VLM的接入与微调实操VLM接入的方式五花八门但大体上分三类闭源API、本地部署、微调定制。闭源API最省事GPT-4V和市面上主流国产视觉大模型接口都可以直接调用但视频监控这类场景涉及大量连续帧和隐私数据很多项目不支持把画面送外部服务。本地部署首选Qwen2-VL、InternVL2、MiniCPM-V、LLaVA这类开源模型显存要求各不相同1.8B到4B的小模型在8G显存能跑7B到8B级别建议至少16G显存72B级别的就得A100了。我推荐的组合是Qwen2.5-VL-7B作为主力模型它在中文场景理解、OCR和细粒度识别上比较均衡7B量级在单张4090上也能稳定出结果。如果通用VLM识别效果不尽人意常见操作是微调。开源微调框架里LLaMA Factory对VLM微调支持得很完整支持QLoRA、全参微调和多模态数据格式。数据准备上视频分析场景最常用的是“图像路径对话”的JSONL格式关键是把YOLO裁剪出来的真实样本整理成“这是什么物品”这样的指令对。我一般用QLoRA微调一个7B模型学习率设置为2e-4rank为16在单卡4090上训练1到2个epoch就够收敛。微调后除了关注loss数值一定要单独验证OCR和细粒度分类两个能力是否出现灾难性遗忘。如果发现原来能识别的类别反而变差了需要降低学习率并把原始通用数据按3:1比例混进训练集。需要注意的是VLM的输出通常是不稳定的。同一个画面两次调用返回的文本可能措辞不同这对后续RAG入库是隐患。我的解决办法是在Prompt里要求严格的JSON输出同时用pydantic写校验器做后处理解析失败就重试一次。这样入库的摘要结构统一检索效果也会稳定很多。3.3 RAG检索链路与视频数据的分块策略RAG常见的坑是把文本RAG的习惯直接套到视频分析上。文本RAG的核心是“分块”切小了语义不全切大了检索噪声大视频分析的数据来源更杂有YOLO输出的结构化记录、VLM生成的摘要、用户的查询、甚至还有音频转写文本不能一概而论。我采用的分块策略是“事件分块”。无论是YOLO检测结果还是VLM摘要都有一个共同的元组时间戳、摄像头ID、目标ID、事件类型。我按照“一次持续交互”作为一个事件单位比如某个人从进入画面到离开画面这期间的检测框和摘要归为一个Chunk。这样做有两个好处其一检索结果天然带有完整的上下文不会出现“只搜到半个人”其二后续做时间线回溯时可以顺滑地按事件组织展示。如果必须按文本长度分块我把tokens控制在128到256之间并且强制确保一个时间粒度比如5秒内的事件不会被切到两个块里。向量化模型我长期用的是bge-m3。它最大的好处是同时支持稠密向量和稀疏向量一个模型搞定两种索引不需要额外搞一套BM25。Milvus是社区用得最多的向量数据库Python pymilvus可以快速构架一套RAG知识库。建Collection时我建议把id、时间戳、摄像头ID、事件文本、向量这几列分好字段索引类型用HNSWM值设为16efConstruction设为64这样查询速度和精度比较均衡。如果视频量巨大可以按天建分区检索时先指定分区能大幅减少扫描数据量。RAG框架的选择上生产环境我推荐LangChain或LlamaIndex但绝不建议为了“用框架”而引入框架。如果只是做一个内部工具直接写Python脚本调用pymilvus和VLM接口完全够用至少省了各种依赖冲突和回调地狱。只有要接Agentic RAG才值得上LangGraph这类编排框架。搜到的热门方案里“基于RAG的智能客服”“基于RAG的智能菜谱”本质都是“检索生成”视频分析场景的差异只有一点记忆对象从纯文本变成了事件摘要和检测属性的混合体。4. 实操过程与核心环节实现4.1 搭建一个最小可用系统端到端流程演示我拿一个真实的“园区关键区域视频查找”项目来做示范。需求很简单摄像头实时分析能回答“今天下午有没有人出现在卸货区的叉车旁边停留超过30秒”。第一步用YOLOv11n做实时检测和跟踪。我从视频流里按每2帧抽一帧送入模型检测到人、叉车这两个类别后就记录坐标和ID不直接把所有帧写入存储。from ultralytics import YOLO import cv2 model YOLO(yolo11n.pt) cap cv2.VideoCapture(rtsp://your_camera_stream) frame_id 0 events [] while True: ret, frame cap.read() if not ret: break if frame_id % 2 ! 0: frame_id 1 continue results model.track(frame, persistTrue, conf0.35, iou0.5, classes[0, 7]) if results[0].boxes.id is not None: for box, cls_id, track_id in zip(results[0].boxes.xyxy.tolist(), results[0].boxes.cls.tolist(), results[0].boxes.id.tolist()): events.append({ frame: frame_id, ts: int(cap.get(cv2.CAP_PROP_POS_MSEC)), track_id: int(track_id), cls: model.names[int(cls_id)], bbox: [round(x, 1) for x in box] }) frame_id 1第二步做事件判定。当检测到“人”track_id与“叉车”track_id并存的帧数超过连续30秒时触发一次关键帧保存。这里注意因为视频是抽帧的判定“30秒”不能按帧数直接算要用时间戳字段也就是代码里的CAP_PROP_POS_MSEC否则抽帧策略一变逻辑就废了。第三步触发一次VLM分析。把触发时刻的前后6帧关键帧拼成一张2x3的网格图送VLM让它输出结构化的场景摘要。我的Prompt是“你是仓库安全分析助手请描述画面中人员和叉车的互动情况按JSON格式输出{has_person, has_forklift, duration_seconds, description}”。VLM返回结果经过schema校验后和YOLO的检测数组一起组成一个事件记录。第四步入库Milvus。这部分我用pymilvus直接操作把事件描述用bge-m3生成向量连同时间戳、摄像头点位、事件ID一起写入Collection。from pymilvus import connections, Collection, utility from sentence_transformers import SentenceTransformer connections.connect(hostlocalhost, port19530) collection Collection(video_events) encoder SentenceTransformer(BAAI/bge-m3) vectors encoder.encode([event_desc])).tolist() data [ [event_id], [camera_id], [unix_ts], [event_desc], vectors ] collection.insert(data)4.2 在线查询从自然语言到结果展示查询侧的处理相对直接。用户输入“下午装卸区有没有人靠近叉车超过30秒”系统先把自然语言解析成“装卸区”“人”“叉车”“30秒”这几个检索要素。时间要素用来过滤分区语义要素生成向量做ann搜索最后把命中的事件记录给VLM让它组织成自然语言回答。这一套流程的实际推理速度是YOLO每帧2到5毫秒关键帧触发VLM每次约1到2秒RAG在线查询单次约50到100毫秒。这里有个体验上的优化点VLM分析是异步发生的也就是检测到事件先落盘提示“分析中”后台再异步生成摘要这样告警的实时性不依赖VLM速度。代码层面建议用FastAPI包一层接口把YOLO推理循环常驻内存通过Redis队列把关键帧发给VLM worker。我把整个应用拆成三个进程视频采集推理进程、VLM事件分析进程、RAG查询API进程通过消息队列解耦。这样任何一个进程挂了都不影响其他模块尤其推理进程和VLM进程之间强烈建议解耦VLM推理非常慢如果同步调用会卡死整条检测链路。4.3 训练与标注链路的最佳实践如果项目要检测的是私有目标比如“货架缺货”“托盘倾覆”就得训练自己的YOLO模型。整个链路我建议这样走先用CVAT做视频标注把目标框出来并且给实例ID用视频标注模式比单张标注效率高一倍以上导出YOLO格式后检查一下标注的txt文件确认框坐标是归一化且类别索引正确训练用Ultralytics命令行config里主要调imgsz640epochs100batch16这些起步参数是我试过最稳的。训练过程中要盯两条曲线train/box_loss和val/box_loss。如果val的box_loss在后期反而上升说明过拟合了我会停止训练并采用最后10轮的平均权重做推理。如果怀疑标注质量有问题用t-SNE可视化嵌入再把高置信度误报样本导出图片人工复查。这一套下来训一个定制目标检测模型通常两三天可以完成关键点在于标注一致性——同一个模糊目标两个人标得不一样模型学起来一定混乱。5. 常见问题与排查技巧实录5.1 运行时问题检测、显存与延迟问题现象是“YOLO检测时好时坏同一个目标有时有框有时没有”排查时先看置信度阈值和NMS IoU是否搭配合理再看跟踪器是否导致ID频繁切换。YOLO做跟踪时我用的是ByteTrack或BoT-SORT它们都依赖检测结果质量如果检测目标太密集建议把跟踪的match_threshold调低一点并开启帧间插值能有效改善ID跳变。VLM占用显存过高常见原因是输入图像过大。7B模型输入1024x1024单次就要占用约14到16G显存如果把多帧拼成大图显存更是爆炸。我的经验是把输入图控制在768x768以内同时开flash-attention2和bitsandbytes量化到4bit显存能压到6到8G。如果还是不够就用MiniCPM-V这种1.8B小模型替代7B。延迟问题的根源几乎都是“同步调用”。视频分析项目不应该让推理进程等VLM或者数据库返回所有慢操作都应该是异步的。我踩过最狠的坑是当时直接把Milvus插入操作写在检测主循环里导致单帧耗时从5毫秒涨到200毫秒画面直接卡成PPT。后来改成一切网络请求走队列主循环只处理纯计算延迟立刻恢复了。5.2 检索与问答问题召回差、时序乱、VLM乱答RAG召回不全时十有八九是embedding模型和查询词不匹配。bge-m3这类多语言模型对短查询效果还行但如果你输入的是“下午装卸区有没有人长时间靠近叉车”我建议在查询侧也做一次轻量的query rewrite提取出核心实体装卸区、人、叉车、长时间再检索效果提升很明显。更进一步的方案是走Hybrid RAGDense和BM25双路召回再把结果合并重排召回率能再提升一截。时序乱是视频RAG特有的问题。向量检索只看语义相似度不care时间顺序所以“上午九点发生的事”可能排在“下午三点”后面。我在Collection里除了存unix时间戳还会多存一个时间partition在查询时强制按partition过滤排序用时间倒序这样能保证“时间线”正确。真正的痛点在于“跨天查询”比如“上周盘点完那天之后有没有异常”这种查询必须先做一个时间实体解析把“盘点完那天”映射成具体日期范围否则只能靠VLM瞎猜。目前没有太通用的方案我一般建议业务侧把这种模糊事件做成明确的“事件标签”入库时打标查询时匹配标签虽然“智能”程度差一点但稳定。VLM乱答是最让人头疼的。输出幻觉、答非所问、把检测框当成真实存在的人物——我踩过无数次。根本原因是VLM的能力边界被后续流程盲目信任。我的处理方式分两步第一Prompt里强制输出“无法判断”选项并告诉模型“不确定就说不确定”能显著减少硬编答案第二在RAG召回阶段如果召回结果置信度低于阈值直接返回“未找到相关事件”而不是硬凑一段回答。前者能在模型层减少幻觉后者能在架构层兜底。5.3 成本与性能优化清单最后总结一下我在多个项目里验证过的成本优化手段。第一YOLO推理层永远用TensorRT FP16或INT8不用PyTorch裸跑性能差距是数量级的第二VLM尽量按批处理把多个关键帧合并成一批送模型耗时比一个一个送至少省40%第三RAG向量库务必做数据生命周期管理超过保留期的数据定期归档否则检索性能会随着Collection膨胀持续下滑第四如果VLM只在特定时间段需要分析比如晚上10到早上6点直接在调度层做时间开关省钱效果立竿见影。这套系统已经在一个30路摄像头的园区稳定跑了三个月实测下来单路日均GPU占用不到30%检索平均响应时间在200毫秒内满足大部分生产需求。最后再多说一句个人体会这类项目的成败八成不取决于哪个模型更准而取决于你把YOLO、VLM和RAG三者的“边界”划得清不清楚。每一层只干自己最擅长的事别让VLM去追帧别让RAG去补视觉别让YOLO去理解长句子系统自然就稳了。真做到这几点后面加需求、换点位、扩数据你都只用改配置不用推翻重来。