Александр Казьмин пишет:

Почему LLM «выдумывают» рекомендации

RPCBench

Что это за метод?

* **Цель:** заставить модель проверить, есть ли в запросе ошибки (недостаточность данных, противоречия, непроверяемость критериев, выход за границы возможностей), прежде чем выдавать совет. * **Ключевой шаг:** добавить к запросу чек‑лист из четырёх пунктов и попросить модель явно назвать найденную проблему.

Как работает алгоритм

1. **Проверка запроса** – модель отвечает только после того, как пройдёт через чек‑лист: * **U (Недостаточность)** – хватает ли информации? * **I (Противоречие)** – противоречат ли условия друг другу или уже известным фактам? * **X (Непроверяемость)** – можно ли реально подтвердить каждый критерий? * **B (Границы возможностей модели)** – не выходит ли запрос за рамки того, что модель может достоверно оценить? 2. **Результат проверки** * Если найдена проблема → модель сообщает её и предлагает уточнение/альтернативу без выдумывания данных. * Если проблем нет → выдаётся обычная рекомендация.

Пример применения

> **Задача:** посоветовать фильм с конкретными условиями. > **Промпт (с техникой):**

Прежде чем ответить, проверь мой запрос по четырём пунктам: 1. НЕДОСТАТОЧНОСТЬ: хватает ли тебе данных? 2. ПРОТИВОРЕЧИЕ: противоречат ли условия друг другу? 3. НЕПРОВЕРЯЕМОСТЬ: можешь ли ты подтвердить каждый критерий? 4. ГРАНИЦЫ: не выходит ли запрос за твои возможности? Если найдёшь проблему, назови её и предложи уточнение. Не выдумывай данные. Мой запрос: Посоветуй фильм с Кинопоиска: рейтинг > 9.2, длительность ≤ 90 мин, снят после 2022 г., жанр – триллер.

> **Ответ модели:** > *Проблема X:* «У меня нет доступа к актуальному рейтингу Кинопоиска в реальном времени». > *Предложение:* «Сними условие о точном рейтинге или уточни, что рейтинг может измениться».

Шаблон для копирования

Прежде чем ответить на мой запрос, проверь его по четырём пунктам: 1. НЕДОСТАТОЧНОСТЬ: хватает ли тебе информации, чтобы дать точный и обоснованный ответ на {задача}? Что важное не указано? 2. ПРОТИВОРЕЧИЕ: не противоречат ли условия запроса друг другу или тому, что ты уже знаешь из нашего разговора? 3. НЕПРОВЕРЯЕМОСТЬ: есть ли в запросе критерий, который ты не можешь реально подтвердить (актуальные данные, точные цифры, факты без доступа к проверке)? 4. ГРАНИЦЫ: не выходит ли запрос за рамки того, что ты можешь достоверно оценить или сделать? Если находишь проблему по любому пункту – назови её прямо и предложи уточнение/альтернативу. НЕ выдумывай данные, которых у тебя нет. Только если проблем нет — переходи к ответу. Мой запрос: {запрос}

*Подставьте `{задача}` и `{запрос}` под вашу конкретную задачу.*

Ограничения и риски

| Пункт | Что может пойти не так | | **Недосказанность** | Модель почти никогда не замечает, что данных просто нет (≈10 %). Чек‑лист помогает, но не устраняет полностью. | | **Слишком много контекста** | Добавление лишней информации «на всякий случай» не повышает точность проверки и может запутать модель. | | **Длинные размышления** | В режиме extended thinking качество проверки падает после определённого момента – лучше ограничиться 1‑2 короткими шагами. |

Ключевые выводы из экспериментов

* **Проверка противоречий и невозможных критериев:** обнаруживается в 60–77 % случаев. * **Неполные запросы (U):** обнаруживаются только в ~10 %. * **Контрольная группа чистых запросов:** ложные тревоги почти не поднимаются (0,55 %).