다중 모델 퓨전

여러 AI 모델에서 동일한 강화를 실행하면 Entity Enricher가 결과를 단일한 고신뢰도 출력으로 융합할 수 있습니다. 융합은 모델 출력 간의 충돌을 감지하고 결정론적 규칙 또는 LLM 기반 중재를 사용하여 이를 해결합니다.

융합 파이프라인

모델 출력
Claude 결과
GPT-4 결과
Gemini 결과
충돌 감지
모든 필드를
모든 모델에서 비교하세요
해석
규칙 기반 병합
또는
LLM 중재
fusion된 결과
단일 출력과
충돌 감사 추적

1단계: 충돌 감지

충돌 감지기는 모든 모델 출력에서 각 필드를 비교합니다. 모든 모델이 일치하는 필드는 변경 없이 통과합니다. 모델이 서로 다른 필드는 해결이 필요한 충돌로 표시됩니다.

필드 유형별 비교 규칙
유형비교 방식합의의 의미
스칼라정규화된 정확 일치(공백 제거, 소문자화, 반올림)정규화 후 모든 값이 동일합니다
다국어실행의 기본 언어가 결정하며, 번역 차이는 언어별 병합만 유발합니다기본 언어에서 동일한 텍스트 — 번역의 표현 차이는 불일치로 보지 않습니다
배열항목의 기본 언어 관점에 대한 집합 비교(순서 무관)순서나 번역 표현과 무관하게 동일한 항목
객체식별 필드가 두 모델이 같은 대상을 설명한다는 것을 입증하는 한 속성 단위로 처리하고, 그렇지 않으면 객체 전체가 하나의 충돌이 됩니다모든 중첩 속성이 일치합니다
Null / 비어 있음null, 빈 문자열 또는 빈 배열 값은 주장이 아니라 기권으로 간주합니다충돌로 집계하지 않고 채워진 값이 우선합니다
예시: 모델 2개로 “Sanofi” 강화하기
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 대 44.1) | description = conflict (다른 텍스트)

2단계: 충돌 해결

결정적 규칙은 모든 융합에서 실행되어 모델들의 값 자체로 입증할 수 있는 모든 것을 확정합니다. 규칙이 답을 선호할 수만 있는 항목 — 서로 상충하는 값, 모델마다 다르게 기술한 중첩 객체, 한 모델만 생성한 항목 — 은 리졸버에게 넘겨집니다. 사이드바에서 중재 모델을 선택하면 그 리졸버가 규칙 자체가 될지, LLM이 될지가 정해집니다.

  1. 1아무것도 선택하지 않으면 결정적 규칙이 계속 해결자 역할을 합니다
  2. 2중재는 별도의 호출로 아래 가격에 따라 과금됩니다
여기서는 필드가 비어 있으며, 이것이 무료 경로입니다. 규칙은 입증할 수 있는 것을 모두 해결하고, 나머지에 대해서는 선호되는 답을 선택합니다. 모델을 지정하면 그 잔여분에 대해서만 판단을 받을 뿐, 엔티티 전체를 다시 처리하지는 않습니다.
옵션 A

규칙 기반 병합

각 필드의 데이터 타입에 따라 결정적 규칙이 적용됩니다. 거의 모든 경우 LLM 호출이 전혀 필요 없으며, 해결은 즉시 이루어지고 비용도 들지 않습니다. 유일한 예외는 모델 간 값 차이가 극심한 숫자로, 어떤 규칙으로도 정직하게 판정할 수 없습니다. 아래를 참고하세요.

