컨텍스트
#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 종료 시점에 다음 정보가 있어야 결정 가능:
TODO (지금 ~ W4 종료)
참고
- 본 이슈는 W4 종료까지 결정 보류. 그 전에 코멘트로 정보가 쌓이는 형태로 운영
- 멘토 정이태(Hardy)에게도 한 번 의견 묻기 (하이브리드 권장하셨으니 어떤 형태를 염두에 두셨는지)
- 관련: #1 LLM 통일 결정, #3 VectorRAG 측정
컨텍스트
#1 결정에 따라 발표 자료의 핵심 비교 표는 다음과 같다 (모두 Kimi 통일):
"Hybrid"가 정확히 무엇을 의미하는가? 두 가지 설계가 가능하며, 각각 발표 서사가 다르다.
두 가지 설계 옵션
옵션 A: Score Fusion
Vector retrieval과 Graph retrieval을 둘 다 호출하고 결과를 RRF/score 합성 후 LLM에 한 번에 투입.
장점:
단점:
옵션 B: Routing Hybrid
질문 유형을 먼저 분류해서 Vector / Graph 중 적합한 쪽으로 라우팅. 또는 둘 다 호출 후 Debate Pool로 합성.
장점:
단점:
발표 임팩트 비교
옵션 B로 가면 발표에 질문 유형별 승률 표를 추가할 수 있다:
이런 분해는 SEOCHO 라우팅 정책의 경험적 정당화가 된다 — "Layer C가 글로벌 요약에 강하다는 건 이론이 아니라 우리 데이터에서 측정된 사실이다."
옵션 A는 이런 분해 분석이 어렵다. "Vector와 Graph를 그냥 합쳤다"가 끝.
잠정 의견
옵션 B 권장. 단, 구현 복잡도 때문에 W5 일정에 부담이 있을 수 있어서 fallback 전략을 둔다:
결정 시점
W4 종료 시점 (5/15 부근) 에 결정.
근거:
agent/router.py단일 파일에 라우팅 로직 격리)결정 시 고려할 입력
W4 종료 시점에 다음 정보가 있어야 결정 가능:
TODO (지금 ~ W4 종료)
agent/router.py만들 때 mode 토글 가능한 구조로 설계 (옵션 A/B 모두 수용)docs/adr/0002-hybrid-design.md작성참고