Двухмодельный процесс: когда разделённая AI-настройка экономит деньги

Почему эта проблема возникает

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

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

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

Повторы вредят сильнее, чем кажется по стоимости токенов. Они ещё и съедают:

• время редактора на проверку того, что изменилось
• фокус команды, потому что люди ждут, читают и снова отправляют запросы
• стабильность, потому что каждая новая попытка может менять тон или факты
• уверенность, потому что никто не понимает, когда результат уже готов

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

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

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

• 3 повторные попытки превращаются в 1
• 12 минут редактирования сокращаются до 5
• $0.80 за готовую задачу снижается до $0.45
• 10 задач с одним плохим результатом превращаются в 10 задач без ошибок

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

Что должна делать каждая модель

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

Если обе модели и исследуют, и пишут, разделение перестаёт окупаться. Вы платите дважды за одно и то же мышление, а те же ошибки всё равно исправляете вручную.

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

Модель для написания должна делать противоположное. Дайте ей небольшой набор утверждённых заметок и попросите упорядочить, упростить и переписать их под читателя. Она должна улучшать формулировки, убирать повторы и держать единый тон. Ей не нужно искать дополнительные факты или додумывать недостающие числа.

Сделайте передачу короткой

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

Хорошая передача обычно включает:

• цель материала
• 5–10 утверждённых фактов или заметок
• открытые вопросы, которые всё ещё мешают писать
• утверждения, которых автор должен избегать
• аудиторию и тон

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

Рано останавливайте смешение ролей

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

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

Небольшая продуктовая команда видит это быстро. Одна модель просматривает обращения в поддержку, заметки о релизе и исправления багов, а затем делает факт-лист. Другая модель превращает этот лист в письмо для пользователей с обновлением. Если автор начинает добавлять новые причины, цифры или продуктовые обещания, кто-то должен всё это проверять, и преимущество по затратам исчезает.

Команды, с которыми советует Oleg, часто получают лучшие результаты, когда строго держат такое разделение в AI-first процессах разработки. Одна модель собирает сырой материал. Одна модель пишет для людей. В тот момент, когда одна из сторон пересекает эту границу, повторы растут, а экономия сокращается.

Как протестировать это шаг за шагом

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

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

Сначала возьмите маленькую выборку. Десяти–двадцати элементов достаточно, чтобы увидеть закономерность, не тратя лишнее время и бюджет.

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

Затем зафиксируйте формат передачи между двумя моделями. Это важнее, чем многие ожидают. Если первая модель передаёт во вторую неаккуратный комок текста, вторая тратит время на догадки вместо написания.

Простой формат передачи может выглядеть так:

Task:
Audience:
Source facts:
Must include:
Must avoid:
Open questions:
Confidence:

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

Теперь прогоните тот же набор задач через разделённую схему. Оставьте вводные, проверяющих и критерии приёмки такими же, как в базовом тесте. Меняйте только одно: модель A собирает, фильтрует или структурирует материал, а модель B пишет финальный черновик.

Для небольшой софтверной команды полезный тест выглядит так:

• Модель A читает треды по багу и извлекает только подтверждённые факты
• Модель B превращает эту передачу в короткое обновление для пользователей
• Ревьюер помечает каждый результат как pass, minor edit, major edit или fail

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

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

Что измерять

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

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

Используйте готовые задачи как базу

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

Небольшая команда может вести пять показателей для каждой задачи:

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

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

Время почти так же важно, как и деньги. Измеряйте время до первого приемлемого черновика, а не до первого ответа. Быстрый ответ, который потом требует 18 минут доработки, медленнее, чем немного более медленный черновик, которому хватает двух правок.

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

Фиксируйте ошибки перезапуска, а не только плохие ощущения

Создайте короткий список ошибок и используйте одни и те же метки каждый раз. Пишите просто:

• неточные или слабые исследования
• черновик не следовал брифу
• факты противоречат исходным заметкам
• формат сломал требуемую структуру
• результат выглядел нормально, но не решал настоящую задачу

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

Команды, которые выстраивают lean AI-assisted operations, часто узнают это на собственном опыте. Разделённая схема экономит деньги только тогда, когда снижает переделки. Если повторы остаются на том же уровне, а время на правки не уменьшается, передача просто добавляет лишние элементы.

Реальный пример небольшой команды

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

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

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

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

Базовый вариант и тест с разделением выглядели так:

