Я долго думала, как написать этот пост.

Люди чувствительно воспринимают критику, даже когда речь идёт не о них, а о предложенном решении. Тем более что и я могу ошибаться.

Но промолчать тоже не получается: подобные утверждения уже становятся содержанием обучения. Поэтому предлагаю непрошеный совет от кота Матроскина, который, напомню, с дядей Фёдором всё-таки подружился.

Поводом стал пост о фреймворках RTF и CREATE. На примере приветственного письма новому сотруднику автор показала, как задать нейросети роль, задачу и формат, а затем назвала такой подход управлением качеством результата с первого запроса.

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

Пойду по четырём тезисам.

Фреймворк фреймворку рознь

Я привыкла понимать фреймворк как известную модель, за названием которой уже стоит определённая логика. Например, достаточно указать 4C/ID, чтобы нейросеть развернула проектирование обучения через практические задачи, необходимую информацию и отработку отдельных операций.

RTF и CREATE используются здесь иначе. Это памятки о том, что положить в запрос: роль, задачу, контекст, примеры и формат ответа.

Такая структура полезна, особенно новичку. Но она не объясняет содержание задачи за пользователя и не гарантирует полноту условий.

Можно и с ними получить бессмысленную кашу и по рецепту — просто она будет аккуратно разложена по тарелкам.

Результат генерации ещё не бизнес-результат

С хаотичными запросами всё понятно: написал первое, что пришло в голову, — получил нечто странное.

Но правильно составленный промпт обеспечивает лишь более подходящий ответ, а не стабильный бизнес-результат.

Допустим, модель подготовила безупречное письмо: указала дату выхода, встречу с наставником и ссылку на базу знаний.

Результат генерации получен.

Бизнес-результат наступит, если сотрудник получит доступы, встретится с наставником, поймёт задачи и начнёт работать. Между письмом и состоявшимся онбордингом остаются люди, системы, действия и контроль.

Впрочем, сначала «пойди туда, не знаю куда, и найди то, не знаю что», а затем претензия к бизнес-результату — это очень по-человечески. 😎

Самопроверка модели ещё не приёмка

В ответ на мой вопрос о критериях качества автор рассказала об эталонных примерах, доработке, сценариях ошибок и техниках, «заставляющих модель проверять саму себя».

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

Как я уже писала здесь, модель может обнаружить собственную ошибку, а может уверенно её подтвердить. Поэтому способ проверки определяется ещё и ценой возможной ошибки.

Не всякая автоматизация нуждается в ИИ

В одном из комментариев письмо предложили автоматизировать: подключить модель через API, передавать ей имя, дату и наставника, а сведения искать в корпоративных документах с помощью RAG.

Но в приведённом примере содержание письма постоянно, меняются только несколько значений. Меня же ещё в 2013 году в институте заставляли сдавать зачёт по созданию таких шаблонов в Word с подстановкой данных.

Дешевле. Быстрее. Предсказуемее.

Тогда зачем здесь вообще ИИ?

Он полезен, если появляется настоящая вариативность: нестандартная ситуация, персональное объяснение или маршрут онбординга из нескольких источников.

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

Глубина внедрения сама по себе не создаёт пользу. Она увеличивает технологическую зависимость, стоимость и масштаб последствий ошибки.

Иногда подходящим решением будет AI-агент. Иногда — сочетание обычной автоматизации и нейросети. А иногда — старый шаблон Word, которому не нужны эмбеддинги, чтобы вспомнить имя наставника.

Профессионализм — это способность выбрать минимально сложное решение, надёжно приводящее к нужному результату.

Хотя вы можете возразить, что Word продаётся хуже ИИ.

И будете правы.

#ИИ