视觉优先多模态RAG：施工图审查看懂标准图集的新范式

施工图审查最耗时的环节，往往不是算不清钢筋量，而是"翻书"：设计人员拿着一本几百页的标准图集，逐页对照图纸节点做没做对、标注符不符合图集大样、材料做法有没有按规范执行。这个过程重复、枯燥，又绝对不能出错。

过去几年，团队普遍用文本 RAG 搭知识库，把规范 PDF 塞进去做问答。但遇到土木标准图集，这套方案很快失灵。原因很简单：图集的核心是图纸，不是文字。图纸上的尺寸、编号、构造做法、节点详图，都是以视觉形式存在的。普通 RAG 只做文本切块和向量检索，它连"图里到底画了什么"都判断不了，更说不出"你这个节点和图集 3-6 页的做法差在哪里"。

这就是为什么多模态 RAG 在建筑工程领域值得被认真对待。更准确地说，是"视觉优先"的多模态 RAG：不是把图片当作附属资料，而是在索引和检索阶段就把图像作为一级公民。本文就以 PlanSightRAG 这类视觉优先多模态 RAG 系统为例，拆解它的核心架构，并给出一个可以跑通的最小原型，覆盖图集解析、多模态索引、问答生成和合规检查完整链路。

1. 为什么土木标准图集需要"视觉优先"的多模态 RAG

土木标准图集和普通技术文档最大的区别在于：信息高度依赖图形表达。一张节点详图里，一个剖面符号、一条引出线、一个尺寸标注，都可能决定整个构造是否符合要求。如果只把这些图纸当作 PDF 来解析，你会丢失大量信息。

1.1 传统文本 RAG 在处理图集时的三个硬伤

第一个硬伤是文本提取不完整。很多图集 PDF 包含矢量文字，可以正常复制；但也有大量扫描版图集、老式蓝图，整页就是一张图片。文本提取器面对这类内容，得到的往往是一堆乱码或空文本。

第二个硬伤是版面结构丢失。图集页面里有标题栏、图框、文字说明、节点索引、表格、材料表。单纯的文本切块会把标题栏里的"图集编号"和节点说明切成一块，检索时的语义边界完全错乱。

第三个硬伤是"图文分离"。图集里绝大部分关键信息是"图 + 标注 + 说明"的组合。文本检索只能命中说明文字，而无法把问题映射到对应的图纸区域。用户问"这个转角处的防水卷材应该上翻多少"，模型如果看不到图，只能靠猜。

1.2 为什么是"视觉优先"，而不是"文本为主、图像为辅"

当前很多所谓多模态 RAG，实际做的是：先用 OCR 把图片变成文本，再走传统文本检索。严格说，这不是多模态 RAG，而是"OCR 增强的文本 RAG"。

视觉优先的差别在于：系统默认视觉内容本身就是检索对象。图纸图片切片被直接编码成视觉向量，用户问题也被编码到同一个语义空间里，检索阶段就能命中"视觉上相似的图纸区域"，而不是仅仅命中文本片段。

这对工程场景很重要。同一个构造做法，不同图集里表达方式可能不一样，文字描述更是千差万别，但视觉结构往往高度相似。视觉优先的检索召回，能覆盖文本召回无法覆盖的那部分。

1.3 PlanSightRAG 要解决的典型场景

PlanSightRAG 面向的核心场景可以归纳为三类：

• 图集问答：例如"图集里关于外墙保温的构造层顺序是什么"
• 合规检查：例如"当前这版施工图的楼梯栏杆高度，是否符合图集和规范要求"
• 变更对比：例如"图纸某节点和图集大样不一致的地方在哪里"

三者本质上都需要同一个能力：把自然语言问题与图纸视觉内容对齐，再结合规则或规范文本产出判断。这正好是视觉优先多模态 RAG 擅长的部分。

2. 多模态 RAG 的核心概念：从文本 RAG 到 Visual-First

2.1 RAG 到底是什么

