Инженер собрал локальный RAG-сервис для документации CAD API на Habr

Инженер опубликовал на Habr разбор того, как собрал локальный RAG-сервис для работы с документацией API систем автоматизированного проектирования (CAD), объяснив это давлением на инженерные компании со стороны заказчиков, которые сокращают бюджеты и сроки проектов.

Почему CAD-документация стала кандидатом на автоматизацию

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

• Автор — инженер, самостоятельно построивший локальный RAG-сервис для CAD API
• Причина проекта — рутинные операции проектирования, которые можно делегировать скриптам
• Общий контекст — сокращение бюджетов и сроков со стороны заказчиков инженерных услуг

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

Что даёт локальный RAG в этом сценарии

RAG (retrieval-augmented generation, генерация с извлечением фактов) — подход, при котором модель перед ответом ищет релевантные фрагменты в собственной базе документов, а не полагается только на то, что запомнила при обучении. Для документации CAD API это особенно уместно: такие API часто описаны в объёмных, разрозненных и регулярно обновляемых мануалах, а локальное развёртывание позволяет держать чувствительные инженерные данные и проприетарную документацию внутри контура компании, не отправляя их во внешние облачные сервисы.

Именно поэтому автор пошёл по пути локального решения, а не готового облачного AI-ассистента: для инженерных данных вопрос конфиденциальности часто важнее удобства настройки, а обращение к актуальной версии API-документации критично, поскольку CAD-системы регулярно меняют интерфейсы и методы. Развёртывание "у себя", без передачи запросов во внешний сервис, снимает и вопрос о том, куда утекают формулировки внутренних технических заданий и фрагменты закрытой документации вендора.

Какие сложности обычно возникают у таких проектов

Техническая документация API — неудобный материал для классического RAG-пайплайна: в ней много таблиц с параметрами, ссылок на другие разделы, версионных пометок и специфичной терминологии конкретной CAD-платформы, которая плохо разбивается на чанки стандартными способами. Разработчикам подобных сервисов обычно приходится отдельно продумывать разбиение документов на смысловые куски, обновление индекса при выходе новой версии API и проверку того, что модель не путает похожие по названию, но разные по поведению методы. Это ручная, кропотливая работа, которая обычно не видна в финальном результате, но занимает значительную часть времени такого проекта.

Что это значит

История отражает более широкий тренд: пока крупные вендоры выпускают универсальных AI-ассистентов, отдельные инженеры и небольшие команды всё чаще собирают узкоспециализированные локальные RAG-инструменты под конкретную рутину — работу с документацией, шаблонными операциями и внутренними стандартами. Для инженерных и проектных организаций, где важны конфиденциальность чертежей и точное соответствие версии API, такой самодельный локальный инструмент зачастую оказывается практичнее, чем подключение внешнего облачного AI-сервиса ко всей базе документации компании.