如果拿一叠土木标准图纸去问大模型“这个排水节点标高是否满足规范”你很快会发现传统文本 RAG 基本帮不上忙。图纸上的结构构件、尺寸标注、图例符号、材料表几乎全是视觉信息PDF 抽出来的文本要么是乱的要么大量遗漏。PlanSightRAG 正是针对这类场景提出的视觉优先多模态 RAG 思路先把图纸里的视觉元素结构化再进检索和问答链路最后用大模型自动生成答案或合规检查结论。这篇文章会把 PlanSightRAG 拆开来讲。先看它的核心能力边界再给出一套可以在本地项目中落地的部署流程、功能测试方法、API 调用示例和批量任务设计最后补充资源占用观察和常见问题排查。如果你正在做建筑、市政、交通类标准图纸的智能问答、合规性检查或者只是想把多模态 RAG 接到工程文档场景里这篇可以直接收藏。1. 核心能力速览能力项说明项目类型面向土木标准图纸的视觉优先多模态 RAG 方案核心功能图纸视觉内容检索、工程问答、合规性检查视觉优先先把图纸中的视觉元素图框、标注、图例、构造节点结构化再进入检索流程技术链路视觉检测 OCR/文本提取 多模态向量化 LLM 推理典型输入标准平面图、剖面图、节点详图、大样图、设计说明、规范条文输出形式自然语言答案、合规检查报告、相关图纸区域定位是否支持 API可按服务化方式封装提供 HTTP 接口是否支持批量任务支持按目录批量处理需要设计任务队列和日志推荐硬件优先 GPU 环境纯 CPU 可跑但体感会明显变慢显存占用取决于视觉模型和 LLM 选型需按实际环境测试适合场景施工图审查辅助、标准图集问答、设计交底、审图意见整理需要说明的是PlanSightRAG 并不是一个把图纸直接丢给大模型就能得到正确答案的“黑盒”。它的核心价值在于改写传统 RAG 的预处理链路让图纸里真正有意义的视觉单元成为可检索对象。这样一来无论是基于规范条文的合规性检查还是针对某个节点做技术问答模型都能拿到对应的图纸区域和上下文。2. 适用场景与使用边界2.1 适合谁用第一类使用人群是设计院和信息化的工程技术人员。他们手里的标准图集数量大、版本多人工翻图效率低。PlanSightRAG 可以把“查找某个节点做法是否满足规范”这类问题变成检索任务。第二类人群是做工程文档智能化的开发团队。需要把图纸、PDF、规范文本接进大模型应用但发现通用 RAG 对图纸无效就可以参考这个方案的视觉优先处理思路。第三类是施工单位的审图和技术交底人员。面对几百张图纸想快速定位“哪些区域的防火门宽度标注可能不符合规范”PlanSightRAG 能在检索阶段返回可疑图纸区域再由模型生成合规判断。2.2 能解决什么问题普通 RAG 对 PDF 文本切块遇到扫描图纸时提取内容基本不可用。PlanSightRAG 的做法是把一张图纸拆成多个“视觉块”例如一个构造节点、一个尺寸标注组、一个图例表。每个视觉块同时拥有图片特征、坐标位置、OCR 文本和对象类型描述检索时不只比文本还比视觉语义召回率会明显更好。合规性检查也比纯规则方案灵活。规则只能写死“符号类型 A 必须满足条件 B”遇到复杂组合和上下文时容易失效。PlanSightRAG 可以把规范条款和图纸视觉信息一起送给 LLM让模型输出“是否合规、依据是什么、对应图纸位置在哪里”的结构化结果。2.3 使用边界和合规提醒这个方案不能替代注册工程师的签章责任。自动生成的合规检查结果可能存在漏检和误判只能作为预审辅助最终结论必须由具备资质的人员复核。图纸和规范通常涉及版权和项目保密要求。本地部署时要注意数据隔离不要随意把图纸上传到不可控的云服务。如果涉及人脸、隐私或敏感建筑数据必须有明确的授权链。涉及标准图集、规范条文时也要确认使用范围是否在版权允许范围内。3. 系统架构与处理流程PlanSightRAG 的核心是“视觉优先”。整个系统可以分成五个模块每个模块都直接影响最终效果。3.1 图纸解析与视觉元素检测这一步负责把一张图纸拆成有意义的视觉单元。常用方式是用目标检测模型识别图框、标题栏、图例、节点编号、尺寸标注和构造详图边界。检测模型输出的是一组目标框每个框里包含对象类型和坐标。然后对每个目标框做细粒度处理比如对尺寸标注区域做 OCR提取数值和单位对图例区域做图标分类对节点详图区域保留原始图像块。最终输出类似下面的结构{ page_id: SHT-03, doc_name: 标准管沟断面图, blocks: [ { block_id: b01, type: detail, bbox: [120, 450, 680, 900], text: DN200 排水管, attributes: {scale: 1:20, material: HDPE} }, { block_id: b02, type: dimension, bbox: [700, 420, 980, 480], text: 管顶覆土 1200mm } ] }这一步做完图纸不再是一个不可分割的 PDF 页面而是一组带空间信息的结构化对象。3.2 视觉块向量化与索引每个视觉块需要同时送入多模态嵌入模型。所谓多模态嵌入是指同一模型能够把图像和文本映射到同一个向量空间。这样用户输入“管沟内管道最小覆土深度是多少”时查询文本可以同时匹配“管顶覆土 1200mm”这类文本块以及对应的节点详图图像块。向量化的结果存入向量数据库并保留原始对象元数据。检索时会先按相关性召回 TopK 个视觉块再按坐标和图纸编号聚合成“候选图纸区域”。这一步为后续问答和合规检查提供了可靠的上下文来源。3.3 规范知识库构建合规性检查不能只靠图纸。需要把标准图集说明、施工及验收规范、条文说明按条款切分和对应规范编号、章节号一起入库。规范文本是纯文本可以直接用通用文本嵌入模型处理也可以复用多模态模型中的文本编码器。建议每个条款都保留最少三重信息规范编号、核心要求、适用对象类型。比如{ code: GB 50268-2017, clause: 6.3.2, content: 管道沟槽回填时管顶以上500mm范围内严禁使用大型机械压实。, applicable_to: [沟槽回填, 管顶防护] }有了结构化条款合规检查模块才能把图纸中的视觉对象和规范条款做对应。3.4 问题理解与意图路由用户输入问题后系统先判断这是一个知识问答还是合规检查请求。知识问答例如“这种标准节点做法通常用几层防水”直接走“问题向量化 - 视觉块召回 - 大模型生成”。合规检查例如“检查这张图里所有消防设施间距是否满足规范”需要先做图纸级扫描把所有相关视觉块大范围召回再逐条匹配规范条款最后拼接上下文交给 LLM。意图路由可以是规则加小模型也可以直接用 LLM 做函数调用。对工程场景推荐先用规则兜底再让 LLM 补充细粒度分类避免误判。3.5 大模型生成与引用输出召回得到的视觉块和规范条款会一起拼进提示词。Prompt 需要明确要求模型输出依据和定位。合规检查的结果建议输出 JSON方便后续生成报告{ result: 该节点管顶覆土厚度为 1200mm满足规范要求的最小值。, compliance: PASS, references: [ { doc: 标准管沟断面图, block_id: b02, location: 第三页右上角, reason: 尺寸标注管顶覆土 1200mm }, { code: 某排水工程规范, clause: 4.2.3, reason: 覆土厚度不应小于 1000mm } ] }这种输出不仅给出结论还能回溯到图纸的具体位置和规范条款对工程复核很有价值。4. 环境准备与前置条件4.1 操作系统与语言版本推荐在 Linux 服务器或本机 WSL2 环境运行。Windows 也可以跑但依赖视觉检测、向量索引等库时Linux 环境踩坑更少。Python 版本建议 3.10 或 3.11这两个版本对这些库兼容性更稳妥。这里给出一套通用环境检查清单操作系统Ubuntu 22.04 / Debian 12 / Windows 11 均可Python3.10建议用 conda 或 venv 隔离CUDA如果使用 GPU安装与显卡驱动匹配的 CUDA 工具包PyTorch根据实际引入的视觉模型选择 CPU 或 CUDA 版本数据库推荐使用向量数据库服务或本地文件型索引按项目实际配置磁盘图纸和模型文件占用较大建议预留 50GB 以上空间4.2 依赖安装示例以下命令是通用模板需要根据实际项目代码仓库调整。# 创建虚拟环境 conda create -n plansight python3.10 -y conda activate plansight # 安装基础依赖实际包名以项目 requirements 为准 pip install torch torchvision pip install transformers pip install sentence-transformers pip install opencv-python pip install pymupdf pip install fastapi uvicorn # 如果有需求文件直接执行 # pip install -r requirements.txt视觉检测部分可能依赖 Detectron2、MMDetection、PaddleOCR 或通用目标检测库安装方式各不相同。建议看项目文档中的 requirements 和 setup 说明不要盲目用同一个命令装所有依赖。4.3 模型文件准备PlanSightRAG 的处理链路通常包含三类模型第一类是视觉检测模型负责找图框、节点、表格和文字区域。这类模型一般有预训练权重按实际开源模型名称下载即可。第二类是 OCR 模型负责识别尺寸文字、图例文字和设计说明。中英文混合场景对 OCR 要求较高建议用支持中文识别的模型并保留图像做二次校对。第三类是嵌入模型和 LLM。嵌入模型把视觉块和文本映射到向量空间LLM 负责最终生成。本地部署如果不方便加载大模型可以先用较小规模的模型测试链路再替换为效果更好的模型。下载模型时注意保存目录和版本。不要直接把模型文件放进代码目录建议统一整理为models/文件夹并按模型名创建子目录。5. 本地部署与启动方式5.1 数据目录结构设计一个清晰的数据目录能避免后面处理几百张图纸时把项目搞乱。参考结构如下plan_sight_rag/ ├── configs/ │ ├── index_config.yaml │ ├── pipeline_config.yaml ├── data/ │ ├── source_plans/ # 原始图纸 PDF 或图片 │ ├── parsed_blocks/ # 解析后的视觉块 JSON │ ├── vector_index/ # 向量索引文件 │ ├── codes/ # 规范条文文本 ├── models/ │ ├── detector/ # 视觉检测模型 │ ├── ocr/ │ ├── embedding/ │ └── llm/ ├── outputs/ │ ├── answers/ │ ├── reports/ │ └── logs/ ├── scripts/ │ ├── build_index.py # 索引构建脚本 │ ├── serve_api.py # API 服务脚本 │ └── run_qa.py # 单次问答脚本建议把原始图纸、中间产物、输出结果分目录管理便于后续追溯和批量重跑。5.2 一次索引构建流程部署的第一步是构建索引。假设已经准备好了图纸目录可以用通用脚本思路import json from pathlib import Path # 伪代码示例实际需要替换为项目对应函数 from plansight.submodules.detector import detect_visual_blocks from plansight.submodules.ocr import extract_text from plansight.submodules.embedding import embed_blocks source_dir Path(data/source_plans) output_dir Path(data/parsed_blocks) for pdf_path in source_dir.glob(*.pdf): # 1. 加载 PDF渲染为高清图片 page_images render_pdf_pages(pdf_path) # 2. 检测视觉块 blocks detect_visual_blocks(page_images) # 3. 对视觉块做 OCR blocks extract_text(blocks) # 4. 向量化并保存 vectors embed_blocks(blocks) save_blocks(blocks, vectors, output_dir / pdf_path.stem)这个流程需要在真实环境中跑通后才能进入问答和检查阶段。首次构建索引时会比较耗时建议先拿几张有代表性的图纸测试确认解析效果后再批量跑。5.3 启动 API 服务链路跑通后建议封装成 API 服务方便后续接网页或者第三方工具。这里使用 FastAPI 的通用示例from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titlePlanSightRAG API) class QARequest(BaseModel): question: str top_k: int 5 doc_filter: str None class ComplianceRequest(BaseModel): plan_path: str code_ids: list [] app.post(/api/qa) def qa(req: QARequest): # 调用检索 生成流程 result run_qa(req.question, top_kreq.top_k, doc_filterreq.doc_filter) return result app.post(/api/compliance) def compliance(req: ComplianceRequest): result run_compliance_check(req.plan_path, req.code_ids) return result # 启动uvicorn serve_api:app --host 127.0.0.1 --port 8000本地测试时建议只绑定127.0.0.1避免端口暴露到外部网络。如果需要局域网访问再按实际情况调整防火墙。6. 功能测试与效果验证6.1 基础问答测试测试目的确认问答链路能够从图纸中检索到相关内容并生成回答。操作步骤准备一张包含管沟断面和尺寸标注的标准图。启动 API 服务。调用问答接口输入问题“管顶覆土厚度是多少”。观察返回答案、检索到的视觉块、引用文本。判断标准答案是否与图中尺寸标注一致。返回结果里是否包含图内区域定位而不仅是模型猜测。如果回答错误优先检查视觉块解析阶段有没有漏掉尺寸标注。失败原因通常有三种OCR 没识别到尺寸数字、视觉块切得太大导致检索不聚焦、提示词没有要求模型引用坐标信息。6.2 合规性检查测试测试目的验证系统能否根据规范条款对图纸中的视觉对象做出合规判断。操作步骤在规范库中加入对应条文例如覆土厚度最小值、管道间距要求。输入合规检查请求指定图纸路径和相关规范编号。查看输出 JSON 中的 compliance 字段。判断标准输出必须包含“PASS”或“FAIL”。FAIL 时应返回具体图块位置和相关规范条款。不要只看结论要检查理由是否和图纸真实信息一致。常见失败场景模型把图纸里其他位置的数字当作目标值。解决办法是在提示词中限制“只根据引用视觉块的 OCR 内容回答”同时让 OCR 结果带上坐标。6.3 批量任务测试测试目的确认系统能够连续处理多张图纸而不中断。操作步骤新建一个文本文件每行一个要检查的图纸路径和规范编号。用批量脚本循环调用合规检查接口。每张图纸输出一个结果文件失败时记录错误日志。建议输出格式outputs/reports/ ├── SHT-01.json ├── SHT-02.json ├── SHT-03.json └── errors.log批量处理时一定要加超时控制和重试机制。某一张图纸解析失败不要影响整个任务队列可以先记录错误后面单独排查。7. 接口 API 与批量任务设计7.1 请求参数设计问答接口建议包含以下参数参数名类型说明questionstring用户问题top_kint检索视觉块数量默认 5doc_filterstring可选限定图纸名称或编号need_evidencebool是否返回证据图块和规范原文合规检查接口建议包含参数名类型说明plan_pathstring待检查图纸路径code_idslist要匹配的规范编号auto_scanbool是否自动识别所有相关视觉块output_formatstringjson 或 markdown7.2 使用 curl 测试接口curl -X POST http://127.0.0.1:8000/api/qa \ -H Content-Type: application/json \ -d {question: 该断面图中的管顶覆土厚度是否满足最小覆土要求, top_k: 5}正常返回时你会看到类似这样结构的 JSON{ answer: 图中的管顶覆土厚度为 1200mm满足要求。, evidence_blocks: [ { doc: SHT-03, block_type: dimension, text: 管顶覆土 1200mm } ], references: [] }如果返回内容为空优先排查索引是否已经构建完成以及问题里的关键词是否在视觉块文本中出现。必要时可以降低 top_k看看更相似的视觉块能不能被召回。7.3 批量任务队列设计批量任务不要在单个请求里同步跑几十张图纸否则接口容易超时。推荐设计一个简单任务表用异步方式处理{ task_id: task-0001, plan_path: /data/source_plans/SHT-01.pdf, code_ids: [GB_50268-2017], status: pending, retry_count: 0 }处理流程请求接口提交任务返回task_id。后台 worker 拉取 pending 任务执行。执行完成后更新结果为 success 或 failed。客户端轮询任务状态获取结果。如果没有消息队列也可以直接用errored files列表加循环重试。核心原则是保证单张图纸失败不会阻塞整个队列。8. 资源占用与性能观察8.1 观察显存和内存的方法在本地部署时重点观察视觉检测、OCR、嵌入模型和 LLM 四部分的资源占用。推荐用nvidia-smi实时查看显存watch -n 1 nvidia-smi如果使用 Docker可以用docker stats查看容器内存上限。更完整的做法是在日志中记录每个阶段耗时和最大显存以确定性能瓶颈。8.2 GPU 与 CPU 对比视觉检测和多模态嵌入在 GPU 上执行速度会快很多。CPU 不是不能跑但在高分辨率图纸下单张页面检测可能就要几十秒甚至更久。如果只是测试几个小图CPU 可以先跑通链路如果要做批量合规检查还是建议使用 GPU。LLM 的显存占用取决于模型大小。可以从较小模型开始测试确认链路正确后再切换到更大模型。如果显存吃紧可以调整输入图片分辨率跳过不必要的视觉块或者把 LLM 换成 API 调用但需要注意图纸数据的隐私合规。8.3 分辨率、批次和文本长度的影响图纸分辨率直接决定视觉检测的质量。分辨率太低节点详图和尺寸标注会糊分辨率太高检测和 OCR 耗时成倍增加。建议先测试多档分辨率找到准确率和速度的平衡点。批量检测时一次送的图片数量越大显存占用越高。可以按 1 到 4 张图片为一组分批处理。文本长度主要影响 LLM 输入视觉块数量过多时会把上下文塞满建议只保留检索结果中得分最高的 TopK 块不要把整张图纸所有视觉块都塞进提示词。8.4 降低资源占用的策略如果显存不够可以关闭视觉模型里不需要的辅助分支或使用模型量化。OCR 部分只对检测到的文本区域跑不要全图识别。向量索引如果用本地文件型数据库注意内存映射参数避免索引全部加载进内存。服务端可以开启模型常驻减少重复加载耗时。但模型常驻会增加显存占用需要按实际服务器资源权衡。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后接口无法访问服务未启动或端口被占用检查进程日志和端口监听换端口或重启服务索引构建时报模型加载失败模型路径写错或模型文件缺失检查 models 目录和日志路径重新下载模型并修正配置图纸 OCR 结果识别错误分辨率低、图纸倾斜、打印底色干扰查看中间产物图片和 OCR 文本提高渲染分辨率增加图像预处理问答答案与图纸不符视觉块切分不合理或检索召回错误检查召回块文本和坐标调整切分参数、增加对象类型过滤合规检查漏检规范条款未正确入库或视觉块未覆盖检查规范索引和解析结果补全规范文本缩小视觉块粒度批量任务中途卡住单张图纸解析超时或资源占用过高查看任务日志和显存占用增加超时和重试机制分批处理API 返回超时LLM 生成太慢或上下文过长观察日志耗时减小 TopK降低输入图片数换更小模型显存不足多模型同时驻留显存查看 nvidia-smi按需加载模型减少并发数输出里有不存在的规范条款LLM 幻觉检查引用来源是否真实存在在提示词中加入“只能引用提供的条文”限制并做后置校验排查时有个通用技巧把中间结果落盘。视觉块 JSON、OCR 文本、检索命中的块 ID 都保存下来。这样每一步都可以单独验不需要每次都完整跑一遍链路。10. 最佳实践与使用建议10.1 开发阶段先小后大第一次测试不要拿几百张图纸灌进去。先选 3 到 5 张覆盖不同图型的图纸跑通“解析 - 索引 - 问答 - 检查”全流程。确认每一步输出符合预期后再逐步扩大数据规模。最小可运行配置建议固定下来。包括图纸分辨率、视觉块切分规则、检索 TopK、提示词模板。这个配置可以作为后续调优的基线。10.2 数据、模型、输出分开管理原始图纸、解析 JSON、向量索引、模型权重、最终报告必须分开存放。避免把模型文件放进 Git 仓库避免让脚本直接修改原始图纸目录。日志统一写入logs/带时间戳方便回溯。10.3 批量任务加日志和重试批量合规检查不确定因素很多。某张图纸可能因为扫描质量差导致 OCR 失败某段规范文本可能因为特殊字符导致索引异常。任务模块必须记录每张图纸的成功失败状态失败任务最多重试两次仍失败就跳过并写入错误报告。10.4 接口服务限制访问范围API 服务默认监听127.0.0.1不要为了方便直接开放到公网。如果要在团队内共享建议放在内网环境并增加简单的 Token 鉴权。涉及图纸数据时传输过程最好启用 HTTPS。10.5 合规性检查必须人工复核PlanSightRAG 的输出是“预审建议”不是最终审查意见。规范条款比较复杂时模型可能忽略前提条件或者把相似条文错误匹配。正式对外交付前应由专业工程师对检查结果逐条复核。10.6 注意版权与隐私标准图纸、标准图集、规范条文都有版权属性。不要拿未授权的图纸做公开演示或商用。若图纸包含未公开的工程信息要在本地环境处理避免数据外泄。涉及人脸、个人信息时还要遵守相应隐私保护要求。11. 总结与下一步PlanSightRAG 最值得尝试的地方是它解决了图纸场景下“文本切块不管用”的痛点。视觉优先意味着图纸里真正有价值的构造节点、尺寸标注、图例说明都能变成可检索对象这正是传统 RAG 做不到的。拿到这套思路后第一步应该先验证“视觉块解析”质量。如果一张断面图的尺寸标注能被正确 OCR 成结构化数据后续的问答和合规检查精度才有保障。最容易踩的坑是只关注 LLM 效果忽略了解析阶段信息丢失的问题。下一步可以从两条线继续扩展一是把合规检查结果接入自动审图报告流程直接生成带定位信息的检查意见表二是把视觉优先检索能力接入设计协同平台让工程师在图上框选节点就能自动关联规范条款。对于正在做工程图纸智能化的团队这是一个值得持续投入的方向。