Drawing_To_Model

背景

• 这是个人入职工业公司使用大模型做的项目，目前已经实现了 Demo，这个项目实现的内容个人调研发现目前工业界没有太多可参考资料，所以我希望开源自己的思路为大家提供思路参考，由于工业场景的工作内容较为垄断封闭，与个人职业发展不符所以已经离职，该项目大概率不会继续更新了，但是如果以后有机会还是希望能做成一个有价值的项目，也不枉个人连续加班四个月搞出来的结果(😭)

• 使用大模型将工业场景下机械零件 2 维PDF 矢量图转换成 3D 零件模型(PDF-->STEP-->Prt)

  • 输入：由Creo 软件导出的机械零件2维PDF 格式矢量图(分辨矢量图：放大几何图线段分辨率不变)

  • 注：为防止泄密，原输入 PDF2 维矢量图不提供，仅提供截图用来参考

  • 阶段 1 输出零件模型格式：通用但是无法被 Creo 直接修改的 SETP 格式(已实现)

  • 阶段 2 输出零件模型格式：Creo 可以读取修改 Prt 格式(待实现)

实现方法：

阶段1 ： 使用 PymuPDF提取并整理PDF矢量图信息(无大模型接入)

1. 根据机械图中定位框特征使用正则+位置(如横向为数字，纵向为字母，且靠近图纸边缘等信息)，构建识别定位框逻辑并划分定位框区域

   1. 注：当前使用 PDF 中坐标信息生成定位框区域范围泛化性不足，后续优化可用 GPT 多模态视觉模型直接识别定位

2. 定位框框选区域内即为内容区域，进一步进行信息处理：

   1. 构建箭头标志检索规则，微微扩大箭头所在坐标区域作为草图区

   2. 使用 pymuPDF中find_tables方法检测表格描述的注释信息，并将注释信息根据所在框分类，之后根据坐标进行排序处理。

   3. 非草图区、表格注释区内容按照注释区处理

3. 对草图区进行进一步处理：

   1. 根据坐标划分贝塞尔曲线、直线、折线、矩形、三角形等

   2. 进一步划分引导线、尺寸界线

      1. 注：使用 GPT5.4 识别几何图，对于引导线中尺寸界线、与径向线连接一起的引导线等复杂引导线对应的部位识别效果较差，可以通过坐标关系结合规则补充图中可见但是复杂信息、需要推测得到的信息，可以大大降低模型不稳定性。
      2. 比如：弧心位置的确定，弧心与对应圆弧的确定，

3. 生成轮廓线组合、弧心圆心参考位置等补充信息(其中圆心、弧心等中心点位于多条线交点，模型识别效果较差)

   1. 注：圆心弧心位置需要显著标明，圆弧方向比如凹凸需要形成固定证据