• Базовый сценарий с одной моделью: 28 минут, 4 попытки запроса, 7 фактических правок до одобрения
• Двухмодельный процесс: 17 минут, 2 попытки запроса, 2 фактические правки до одобрения
• Время проверки снизилось с 9 минут до 4
• Общие траты на модели упали примерно на 22%, хотя первая модель обработала больше сырых заметок

Выигрыш появился не из-за более красивого текста. Он появился из-за сокращения повторов. В базовом варианте каждый слабый черновик заставлял команду заново объяснять функцию. В разделе с двумя моделями первая модель заранее вытаскивала недостающие факты, а вторая писала на основе стабильного брифа.

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

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

Ошибки, которые убивают эффект

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

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

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

Ещё одна ошибка — менять промпты на каждом прогоне. Если поисковый промпт меняется в понедельник, промпт для писателя — во вторник, а правило проверки — в среду, вы тестируете не разделение. Вы тестируете движущуюся цель. Оставьте промпты фиксированными достаточно долго, чтобы сравнивать действительно осмысленные прогоны.

Расчёты по стоимости ломаются и тогда, когда команды смотрят только на цену токенов. Дешёвые токены всё равно могут стоить дорого, если сотрудники тратят 20 минут на исправление слабых черновиков, объединение дублирующихся результатов или выбор того, какой версии доверять. Разделение, которое сокращает расходы на API на 15%, но добавляет час проверки каждый день, — плохая сделка.

Худший сценарий — когда обе модели переписывают всю задачу целиком. Тогда вы платите дважды за одну и ту же работу. Чёткие границы помогают:

• Модель один собирает факты, извлекает примеры или ранжирует исходные материалы.
• Модель два превращает этот бриф в финальный черновик.
• Человек проверяет крайние случаи, а не переписывает каждое предложение с нуля.

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

Быстрые проверки перед запуском

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

Начните с самого простого теста: может ли одна модель уже закончить задачу после одной-двух повторных попыток? Если да, вторая модель может просто добавить стоимость токенов, задержку и больше мест, где процесс уйдёт в сторону.

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

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

Короткий список перед запуском помогает сохранить тест честным:

• Попробуйте задачу сначала на одной модели и посчитайте, сколько повторов ей нужно.
• Сделайте передачу достаточно компактной, чтобы человек мог прочитать её без прокрутки стены текста.
• Попросите одного проверяющего одобрить или отклонить передачу меньше чем за минуту.
• Задайте правило остановки до начала теста, например: «закончить через две недели, если стоимость и число повторов останутся на том же уровне».
• Запишите, что значит «готово», чтобы все оценивали результаты одинаково.

Последний пункт подводит команды чаще, чем они ожидают. Один человек думает, что «готово» означает «читается». Другой считает, что это значит «проверено по фактам, соответствует бренду и готово к публикации». Если не договориться об этом до запуска, цифры будут шумными, а виноватым объявят передачу между моделями, хотя проблема была в неясных правилах проверки.

Небольшой пример делает это понятнее. Допустим, продуктовая команда использует модель A для поиска по заметкам, тикетам и документам, а затем модель B для написания релиз-нотов. Если первая модель возвращает краткое резюме с номером версии, изменениями, которые вышли, известными ограничениями и недостающими данными, пишущая модель обычно работает нормально. Если же она выдаёт три грязные страницы, вторая модель начинает гадать, и число повторов растёт.

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

Что делать вашей команде дальше

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

Держите тест компактным. Одна задача, одна команда и одно окно на 2–3 недели обычно дают достаточно данных, не превращая эксперимент в отдельный побочный проект. Если задача меняется каждый день, вам будет сложно понять, помогла ли передача между моделями или сама работа просто стала легче.

Задайте правило оставлять или убирать схему до начала. Если подождать до конца, люди начнут спорить на уровне ощущений. Лучше работает простое правило:

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

Сделайте порог конкретным. Например, вы можете оставить схему только если число повторов падает с 3 попыток до 1, средняя стоимость задачи уменьшается на 20% или каждая задача экономит не меньше 10–15 минут. Так отслеживание стоимости AI превращается в реальное решение, а не в расплывчатое мнение.

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

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

Для продуктовых команд, которым нужен практичный пилот, Fractional CTO advisory от Oleg Sotnikov может помочь настроить процесс, определить передачу и отслеживать стоимость, повторы и время, чтобы понять, действительно ли разделение экономит деньги.