ИИ-агент внутри T-FLEX CAD: как заставить нейросеть не врать, а чертить

Почему инженер ненавидит нейросети (и прав)

Представьте: вы загрузили в ИИ-агента задачу — "спроектировать кронштейн под нагрузку 500 Н". Через минуту он выдаёт C# скрипт, T-FLEX CAD запускает макрос, и на экране появляется... трёхмерная свалка. Грани не сходятся, отверстия в воздухе, радиусы отрицательные. ИИ уверен, что всё правильно. Вы в бешенстве.

Это не гипотетика. Я перепробовал кучу подходов — от прямой генерации g-кода через Python-обёртки до вызова LLM внутри макроса T-FLEX. Везде одно и то же: нейросеть галлюцинирует размеры, игнорирует допуски и уводит модель в небытие. Проблема не в том, что LLM плохие — проблема в том, что мы даём им слишком много власти.

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

Схема «контролируемый хаос»

Вот типичная ошибка, которую я вижу в 9 из 10 интеграций: берут Python-скрипт, который вызывает T-FLEX COM-объекты, и засовывают внутрь LLM-промпт. ИИ прямо генерирует вызовы API — мол, SetRadius(10). Результат: каждый второй запрос ломает сессию, потому что нейросеть передаёт невалидные параметры или пытается вызвать несуществующие методы.

Вместо этого я предлагаю трёхзвенную архитектуру:

• AI Core — нейросеть (любая, я использую Claude 4 и GPT-4.5). Получает текстовое описание задачи + контекст из базы деталей. Генерирует только C#-код для T-FLEX CAD.
• Sandbox Executor — минимальный C#-проект, который компилирует код на лету, запускает в отдельном AppDomain и возвращает результат (успех/ошибку + лог).
• Validation Gateway — проверяет получившуюся модель: валидность топологии, размеры, габариты, области пересечения. Если что-то не так — кидает исключение обратно в AI Core для регенерации.

Зачем нам Python-обёртка? Низачем. Вся логика на C# — родном языке T-FLEX CAD. Python мы используем только как glue для вызова LLM (если очень хочется — но можно и напрямую через REST). Я предпочитаю C#-агент, который ходит в OpenAI/Anthropic API через HttpClient. Меньше точек отказа.

1 Песочница для макросов

Берём стандартный шаблон T-FLEX CAD для макросов. Создаём сборку, которая принимает на вход строку с C#-кодом, компилирует её через Roslyn (Microsoft.CodeAnalysis.CSharp) и выполняет в изолированном домене. Собираем все исключения, время выполнения, предупреждения компилятора.

using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.CSharp;
using System.Reflection;

public class MacroSandbox
{
    public static (bool Success, string Log) Run(string code)
    {
        var options = CSharpParseOptions.Default.WithKind(SourceCodeKind.Script);
        var script = CSharpScript.Create(code, options, globalsType: typeof(Globals));
        // ... компиляция, запуск с таймаутом, перехват исключений
        return (true, log);
    }
}

2 Валидация через API T-FLEX

После того как макрос создал/изменил 3D-модель, запускается цепочка проверок. В T-FLEX CAD есть интерфейсы для чтения геометрии — ITFPart, ITFBody. Мы пробегаем по всем твёрдым телам и проверяем:

• Минимальная толщина — не менее 2 мм (параметр из конфига).
• Отсутствие нулевых рёбер — если длина ребра < 0.01 мм, модель считается невалидной.
• Замкнутость контуров — для каждого эскиза проверяем, нет ли разрывов.
• Не пересекается ли с запретными объёмами — если указана зона «ничего не должно торчать», проверяем через булевы операции.

public bool Validate(TFPart part)
{
    foreach (var body in part.Bodies)
    {
        if (body.MinThickness < 2.0) return false;
        foreach (var edge in body.Edges)
            if (edge.Length < 0.01) return false;
    }
    return true;
}

Критический момент: валидация должна быть детерминированной. Никакой вероятностной логики. Иначе ИИ-агент не сможет понять, почему его код забраковали. Вся метрика и пороги — жёстко в конфиге.

Разделение ответственности: кто за что отвечает?

В книжках по DevOps любят говорить про separation of concerns. В нашей архитектуре это выглядит так:

Такая схема даёт прозрачность. Если конечная модель бракованная — мы точно знаем, кто виноват: либо LLM написала неправильный код, либо валидатор пропустил дефект, либо песочница неверно выполнила. Никаких «нейросеть намудрила». Есть логи, есть трейсы.

Кстати, похожий подход к разделению зон ответственности мы обсуждали в статье «Кто ответит, когда AI-агент сломает ваш бизнес?» — рекомендую, если планируете внедрять нечто подобное в промышленную эксплуатацию.

Самопроверка: нейросеть проверяет сама себя (но не в одиночку)

Главный страх: LLM нагенерирует код, который выглядит красиво, но делает ерунду. Исследования показывают, что современные модели (даже GPT-4.5, Claude 4) в ~15% случаев выдают галлюцинации в CAD-задачах. Как с этим бороться?

