Две модели на одну задачу: одна пишет, вторая проверяет

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

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

Почему вторая модель замечает то, что не заметила первая

Начнём с того, почему нельзя просто попросить ту же модель проверить саму себя.

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

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

Есть и второй фактор, менее очевидный. Проверка — задача принципиально проще генерации. Написать связный абзац про закон, которого не существует, легко; оценить конкретное утверждение «такая норма есть, вот номер» на правдоподобие — задача с гораздо более узким пространством ответов. Модель в роли проверяющего работает в более комфортном для себя режиме, чем модель в роли автора.

Какие задачи окупают вторую пару глаз

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

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

Переводы. Здесь вторая модель полезна иначе: она не столько ищет фактические ошибки, сколько сверяет смысл. Типичные находки — пропущенное отрицание, потерянное условие («при условии», «если иное не предусмотрено»), термин, переведённый по общему словарю вместо отраслевого, и калька, которая формально верна, но по-русски звучит неестественно. Отдельно стоит смотреть на числа и единицы измерения: в переводе они переносятся механически и незаметно теряют или приобретают разряд.

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

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

Как устроен промт для роли проверяющего

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

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

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

Задайте один критерий, а не все сразу. Проверка на факты, проверка на смысл перевода и проверка на тон — три разных прохода. Смешанный запрос даёт размазанный ответ, где всё понемногу и ничего конкретно.

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

Базовый каркас, который дальше подстраивается под задачу:

Тебе прислали текст на согласование. Автор неизвестен, твоя оценка ни на кого не повлияет.
Задача: найти [один критерий].
Не переписывай текст и не предлагай свою версию.
Формат ответа — список пунктов:
1. Цитата из текста (дословно).
2. В чём проблема.
3. Насколько ты уверен: высокая / средняя / низкая уверенность.
Если проблем нет, так и напиши. Не придумывай замечания ради объёма.

Промт для проверки фактов

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

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

Промт для проверки перевода

Тебе прислали перевод на сверку. Ниже оригинал и перевод.
Задача: найти расхождения по смыслу, а не по красоте.
Ищи: пропущенные отрицания, потерянные условия и оговорки,
изменённую модальность (должен / может / рекомендуется),
термины, переведённые общим словом вместо отраслевого,
добавленное в переводе, чего нет в оригинале.
Формат: фрагмент оригинала — фрагмент перевода — в чём расхождение.
Стилистические замечания вынеси отдельным блоком в конце.

Промт для проверки объяснения кода

Ниже фрагмент кода и текстовое объяснение к нему, написанное другим человеком.
Задача: сверить объяснение с кодом.
Отметь: утверждения об объяснении, которые коду противоречат;
поведение, описанное неточно; ветки, условия и краевые случаи,
которые код содержит, а объяснение не упоминает.
Не улучшай код и не переписывай объяснение.
Формат: строка или фрагмент кода — что сказано в объяснении — в чём несоответствие.

Промт для проверки письма

Тебе прислали черновик письма перед отправкой. Получатель: [кто это, какие отношения].
Задача: прочитать письмо глазами получателя.
Ответь на четыре вопроса.
1. Какое главное сообщение он вынесет из письма?
2. Что он поймёт как обещание с нашей стороны?
3. Есть ли фразы, которые могут прочитаться как обвинение или отговорка?
4. Что останется непонятным и о чём он переспросит?
Текст не переписывай.

Какие модели ставить в пару

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

Логика распределения простая. На фактах в роли проверяющего удобен Perplexity Sonar Pro — эта линейка заточена под работу с источниками. На переводах и письмах полезнее модель с другой языковой настройкой, чем у автора; какие модели аккуратнее работают с русским, разбиралось в материале про то, какая модель лучше пишет по-русски. На объяснениях кода полезно ставить проверяющим модель общего назначения, а не вторую специализированную: она реже разделяет с автором одни и те же привычки чтения кода и чаще спрашивает «а где здесь обработка пустого значения».

В каталоге Most AI все эти модели открываются в одном кабинете, поэтому перекладывание текста из одного чата в другой не требует ни второй подписки, ни VPN. Проверка обычно обходится дешевле генерации, потому что ответ проверяющего короткий и без развёрнутого текста. А для черновой проверки годится и бесплатный чат ChatGPT — он доступен без ограничения по числу запросов, и на роли «прочитай письмо глазами получателя» его хватает.

Честно: где приём не работает

Перекрёстная проверка снижает риск, но не убирает его. Стоит держать в голове четыре ограничения.

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

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

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

Ссылки, цитаты и номера документов всё равно проверяются руками. Ни одна из двух моделей не открывает страницу и не видит, что там лежит. Максимум, что даёт связка, — короткий список того, что стоит открыть самому.

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

Частые вопросы