LLM读取工程图纸：准确率从50%到95%的实战复盘

把ChatGPT直接怼到一张工程图纸上，让它提取IO清单，准确率大约50%——这是比利时软件公司Nebulae客户最初尝试的结果。对于需要精确到每一个传感器、执行器接线点位的建筑自动化项目来说，50%意味着工程师仍然要逐行复核，工具形同虚设。

Nebulae为这位客户构建了一套人机协作的文档解析工具，把读取准确率拉到了95%以上，并且已经在真实项目中日常使用。他们的技术负责人说，以前处理一张图纸要预留两个小时，现在「咖啡还没凉就检查完了」。

这篇文章拆解他们做对了什么。

任务：为什么工程图纸这么难自动化

每个建筑自动化项目都从同一堆文档开始：多页Visio图纸，标注着数百个输入输出连接点，用箭头和图形区分信号类型与方向。暖通空调、气候控制和照明系统的控制器选型和接线，全部依赖这份图纸。

工程师需要逐点识别：数字还是模拟、输入还是输出、属于哪个设备、叫什么名字，然后按正确顺序转录成结构化的IO清单。

这个任务的难点在于，它依赖读图者理解一套视觉约定，而不是纯文本匹配。同一个符号在不同图纸里可能有细微差异，命名规则是项目特定的，甚至同一家公司的图纸经过多年迭代后会形成自己的「方言」。

对于有经验的工程师，这是每份文档一到两小时的高度重复劳动。漏读或误读一个符号，就可能传导到现场接线错误。

IO清单（I/O List） 是建筑自动化、工业控制领域的核心工程文档，全称输入输出清单。它逐行列出控制系统中每一个信号点的完整属性：点位编号、所属设备、信号类型（数字量DI/DO或模拟量AI/AO）、方向（输入还是输出）、物理地址、接线端子号以及命名标识。这份清单是控制器选型、线缆敷设、现场接线和后期调试的唯一依据，任何一处遗漏或错位都会直接导致现场设备无法联动甚至损坏。因此IO清单的准确性要求极高，既不能漏点也不能错序，这也是为什么纯文本级别的模型输出在此场景下几乎不可接受——工程师需要的是可直接施工的成品文档，而非近似正确的结果。

第一次尝试：直接问模型，结果不理想

客户最早试了最直觉的方案：把图纸直接丢给ChatGPT，让它输出IO清单。

结果准确率大约50%，甚至更低。这个数字的意义不在于「模型不行」，而在于：如果工程师仍然需要逐行复核，那这个工具没有节省任何时间，反而增加了信任成本。

问题出在两个地方。第一，plain text提取会丢失符号与连线之间的空间关系，而那个关系恰恰是判断信号归属的关键。第二，模型不知道这个团队的命名习惯和设备配对规则，只能按通用理解去猜。

Few-shot示例（少样本提示） 是大模型应用中一种通过上下文学习的技术：在提示词中提供若干条与目标任务高度相似的输入输出范例，让模型在不更新参数的情况下推断出所需的模式、格式和领域规则。相比微调，few-shot部署成本极低、迭代迅速，特别适合命名规则、字段结构等项目特定知识。在工程文档解析中，few-shot示例的质量直接决定模型能否学会客户内部的命名习惯。Nebulae从客户历史的热泵、通风、暖通项目中提取样本，正是为了让模型对齐该团队的实际术语体系，而不是依赖通用训练数据里的教科书式表达，这一步是准确率爬升的重要来源。

五个改动，把准确率推到95%

Nebulae没有试图构建一个全自动黑盒。他们的判断是：在混合了厂商特定符号、项目特定命名和多年演化图纸的场景下，没有模型能达到100%。所以工具的设计目标从一开始就是human-in-the-loop——AI负责读，工程师负责最终确认。

准确率的提升来自工作流设计，而不是更聪明的提示词。

1. 每页给模型两种视图

每一页图纸分两次输入模型：原始文本层，保证标签的精确性；同一页的渲染图像，保留符号与周边元素的从属关系。

