Skip to content

[Design] Hybrid 모드의 정체 — Score Fusion vs Routing Hybrid (W4 종료 시 결정) #4

Description

@TaskerJang

컨텍스트

#1 결정에 따라 발표 자료의 핵심 비교 표는 다음과 같다 (모두 Kimi 통일):

| 시스템              | Retrieval                | LLM     |
|---------------------|--------------------------|---------|
| VectorRAG (Before)  | BM25 단독                | Kimi    |
| VectorRAG (Full)    | BM25+Dense+RRF+Reranker  | Kimi    |
| GraphRAG            | Layer A/B/C 라우팅       | Kimi    |
| Hybrid              | ???                      | Kimi    |  ← 본 이슈가 정의해야 할 부분

"Hybrid"가 정확히 무엇을 의미하는가? 두 가지 설계가 가능하며, 각각 발표 서사가 다르다.

두 가지 설계 옵션

옵션 A: Score Fusion

Vector retrieval과 Graph retrieval을 둘 다 호출하고 결과를 RRF/score 합성 후 LLM에 한 번에 투입.

Question
   ├─→ Vector retrieval (BM25 + Dense + Rerank) → top-k 청크
   ├─→ Graph retrieval (Layer A/B/C 통합) → 관련 entity/subgraph
   └─→ Score Fusion → 합쳐진 컨텍스트 → LLM → 답변

장점:

  • 구현 단순. Vector와 Graph가 각자 동작하면 합성만 하면 됨
  • 결과 풍부 — 두 검색의 강점을 모두 활용

단점:

  • 컨텍스트 비용↑ (LLM 토큰 사용량 증가)
  • 중복 우려 (같은 정보가 양쪽에서 나올 수 있음)
  • "왜 이 답이 나왔나" 추적이 복잡

옵션 B: Routing Hybrid

질문 유형을 먼저 분류해서 Vector / Graph 중 적합한 쪽으로 라우팅. 또는 둘 다 호출 후 Debate Pool로 합성.

Question
   └─→ Router (LLM-based 분류기 또는 rule-based)
         ├─→ "단일 사실"   → Vector
         ├─→ "관계 질의"   → Graph (Layer B)
         ├─→ "글로벌 요약" → Graph (Layer C)
         └─→ "복잡 질의"   → 둘 다 호출 + Debate Pool 합성

장점:

  • 비용 효율 — 질문당 한 번만 검색
  • SEOCHO 철학과 일치 (커리큘럼의 Routing Agent / Debate Pool이 정확히 이것)
  • 발표 임팩트 높음 — "단순 합치기가 아니라 라우팅 정책 자체가 작품"
  • 질문 유형별 분해 분석이 자연스럽게 가능

단점:

  • 분류기 성능에 의존 (틀리면 답이 망가짐)
  • 구현 복잡도↑

발표 임팩트 비교

옵션 B로 가면 발표에 질문 유형별 승률 표를 추가할 수 있다:

| 질문 유형              | Vector 승률 | Graph 승률 | Hybrid 승률 |
|-------------------------|-------------|------------|-------------|
| 단일 사실 ("X의 매출?")  | 70%         | 60%        | 75%         |
| 관계 질의 ("A와 B 관계") | 30%         | 85%        | 80%         |
| 글로벌 요약 ("전체 흐름")| 20%         | 50%        | 75%         |

이런 분해는 SEOCHO 라우팅 정책의 경험적 정당화가 된다 — "Layer C가 글로벌 요약에 강하다는 건 이론이 아니라 우리 데이터에서 측정된 사실이다."

옵션 A는 이런 분해 분석이 어렵다. "Vector와 Graph를 그냥 합쳤다"가 끝.

잠정 의견

옵션 B 권장. 단, 구현 복잡도 때문에 W5 일정에 부담이 있을 수 있어서 fallback 전략을 둔다:

  • W5 초반: 옵션 B 시도 (분류기 + 라우팅)
  • W5 중반 시점: 분류기 정확도가 부족하면 옵션 A로 fallback. "Routing Hybrid는 future work" 으로 발표
  • W5 후반: 결정된 Hybrid로 40 QA 측정

결정 시점

W4 종료 시점 (5/15 부근) 에 결정.

근거:

  • W3-W4 동안 GraphRAG (Layer A/B/C) 가 어느 정도 동작해야 두 옵션의 가능성을 가늠할 수 있음
  • 지금 (W1) 결정하면 미지의 변수가 너무 많음
  • 결정만 미루는 것이지, W3-W4 동안 GraphRAG 설계 자체는 두 옵션 모두를 지원할 수 있게 유지 (agent/router.py 단일 파일에 라우팅 로직 격리)

결정 시 고려할 입력

W4 종료 시점에 다음 정보가 있어야 결정 가능:

  • GraphRAG (Layer A/B/C) 동작 여부 + 각 Layer의 단독 성능 (40 QA로 미니 측정)
  • 질문 유형별 분포 (이미 알려져 있음 — numerical 23, factual 9, summary 4, negative 4)
  • 분류기 정확도 추정 (간단한 LLM-based 분류로 sample 10개 정도 분류 정확도 미리 봄)
  • W5 남은 시간 + Opik 작업 부담

TODO (지금 ~ W4 종료)

  • (W3-W4) agent/router.py 만들 때 mode 토글 가능한 구조로 설계 (옵션 A/B 모두 수용)
  • (W4 후반) 분류기 정확도 sample 측정
  • (W4 종료) 본 이슈 update 코멘트로 결정 박제 + ADR docs/adr/0002-hybrid-design.md 작성
  • (W5) 결정된 Hybrid 구현
  • (W5) 40 QA 측정 + 질문 유형별 승률 표 작성

참고

  • 본 이슈는 W4 종료까지 결정 보류. 그 전에 코멘트로 정보가 쌓이는 형태로 운영
  • 멘토 정이태(Hardy)에게도 한 번 의견 묻기 (하이브리드 권장하셨으니 어떤 형태를 염두에 두셨는지)
  • 관련: #1 LLM 통일 결정, #3 VectorRAG 측정

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions