Предотвращение галлюцинаций — документация Entity Enricher

Предотвращение галлюцинаций

Когда LLM создают структурированные данные, они могут выдумывать правдоподобно выглядящие факты. Entity Enricher использует 8 уровней защиты, чтобы вы получали точные данные или ничего — но не убедительно звучащий вымысел.

Проблема структурированных галлюцинаций

В свободном тексте вымышленное предложение явно расплывчато. В структурированном выводе вымышленное поле вроде "founded_year": 1987 выглядит авторитетно, и его почти невозможно отличить от корректного значения. Особенно опасным это делают три фактора:

Ложная точность

Галлюцинированное значение JSON выглядит в точности как настоящее. Никаких оговорок, никакого «примерно» — просто чистая, уверенная единица данных, которая оказывается неверной.

Нагрузка на схему

Обязательные поля вынуждают LLM выдавать значение, даже когда у неё нет данных. Модель выдумывает данные вместо того, чтобы оставить пробел в структуре.

Тихое распространение

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

Типичные паттерны галлюцинаций

ШаблонПримерПричина
Уверенная фабрикация"ceo": "John Smith"LLM заполняет обязательное поле правдоподобным именем
Временная путаница"revenue": "$2.3B"Ограничение обучающих данных или смешение периодов
Смешение сущностейАтрибуты компании A для компании BПохожие имена в пересекающихся обучающих данных
Разумные значения по умолчанию"employees": 500LLM выбирает «разумное» число вместо того, чтобы признать незнание
Вымышленные связи"subsidiary_of": "Alphabet"LLM выводит несуществующую связь

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

8 уровней защиты

Entity Enricher не полагается на один-единственный приём. Он объединяет 8 независимых уровней защиты, каждый из которых нацелен на свой тип сбоя. Если один уровень пропускает галлюцинацию, её ловит следующий.

1
Предварительная классификация

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

Пример: «Titan» относительно схемы «Planet» помечается как спутник — модели обогащения получают этот контекст и используют null для полей, специфичных для планет.

2
Объявленные неизвестные значения и осторожный prompt

Все стратегии дают LLM указание: «Будьте точны и осторожны — никогда не выдумывайте значение». Модель объявляет поля, которые не смогла определить, вместо того чтобы заполнять их заглушками, и эти объявления становятся честными null-значениями в результате.

Это напрямую снижает давление schema — причину №1 структурированных галлюцинаций. Объявленное неизвестное значение также устраняет неоднозначность реальных ответов: 0, который модель отстаивает, — это данные, а объявленный 0 — нет.

3
Определение экспертной области

Свойства схемы сгруппированы по областям экспертизы. Каждый вызов LLM видит только поля своей области с инструкцией сосредоточиться исключительно на ней.

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

4
Фокусировка ключа поиска

Ключевые свойства (отмеченные is_key: true) выделяются в промптах, чтобы сориентировать LLM на идентифицирующей информации перед заполнением остальных полей.

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

5
Валидация схемы и самокоррекция

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

До 5 автоматических попыток исправления в рамках одного запуска агента. (Генерация схемы исправляется иначе — пошагово, с детерминированными запасными вариантами.)

6
Сохранить логику

Поля, помеченные preserve: true (идентификаторы, SKU, идентификаторы импорта), после обогащения восстанавливаются к своим исходным входным значениям — LLM не может перезаписать достоверные данные. В запросах на обогащение необходимо указывать значение для каждого сохраняемого поля, чтобы ничто никогда не оказалось равным null или придуманным.

Внутри массивов обогащённые элементы сопоставляются с вашими входными элементами по их ключевым полям; элементы, обнаруженные ИИ, получают null вместо придуманного идентификатора.

7
Мультимодельный консенсус

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

Если Claude сообщает, что выручка $2,3 млрд, а GPT-4 — $1,8 млрд, этот конфликт обнаруживается и выводится.

8
Разрешение конфликтов и арбитраж

Обнаруженные конфликты разрешаются с помощью голосования по правилам (большинство, медиана, объединение) или специальным LLM-арбитром, который оценивает точность, полноту и согласованность.

Каждое решение arbitration включает обоснование и уровень уверенности — полная прозрачность того, как были разрешены конфликты.

Конвейер защиты

1Предварительная классификацияБлокировать неверные типы сущностей
2Допускает null + консервативные промптыСнизить нагрузку на схему
3Определение экспертной областиСузьте то, на что должен отвечать LLM
4Фокус ключа поискаОпирайтесь на идентификаторы
5Проверка и самокоррекцияИсправить структурные ошибки
6Сохранить логикуЗащита эталонных данных
7Мультимодельный консенсусОбнаружение расхождений
8Арбитраж конфликтовРазрешить с рассуждением
Перед обогащением
Во время обогащения
После обогащения

Философия дизайна

Основной принцип

Отсутствие данных всегда лучше неверных данных. Каждый уровень усиливает этот принцип — система спроектирована так, чтобы возвращать null, а не правдоподобную выдумку.

Что делает Entity Enricher
  • Явно разрешает LLM возвращать null
  • Выполняет перекрёстную проверку несколькими независимыми model
  • Защищает проверенные данные от перезаписи
  • Обеспечивает полную прозрачность разрешения конфликтов
Что делают типичные инструменты
  • Заставлять LLM заполнять каждое поле любой ценой
  • Полагаться на одну модель без перекрёстной проверки
  • Разрешить LLM свободно перезаписывать входные данные
  • Возвращать результаты как чёрный ящик без журнала аудита