Вы заказывали точный ответ, а получили красивый бред
Вы просите LLM проанализировать технический документ и выделить риски. Модель послушно генерирует список из десяти пунктов. Пять из них - реальные угрозы. Еще три - полуправда, приукрашенная убедительными деталями. Оставшиеся два - чистый вымысел, который звучит так логично, что вы чуть не запускаете дорогостоящую проверку. Это не ошибка промпта. Это фундаментальный архитектурный изъян, который мы усердно латаем костылями.
Типичный промпт 2025 года выглядит как инструкция для шизофреника: "Будь точным, но креативным. Анализируй глубоко, но отвечай кратко. Следуй фактам, но если не уверен - предположи. И ни в коем случае не галлюцинируй!". Мы требуем от одной нейросети выполнить две взаимоисключающие задачи: анализ (консервативный, основанный на данных) и генерацию (творческую, вероятностную). И удивляемся результату.
Почему один промпт на все случаи жизни - это архитектурное преступление
Представьте, что вы нанимаете одного сотрудника и говорите ему: "Ты будешь и аудитором, и копирайтером. Проверь эти финансовые отчеты на мошенничество, а потом напиши продающий текст для нового продукта. И сделай это за один присест". Результат предсказуем. Так почему мы ожидаем другого от LLM?
В основе галлюцинаций лежит не "глупость" модели, а конфликт внутренних механизмов. Когда вы просите GPT-5o (актуальная версия на апрель 2026) или Claude 3.7 Sonnet проанализировать и сгенерировать в одном потоке, модель вынуждена постоянно переключаться между режимами мышления. В геометрии residual stream это создает интерференцию паттернов. Аналитические векторы смешиваются с генеративными, и на выходе получается нечто среднее - "творческий анализ" или "логический вымысел".
Разделяй и властвуй: паттерн Analysis-Generation Separation
Решение настолько простое, что его пропускают 90% инженеров. Вместо одного универсального промпта используйте два специализированных контура, работающих последовательно:
- Контур анализа: Модель-"аудитор". Ее задача - только извлекать, проверять, классифицировать. Никакой генерации нового контента. Только структурированный вывод: факты, сущности, связи, противоречия.
- Контур генерации: Модель-"коммуникатор". Получает на вход строгие результаты анализа и инструкцию по формату. Ее работа - упаковать проверенные данные в нужную форму (отчет, email, код, ответ клиенту).
Это не "цепочка мыслей". Это принципиально разные задачи для разных инстансов модели (или даже разных моделей). В моих продакшн-системах этот паттерн снижал галлюцинации в задачах анализа документов на 70-80%. И дешевле, чем апгрейд до GPT-5 Turbo.
Пошаговый план: как внедрить разделение в вашем проекте
1 Диагностика конфликтующих задач
Вытащите ваши промпты. Если в них есть союзы "и", "но", "также" между аналитическими и творческими инструкциями - у вас проблема. Пример плохого промпта:
"Проанализируй этот юридический договор, найди скрытые риски и напиши дружелюбное письмо клиенту с объяснением проблем и предложением альтернатив."
Три разные задачи в одном запросе. Модель будет жертвовать точностью анализа ради красоты письма. Всегда.
2 Проектирование контура анализа
Создайте промпт, который запрещает генерацию. Буквально. Используйте технику CausaNova - требуйте доказательства для каждого утверждения. Пример промпта для анализатора:
ТЫ - СИСТЕМА ИЗВЛЕЧЕНИЯ ФАКТОВ. ТВОЯ ЕДИНСТВЕННАЯ ЗАДАЧА - НАЙТИ В ТЕКСТЕ КОНКРЕТНУЮ ИНФОРМАЦИЮ.
ИНСТРУКЦИИ:
1. Не придумывай ничего нового
2. Если информация неполная - укажи "ДАННЫХ НЕДОСТАТОЧНО"
3. Для каждого факта приведи цитату из текста (строка:символ)
4. Формат вывода строго JSON: {"факты": [{"тип": "...", "значение": "...", "источник": "..."}]}
ТЕКСТ ДЛЯ АНАЛИЗА: {документ}
Для этого контура подходят модели с низкой "креативностью" (temperature 0.1-0.3). В 2026 году отлично работают специализированные модели для извлечения информации типа Nemo Retriever или GPT-5 Analysis с настроенными параметрами.
3 Проектирование контура генерации
Генератор получает на вход готовые, проверенные данные. Его промпт должен запрещать изменять факты. Пример:
ТЫ - СИСТЕМА ФОРМАТИРОВАНИЯ. ТВОЯ ЗАДАЧА - ПРЕОБРАЗОВАТЬ СТРУКТУРИРОВАННЫЕ ДАННЫХ В ЗАПРОШЕННЫЙ ФОРМАТ.
ПРАВИЛА:
1. Используй ТОЛЬКО факты из предоставленных данных
2. Если данных нет по какому-то пункту - напиши "Информация отсутствует"
3. Стиль: {деловой/дружелюбный/технический}
ДАННЫЕ ДЛЯ ОБРАБОТКИ: {результат_анализа_в_JSON}
ТРЕБУЕМЫЙ ФОРМАТ: {например, письмо клиенту с разделами}
Здесь можно использовать более "творческие" модели (temperature 0.7-0.9) - они не испортят факты, потому что факты заблокированы на входе. Claude 3.7 Sonnet или Gemini 2.5 Pro отлично справляются.
4 Добавление слоя валидации (опционально, но сильно)
Между анализом и генерацией вставьте простую проверку. Можно использовать архитектуру двухслойной валидации. Третий, микро-контур, который проверяет, не добавил ли анализатор от себя лишнего. Часто достаточно простых правил: "Если в выводе анализатора нет цитаты из текста - отклонить".
Нюансы, о которых молчат в теориях
| Проблема | Реальное решение | Что будет, если проигнорировать |
|---|---|---|
| Latency увеличивается в 2 раза | Запускать контуры параллельно, где возможно. Анализ часто можно кэшировать. | Пользователи уйдут к конкурентам с более быстрым, но менее точным ботом. |
| Стоимость двух вызовов вместо одного | Использовать маленькую/дешевую модель для анализа (например, Llama 3.2 3B), дорогую - для генерации. | Бюджет сгорит на ошибках, которые придется исправлять вручную. |
| Передача контекста между контурами | Использовать строгий структурированный формат (JSON, XML). Никакого свободного текста. | Генератор неправильно интерпретирует вывод анализатора - получаем галлюцинации второго порядка. |
| Слишком жесткие ограничения анализатора | Разрешить категорию "ВЕРОЯТНЫЕ_ФАКТЫ" с уровнем уверенности. Но генератору их не отдавать. | Анализатор будет молчать по спорным моментам, теряя ценную информацию. |
Типичные ошибки при внедрении
- Использовать одну и ту же модель для обоих контуров с одинаковыми параметрами. Бесполезно. Анализатору нужен temperature 0.1, генератору - 0.7. Если у вас одна модель, создайте два разных инстанса с разными системными промптами и параметрами.
- Разрешать генератору "додумывать", если данных мало. Это ловушка. Лучше явный текст "В предоставленных данных нет информации о..." чем красивый вымысел.
- Не проверять формат передачи данных. Анализатор выдал JSON с ошибкой, генератор упал - система молча вернула пустой ответ. Добавляйте схему валидации (JSON Schema) между этапами.
- Забывать про проблему 'Молчаливого ученого'. Анализатор может не выдать важный факт, потому что он "очевиден из контекста". Заставляйте его явно извлекать все, даже кажущиеся тривиальными данные.
Частые вопросы (FAQ)
Этот паттерн увеличивает latency. Как быть с real-time системами?
Анализируйте асинхронно. В чат-боте: первый ответ дает быстрая генеративная модель (с оговоркой "ищу информацию..."), затем фоново запускается анализ, и через 2 секунды приходит уточненное сообщение. Пользователи ценят точность больше, чем мгновенность.
А если мне нужен именно творческий анализ? Например, генерация гипотез на основе данных?
Тогда ваш запрос чисто генеративный. Но разделяйте этапы: 1) Извлеки факты (анализ, temperature 0). 2) На основе ЭТИХ фактов предложи гипотезы (генерация, temperature 0.9). Ключ в том, что генерация работает на выходе анализа, а не вместо него.
Как тестировать такую систему? У меня же теперь два контура вместо одного.
Тестируйте по отдельности. Для анализатора используйте промпты для тестирования на точность извлечения фактов. Для генератора - тесты на соответствие формату при неизменных входных данных. Интеграционные тесты проверяют только передачу данных между контурами.
Что делать сегодня, прямо сейчас
Откройте ваш самый проблемный промпт. Тот, где LLM постоянно врет или приукрашивает. Разрежьте его на две части: что нужно ИЗВЛЕЧЬ из контекста и что нужно СФОРМУЛИРОВАТЬ на основе извлеченного. Напишите два разных системных сообщения. Запустите последовательно, даже если это увеличит время ответа на 50%.
Сравните результаты. В 8 из 10 случаев вы увидите драматическое улучшение точности. Модели 2026 года стали умнее, но их архитектура по-прежнему требует от нас, инженеров, правильной организации работы. Прекратите заваливать LLM противоречивыми инструкциями. Дайте каждой части задачи свою собственную, четко определенную роль. Система скажет вам спасибо - количеством сэкономленных часов на проверке бреда.
Неочевидный совет: Самый опасный вид галлюцинаций - когда модель добавляет "немного" вымысла к реальным фактам. Пользователь верит, потому что 90% информации верно. Разделение анализа и генерации бьет именно по этим гибридным ошибкам. Анализатор не умеет приукрашивать. Генератор не умеет придумывать факты. Вместе они производят только то, что можно проверить.
