在之前的实际开发里做一套视觉监控系统最麻烦的往往不是模型本身而是业务规则的沉淀与变化。识别到「人」之后要不要报警报警等级怎么定现场处置建议要参考哪份安全规范——这些逻辑过去要么写死在代码里要么维护在复杂的规则引擎中换一个厂区、换一类设备就要重新梳理一遍。最近在一个温升态势监控项目里我把 YOLO 的检测能力、VLM 的图文理解能力、RAG 的知识检索能力组合到了一起把大量业务规则外置成 Prompt 模板和知识库文档效果出乎意料地好。这篇文章就把这套方案的完整落地过程整理出来。文章会先讲清楚 YOLO、VLM、RAG 三种技术在智能监控系统中各自扮演什么角色然后给出一套可运行的工程框架包含完整代码、Prompt 模板、知识库建设方法和常见报错排查思路。适合正在做视觉监控、安全巡检、工业质检的开发者也适合想了解多模态大模型如何落地的同学。1. 背景与核心概念为什么监控系统需要三合一1.1 传统监控系统的痛点在哪儿先聊一个很现实的场景工厂车间的槽面温升监控。传统方案是架一个普通摄像头后端跑一个目标检测模型检测到设备区域后再用图像处理判断温度颜色变化。这套方案的问题很明显规则写死场景一变就崩。换一个车间、换一种设备检测阈值、报警规则、处置建议全部要改代码。只能“看到”不能“理解”。YOLO 能告诉你画面里有一个“人”、一个“设备”但它不知道这个人在做什么设备状态是否异常更不知道下一步该怎么处置。业务知识没有沉淀。老师傅的经验、安全规范、历史事故案例都停留在文档和口头传帮带里系统完全用不上。这些痛点的本质是感知层和认知层是断裂的。我们需要一个系统它既能感知画面中的目标又能理解场景语义还能结合业务知识给出决策建议。这正是 YOLO VLM RAG 组合的切入点。1.2 三种技术如何分工先给出一张简单的角色分工表后面再逐一展开技术定位在监控系统中的职责YOLO感知层实时检测目标输出目标框、类别、置信度VLM认知层理解画面场景进行语义分析、风险研判RAG知识层检索安全规范、历史案例为 VLM 提供知识上下文Prompt控制层把业务角色、分析要求、输出格式全部外置成模板简单来说YOLO 负责“看见”VLM 负责“看懂”RAG 负责“知道该怎么处理”Prompt 负责把这三者按照业务需要编排起来。这也是最近比较热的多模态 Agent思路在监控领域的落地形态。1.3 为什么说“不写代码只写 Prompt”是可行的传统开发模式里业务逻辑是硬编码在程序里的。每调整一次报警策略就要发一次版本。而在这套架构里核心代码只承担管道编排功能业务规则全部放在 Prompt 模板和知识库文档中。也就是说业务人员修改一个 Markdown 文件、更新一篇安全规范系统行为就跟着变化。比如你想让 VLM 从“只报高风险事件”变成“输出详细处置步骤”只需要改模板里的任务描述不需要动任何代码。这种模式非常适合监控这种业务规则密集、变化频繁的场景。2. 系统架构设计与工作流程2.1 整体架构整个系统按处理流水线可以分为四层运行顺序如下视频流/摄像头 → YOLO 目标检测 → 检测结果整理 → RAG 知识检索 → Prompt 渲染 → VLM 分析 → 输出决策与建议从实现角度看这是一个典型的串行管道。每一层只做一件事层与层之间通过标准化的数据结构传递这样每个模块都可以独立替换和升级。2.2 工作流程拆解视频采集从摄像头、视频文件或 RTSP 流读取画面帧。YOLO 检测对当前帧进行目标检测输出目标列表包括类别、坐标、置信度。检测结果文本化把检测结果转换成文本描述例如“检测到 person置信度 0.87坐标 [120, 240, 350, 520]”。RAG 知识检索根据当前场景关键词或检测到的目标类别从向量知识库中检索相关的安全规范和历史案例。Prompt 渲染把检测文本、知识库上下文、业务任务说明填充进模板。VLM 分析把当前帧画面和渲染后的 Prompt 一起发送给 VLM返回结构化的风险研判结果。结果输出在画面上绘制检测框同时打印或上报告警信息。2.3 关键设计思路这套系统的核心不在于某个模型有多强而在于模块之间的耦合方式。我推荐把所有业务差异都沉淀到三个地方prompts/目录管理所有 Prompt 模板一份模板对应一种分析角色或场景。knowledge_base/目录存放知识库原始文档新增规范时只需添加 Markdown 文件。config.yaml统一管理模型路径、API 地址、检索参数。代码本身保持精简和稳定这样团队里不同角色可以各司其职——算法工程师优化模型业务人员维护模板和知识库运维人员关注部署和监控。3. 环境准备与项目结构3.1 运行环境说明在开始写代码之前先说明一下环境。本文示例以常见环境为例具体版本需要根据你的项目实际情况调整操作系统Windows 10/11 或 Ubuntu 20.04/22.04Python3.9 及以上深度学习框架PyTorch用于运行 YOLO目标检测库ultralytics视觉语言模型支持 OpenAI 兼容接口的 VLM 服务如 qwen-vl 系列等向量数据库ChromaDB嵌入式模型BGE 系列或其他中文 Embedding 模型依赖管理pip 或 conda如果你的 VLM 是本地部署的建议使用支持vLLM或Xinference等推理框架的服务方便通过 OpenAI 兼容接口调用。3.2 项目目录结构推荐按下面的结构组织工程职责清晰也方便后续扩展smart-monitor/ ├── main.py # 主入口 ├── config.yaml # 系统配置文件 ├── requirements.txt # 依赖清单 ├── prompts/ │ ├── __init__.py │ ├── template.py # Prompt 渲染工具 │ ├── system.md # 系统角色模板 │ └── analysis.md # 场景分析模板 ├── modules/ │ ├── __init__.py │ ├── detector.py # YOLO 检测模块 │ ├── vlm_analyzer.py # VLM 分析模块 │ └── rag_retriever.py # RAG 检索模块 ├── knowledge_base/ # 知识库原始文档 │ ├── safety_rules.md │ └── incident_cases.md └── kb_store/ # 向量数据库持久化目录3.3 依赖清单requirements.txt内容如下ultralytics8.0.0 opencv-python4.8.0 pyyaml6.0 requests2.31.0 chromadb0.4.0 langchain0.1.0 sentence-transformers2.2.0注意langchain和chromadb的版本更新较快不同版本的 API 可能有细微差异。如果你遇到导入错误优先检查是不是版本兼容问题必要时锁定的具体版本。4. 核心代码实战从零搭建智能监控管道4.1 配置文件 config.yaml配置是这套系统的“基础设施”。把模型路径、VLM 接口地址、RAG 参数全部放进来避免把可变参数散落在代码里。yolo: model_path: yolov8s.pt confidence: 0.4 vlm: endpoint: http://your-vlm-service:8000/v1 api_key: sk-demo model: qwen-vl-plus rag: top_k: 3 embedding_model: BAAI/bge-small-zh-v1.5 chunk_size: 300 chunk_overlap: 50 knowledge_dir: ./knowledge_base stream: # 摄像头传 0视频文件传路径RTSP 流传 rtsp:// 地址 source: 0 frame_width: 1280 frame_height: 720说明一下几个关键参数confidenceYOLO 检测置信度阈值低于该值的目标会被过滤掉。top_kRAG 检索返回的知识片段数量数量越多Prompt 越长但也更容易覆盖相关知识。chunk_size知识库切块长度需要根据文档特点调整后面会详细讲。4.2 YOLO 目标检测模块modules/detector.py封装了 YOLO 的检测逻辑输入是一帧图像输出是标准化的目标列表。# modules/detector.py import cv2 from ultralytics import YOLO class DetectionModule: def __init__(self, model_pathyolov8s.pt, confidence0.4): self.model YOLO(model_path) self.confidence confidence def detect(self, frame): results self.model(frame, confself.confidence, verboseFalse)[0] detections [] for box in results.boxes: cls_id int(box.cls[0]) label results.names[cls_id] x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) score float(box.conf[0]) detections.append({ label: label, bbox: [x1, y1, x2, y2], score: round(score, 4) }) return detections代码要点results.names是 YOLO 模型内置的类别名称映射表比如0对应person。box.xyxy返回目标的左上角和右下角坐标便于直接在原图上绘制。所有检测结果都转换成字典格式方便后续转成文本或 JSON。如果你想用 YOLO 做实例分割而不是目标检测只需要把模型权重换成yolov8s-seg.pt然后解析results.masks即可整体管道结构不变。4.3 VLM 分析模块VLM 的接入方式在工程上比较关键。一个好的实践是使用 OpenAI 兼容接口这样无论底层是本地部署的 qwen-vl还是云端的其他多模态模型代码都不需要改。# modules/vlm_analyzer.py import base64 import cv2 import requests class VLMAnalyzer: def __init__(self, endpoint, api_key, modelqwen-vl-plus): self.endpoint endpoint.rstrip(/) self.api_key api_key self.model model staticmethod def frame_to_base64(frame, quality85): _, buffer cv2.imencode(.jpg, frame, [cv2.IMWRITE_JPEG_QUALITY, quality]) return base64.b64encode(buffer).decode(utf-8) def analyze(self, frame, prompt, max_tokens1024): image_b64 self.frame_to_base64(frame) payload { model: self.model, messages: [ { role: user, content: [ { type: image_url, image_url: { url: fdata:image/jpeg;base64,{image_b64} } }, {type: text, text: prompt} ] } ], max_tokens: max_tokens } headers {Authorization: fBearer {self.api_key}} resp requests.post( f{self.endpoint}/chat/completions, jsonpayload, headersheaders, timeout30 ) resp.raise_for_status() return resp.json()[choices][0][message][content]需要强调的是VLM 的 Prompt 设计直接决定输出质量。在监控场景中我强烈建议在 Prompt 里要求模型输出严格 JSON 格式方便程序做后续判断和告警。如果模型输出的 JSON 偶尔格式不对可以在代码里加一个简单的容错解析逻辑或者让 Prompt 里写明“只输出 JSON不要包含其他内容”。4.4 RAG 知识库检索模块RAG 在这里的定位是给 VLM 提供业务上下文。以温升监控场景为例VLM 看到“槽面出现明显烟火特征”时仅凭图片无法知道该按哪条规程处置。通过 RAG系统可以检索到《电解槽温度异常应急规范》中的相关条款把它拼进 PromptVLM 就能结合知识给出符合规范的建议。# modules/rag_retriever.py from pathlib import Path from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings import chromadb class RAGRetriever: def __init__(self, embedding_modelBAAI/bge-small-zh-v1.5, k3): self.client chromadb.PersistentClient(path./kb_store) self.collection self.client.get_or_create_collection(monitor_kb) self.embedding_fn HuggingFaceEmbeddings(model_nameembedding_model) self.k k def build_index(self, docs_dir./knowledge_base): splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50 ) chunks [] metadatas [] ids [] for path in Path(docs_dir).glob(*.md): text path.read_text(encodingutf-8) split_chunks splitter.split_text(text) for i, chunk in enumerate(split_chunks): chunks.append(chunk) metadatas.append({source: path.name}) ids.append(f{path.stem}_{i}) self.collection.add(documentschunks, metadatasmetadatas, idsids) def query(self, text): embedding self.embedding_fn.embed_query(text) result self.collection.query( query_embeddings[embedding], n_resultsself.k ) return result[documents][0]代码要点build_index方法负责把knowledge_base目录下的所有 Markdown 文档切块、向量化并写入本地数据库。新增知识后需要重新调用一次。query方法先把输入文本转成向量再从向量库中检索最相似的k个片段。切块策略这里用的是固定 300 字符 50 字符重叠。对安全规范类文档300 字符通常能保留完整条款如果你发现知识被切得太碎导致语义不完整可以适当增大到 500 或 800。4.5 Prompt 模板系统Prompt 模板是本系统的灵魂。我们把角色设定、任务描述、输出格式全部放在prompts/目录下用代码读取模板文件并填充变量。先看系统角色模板prompts/system.md你是一名资深的安全监控分析助手负责基于实时视觉检测结果和知识库规范 对监控画面中的异常事件进行研判并给出可执行的处理建议。 你在回答时必须遵循以下原则 1. 只基于已知的检测信息和知识库上下文进行判断不要编造安全规范。 2. 风险等级分为低、中、高三级判断标准参考知识库中的相关规定。 3. 处置建议要具体、可执行最多给出 3 条。 4. 禁止在答案中出现与业务无关的讨论。再看场景分析模板prompts/analysis.md【检测信息】 场景{scene_name} 检测到目标 {detections} 【知识库参考】 {knowledge} 【任务】 1. 判断当前画面是否存在安全风险给出风险等级低/中/高。 2. 如果存在风险说明风险类型和可能原因。 3. 结合知识库规范给出 3 条以内的处理建议。 4. 只输出 JSON 格式不要输出任何其他内容。 JSON 格式 { risk_level: 低/中/高, risk_type: 风险类型, analysis: 简要分析, suggestion: [建议1, 建议2, 建议3] }接下来是模板渲染工具prompts/template.py# prompts/template.py from pathlib import Path def _read_template(name: str) - str: path Path(__file__).parent / name return path.read_text(encodingutf-8) def render_prompt(scene_name: str, detections: str, knowledge: str) - str: system_template _read_template(system.md) analysis_template _read_template(analysis.md) user_content analysis_template.format( scene_namescene_name, detectionsdetections, knowledgeknowledge ) return { system: system_template, user: user_content }这样做的收益很明显想让 VLM 从“只返回风险等级”变成“返回带图片坐标的分析结果”只需要改模板不需要改 Python 代码。Prompt 就是业务代码的一部分而且是最容易迭代的那部分。4.6 主流程 main.py最后把所有模块串起来# main.py import argparse import cv2 import yaml from modules.detector import DetectionModule from modules.vlm_analyzer import VLMAnalyzer from modules.rag_retriever import RAGRetriever from prompts.template import render_prompt def load_config(pathconfig.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def main(): parser argparse.ArgumentParser(descriptionYOLOVLMRAG 智能监控系统) parser.add_argument(--source, typestr, defaultNone, help摄像头索引或视频文件路径) parser.add_argument(--config, typestr, defaultconfig.yaml) args parser.parse_args() cfg load_config(args.config) detector DetectionModule( model_pathcfg[yolo][model_path], confidencecfg[yolo][confidence] ) vlm VLMAnalyzer( endpointcfg[vlm][endpoint], api_keycfg[vlm][api_key], modelcfg[vlm][model] ) rag RAGRetriever( embedding_modelcfg[rag][embedding_model], kcfg[rag][top_k] ) # 首次运行或知识库更新后需要执行一次索引构建 rag.build_index(cfg[rag][knowledge_dir]) source args.source if args.source is not None else cfg[stream][source] cap cv2.VideoCapture(source) if source 0: cap.set(cv2.CAP_PROP_FRAME_WIDTH, cfg[stream][frame_width]) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, cfg[stream][frame_height]) while True: ret, frame cap.read() if not ret: break detections detector.detect(frame) if len(detections) 0: continue det_text \n.join( [f- {d[label]} 置信度 {d[score]} 位置 {d[bbox]} for d in detections] ) context rag.query(当前场景的风险处置规范) prompt render_prompt( scene_name电解车间槽面监控, detectionsdet_text, knowledge\n.join(context) ) analysis vlm.analyze(frame, prompt) print(检测目标, det_text) print(VLM 分析结果, analysis) for d in detections: x1, y1, x2, y2 d[bbox] cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(frame, d[label], (x1, y1 - 10), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) cv2.imshow(smart-monitor, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows() if __name__ __main__: main()这里有几个踩坑后总结的细节没有检测目标时直接跳过。监控画面大多数时间是没有目标的让 VLM 对空画面做分析既浪费 token 又容易产生误报。VLM 调用放在检测到目标之后。这样能把 API 调用频率控制在一个合理的水平。先离线验证再上摄像头。建议先用一段录制好的视频文件跑通整条链路确认 Prompt 效果没问题后再接实时摄像头。4.7 运行与验证运行命令如下# 用摄像头 python main.py --source 0 # 用视频文件 python main.py --source ./demo.mp4预期效果是画面中检测到目标后终端会打印检测目标列表和 VLM 的结构化分析结果同时 OpenCV 窗口会叠加显示检测框。5. Prompt 的关键设计让 VLM 输出真正可用5.1 从“让模型理解”到“让系统可用”很多初学者使用 VLMPrompt 写得很随意比如“请分析这张图片”结果模型返回一大段描述性文字程序没法直接使用。而在工程系统里我们需要的往往是结构化的、可解析的输出。我的建议是任何进入生产流程的 VLM 输出都应该要求 JSON 结构化。例如上面的模板中明确要求模型只输出指定结构的 JSON。这样主程序可以很方便地解析风险等级决定是否触发告警。5.2 Prompt 模板的参数化设计不要把具体场景写死在模板里而是用{scene_name}、{detections}、{knowledge}这类占位符。这样同一套系统可以服务多个场景——电解车间换到油库监控只需在调用时传入不同的场景名或者新增一份模板。5.3 防止无效 Prompt 和内容安全拦截在实际调用大模型接口时偶尔会遇到类似下面的报错invalid prompt: your prompt was flagged as potentially violating our usage policy这个问题通常有两个原因输入内容触发了服务端的内容安全策略比如画面帧里包含敏感内容或特定实体。此时不能硬绕过应该做输入侧过滤比如在送入 VLM 前先判断检测目标类型对明显超出监控范围的画面帧不调用 VLM。Prompt 里包含诱导越狱、生成违规内容的措辞即使业务上完全合规也会被安全模型拦截。排查方法是把 Prompt 中的任务描述改成中性表达比如把“展开攻击代码”这类演示性词语全部改为“分析目标行为”。还有一个高频报错prompt is too long ... automatic compaction failed这代表拼接后的 Prompt 超过了模型上下文长度。解决思路不是盲目调大max_tokens而是减少 RAG 返回的top_k从 5 降到 3。减小知识库切块大小让每段上下文更精简。检测到多个目标时只保留置信度最高的前 5 个目标进入 Prompt。对画面帧做降采样压缩VLM 输入图片分辨率越高占用的视觉 token 越多。5.4 模板版本管理Prompt 模板也应该纳入版本管理。我的习惯是把模板文件放在 Git 仓库中和代码一起提交。每次调整 Prompt 后记录一下输出效果的变化方便回溯。你可以把模板文件名带上日期或版本号analysis_v2.md analysis_v3.md不建议直接覆盖原文件。监控系统的业务规则变化很快能回滚的 Prompt 能帮你减少很多事故。6. 知识库建设与 RAG 切块策略6.1 知识库里应该放什么对于监控系统知识库内容通常包括三类安全规范类设备操作规程、检查标准、风险分级标准。历史案例类历史事故描述、原因分析、处置结果。应急预案类突发事件响应流程、联系人信息、物资清单。这些文档建议用 Markdown 维护因为结构清晰、便于阅读和版本管理。下面是一个温升监控场景的知识库示例# 电解槽温度异常应急规范 1. 当槽面局部温度超过企业规定阈值上限时属于一级预警需要立即通知工艺负责人。 2. 当检测到明显烟火特征时立即启动消防应急预案并切断局部电源。 3. 处置过程中必须穿戴对应的防护装备并保持安全距离。注意**具体温度阈值因企业工艺不同差异很大请以你所在企业的规范为准不要在代码里写死。6.2 切块策略怎么调RAG 的检索效果很大程度上取决于切块策略。切太碎语义会被切断切太长检索精度下降且 Prompt 变长。几个实用经验按章节切分如果知识库文档本身有清晰的章节结构优先按章节切而不是固定长度切。固定长度加重叠没有清晰结构时用 300-500 字符 50-100 字符重叠是消耗比不错的选择。保留文档来源检索结果里带上source元数据方便在输出中注明依据。6.3 索引更新时机知识库更新后必须重新构建索引否则检索结果还是旧的。如果你的服务是常驻运行的可以在每次启动时检查知识库文件的修改时间有变化才重新构建避免启动过慢。7. 常见问题与排查思路问题现象常见原因解决思路invalid prompt 报错输入内容触发安全策略在送入 VLM 前过滤敏感检测目标修改 Prompt 措辞prompt is too long上下文长度超限减少 top_k、减小 chunk_size、省略低置信度目标画面卡顿、帧率低YOLO 检测和 VLM 调用耗时过长降低检测频率、抽帧处理、VLM 调用放入异步任务检测漏报/误报置信度阈值设置不当调低置信度看漏报调高置信度看误报找到平衡点RAG 检索结果不相关切块策略不合理或 Embedding 模型不合适调整切块大小换用领域相关 Embedding 模型VLM 返回内容不是合法 JSON模板约束不够严格在模板中强调“只输出 JSON”并增加程序容错解析摄像头无法打开source编号错误或权限不足检查摄像头索引确认操作系统摄像头权限视频流断连RTSP 流网络不稳定增加重连逻辑配合cap.grab()等超时控制在排查过程中建议按“先检查输入、再检查模型服务、最后检查程序逻辑”的顺序来避免一上来就改代码。比如 VLM 返回异常先手动拿同样的图片和 Prompt 调用一次接口能快速判断是服务问题还是代码问题。8. 最佳实践与工程建议8.1 安全边界与合规监控系统涉及视频数据和个人信息有几个底线要守住最小权限原则系统账号只授予摄像头读取和告警推送所需的最小权限。数据安全视频帧和检测记录不能随意存储到公开环境建议配置日志保留策略和访问审计。内容安全不要试图绕过 VLM 服务的内容安全策略。内置的安全过滤是对服务提供方和使用方的共同保护合规比一时的便利更重要。生产环境变更修改 Prompt 模板或知识库内容前先在测试环境用录制视频验证再灰度到生产环境。8.2 性能优化这套架构最耗时的两个环节是 YOLO 推理和 VLM 推理。几个实用优化方向抽帧策略VLM 不需要每帧都调用。摄像头 25fpsYOLO 可以跑全帧VLM 每 1-2 秒分析一次即可。异步化VLM 分析结果不影响 YOLO 检测主循环用队列 线程池把耗时任务异步化。YOLO 模型选型边缘设备选yolov8n或yolov8sGPU 服务器可以上yolov8m以上。VLM 部署生产环境建议用 vLLM 或同类推理框架部署而不是直接通过 Transformers 逐次推理吞吐量差距很大。8.3 可观测性与运维监控系统本身就是运维工具自身也要可观测。建议在代码里增加几个关键日志点每次 YOLO 检测的目标数量和耗时。每次 RAG 检索返回的知识片段来源。每次 VLM 调用的耗时、token 消耗和输出结果。告警事件落库保留完整上下文时间、图片、检测结果、Prompt、VLM 输出。日志格式建议统一 JSON方便接入日志平台。告警也应该有分级避免高频刷屏导致真正的高风险事件被淹没。8.4 团队协作模式最后聊一下团队协作。这套架构最大的价值是让非算法背景的成员也能参与系统迭代。业务人员维护知识库文档安全专家编写 Prompt 模板算法工程师专注优化模型和管道性能。代码仓库里的 Code Review 只需要关注管道逻辑而业务变化的 Review 重点放在模板和文档上。这种分工方式能明显降低系统的迭代成本。建议在项目初期就约定好 Prompt 模板和知识库文档的写作规范比如标题层级、变量命名、输出格式等保证后续协作顺畅。9. 总结与下一步学习路线这篇文章围绕智能监控系统完整实现了 YOLO 感知、VLM 分析与 RAG 知识增强的三层管道把业务规则外置到 Prompt 模板和知识库文档中让整个系统在“不写业务代码”的情况下具备持续迭代能力。通过这套方案你已经可以做到用 YOLO 实时检测监控画面中的目标并标准化输出检测结果。用 RAG 把企业安全规范、历史案例实时注入到分析上下文中。用 VLM 对画面进行场景理解和风险研判并返回结构化 JSON 结果。通过修改 Prompt 模板和知识库文档来调整系统业务行为而不依赖发版。如果你是从零开始学习这条技术路线我建议按以下顺序推进先在公开数据集上跑通 YOLO 检测理解检测结果的数据结构然后调通一个 VLM 的接口体验多模态 Prom 的效果接着搭建一个几百条知识文档的小型 RAG 库掌握切块和检索的基本流程最后把三者串成完整管道用离线视频验证再接入摄像头。在实际项目中最优先关注的是数据安全和 Prompt 边界——监控系统不能出现越权查看、数据泄露或绕过内容合规的漏洞这是底线。其次才是检测精度和响应延迟。先把一套流程稳定跑通再逐步优化模型和性能这条路会比一开始追求“最优效果”走得更远。如果你正在做类似的项目或者对某个模块的细节有疑问欢迎在实际调试后回来交流。技术方案没有银弹结合自己业务场景反复调优才是把这套架构真正用好的方式。