Наша самая дорогая модель набрала 6 из 12. Не Haiku. Не Sonnet. Opus — флагман — показал худший результат во всей серии экспериментов, когда получил сложную задачу без шага верификации. Модель среднего уровня с инструкцией «перечитай и удали всё, что не можешь доказать» — 11.

То, как вы спрашиваете, важнее, чем у кого вы спрашиваете. И самое эффективное изменение — не лучший шаблон prompt, не более продвинутый фреймворк и не более дорогая модель. Это отдельный шаг с инструкцией: «Вернись и удали всё, в чём не уверен».

Эксперимент

Мы построили H-MATRIX: 23 эксперимента, тестирующих комбинации структуры prompt (plain vs. атомарный), уровня модели (Haiku, Sonnet, Opus) и верификации (есть/нет) — на трёх типах задач:

  • Code review производственного bash-скрипта с известными багами
  • Генерация контента для Telegram-канала с проверяемыми фактами
  • Разработка — поиск и исправление всех экземпляров конкретного паттерна бага

Каждый эксперимент оценивался по запечатанному эталону по шкале 0-12 (четыре измерения, 0-3 каждое). Оценщик не видел, какая конфигурация породила какой результат. В сочетании с 36 предыдущими экспериментами той же программы исследования VERIFY и 4 экспериментами расширенной валидации на новых типах задач, датасет охватывает 63 эксперимента в трёх сериях.

КонфигурацияCode ReviewКонтентDev
Plain prompt, без verify71011
Plain prompt + verify91011
Structured prompt, без verify111010
Structured prompt + verify111212
Structured + Opus + verify12——
Structured + Haiku + verify80 (отказ)10
3-агентная команда + verify91012

Два паттерна бросаются в глаза.

Третья серия — Пробелы Менделеева — тестировала четыре дополнительных типа задач: security audit (11.5/12), архитектурные решения (12/12), рефакторинг (9/12) и стратегические решения (10/12). Средний результат с верификацией: 10.6/12. Паттерн воспроизводился на каждом типе задач, который мы проверяли.

Эффект синергии

На контенте и разработке ни структурированные prompt-ы, ни верификация по отдельности не помогали. Plain + verify = 10 и 11. Structured + без verify = 10 на обоих. Но в сочетании они давали идеальный результат — 12 из 12 на обоих задачах.

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

Code review повёл себя иначе: структура одна подняла результат с 7 до 11. Верификация сверху ничего не добавила. Почему? Потому что code review по своей природе фальсифицируем — смотришь на код и видишь, реальная ли находка. В задаче встроена собственная верификация.

У контента и разработки этой встроенной проверки нет. Можно написать правдоподобный абзац с выдуманной статистикой и не заметить это, пока кто-то не спросит «а источник?». Именно это и перехватывает шаг верификации.

Больше агентов — хуже результат

Это был некомфортный вывод.

ЗадачаSolo (structured + verify)3-агентная команда
Code Review119
Контент1210
Dev1212

Команды сравнялись с одиночным агентом только на самой механической задаче (поиск паттерна бага). На всём, что требует суждения — калибровка серьёзности в code review, соответствие редакционному голосу в контенте — команды активно снижали качество.

Механизм оказался показательным. В code review ложноположительное утверждение о bash heredoc expansion — ловушка, которую наш эталон явно пометил как известную — распространилась через оба мультиагентных эксперимента. В обоих случаях слой оркестрации обрезал контекстное окно, удалив предупреждение, которое предотвратило бы ошибку. Агенты не смогли независимо верифицировать утверждение, потому что потеряли знание, необходимое для его фальсификации.

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

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

Парадокс Opus

Наш самый контринтуитивный результат: в предыдущей серии экспериментов Opus без верификации набрал 6/12 — худший результат в обеих сериях. Sonnet с верификацией — 11/12. Haiku с верификацией — 10/12 на задачах разработки.

Инверсия разительная: модель, стоящая в 5-10 раз дешевле, превзошла флагман на 5 баллов — просто добавив шаг верификации.

Более мощная модель делает не меньше ошибок. Она делает более убедительные. Большая мощность — большая беглость речи, а значит, более связно звучащие ошибки. С верификацией Opus восстановился до 12/12 — единственный идеальный результат в code review. Без неё беглость стала обузой.

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

Почему это происходит

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

Ключевое слово — отдельный. Дописать «пожалуйста, перепроверь» в конец prompt-а не помогает — модель уже смещена в сторону своего вывода. В нашей предыдущей серии добавление «и верифицируй свои находки» в конец prompt-а дало 8/12 — столько же, сколько без верификации. Структурно отдельная секция VERIFY дала 11/12. Та же модель, та же задача. Единственное отличие — встроена или отделена верификация.

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

Что реально работает

После 63 экспериментов в трёх сериях оптимальная конфигурация до неловкости проста:

  1. Structured prompt — скажи модели, что делать, в каком порядке и как оценивать качество
  2. Sonnet — модель среднего уровня
  3. Шаг верификации — «Перечитай свой вывод. Удали любую находку, которую не можешь отследить до конкретных доказательств.»

Никаких роёв агентов. Никакой инъекции навыков. Никаких дорогих моделей. Эта конфигурация набирала 11-12/12 на каждом типе задач, который мы тестировали.

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

Паттерн внешнего критика

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

Generate → (context break) → Evaluate → Output

Разрыв контекста может быть:

  • Отдельным API-вызовом только с выводом и критериями оценки
  • Другой моделью, оценивающей вывод первой
  • Структурированной секцией VERIFY, которая явно просит модель перечитать и удалить

Где мы ошиблись

Наши предсказания оказались верными в 4 случаях из 11. Мы ожидали, что верификация поможет везде одинаково (она синергична со структурой). Мы ожидали, что команды превзойдут одиночных агентов (они не превосходят на однофайловых задачах). Самая важная находка — синергия структуры и верификации — была совершенно непредсказана. Она вышла из данных, не из теории. Интуиция о поведении LLM ненадёжна, даже для тех, кто работает с этими системами ежедневно.

Ограничения, о которых мы говорим открыто: каждая конфигурация тестировалась один раз (N=1). Оценщик также создавал эталон — это вносило возможное смещение, несмотря на слепое тестирование. Командные эксперименты использовали слой conductor, который обрезал контекст — деградация команды может частично отражать баг реализации, а не фундаментальное свойство мультиагентных систем.

Попробуй сегодня

  1. Возьми свой самый важный LLM pipeline
  2. Добавь шаг верификации после генерации: «Перечитай свой вывод. Для каждого утверждения найди доказательство. Удали любое утверждение, где доказательство неоднозначно.»
  3. Измерь разницу

Единственное, что дороже добавления шага верификации — это его отсутствие.

Эта статья основана на трёх сериях экспериментов: H-MATRIX (23 эксперимента), предыдущее исследование VERIFY (36 экспериментов) и расширенная валидация Пробелов Менделеева (4 эксперимента) — все проведены в январе-феврале 2026 года в рамках проекта Aletheia. Все данные экспериментов, эталонные файлы и рубрики оценки доступны в директории исследований проекта.