CDC Core. Как научить компьютер разбирать строительную документацию

Андрей Леонов

CDC Core. Как научить компьютер разбирать строительную документацию

CDC Core. Как научить компьютер разбирать строительную документацию

История проекта, боли, решения и технологии — без единой строчки кода

Исходный код проекта: https://github.com/AndreyLeonov80/cdc-core

Telegram: https://t.me/aidialog

GitHub: https://github.com/AndreyLeonov80/about

E-mail: [e-mail]

© 2026 Автор кода CDC Core. Все права защищены.

Содержание

Введение. Зачем эта книга

Глава 1. Боль первая: хаос строительной документации

Глава 2. Боль вторая: ручная работа с кодами и ревизиями

Глава 3. Боль третья: система, которую нельзя развивать

Глава 4. Как создавался CDC Core

Глава 5. Что делает система: конвейер из девяти этапов

Глава 6. Технологии: почему именно они

Глава 7. Кому и сколько это экономит

Глава 8. Безопасность и честная коммерция

Глава 9. Запуск и повседневная работа

Глава 10. Куда расти: дорожная карта

Об авторе

Глава 11. Типовые ошибки ручной классификации: пять кейсов

Глава 12. Глоссарий

Глава 13. Частые вопросы

Глава 14. Почему конвейер устроен именно так

Глава 15. Чек-лист внедрения за неделю

Глава 16. Заключение

Глава 17. Анатомия проектного архива

Глава 18. Экономика ручной обработки

Глава 19. Оператор: профессия, которую меняет машина

Глава 20. Как нейросети читают страницу

Глава 21. Русский язык глазами машины

Глава 22. Математика похожести

Глава 23. Базы данных и интерфейсы для не-программистов

Глава 24. Контейнеры и автопроверки

Глава 25. Как измерять качество классификации

Глава 26. Сопротивление внедрению и как его пройти

Глава 27. Право, лицензии и чужие документы

Приложение А. Паспорт файла: что система помнит о документе

Приложение Б. Настройки окружения

Послесловие

Введение. Зачем эта книга

Эта книга — история одного практического проекта и одновременно инструкция по мышлению. Ее герой — CDC Core, система автоматической классификации строительной проектной документации. Каждый день проектные организации выпускают сотни чертежей, пояснительных записок, спецификаций и смет. Каждый документ нужно распознать, понять, к какому комплекту он относится, определить его ревизию и положить в правильную папку. Вручную эта работа занимает часы и дни, а ошибка стоит дорого: документ, попавший не в тот комплект, может задержать стройку или привести к переделкам.

CDC Core берет эту рутину на себя. Система принимает сканы и текстовые выгрузки, распознает текст на русском языке, определяет код комплекта чертежей, выстраивает иерархию раздел — подраздел — часть — книга — том, фиксирует ревизию документа и раскладывает файлы по папкам. Результат сохраняется в базу данных и сводный отчет, с которыми работает человек-оператор через веб-интерфейс.

Книга написана без единой строчки исходного кода. Все технические решения объяснены словами: что делает каждый этап, зачем он нужен и какие задачи решает. Полный исходный код проекта открыт и доступен по ссылке: https://github.com/AndreyLeonov80/cdc-core. Книга — это карта, код — территория. Читайте карту, а за деталями реализации заглядывайте в репозиторий.

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

Глава 1. Боль первая: хаос строительной документации

Строительный проект — это тысячи документов. Генеральный план, архитектурные решения, железобетонные конструкции, отопление и вентиляция, водоснабжение, электрика, технология производства, сметы, пояснительные записки. Каждый комплект чертежей имеет свой буквенный код: ГТ, АР, КЖ, ЭОМ, ОВ, ВК и десятки других. Внутри комплекта — разделы, подразделы, части, книги, тома. Отдельная ось — стадии строительства и ревизии: документ живет, меняется, и каждая его версия должна лежать на своем месте.

На практике документы приходят в самом разном виде. Сканы разного качества, фотографии с телефона, выгрузки из разных систем, файлы с именами вроде «скан_023_финал_2». Один и тот же чертеж может существовать в пяти копиях с разными именами в разных папках. Сотрудник открывает файл, вчитывается в штамп, определяет код комплекта, сверяется со структурой проекта, переименовывает файл и переносит его в нужную папку. На один документ уходят минуты. На тысячу — недели.

