От «Вечного стажера» к «Цифровому советнику»

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

У вас в папке «Избранное» лежат десятки запросов к нейросети. Вы писали их в моменте — под конкретную задачу, под конкретную модель, под конкретное настроение. Они работали. А через месяц вы не помните, какой из них актуален, под какую версию модели заточен и почему там стоит оговорка «не используй слово „возможно“». Это не библиотека. Это кладбище.

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

Сегодня покажем, как превратить разовую атомарную операцию в переиспользуемый интеллектуальный актив — модуль (в англоязычных источника — «skills») — и почему этот актив мертв без среды исполнения. А также разберем ментальный инструмент, который отсекает 80% избыточных решений еще до того, как вы потратите первый рубль.

Если вы читали серию публикаций «Executive AI OS» в корпоративном канале ЦКР, то знаете три слоя когнитивной архитектуры: аксиоматический, методологический и протокол вывода. Сегодня смотрим на ту же систему с другого берега: не сверху вниз (от операционной системы к модулям), а снизу вверх — от атомарной операции к модулю, и дальше к системе. Тем, кто уже проектирует свою когнитивную операционную систему, она ответит на вопрос, который неизбежно возникает после шестой публикации: «А что именно является кирпичом, из которого строится здание?» Кирпич — это модуль.

Прежде чем говорить о технологии, поговорим о роли. Потому что переход от «атомарной операции» к «модулю» — это не технический апгрейд. Это смена вашей профессиональной идентичности.

В менеджменте есть классическая рамка: техник; управленец; архитектор. Техник делает работу руками. Управленец строит процесс. Архитектор проектирует систему, в которой процессы рождаются и умирают по объективным законам, а не по настроению.
Когда вы пишете запрос в чат — вы техник. Вы решаете конечную задачу здесь и сейчас, вручную, без возможности масштабировать. Завтра вы будете решать ту же задачу заново. Когда вы фиксируете этот запрос как модуль — с входом, выходом, валидатором и владельцем — вы становитесь управленцем. Вы построили процесс. Теперь его может запустить любой уже без вас. Когда вы встраиваете модуль в когнитивную операционную систему, где он подчиняется аксиомам, выдает артефакты и может быть перенесен с одной модели на другую без переписывания — вы становитесь архитектором. Вы создали среду, в которой интеллектуальные активы живут, комбинируются и масштабируются, имеют ограничения и подстраховку от ошибок и галлюцинаций LLM.

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

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

Модуль — это то, что вы уже делаете, но вслепую

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

Представьте модуль как строку в таблице бизнес-процесса: шаг, вход, выход, исполнитель, владелец. Шаги бывают двух типов:

1. По алгоритму — поиск слова в тексте, проверка формата, расчет по формуле. Нейросеть не вызывается. Результат всегда одинаковый. Нулевой риск ошибки.
2. Экспертный — классификация текста, извлечение смысла, формулировка вывода. Здесь нейросеть незаменима. Но вход для нее — те самые рычаги настройки, а выход — строго в заданном формате: не «наверное, это про штрафы», а конкретный ответ с цитатой из документа.

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

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

Модуль не рождается в момент написания запроса. Он рождается в момент, когда вы проходите через четыре этапа проектирования. Пропустите хотя бы один — и получите очередной труп в папке «Избранное».

Шаг 1. Декомпозиция

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

1. Найди пункт о штрафных санкциях.
2. Извлеки сумму.
3. Верни ответ в заданном формате с цитатой из текста".

Вы не можете автоматизировать то, что не разделили конечные операции с понятным результатом. Это первый и главный закон. Вы все еще техник, но уже думаете, как управленец: не «сделай мне», а «сделай вот это, потом вот это, потом верни вот в таком формате».

Шаг 2. Калибровка: принцип нулевого бюджета

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

Сценарий А. Неограниченный бюджет.
Представьте: у вас самая мощная модель мира, команда из десяти разработчиков, векторная база на сто миллионов документов и бюджет в сотни миллионов. Как бы вы решили задачу? Скорее всего это будет поисковая генерация, дообучение модели на ваших документах, мультимодальный анализ, оркестрация пяти агентов. Модно. Молодежно. Красиво. Дорого. И в 90% случаев избыточно.

Сценарий Б. Нулевой бюджет.
У вас только браузер, локальная модель Gemma 4 E2B на ноутбуке с 16 ГБ оперативной памяти и один час времени. Как решить ту же задачу? Вы вынуждены декомпозировать процесс до предела. Вы отказываетесь от семантического поиска в пользу точного совпадения ключевых слов. Заменяете сложную оркестрацию и параллельную работу нескольких моделей со сравнением выданных ими результатов и рекурсивными повторными запросами простой и жесткой последовательностью из трех шагов. Вы не прячете ошибки модели за архитектурой — вы проектируете изначально так, чтобы ошибиться было попросту невозможно.

Парадокс в том, что решение из сценария Б оказывается точнее, чем из сценария А. Потому, что ограничение рождает дисциплину.

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

Для топ-менеджмента это ключевой тезис. Когда в следующий раз команда запросит бюджет на «более мощную модель, которая справится лучше», задайте один вопрос:

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

