Проблема: 2 000+ проектировщиков тратят 15–30 минут на поиск ответа в 120+ инструкциях Confluence.
Решение: ИИ-помощник на основе архитектуры RAG, который отвечает за несколько минут.
Результат: время поиска сократилось до 5 минут, адаптация персонала — с 2–4 недель до 3–5 дней.
Привет, Хабр! Меня зовут Максим Курбатов, я — руководитель продукта BIM Inspector в ПИК Digital. Сегодня расскажу, как мы решили одну из непростых задач в BIM-автоматизации — помогли новому пользователю начать работать с системой за дни, а не за недели.
BIM Inspector — это система автоматической проверки модели и конструкторской документации на соответствие BIM-требованиям, стандартам и нормативам. Она встроена в среду проектирования (Revit, AutoCAD) и проверяет модель по мере внесения изменений. Более подробно вы можете ознакомиться с продуктом BIM Inspector и историей его создания в нашей предыдущей статье «Экосистема ПИК. История BIM Inspector».
Как это работает:
Проектировщик работает в Revit.
Система автоматически отслеживает изменения, формирует очередь и выполняет проверку на выделенных фермах.
Результат отображается в программе или веб-интерфейсе.
Проектировщик всегда видит актуальные результаты с перечнем проверок, описанием ошибок, элементами с несоответствиями и ссылками на инструкции по их исправлению.
Исправление ошибок выполняется с помощью инструментов экосистемы BIMTeam.
После исправлений модель проверяется автоматически и при соответствии требованиям переводится в статус «Выпуск».
Когда мы запускали BIM Inspector, у нас была одна цель — упростить проверку моделей. Но чем дольше развивался продукт, тем больше росла база знаний в Confluence. Сегодня она содержит более 120 инструкций по проверкам, а также множество статей о настройках сервиса.
И вот парадокс: система должна упрощать и ускорять работу, но пользователь тратит много времени, чтобы понять, почему модель не прошла проверку и как это исправить.
Так мы поняли: хорошая документация — это не решение, если с ней сложно работать.
Мы задали себе простой вопрос: «А что, если пользователь сможет просто спросить — и сразу получить точный, структурированный ответ?»
Идея родилась из боли: проектировщик не хочет читать инструкции. Он хочет быстро исправить ошибку и продолжить работу. Так появился ИИ-помощник — не как модный тренд, а как инженерное решение проблемы доступа к знаниям. Далее мы подробно расскажем про выбранный подход и технологии.
Мы сознательно отказались от дополнительного обучения LLM — это дорого и долго. Вместо этого мы построили систему на архитектуре генерации с расширением поиска — RAG (Retrieval-Augmented Generation), которая работает с существующей базой знаний.
RAG — это подход, при котором:
Система ищет релевантные фрагменты в базе знаний.
Передаёт их в языковую модель.
Модель генерирует ответ на основе найденного контекста.
Преимущество: не нужно дополнительно обучать модель, достаточно качественно организовать поиск по существующим данным.
Перед тем, как система сможет отвечать на вопросы, документы проходят многоступенчатую обработку.
Система работает с реальными корпоративными данными:
Confluence — централизованная база знаний (120+ инструкций);
Локальные файлы — PDF, DOCX, XLSX, PPTX, Markdown, HTML.
Никакого дополнительного обучения языковой модели! Вся информация берётся из существующих источников.
Документы разбиваются на фрагменты:
Размер чанка: 300 символов;
Перекрытие: 120 символов между соседними чанками.
Зачем? Чтобы сохранить логические утверждения целиком и обеспечить плавный переход между фрагментами.
LaBSE (Language-agnostic BERT Sentence Embedding) — многоязычная модель от Google, которая преобразует предложения на 109 языках в единое векторное пространство.
Технические характеристики:
Размерность вектора: 768 измерений;
Поддерживаемые языки: 109 языков, включая русский и английский;
Максимальная длина текста: 512 токенов.
Как это работает:
Расстояние между векторами = семантическая близость. Фразы «высота этажа» и «floor height» имеют малое косинусное расстояние, несмотря на разные языки.
ChromaDB — хранит векторы для семантического поиска;
NetworkX — графовая БД хранит связи между чанками.
Когда пользователь задаёт вопрос: «Почему модель не проходит проверку FmStatus?», запускается сложный конвейер из пяти этапов.
Система автоматически генерирует синонимы и связанные термины:
Это увеличивает шанс найти релевантные документы.
Одновременно выполняются два типа поиска:
BM25 — классический алгоритм ранжирования документов, разработанный в 1990-х годах. Он оценивает релевантность на основе:
Частота термина (TF) — сколько раз слово встречается в документе;
Обратная частота документа (IDF) — насколько слово уникально;
Длина документа — короткие документы с совпадениями ранжируются выше.
Что добавляет «+» в BM25+?
Проблема нулевых совпадений: добавляет бонус за смежные термины.
Жёсткое ранжирование: более плавное ранжирование за счёт сглаживания.
Игнорирование контекста: учитывает соседние слова и порядок терминов.
Переводит текст в числовое представление (векторы) и находит семантически похожие фрагменты.
Пример: «Актуальность семейств» и «используемые семейства» система считает близкими по смыслу, даже если в документе нет точного совпадения.
Гибридный поиск даёт лучшее из двух миров: семантика + точность.
Комбинирует три сигнала для финального ранжирования:
Cross-encoder — глубокая семантическая оценка.
Метаданные — тип документа, дата обновления.
Термины — точные совпадения ключевых слов.
MMR (Maximal Marginal Relevance) — алгоритм, который балансирует между релевантностью и разнообразием результатов.
Проблема без диверсификации:
С диверсификацией (λ = 0.7):
Система добавляет соседние чанки из графа (NetworkX), чтобы ответ был полным. Это гарантирует, что пользователь получит не только прямой ответ, но и контекст (примеры, исключения, связанные правила).
Отобранные фрагменты передаются в LLM (у нас это DeepSeek-чат). Модель формирует чёткий, структурированный ответ с указанием источников.
Ответ содержит:
объяснение причины ошибки;
пошаговую инструкцию по исправлению;
ссылку на источник.
Система умеет обрабатывать составные вопросы без дополнительных вызовов языковой модели: «Расскажи принцип работы плагина, какие параметры заполнять, как настраивать».
Как это работает:
Автоматически разбивает запрос на части:
принцип работы → концептуальный поиск;
параметры → справочный поиск;
настройка → процедурный поиск.
Применяет специализированные стратегии поиска для каждого типа.
Гарантирует охват всех аспектов (Coverage-aware re-ranking).
Формирует структурированный ответ с заголовками.
«Теперь я не читаю инструкции — я просто спрашиваю», — реальный отзыв проектировщика.
Решение, изначально созданное для BIM Inspector, планируется развернуть как самостоятельный сервис, который будет интегрирован во все продукты экосистемы ПИК.
ИИ-помощник — это не магия, а инженерное решение:
он не заменяет документацию, а делает её живой и интерактивной;
он не требует дополнительного обучения, а использует то, что уже есть;
он понимает контекст, сложные запросы.
Главный принцип: «Пользователь не должен учиться системе — система должна понимать пользователя».
Мы не упрощали продукт — мы упростили доступ к его ценности. ИИ-помощник — это мост между сложной автоматизацией и человеком.
BIMTeam
BIM Inspector
Источник


