Когда вы запускаете одно и то же обогащение на нескольких моделях ИИ, Entity Enricher может слить результаты в единый результат с высокой уверенностью. Слияние обнаруживает конфликты между результатами моделей и разрешает их с помощью детерминированных правил или арбитража на базе LLM.
Детектор конфликтов сравнивает каждое поле по всем выводам моделей. Поля, в которых все модели согласны, проходят без изменений. Поля, в которых модели расходятся, помечаются как конфликты, требующие разрешения.
| Тип | Способ сравнения | Согласие означает |
|---|---|---|
| Скаляр | Нормализованное точное совпадение (без пробелов, в нижнем регистре, округлённое) | Все значения равны после нормализации |
| Многоязычный | Основной язык запуска определяет результат; различия перевода лишь запускают объединение по языкам | Одинаковый текст на основном языке — варианты формулировки перевода не считаются расхождениями |
| Массив | Сравнение множеств (без учёта порядка) по представлению элементов на основном языке | Одни и те же элементы независимо от порядка или формулировки перевода |
| Объект | По свойствам — пока идентифицирующие поля подтверждают, что обе модели описывают одно и то же; иначе весь объект считается одним конфликтом | Все вложенные свойства совпадают |
| Null / пусто | Значение null, пустая строка или пустой массив — это воздержание, а не утверждение | Заполненное значение побеждает без учёта конфликта |
Детерминированные правила применяются при каждом слиянии и решают всё, что можно доказать значениями самих моделей. То, чему они могут лишь отдать предпочтение, — противоречивое значение, вложенный объект, который модели описывают по-разному, элемент, который выдала лишь одна модель, — передаётся на разрешение. Выбор модели арбитража на боковой панели определяет, кто выносит это решение: сами правила или LLM.
Детерминированные правила применяются в зависимости от типа данных каждого поля. Почти всегда для этого не нужен ни один вызов LLM — разрешение происходит мгновенно и бесплатно. Единственное исключение — числа, по которым модели расходятся радикально: ни одно правило не может честно их согласовать, см. ниже.
| Тип поля | Правило | Обоснование |
|---|---|---|
| Строка | Голосование большинством; при равенстве выбирается самое длинное значение | Больше деталей — обычно лучше |
| Число | Значение модели, ближайшее к медиане | Устойчиво к выбросам, никогда не выдаёт искусственное среднее |
| Логический | Большинство; при равенстве побеждает true | Консервативное значение по умолчанию |
| Многоязычный | Голосование большинством по каждому языку, объединение языков | Каждый язык разрешается независимо |
| Массив | Объединение с учётом ключей: элементы группируются по ключевым полям, варианты написания сводятся вместе, совпавшие элементы объединяются по полям | Одна строка на логическую сущность, ничего не теряется |
| Объект | По полям, когда совпадают идентифицирующие данные; иначе объект одной модели берётся целиком | Смешение двух объектов, описывающих разные сущности, породило бы третий, который не вернула ни одна модель |
| Null или значение | Предпочитать заполненное значение | Отсутствие данных хуже любого значения |
Разрешение ничьей: при равенстве голосов побеждает значение более дорогой модели (как косвенный признак её возможностей), затем — алфавитный порядок имён моделей. Для объекта, взятого целиком, между этими двумя критериями вклинивается полнота — число заполненных листьев: раз доказать, какая сущность настоящая, нечем, предпочтение отдаётся более сильной модели, а затем ответу, который несёт больше информации.
Объединять вложенный объект поле за полем безопасно только до тех пор, пока обе модели описывают одно и то же. Если поля идентичности этого не подтверждают — разные ключи либо ключей нет вовсе, а под ними реальное расхождение, — объект становится единым конфликтом, и версия одной из моделей берётся как есть. Иначе слияние собрало бы химеру: адрес одной модели у компании из другой. Одно следствие сделано намеренно, но о нём стоит знать: победитель берётся вместе со своими пропусками, поэтому поле, оставленное им пустым, так и останется пустым — а это может задержать сущность на входном контроле базы данных. Причина указывается в предупреждениях валидации прогона.
«Ближайшее к медиане» подходит для моделей, которые по-разному округляют, и не подходит для моделей, которые противоречат друг другу: 0 против 1854 — это не разница в округлении. Когда относительный разброс значений достигает 20%, это поле передаётся LLM-арбитру, выбранному автоматически по обычным правилам выбора модели вашей организации, и вызов тарифицируется как любой другой. Такие поля помечаются в журнале аудита слияния как переданные на арбитраж автоматически, поэтому слияние, потребившее токены, всегда показывает, какие поля к этому привели.
Когда вы выбираете модель арбитража на боковой панели, вопросы, которые не смогли решить правила, передаются этой LLM. Она видит идентичность сущности, описание каждого поля и значение каждой модели на вашем основном языке обогащения — и отвечает, указывая на вариант, но никогда не пишет собственное значение.
Вопросы задаются уровень за уровнем: сначала сама сущность, затем каждый сопоставленный элемент массива — в отдельном вызове, с собственной идентичностью в качестве контекста («Акт I этой оперы»), — причём об элементе, отброшенном арбитром, вопросы больше не задаются. Общая часть промпта кешируется первым вызовом, поэтому более глубокие вызовы выполняются параллельно и стоят намного дешевле.
Запасной вариант: если модель арбитража не отвечает (таймаут, ошибка), в силе остаются решения, принятые по правилам, поэтому результат вы получите в любом случае — а в записи указано, какой метод был применён.
После разрешения конфликтов система формирует единый объединённый результат и сохраняет его в базе данных как запись «арбитража». Каждый объединённый результат включает журнал аудита, чтобы вы могли отследить, как был разрешён каждый конфликт.
Каждый объединённый результат включает метаданные, документирующие процесс слияния:
Тот же аудиторский след показывается для любой объединённой записи на странице История, на вкладке «Обзор». Решения, принятые внутри массива — по полю сопоставленного элемента, о сохранении или отбрасывании элемента, — также перечислены, поэтому исключённое видно так же хорошо, как и сохранённое. В записи с арбитражем через LLM в качестве модели указан её арбитр; при слиянии по правилам вместо этого перечислены объединённые модели, поскольку вызова LLM не было вовсе — а значит, нет ни промпта, ни токенов, ни стоимости.
После завершения слияния вкладка «Объединённый» на панели результатов показывает:
В пакетном обогащении слияние происходит автоматически, когда вы выбираете две или более модели. Нажимать “Merge Results” вручную не нужно: как только каждая модель успешно отработает по сущности, запускается слияние и объединённый результат появляется рядом с результатами отдельных моделей. Запуск, в котором одна модель завершилась ошибкой, намеренно не сливается: объединение оставшегося молча выдало бы частичный ответ за согласованный. Сначала восстановите недостающую модель — после повторного выполнения её неудавшихся экспертиз запуск сливается автоматически, как только снова становится полным.
fusion_started, conflicts_detected и fusion_completed в реальном времени.