필드 유형규칙근거
문자열다수결, 동점 시 가장 긴 값을 선택합니다일반적으로 세부 정보가 많을수록 좋습니다
숫자중앙값에 가장 가까운 model 값이상치에 강건하며, 조작된 평균을 만들지 않습니다
불리언다수결, 동점 시 true 우선보수적 기본값
다국어언어별 다수결, 언어 통합각 언어를 독립적으로 처리합니다
배열키 인식 통합: 항목을 키 필드로 그룹화하고, 철자 변형을 하나로 병합하며, 일치하는 항목은 필드별로 병합합니다논리적 entity당 한 행씩, 손실 없음
객체식별 정보가 일치하면 필드 단위로 처리하고, 그렇지 않으면 한 모델의 객체를 통째로 채택합니다서로 다른 엔티티를 설명하는 두 객체를 섞으면 어느 모델도 반환하지 않은 제3의 객체를 만들어 내게 됩니다
Null 대 값채워진 값을 우선합니다데이터 누락이 어떤 값보다 낫습니다

동점 처리: 득표가 같을 경우 더 비싼 모델의 값이 우선하고(성능의 대리 지표로 사용), 그다음은 모델 이름의 알파벳 순서입니다. 객체 전체를 원자적으로 다룰 때는 완성도, 즉 채워진 리프의 개수가 이 둘 사이에 들어갑니다. 어떤 엔티티가 진짜인지 증명할 근거가 없다면 더 강력한 모델을, 그다음으로 더 많은 정보를 담은 답변을 선택합니다.

중첩된 객체는 섞이지 않고 통째로 병합됩니다

중첩된 객체를 필드 단위로 병합하는 것은 두 모델이 같은 대상을 설명하고 있을 때만 안전합니다. 식별 필드가 이를 입증하지 못할 때 — 키가 서로 다르거나, 키가 아예 없는데 그 아래 실제로 내용이 어긋날 때 — 해당 객체는 하나의 충돌로 처리되어 한 모델의 버전이 그대로 채택됩니다. 그렇지 않으면 융합은 키메라를 조립하게 됩니다. 이 모델의 주소가 저 모델의 회사에 붙는 식입니다. 의도된 동작이지만 알아 둘 만한 결과가 하나 있습니다. 승자는 빈칸까지 포함한 채로 채택되므로 승자가 비워 둔 필드는 계속 비어 있게 되고, 이로 인해 엔터티가 데이터베이스 승인 관문에서 막힐 수 있습니다. 그 이유는 실행의 검증 경고에 함께 기록됩니다.

숫자 차이가 너무 커서 병합할 수 없는 경우

“중앙값에 가장 가까운 값”은 모델마다 반올림 방식이 다를 때는 적절하지만, 모델끼리 서로 모순될 때는 적절하지 않습니다. 0과 1854는 반올림 차이가 아닙니다. 값들의 상대적 편차가 20%에 도달하면 해당 필드는 조직의 일반적인 모델 선택 방식에 따라 자동으로 선정된 LLM 중재자에게 넘겨지며, 이 호출은 다른 호출과 동일하게 과금됩니다. 해당 필드는 융합 감사 기록에 자동 에스컬레이션으로 표시되므로, 토큰을 소모한 병합은 항상 어떤 필드가 그 원인이었는지 알려줍니다.

옵션 B

LLM 중재

사이드바에서 중재 모델을 선택하면 규칙이 확정하지 못한 질문이 해당 LLM에 전달됩니다. LLM은 엔터티의 식별 정보, 각 필드의 설명, 그리고 기본 보강 언어로 표시된 모든 모델의 값을 확인한 뒤, 직접 값을 작성하지 않고 지목하는 방식으로만 답합니다.

중재자가 반환하는 값
선택된 모델상충하는 값이나 이견이 있는 객체의 경우: 어느 모델이 옳았는지를 결정합니다. 해당 모델의 값은 반환된 그대로, 채워진 모든 언어에 대해 복사됩니다.
항목 판정한 모델만 생성한 배열 항목의 경우: 유지할지, 제외할지, 아니면 중복되는 항목에 병합할지를 결정합니다 — 두 모델이 같은 막이나 같은 배역을 다르게 표현한 경우처럼.
추론다른 대안 대신 해당 모델 또는 판정을 선택한 이유
신뢰도결정에 대한 확신 정도(높음, 중간, 낮음)
중첩 데이터는 있는 자리에서 판정합니다

