Профиль клиента
Инженер-механик в среднем по размеру производителе прецизионных компонентов отвечает за проверку соответствия GD&T (геометрическое задание размеров и допусков) технических чертежей перед их передачей в производство. Его зона ответственности охватывает как входящие чертежи поставщиков, так и результаты внутренней разработки: всё, что попадает на участок, должно быть проверено на соответствие применимому стандарту до начала изготовления деталей. Среди наиболее сложных для проверки — сборки с вращающимися компонентами, зубчатыми передачами и посадками с натягом для втулок: размерные цепи, соосность и допуски биения напрямую влияют на работу и срок службы.
Команда работает в среде с высокой номенклатурой и малыми объёмами, где качество чертежей заметно различается у разных клиентов и поставщиков. Последовательный, прослеживаемый процесс аудита — с документированными выводами и явными ссылками на стандарт — необходим, чтобы обосновывать решения при аудитах поставщиков и на внутренних совещаниях по проектированию. Простых пометок на чертеже уже недостаточно; команды по качеству теперь ожидают, что каждое замечание будет привязано к конкретному пункту стандарта и конкретному элементу.
Проблема
Две структурные проблемы мешали масштабировать существующий процесс проверки.
Первая — узкое место со справочными материалами. Основной стандарт GD&T компании представляет собой технический handbook объёмом 411 страниц. Ни один инженер не может удерживать такой объём спецификаций в рабочей памяти во время активной проверки чертежа. Традиционный подход — держать PDF открытым во втором окне и выполнять ручной поиск — медленный, непоследовательный и приводит к аудиторским записям, которые по сути сводятся к экспертным суждениям, а не к выводам, подтверждённым стандартом. Когда решение по проверке должно выдержать спор с поставщиком по качеству, замечание без ссылки на страницу имеет небольшой вес.
Вторая проблема — доступ к структурированным данным. Чертежи поступали в проприетарных файлах DWG. До применения любой логики GD&T инженеру требовалось получить структурированное представление аннотационного содержимого чертежа: компоновки paper-space, текстовые строки, размерные выноски, вставки блоков и потенциальные рамки допусков GD&T. Делать это вручную, по сущности за сущностью, для сложных сборок непрактично. Без скриптового шага извлечения остаётся только визуальный просмотр — а он не позволяет делать цитирование на уровне сущностей, не поддаётся автоматизации и не повторяется при пересмотре чертежа.
Проверяемый чертёж — стальная катушка в сборе, объединяющая шестерни и втулку — наглядно демонстрировал обе проблемы одновременно. В нём был понятен производственный замысел, но он никогда не проходил проверку на полноту по современному стандарту GD&T. Выявить все пробелы, сослаться на соответствующий пункт handbook для каждого из них и подготовить структурированный отчёт, который можно вернуть инициатору с указаниями по исправлению, требовало процесса, который существующие инструменты не могли обеспечить.
Почему именно сейчас
Требования к качеству у поставщиков постепенно ужесточались, и внутренний чек-лист компании по проектированию для производства был обновлён: для любой вращающейся или прецизионно подогнанной сборки перед выпуском теперь требовалось явное покрытие GD&T — базы, рамки допусков, обозначения шероховатости поверхности и критерии приемки при контроле.
Чертёж стальной катушки был типовым примером: полезная геометрия, частичное нанесение размеров и набор производственных примечаний, которые передавали замысел, но не соответствовали обновлённому порогу полноты. Возвращать чертёж с общим замечанием больше было нельзя. Новый процесс требовал перечисленных по пунктам пробелов со ссылками на стандарт. Делать это вручную для многокомпонентной вращающейся сборки — шестерня, втулка, корпус катушки — при наличии 411-страничного справочника и конвертации DWG в структурированные данные перед проверкой означало бы тратить большую часть рабочего дня на один чертёж. При том объёме проверок, который вела команда, такой темп был нежизнеспособен.
Почему energent.ai
Перед тем как остановиться на energent.ai, команда рассмотрела несколько альтернатив.
Отдельный инструмент для аннотирования PDF мог находить термины в handbook, но не давал возможности связать ссылки на стандарт с конкретными сущностями чертежа или сформировать структурированный отчёт аудита. Таблица с чек-листом и версионным контролем обеспечивала единообразие, но всё равно требовала, чтобы человек вручную заполнял каждую строку, читая чертёж и стандарт в разных окнах. Привлечение специализированного чертёжника для извлечения и сопоставления данных добавило бы сроки и стоимость на каждый чертёж, не повышая повторяемость процесса.
Оценивались и другие AI-инструменты, но рабочему процессу проверки требовались возможности, которые редко сочетались в одной сессии: загрузка бинарного CAD-файла в формате DWG, выполнение скриптов конвертации и извлечения, запись структурированного вывода в CSV и JSON, загрузка и обработка технического PDF на 411 страниц, поддержание доступной для запроса справочной базы по этому документу без риска галлюцинаций и подготовка инженерного отчёта с возможностью цитирования — всё это в рамках одной связной сессии и без ручной передачи между средами.
Решающим фактором стала возможность energent.ai запускать Python- и bash-скрипты в той же агентской сессии, где выполнялся анализ документов. Агент мог запустить конвертер DWG-to-DXF, выполнить скрипты извлечения по результату, сформировать структурированные таблицы с пространственными handle на уровне сущностей, а затем использовать эти таблицы вместе со справкой handbook, чтобы подготовить отчёт, который можно проверять построчно.
Агент также явно учёл риск галлюцинаций. Вместо заявления о том, что он якобы удержал все 411 страниц в надёжной рабочей памяти — что сам агент отметил как ненадёжное для документа такого объёма — он построил внешнюю структурированную справочную базу, включающую семантические заметки на уровне страниц, инвентаризацию понятий и журнал чтения в формате CSV/JSON. Каждое утверждение в итоговом отчёте можно было проследить до диапазона страниц в исходном документе. Такая проверяемость была не бонусом, а обязательным требованием.
Workflow
Сеанс выполнил шестиступенчатый конвейер — от исходного DWG-файла до итогового инженерного отчета.
Шаг 1 — Конвертация DWG в DXF. Агент запустил навык CAD-конвертации для исходного файла и получил валидированный DXF в формате AC1027, что было подтверждено проверкой целостности после конвертации. Сразу выявилась критически важная структурная деталь: аннотационный контент чертежа почти полностью находился в компоновке paper-space под названием "lito", а не в model space. Наивное извлечение, ориентированное на model space, вернуло бы почти пустые таблицы и упустило бы основную часть содержимого чертежа, относящегося к GD&T.
Шаг 2 — Извлечение сущностей в структурированные файлы. Скрипт извлечения инвентаризировал каждую сущность в компоновке paper-space: текстовые строки, размерные обозначения, вставки блоков, слои и координатные границы. Результат был записан в JSON-сводку извлечения — машиночитаемую карту чертежа с пространственными идентификаторами, на которые можно было ссылаться по ходу последующего отчета.
Шаг 3 — Выделение кандидатов GD&T. Второй скрипт отфильтровал извлеченные сущности по признакам, релевантным GD&T: обозначения допусков, метки баз, модификаторы состояния материала и производственные примечания. Результаты были записаны в структурированный CSV с кандидатами GD&T, к которому агент обращался на протяжении всего этапа проверки.
Шаг 4 — Построение справочной базы по handbook. Агент обработал 411-страничный handbook по GD&T в три извлекаемых слоя: семантические заметки на уровне страниц, инвентарь понятий и CSV/JSON-журнал чтения. Выбор был осознанным — вместо попытки удерживать весь документ в рабочем контексте структурированная внешняя справка позволила выполнять поиск на уровне понятий с цитированием диапазонов страниц во время проверки. Дерево знаний можно повторно использовать в будущих аудитах чертежей без повторного индексирования.
Шаг 5 — Инженерная проверка с перекрестными ссылками. Когда были доступны и таблицы чертежа, и справка по handbook, агент подготовил подробный инженерный отчет в markdown. Каждое замечание содержало ссылку на DXF entity handle для указания места в чертеже и на понятие из handbook с диапазоном страниц как нормативное основание. В отчете были разделены подтвержденные хорошие практики и основные пробелы, перечислены рекомендуемые минимальные дополнения GD&T перед выпуском, а также явно отмечены положения, зависящие от символов или схем контроля, как требующие визуальной проверки по исходным PDF-иллюстрациям.
Шаг 6 — Упаковка результата. Было подготовлено четыре файла: конвертированный DXF, инженерный отчет в markdown, таблица аннотаций-кандидатов GD&T в CSV и сводка извлечения чертежа в JSON. Каждый файл выполняет свою роль — DXF для последующих CAD-инструментов, отчет для запроса на исправление, CSV и JSON как проверяемая доказательная база.
Results
Инженерная проверка выявила шесть основных пробелов GD&T в чертеже стальной катушки в сборе:
- Отсутствует указание стандарта чертежа
- Слабая или неоднозначная схема базирования
- Отсутствуют контроль биения и соосности для вращающейся сборки
- Не заданы позиционные допуски для групп отверстий
- Недостаточно определен интерфейс с посадкой с натягом
- Требования к контролю зубчатого колеса указаны без критериев приемки
Седьмое замечание — требования к динамической балансировке без критериев приемки — было выявлено не визуальным просмотром, а из структурированной таблицы кандидатов, что наглядно показывает ценность извлечения на уровне сущностей по сравнению с чисто визуальной проверкой.
Каждый пробел был сопоставлен с соответствующим понятием handbook и диапазоном страниц, что дало инженеру документальную основу для каждого запроса на исправление, а не список неподтвержденных мнений. В отчете также было отмечено, что в чертеже выполнено хорошо — подтвержденные практики, не требующие доработки, — поэтому запрос на исправление получился сфокусированным и практически применимым, а не представлял собой безусловный отказ.
Со стороны справочной базы 411-страничный handbook был преобразован в постоянное, доступное для запросов дерево знаний. Вместо статичного PDF, требующего ручного поиска для каждого нового чертежа, у команды теперь есть структурированная CSV/JSON-справка, по которой агент может искать по понятию для любого последующего аудита. Конвейер извлечения и проверки — от приема DWG до структурированного отчета — воспроизводим для любого входящего чертежа и может запускаться повторно по мере внесения изменений.
Proof
"Больше всего меня удивило качество цитирования. По каждому вопросу в отчете был DXF handle, указывающий на точную аннотацию в чертеже, и диапазон страниц handbook, подтверждающий требование. При ручной работе за один сеанс я бы такого не сделал — перекрестная проверка всего вручную заняла бы большую часть дня." — Mechanical engineer, precision components manufacturing
Итоговый комплект поставки агента включал полный инженерный отчет, организованный по разделам: подтвержденные хорошие практики, основные пробелы, ссылки на местоположение в чертеже по entity handle, цитаты из handbook по понятию и диапазону страниц, а также рекомендуемые минимальные дополнения перед выпуском. CSV с кандидатами GD&T служил прослеживаемым инвентарем аннотаций, на котором основывалось каждое замечание.
Trust note
Агент прямо обозначает одно важное ограничение: выводы, зависящие от символов GD&T, схем рамок допусков или иллюстраций настроек контроля, требуют визуальной проверки по исходным PDF-иллюстрациям. Журнал чтения и инвентарь понятий позволяют обоснованно интерпретировать требования GD&T, но не заменяют человеческую проверку контента, зависящего от изображений. Инженерные отчеты, подготовленные по этому workflow, следует рассматривать как первичный аудит с полной прослеживаемостью документации — не как окончательное утверждение к выпуску. Квалифицированный специалист по GD&T должен подтвердить выводы, зависящие от символов, прежде чем чертеж будет возвращен инициатору или утвержден к производству.