Есть трюк: после того как код сгенерирован, мы даём LLM прочитать его же и попросить проверить на наличие типовых ошибок. Но не доверяем этому на 100% — результат проверки идёт как дополнительный вход в валидатор. Если нейросеть говорит «всё ок», а валидатор ругается — приоритет у валидатора.

Более того, можно включить сравнение с идеальным решением, если оно есть. Например, если в базе есть эталонный чертёж похожей детали — мы прогоняем макрос через diff геометрии. В T-FLEX CAD это можно сделать через COM-интерфейс ITFModel.CompareTo.

public double CompareWithEtalon(TFPart generated, TFPart etalon)
{
    var diff = generated.Model.CompareTo(etalon.Model, ComparisonMode.Geometry);
    return diff.Similarity; // 0..1
}

Пороговое значение — 0.95. Если сходство ниже — откат и перегенерация с указанием расхождений. Это даёт замкнутый контур: нейросеть учится на своих ошибках, но не за счёт дообучения, а за счёт того, что промпт следующей итерации включает diff.

А как же галлюцинации? (спойлер: никак, но мы их ловим)

Полностью убрать галлюцинации LLM невозможно. Это не баг, а фича вероятностной генерации. Но мы можем сделать так, чтобы они не наносили ущерба.

• Ограничение пространства имён. В промпте жёстко запрещаем обращаться к System.IO, System.Net — только T-FLEX API.
• Статический анализатор. Перед компиляцией прогоняем код через Roslyn Analyzer с правилами безопасности (например, запрет на бесконечные циклы).
• Обязательный catch-all. Весь код макроса оборачивается в try-catch, и любое исключение возвращается в Orchestrator как ошибка с текстом.
• Лимит попыток (3–5). Если после N итераций валидация не пройдена — задача маркируется как «невыполнимая» и отправляется человеку.

Эти меры описаны в системной инструкции для агента. Я взял за основу методику из Agent Skills — там хорошо показано, как фиксировать инструкции, чтобы нейросеть не забывала их через пару сообщений.

Как это выглядит на практике (пошагово)

Допустим, типовой сценарий: нужно создать фланец с 8 отверстиями под болты M10. ТЗ: внешний диаметр 120 мм, внутренний 60 мм, толщина 15 мм.

1. Инженер пишет задание в формате YAML: type: flange, outer: 120, inner: 60, thickness: 15, holes: 8, thread: M10.
2. Orchestrator дополняет контекст актуальными допусками (например, EQS для отверстий — 0.1 мм) и отправляет в LLM.
3. LLM возвращает C#-код с использованием TFFlangeBuilder и TFHolePattern. Sandbox компилирует — успешно.
4. Validator проверяет: все 8 отверстий присутствуют, диаметр 120, толщина 15, нет самопересечений. Проходит.
5. Результат — файл T-FLEX (.grb).

Если на шаге 4 валидация не пройдена (например, вместо 8 отверстий — 7), Orchestrator отправляет LLM сообщение: Validation failed: expected 8 holes, got 7. Re-generate. И так до 3 раз.

Типовые грабли (и как их обойти)

Начну с главной: не пишите обёртки на Python, если у вас вся CAD-инфраструктура на .NET. В теории Python удобен для прототипирования, но на практике вы получаете зоопарк зависимостей и тормоза при вызове COM. Я потратил месяц, переписывая всё на C# — и скорость работы выросла в 5 раз. Никакой магии, просто меньше накладных расходов на маршаллинг.

Вторая грабля: не зашивайте промпты в код. LLM-инструкции должны лежать в отдельном файле (Git-репозитории) и проходить review как обычный код. Иначе вы не заметите, как промпт устарел или в него закралась логическая ошибка. Я видел, как одна строчка «проверять все размеры с точностью 0.01» выключила валидацию для крупных деталей (там точность ±0.5 — норма).

Третья: не держите историю сессии бесконечной. LLM-агенты склонны накапливать контекст и «забывать» первые указания. Организуйте ротацию: каждые 10 сообщений сбрасывайте историю до последнего «важного» TЗ. Механизм описан в статье про Agent Skills — там же пример кода.

Что в итоге? (без заключения, просто мысль)

Спустя полгода эксплуатации такой связки могу сказать: ИИ-агент живёт в T-FLEX CAD как рядовой стажёр — делает много, но под присмотром. Галлюцинации снизились с ~20% до ~3% (и это в основном на экзотических задачах). Валидатор отлавливает 100% ошибок, которые критичны для производства. Контур самопроверки не даёт агенту зацикливаться на неверных решениях.

Если ваша компания работает под регуляторикой ФСТЭК (КИИ, госорганы), обратите внимание на статью «ИИ-комплаенс в РФ: ФСТЭК 117 и Указ 490» — там описаны требования к логированию и сертификации таких систем. У нас аудиторы приняли архитектуру именно благодаря чёткому разделению ответственности.

И последнее: не бойтесь, что нейросеть заменит инженеров. Она заменит только рутину. А вот испортить деталь, если дать ей волю — может. Наша задача — построить клетку, внутри которой ИИ полезен, но не опасен.

Подписаться на канал