Подойдёт, если:
вы уже умеете писать структурные промты, но хотите исключить «уверенную неправду»: снизить выдумки, научить ИИ честно говорить «не знаю», маркировать допущения и аккуратно работать с фактами.
Самая опасная ошибка при работе с ИИ — не “вода” и не “кривая структура”. Самая опасная — уверенная неправда. Когда ответ звучит убедительно, но факты там придуманы. И беда в том, что на глаз это не всегда видно — особенно в маркетинговых и информационных текстах, где модель легко добавляет “красивые цифры”, “типовые кейсы” и “как будто реальные” ссылки.


вы уже умеете писать структурные промты, но хотите исключить «уверенную неправду»: снизить выдумки, научить ИИ честно говорить «не знаю», маркировать допущения и аккуратно работать с фактами.
использовать протокол «Факты / Предположения / Неизвестно / Что спросить дальше», включать self-check перед выдачей ответа и настраивать «честный режим» — без придуманных цифр, кейсов и ссылок.
продакшен-инженерии: подключение базы знаний (RAG), вызов инструментов/API, мониторинг и A/B-тесты, PromptOps-процессы и полноценный набор метрик качества.
Эта статья — про практику: как заставить ИИ работать в честном режиме, маркировать допущения и проверять себя перед выдачей результата.
Под “галлюцинациями” обычно понимают “ИИ придумал факт”. Но в реальности они бывают разными:
Чем более “деловым” выглядит ответ, тем легче его принять на веру. Поэтому нужен протокол.
Есть несколько причин, которые повторяются постоянно:
Это не “поломка”. Это поведение по умолчанию. Наша задача — поменять режим.
Отделяйте факты от предположений. Это один из самых надёжных способов снизить выдумки и получить результат, который не стыдно публиковать.
Правило звучит так: факты — отдельно, предположения — отдельно. Если модель что-то додумала “по умолчанию”, это должно быть явно помечено, а не спрятано в тексте как будто это истина.
Универсальный формат, который почти всегда спасает ситуацию, состоит из четырёх частей. Факты — это только то, что вы дали во входных данных. Предположения — то, что модель добавляет как типовой вариант, когда информации не хватает. Неизвестно — вещи, которые нельзя утверждать без дополнительных данных. И наконец что спросить дальше — 1–3 уточняющих вопроса, которые закрывают главные пробелы.
Если вы готовите материал к публикации, такой формат часто работает лучше любого запроса “будь точным”, потому что он заставляет модель показывать границу между данными и догадками.
“Не знаю” — это не отказ. Это нормальная точка контроля.
Хороший протокол выглядит так:
Пример: “В тексте нет данных о сроках и цене, поэтому я не буду их указывать. Уточните: срок разработки (1–2 / 2–4 / 4–8 недель) и есть ли фиксированная стоимость. Если не знаете — сделаю версию без цифр.”

Self-check — это не “внутренние рассуждения”. Это просто контроль по чек-листу перед финальным ответом.
Мини-чек-лист:
Когда в тексте появляются цифры, цены или сроки. Любая конкретика такого типа без проверки — прямой путь к “уверенным данным из воздуха”.
Также self-check нужен, если вы даёте обещания результата. Даже мягкие формулировки могут незаметно превратиться в гарантию, а это уже риск.
Отдельный случай — публикация от имени компании. Здесь цена ошибки выше: текст воспринимают как официальную позицию, и “неточность” легко становится репутационной проблемой.
Self-check обязателен, когда вы добавляете ссылки или источники. Если источник не был дан, модель может “сгенерировать” его видимость — это нужно отсекать на входе.
И наконец, self-check нужен при любых юридически чувствительных формулировках: ответственность, условия, гарантии, возвраты, соответствие требованиям и любые заявления, которые могут быть истолкованы как обязательство.
Простая установка, которую лучше прописывать в промте:
И отдельное правило для кейсов:
“Если кейсы не предоставлены — не придумывай кейсы. Предложи шаблон кейса или вопросы для сбора данных.”