Проверка ПД через ИИ
#СтройпрактИИкум@IIstroika
Часть 1 из 2. Процент использования ИИ: 25%
Меня часто просят выложить практические примеры, но вы забываете, что я смотрю на ИИ не как на технологию, а на то, как это внедрять с точки зрения управленца. И поэтому опишу свой подход через призму решения конкретной задачи. Например, проверку документации на соответствие ПП87. В целом эта задача под силу современным LLM топового уровня. Для этого нужно правильно сформулировать промт и загрузить данные в топовую LLM. Например, вы можете найти множество нужных промтов у коллег с канала «AI песочница инженера» (это не реклама). Сразу же скажу: Идея, что качество ответа ИИ обеспечивается волшебным промтом, давно умерла. Это не так и качество достигается другим. Но об этом буду писать в новых постах.

Давайте данный пример с ПП87 разберём с точки зрения системного применения ИИ в компании, а не прикольных экспериментов или улучшения работы конкретного ГИПа.
Допустим, мы выявили, что данная задача действительно съедает много времени и ресурсов компании.
Обратите внимание: проблема отдельно взятого сотрудника может быть некритичной для компании, такое можно выявить только при комплексном взгляде. Да, вы можете удивиться, но локальная неэффективность процесса внутри компании не всегда требует оптимизации.

Небольшое отступление:

Классическое, что можно услышать от рядового сотрудника: этот директор совсем, что ли, не понимает, что данная проблема важна, почему он решает другие вопросы?!
Да, он будет решать именно другие, потому что, с точки зрения руководителя, потери на этом участке ничтожны по сравнению с другими, а тратить ресурсы и время на локальную неэффективность при работающем процессе нерационально. В особенности если процесс не является узким местом корпоративных процессов. Про это целые книжки написаны, и выявить такое можно только в ходе обследования😄

Что мы видим на представленном примере с ПП87? У коллег из AI песочницы вы можете найти перечень промтов и рекомендации по улучшению. В целом всё очень толково. Но вот немасштабируемо. Меня как эксперта-управленца интересует исключительно формирование подхода/решения на уровне компании, с качественным результатом, с минимальными требованиями к сотрудникам и легко повторяемым/масштабируемым результатом.
Таким же промтом могут пользоваться лишь несколько инженеров, заинтересованных в использовании современных решений, но это не сервис и, самое главное, процесс неконтролируемый, с непредсказуемым результатом.

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

Итак, мы решили, что нам жизненно необходима проверка документации на соответствие ПП87.
Как начинается работа? Как и в примере выше: нужен доступ к качественной модели, правильно поставленная задача и хорошие промты. Если всё правильно сделано будет результат.
Но нас как раз и не устраивает вот это самое «если всё правильно сделано».

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

1️⃣Слой 1. ИИ-утилита вместо прямого общения с LLM.
Делается буквально на коленке за несколько дней как первый рабочий прототип.
Берём проверенные промты под разные типы объектов и прячем их внутрь сервиса. Навайбкодим простой интерфейс: пользователь загружает ПД, выбирает тип объекта, при необходимости указывает несколько параметров и получает результат проверки.
Всё. Инженер уже не должен знать, какую модель выбрать, какой промт написать, куда вставить ПП87, в каком порядке загружать документы и какие дополнительные инструкции дать модели.
Мы убираем прямое взаимодействие инженера с LLM, тем самым получаем чуть более контролируемый результат.

Причём я бы даже на этом уровне не заставлял LLM просто отвечать: «соответствует / не соответствует». Лучше сразу делать структурированный результат: какой пункт проверяется, применим ли он к данному объекту, найдено ли соответствующее требование в ПД, где именно найдено и почему система считает его выполненным или невыполненным.

То есть даже первый прототип должен стремиться не просто выдавать ответ, а показывать доказательство, откуда этот ответ взялся. Всё это легко прописать в JSON или MD схемах, после консультации с экспертами. Но качество всё равно будет только приемлемым.

Почему?
Потому что пользователь будет грузить что попало. Один загрузит всю ПД, другой только записку, третий зачем-то приложит ещё двадцать документов, четвёртый забудет половину исходных данных. И даже если написать инструкцию на десятки страниц, её всё равно никто читать не будет.😕

Плюс сам результат работы LLM ещё надо проверять.
В этом месте появляется первый принципиально важный элемент системного применения ИИ:

Тестирование это не этап разработки. Это постоянный процесс.

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

Условно: было 100 контрольных требований ПП87. Вчера система правильно проверяла 92, сегодня после обновления модели 89. Значит, у нас проблема.
Здесь же кроется неприятная новость для руководителей. Эксперты предметной области будут нужны постоянно. Особенно на первых этапах. Нельзя посадить программиста, дать ему ПП87 и через месяц получить хороший инженерный сервис.