RAG（Retrieval-Augmented Generation，检索增强生成）是一种让大语言模型在回答问题时先检索外部知识的技术方案。它的基本流程是：把文档切块、向量化、存储到向量数据库；用户提问时，把问题向量化，在向量库中找出最相似的片段；把检索到的片段作为上下文，连同问题一起交给大模型生成答案。

RAG 的价值在于：模型不需要把知识背进参数里，答案可以溯源到文档片段，知识更新只需要重建索引，不需要重新训练模型。

2.2 三种多模态 RAG 形态

需要把概念边界先理清。材料里常见的多模态 RAG 大致有三种形态：

PlanSightRAG 的定位是第三种。它不是把图片当作"附带的 metadata"，而是把图像切片当成检索的主要对象。

2.3 视觉优先多模态 RAG 的数据流

一个视觉优先多模态 RAG 的完整数据流可以概括为六个环节：

1. 图集文件解析：从 PDF、扫描件、CAD 导出的图纸中生成页面图像。
2. 版面分析与区域切分：识别图框、标题栏、节点详图区域、文字说明区域，把大图切成有意义的子图。
3. 视觉编码：用视觉语言模型的图像编码器把子图转成向量。
4. 混合索引：图像向量、OCR 文本向量、版面元数据一起写入向量数据库。
5. 检索召回：用户输入问题后，分别做视觉检索和文本检索，然后用重排模型融合排序。
6. 生成与检查：把命中的子图和文本上下文交给视觉语言模型，生成答案或合规检查结论。

3. PlanSightRAG 整体架构设计

在设计阶段，需要把系统拆成可独立演进的模块。参考 RAG 框架的通用做法，我会把系统分为四层。

3.1 文档接入层

这一层解决"图集怎么进来"的问题。输入可能是整本 PDF、单张扫描图、CAD 导出的 PNG，甚至是有图层信息的 PDF。文档接入层负责统一转成标准格式的页面图像和基础 OCR 文本。

工程经验是：PDF 矢量图层要单独保留，不能只留渲染图。矢量文字和标注的坐标信息，对后续版面分析很有价值。

3.2 内容理解层

内容理解层是整个系统的关键。它要完成三件事：

• 版面分析：用目标检测模型识别页面上的"图框""标题栏""尺寸标注""节点编号""文字段落"等区域。
• 视觉切图：把检测到的图纸区域自动裁剪成子图，避免整页大图检索导致向量语义过于模糊。
• 文本抽取：对图框内文字做 OCR，并与子图建立映射关系。

3.3 索引与检索层

这一层负责把理解结果向量化并存储。检索时采用混合检索：

• 文本检索：用 embedding 模型对 OCR 文本和问题向量做余弦相似度检索。
• 视觉检索：用视觉编码器对子图和问题对应的视觉表示做相似度检索。
• 融合重排：把两种检索结果合并后，用 rerank 模型重新打分，最终保留最相关的子图。

3.4 生成与检查层

这一层对用户可见。它接收检索到的子图和文本片段，交给视觉语言模型（VLM）生成回答。对于合规检查场景，还会配置一套规则模板，把"检查项要求"作为约束条件传给模型，并要求输出结构化 JSON 结果。

3.5 为什么需要 Agent 化

在真实工程中，用户的问题往往不是一次性问答，而是多轮排查链条。例如先问"这个节点属于哪种做法"，再问"相邻节点是否一致"，最后问"是否符合图集的第几条"。这时可以引入 Agentic RAG 的思路：让系统内部先拆解问题、规划检索步骤，再逐轮检索，最终汇总结论。PlanSightRAG 如果要在生产环境落地，这层能力不能缺失。

4. 环境准备与前置条件

下面进入实战环节。由于 PlanSightRAG 并不是一个可以直接 pip install 的现成框架，我采用"按架构组装原型"的方式，选择一套在工程环境里比较容易落地的开源组件组合。重点是把链路跑通，技术选型可以根据团队资源和数据情况替换。