질문은 계층별로 이루어집니다. 먼저 엔터티 자체를, 그다음 매칭된 각 배열 항목을 자체 식별 정보를 컨텍스트로 삼아(“이 오페라의 1막”) 개별 호출로 질문하며, 중재자가 제외한 항목은 다시 묻지 않습니다. 프롬프트의 공통 부분은 첫 호출에서 캐시되므로 하위 호출은 훨씬 적은 비용으로 병렬 실행됩니다.

폴백: 중재 모델이 실패하면(타임아웃, 오류) 규칙 기반 결정이 그대로 적용되므로 항상 결과를 얻을 수 있으며, 어떤 방식이 적용되었는지는 레코드에 기록됩니다.

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, chosen_from_model, rule_used | reasoning, verdict, ... }]

동일한 감사 추적은 히스토리 페이지의 개요 탭에서 병합된 모든 레코드에 대해 표시됩니다. 배열 내부에서 내려진 결정 — 매칭된 항목의 필드, 유지되거나 제외된 항목 — 도 함께 나열되므로 유지된 내용만큼 제외된 내용도 명확히 확인할 수 있습니다. LLM이 중재한 레코드는 중재자를 모델로 표시하고, 규칙 기반 병합은 대신 병합에 사용된 모델들을 나열합니다. LLM 호출을 전혀 하지 않아 프롬프트도, 토큰도, 비용도 없기 때문입니다.

UI에서 보이는 것

퓨전이 완료되면 결과 패널의 “병합됨” 탭에 다음이 표시됩니다:

1
요약 헤더
해결 방식(규칙 기반 또는 LLM)과 “18개 일치 / 5개 해결 / 총 23개 필드” 같은 개수를 표시합니다.
2
fusion된 JSON
합의된 값과 해결된 충돌을 하나의 JSON 문서로 결합한 완전한 구조화 출력입니다.
3
충돌 보고서
각 충돌에 대한 펼칠 수 있는 카드로, 필드 경로, 해결 방식 배지(Majority Vote, Median, Union 등), 선택된 값이 강조 표시된 모든 model 값, 그리고 LLM arbitration이 사용된 경우 근거 텍스트를 보여줍니다.

batch 처리 시 자동 fusion

배치 보강에서는 모델을 두 개 이상 선택하면 융합이 자동으로 실행됩니다. “Merge Results”를 직접 클릭할 필요가 없습니다. 한 엔티티에 대해 모든 모델이 성공하는 즉시 융합이 실행되고, 병합된 결과가 개별 모델 출력과 나란히 표시됩니다. 모델 하나가 실패한 실행은 의도적으로 융합하지 않습니다. 남은 결과만 병합하면 부분적인 답을 합의된 답인 것처럼 조용히 게시하게 되기 때문입니다. 먼저 누락된 모델을 복구하세요. 실패한 전문 도메인을 재시도해 실행이 다시 온전해지면 융합이 자동으로 이루어집니다.

스트리밍 fusion: 단일 entity 및 batch enrichment 모두에서 fusion 진행 상황이 Server-Sent Events를 통해 스트리밍됩니다. fusion_started, conflicts_detected, fusion_completed 이벤트를 실시간으로 확인할 수 있습니다.

규칙 기반 vs LLM 중재: 각각 언제 사용하는가

규칙 기반 (즉시, 거의 항상 무료)
  • 투표 로직이 잘 작동하는 대부분의 사실/숫자 데이터
  • 비용이 중요한 대용량 또는 batch 처리
  • 예상 충돌이 적은 단순한 스키마
  • 결정론적이고 재현 가능한 결과를 원하는 경우
LLM 중재(추가 비용)
  • 해결을 위해 컨텍스트가 중요한 복잡한 스키마
  • 투표만으로는 부족한 텍스트 데이터(설명, 요약)
  • 근거와 함께 설명 가능한 결정이 필요한 경우
  • 정확도가 추가 비용만큼 가치 있는 고위험 enrichment