Цена ошибки высока. Чертеж, попавший в чужой комплект, не найдут, когда он понадобится. Устаревшая ревизия, выданная в работу вместо новой, превращается в переделки на площадке. Потерянный документ приходится запрашивать заново. Хаос в документации — это не абстрактное неудобство, а прямые финансовые потери и срывы сроков.

Первая боль, которую решает CDC Core, — это именно хаос на входе. Система не требует, чтобы файлы были аккуратно названы или разложены. Она принимает то, что есть: гору сканов и текстовых файлов — и сама разбирает, что есть что. Вместо недель ручной сортировки — автоматический прогон, после которого человек проверяет результат, а не выполняет его с нуля.

Глава 2. Боль вторая: ручная работа с кодами и ревизиями

Даже когда документы более-менее упорядочены, остается тонкая ручная работа: определить код комплекта и ревизию. Код комплекта — это короткий шифр из букв и цифр, который нужно найти в тексте документа. Он может стоять в штампе, в колонтитуле, в названии файла или прятаться среди десятков других обозначений. Человек учится видеть его с опытом, но каждый новый проект приносит новые форматы.

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

Есть и ловушки, в которые попадает даже внимательный человек. Дата в тексте похожа на код документа: набор цифр с точками и дефисами. Номер страницы похож на ревизию. Служебные пометки — «Раздел», «Книга», «Часть» — сбивают с толку при поиске. Правила, отличающие настоящий код от похожего мусора, приходится держать в голове и применять к каждой строке.

Вторая боль, которую снимает CDC Core, — это автоматическое извлечение кодов и ревизий по формальным правилам. Система проверяет каждую строку текста набором эвристик: достаточно ли в ней цифр, нет ли признаков даты, нет ли служебных слов, есть ли характерные символы. Кандидаты, прошедшие фильтр, сравниваются со справочником нечетким поиском, который прощает опечатки распознавания. Человеку остается контрольная функция: подтвердить или поправить, а не выискивать.

Глава 3. Боль третья: система, которую нельзя развивать

Третья боль менее заметна, но со временем становится главной. Первый рабочий прототип системы обработки документов обычно рождается как один большой файл: все подряд — веб-сервер, база данных, распознавание, поиск, отчеты. Пока задач мало, это удобно: все под рукой, все работает. Но проект растет. Добавляется новый тип документов — приходится лезть в середину файла и бояться что-нибудь сломать. Нужно изменить одну эвристику — непонятно, на что еще она влияет. Новый разработчик открывает файл на несколько тысяч строк и тонет.

Монолит тянет за собой и другие проблемы. Настройки захардкожены: адреса, пути к папкам, порты разбросаны по коду. Пароли и ключи лежат рядом с логикой. Запуск зависит от конкретной машины разработчика: на другом компьютере система не стартует, потому что ждет папку, которая есть только на первом. Тестов нет, потому что тестировать клубок взаимосвязанного кода почти невозможно. Каждое изменение — риск, каждый релиз — стресс.

Рано или поздно наступает момент, когда развивать систему дороже, чем переписать ее. Именно этот путь прошел CDC Core: первая версия была монолитом в одном файле на несколько тысяч строк, а зрелая версия — аккуратным пакетом из небольших модулей, где у каждого своя ответственность. Переход не был cosmetic: изменились имена, структура, способ хранения настроек, подход к ошибкам. Зато результатом стала система, которую можно тестировать, документировать и развивать по частям.

Третья боль, которую закрывает проект, — это боль роста. CDC Core спроектирован так, чтобы новый тип документов, новый алгоритм сравнения или новый отчет добавлялись как отдельный модуль, а не как правка в середине гигантского файла. Эта книга в том числе и об этом: как принимать архитектурные решения, которые не мешают будущему.

Глава 4. Как создавался

CDC

Core

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

Второй этап — извлечение смысла. Распознанный текст сам по себе бесполезен, если из него нельзя достать код комплекта, ревизию и стадию. Появились правила поиска кодов, справочники комплектов и объектов, нечеткое сравнение для прощения ошибок распознавания. Система научилась отличать настоящий код от даты, номера страницы и служебных пометок.

Третий этап — иерархия. Документу мало иметь код: нужно понять его место в структуре проекта. Появились разбор дерева разделов, поиск по иерархическому справочнику и sidecar-файлы — маленькие паспорта, которые хранятся рядом с каждым текстовым файлом и помнят все, что система о нем узнала: ревизию, стадию, объект, коды разделов.