4.1 硬件与运行环境

• 操作系统：Linux / macOS / Windows WSL2 均可。
• Python：3.10 或 3.11。
• GPU：建议 16GB 以上显存。如果只是小规模验证，也可以用 CPU + 较小的开源模型，速度会慢一些。
• 本地部署语言模型：可选用 llama.cpp + Qwen2.5-VL 系列，搭配 FastAPI 封装服务；如果你有 API 调用条件，也可以直接使用视觉语言模型 API。

4.2 安装依赖

下面命令安装核心依赖。版本请以实际项目为准，本文重点演示通用思路。

pip install pdfplumber pip install opencv-python pillow pip install pytesseract pip install chromadb pip install transformers accelerate pip install langchain langchain-community

OCR 需要额外安装系统级 Tesseract：

# Ubuntu / Debian sudo apt-get install tesseract-ocr tesseract-ocr-chi-sim # macOS brew install tesseract tesseract-lang

4.3 模型选择

视觉向量编码可以选择 CLIP 系列或 Qwen2.5-VL 的图像编码器。生成环节建议选择支持图像输入的视觉语言模型，例如 Qwen2.5-VL 的 7B 版本。模型名称和 HF 仓库 ID 以你实际使用的版本为准，不要盲目追新。

5. 核心模块实现：从图集解析到视觉索引构建

5.1 PDF 图集解析与页面图像生成

假设输入是一本 PDF 格式的标准图集。先用 pdfplumber 把每一页渲染为高清图像，同时提取文本层。

# parse_plans.py import os import pdfplumber def extract_pdf_pages(pdf_path, output_dir, dpi=200): os.makedirs(output_dir, exist_ok=True) page_items = [] with pdfplumber.open(pdf_path) as pdf: for page_index, page in enumerate(pdf.pages): page_no = page_index + 1 image = page.to_image(resolution=dpi).original image_path = os.path.join(output_dir, f"plan_p{page_no:03d}.png") image.save(image_path) page_items.append({ "page_no": page_no, "image_path": image_path, "text": page.extract_text() or "" }) return page_items

这里需要留意一个很容易踩坑的点：page.extract_text() 对矢量 PDF 有效，但对扫描版图集基本提取不到内容。所以后续必须叠加 OCR。

5.2 OCR 文字补充

对页面图像做 OCR，把识别出的文本与页面关联起来。考虑到工程质量，建议使用 Tesseract 做初筛，生产环境可以换成 PaddleOCR 这类中文识别更强的方案。

# ocr_plans.py import pytesseract from PIL import Image def ocr_image(image_path, lang="chi_sim+eng"): image = Image.open(image_path) content = pytesseract.image_to_string(image, lang=lang) data = pytesseract.image_to_data(image, lang=lang, output_type=pytesseract.Output.DICT) regions = [] for i in range(len(data["text"])): text = data["text"][i].strip() if text: regions.append({ "text": text, "x": data["left"][i], "y": data["top"][i], "width": data["width"][i], "height": data["height"][i], "confidence": float(data["conf"][i]) }) return content, regions

OCR 的置信度信息一定要保留下来。合规检查场景中，置信度过低的文字不能作为判断依据，需要在结果里标出"低置信度区域，请人工复核"。

5.3 版面分析与图纸区域切分

这是视觉优先的关键一步。用目标检测模型识别页面中的图框和图纸区域后，把整页图切成若干子图。部署时可以选择成熟的版面分析模型，或者用 OpenCV 的轮廓检测做简单版。

# detect_regions.py import cv2 def detect_drawing_regions(image_path, min_area_ratio=0.02): image = cv2.imread(image_path) gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY) _, thresh = cv2.threshold(gray, 200, 255, cv2.THRESH_BINARY_INV) contours, _ = cv2.findContours(thresh, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) h, w = gray.shape[:2] regions = [] for contour in contours: x, y, rw, rh = cv2.boundingRect(contour) area = rw * rh if area >= min_area_ratio * h * w: regions.append({ "bbox": [int(x), int(y), int(rw), int(rh)], "center": [int(x + rw / 2), int(y + rh / 2)] }) return regions