4. 提取草图信息使用 Json 数据格式保存，以上示意图为 Json 数据的可视化，最终输入结果为草图区的几何分析图以及一些中心点识别、尺寸标注等等 Json 数据，输出为图中尺寸值以及对应部位的绑定关系 Json 文件，格式如：{英文名："xxxx", 尺寸值: num, "中文名": "xxxx"}

   阶段 2 构建RAG知识库

   1. 注：本项目使用 build123d 开源包来生成建模代码

   2. 收集 build123d 官方示例代码和说明文档来构建本项目所用知识库

      1. 第一层：文档切分(总结就是按文件边界、RST文档结构、关键标记来划分)
         1. 示例模型examples/ 目录下每个 .py 文件直接作为一个 chunk，不做额外切割。同时根据文件中固定格式中的关键字会来解析出 docstring 摘要、建模步骤、关联文档和关联图片(取示例中的关键字 API 进行解析处理)。
         2. 在完整示例 chunk 之外，同一份代码再按代码模式关键字做二次切分：检测到 hole、fillet、sweep、pattern 等特定 API 关键字时，取匹配行前后各 5~10 行作为窗口，截出一个子 chunk。每种模式每个文件最多取 3 个片段(关键字是单独生成的)。
         3. 入门示例模型general_examples.py 和 general_examples_algebra.py 是两个巨大的示例合集文件，按 Ex. 1、Ex. 2... 这类标记拆成独立 chunk，同时从对应的 .rst 文档中提取每个示例的标题(切分前需要对知识库文件进行关键词匹配关联)。
         4. RST 文档里如果有 .. literalinclude:: xxx.py 指令引用了 Python 文件，就把该 RST 章节中在此指令之前的解释文本 + 被引用的代码文件内容合并为一个 chunk（取解释文本最后 2500 字，literalinclude 一般是对整个 py 文件代码的解释）。
         5. RST 文档里的 .. code-block:: python 内联代码块，会把代码块前面的章节解释文本（取最后 1800 字）+ 代码块内容合并为一个 chunk(code-block 一般是文档中附部分代码进行说明)。
         6. RST 文档按章节标题（===== 或 ------ 下划线格式）正则匹配切分，每个章节独立成 chunk。只保留包含建模关键词（extrude、hole、sketch 等）的章节，过滤掉安装说明、调试日志等非建模内容。
      2. 第二层：在 1 基础上构建标签体系：
         1. 根据 build123d 官方文档和示例信息构建关键词映射表，每个表都是一个 {标签名: 关键词列表} 的结构
         2. 关键词映射表分为：零件类型、几何特征、操作类型、几何形状、布局方法、拓扑选择、构建方式、基础族、轮廓类型等多维度分类信息
         3. 提取补充标签信息：mode(建模方式，分为代数和封装 API 调用两种模式)、判断单体还是组装体、chunk 信息来源(手动添加权重，如代码比文档权重要高)
         4. 抽取 build123d 库中的 API，对应 2 中多维度分类具体实现的方法
         5. 添加复杂度评分：
            1. 根据操作赋予权重，如旋转和拉升就是不同难度，所以权重不一致
            2. 示例模型特征种类累加，越多分越高
            3. 构造方式权重，比如：扫掠获得和组装获得权重不一致
            4. 代码长度
            5. 特殊特征加成，比如凸台、钣金弯折等
            6. 纯文档有封顶分数
         6. 构建标签体系完成后，绑定示例模型所对应的标签
      3. 第三层：Embedding 向量化并优化储存
         1. 使用 OpenAI 的 text-embedding-3-small (也可以用其他 Embedding 模型)进行 Embedding
         2. 使用 LanceDB 进行储存
            1. LanceDB：
               1. 优势：数据少直接纯本地划算、嵌入式运行不需要与数据库交互(也可以启动 Server 模式)、列式存储格式、同时支持向量检索 + 元数据过滤(sql 过滤)(储存底层格式有优化)、开源、兼容性好(LangChain、LlamaIndex 原生集成，可以直接用 Pandas、Pyarrow 读取)
               2. 缺点：单机模式下多进程同时读写同一个本地文件，会有锁冲突，并发写不强； 大数据量不行；GPU 加速不完善
               3. 简单类比：FAISS = 高性能向量索引工具包，只管向量，不管元数据存储、过滤、增删改 ，其他全部自己手写；LanceDB = 带完整数据库能力的嵌入式向量库，文件即数据库，向量、文本、标签全部统一管理。
         3. 对元数据进行优化处理：
            1. 标签倒排索引：举例就是仓库里每个零件箱子外面贴了属性标签，想找"带通孔的法兰"，就去查"通孔"和"法兰"标签，拿到两批箱子编号，取交集。
            2. API 倒排索引：精确到"这个零件用了哪个 build123d API"。比如确定需要用 CounterBoreHole 这个函数，直接查 API 倒排就能拿到所有用过它的代码示例。
            3. 关键词倒排索引：把每个 chunk 的标题、摘要、检索文本、标签、API 名称全部混在一起做分词，去掉停用词（the、and、with 这种无意义的），建立最基础的词 → chunk 映射。
      4. 第四层：检索召回（与知识库 Query 文件生成部分是同步的）
         1. 将构建的 query 脚本信息拆分成 Item，用于逐一匹配
         2. 对于每个 Item，依次走标签召回 --> API 召回 --> 关键词召回
         3. 对于整个 query 拆分成的 query item，单独进行向量化计算相似度
         4. 根据不同召回方式以及搭配多方面信息进行排序
            1. 正向加分：标签召回(人工设计，精准度最高) > 向量分(综合语义召回) > API 召回(精准度高但是难命中) > 关键词召回(兜底策略，但是噪音较大) > 来源权重(完整示例>分割示例) > 复杂度权重(优先召回与当前零件复杂度类似的模型示例)
            2. 负面惩罚：
               1. 超复杂惩罚，召回零件复杂度远高于当前零件，扣分
               2. prompt 中禁止内容命中，扣分
            3. 额外加分(权重相比前两个很小)：
               1. 当前零件整体特征命中，额外加分
               2. 单独特征、组合特征命中，额外加分
               3. 操作方式命中，额外加分
         5. 最终召回示例分为：参考整体建模(比如弯折就必须从整体来看，优先实现)、参考局部特征实现(比如凸台上圆弧和打孔)、参考 API 调用(具体如何实现)

      阶段 3：构建知识库召回Query(GPT5.4)

      1. 输入：根据阶段 1 生成的尺寸值-对应部位绑定 Json 信息以及"最终输入图"、约束 Prompt，生成从知识库召回示例模型的 Query
         1. Prompt 包含草图区外包含三视图确定方法、尺寸数值的信息处理、包含内容所对应参数含义、定位关系识别引导、检索模型规则等等信息
      2. Query 中包含内容主要为以下部分：
         1. 当前模型整体外形信息，如当前零件为钣金弯折件，水平和竖直部分分别有凸台，凸台上有圆孔等等(帮助模型理解当前零件形状，方便筛选大类)
         2. 根据 2D 草图中不同视图，按照视图对尺寸信息和描述信息进行归类(整合 2D 图纸方便后续处理)
         3. 根据零件局部特征，如水平部分、竖直部分整理不同部分包含的基础特征以及特征信息(方便后续根据特征召回)
         4. 从零件特征、组合特征、实现操作、复用模式、参数化多维度构造检索查询，提取可复用参数化代码 / 几何模式，同时设置检索标签与排除标签(多维度召回)。

      阶段4： 构建几何关系(GPT5.4)

      1. 当前已有信息主要是可视化文字信息以及简单直接的推导信息，建模还需要补充一些深层需要推导的几何关系信息

      2. 输入：阶段 3 生成的 Query 和 使用 Query 召回的示例模型结果

         1. 示例模型提供所需要生成的关键几何关系(当前 GPT5.4 还存在部分几何关系明显但是依然保守输出的问题，依然需要把卡点变成明确事实才能使用，个人感觉 5.6 会一步到位效果更好，未尝试)

         2. Prompt 中需要补充工业零件常识信息、方向判断方法、推测数值计算方法、思考顺序等等引导补充信息

         3. 召回的示例模型如下：

      3. 输出几何关系信息主要包含：

         1. 如：弯折宽度信息传递，如在弯折两侧部分有其中一个包含该信息，可以传递到另一侧以及共有地方
         2. 如：弯折件厚度、弯折倒圆角中内弧和外弧的半径长度关系等信息

      4. 校验迭代：根据设定 Prompt 处理推测的几何关系、尺寸链信息自相矛盾不自洽问题(最大迭代 3 次)

      阶段5： 生成建模思路和建模代码(GPT5.6Sol)

      1. 第一步：提取输入Query、几何关系、召回示例模型的信息摘要，如 Query 中只需要零件整体信息、整理归类后的可视化数值和描述信息， 几何关系只需要其中与 Query 不重合的关键补充信息，召回示例模型信息只保留召回示例模型包含的基础特征，实现操作方式，具体使用 API，生成代码模式，禁止参考事项等对建模可参考信息

         1. 这一步的目的是 1 是这三类信息中很多冗余信息 2 信息过多稀释模型注意力 3 信息过多 GPT5.6 容易连接超时 4 降低token消耗(输入文件大小从 100K ，处理后降低到 20K)

      2. 第二步：根据 Prompt 约束和建模思路示例生成当前零件的建模思路

         1. 注：该建模思路是对 1 中信息的进一步融合提取关键信息，并将关键信息按照建模思路组合起来提高建模准确率(后续验证发现稳定性和准确率都提高了 10%左右，但是不加建模思路其实也可以生成零件准确率也在 80% 左右)

         2. 建模思路示例如下：

      3. 第三步：结合第一步结果和第二步结果，生成具体的建模代码

         1. 测试发现 GPT5.6Sol 确实比 GPT5.4(最高质量模式下)生成建模思路、建模代码效果好，同样输入情况下GPT5.4 基本无法准确生成建模代码

      4. 第四步：验证生成的建模代码是否存在语法问题，如果存在语法问题，提取问题摘要加入到生成建模代码 Prompt 中，重新生成(最大重试 3 次)

      5. 备选方案 1：复杂模型考虑为生成的模型生成三视图，让模型比较原始三视图来迭代优化(感觉会把问题复杂化，未尝试)

      6. 备选方案 2：分阶段生成零件模型，比如当前零件，先生成弯折板，再构建凸台，最后打孔(GPT5.6 未尝试，对于当前简单零件完全没必要，复杂文件可以尝试，还未对复杂零件进行尝试)

      阶段6：使用LangGraph框架、Harness 架构进行工程化

      1. 节点（Node）+ 图（Graph）：把之前的每个阶段处理逻辑整理成不同的 Node，不同 Node 之间互相串联并注册到图中，支持根据条件进行分流
      2. 状态机制（State）：之前不同阶段串联主要依靠上个阶段的结果 Json 文件，当前使用 State 机制统一管理，比如数据部分：统一管理当前零件相关信息、阶段产物路径、运行记录等文字信息； 阶段执行规范信息：阶段名称、输入输出信息、执行函数、执行记录等等，用于生成报告。
      3. 统一处理（错误处理 / 重试 / 修复） ： 原来哪个阶段出错就在哪个阶段崩，当前情况由于每个阶段都有状态机制，所以能自动捕获错误，根据错误类型进行修复并自动重试，记录可以在报告中查看，方便分析每个阶段的运行情况。
      4. 一键入口（Harness）+ 运行记录 : 一个命令跑完全流程；每个阶段相关记录都有总结，一份是 Json 文件用于Node 之间串联使用，一份是 Markdown 文件用于分析。
      5. 感觉当前还是比较简单的使用框架，后续有很多的优化空间。

   思考

   1. 个人认为可以将该项目加入人工接入模块，用于模型遇到难以处理的问题时候人工介入，提供复杂模型生成准确率低的一种解决方法。
   2. build123d 当前的示例模型还是较少，对于非常复杂的工业模型个人认为是可以实现，但是需要非常熟练的掌握build123d 库的使用，并且需要把一些通用的复杂零件构建建模代码新增到 RAG 中，才能进一步提高建模准确率
   3. 经验：GPT5.4 模型使用过程中我发现了以下几个问题：

      1. 大模型越权，当前随着大模型能力越来越强，同时也出现了更多能力强模型专属的问题，如大模型训练优化方向是高效、最优解，但是这样会导致模型在处理任务过程中自认为找到了最优解，导致越过 Prompt 约束，此时需要精细每个阶段的颗粒度，为每个小阶段都说明具体目标，防止越权

         1. 具体表现比如：推理部分是按照你的引导来生成的，没有问题，但是结果根本不顺着推理生成，而且大模型直接给个自认为更可信的结果(睁眼说瞎话)

      2. 回答过于保守，GPT 系列模型的一个通病(或者说当前能力较强模型的一个通病)，为了降低回答错误率，大模型回答的策略可能更偏向于模棱两可，保守回答留有余地，并且不使用保守证据，导致很多模型其实可以识别推理的信息，因为保守属性而放弃使用该信息，此时需要明确告知如果依据已有明确信息，可以推测出已有推测信息，不得保守表达，也不得启用该类信息

         1. 比如已经识别到弯折部分的宽度是可以根据已有信息推测的，已有部分类似表达，但是最后依然打上保守处理的标签，导致该信息无法使用

      3. Prompt 中规则和引导提示词占比，如果规则过多而任务目标需要经过较为复杂的处理步骤，就会出现模型处理的任务目标变成了绕过规则，而引导词过多则会贴近于当前零件，丢失泛化性。

      4. 当前大模型都无法看到其思维链，所以只能根据结果来分析原因，并且无法限定温度(同事测试发现 GPT5.4 就算控制温度，top-k 等参数依然不能让每次输出都一致，所以需要 Prompt 中引导正确并且搭配一些生成证据来保证稳定性)

      5. 这是个人使用 GPT 最新模型处理项目问题的经验，我个人 Prompt 写的不算太好，所以遇到的问题可能是不规范导致的，欢迎Prompt 厉害的伙伴指正讨论。

   结尾

   1. 具体项目流程图以及项目代码见：drawing_to_model
   2. Build123d 项目地址：build123d