У меня долго была довольно простая схема работы с нейросетью.
Дал задачу.
Получил текст.
Прочитал.
Если всё нормально — используем.
Если нет — пишем:
Проверь свой ответ, найди ошибки и исправь.
На первых порах это казалось вполне разумным. Модель же умная. Если она умеет написать текст, наверное, сможет и проверить собственную работу.
Потом я начал замечать забавную закономерность.
Нейросеть очень часто перечитывала собственную ошибку и отвечала примерно так:
Да, всё корректно.
То есть сначала уверенно придумала ерунду, а потом столь же уверенно её одобрила.
И тогда возник очевидный вопрос:
а что будет, если одну нейросеть проверять другой?
Не попросить автора ещё раз посмотреть на свой текст, а устроить маленькую редакцию:
один пишет;
второй ищет косяки;
первый исправляет;
третий принимает результат.
Именно такую механику я в итоге начал использовать в собственных автоматизациях.
Спойлер: ошибок действительно стало меньше.
Но обнаружилось несколько нюансов, из-за которых схема «пусть три ИИ поспорят и выдадут истину» работает совсем не так красиво, как звучит.
Почему нейросеть плохо проверяет сама себя
С человеком ситуация похожая.
Если я написал текст и через тридцать секунд начинаю его вычитывать, мозг часто видит не то, что реально написано, а то, что я собирался написать.
Поэтому редактор замечает вещи, которые автор спокойно пропускает.
У языковых моделей есть похожая проблема, хотя механизм, конечно, другой.
Модель уже построила определённую интерпретацию задачи. Она выбрала факты, аргументы и логику. Когда мы говорим:
Проверь себя.
она часто продолжает рассуждать внутри той же конструкции.
Если первоначально модель решила, что некий факт верен, у неё нет автоматической причины внезапно начать считать его подозрительным.
Особенно если текст звучит убедительно.
Нейросети вообще удивительно хорошо умеют писать неправду так, будто автор лично присутствовал при событии и ещё сохранил фотографии.
Поэтому команда:
Проверь, нет ли ошибок.
часто превращается в литературный ритуал.
Модель читает собственный ответ, находит пару стилистических мелочей и торжественно сообщает:
Существенных ошибок не обнаружено.
Очень удобно.
Тогда я разделил роли
Вместо одного универсального запроса появилась цепочка.
Одна модель получает задачу:
Напиши материал.
Другая:
Не переписывай текст. Найди конкретные ошибки, слабые места, противоречия и неподтверждённые утверждения.
После этого автору возвращается не команда:
сделай лучше,
а список:
- Здесь утверждение слишком категоричное.
- Эта дата требует проверки.
- Этот абзац повторяет предыдущий.
- Вывод не следует из приведённых аргументов.
И только потом автор делает исправления.
На последнем этапе ещё одна модель получает уже готовый вариант и должна принять решение:
публиковать;
вернуть на доработку;
остановить.
На бумаге выглядит как обычная редакция.
Автор.
Редактор.
Контролёр.
Только все трое живут в дата-центре.
Первое открытие: независимый критик действительно полезнее
Самый заметный эффект появился не от того, что проверяющая модель была «умнее».
Она просто получала другую задачу.
Автору говорили:
создай хороший текст.
Критику:
твоя работа — найти причины, по которым этот текст плох.
Это очень разное положение.
Если поставить модель в режим критика, она начинает смотреть на результат иначе. Вдруг появляются замечания к логике, повторениям, структуре, слишком широким выводам.
Особенно хорошо ловятся вещи вроде:
в начале автор обещал рассказать о трёх причинах, а разобрал две;
один и тот же тезис повторён разными словами;
вывод звучит сильнее, чем доказательства;
статья незаметно ушла от заявленной темы.
Такие ошибки одна модель действительно часто видит у другой.
И тут я впервые подумал:
О, вот оно. Сейчас посадим пять нейросетей проверять друг друга и получим идеальный текст.
Не получили.
Потому что несколько моделей могут ошибаться совершенно одинаково
Вот это намного интереснее.
Допустим, автор пишет:
Событие произошло в 1987 году.
Проверяющая модель тоже знает — или думает, что знает — примерно ту же информацию.
Она видит дату:
И отвечает:
Всё правильно.
Потом приходит третья.
Тоже:
Да, 1987.
Три независимых голоса.
Красота.
Только событие произошло в 1989-м.
Получилась маленькая демократическая процедура, где галлюцинация победила со счётом 3:0.
😁
Если несколько моделей обучались на похожих данных, у них могут быть коррелированные ошибки.
Это не три историка, которые независимо сходили в разные архивы.
Это три системы, у которых значительная часть знаний сформирована из пересекающегося информационного пространства.
Поэтому простое большинство:
две нейросети согласились — значит правда
не работает.
Особенно плохо они проверяют факты без доступа к источникам
Можно попросить модель:
Проверь все факты в статье.
Она выглядит занятой.
А потом выдаёт:
Факты в целом соответствуют действительности.
Но что именно произошло?
Она не проверила их.
Она сравнила текст со своими внутренними представлениями.
Это совсем другое.
Если нужно проверить дату, цену, цитату, закон, характеристики продукта или свежую новость, критик должен получить возможность обратиться к источнику.
Иначе мы имеем не фактчекинг.
А голосование памяти нейросетей.
Поэтому в своих конвейерах я разделяю как минимум два вопроса:
Текст логичный?
и:
Факты подтверждаются?
Первое модель умеет оценивать сама довольно хорошо.
Второе требует источников.
Зато против выдуманных выводов вторая модель работает великолепно
Например, автор получает данные:
продажи выросли на 8%.
И пишет:
Это доказывает, что новая стратегия компании полностью изменила рынок.
Красиво.
Только ничего такого цифра не доказывает.
Независимый редактор довольно часто ловит такие скачки:
Из приведённых данных нельзя сделать этот вывод.
Вот тут второй ИИ очень полезен.
Потому что ошибка находится не в факте.
Цифра может быть абсолютно правильной.
Проблема в интерпретации.
То же самое с причинно-следственными связями:
После внедрения ИИ выросли продажи, следовательно, продажи выросли благодаря ИИ.
Не обязательно.
Может, одновременно снизили цену.
Запустили рекламу.
Наступил сезон.
Пришёл крупный клиент.
Одна модель легко протаскивает красивую причинность в текст.
Вторая, если специально попросить искать такие вещи, начинает портить праздник.
И правильно делает.
Потом появилась другая проблема: редактор хочет переписать всё
Знакомая история.
Даёшь модели хороший текст:
Найди ошибки.
Она возвращает:
Я подготовил улучшенную версию!
И вместо четырёх исправлений имеем полностью другую статью.
Поменялся стиль.
Пропали удачные фразы.
Появились новые факты.
Старые ошибки исчезли, зато возникли свежие.
Поэтому роль редактора пришлось ограничивать очень жёстко.
Не:
отредактируй.
А:
не переписывай текст; перечисли конкретные проблемы и объясни, что необходимо изменить.
Это принципиальная разница.
Редактор выдаёт диагноз.
Автор лечит.
Потому что иначе у нас начинается бесконечное поколение:
версия 1 → улучшенная версия → улучшенная улучшенная версия → финальная окончательная версия 7.
И каждый следующий этап способен заново сломать то, что уже работало.
Ещё полезнее стало заставлять критика цитировать проблемное место
Не буквально длинными цитатами, а указывать конкретный фрагмент.
Например:
Проблема 3. В абзаце «Роботы полностью вытеснят людей со складов…» вывод слишком категоричный. Приведённые данные показывают рост автоматизации, но не доказывают полное вытеснение работников.
Вот это уже хорошая задача на исправление.
Автору не нужно заново переосмысливать всю статью.
Он знает:
вот проблемный кусок;
вот причина;
вот ограничение.
После такого точечного задания модели обычно исправляют материал гораздо аккуратнее.
А потом я добавил финального контролёра
Логика была такая.
Редактор нашёл пять ошибок.
Автор говорит:
Всё исправил.
Кто это проверит?
Если поверить автору, мы опять вернулись в начало.
Поэтому появляется третий участник.
Он получает:
исходные замечания;
исправленную статью.
И проверяет:
замечание №1 выполнено;
№2 выполнено;
№3 исправлено частично;
№4 не выполнено;
№5 выполнено.
Это неожиданно эффективная схема.
Потому что задача очень конкретная.
Не:
оцени прекрасность статьи по шкале от добра до совершенства.
А:
сделали то, что требовалось, или нет?
LLM вообще заметно лучше работают, когда критерий проверки можно сформулировать однозначно.
Вот почему мне не нравятся оценки вида «текст на 92 балла»
Хотя сам я их тоже использую.
😁
Оценка удобна как быстрый индикатор.
Но сама по себе:
92/100
почти ничего не объясняет.
Почему 92?
Почему не 89?
Что конкретно надо изменить, чтобы стало 95?
Гораздо полезнее структура:
фактическая надёжность — есть проблема;
логика — нормально;
повторы — найден один;
стиль — соответствует;
обязательный тезис №3 пропущен.
А уже поверх этого можно вывести общий балл для оркестратора.
Человеку приятнее видеть цифру.
Машине полезнее видеть условие.
Самое важное — модели должны быть действительно независимыми по роли
Представьте такой диалог:
— Напиши текст.
— Готово.
— Теперь будь редактором и проверь его.
— Проверил.
— Теперь будь строгим контролёром.
— Проверил ещё раз.
Технически мы использовали три роли.
Фактически всё время разговаривали с одной системой в одном контексте.
Она уже знает, почему написала именно так.
Гораздо интереснее дать текст новой модели без истории его создания.
Она не видит рассуждения автора.
Не знает, что тот пытался сделать.
Перед ней только результат и правила.
Это приближает проверку к независимой.
Ещё лучше, когда роли выполняют разные семейства моделей.
Не потому что одна обязательно умнее другой.
У них просто отличаются сильные и слабые стороны.
Одна отлично держит длинную структуру.
Другая прекрасно чувствует стиль.
Третья хорошо замечает противоречия.
Вот из этого уже получается маленькая редакционная команда.
Но больше моделей не значит лучше
Я пробовал логически раскручивать эту конструкцию дальше.
Если два проверяющих лучше одного, поставим четыре.
Потом арбитра.
Потом проверяющего арбитра.
А потом, видимо, Верховный суд нейросетей.
Проблема очевидна.
Каждый дополнительный этап:
увеличивает стоимость;
занимает время;
добавляет новую возможность ошибиться;
может начать спорить о вкусовщине;
иногда возвращает уже исправленную проблему.
В какой-то момент прирост качества становится меньше прироста сложности.
Поэтому сейчас мне гораздо ближе короткий конвейер:
автор → независимый редактор → исправление → финальная проверка.
Для большинства задач этого достаточно.
А дополнительные этапы нужны только там, где цена ошибки выше.
Для исторической статьи и художественного рассказа проверки вообще разные
Это тоже быстро выяснилось.
Представим художественный текст.
Критик пишет:
Нельзя подтвердить источник утверждения героя о том, что он ненавидит соседа.
Спасибо.
Очень полезно.
😁
Для художественного материала важны:
канон;
мотивация персонажей;
логика событий;
повторы;
голос;
темп;
соответствие предыдущим эпизодам.
А для статьи:
факты;
источники;
структура;
точность выводов;
соответствие теме.
Поэтому универсальный промпт:
Проверь качество текста.
слишком расплывчатый.
Сначала надо решить:
Что именно в этом типе текста считается ошибкой?
И только потом выпускать контролёра.
Код тоже должен проверять ИИ
Вот это, пожалуй, один из самых важных выводов.
Нейросеть прекрасно может проверить:
логично ли раскрыта тема.
Но зачем спрашивать её:
статья длиннее 5000 знаков?
Python посчитает точнее.
Нужно проверить:
есть ли обязательное поле в JSON?
Код.
Правильный ли формат ссылки?
Код.
Есть ли запрещённая фраза?
Код.
Совпадает ли количество элементов?
Код.
Не повторился ли один абзац дважды?
Во многих случаях опять код.
Модель имеет смысл использовать там, где требуется смысловая оценка.
Всё, что можно проверить детерминированно, лучше проверять обычной программой.
Это дешевле.
Быстрее.
И главное — программа не ответит:
На мой взгляд, здесь примерно шесть элементов.
Она просто посчитает.
В итоге ошибок стало меньше. Но не потому, что модели «договорились»
Вот это главный вывод моего эксперимента.
Я сначала представлял систему примерно так:
одна нейросеть сказала А;
другая Б;
третья рассудила, кто прав.
На практике лучший результат получился совсем из другого.
Каждому участнику нужно дать узкую ответственность.
Автор отвечает:
за создание текста.
Редактор:
за поиск конкретных проблем.
Фактчекер:
за проверку утверждений по источникам.
Автор исправлений:
за точечное выполнение замечаний.
Финальный контролёр:
за принятие результата по заранее установленным критериям.
А программа проверяет всё, для чего интеллект вообще не нужен.
Получается не совет мудрецов.
Получается обычный производственный процесс.
И мне кажется, именно так будут работать серьёзные ИИ-системы
Не один огромный волшебный агент:
Я умею всё!
А набор довольно скучных специализаций.
Один читает.
Другой пишет.
Третий проверяет.
Четвёртый ищет расхождения.
Код контролирует формат.
Человек определяет правила игры.
Очень похоже на нормальную компанию.
Только совещаний меньше.
Хотя если дать агентам возможность бесконечно обсуждать друг друга, они и это быстро исправят.
😁
Я постепенно переношу именно такой подход в свои реальные автоматизации: не доверять одной генерации только потому, что она красиво написана, и не заставлять автора принимать собственную работу. На практике независимый контроль оказался намного полезнее очередного усложнения промпта.
За такими экспериментами и тем, как я собираю рабочие ИИ-конвейеры, можно следить в GPT-Лаборатории в Telegram или ВК.
Потому что следующий интересный вопрос уже не:
может ли ИИ проверить другой ИИ?
Может.
Гораздо важнее другое:
кто проверит их обоих, когда они очень уверенно ошиблись одинаково?
