[0. 결정 요약 (TL;DR)]

• AWS Bedrock Cohere Rerank 3.5(cohere.rerank-v3-5:0) 도입.
• 실도입 의사결정의 핵심: 운영요건 - 충분한 처리량(RPM)과 데이터 거버넌스
  • 거버넌스: Bedrock(AWS 내부)/Azure(이미 사용 중인 벤더) 두 경로를 허용하고 제3자 Cohere Direct만 배제
  • RPM: v4.0-pro가 있는 Azure 경로는 RPM 제약이 있어, 충분한 RPM을 AWS 쿼터로 확보하는 Bedrock 3.5로 결정
• 성능축:
  • 후보 리랭커 3종(Cohere / mxbai)이 실제 파이프라인 평가에서 모두 baseline을 충분히 넘음.
  • 검색 품질은 무엇을 골라도 확보되는 전제 조건이었고, 모델 선택의 변별 요인이 아니었음

성능: 후보 3종 동률 (모두 baseline 압도)   → 전제 충족, 변별 요인 아님
        │
운영요건 관문
  ├─ 거버넌스: AWS 내부(Bedrock)/기존 벤더(Azure) 허용, 제3자(Cohere Direct) 배제
  └─ RPM: v4.0-pro 경로인 Azure는 제약 / Bedrock은 AWS 쿼터로 충분
        │
        ▼
  AWS Bedrock (Cohere = 3.5뿐) ── 성능 동률이라 v4→3.5 손실 없음
        │
        ▼
  Cohere Rerank 3.5 (도쿄, ap-northeast-1)

최종 선택

“평가 1등”과 “도입 모델”이 다른 이유: 순수 성능 미세 우위는 Cohere v4.0-pro였으나 채택하지 않았다. v4.0-pro의 거버넌스 충족 경로는 Azure뿐인데 Azure는 RPM 제약이 있었고, 성능은 3종 동률이라 v4→3.5로 내려도 손실이 없었다.

[1. 배경 / 목적]

기존 RAG는 벡터 검색(OpenSearch hybrid) 결과의 상위 top-k만 잘라 LLM에 전달(baseline).

• 기존 방식의 한계:
  • cross-lingual 및 의미 변형 매칭 부재: 벡터 유사도 순서에만 의존 → 쿼리와 다른 언어/표현의 정답 청크를 상위로 못 올림
  • 정답 청크가 top-30 안에는 있으나 top-3 밖이면 컨텍스트에 미포함

reranker는 1차 검색이 넓게 회수(top-30)한 후보를 쿼리-문서 쌍으로 재채점해 top-n을 정밀 재정렬. 목표는 답변 근거 청크의 상위 노출률/검색 품질 향상.

제약 조건

[2. 후보 탐색]

2.1 3조건 교차 필터

리랭커 시장(MTEB-R·BEIR·MIRACL, 커뮤니티 채택도, 클라우드 가용성)에서 Top 10을 산출한 뒤 요건 3조건으로 필터링.

조건: ① Top 10 · ② EN/JA/KO 지원 · ③ AWS Bedrock 또는 Azure 매니지드 제공

3조건을 모두 만족하는 매니지드 리랭커는 Cohere Rerank가 유일.

2.2 Cohere 제공 경로

경로마다 제공 버전·데이터 처리 위치·RPM이 다르며, 이것이 최종 결정을 좌우함.

• 최신 v4.0-pro는 Azure·Cohere Direct에만 있음.
• Cohere Direct는 제3자 노출로 배제되고, 남는 Azure 경로는 RPM 제약이 있음.
• Bedrock은 3.5만 제공하지만 AWS 쿼터로 충분한 RPM을 확보할 수 있음.

2.3 self-host 배제

오픈소스 self-host(ECS+GPU)는 이번 단계에서 배제했다. ① 손익분기가 월 10~20만 쿼리 이상(도입 초기 트래픽 미달), ② GPU 상시 운영·서빙·스케일링 오버헤드. 단, 트래픽이 손익분기를 넘으면 self-host(Apache 2.0인 mxbai) 전환 경로는 남겨둔다.

[3. 성능 검증]

결론: 후보 3종은 모두 baseline을 압도했고, 서로는 통계적으로 동률. → 결정축을 성능에서 운영 요건으로 넘긴 근거.

3.1 Phase 1 - 공개 벤치마크

• Cohere v4는 블랙박스: 벤치마크 수치 전량 미공개 → 직접 평가 필수
• mxbai는 JA/KO 상대 약점: EN 강, JA/KO 절대값 중간(bge-v2-m3 대비 JA −10.8, KO −10.2)

→ Phase 1로는 결론 불가, 실제 파이프라인 평가로 이월.

3.2 Phase 2 - 파이프라인 통합 평가 (LLM-as-Judge)

