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

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

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

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

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

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

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

Правила сравнения по типу поля
ТипСпособ сравненияСогласие означает
СкалярНормализованное точное совпадение (без пробелов, в нижнем регистре, округлённое)Все значения равны после нормализации
МногоязычныйОсновной язык запуска определяет результат; различия перевода лишь запускают объединение по языкамОдинаковый текст на основном языке — варианты формулировки перевода не считаются расхождениями
МассивСравнение множеств (без учёта порядка) по представлению элементов на основном языкеОдни и те же элементы независимо от порядка или формулировки перевода
ОбъектПо свойствам — пока идентифицирующие поля подтверждают, что обе модели описывают одно и то же; иначе весь объект считается одним конфликтомВсе вложенные свойства совпадают
Null / пустоЗначение null, пустая строка или пустой массив — это воздержание, а не утверждениеЗаполненное значение побеждает без учёта конфликта
Пример: обогащение «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 или значениеПредпочитать заполненное значениеОтсутствие данных хуже любого значения

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

Вложенные объекты объединяются целиком, а не смешиваются

Объединять вложенный объект поле за полем безопасно только до тех пор, пока обе модели описывают одно и то же. Если поля идентичности этого не подтверждают — разные ключи либо ключей нет вовсе, а под ними реальное расхождение, — объект становится единым конфликтом, и версия одной из моделей берётся как есть. Иначе слияние собрало бы химеру: адрес одной модели у компании из другой. Одно следствие сделано намеренно, но о нём стоит знать: победитель берётся вместе со своими пропусками, поэтому поле, оставленное им пустым, так и останется пустым — а это может задержать сущность на входном контроле базы данных. Причина указывается в предупреждениях валидации прогона.

Когда числа расходятся слишком сильно для слияния

«Ближайшее к медиане» подходит для моделей, которые по-разному округляют, и не подходит для моделей, которые противоречат друг другу: 0 против 1854 — это не разница в округлении. Когда относительный разброс значений достигает 20%, это поле передаётся LLM-арбитру, выбранному автоматически по обычным правилам выбора модели вашей организации, и вызов тарифицируется как любой другой. Такие поля помечаются в журнале аудита слияния как переданные на арбитраж автоматически, поэтому слияние, потребившее токены, всегда показывает, какие поля к этому привели.

Вариант 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, ... }]

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

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

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

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

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

В пакетном обогащении слияние происходит автоматически, когда вы выбираете две или более модели. Нажимать “Merge Results” вручную не нужно: как только каждая модель успешно отработает по сущности, запускается слияние и объединённый результат появляется рядом с результатами отдельных моделей. Запуск, в котором одна модель завершилась ошибкой, намеренно не сливается: объединение оставшегося молча выдало бы частичный ответ за согласованный. Сначала восстановите недостающую модель — после повторного выполнения её неудавшихся экспертиз запуск сливается автоматически, как только снова становится полным.

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

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

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