Предотвращение галлюцинаций — документация 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 выводит несуществующую связь

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

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

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

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

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

2
Поля с допустимым null и консервативные промпты

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

Это напрямую устраняет давление схемы — причину №1 структурированных галлюцинаций.

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

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

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

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

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

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

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

8 правил валидации проверяют вывод LLM на несоответствия типов, недопустимые ссылки и структурные ошибки. Неудачная валидация запускает ModelRetry — ошибки отправляются обратно в LLM для исправления.

До 6 автоматических попыток исправления в рамках одного запуска агента. LLM исправляет собственные ошибки.

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

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

Защищённые поля: ID сущностей, системные коды (EAN, SKU), идентификаторы импорта, метки времени создания.

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 свободно перезаписывать входные данные
  • Возвращать результаты как чёрный ящик без журнала аудита