Короткий ответ

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

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

Что понадобится

Чтобы снизить долю выдуманных фактов, нужен не «волшебный промпт», а минимальный контур управления качеством. Даже для небольшой команды достаточно пяти элементов.

Источник истины. Это может быть утвержденная база знаний, набор внутренних документов, каталог товаров, API с актуальными данными или вручную отобранный корпус текстов.
Шаблон запроса. В нем должны быть правила ответа: на чем можно основываться, когда нужно отказаться, в каком формате возвращать результат.
Право на неопределенность. Если модель обязана отвечать любой ценой, она чаще заполняет пробелы догадками.
Проверка после генерации. Отдельный шаг, где сверяются факты, цитаты, числа, единицы измерения, даты и выводы.
Набор тестовых вопросов. Нужны вопросы с заведомо отсутствующими данными, устаревшими формулировками, конфликтующими источниками и ловушками на точность.

Элемент	Минимальная реализация	Зачем нужен
Источник истины	Папка с утвержденными документами или подключенная база	Убирает необходимость «вспоминать» факты из параметров модели
Шаблон промпта	Один стандартный запрос для типового класса задач	Снижает разброс поведения между операторами
Формат ответа	Поля: вывод, основание, ссылка на фрагмент, статус уверенности	Облегчает автоматическую и ручную проверку
Чек-лист проверки	5–7 пунктов для редактора или владельца процесса	Не дает пропустить очевидные ошибки
Тестовый набор	20–50 реальных и негативных вопросов	Позволяет сравнивать версии после изменений

Если у вас нет источника истины, методы ниже все равно помогут, но только для задач низкого риска: редактирование текста, суммаризация предоставленного материала, переписывание в другой стиль, извлечение сущностей из входного документа. Для ответов о внешнем мире без свежих данных они ограничены.

Пошаговый план

1. Разделите задачи по режимам

Не пытайтесь одним и тем же режимом обслуживать все сценарии. Минимум нужны два класса:

Фактические ответы. Важны точность, ссылки и воспроизводимость. Здесь модель должна говорить только по источникам.
Творческие или черновые задачи. Допустимы вариативность и предположения, но результат не должен маскироваться под проверенный факт.

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

2. Назначьте источник истины для каждого сценария

Для каждой категории запросов заранее определите, на чем модель имеет право основывать ответ. Это может быть конкретный реестр документов, внутренняя wiki, база тарифов, справочник API или набор страниц сайта.

Если источник не задан, модель будет опираться на вероятностные связи из обучения. Для практических задач это главный источник галлюцинаций. Поэтому хороший рабочий шаблон обычно звучит жестко:

Отвечай только на основе предоставленных материалов. Если в них нет достаточных данных, напиши: Недостаточно данных. Не додумывай факты, даты, цифры и ссылки. Для каждого ключевого утверждения укажи фрагмент источника.

Если используете поиск по документам, следите не только за качеством модели, но и за качеством извлечения фрагментов. Плохой поиск даст ложное ощущение контроля: ответ будет со ссылкой, но на нерелевантный кусок текста.

3. Разрешите модели отказываться и задавать уточняющие вопросы

Запрет на отказ почти всегда увеличивает количество выдумок. Модель должна иметь три безопасных выхода:

прямой отказ из-за отсутствия данных;
запрос уточнения, если вопрос неоднозначный;
разделение факта и предположения, если пользователь просит оценку.

Полезный шаблон:

Если вопрос двусмысленный, сначала задай до двух уточняющих вопросов. Если источники не подтверждают ответ, сообщи об этом явно. Не замещай отсутствие данных общими знаниями.

Это особенно важно для внутренних знаний компании, быстро меняющихся правил и всего, что зависит от даты. Чем чаще меняется домен, тем опаснее полагаться на память модели.

4. Сузьте формат ответа

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

Для рабочих сценариев удобно требовать четыре поля:

Краткий ответ.
Основание. Что именно в источнике это подтверждает.
Ссылка на фрагмент. Номер документа, раздел, строка или идентификатор записи.
Статус. Подтверждено, недостаточно данных, требуется уточнение.

Пример шаблона:

Верни результат в формате: 1) ответ; 2) подтверждающий фрагмент; 3) идентификатор источника; 4) статус. Если статус не Подтверждено, не формулируй категоричный вывод.

Для чисел и расчетов добавьте отдельное поле расчет, где видны формула, исходные величины и единицы измерения. Иначе модель часто пишет правдоподобное число без надежного происхождения.

5. Разделите генерацию и проверку

Не смешивайте создание текста и контроль качества в одном шаге. После генерации нужен второй проход: ручной или автоматический. Проверка должна отвечать не на вопрос «звучит ли убедительно», а на вопрос «все ли утверждения подтверждены».

Минимальный постпроцесс:

выделить фактические утверждения;
сопоставить каждое утверждение с источником;
проверить даты, числа, единицы и имена собственные;
пометить неподтвержденные фрагменты;
либо переписать ответ, либо заблокировать публикацию.

Если автоматизируете этот шаг, не просите вторую модель просто «оценить качество». Дайте ей узкую задачу: найти утверждения без опоры, проверить соответствие цитаты тезису, обнаружить противоречия между абзацами.

6. Тестируйте на плохих вопросах, а не только на красивых демо

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

В хороший тестовый набор входят:

вопросы, ответа на которые нет в базе;
вопросы с устаревшими формулировками;
вопросы, где в разных документах есть конфликт;
вопросы с похожими сущностями и риском перепутать объект;
вопросы с числами, диапазонами и единицами измерения;
провокационные просьбы «ответить наверняка» или «догадаться».

После каждого изменения промпта, модели, корпуса документов или логики поиска прогоняйте одинаковый набор вопросов заново. Иначе вы не заметите регрессию.

7. Зафиксируйте правила публикации

Даже хороший ответ модели не должен автоматически становиться официальным ответом компании, если это влияет на деньги, безопасность, права пользователя или выполнение регламента.

Полезно ввести простые стоп-правила:

не публиковать ответ без подтверждающего источника, если вопрос фактический;
не публиковать расчеты без формулы и исходных величин;
не публиковать советы по праву, медицине, налогам и безопасности без человека в контуре;
не объединять в один ответ подтвержденные факты и догадки без явной маркировки.

Если строите корпоративный процесс, полезно сверить его с OWASP Top 10 for LLM Applications и NIST AI Risk Management Framework. Эти материалы не дают готового промпта, но хорошо описывают риск-модель и контрольные точки.

Типичные ошибки

Лечить все одним промптом. Если у вас нет источника истины и режима отказа, даже очень аккуратная формулировка не спасет.
Требовать отвечать всегда. Принуждение к ответу любой ценой почти гарантирует догадки.
Смешивать факты и генерацию. Пользователь не должен угадывать, где факт, а где предположение.
Проверять только «на глаз». Убедительный текст легко маскирует неверные ссылки, даты и числа.
Не учитывать свежесть данных. Корректный ответ на прошлой неделе может быть неверным сегодня.
Давать слишком широкий контекст. Если в подложке есть противоречивые документы без приоритета, модель может выбрать любой.
Не фиксировать приоритет источников. Должно быть ясно, что важнее: регламент, база, FAQ, письмо, черновик.
Игнорировать логирование. Без журналов запросов трудно воспроизвести ошибку и понять, где возникла галлюцинация: в поиске, промпте или в самой генерации.
Путать отсутствие доказательства с доказательством отсутствия. Если в источниках ничего нет, честный результат — «недостаточно данных», а не категоричное отрицание.

Как проверить результат

Проверяйте не общую «впечатляющую умность» системы, а конкретные свойства ответа. Минимальный контроль можно провести за один рабочий цикл.

Соберите тестовый набор. Возьмите реальные запросы пользователей и добавьте негативные случаи, где модель должна отказаться.
Определите ожидаемое поведение. Для каждого вопроса заранее решите: нужен точный ответ, уточнение или отказ.
Проверьте подтверждаемость. Каждое ключевое утверждение должно опираться на конкретный фрагмент источника.
Проверьте точность сущностей. Имена, даты, номера договоров, коды продуктов и единицы измерения должны совпадать с источником без нормализации «по смыслу».
Проверьте устойчивость. Переформулируйте вопрос несколькими способами и убедитесь, что поведение не меняется радикально.
Зафиксируйте регрессию. Если после изменения промпта или модели выросло число неподтвержденных утверждений, откатите изменение или доработайте процесс.

Сценарий	Что обязательно требовать	Когда блокировать ответ
Ответ по внутренним документам	Ссылка на документ и раздел для каждого правила	Есть утверждение без подтверждения или ссылка не совпадает с тезисом
Ответ с числами	Исходные данные, формула, единицы измерения	Число есть, а происхождение не показано
Текущие внешние факты	Актуальный источник и дата проверки	Источник старый или не указан
Высокорисковые темы	Человеческая проверка и явное ограничение роли ИИ	Ответ идет напрямую пользователю без ревью
Суммаризация предоставленного текста	Отсутствие новых фактов, которых не было во входе	В summary появились детали не из исходного документа

Хороший практический критерий прост: если редактор или владелец процесса не может за минуту понять, откуда взялось ключевое утверждение, значит ответ еще нельзя считать надежным.

FAQ

Можно ли убрать галлюцинации полностью?

Нет. Можно только снижать их вероятность и последствия. Для критичных сценариев всегда нужен источник истины, правило отказа и человеческий контроль там, где цена ошибки высока.

Достаточно ли одного RAG-поиска по документам?

Нет. Поиск помогает только тогда, когда извлеченные фрагменты релевантны, документы актуальны, а модель обязана ссылаться именно на них. Плохой retrieval создает уверенные, но неверно обоснованные ответы.

Когда промпта без базы знаний достаточно?

Когда задача не требует знания внешних фактов: редактирование, сокращение текста, классификация по фиксированным правилам, преобразование формата, извлечение данных из уже предоставленного документа.

Нужно ли просить модель раскрывать полный ход рассуждений?

Для контроля качества полезнее требовать короткое объяснение, ссылки на источник и явный статус уверенности. Внутренние рассуждения сами по себе не гарантируют правильность и часто только усложняют проверку.

Что делать с конфликтующими источниками?

Заранее задайте приоритет: например, действующий регламент выше FAQ, а подписанный договор выше черновика. Если приоритет не определен, правильный ответ — указать конфликт и запросить решение человека.

Как работать с новостями и быстро меняющимися данными?

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

Как избежать галлюцинаций ИИ в ответах: практический процесс