版面分析模块的输出不只是一个框，还应该有区域类型标签，例如"标题栏""节点详图""尺寸标注""文字说明"。有了类型标签，后续检索时才能做加权。

5.4 视觉向量化与多模态索引

切分好的子图通过视觉编码器转成向量。文本通过 embedding 模型转成向量。两者写入同一个向量数据库。

# build_index.py import chromadb from chromadb.utils import embedding_functions # 简化示例：视觉向量由视觉编码器生成，这里假设已经封装好 def get_visual_embedding(image_path): # 生产环境可调用 CLIP / 视觉语言模型的 image encoder pass def get_text_embedding(text): # 生产环境可调用 embedding API 或本地模型 pass client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection( name="plan_sight", metadata={"hnsw:space": "cosine"} ) def add_plan_item(item_id, image_path, text, bbox, page_no): visual_vec = get_visual_embedding(image_path) text_vec = get_text_embedding(text) # 多模态场景可将视觉向量与文本向量拼接或加权融合 embedding = visual_vec # 为演示，使用视觉向量作为主向量 collection.add( ids=[item_id], embeddings=[embedding], documents=[text], metadatas=[{ "image_path": image_path, "bbox": str(bbox), "page_no": page_no }] )

这里使用的向量数据库是 Chroma，简单、单机可跑。生产环境可以考虑 Milvus 或 Elasticsearch 向量检索能力，差别主要是规模和高可用。

索引阶段有一个重要经验：如果子图数量大（比如整本图集切出几万张图），不要把所有向量塞进同一个 collection。建议按图集编号或章节建立多个 collection，检索时先定位图集范围，再做细粒度检索，可以明显提升准确率。

6. 完整示例：基于 PlanSightRAG 的问答与合规检查

6.1 混合检索实现

用户提问"反梁节点处防水卷材在这本图集中要求上翻多少"，系统先对问题进行文本编码，同时结合关键词过滤准确定位图集，再查向量库。

# search.py def retrieve(query, collection, top_k=5): query_vec = get_text_embedding(query) results = collection.query( query_embeddings=[query_vec], n_results=top_k, include=["documents", "metadatas", "distances"] ) return results

为了让这类项目能稳定落地，还需要在原始向量检索后加一个重排阶段。第一轮先粗召回 20 到 50 条，再用单塔重排模型对图文上下文与问题做精细打分，最后取 top 5。重排模型（Rerank）对多模态 RAG 的改善通常非常明显，尤其是在图集这种"相似页面多、语义差异小"的数据集上。

6.2 问答生成：VLM 结合图片上下文

检索到子图之后，把图像和文本上下文拼进提示词，交给视觉语言模型生成答案。

# generate_answer.py from transformers import Qwen2_5_VLForConditionalGeneration, AutoProcessor from PIL import Image model_name = "Qwen/Qwen2.5-VL-7B-Instruct" model = Qwen2_5_VLForConditionalGeneration.from_pretrained( model_name, torch_dtype="auto" ) processor = AutoProcessor.from_pretrained(model_name)

回答生成的服务封装如下：

# answer_service.py def ask_with_image(question, image_path, context_text): image = Image.open(image_path) messages = [ { "role": "user", "content": [ {"type": "image", "image": image}, {"type": "text", "text": ( "你是土木标准图集问答助手。请根据这张图纸和附加说明回答问题。\n" f"附加说明：{context_text}\n" f"问题：{question}\n" "如果图纸中没有足够信息，请直接说明，不要猜测。" )} ] } ] text = processor.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) inputs = processor(text=[text], images=[image], return_tensors="pt") outputs = model.generate(**inputs, max_new_tokens=512) return processor.batch_decode(outputs, skip_special_tokens=True)[0]

