Отказ от абстракций и проверка моделей на практике / Хабр


Попытки интеграции больших языковых моделей с инженерным ПО часто сталкиваются с реальными трудностями.

Системы, такие как T-FLEX CAD, оперируют через закрытые DLL-библиотеки, требуют строгого контроля сессий и точно заданных методов API. В этих условиях нейросети могут «галлюцинировать», создавая код, который выглядит корректно на первый взгляд, но приводит к сбоям или блокировке лицензий. Ошибки в типах данных или неверные предположения в САПР недопустимы.

Для автоматизации настоящих инженерных задач и получения стабильных результатов нам пришлось отойти от привычных форматов чат-ботов. Мы разработали tflex_harness, где агент состоит из языковой модели, системы управления, локального поиска по API-документации, генерации C#-кода, компиляции и контролируемого выполнения в T-FLEX CAD.

Разделение зон ответственности

При интеграции с САПР существует искушение использовать удобные обертки на Python (например, part.add_hole()). На практике это может быстро привести к проблемам: в случае сбоя нейросеть начинает исправлять ошибки в обертках, теряя из виду основную инженерную задачу.

Мы выбрали другой путь, разделив зоны ответственности. Python остался в рамках управления: он принимает задания, ищет информацию в локальной документации API, подготавливает рабочую папку и собирает результаты. Взаимодействие с ядром T-FLEX CAD происходит через сгенерированный исходный C#-код, который компилируется вместе с необходимыми классами и библиотеками. Жесткая разделенность логики обеспечивает безопасность: Python лишь управляет процессом, а взаимодействие с САПР выполняется исключительно на чистом C#.

Python маршрутизирует процессы: принимает конфигурационные файлы, находит данные в документации API и собирает результаты. Все обращения к T-FLEX происходят через генерацию открытого C#-кода, который компилируется с использованием нативных библиотек САПР.


Проверка компилятором перед запуском

Языковые модели могут создавать несуществующие методы. Модель может уверенно предложить вызов, такой как ExportToStep(), даже если такой метод отсутствует в текущей версии API. Поэтому такой код не следует отправлять непосредственно в сессию САПР; его необходимо проверить на уровне компиляции.

Поэтому мы внедрили промежуточный этап обязательной компиляции.

Система сначала ищет точные названия методов в локальном API-справочнике и формирует черновик программы. Затем сгенерированный код передается штатному компилятору csc.exe без запуска T-FLEX CAD. Это позволяет устранить многие ошибки: несуществующие методы, несоответствие типов, неверные пространства имен и сигнатуры вызовов.

Как мы обучили нейросеть API-справочнику

Одной из главных проблем при работе с энтерпрайз-САПР является формат документации. API-справочник T-FLEX поставляется в виде компилированного файла .chm на 17 МБ и набора сырых .xml файлов с метаданными.

Загружать мегабайты неструктурированного XML в контекст языковой модели — плохая идея. Модель может «съесть» большое количество токенов, потерять контекст и продолжить генерировать несуществующие методы.

Мы избрали другой подход: написали парсер, который берет TFlexAPI.xml и разбивает его на тысячи атомарных Markdown-файлов (.md). Каждый файл описывает строго один класс, интерфейс или метод.


Как это работает в динамике:

  1. Алгоритм осуществляет поиск по локальной базе .md файлов и находит только те классы, которые необходимы для решения текущей задачи.

  2. В контекст (промпт) нейросети отправляется не весь справочник, а лишь краткая и актуальная информация в удобном для ИИ формате Markdown.

Для реализации этого этапа мы рекомендуем использовать deepwiki из нашего репозитория t-flex_api (ссылка указана в конце статьи); это дает лучшие результаты при поиске связей между методами. Однако для базового варианта подойдет также простой текстовый поиск по .md файлам. Получая контекст в таком формате, модель перестает «фантазировать» и опирается лишь на четко заданную спецификацию.

Открытые инструменты и самопроверка алгоритма

