#СтройпрактИИкум@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.