这里有一个容易被忽视的细节：不要只传一张页面大图给模型，而是要把检索命中的子图和它的坐标信息一起传入。这样模型能看到"图纸的某个区域"而不是"整页糊成一团"。

6.3 合规检查：从问答到规则约束

问答可以相对开放，但合规检查必须有明确边界。合规检查不能只靠 LLM 自由发挥，必须叠加规则模板。规则模板的核心是：把检查要求写成结构化约束，并要求模型输出固定格式 JSON。

# compliance_check.py import json COMPLIANCE_PROMPT_TEMPLATE = """ 你是土木标准图集合规检查助手。请对输入的图纸区域进行合规性检查。 检查依据： {rule_text} 图纸说明文字： {context_text} 要求： 1. 只依据图纸中可见的信息判断。 2. 如果图纸信息不足，状态输出 UNKNOWN，并说明缺少什么信息。 3. 输出 JSON，格式如下： { "status": "COMPLIANT | NON_COMPLIANT | UNKNOWN", "reason": "判断依据，引用图纸中的可见内容", "evidence": "图纸中支持判断的文字或标注", "suggestion": "如果不合规，给出整改建议" } """ def compliance_check(question, image_path, context_text, rule_text): prompt = COMPLIANCE_PROMPT_TEMPLATE.format( rule_text=rule_text, context_text=context_text ) image = Image.open(image_path) messages = [ { "role": "user", "content": [ {"type": "image", "image": image}, {"type": "text", "text": prompt} ] } ] # 调用视觉语言模型，得到文本 raw = call_vlm(messages) # 容错解析 JSON try: return json.loads(raw) except json.JSONDecodeError: return { "status": "UNKNOWN", "reason": "模型输出无法解析为 JSON", "evidence": raw, "suggestion": "请人工复核" }

合规检查的"检查依据"不能简单地由用户口头描述，建议从规则知识库中检索。这里可以进一步引入 Ontology RAG 的思路：把规范条文、图集编号、构造做法之间的关系构建成工程知识图谱，合规检查时先通过图谱找到"本节点涉及哪些规范条目"，再带着这些条目去检查图纸。这种结构化约束能显著减少 VLM 的幻觉。

6.4 整合成一个可运行脚本

把以上模块串起来，形成一条完整的命令式流程。

# run_inspection.py import argparse def main(): parser = argparse.ArgumentParser() parser.add_argument("--question", required=True) parser.add_argument("--rule", required=True) parser.add_argument("--topk", type=int, default=5) args = parser.parse_args() results = retrieve(args.question, collection, top_k=args.topk) # 取第一个命中项做演示，实际生产可以合并多个 item = results["metadatas"][0][0] image_path = item["image_path"] context_text = results["documents"][0][0] answer = ask_with_image(args.question, image_path, context_text) print("问答结果：", answer) report = compliance_check( question=args.question, image_path=image_path, context_text=context_text, rule_text=args.rule ) print("合规检查结果：", json.dumps(report, ensure_ascii=False, indent=2)) if __name__ == "__main__": main()

7. 运行结果与效果验证

7.1 运行命令

python run_inspection.py \ --question "图集4-3页的底板防水卷材上翻高度是多少" \ --rule "防水卷材在反梁节点处应沿墙面上翻，且上翻高度不应小于设计要求"

7.2 预期输出

运行成功后会看到两部分输出：问答结果和合规检查结果。合规检查结果类似：

{ "status": "COMPLIANT", "reason": "图纸中标注该节点卷材上翻高度为500mm，大于设计要求的最小值。", "evidence": "可见标注：上翻500", "suggestion": "" }

7.3 如何判断系统是否达标

一个多模态 RAG 系统是否真正可用，不能只看一两个例子。建议搭建一个小规模评测集，包含三类用例：

