先说结论这个方案真正解决的不是“彻底不写代码”而是把智能监控系统里的“场景判断逻辑”从硬编码中解放出来用 YOLO、VLM、RAG 和 Prompt 四样东西重新分工。YOLO 负责看见目标VLM 负责看懂画面RAG 负责把业务规则和现场知识喂给模型Prompt 则像一条总线把这三者的结果串成最终结论。适合谁看准备用大模型改造监控系统又不想频繁改代码的开发者、算法工程师、运维人员。最值得关注的一点是这种架构下换一个监控场景往往只需要换检测类别、换提示词、换知识库而不是推翻整个程序。不过我先要泼一盆冷水网上说“不写代码只写 Prompt”很容易让人误解。实际落地时你还是要写少量 Python 脚本来做视频流读取、模型调用、结果组装和告警推送。真正能省掉的是那些“什么情况要告警、告警级别怎么定、在什么区域做什么判断”这类频繁变化的业务规则代码。下面按我实际踩坑的顺序完整拆一遍。1. 为什么监控系统要同时用 YOLO、VLM 和 RAG 三个东西1.1 传统监控方案最容易在三个地方出问题第一是规则写死。传统物体检测模型只输出“哪个位置、什么类别、多少置信度”没有场景理解能力。比如“一个人在车间门口站了 10 秒”检测模型只知道有 person 和 door不知道这个行为可能异常。要判断异常通常得在代码里写距离、时长、IOU 交叉、区域关系逻辑一多就难维护。第二是误报多。摄像机角度一变、光线一变、遮挡一多固定阈值就开始乱报。很多项目为了降低误报只能不断加判断条件最后代码变得非常复杂。第三是换场景成本高。上一个项目做安全帽检测下一个项目做车辆逆行虽然 YOLO 部分重新训练数据就行但告警规则、输出描述、目标对象关系全都要改代码。1.2 三者分工看见、看懂、查规则在这个架构里YOLO 做的是“看见”。它从图像或视频帧中检测出目标边界框、类别和置信度。YOLO 的响应快几毫秒到几十毫秒就能完成一帧检测适合做第一级筛选。我一般会给它配置一个较低的置信度阈值比如 0.25 到 0.4宁可多检测出一些候选目标也不要漏掉关键对象。VLM 做的是“看懂”。给它一张图和一段检测结果文本它能描述人物是否倒地、人群是否聚集、有没有人在禁入区域逗留、流程动作是否合规。VLM 的价值是能处理“模糊语义”这是固定规则很难做到的。RAG 做的是“查规则”。每个监控现场都有自己的规则比如园区规定、实验室安全规范、车间操作流程。RAG 把这些规则切块、向量化在需要判断的时候把最相关的规则片段检索出来拼到 Prompt 里让 VLM 不是凭通用常识瞎猜而是依据真实文本做判断。这就是“监控系统的记忆库”。1.3 Prompt 不是魔法是接口协议很多人把 Prompt 理解成一段“跟模型说好话的咒语”其实不对。在这个系统里Prompt 是 YOLO、VLM、RAG 之间的数据协议。检测结果要转成自然语言VLM 才能理解业务规则要从知识库检索拼到 Prompt 里VLM 才有依据VLM 输出必须按照约定的 JSON 结构返回后面的告警模块才能稳定解析。所以设计 Prompt 的核心不是“让它聪明”而是“让它稳定、可解析、可替换”。你越早把 Prompt 当作接口来看待后面调试就越轻松。2. 系统结构和数据流设计2.1 六个模块串成一条流水线我建议把整个系统拆成六个模块每个模块只关心一件事模块职责输入输出视频源接入读取摄像头或视频文件RTSP、本地文件、图片列表图像帧目标检测YOLO 推理图像帧、模型路径检测框数组观测文本生成把检测框转自然语言检测框数组、Prompt 模板一段文本视觉语言理解VLM 判断画面事件图像、观测文本、Prompt结构化事件 JSON规则检索从知识库召回规则场景类型、事件类型规则片段决策输出生成告警或记录事件 JSON、规则片段、Prompt告警级别、原因、建议模块之间不要混在一起。尤其是 VLM 的调用和知识库检索必须独立写否则以后换模型、换向量库都很麻烦。2.2 关键约定每一层的数据长什么样我先说 YOLO 输出。常见的检测结果是这样的[{class: person, box: [120, 300, 560, 760], conf: 0.87}, {class: helmet, box: [180, 310, 220, 350], conf: 0.72}]如果直接把这段数组丢给 VLM模型能看懂一点但不稳定。尤其是坐标非常多、目标非常密集的时候VLM 会失去重点。我建议先做一次压缩只保留当前帧里有哪些类别每类目标多少个置信度最高目标的大概位置目标之间的空间关系比如“一个 person 在禁入区域 polygon 内”这一步可以用 Prompt 让一个轻量文本模型做也可以自己在代码里写 30 行规则。实际项目中我倾向直接用代码生成因为没必要让大模型做简单的格式化。2.3 为什么要把检测结果转成自然语言很多第一次接触这个架构的人会问YOLO 已经有坐标了为什么还要绕一道转成文本原因在于 VLM 的输入接口。虽然多模态 VLM 可以直接看图但如果图里有大量目标模型并不知道你要关注哪几个。提前检测出来把关键目标、位置关系写成文本实际上是在告诉 VLM“重点看这些东西。” 这既降低了模型推理难度也减少了幻觉。从实测看同样的阈值设定加上了检测文本引导之后VLM 对“是否倒地”“是否在区域内”“是否有异常聚集”的回答稳定性会明显高不少。3. 环境与基础依赖准备3.1 本地运行条件与推荐配置不要相信“任意电脑都能跑”。一个完整的 YOLO VLM RAG 链路至少需要一块能跑 CUDA 的显卡或者一个能访问大模型 API 的网络环境。本地部署的 VLM 通常对显存要求比较高。更稳妥的最小配置可以按这个思路判断纯 CPU 环境可以跑 YOLO 和 RAG但 VLM 要选量化版本或小模型识别速度会很慢建议先做单帧测试。8GB 左右显存适合跑 YOLO本地 VLM 可以用 7B 到 8B 级别的量化模型单张图推理几秒到十几秒。16GB 以上显存可以跑更大参数模型批量处理也会更稳。纯 API 方案本地只需要准备 Python 环境和向量库显存压力小但要注意接口超时和调用成本。原始材料里没有给出固定版本落地时先确认 Python 版本、CUDA 版本、模型权重格式再装依赖。我最常遇到的坑是torch 版本和 CUDA 不匹配模型加载不报错一推理就崩。3.2 模型选型YOLO、VLM、向量库怎么选YOLO 这边优先选成熟、社区资料多的版本比如 YOLO 系列的官方或主流复现项目。如果你要检测的类别很特殊比如“冒险岛数据集”那种游戏截图检测就要用 YOLO 重新训练如果只是人、车、安全帽、烟火这类常见目标直接用预训练权重加少量微调就够了。VLM 有两种选法。一是调用云服务例如支持视觉输入的通用大模型 API优点是省部署、效果稳定缺点是每张图都有成本还会受内容安全策略影响。二是本地部署开源 VLM比如常见的 Qwen2-VL、InternVL、LLaVA 系列优点是数据和成本可控缺点是部署比 API 麻烦。我建议学习和验证阶段先用 API跑通了再决定要不要换成本地。向量库选型可以从简单开始。单机小项目用 Chroma、FAISS 就够了如果规则量很大、并发高再考虑 Milvus、pgvector。这里不要一开始就上分布式规则文本几千条以内单机向量库完全能扛住。3.3 首次联调的最小目录结构下面是一个参考结构按这个拆分目录会清爽很多monitor_system/ configs/ system.yaml prompts/ compress_prompt.txt vlm_judge_prompt.txt rag_final_prompt.txt detectors/ yolo_detector.py vlm/ vlm_client.py rag/ kb_loader.py retrieval.py pipeline/ single_frame_pipeline.py video_pipeline.py outputs/ alerts/ logs/ main.py配置、提示词、代码分开是这批项目里最重要的习惯。因为后面你会频繁调整 Prompt如果 Prompt 硬编码在 Python 字符串里每次改动都要重新发布代码很容易出错。注意不要一上来就追求目录完整先建好 configs、detectors、vlm、rag、pipeline 这五个目录就够了其他等运行到再加。4. 核心 Prompt 设计从检测框到监控结论4.1 第一段 Prompt把检测框压缩成观测文本这一步的目标是生成一段“画面事实描述”不需要判断不需要推理只做信息压缩。以下是一个参考模板你是一个视觉检测结果整理助手。我会给你一段目标检测结果请整理成简洁的中文现场描述。 要求 1. 只描述事实不推测意图。 2. 按类别整理数量例如“检测到 3 个人、2 辆汽车”。 3. 如果检测框包含坐标简述主要目标的位置关系。 4. 不要输出 Markdown最多 80 字。 检测结果 {{detections}}实际验证时你会发现这一步不会经常触发模型调用。因为如果只是坐标格式化用 Python 生成更快。只有当你希望模型理解“人在围栏左侧、车在围栏右侧”这类空间语义时才需要模型介入。4.2 第二段 Prompt让 VLM 判断事件这是整个链路里最关键的一段。VLM 要同时看图片和文本判断是否发生异常事件。参考模板你是一名园区安防监控分析助手。请根据摄像头画面和检测描述判断是否存在需要关注的行为。 重点关注 1. 人员跌倒、长时间倒地 2. 人员进入禁入区域 3. 未佩戴安全帽进入作业区 4. 人员异常聚集或奔跑 5. 车辆逆行或违停 请严格按以下 JSON 格式返回不要输出其他内容 {is_alert: true或者false, event_type: 事件类型没有则为 null, confidence: 0到1之间的小数, reason: 判断依据不超过50字} 检测描述 {{observation_text}} /检测描述这里有一个非常重要的设计点把“重点关注哪些事件”写进 Prompt而不是靠模型自己猜。监控需求本来就因场景而异把事件清单做成配置项换场景时只改这段文本就行。4.3 第三段 Prompt把 RAG 知识应用起来当 VLM 判断可能发生了事件就需要检索规则来确定要不要告警。RAG 的检索结果会拼成一个“安全规则上下文”然后让最终决策模块给出结论。下列片段来自当前场所的安全管理规则请作为判断依据 {{rag_context}} 刚才的视觉分析结果是 事件类型{{event_type}} 事件置信度{{confidence}} 画面描述{{observation_text}} 请判断是否应该告警并给出告警级别。告警级别分为 low、medium、high。 严格返回 JSON {should_alert: true或者false, alert_level: low/medium/high, reason: 为什么这样判断, suggestion: 给值班人员的建议}这里体现的就是 RAG 的价值。没有规则上下文时模型只会根据自己的常识判断“倒地可能要救人”接了 RAG 之后它知道“实验室走廊倒地被定义为 medium需要通知安全员不要直接拨打急救电话”。这就是监控系统的场景记忆。4.4 输出格式控制要求 JSON 是手段不是目的很多人在 Prompt 里写“请返回 JSON”但模型偶尔还是会把 JSON 包在 Markdown 代码块里或者额外解释几句。这不是模型笨而是提示词缺少约束。我验证下来比较有效的做法有四点明确“不要输出其他内容”在示例中给出完整 JSON 结构要求字段名使用英文值使用中文避免中文键名解析问题在代码层做一次容错比如去掉前后 json 标记、提取第一个大括号再解析如果解析仍然失败不要反复重试更不要试图用更长的 Prompt 压制模型。先把输出日志打出来看看模型到底返回了什么再针对性修改。关键经验VLM 输出不稳定时第一步是打印原始响应不要凭想象猜问题。5. 最小可行链路单帧图片先跑通5.1 单帧流程先用一张图走通我建议所有新方案都从单帧图片开始。原因很简单视频流里的问题很多调试困难单帧跑通了基本能看到 80% 的问题。执行顺序准备一张真实摄像头截图不要用网络上的理想图。用 YOLO 检测目标打印检测框。把检测结果转成观测文本。调用 VLM传原图和观测文本得到事件 JSON。根据场景类型检索知识库得到规则片段。调用最终决策 Prompt得到告警 JSON。人工核对模型判断是否符合常识输出是否可解析。5.2 一个极简调用示意下面是一个简化版的数据流示意不是完整生产代码但足以表达各部分如何拼接import json def run_single_frame(image_path, detector, vlm_client, retriever): # 1. YOLO 检测 detections detector.predict(image_path) print(检测框数量:, len(detections)) # 2. 检测结果转文本可以走代码也可以走轻量模型 observation format_detections_to_text(detections) # 3. VLM 判断事件 vlm_result vlm_client.judge(image_path, observation) event_data try_parse_json(vlm_result) # 4. 检索规则 rule_context retriever.search(event_data.get(event_type, default)) # 5. 最终决策 final_result vlm_client.final_decision(observation, event_data, rule_context) return json.loads(final_result)这里try_parse_json要自己写逻辑就是去掉多余内容、提取 JSON 片段、解析失败时记录日志。5.3 验证标准不能只看“跑不跑得通”单帧跑通后要按三个标准判断输出是否完整事件类型、置信度、原因字段是否都有。输出是否稳定同一张图跑三次结果是否一致。如果温度设置过高或 Prompt 太模糊结果会飘。耗时是否可接受一次完整链路是 1 秒、3 秒还是 15 秒。VLM 耗时往往是最大瓶颈。我通常会拿 10 张真实截图做小样本测试不追求一次调好只看哪几张错、哪些 Prompt 字段没有生效。6. 参数调优和监控指标6.1 YOLO 侧参数YOLO 推理时最常调的是置信度阈值和 NMS 阈值。建议从低置信度开始比如 0.25。因为最终判断由 VLM 负责YOLO 漏检反而更致命。宁可把一些背景目标传过去也不要让真正重要的人或车没被检测出来。如果目标非常多为了控制 VLM 上下文长度可以只保留置信度最高的 N 个目标一般 N 取 20 到 50 足够。这个数字不是越大越好目标太多VLM 会抓不住重点。6.2 VLM 侧参数VLM 的温度参数通常要调低我一般设置在 0.1 到 0.3 之间。温度高输出会更灵活但监控场景不需要创造性只需要稳定判断。max_tokens 不要给太小否则 JSON 经常被截断。给 300 到 800 比较合理。如果返回内容一直截断优先看是不是检测目标太多、观测文本过长而不是只调 max_tokens。图像输入分辨率也要控制。很多 VLM 对过大的图片会做缩放目标细节可能丢失。可以先把图像裁剪到检测目标附近区域再传给 VLM比直接全图传更有效。6.3 RAG 侧参数RAG 在监控系统里的核心参数有三个分块大小、检索数量、相似度阈值。分块大小影响规则召回。按段落或按条目切分通常比按字符硬切更好。安全规则往往是“如果……那么……”结构硬切容易把规则切断导致模型误判。我建议先按条切每条不超过 200 字不够再细分。检索数量 top_k 在 3 到 5 左右比较合适。太多会让 Prompt 过长模型反而抓不住重点太少则可能漏掉关键规则。相似度阈值不要设太高0.5 以下可能召回无关内容0.7 以上可能漏召建议先用 0.6 左右试跑一批场景再调。6.4 整体灵敏度怎么调整条链路的灵敏度不是单个模型决定的而是多个阈值叠加YOLO 置信度低 → 更多候选目标VLM 判断事件越多 → 被 RAG 检索的次数越多RAG 阈值低 → 更多规则参与决策最终决策 Prompt 里“事件类型”决定哪些组合该告警这也就意味着如果你想要系统少报警不要只调一项要看哪一层过滤掉了关键信息。我一般先固定 YOLO 和 RAG 参数通过调整 VLM 的“重点关注事件”清单来控制灵敏度效果最直观。7. 从单帧到视频流批量化和稳定性处理7.1 抽帧策略不要把每一帧都送进 VLM视频流场景里最大的问题是成本和时间。YOLO 可以每秒跑 20 到 30 帧但 VLM 每帧都要跑的话再强的机器也不够用。常见的抽帧策略有三个固定间隔抽帧比如每 2 秒取一帧适合人员走动不频繁的场景。变化检测抽帧先计算相邻帧的像素差异或 YOLO 目标位置差异变化大时再送 VLM。事件触发抽帧当 YOLO 检测到某个目标进入某个区域或目标突然消失时立刻触发 VLM 分析。我在实测里更喜欢先做项目内差异检测再做固定间隔兜底。因为固定间隔在高动态场景会漏事变化检测在静止场景能省大量资源。7.2 队列与并发不要一上来就开最大并发很多人把摄像头并发数直接开到 8、16然后整个程序崩溃。VLM 推理和 API 调用都有并发上限盲目开线程只会让超时和报错越来越多。更稳的路线是先单路视频跑通测量一次完整链路耗时再开两路并发稳定后再逐步增加。每一路视频建议使用独立的队列抽帧线程只负责往队列塞帧VLM 工作线程从队列取任务。这样即便某一帧分析很慢也不影响视频读取。并发数的经验值如果单帧完整链路耗时 3 秒4 路并发意味着每秒约 1.3 帧需要分析普通显卡压力不算大如果单帧耗时 15 秒2 路并发就可能排队严重。7.3 失败重试与输出时序视频流不是跑一次就结束。它会产生大量的中间结果必须考虑失败重试和告警去重。失败重试要区分错误类型。VLM 返回内容安全策略拦截、超时、网络抖动处理方式不同。重试超过 2 次就跳过当前帧把错误写入日志不要死循环重试否则错误帧会阻塞后面所有任务。告警去重也很关键。同一个事件在连续 30 帧里反复出现不能发 30 次告警。我一般用“事件类型 目标位置 第一次出现时间”做指纹相同指纹只发一次直到事件消失超过一定时间再重新激活。7.4 人工复核把决定留给人这个架构最大的风险不是模型犯错而是模型犯错后直接推送给用户。要保留一道人工复核机制尤其是告警级别高的场景。我建议把系统的输出分成两层记录层所有分析和告警结果写入日志或数据库值班人员可以后续查看。推送层只有当最终决策置信度高于阈值并且符合规则库里的“必须告警”条目时才推送。如果模型连续多次给出不确定结论可以降低推送优先级而不是直接把不确定内容顶到首页。这比在 Prompt 里写一万遍“请谨慎判断”更可靠。8. 常见问题排查与避坑清单8.1 VLM 输出不是 JSON或者被内容安全策略拦截这是最常遇到的问题。打印原始响应后一般能看到两类情况一类是模型返回了 JSON 但外面包了 Markdown 代码块这个好处理代码里提取大括号范围即可。另一类是模型返回类似“您的提示词触发了内容策略拦截”之类的提示。这种情况通常不是模型能力问题而是输入图像或文本触发了安全校验。不要尝试用对抗性 Prompt 去绕过限制正确做法是调整输入材料把图像裁剪到有效的检测目标区域避免大范围背景噪声检查检测文本里是否包含“暴力”“攻击性”等敏感描述词用更中性、工程化的描述替代如果是本地模型确认输入图像尺寸是否超过限制在监控系统中我见过很多次“模型不回答问题”是因为输入图像里有人脸特写、血腥类比或模糊线索而不是模型坏掉了。提前做输入清洗比事后改 Prompt 更有效。8.2 RAG 检索不到或者检索到的内容完全无关先检查知识库的切块逻辑。如果你对整个 PDF 按 500 字硬切一条完整的安全规则会被切成两截检索时只召回一半模型自然判断不准。解决思路有两种改进切块策略先按段落分再按“如果……那么……”结构分尽量让一个语义单位保持完整。增加元信息每条规则都带上“适用区域”“适用角色”“事件类型”比如“regionlaboratory, eventfall”。检索时不只用向量相似度还能用元信息做一次硬过滤。这种方式比纯向量检索更稳也是目前很多项目把 RAG 和知识图谱结合的原因。如果规则不多还可以直接用“事件类型”做键值映射先检索再向量排序。不要为了 RAG 而 RAG简单规则用字典查也能解决问题。8.3 YOLO 漏检和重复告警漏检通常不是参数问题而是数据问题。摄像头角度和训练数据分布差太多就会发生漏检。不要只通过调低置信度来硬扛应该重新收集现场数据做微调。热搜词里也有“yolo训练”相关讨论YOLO 针对现场数据集做少量训练是监控项目里最常见也最有效的步骤。重复告警则是工程问题。不管是同一个目标连续触发还是多个摄像头看到同一个目标都要做跨帧、跨摄像头的去重。我的建议是引入一个轻量的目标跟踪状态比如 YOLO 检测结果加上跟踪 ID再用“跟踪 ID 事件类型”做去重而不是只用坐标做去重。坐标抖动会导致去重失效跟踪 ID 会稳定很多。8.4 性能瓶颈先分清是慢还是卡系统表现出的问题有两种一种是慢但最终能出结果另一种是卡死一直没有输出。这两者排查路径完全不同。慢的问题先打印每一层的耗时。YOLO 耗时多少、VLM 耗时多少、检索耗时多少用日志记录。通常瓶颈都在 VLM。解决方法依次是降低抽帧频率、裁剪图像、减少检测目标数量、用更小的模型、做模型并行。卡死的问题大概率是并发写冲突、无响应请求没有设置超时、队列积压导致内存爆炸。给 VLM 调用设置合理的超时时间比如 30 到 60 秒超时就按失败处理。给队列设置最大长度满了就丢帧而不是无限堆积。很多系统不是被模型拖垮的是被队列拖垮的。8.5 需要避开的“过度智能”最后说一个最容易踩的坑让 VLM 做太多判断。我见过有人让 VLM 直接统计人数、直接判断“这个人是员工还是访客”、直接预测“这个人下一步会做什么”。这些任务不是完全不能做而是稳定性很难保证而且在真实监控场景中错误成本太高。更稳妥的分层是YOLO 做定量检测代码做空间关系判断VLM 做语义判断RAG 提供依据。凡是“数量、距离、时长、是否进入某个多边形区域”这类能精确计算的问题不要让大模型回答凡是“这个行为是否会引起安全风险、结合规则该定什么级别”这类开放语义问题才值得用 VLM。把精确问题交给精确工具把模糊问题交给大模型是这套架构能稳定落地的关键。9. 这方案适合什么场景不适合什么场景9.1 适合规则复杂、场景多变、需要快速调整的监控场景我最推荐使用的场景有两个特点一是事件语义比较模糊比如“人员聚集”“行为异常”“流程不规范”传统规则写不干净二是业务规则会频繁变化比如不同园区、不同季节、不同活动期间告警要求不一样。典型例子园区安防检测人员闯入、车辆违停、异常聚集规则按园区单独配置。工业安全安全帽、工作服、禁区逗留、跌倒检测规则来自安全管理制度。实验室规范是否有人员操作、是否佩戴口罩、是否接近危险区域规则来自实验规范文档。交通辅助车辆逆行、行人闯区域等事件可先做人工辅助判断不建议直接闭环控制。这些场景有几个共同点结果可以接受秒级延迟人工复核成本可以承受规则文本容易整理。9.2 不适合实时闭环控制、责任判定、极端依赖稳定输出这套方案不适合对实时性要求极高的控制系统。比如自动门禁、紧急刹车、机械臂保护这些系统需要毫秒级确定性和可证明的安全性大模型的推理速度和不稳定性都满足不了。也不适合做责任判定类应用。比如认定“某个人造成了事故”“这是谁的责任”这类问题对可解释性和法律合规要求极高。Prompt 驱动的大模型目前只能做辅助参考不能作为最终裁决。如果现场没有 GPU也不方便调用外部 API只看 CPU 环境那 VLM 部分基本没法用。这时候不如把范围缩小到“YOLO 规则引擎”完全不用 VLM 和 RAG效果反而更稳定。9.3 给想落地的人一句实在话我做了几轮测试后的体感是这套架构真正的门槛不在模型而在工程配合。模型选型、Prompt 设计这些东西多试几次就能上手但视频流管理、队列控制、告警去重、日志分析、知识库维护这些才是决定系统能不能长期跑下去的关键。如果你只做学习验证从单帧图片开始用 API 方式调用 VLM用一个小型向量库管理规则一两天就能看到完整链路。如果是生产项目建议至少预留两周做数据采集、Prompt 调优、抽帧策略验证和并发压力测试。不要等到上线那天才发现模型在测试集上表现很好但在真实摄像头角度下频繁漏检。这个方案真正落地时最该盯住的不是功能列表而是输入格式、资源占用和失败重试。把这三点处理干净再谈告警准确率。