他们还自己写了预处理管线，提取页面上每个元素的精确位置，让模型按照人的阅读顺序（从左到右、从上到下）去读图，而不是按PDF内部存储的随机顺序。这个细节很关键——顺序错了，IO清单的顺序就错了，而现场工程师是按顺序施工的。

PDF文本层与渲染图像的区别 是理解多视图输入价值的关键。PDF文件内部通常保存着一个不可见的文本层，记录了每个字符的精确编码和字符串内容，适合提取标签名称；但它不描述图形、箭头、连线的位置含义，且元素的内部存储顺序往往是随机的，与人类阅读顺序无关。渲染图像则把页面像素化，保留了符号形状、连线走向和空间从属关系，模型可以据此判断某个标签属于哪个设备。两者结合才能兼顾“读得准”和“看得懂”。Nebulae自建预处理管线提取元素坐标并按从左到右、从上到下的顺序重排，本质上是把视觉空间信息转换成有序的阅读流，避免IO清单顺序错乱，因为现场施工是严格按顺序进行的。

2. 要求结构化、有序的输出

模型直接返回固定结构的、有序的IO清单，工程师拿到的是一个可以检查的成品框架，而不是从零开始构建。

3. 用客户自己的历史项目做few-shot示例

他们从客户过去的热泵安装、服务器机房通风、暖通空调系统等项目里提取了一组小样本库。模型因此学到的是这个团队实际使用的命名规则和设备配对方式，而不是教科书版本。每一页图纸还会对照它自己的图例来读取。

4. 保留人工检查点

每个提取结果都进入一个审查界面：左边是原始图纸，右边是AI的结构化读取结果。工程师可以在几秒内检查并修正类型、方向、命名或顺序，而不是重新推导一遍。

5. 把活干完

工程师确认后，审查过的清单直接组装成现场团队可用的最终文档。没有额外的格式化步骤，不需要在工具之间复制粘贴。

模型选择：Gemini，但只是一个时间点上的快照

Nebulae当时选择Google的Gemini，理由是它在真正的多模态推理上表现最强——能在一次处理中同时读取渲染图像和底层文本，而不是把多个工具拼接起来。成本也足够低，可以在完整的多页图纸集上运行而不至于让每个项目的AI开销变成一条显眼账单。

他们特别强调：模型迭代很快，这个选择是当时的一个快照，不是推荐。

多模态推理 指模型能够在同一次推理过程中同时理解多种输入模态（如文本、图像、表格）并建立跨模态的关联。在工程图纸解析场景中，这意味着模型可以把渲染图像中某个符号的形状、位置，与文本层中对应的标签字符串直接对应起来，而不是先用OCR识别文字、再用另一个模块定位图形、最后人工拼接。这种端到端的多模态能力显著降低了管线复杂度和误差累积。Nebulae选择Gemini正是看中这一点，但需要强调的是，多模态模型迭代极快，今天的优势可能半年后就被追平，因此模型选型应视为可替换的时间点快照，而非长期架构决策，工作流设计才是更稳定的资产。

关键的学习

Nebulae的复盘里有几条值得记下的判断：

提升来自工作流，不是提示词技巧。 结构化输入、结构化输出、在信任之前加一个人工检查点——这三件事把结果从50%推到了95%以上。

为审查而设计，不是为100%而设计。 一个快速的审查步骤，才是让输出可以安全投入使用的关键。追求全自动反而会卡在最后一公里的准确率上。

用团队自己的例子。 模型学会这个团队的命名习惯和设备配对，靠的是他们自己的历史项目样本。

数字的适用范围有限。 他们明确提醒：这些数字来自一个客户的图纸，你的图纸会不一样，在任何百分比（包括他们这个）被信任之前，先在自己的文档上测量。

这个案例的价值不在于「LLM能读工程图纸」这个结论本身，而在于它展示了一种务实的AI落地路径：不追求端到端自动化，而是找到人类判断力最不可替代的那个环节，让模型处理其余部分。

对于任何仍然依赖人工阅读、转录或复核的工程流程，这套框架——多视图输入、结构化输出、领域样本、人工检查点、无缝交付——可能比换一个更强的模型更值得先试。