Разрабатывать с нуля шаблонный код для подключения к документам или настройки экспорта долго и неэффективно. Мы подготовили базовый набор вспомогательных классов на C#. Главное их отличие заключается в том, что это не скрытые компилированные библиотеки, а обычные текстовые файлы (например, EasySession.cs), которые копируются в рабочую папку и компилируются вместе с кодом, созданным алгоритмом.

Нейросеть имеет доступ к этим файлам, использует их функции и самостоятельно формирует логику для проверки своей работы. На следующем фрагменте кода алгоритм создает параметрический кронштейн.

      
      var endSubtract = doc.EndChanges();
      EasyDiagnostics.Print("subtract.endChanges", endSubtract);
      if (endSubtract.ToString() != "OK") return 30; // Жесткий выход при ошибке построения

      var box = EasyDiagnostics.PrintBodyBoxMm("final", finalBracket);
      int operations = Document3D.GetOperations(doc).Count;

      string outPath = sess.ArtifactPath("symmetric_clevis_bracket.grb");
      bool saved = EasyExport.Grb(doc, outPath);

      // Проверяем ключевые контрольные размеры модели
      if (!box.Valid) return 40;
      if (!Near(box.SpanX, 140.0, 0.5) || !Near(box.SpanY, 86.0, 0.5)) return 41;
      if (operations < 0) return 42;

Алгоритм запрашивает у системы размеры контейнера модели, измеряет параметры по осям, подсчитывает количество операций в дереве построений и только после успешного прохождения всех проверок программа возвращает код завершения (проверки можно добавлять или изменять по желанию).

Фиксация результатов вместо переписки

Для каждой попытки создаётся отдельная директория, где сохраняются исходное задание, сгенерированный код, логи компиляции, консольный вывод, код завершения и готовые артефакты.

/artifacts/runs/20260529_120000_clevis_bracket/
 ├── request.json       # Исходное техническое задание
 ├── snippet.cs         # Сгенерированный алгоритмом код
 ├── helpers/           # Скопированные вспомогательные классы
 ├── build.log          # Подтверждение успешной компиляции
 ├── stdout.txt         # Консольный вывод и измерения
 ├── result.json        # Код завершения
 └── artifacts/
      └── symmetric_clevis_bracket.grb  # Готовая 3D-модель

Если сгенерированный код успешно скомпилирован, выполнен в T-FLEX CAD и прошёл встроенные проверки, его можно сохранить как проверенный «рецепт» и переиспользовать в C#-сценарии для аналогичных задач.

Автоматизация рутины, а не замена инженера

Проверенные рецепты переводят сценарий из эксперимента в режим пакетной обработки. На вход можно подать таблицу Excel или JSON с параметрами, а результатом будет набор файлов .grb/.step, сводный CSV-отчет или извлечённые атрибуты моделей.


Мы разработали данный подход для T-FLEX CAD, но сам принцип является универсальным. Искусственный интеллект пока не может полностью заменить инженера-конструктора или создать сложное изделие с нуля, и мы не обещаем этого.

Тем не менее, этот подход эффективно работает для точечной автоматизации рутинных задач. Массовое перестроение типовых моделей, выгрузка атрибутов и проверка спецификаций - это процессы, на которые специалисты тратят значительное количество часов рабочего времени.

Для таких задач стандартные языковые модели в виде чат-ботов не подходят. Здесь требуется глубокая интеграция на уровне API и строгий контроль процесса, что применимо к любой корпоративной системе с открытым API (будь то T-FLEX, Компас-3D, SolidWorks или системы документооборота).

Репозитории:

t-flex harness: https://github.com/dwnmf/tflex_harness *любая обратная связь и PR приветствуются

t-flex api: https://github.com/dwnmf/tflex_api

https://deepwiki.com/dwnmf/tflex_api

Если у вас есть повторяемые инженерные или расчётные процессы, которые занимают слишком много времени, напишите нам: vanamasorub@gmail.com.

ОСТАВЬТЕ ОТВЕТ

Пожалуйста, введите ваш комментарий!
пожалуйста, введите ваше имя здесь

Основатель более 10 стартапов в области ИТ и ИИ. Серийный предприниматель. Профессиональный управленец.