TL;DR
LLM систематически смешивает четыре разных типа знания в одном ответе: прямые факты из источника, умозаключения, чужие слова и собственные догадки — и подаёт всё это одинаково уверенным тоном. Если попросить модель явно маркировать каждое утверждение по его источнику, она перестаёт прятать умозаключения под видом фактов.
Главная находка: модель не обязательно лжёт, когда говорит "Алиса обеспокоена дедлайном" — это может быть честный вывод из прочитанного письма. Проблема в том, что вывод подаётся так же, как прямая цитата. Пользователь не знает, что это интерпретация, а не факт. Исследователи замерили: даже технические системы верификации путаются именно на этом типе галлюцинации — "вывод-как-факт" (inference-as-fact).
Метод: попросить модель после каждого утверждения явно указать его тип — прямой факт из предоставленных данных, умозаключение, ссылка на внешний источник, утверждение об отсутствии чего-то или личное мнение. Это переносит структуру верификации прямо в промпт — без инфраструктуры, только инструкция.
Схема метода
(Один промпт — один запрос)
ШАГ 1: Дать задачу → модель генерирует ответ с маркировкой утверждений
ШАГ 2: Читать ответ → смотреть не только на содержание, но на тип каждого утверждения
ШАГ 3 (опционально): Отдельно уточнить "вывод"-утверждения → проверить их обоснованность
Пример применения
Задача: Ты просишь Claude разобрать переписку с клиентом и понять — стоит ли давать скидку.
Промпт:
Вот переписка с клиентом Иваном за последние 2 недели:
[вставляешь переписку]
Разбери, стоит ли давать ему скидку 20%.
После каждого утверждения в своём ответе укажи в скобках его тип:
— [ФАКТ] — если это прямо написано в переписке
— [ВЫВОД] — если это твоё умозаключение из написанного
— [МНЕНИЕ] — если это твоя оценка без прямых доказательств в тексте
— [ОТСУТСТВУЕТ] — если ты говоришь, что чего-то нет в переписке
Результат:
Модель выдаст разбор, где каждое утверждение будет промаркировано. Ты увидишь: "Иван упомянул конкурентов трижды [ФАКТ]" и "скорее всего, он готов уйти [ВЫВОД]" — и сразу поймёшь, где твёрдая почва, а где интерпретация. Утверждения типа [ВЫВОД] и [МНЕНИЕ] — сигнал: стоит перепроверить или задать уточняющий вопрос.
Почему это работает
LLM не различает слои знания по умолчанию. Модель генерирует следующий токен на основе предыдущих — без встроенного механизма, который отделял бы "я это прочитал" от "я это вывел". Всё выходит в одном потоке, одним тоном.
Зато модель умеет классифицировать, когда её явно просят. Просьба "укажи тип" — это не магия. Это перенос задачи в инструкцию: теперь у модели есть конкретный критерий, по которому она оценивает собственный текст прямо в процессе генерации. Исследование показало: при правильной инструкции модели корректно маркируют утверждения в 85–92% случаев — и это в реальных агентских системах, а не просто в чате.
Рычаги управления: - Детальность типологии — можно упростить до трёх типов (факт / вывод / мнение) или расширить (добавить "ссылка на источник", "утверждение об отсутствии") - Финальный запрос — после маркированного ответа уточни: "Все ли [ВЫВОД]-утверждения обоснованы? Какой из них наиболее уязвим?" Модель пересмотрит собственные умозаключения - Строгость — добавь "если не уверен в типе — пиши [МНЕНИЕ]", это снизит ложную уверенность
Шаблон промпта
{Твоя задача или вопрос}
{Контекст / текст / данные для анализа}
После каждого фактического утверждения в ответе укажи в скобках его тип:
— [ФАКТ] — прямо содержится в предоставленных данных
— [ВЫВОД] — умозаключение из данных, не сказано напрямую
— [ИСТОЧНИК] — ссылка на внешний материал или общеизвестное
— [МНЕНИЕ] — оценка без конкретных оснований в тексте
— [ОТСУТСТВУЕТ] — утверждение о том, чего нет в данных
Если тип неочевиден — выбирай наиболее осторожный вариант.
Плейсхолдеры:
- {Твоя задача} — что ты хочешь узнать или решить
- {Контекст / данные} — переписка, документ, транскрипт, статья, что угодно
🚀 Быстрый старт — вставь в чат:
Вот шаблон для маркировки утверждений по источнику знания.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие данные ты анализируешь и насколько детальной должна быть типология — потому что классификация должна совпадать с форматом твоих источников. Она возьмёт паттерн из шаблона и подстроит под твою задачу.
Ограничения
⚠️ Вывод-как-факт — самый сложный случай: модели хуже всего маркируют умозаключения. Если LLM уверена в выводе, она может пометить его как [ФАКТ]. Это самый распространённый тип галлюцинации — и именно он реже всего отлавливается.
⚠️ Работает только с предоставленными данными: если ты не даёшь источник в промпте, а спрашиваешь о "внешних знаниях" модели — маркировка теряет смысл. Почти всё станет [МНЕНИЕ] или [ИСТОЧНИК] без возможности проверки.
⚠️ Основная система (NabaOS) — инфраструктурная: HMAC-подписанные квитанции, движок верификации, интеграция с агентами — это серверная архитектура, не промпт. В чате ты получаешь только принцип эпистемической классификации, но не криптографическую гарантию.
⚠️ Не для коротких ответов: маркировка раздувает текст. На задачах типа "дай краткий ответ на один вопрос" — избыточно.
Как исследовали
Команда создала бенчмарк NyayaVerifyBench — 1800 сценариев с намеренно внедрёнными галлюцинациями шести типов на четырёх языках (английский, хинди, китайский, испанский). Интересная деталь: каждый тип галлюцинации тестировался отдельно — "придумал вызов инструмента", "неверное количество", "факт подменён", "вывод выдан за факт", "ложное отсутствие", "выдуманная ссылка". Это позволило увидеть, где конкретно ломается каждый метод.
NabaOS сравнивали с пятью альтернативами: без верификации, самосогласованность (ask twice), RAG-проверка по тексту, регулярные выражения и лёгкий классификатор. Главный сюрприз: текстовые методы (RAG, self-consistency) дали много ложных срабатываний — 12–18% — потому что паrafраза правильного утверждения похожа на галлюцинацию. NabaOS держит 4% ложно-позитивных, потому что сверяется со структурированными данными (квитанциями), а не с текстом.
Ещё важное: в неанглийских языках текстовые методы деградируют на 10–17 процентных пунктов, а receipt-верификация — только на 4. Потому что структурированные данные не зависят от языка. Это прямой аргумент для тех, кто работает с русскоязычными данными.
Адаптации и экстраполяции
🔧 Техника: двойной проход — сначала ответ, потом аудит
Иногда просить маркировать в процессе — неудобно: разбивает текст. Альтернатива — два запроса:
Запрос 1: {задача + данные} — дай ответ
Запрос 2: Возьми свой предыдущий ответ и для каждого фактического утверждения
скажи: это прямо в тексте, это твой вывод, или это твоё предположение?
Укажи, какое утверждение ты считаешь наименее обоснованным и почему.
Второй запрос работает как ретроспективный аудит. Модель часто замечает свои слабые места, которые пропустила в первом ответе.
🔧 Техника: "маркировка уязвимостей" для важных решений
Если тебе нужно принять решение на основе анализа LLM — добавь блок после маркировки:
...
После маркировки добавь раздел «Уязвимые утверждения»:
перечисли все [ВЫВОД] и [МНЕНИЕ]-утверждения,
которые при проверке могут оказаться неверными,
и что нужно уточнить чтобы их подтвердить.
Это превращает маркировку в конкретный чек-лист для дополнительной проверки — особенно полезно в юридических, финансовых или медицинских контекстах.
Ресурсы
Abhinaba Basu — "Tool Receipts, Not Zero-Knowledge Proofs: Practical Hallucination Detection for AI Agents" (2025)
Автор: mail@abhinaba.com
Философская база: Nyāya Sūtras (Готама, ~2 в. н.э.) — индийская эпистемология, классификация источников знания (pramāṇa)
Смежные работы упомянутые в статье: - Chain-of-verification — Dhuliawala et al. (2023) - Self-consistency — Wang et al. (2023) - zkLLM — Sun et al. (2024)