TL;DR
Когда ты просишь LLM что-то порекомендовать — книгу, фильм, ресторан, стратегию — а в твоём запросе не хватает данных, есть противоречие или невозможный критерий, модель не заметит проблему и просто выдумает ответ. Исследователи создали тест из 4623 запросов с "поломанными" условиями в пяти областях (фильмы, новости, рестораны, товары, книги) и проверили, замечают ли 11 LLM подвох перед тем, как дать совет.
Главная находка: модели почти никогда не замечают, что данных просто не хватает. Если запрос явно противоречит сам себе или спрашивает о невозможном — модель это ловит в 60-77% случаев. Но если запрос просто "недосказан" (например: "посоветуй книгу с крупным шрифтом", а у модели нет данных о размере шрифта книг) — она находит проблему всего в 10% случаев. Вместо вопроса "уточни, что тебе важно" модель тихо выдумывает подходящий ответ, потому что недосказанный запрос выглядит как обычный.
Метод решения простой: явно попросить модель сначала проверить предпосылки запроса по чек-листу (хватает ли данных, нет ли противоречий, реально ли проверить критерий, не выходит ли запрос за возможности модели) — и только потом отвечать. Плюс два побочных инсайта: заваливать модель лишним контекстом не помогает точности проверки, а слишком долгие размышления (extended thinking) даже снижают качество критики после определённой точки.
Схема метода (адаптация инсайта в промпт-приём)
ШАГ 1: Перед ответом модель проверяет запрос по 4 категориям ошибок → находит проблему или нет
U — недостаточно данных для точного ответа
I — противоречие (в самом запросе или с тем, что уже известно)
X — критерий, который невозможно проверить
B — запрос выходит за границы возможностей модели
ШАГ 2: Если проблема найдена → модель называет её и уточняет/предупреждает, НЕ выдумывая данные
ШАГ 3: Если проблем нет → модель даёт обычную рекомендацию
Все шаги — в одном промпте, один запрос.
Пример применения
Задача: Ты просишь ChatGPT или Яндекс GPT подобрать фильм под очень конкретные условия.
Промпт (без техники, как обычно):
Посоветуй фильм с Кинопоиска: рейтинг выше 9.2, длительность до 90 минут,
снят после 2022 года, в жанре триллер.
Что происходит без техники: модель, скорее всего, назовёт 2-3 фильма и уверенно припишет им рейтинг и хронометраж — даже если реально не может проверить эти цифры в момент ответа. Она "услужливо" закроет пробел, а не спросит "у меня нет доступа к актуальному рейтингу Кинопоиска, уточни источник или сними это условие".
Промпт с техникой:
Прежде чем дать рекомендацию, проверь мой запрос:
1. Недостаточность — хватает ли тебе данных, чтобы дать точный ответ?
2. Противоречие — не спорят ли условия друг с другом?
3. Непроверяемость — можешь ли ты реально подтвердить каждый критерий,
или это то, что у тебя нет доступа проверить?
4. Границы — не выходит ли запрос за рамки того, что ты можешь достоверно оценить?
Если находишь проблему — скажи о ней прямо и не выдумывай данные,
которых у тебя нет. Только после этого, если всё чисто, дай рекомендацию.
Мой запрос: Посоветуй фильм с Кинопоиска: рейтинг выше 9.2, длительность
до 90 минут, снят после 2022 года, в жанре триллер.
Результат: модель сначала явно скажет, что не может проверить актуальный рейтинг Кинопоиска в реальном времени (это X — непроверяемый критерий), предложит либо снять это условие, либо дать ориентировочный список с пометкой "рейтинг мог измениться и нужно проверить самостоятельно" — вместо того, чтобы уверенно приписать фильмам цифры, которых модель не знает.
Почему это работает
LLM обучены быть полезными и услужливыми — это их сильная сторона превращается в слабость, когда запрос неполный. Модель предпочитает дать хоть какой-то ответ, а не признать, что данных недостаточно, потому что молчание или уточняющий вопрос воспринимается как "менее полезный" ответ во время обучения.
Явный чек-лист предпосылок работает, потому что превращает "невидимую" проверку в обязательный шаг перед ответом. Модель хорошо умеет следовать явным инструкциям в моменте — она просто не делает это сама по умолчанию. Заставляя её явно назвать категорию проблемы (недостаточность, противоречие, непроверяемость, граница), ты убираешь возможность "тихо проскочить" мимо пробела в данных.
Рычаги управления: - Если хочешь более мягкий тон — замени "не выдумывай данные" на "явно помечай предположения как предположения". - Если работаешь с фактическими темами (цены, характеристики, доступность) — усиливай пункт про непроверяемость, там модели чаще всего выдумывают. - Если задача творческая/субъективная (советы по стилю, идеи для текста) — пункт про недостаточность важнее противоречий, там модели теряются реже, но недосказанность съедают чаще.
Шаблон промпта
Прежде чем ответить на мой запрос, проверь его по четырём пунктам:
1. НЕДОСТАТОЧНОСТЬ: хватает ли тебе информации, чтобы дать точный
и обоснованный ответ на {задача}? Что важное не указано?
2. ПРОТИВОРЕЧИЕ: не противоречат ли условия запроса друг другу или
тому, что ты уже знаешь из нашего разговора?
3. НЕПРОВЕРЯЕМОСТЬ: есть ли в запросе критерий, который ты не можешь
реально подтвердить (актуальные данные, точные цифры, факты без
доступа к проверке)?
4. ГРАНИЦЫ: не выходит ли запрос за рамки того, что ты можешь
достоверно оценить или сделать?
Если находишь проблему по любому пункту — назови её прямо и предложи
уточнение или альтернативу. НЕ выдумывай данные, которых у тебя нет.
Только если проблем нет — переходи к ответу.
Мой запрос: {запрос}
Подставь в {задача} и {запрос} — свою реальную формулировку.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки предпосылок запроса перед ответом. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие данные у неё реально есть по твоей теме и какие критерии в твоём запросе могут быть непроверяемыми — потому что без этого чек-лист превратится в формальность, а не в реальную проверку.
Ограничения
⚠️ Недосказанность ловится хуже всего: даже с явной инструкцией проверять предпосылки, модели гораздо хуже замечают "у меня просто не хватает данных", чем явное противоречие. Чек-лист снижает проблему, но не убирает её полностью — расплывчатый запрос всё ещё маскируется под обычный.
⚠️ Не заваливай контекстом: если даёшь модели много фоновой информации "на всякий случай", это не повышает точность проверки — лучше оставить только то, что прямо относится к запросу.
⚠️ Длинные рассуждения не всегда лучше: если просишь модель "подумать подольше" (режим расширенных размышлений), качество проверки предпосылок растёт только до определённой точки, а потом падает — модель начинает переусложнять и путается.
Как исследовали
Исследователи взяли пять реальных наборов данных о рекомендациях — фильмы (MovieLens), новости (MIND), рестораны (Yelp), товары (Amazon), книги (Goodreads) — и для каждого сгенерировали пары запросов: чистый (решаемый) и "испорченный" одной из десяти ошибок в предпосылке. Всего получилось 4623 проверенных примера после отсева и ручной чистки.
Каждый ответ 11 моделей (GPT-5.5, Claude, Gemini, DeepSeek, Qwen, Llama и другие) проверяли три независимых LLM-судьи, а надёжность их оценок дополнительно проверили люди на 500 ответах — совпадение с судьями составило 82,6%. Отдельно прогнали контрольную группу из чистых запросов без ошибок — модели почти не поднимали ложную тревогу (0,55%), но при этом реальные ошибки пропускали почти в половине случаев.
Самое неожиданное: тип ошибки сильно влияет на результат. Явные противоречия и невозможные критерии модели замечают в 60-77% случаев, а вот "просто неполный" запрос — только в 10%. Это и натолкнуло авторов на главный вывод: проблема не в том, что модель не умеет разбираться с ошибкой, а в том, что она не замечает её вообще, когда ошибка выглядит тихо и незаметно.
Ресурсы
RPCBench, Zhongru Chen, Yuan Wu, Yi Chang — Jilin University. Код: github.com/ZhongruChen/RPCBench