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