• 检索用例：给定问题，人工标记哪些图纸区域是正确答案，计算 Recall@K。
• 问答用例：给定问题和图纸，人工写参考答案，计算回答准确率和漏答率。
• 合规检查用例：给定图纸和规则，人工标注合规/不合规，计算一致率。

如果 CR（Criteria Rate）达不到团队可接受阈值，先不要调模型，优先检查版面切分和检索召回。多数多模态 RAG 项目效果不好，问题不是出在生成模型上，而是出在检索阶段根本没有把正确的子图找回来。

7.4 失败时第一步看哪里

如果整体输出明显不正确，按顺序排查：

1. 先看检索命中的 image_path 是否是正确区域。
2. 再看传入 VLM 的上下文文本是否包含关键标注。
3. 最后才是检查提示词约束是否清晰。

这个顺序很重要。直接改提示词往往是在补救一个错误检索结果，治标不治本。

8. 常见问题与排查方法

9. 最佳实践与工程建议

9.1 图集版本管理要前置

标准图集会更新、作废、替代。索引数据如果混入多个版本的图集，合规检查极易出错。工程上建议按"图集编号 + 版本号"创建隔离的 collection，并在元数据中保存版本号、生效日期、作废日期。检索时先按版本过滤，再做向量排序。

9.2 混合检索是底线能力

视觉优先不代表放弃文本检索。在实际工程数据上，最好的方案是文本召回、视觉召回、版面属性过滤三者结合，最后用重排模型统一排序。图纸上那些编号、尺寸文字，往往是文本检索的高信号内容，不能浪费。

9.3 合规检查需要可解释性

LLM 生成的合规结论如果没有依据，在生产环境是无法被工程师采信的。PlanSightRAG 输出的每条结论，都应该能追溯到三个层面：

• 图纸层面：命中哪张图、哪个区域、哪条标注。
• 文本层面：命中哪段 OCR 文字、置信度多少。
• 规则层面：依据的是哪条规范或图集条文。

有了这条溯源链，工程师才愿意把系统当作"辅助初筛工具"而不是"黑盒判断机器"。

9.4 人机协同比全自动更现实

在建筑工程领域，合规检查直接关系安全和责任，系统适合做的是"批量预筛 + 可疑项排序"：先把明显合规和明显不合规的图纸筛掉，把边界模糊、低置信度的情况标记出来，交给注册工程师重点复核。这个定位比追求百分百自动化更务实，也更容易在团队里落地。

9.5 安全与权限

图纸数据通常是企业内部敏感数据。部署时建议私有化部署，模型本地运行，不要把图纸图片直接发往外部 API。向量数据库、OCR 服务、模型服务之间要做网络隔离，访问要控制到最小权限。涉及生产项目数据时，先在测试环境验证全流程，再逐步扩大范围。

10. 总结与后续学习方向

PlanSightRAG 这类视觉优先多模态 RAG 解决的核心问题，是让检索系统能像人一样"看图找依据"，再结合大模型生成能力完成问答和合规检查。它的技术关键不在生成端，而在索引端：版面分析是否准确、图像切块是否合理、视觉向量和文本向量是否对齐、重排是否到位。这些环节决定了整个系统的上限。

如果你要在实际项目中落地，建议按这个顺序推进：先做一个小规模图集数据切片，跑通解析、切图、索引、检索、问答的闭环；再用测试集量化评估检索和问答的准确率；最后再引入规则模板、知识图谱和 Agent 化流程，逐步扩大覆盖范围。

后续值得深入研究的方向有三个。第一是 Agentic RAG，让系统具备多轮检索、计划拆解和工具调用能力，用于复杂节点审查。第二是 Ontology RAG，把图集规范构建成工程知识图谱，让合规检查的规则检索更准确、更可解释。第三是更细粒度的视觉定位模型，把用户问题直接定位到图纸像素级区域，进一步提升检索精度。

先把一条最小链路跑通，你就已经超越了大多数还在"把 PDF 切一切丢给 ChatGPT"的团队。