Проблема: Галлюцинации в инженерных расчетах

Я занимаюсь расчетами строительных конструкций в комплексе SOFiSTiK. Основной инструмент взаимодействия с ним — внутренний язык CADINP. Это мощный, но старый процедурный язык с жестким синтаксисом: строгая последовательность модулей (AQUA -> SOFIMSHC -> ASE), специфичные команды фиксации узлов и неявные зависимости.

SOTA-модели (ChatGPT-4o, Claude 3.5 Sonnet) справляются с CADINP посредственно. Основные проблемы при генерации кода general-purpose моделями:

1. Синтаксический шум: Выдумывание несуществующих аргументов функций.

2. Потеря контекста: Забывают объявить материалы перед их использованием.

3. Ошибки физики: Игнорирование степеней свободы (например, отсутствие фиксации кручения для 3D-стержней), что приводит к сингулярности матрицы жесткости.

Имея на руках рабочую станцию с NVIDIA RTX 3090 (24 GB), я поставил задачу: дообучить (fine-tune) небольшую открытую LLM, которая понимала бы специфику инженерной логики лучше, чем гиганты от OpenAI.

Стек и железо

• GPU: GeForce RTX 3090 (24 GB VRAM).

• OS: Windows 11 + WSL2 (Ubuntu).

• Фреймворк: Unsloth (для оптимизации памяти и скорости).

• Базовая модель: Qwen 2.5 / Qwen 3 (экспериментировал с размерами 7B, 14B, 8B).

Подготовка данных: Chain of Thought

Просто "скармливать" модели мануалы оказалось неэффективным. Модель учила определения, но не логику построения скрипта.
Я собрал датасет из 3500+ пар «Инструкция — Решение», используя подход Chain of Thought (CoT).

Вместо прямой генерации кода я заставил модель сначала формировать блок рассуждений <think>. Это критически важно для инженерных задач.

Пример структуры jsonl (переведено на русский язык для наглядности):

{
  "messages": [
    {"role": "user", "content": "Смоделируй бетонную балку 6м..."},
    {"role": "assistant", "content": "<think>Задача на статику. Нужно определить материал в AQUA, затем геометрию. Внимание: балка в пространстве, необходимо закрепить поворот вокруг оси X.</think>\n+PROG AQUA..."}
  ]
}

Разметка и валидация датасета производилась полуавтоматически с помощью скриптов на Python.

Процесс обучения и борьба с VRAM

Основным вызовом стало ограничение памяти. 24 ГБ VRAM — это пограничное значение для полноценного файнтюнинга даже квантованных моделей, если требуется длинный контекст.

Попытка 1: 14B-модель.
При контексте max_seq_length = 4096 (необходимо для длинных скриптов) я столкнулся с OOM (Out Of Memory). Оверхед WSL и системы съедал около 2-3 ГБ, и батч даже в 1 единицу не влезал.

Попытка 2: 7B-модель (Overfitting).
Обучение на 6 эпох привело к деградации модели. Loss упал до 0.02, модель начала выдавать мусорные токены и перешла на китайский язык (особенность базы Qwen).

Финальная конфигурация:
Я остановился на архитектуре 8B (Qwen 3) с дистилляцией логики DeepSeek.

Гиперпараметры, которые дали стабильный результат:

• LoRA Rank/Alpha: 32 / 64 (Агрессивное обучение для лучшего запоминания синтаксиса).

• Epochs: 3 (Оптимум для предотвращения оверфиттинга на датасете в 3.5к записей).

• Learning Rate: 2e-4 с косинусным планировщиком.

• Gradient Accumulation: 8.

  • Важный нюанс: Так как физический Batch Size на карте был равен 2, накопление градиента (8 шагов) позволило эмулировать эффективный батч = 16. Это сгладило кривую обучения и сделало модель более "вдумчивой".

Результаты

Модель была квантована в GGUF (q8_0) для инференса через LM Studio.

На тестовых задачах модель демонстрирует способность к самокоррекции через блок <think>.
Пример (сокращенно):

Запрос: Задай нагрузку на балку.
Мысль модели: ...Нагрузка должна быть приложена к структурной линии. Проверяю направление: ось Z смотрит вниз, значит нагрузка положительная.
Код: LINE SLN 1 TYPE PZZ P1 15.0

Модель корректно расставляет FIX PPMX (фиксация кручения) и соблюдает иерархию модулей. Ошибки случаются (примерно в 10-15% случаев), чаще всего связаны с модулем SOFIMSHA и SOFIMSHC, ответственные за генерацию сетки конечных элементов.

Заключение и планы

На данный момент получился специализированный локальный Copilot, который в узкой доменной области CADINP работает точнее, чем универсальные модели. Проект полностью некоммерческий и открытый (Open Weights).

Где взять:
Модель опубликована на Hugging Face. Там же, в карточке модели (README), я собрал всю необходимую информацию:

• Ссылку на скачивание GGUF (q8_0).

• Инструкцию по запуску через LM Studio.

• Контакты для обратной связи (Телеграм, Discussions) — для тех, кто готов помочь с тестированием.

Планы на v2:
Сейчас я собираю «Red Team» из инженеров для поиска edge-cases — сценариев, где модель ошибается. Если вам интересна тема применения локальных LLM в проектировании, буду рад вашим баг-репортам. Ссылки на каналы связи ищите в описании модели.

Репозиторий проекта:
ссылка