8.7.1 검색된 문서 간 정보가 상충할 때의 해결 오라클(Majority Vote 등)

8.7.1 검색된 문서 간 정보가 상충할 때의 해결 오라클(Majority Vote 등)

기업의 RAG 파이프라인이 마주하는 가장 곤혹스러운 딜레마는, 검색기(Retriever)가 유저의 질문을 해결하기 위해 여러 개의 문서를 가져왔는데 그 문서들이 서로를 부정하는 모순된 사실을 주장할 때 발생한다.

예를 들어 “입사 1년 차의 휴가 일수는 며칠인가?“라는 질문에 대해, 검색기가 동일한 회사의 규정 데이터베이스에서 가져온 3개의 청크(Chunk)가 다음과 같다고 가정해 보자.

  • Chunk A (2020년 작성): “휴가 일수는 15일이다.”
  • Chunk B (2022년 작성): “휴가 일수는 12일이다.”
  • Chunk C (작성일 미상): “신입 사원의 휴가는 15일 보장.”

타겟 모델에게 이 혼란스러운 3개의 문서를 그대로 던져주면, LLM은 ’15일’과 ‘12일’ 사이에서 확률적 방황을 하다가 “휴가 일수는 12일 또는 15일입니다“라는 매우 무책임하고 비결정적인(Nondeterministic) 답변을 렌더링하고 만다. 오라클 시스템은 이러한 텍스트 혼합(Mixing)을 원천 차단하기 위해, 응답 생성 이전에 먼저 **가장 지배적인 진실(Dominant Truth)을 수학적으로 결정하는 합의 알고리즘(Consensus Algorithm)**을 가동해야 한다.

1. 다중 에이전트 다수결(Majority Vote) 오라클 설계

자율 에이전트(Autonomous Agent) 방법론에서 차용한 가장 직관적이고 강력한 충돌 해결 모델은 Majority Vote (다수결 투표) 메커니즘이다. 오라클 파이프라인은 텍스트 생성을 즉시 멈추고, 충돌하는 청크들을 각각 독립적인 평가 인스턴스(Evaluator Instance)에 병렬로 던져 가상의 ’투표장(Voting Context)’을 연다.

  1. 독립된 전제 추출 (Independent Premise Extraction): 오라클은 타겟 모델을 직접 부르지 않고, 가벼운 제어용 SLM(Small Language Model)이나 파서(Parser)를 3개 스폰(Spawn)시켜 각 청크로부터 핵심 팩트(Key Fact)만 이산적인 데이터(Discrete Data)로 뽑아낸다. (결과: Fact A = 15, Fact B = 12, Fact C = 15)
  2. 모드(Mode) 연산을 통한 다수결 확정: 오라클 백엔드 로직은 추출된 팩트들의 단순 배열 [15, 12, 15]에서 최빈값(Mode)을 기계적으로 계산한다. 수학적으로 가장 많은 지지(Support)를 확보한 ’15’가 최종 정답지(Ground Truth)로 승격된다.
  3. 패배한 지식의 강제 가지치기(Pruning): 오라클은 타겟 LLM의 프롬프트에서 패배한 소수 의견인 Chunk B(12일) 영역을 메모리에서 물리적으로 잘라내어 소각(Drop)해 버린다. 타겟 LLM은 오직 승리한 Chunk AChunk C만을 컨텍스트로 제공받으므로, 애초에 12일이라는 텍스트를 생성할 물리적 확률 자체가 0\%로 제어된다.

2. 문서 권위도(Authority Weighting) 기반의 가중치 투표

하지만 모든 문서의 가치가 평등(1인 1표)한 것은 아니다. 사내 게시판에 쓰인 무명 직원의 메모(Chunk C)가, 대표이사가 서명한 공식 취업규칙(Chunk B)을 다수결로 이겨버린다면 이는 시스템의 재앙이다. 이를 해결하기 위해 오라클은 **메타데이터 가중치(Metadata Weighting)**를 다수결 알고리즘에 결합한다.

Vector DB에 청크를 인덱싱할 때, 각 데이터의 메타데이터 필드에 authority_level (권위도) 속성을 미리 정수로 하드코딩해 두는 방식이다.

  • 공식 회사 내규 (Official Policy): Weight 5
  • 부서 공지 (Department Notice): Weight 3
  • 사내 게시판/이메일 (Slack/Board): Weight 1

충돌이 발생하면 오라클은 단순 개수(Count)가 아니라, 이 가중치 합산(Weighted Sum)을 통해 승자를 결정한다. Chunk C(가중치 1)와 Chunk A(가중치 1)가 연합하여 15일을 주장하더라도 그 합은 2에 불과하지만, 공식 내규인 Chunk B(가중치 5)가 12일을 보장한다면, 오라클은 압도적인 권위 가중치 산술 연산에 따라 15일을 폐기하고 12일을 최종 정답으로 락인(Lock-in)한다.

3. Self-Consistency (자기 일관성) 체인을 통한 다중 온도(Temperature) 평가

다수결 오라클은 비단 물리적으로 다른 문서를 분리 평가할 때만 쓰이는 것이 아니다. 문서의 의미가 너무 모호하여 추출된 팩트 자체가 흔들리는 고난도 상황에서는 단일 프롬프트를 대상으로 Self-Consistency (자기 일관성) 기술을 가동한다.

오라클 미들웨어는 타겟 LLM의 temperature를 의도적으로 0.7정도로 스파이크 시켜(분산을 키워) 동일한 컨텍스트와 질문으로 답변 생성을 5회 반복(Sampling)한다. 만약 5회의 결과 중 4회가 일치하는 결론을 내면 오라클은 이를 ‘논리적 수렴(Logical Convergence)’ 상태로 판단하고 해당 텍스트를 배포한다. 하지만 5회의 샘플링 결과가 [A, B, A, C, D]처럼 중구난방으로 퍼진다면 (낮은 Self-Consistency), 오라클은 해당 지식이 ‘인간 전문가의 해석 없이는 판별 불가한 임계적 충돌’ 공간에 있음을 인정하고, 즉각 폴백(Fallback) 방어벽을 쳐 인간 상담원(Human-in-the-loop)에게 트랜잭션을 이관(Escalation)시킨다.

상충하는 문서 간의 전쟁터에서 LLM의 유창한 언어능력을 맹신하는 것은 자살행위다. 오직 투표 수학(Voting Mathematics)과 가중치 연산(Weight Calculus)이라는 결정론적 통제만이 이 지식의 무정부 상태를 평정할 수 있다.