Вернемся к кейсу про NDA, который мы разбирали в «Партизанской автоматизации», и посмотрим, как это работает на практике.
Неограниченный вариант, который мне предложили бы в классическом ИТ-проекте:

1. Поисковая генерация по базе прецедентов.
2. Дообучение модели на трехстах договорах.
3. Мультимодальный анализ сканов.
4. Оркестрация агентов.
5. Срок: четыре месяца. Бюджет: полтора миллиона.

Результат: «идея не взлетела, дайте еще ресурсов».

Нулевой вариант в три атомарных шага:

1. Поиск по шаблону ключевого слова «штраф».
2. Извлечение абзаца.
3. Проверка, что ответ в нужном формате.

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

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

Шаг 3. Фиксация
Модуль записывается в утвержденном формате. Не в чат. Не в заметку. В спецификацию, которую может прочитать любой новый сотрудник и развернуть за пять минут. У модуля есть версия, владелец, срок ревизии и критерии приемки. Он переживет увольнение автора и смену модели.

На этом шаге вы перестаете быть техником и становитесь управленцем: процесс задокументирован и воспроизводим без вашего участия.

Шаг 4. Встраивание
Модуль подключается к конвейеру. Определяется условие запуска, последовательность в цепочке и протокол вывода. Модуль не существует сам по себе — он существует как часть процесса. Ни один модуль не вызывается вручную. Ни один результат не уходит в работу без прохождения валидатора.

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

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

Модуль мертв без операционной системы
Библиотека модулей без среды исполнения — это набор текстовых инструкций. Прогресс по сравнению с кладбищем промптов, но не более.

Сценарий: модуль «Проверка штрафных санкций» возвращает результат. Цитата пустая. Модель не нашла дословного подтверждения и попыталась «договорить» сумму. В обычном чате вы бы этого не заметили. В библиотеке модулей без операционной системы — тоже не заметили бы, потому что нет механизма, который проверяет.

В когнитивной операционной системе срабатывает аксиоматический слой: правило «Любой вывод должен сопровождаться цитатой из исходного документа. Если цитата отсутствует — результат не валиден». Система блокирует вывод. Модуль получает сигнал об ошибке. Запрос повторяется с принудительным извлечением цитаты. Если цитаты нет — модуль возвращает статус «отсутствует», а не выдумывает сумму.

Один механизм. Одна строка в Конституции операционной системы. И галлюцинация становится невозможной не потому, что модель «стала умнее», а потому что среда исполнения не позволяет ей солгать.

Модули — это мышцы. Операционная система — это нервная система. Мышца без нерва дергается случайно. Мышца, подключенная к нервной системе, двигает тело точно и предсказуемо.

Переход от «Вечного стажера» к «Цифровому советнику» — это не апгрейд модели. Это смена вашей роли. Вы перестаете писать запросы и начинаете проектировать среду, в которой запросы становятся не нужны.

И первый шаг к этому — не покупка новой модели. Не запрос бюджета. Не согласование с ИТ-департаментом. Первый шаг — взять одну рутинную задачу, которая убивает в вас интерес к профессии, и спросить себя: «Как бы я решил это с нулевым бюджетом?»
Ответ на этот вопрос и станет вашим первым модулем.

Ниже приведена одна из пяти атомарных операций реального модуля для анализа динамики кибератак из PDF-отчетов. Полный текст спецификации превышает 20 000 символов и включает пять LLM-операций, шесть детерминированных шагов, два справочника и протокол вызова модели с каскадным механизмом повторных попыток.
Для демонстрации выбрана операция «Верификация данных по тексту». Именно она защищает результат от галлюцинаций модели.

Модуль «Анализ трендов кибератак из PDF-отчетов» v1.0

Каскадная стратегия верификации:

1. Детерминированный поиск цитаты (модель не вызывается). Разбиение текста на предложения. Поиск предложения, где одновременно есть термин категории и число. Если найдено — статус «verified», достоверность 1.0. Модель не тратит ни одного токена.

2. LLM-верификация (если детерминированный поиск не сработал).
Системная инструкция: «Ты — верификатор цитат. Отвечай только JSON.»

Пользовательский запрос:

JSON-схема выхода (цифровые критерии готовности):

Валидатор:

• status обязан быть одним из четырех допустимых значений.
• quote обязан быть строкой.
• При невалидном ответе: повтор запроса с добавлением «Предыдущий ответ не прошел валидацию. Верни только JSON строго по схеме.»
• Детерминированная корректировка после ответа модели:
• Проверка, что цитата действительно присутствует в оригинальном тексте.
• Проверка наличия числа и термина категории в цитате.
• Корректировка статуса на основе результатов.
• Параметры вызова: max_tokens=500, temperature=0.0, seed=42

Важное уточнение по предметной области: анализ трендов в данном конвейере не включает обработку сырой статистики атак (логов, алертов, телеметрии). Конвейер работает с готовыми оценками внешних SOC-провайдеров — извлекает уже рассчитанные доли из их PDF-отчетов, нормализует категории и верифицирует данные по оригинальному тексту. Это доверие к чужой аналитике, а не замена собственной.