如果拿一叠土木标准图纸去问大模型“这个排水节点标高是否满足规范”，你很快会发现传统文本 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 均可
- Python：3.10+，建议用 conda 或 venv 隔离
- CUDA：如果使用 GPU，安装与显卡驱动匹配的 CUDA 工具包
- PyTorch：根据实际引入的视觉模型选择 CPU 或 CUDA 版本
- 数据库：推荐使用向量数据库服务或本地文件型索引，按项目实际配置
- 磁盘：图纸和模型文件占用较大，建议预留 50GB 以上空间
4.2 依赖安装示例
以下命令是通用模板，需要根据实际项目代码仓库调整。
# 创建虚拟环境 conda create -n plansight python=3.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(title="PlanSightRAG 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_k=req.top_k, doc_filter=req.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 请求参数设计
问答接口建议包含以下参数：
| 参数名 | 类型 | 说明 |
|---|---|---|
| question | string | 用户问题 |
| top_k | int | 检索视觉块数量，默认 5 |
| doc_filter | string | 可选，限定图纸名称或编号 |
| need_evidence | bool | 是否返回证据图块和规范原文 |
合规检查接口建议包含：
| 参数名 | 类型 | 说明 |
|---|---|---|
| plan_path | string | 待检查图纸路径 |
| code_ids | list | 要匹配的规范编号 |
| auto_scan | bool | 是否自动识别所有相关视觉块 |
| output_format | string | json 或 markdown |
7.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 效果，忽略了解析阶段信息丢失的问题。
下一步可以从两条线继续扩展：一是把合规检查结果接入自动审图报告流程，直接生成带定位信息的检查意见表；二是把视觉优先检索能力接入设计协同平台，让工程师在图上框选节点就能自动关联规范条款。对于正在做工程图纸智能化的团队，这是一个值得持续投入的方向。