• 방식: LLM 생성 도메인 문서 9건(EN/JA/KO 각 3건) 실제 업로드 → 전체 파이프라인(파싱→청킹→임베딩→OpenSearch) 통과 → 4개 시스템(baseline / Cohere-pro / Cohere-fast / mxbai)이 top-3 회수
• 판정: Claude Opus 4.7, Language-Neutral Pairwise(언어 정합성 무시) 30건 층화표본 + Recall@3

Pairwise Win Rate

1. 3종 모두 baseline 압도 - 31.7% → 55~57%, 전 언어 일관. head-to-head에서 baseline은 3종 모두에 대패(vs Cohere-fast 2승/15패/13무).
2. 3종 간은 동률 - 격차 ±2%p, tie 53.3%, 승패 균등(pro:fast 6:6, fast:mxbai 8:8). Recall@3 모두 0.97.

검색 품질은 어느 리랭커든 확보된다. 성능은 변별 요인이 아니라 전제 조건. 도입 모델은 운영 요건에서 결정한다.

• 상세 수치

  • 모델별 평균 (n=86, Pairwise n=30)

    모델	Answerability	Recall@3	Pairwise
    baseline	3.83	1.00	31.7%
    Cohere v4.0-pro	3.52	0.97	55.0%
    Cohere v4.0-fast	3.42	0.97	57.2%
    mxbai	3.45	0.97	56.1%

  • Head-to-Head (n=30, 행 승/열 승/무)

    	baseline	pro	fast	mxbai
    baseline	-	3/11/16	2/15/13	1/13/16
    pro	11/3/16	-	6/6/18	6/5/19
    fast	15/2/13	6/6/18	-	8/8/14
    mxbai	13/1/16	5/6/19	8/8/14	-

  전체 tie 96/180 = 53.3%.

3.3 레이턴시 관찰

모델 차이보다 경로(인프라) 차이가 훨씬 크다.

→ Azure 경유 페널티(약 +1초)가 모델 간 미세 차이(187 ms)를 흡수. 경로 선택이 레이턴시를 좌우하며, 이 역시 운영요건 심사의 근거가 된다.

[4. 운영요건 체크]

성능이 전제로 충족된 이상 결정은 ① 거버넌스(후보 압축) · ② RPM(최종 결정) · ③ 레이턴시·비용 순으로 이뤄졌다.

4.1 데이터 거버넌스 - 후보를 두 경로로 압축

• 리랭커 입력은 고객 업로드 문서 원문 청크.
• 데이터가 어느 사업자 경계를 넘느냐는 계약·컴플라이언스·신뢰 문제.
• 기존 스택은 AWS(S3·OpenSearch에 문서·임베딩 상주)와 Azure OpenAI(임베딩·LLM)를 이미 사용 중이므로, 두 사업자는 신뢰경계 안이다.

→ 거버넌스는 후보를 Bedrock·Azure 두 경로로 압축하고, 신규 제3자인 Cohere Direct만 배제한다. Bedrock·Azure 사이의 결정은 RPM으로 넘어간다.

4.2 처리량 (RPM) - 최종 결정

거버넌스를 통과한 두 경로 중, v4.0-pro가 있는 Azure는 RPM 제약이 걸린다. Bedrock은 AWS 쿼터로 충분한 처리량을 확보한다.

Bedrock은 기존 AWS 쿼터 체계에서 처리량을 확보·증설할 수 있어, 거버넌스 비용 없이 충분한 RPM을 얻는다. 이 지점에서 v4.0-pro(Azure) 대신 3.5(Bedrock)가 확정된다.

4.3 레이턴시 · 비용 (보조)

• 레이턴시: Bedrock은 AWS 내부 호출 → 타 클라우드 경유(Azure +1초) 페널티 없음
• 비용: $2.00/1K 쿼리 - 손익분기(월 10~20만 쿼리) 전까지 self-host GPU 상시비(~$360/월+)보다 유리
• 리전: 도쿄(ap-northeast-1) + EN/JA/KO 명시 지원

[5. 최종 결정]

순수 성능 미세 우위는 v4.0-pro였으나, 도입은 Bedrock Cohere Rerank 3.5다. 셋이 함께 이 결론을 만든다.

1. 거버넌스로 후보 압축 - 신뢰경계 안인 Bedrock·Azure만 허용, 제3자 Cohere Direct 배제
2. RPM이 v4.0-pro를 탈락시킴 - v4.0-pro의 거버넌스 충족 경로는 Azure뿐인데 Azure는 RPM 제약. 반면 Bedrock은 AWS 쿼터로 충분한 RPM 확보 (단 3.5만 제공)
3. 성능 손실 없음 - 3종 tie 53% 동률. v4→3.5로 내려도 실질 손실 없음

성능이 동률이므로 최신 v4.0을 고집할 이유가 없고, 충분한 RPM을 거버넌스 충족 상태로 확보하는 경로가 Bedrock(3.5)뿐이었다. 성능을 타협한 차선책이 아니라, 성능이 확보된 상태에서 운영요건을 최적화한 최선책이다.