2️⃣Слой 2. Нормализация входящих данных.
Здесь начинается самое интересное. Потому что вечная истина никуда не делась:
мусор на входе = мусор на выходе.
Проектная документация вообще довольно мерзкий источник данных для машинной обработки.🤮 Рамки, штампы, колонтитулы, таблицы, сноски, перечни, схемы, картинки, графики, обозначения, номера листов, ссылки между разделами, сканы внутри PDF, таблицы внутри текста и ещё куча всего. И просто засунуть PDF на 500 страниц в LLM, далеко не лучший способ работы.
Поэтому перед моделью появляется отдельный пайплайн подготовки документации.
Он должен понять:
🟥Где структура документа
🟥Где разделы и подразделы
🟥Где основной текст
🟥Где таблицы
🟥Где изображения и схемы
🟥Где служебное оформление
🟥Где ссылки на другие части документа
🟥Что относится к конкретному листу или странице
Причём важный момент: ненужное не всегда надо просто выбрасывать.
Например, координаты объекта на странице, номер листа, номер таблицы или связь фрагмента текста с конкретным чертежом могут вообще не понадобиться LLM для ответа, но понадобятся нам потом, чтобы сказать инженеру:
«Вот здесь проблема. Лист 17, таблица 4, строка 6».
Поэтому правильнее говорить не просто о переводе PDF в Markdown, а о формировании некоторого нормализованного представления ПД, из которого уже можно отдавать модели текст, таблицы, изображения и необходимые метаданные в удобном виде.
Вот после этого качество начинает расти уже довольно заметно.
Потому что LLM получает не помойку из PDF, а подготовленные данные. И опять же, требования к пользователю уменьшаются.
Он просто загрузил документацию. Всё остальное сделал пайплайн.
3️⃣Слой 3. Формализация самой проверки.
Вот этого слоя обычно как раз не хватает в подходе «давайте сделаем хороший промт».
ПП87 это не просто текст, который надо дать почитать LLM. Это набор требований, причём часть требований применима к одному типу объектов, часть к другому, какие-то зависят от параметров проекта, какие-то требуют наличия определённых разделов, данных или обоснований.
Поэтому постепенно сам норматив тоже надо превращать в машинно-читаемую структуру.
Условно:
Из требования формируется условия применимости, далее, что необходимо найти, где это обычно находится, критерий проверки и финализируем источником требований.
И тогда LLM уже не получает абстрактную задачу: «Проверь документацию на соответствие ПП87».
Она получает сто конкретных маленьких задач. Например:
🟥Применимо ли требование
🟥Есть ли необходимая информация
🟥Где она находится
🟥Соответствует ли найденное значение требованию
🟥Достаточно ли данных для вывода
🟥Если нет, что именно отсутствует
Не забываем то, что можно проверить обычным кодом, вообще не надо отдавать LLM!
LLM оставляем там, где требуется работа со смыслом, неоднозначным текстом, классификацией, извлечением или сопоставлением. Это очень важный принцип.
В результате получаем не огромный промт, а управляемый конвейер проверок.
На этом слое начинается переход от забавной ИИ-утилиты к нормальному корпоративному сервису.
4️⃣Слой 4. ПД превращается в базу знаний.
А вот здесь мы уже начинаем строить ядро, которое выходит далеко за пределы одного ПП87.
Потому что после того, как мы научились качественно разбирать ПД, становится довольно глупо каждый раз заново скармливать её модели целиком. Мы превращаем документацию в индексируемую базу знаний. Здесь появляются:
🟥Структурный индекс документа
🟥Полнотекстовый поиск
🟥Семантический поиск
🟥Векторный индекс
🟥Метаданные
🟥Связи с листами, разделами и таблицами
🟥Дополнительный отбор наиболее релевантных результатов
🟥Непосредственно ядро поиска и сборки контекста для LLM
И отдельно обращу внимание: одной векторной базы здесь мало, чистый RAG редко работает нормально.
В инженерной документации огромное количество точных значений:
марки оборудования, номера помещений, обозначения систем, ссылки на СП, диаметры, классы, номера листов, позиции, шифры, GUID и т. п.
Если мне надо найти условный насос Н-17, я не хочу, чтобы система нашла мне «семантически похожий насос» Мне нужен именно Н-17.
Поэтому хороший инженерный поиск почти неизбежно становится гибридным.
🟥Где-то ищем по смыслу
🟥Где-то по точному совпадению
🟥Где-то по структуре документа
🟥Где-то по типу сущности
🟥Где-то одновременно по всему этому
А уже потом отдаём найденный контекст LLM.
Теперь у LLM есть внешний механизм поиска, который сначала находит нужные данные в ПД, а уже потом передаёт их модели для анализа.
И очень важно: каждый вывод должен сохранять связь с первоисточником.
Не просто: «Требование не выполнено», а «Требование не выполнено. Основание: пункт такой-то. Проверены такие-то разделы. На странице такой-то обнаружено это. Требуемая информация не найдена».
Вот после этого системой уже можно начинать серьёзно пользоваться.
Причём созданное ядро становится пригодно не только для ПП87.
На него можно постепенно навешивать нормоконтроль, поиск противоречий, сравнение версий, проверку ТЗ, извлечение ВОР, поиск проектных решений, анализ замечаний и десятки других сценариев.
То есть мы один раз дорого и хорошо решаем проблему подготовки и понимания ПД, а потом получаем инфраструктуру сразу под множество ИИ-сервисов.
Вот это уже называется масштабирование.
5️⃣Слой 5. Онтология, граф и инженерная логика.
Если вы дошли до этого уровня, мои советы вам уже, скорее всего, не особенно нужны.😬
Предыдущие уровни я разрабатывал и проверял собственными руками. А вот этот у меня пока находится на уровне R&D.
Причём он уже вообще не про проверку ПП87. Но если хорошо реализовать предыдущий слой, то аппетит неизбежно придёт во время еды. Потому что довольно быстро захочется спросить систему не «Где в документации указан расход насоса?», а «Что произойдёт с проектом, если я заменю этот насос на другой?» Естественно здесь обычный RAG заканчивается.
Потому что система должна понимать, что насос это не просто кусок текста.
Это конкретный объект, который относится к конкретной инженерной системе и к него есть расход, напор, мощность и другие параметры. А самое главное он связан с:
🟥Трубопроводами
🟥Эектроснабжением
🟥Автоматикой
🟥Помещением
🟥Расчётами
🟥Спецификацией
🟥Планами
🟥Схемами
🟥Требованиями нормативов
И изменение одного параметра потенциально должно вызвать проверку целой цепочки зависимостей. Здесь ПД начинает превращаться уже не просто в базу знаний, а в модель проекта.
Появляется онтологическая модель предметной области: какие сущности существуют, какими свойствами обладают, какие типы связей между ними возможны и что эти связи означают.
А поверх неё формируется граф конкретного проекта: уже с реальными насосами, помещениями, системами, расчётами, листами, требованиями и связями между ними.
Причём онтологическая строительная модель с переходом в граф знаний конкретного проекта, это самое интересное место исследований в паре с ИИ, которые я сейчас пытаюсь решить.
В результате этого, теоретически, мы действительно можем прийти к системе, которая скажет:
«Если заменить этот насос, проверь вот эти три расчёта, две схемы, спецификацию оборудования и данный раздел пояснительной записки. Вот почему».
Причём не потому, что LLM красиво это придумала, а потому, что в модели проекта существуют реальные связи, на основании которых этот вывод был сделан.
Вот к такому уровню я бы в итоге и стремился. Потому что здесь ИИ уже перестаёт быть отдельной игрушкой рядом с проектированием. Он становится одним из слоёв самого проектного процесса и поддержки принятия решений.
😴В итоге.
При системном применении ИИ не должно быть перечня промтов. На первых этапах должны быть ИИ-утилиты, снимающие самые трудоёмкие задачи, затем движение к ИИ-слою как базовому элементу реализации проектного процесса и поддержки принятия решений. Доступ к прямому интерфейсу ИИ нужен, но требует отдельного проекта по организации такой работы. Говорить о том, что все должны использовать прямой ИИ, пока рано. Массовое применение ИИ это не куча подписок на ИИ-сервисы, а кастомные решения под задачи компании, которые уже сейчас могут разрабатываться внутри компании или внешними специалистами.