Можно снизить количество привлечения экспертов, особенно если руководитель разработки сам хорошо знает предметную область, но полностью убрать их из процесса не получится.

🎁Сквозной слой. Безопасность и контроль данных.
Я специально не называю это слоем 2, потому что безопасность должна появляться с первого обращения к внешней LLM.
ПД, а особенно сметы и внутренняя документация компании, могут содержать не только ПДн, но и целый букет проблем⚠️. Там может быть коммерческая тайна, информация по режимным объектам, внутренние технические решения, данные заказчика и много всего интересного, что совсем не хочется однажды обнаружить на серверах супостата. И я сейчас не иронизирую, бывали такие случаи.
Поэтому пользователь вообще не должен решать, что можно отправлять в LLM, а что нельзя.

Это должна решать система.
На входе документ классифицируется, проверяется на чувствительные данные, при необходимости данные удаляются, маскируются или заменяются, а после обработки возвращаются обратно.

То есть правило, в стиле закона Мерфи:

если пользователю дали возможность ошибиться, то рано или поздно он ошибётся.

🔴Даже если подписал инструкцию.
🔴Даже если прошёл обучение.
🔴Даже если вчера клялся СБ, что всё понял ))

Поэтому задача корпоративного решения не научить человека помнить правила, а технически не позволить их нарушить там, где это возможно.

Конец Части 1 из 2.

Продолжение. Часть 2 из 2.

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 красиво это придумала, а потому, что в модели проекта существуют реальные связи, на основании которых этот вывод был сделан.
Вот к такому уровню я бы в итоге и стремился. Потому что здесь ИИ уже перестаёт быть отдельной игрушкой рядом с проектированием. Он становится одним из слоёв самого проектного процесса и поддержки принятия решений.

😴В итоге.
При системном применении ИИ не должно быть перечня промтов. На первых этапах должны быть ИИ-утилиты, снимающие самые трудоёмкие задачи, затем движение к ИИ-слою как базовому элементу реализации проектного процесса и поддержки принятия решений. Доступ к прямому интерфейсу ИИ нужен, но требует отдельного проекта по организации такой работы. Говорить о том, что все должны использовать прямой ИИ, пока рано. Массовое применение ИИ это не куча подписок на ИИ-сервисы, а кастомные решения под задачи компании, которые уже сейчас могут разрабатываться внутри компании или внешними специалистами.

Бытовые наблюдения непрограммиста
#Бесполезные_мысли #Бесполезные_мысли@IIstroika
Объем применения ИИ: 20%

Как и все мальчики моего возраста, я частенько занимаюсь цифровым рукоблудием. Сейчас это модно называть вайбкодингом. Конечно, пока эта интеллектуальная девиация не перетекает в радикальные формы типа B2B SaaS, но иногда всё же заносит на поворотах. Поэтому решил поделиться рядом наблюдений. Интересно, как у вас? И не делайте вид, что вы все приличные и ничем таким постыдным не занимаетесь!
В основном наблюдения построены вокруг взаимодействия с OpenAI (Codex, API).

1️⃣ИИ сильно недооценивает техническую сложность реализации твоей новой идеи.
Я регулярно прихожу к ИИ с идеями что-то сделать. Обсудить, так сказать. И буквально на каждую идею он выдаёт:

Давай, братан, у тебя уже 30% бэкенда готово. Тут делов-то на 20 минут, вошли и вышли (с)...

Через 5 недель, отлаживая жуткий пайплайн и спустя миллиарды токенов, понимаешь, что довести это чудо до работоспособности будет очень сложно. Хотя 2 недели назад ИИ говорил, что проект готов на 90%.

2️⃣Оказывается, ИИ тебе писал, сколько это займёт, но ты, скорее всего, пропустил это мимо ушей.
Вот такое необычное когнитивное искажение я словил. Когда обсуждал проект с ИИ, он мне честно говорил, что понадобится не меньше месяца на реализацию. На что я говорил себе: да ладно, там нет ничего сложного. Спустя месяц, впервые запуская проект, я понял, что он не ошибался. И такое было много раз.

3️⃣ИИ маниакально зациклен на безопасности. Особенно если разрешить ему самому решить, сколько безопасности вам нужно.
Намедни собирал бэкенд с ИИ и доверил ему разработку системы безопасности без моего управления. Дык, по итогу, на готовом сервисе, чтобы войти под суперадмином, пришлось проворачивать настоящую спецоперацию уровня ядерного чемоданчика, а нормы безопасности были такими, что шагу выполнить пользователю нельзя без одобрения админа и суперадмина. Эта ситуация повсеместна. 👮
Я как-то собирал агента на VPS-сервере и решил довериться тому, что рекомендует ИИ. В итоге этот агент мог только отвечать на прямые вопросы, любые другие шаги превращались в DevOps-ад. Всё из-за маниакальной системы безопасности.👮
Если отдать ИИ проектирование безопасности без явно заданной модели угроз, допустимого риска и требований к UX, он почти неизбежно начинает перестраховываться.
Проблема в том, что модель не знает, где у тебя проходит граница между «безопасно» и «этим невозможно пользоваться», и выбирает консервативный вариант.

