Слияние нескольких моделей — документация Entity Enricher

Слияние нескольких моделей

Когда вы запускаете одно и то же обогащение на нескольких моделях ИИ, Entity Enricher может слить результаты в единый результат с высокой уверенностью. Слияние обнаруживает конфликты между результатами моделей и разрешает их с помощью детерминированных правил или арбитража на базе LLM.

Конвейер слияния

Выходные данные модели
Результат Claude
Результат GPT-4
Результат Gemini
Обнаружение конфликтов
Сравнивайте каждое поле
по всем моделям
Разрешение
Слияние на основе правил
или
Арбитраж LLM
Объединённый результат
Единый результат с
журналом аудита конфликтов

Шаг 1: Обнаружение конфликтов

Детектор конфликтов сравнивает каждое поле по всем выводам моделей. Поля, в которых все модели согласны, проходят без изменений. Поля, в которых модели расходятся, помечаются как конфликты, требующие разрешения.

Правила сравнения по типу поля
ТипСпособ сравненияСогласие означает
СкалярНормализованное точное совпадение (без пробелов, в нижнем регистре, округлённое)Все значения равны после нормализации
МногоязычныйСравнение по языкамКаждый языковой ключ сопоставляется между model
МассивСравнение множеств (независимо от порядка)Одинаковые элементы независимо от порядка
ОбъектРекурсивно по каждому свойствуВсе вложенные свойства совпадают
NullNull равнозначно отсутствиюСчитаются эквивалентными
Пример: обогащение «Sanofi» с помощью 2 моделей
Вывод Claude
revenue: 42.2
gmp_status: true
description: “Sanofi is a global...”
Вывод GPT-4
revenue: 44.1
gmp_status: true
description: “Sanofi SA is a...”
Результат: gmp_status = agreed | revenue = conflict (42.2 vs 44.1) | description = conflict (различный текст)

Шаг 2: Разрешение конфликтов

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

Вариант A

Слияние на основе правил

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

Тип поляПравилоОбоснование
СтрокаГолосование большинством; при равенстве выбирается самое длинное значениеБольше деталей — обычно лучше
ЧислоМедианное значениеУстойчив к выбросам
ЛогическийБольшинство; при равенстве побеждает trueКонсервативное значение по умолчанию
МногоязычныйГолосование большинством по языкамКаждый язык разрешается независимо
МассивОбъединение всех элементовСохранить всю информацию
ОбъектРекурсивно по каждому полюПрименить правила к вложенным полям
Null или значениеПредпочитать не-null значениеОтсутствие данных хуже любого значения

Разрешение ничьей: При равенстве голосов побеждает значение от более дорогой модели (как показатель её возможностей), затем — по алфавитному порядку имён моделей.

Вариант B

Арбитраж LLM

Когда вы выбираете модель арбитража на боковой панели, конфликты отправляются в LLM для интеллектуального разрешения. Арбитр получает контекст сущности, описания полей схемы и все конфликтующие значения, а затем принимает обоснованные решения.

Что возвращает арбитр
Выбранное значениеЗначение, которое оно считает наиболее точным
Исходная модельИз какой модели получено выбранное значение
РассуждениеПочему было выбрано именно это значение, а не альтернативы
УверенностьНасколько она уверена в решении (высокая, средняя, низкая)

Резервный вариант: Если модель арбитража даёт сбой (тайм-аут, ошибка), система автоматически переходит к объединению на основе правил, чтобы вы всегда получали результат.

Шаг 3: Объединённый результат

После разрешения конфликтов система формирует единый объединённый результат и сохраняет его в базе данных как запись «арбитража». Каждый объединённый результат включает журнал аудита, чтобы вы могли отследить, как был разрешён каждый конфликт.

Журнал аудита (метаданные арбитража)

Каждый объединённый результат включает метаданные, документирующие процесс слияния:

“method”: “rule_based” | “llm”
“source_record_ids”: [“uuid-1”, “uuid-2”]
“total_fields”: 23
“agreed_fields”: 18
“conflicted_fields”: 5
“decisions”: [{ path, chosen_value, rule_used, ... }]

Что вы видите в интерфейсе

После завершения слияния вкладка «Объединённый» на панели результатов показывает:

1
Заголовок сводки
Показывает метод разрешения (на основе правил или LLM) и счётчик вида «18 совпало / 5 разрешено / 23 полей всего».
2
Объединённый JSON
Полный структурированный вывод, объединяющий согласованные значения и разрешённые конфликты в единый JSON-документ.
3
Отчёт о конфликтах
Разворачиваемые карточки для каждого конфликта, показывающие: путь к полю, значок метода разрешения (Majority Vote, Median, Union и т. д.), значения всех моделей с выделением выбранного и текст обоснования, если использовался арбитраж LLM.

Автоматическое слияние при пакетной обработке

В пакетном обогащении слияние происходит автоматически, когда вы выбираете две или более модели. Вам не нужно вручную нажимать «Объединить результаты» — как только все модели завершают работу над сущностью, запускается слияние, и объединённый результат появляется рядом с результатами отдельных моделей.

Потоковое слияние: Как при обогащении отдельной сущности, так и при пакетном обогащении прогресс слияния передаётся через Server-Sent Events. Вы видите события fusion_started, conflicts_detected и fusion_completed в реальном времени.

Арбитраж на основе правил или LLM: когда использовать каждый

На основе правил (бесплатно, мгновенно)
  • Преимущественно фактические/числовые данные, где хорошо работает логика голосования
  • Большой объём или пакетная обработка, где важна стоимость
  • Простые схемы с небольшим числом ожидаемых конфликтов
  • Когда вам нужны детерминированные, воспроизводимые результаты
Арбитраж LLM (дополнительная стоимость)
  • Сложные схемы, где контекст важен для разрешения
  • Текстовые данные (описания, сводки), где голосования недостаточно
  • Когда вам нужны объяснимые решения с обоснованием
  • Ответственные обогащения, где точность оправдывает дополнительные затраты