TL;DR
VibeCheck — метод оценки контента, который создаёт ИИ, через пять отдельных критериев качества плюс перекрёстную проверку, где каждый агент оценивает работу других, но никогда — свою собственную. В оригинале метод применили к юнит-тестам кода, но логика годится для любой оценки AI-сгенерированного материала.
Главная находка: то, что "работает" — не значит "качественно". Тесты запускались без ошибок и даже проходили проверку, но при детальном разборе оказывались пустыми: проверяли только "не пустое значение", забывали крайние случаи, тянули общие данные между тестами, из-за чего результаты могли меняться от запуска к запуску. Поверхностная проверка ("выполнилось / не выполнилось") пропускает ровно те проблемы, которые вскрываются глубже. То же самое легко происходит с любым AI-текстом: план звучит убедительно, но не проверен по частям.
Суть метода — заменить один общий вопрос "хорошо получилось?" на рубрику из пяти конкретных критериев, и заставить оценивать не автора самого себя, а других — по схеме "исключи себя из проверки своей же работы" (leave-one-out).
Схема метода
ШАГ 1: Генерация контента → строгий промпт с ограничениями (не придумывать, не менять исходники) → чистый результат без пояснений
ШАГ 2: Перекрёстная оценка (отдельные запросы к другим агентам/чатам) → каждый оценщик проверяет ТОЛЬКО чужие результаты, не свои
ШАГ 3: Оценка по 5 критериям (0-5 баллов каждый) + список конкретных проблем + уверенность оценщика → в формате структурированного отчёта
ШАГ 4: Усреднение оценок от нескольких независимых оценщиков → финальный балл + список слабых мест
Все шаги — отдельные запросы (к разным чатам или к одному чату с явным разделением ролей).
Пример применения
Задача: Маркетолог просит три разные нейросети (или три отдельных чата) написать текст для рекламной рассылки нового банковского продукта. Все три текста звучат убедительно — но какой реально сработает?
Промпт (для оценки каждого варианта):
Ты — строгий оценщик маркетинговых текстов.
Тебе дан контекст (описание продукта, аудитория, тон бренда) и один текст рассылки.
Оцени текст ТОЛЬКО на основе контекста, не придумывай преимущества, которых нет в описании продукта.
Ты ОБЯЗАН:
- Проверить, есть ли в тексте конкретные факты или только общие фразы
- Оценить, закрывает ли текст типичные возражения клиента (цена, надёжность, простота)
- Найти риски: обещания, которые продукт не подтверждает
- Указать, что мешает читателю дочитать до конца
- Дать конкретные правки
Рубрика (0-5 баллов по каждому):
- R1 Конкретность (факты vs общие слова)
- R2 Убедительность аргументов
- R3 Покрытие возражений клиента
- R4 Соответствие тону бренда
- R5 Читаемость и структура
Выведи отчёт: баллы по каждому пункту, найденные проблемы, конкретные правки, итоговая оценка, твоя уверенность в оценке (0-100%).
КОНТЕКСТ ПРОДУКТА: {вставить описание}
ТЕКСТ ДЛЯ ОЦЕНКИ: {вставить один из трёх вариантов}
Результат: Модель выдаст структурированный отчёт по каждому из пяти критериев с конкретными баллами, списком слабых мест (например: "текст обещает кэшбэк, но не указывает условия — риск претензий"), предложенными правками и уровнем своей уверенности в оценке. Если прогнать так все три текста через оценку двумя разными моделями (каждая оценивает чужие тексты, не свой), получите более честную картину, чем субъективное "нравится/не нравится".
Почему это работает
LLM склонны давать поверхностную общую оценку — "выглядит хорошо" — потому что не проверяют каждый аспект отдельно, если их не попросить явно. Это то же самое, что спросить человека "как тебе фильм?" вместо "как тебе сценарий, актёрская игра, монтаж, музыка отдельно?" — второй вопрос вытаскивает куда больше деталей.
Сильная сторона LLM — она хорошо ищет конкретные недостатки, если дать чёткий список, что искать (это как разница между "проверь код" и "проверь: работает ли без ошибок, есть ли проверка на пустые данные, повторяется ли код").
Метод использует эту сильную сторону дважды: рубрика заставляет искать проблему в каждом измерении по отдельности, а правило "не оценивай своё" убирает известную слабость — модели склонны хвалить свой же текст выше, чем чужой (даже без злого умысла, просто потому что видят логику своего решения "снаружи").
Рычаги управления: - Число критериев в рубрике → можно сократить до 3 для простых задач, экономия времени - "Без объяснений" в промпте генерации → убери, чтобы видеть логику черновика - Confidence score (уверенность оценщика) → полезен, когда сравниваешь несколько оценок и хочешь понять, где модель сама не уверена - Diagnostic signals (конкретные проблемы + предложенные правки) → можно заменить на любой список типичных ошибок для своей задачи
Шаблон промпта
ГЕНЕРАЦИЯ:
Тебе дан контекст: {описание задачи/проекта/продукта}.
Создай {что создать} со следующими ограничениями:
- Используй только информацию из контекста, не придумывай факты
- Следуй существующему стилю/формату
- Сфокусируйся на {конкретных требованиях}
Выведи только результат, без пояснений.
ОЦЕНКА (отдельный запрос, другой чат/модель):
Ты — строгий оценщик {тип контента}.
Тебе дан контекст и один результат для проверки.
Оцени результат ТОЛЬКО на основе контекста, не додумывай за автора.
Ты ОБЯЗАН:
- {критерий проверки 1}
- {критерий проверки 2}
- {критерий проверки 3}
Рубрика (0-5 баллов каждый):
- R1 {критерий 1}
- R2 {критерий 2}
- R3 {критерий 3}
- R4 {критерий 4}
- R5 {критерий 5}
Выведи: баллы по каждому пункту, найденные проблемы, конкретные правки, итоговый балл, твоя уверенность (0-100%).
КОНТЕКСТ: {вставить}
РЕЗУЛЬТАТ ДЛЯ ПРОВЕРКИ: {вставить}
🚀 Быстрый старт — вставь в чат:
Вот шаблон оценки VibeCheck: пятимерная рубрика + честная проверка без самооценки.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие именно пять критериев важны для твоей задачи и что считать проблемой — потому что рубрика работает только если критерии конкретные, а не общие ("хорошо/плохо").
Ограничения
⚠️ Нужно несколько независимых источников. Если один и тот же чат генерирует и оценивает — правило "не оценивай себя" не работает, смысл теряется.
⚠️ Метод находит проблемы, но не решает их сам. Рубрика показывает, где слабое место, но исправление — отдельный шаг.
⚠️ Согласие оценщиков может быть иллюзией. Если несколько LLM основаны на одной базовой модели, их совпадающие оценки могут говорить не о правильности, а о том, что у них общий "взгляд на вещи" — это не гарантия объективности.
Как исследовали
Исследователи взяли 15 студенческих репозиториев на Python и JavaScript и заставили три ИИ-редактора кода (Kiro, Antigravity, Cursor) — все на одной модели Claude Sonnet 4.5 — генерировать юнит-тесты по одному и тому же строгому промпту: только по репозиторию, без внешних предположений. Baseline — та же модель Claude без обёртки редактора.
Каждый набор тестов затем оценивали три других агента по правилу leave-one-out — никто не проверял свою же работу — по пятибалльной рубрике из пяти измерений.
Главный вывод: тесты почти всегда запускались (высокая "runnability"), но проваливались по глубоким критериям — слабые проверки, пропущенные крайние случаи, общие данные между тестами. Это подтвердилось и для трёх редакторов, и для baseline-модели — значит, проблема не в конкретном инструменте, а в самой природе того, как модель генерирует "рабочий, но неглубокий" результат.
Любопытная деталь: согласие между оценщиками было неравномерным — Cursor и Kiro совпадали с базовой моделью чаще, а Antigravity — заметно реже, хотя все работают на одной модели. Значит, обёртка (как редактор организует контекст) сама по себе влияет на качество оценки, а не только базовая модель.