4️⃣Следи за тем, что делает ИИ.
Не знаю, как у других, но я не представляю, что можно поставить задачу, включить выполнение цели и типа пусть ИИ сам решает задачу как хочет. 👀
Мой опыт говорит, что он решит таким образом, что волосы зашевелятся даже там, где их нет. Нельзя отпускать ИИ надолго без контрольных точек, чтобы ловить момент, когда его потянет на блудняк. Хотя все ограничения строго прописаны везде, где только можно. Уже неоднократно ловил момент, когда ИИ начинал делать какой-то функционал, который особо не нужен, но с его точки зрения это логично.

5️⃣Не доверяй слепо его рекомендациям по проверкам. Особенно когда вместо локального теста он предлагает очередной полный аудит проекта силами LLM.
Очень частая ситуация, когда ведётся сложная сборка какой-либо информации (люблю я строить онтологические модели для разных задач) или просто какой-либо этап разработки, и он говорит, что надо сделать проверку целостности данных всего проекта. Хотя на прошлом шаге он уже это делал. Каждый такой шаг просто пожирает токены/лимиты. Но как только задаёшь вопрос, так ли необходима такая проверка, оказывается, что нет, и он просто решил перестраховаться.😡

6️⃣Если ребёнок в соседней комнате затих, жди беды. Тут то же самое.
На одном из проектов ИИ начал гонять безумное количество долгих тестов на GitHub. Вроде что-то делает, ничего не просит, проблем нет. Я решил поинтересоваться: а что это ты там делаешь? Он и говорит: у тебя на сервере нет нужного ПО, поэтому я вынужден тесты прогонять через жутко медленные пайплайны на GitHub. Дык какого хера ты не сказал, что это ПО нужно?😠
Теперь во всех инструкциях указываю проверить список доступного ПО и сообщить, если чего-то не хватает. Всегда интересуйтесь, чем же занят ваш ИИ и по какому пути он идёт. Могут быть сюрпризы.

7️⃣ИИ подвержен туннельному синдрому.
Это касается и разработки, и просто консультаций. ИИ знает всё, но в некоторых темах он сам по себе может зарыться в одно направление и копать туда «до талого». Не доверяйтесь слепо, всегда сами старайтесь смотреть шире и подкидывать идеи для ИИ. Возможно, будет что-то толковое. Только учтите, у моделей вообще есть известная склонность соглашаться с пользователем. Проще говоря, это подхалимство.❤️

8️⃣Не верь процентам готовности проекта.
Если ИИ говорит: «проект готов на 90%», это вообще ничего не значит. 90% файлов написано? 90% функциональности работает? 90% требований закрыто? 90% тестов зелёные? Я уже несколько раз видел проекты, которые были «готовы на 90%» за две недели до того, как выяснялось, что впереди ещё месяц работы.
Теперь процент готовности существует только относительно конкретного чек-листа и критериев приёмки.

9️⃣ИИ очень любит незаметно расширять задачу.
Просишь добавить кнопку. Через некоторое время выясняется, что он уже строит универсальный слой технологий на случай, если когда-нибудь появятся ещё 14 кнопок с одновременным контуром тестирования решений, которые ты не закладывал.
Особенно страшно звучит фраза: «Заодно я заметил, что архитектуру здесь можно улучшить».😫
Поэтому у меня теперь отдельно прописано: не исправлять соседние проблемы, не проводить рефакторинг и не добавлять функциональность, которую явно не просили.

Очень интересно мнение общественности. У вас такие же проблемы?🍿

Иногда ИИ уходит в такой язык, что он становится только машиночитаемым. Даже у меня нервы не выдерживают от такого. 😠

#СтройпрактИИкум@IIstroika

Я уже делал ранее пост, как начать дорабатывать САПР с помощью ИИ. Теперь решил дополнить его уже полноценным гайдом, чуть более приближенным к практике. Здесь PDF версия нового гайда.

Как всегда, кратко не получилось, гайд не влез даже в 4 сообщения, поэтому сделал PDF статью. Нейрослопа по минимум, всё авторская боль, боль тех кого консультирую и бессонные ночи в попытках заставить это работать.

Гайд не просто о том как начать, а о том как начать делать на серьёзном уровне, инженерном уровне.

P.S. Не нужно загонять этот гайд в ИИ и просить сделать краткий пересказ, потеряете весь цимес, я пробовал.😎