LLM اختلقت خط مساعدة: لماذا الرموز لا توقف الهلوسات

LLM-бот заметил тревожные сигналы в переписке и порекомендовал позвонить на телефон доверия. Номер оказался детским — модель его выдумала. В промпте стоял явный запрет: «не придумывай контактные данные».

Не помогло. Это не баг, который лечится магическими словами. Это архитектурная проблема.

Сценарий реальный и пугающий. Девушка пересылает боту переписку с бойфрендом. Модель распознаёт паттерны: эмоциональное давление, изоляция, газлайтинг.

Реагирует как заботливый помощник — предлагает обратиться за профессиональной помощью и называет конкретный номер. Всё выглядит логично, кроме одного: номер оказался детской горячей линией. Модель сгенерировала правдоподобную строку цифр, потому что именно это она умеет делать лучше всего — предсказывать то, что выглядит уместно.

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

Инструкция «не придумывай» конкурирует с выученным поведением миллиардов параметров, настроенных на helpfulness через RLHF. В этом состязании промпт почти всегда проигрывает. Желание модели быть полезной оказывается сильнее любого словесного запрета.

Это означает конкретное следствие для продуктов: если ваш сервис опирается на LLM для передачи критических данных — телефонов, адресов, имён специалистов, юридических ссылок — вы строите на ненадёжном фундаменте. Галлюцинация не исключение, она встроена в природу модели. Чем более «заботливой» вы её делаете, тем сильнее импульс дать ответ даже при отсутствии надёжной информации.

Что работает вместо промптинга? Архитектурная развязка. Контакты хранятся в верифицированной базе данных, а не в весах модели.

LLM распознаёт намерение пользователя и вызывает функцию или RAG-запрос: получает конкретный номер из конкретной строки таблицы. Модель не генерирует цифры — она их извлекает. Разница принципиальная.

Функциональный вызов (function calling, tool use) решает задачу напрямую. Вы описываете инструмент get_crisis_contact(region, type) — и при соответствующем намерении модель вызывает его вместо того, чтобы фантазировать. Ответ берётся из базы, а не из вероятностного распределения токенов.

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

Это не даёт стопроцентной гарантии — базу тоже надо поддерживать — но это на порядок надёжнее инструкции в промпте. Третий паттерн — явное разграничение типов знания в архитектуре. Есть знание, которое модель может генерировать свободно: тон, структура, эмпатия, интерпретация ситуации.

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

Человек в кризисе получает неверный номер. Это не неудобство — это потенциальный вред. Таких сценариев в продакшене гораздо больше, чем принято признавать: юридические консультации, медицинские справки, финансовые данные, рекомендации специалистов.

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

Давайте ей функции, базы и инструменты. Пусть понимает контекст и интерпретирует намерение, но не изобретает факты. Это и есть архитектура — а не набор магических слов в system prompt.