Query Decomposition은 복잡한 사용자 질문을 여러 개의 간단한 하위 질문(sub-queries)으로 분해하여 각각 검색한 후 결과를 통합하는 RAG(Retrieval-Augmented Generation) 기법입니다.
원래 복잡한 질문:
"2023년 OpenAI의 GPT-4 출시가 구글의 검색 엔진 시장점유율과 주가에 미친 영향은?"
분해된 서브 쿼리:
1. "GPT-4는 언제 출시되었나?"
2. "GPT-4의 주요 기능은?"
3. "2023년 구글 검색 엔진 시장점유율 변화"
4. "2023년 구글 주가 변동"
5. "GPT-4가 검색 시장에 미친 영향"
복잡한 질문
↓
[LLM으로 분해]
↓
서브쿼리 1, 2, 3, 4, 5
↓
[각각 독립적으로 검색]
↓
결과 1, 2, 3, 4, 5
↓
[통합 (RRF 등 사용)]
↓
최종 답변 생성
원본 질문:
"React와 Vue.js의 성능, 학습곡선, 커뮤니티 크기를 비교해줘"
분해:
1. "React 성능 특징"
2. "Vue.js 성능 특징"
3. "React 학습 난이도"
4. "Vue.js 학습 난이도"
5. "React 커뮤니티 규모"
6. "Vue.js 커뮤니티 규모"
장점: 각 측면을 독립적으로 깊이 있게 검색 가능
원본 질문:
"코로나19 팬데믹이 원격근무 확산에 미친 영향과 이로 인한 상업용 부동산 시장 변화"
분해:
1. "코로나19 시기 원격근무 통계"
2. "2020-2023 원격근무 증가율"
3. "원격근무와 사무실 수요 관계"
4. "2020-2023 상업용 부동산 공실률"
5. "상업용 부동산 가격 변화 추이"
문제 상황 예시:
원본 질문 (구체적):
"우리 회사 2024년 Q3 매출이 감소한 이유를 경쟁사 A의 신제품 출시와 연관지어 분석해줘"
잘못된 분해 (너무 일반적):
1. "기업 매출 감소의 일반적인 원인" ❌
2. "경쟁 분석 방법론" ❌
3. "신제품 출시가 시장에 미치는 영향" ❌
4. "Q3 계절적 요인" ❌
올바른 분해 (구체성 유지):
1. "2024년 Q3 우리 회사 매출 데이터" ✓
2. "경쟁사 A 신제품 2024년 출시 정보" ✓
3. "우리 회사 주요 제품 시장점유율 변화" ✓
4. "경쟁사 A 신제품 고객 반응" ✓
시나리오:
원본 질문: "삼성전자 갤럭시 S24 배터리 수명"
적절한 검색 (분해 없이):
과도한 분해:
1. "삼성전자 역사" → 문서 X, Y, Z
2. "갤럭시 시리즈 특징" → 문서 P, Q, R
3. "스마트폰 배터리 기술" → 문서 L, M, N
4. "S24 배터리 수명" → 문서 A, B
문제:
분해 전 (단일 쿼리):
과도한 분해 후 (4개 서브쿼리):
결과: 관련성 낮은 문서들이 상위권에 진입
# 복잡도 판단
if is_complex_query(query):
sub_queries = decompose(query)
else:
# 단순 질문은 분해하지 않음
sub_queries = [query]
"다음 질문을 분해할 때, 원본의 구체적인 맥락과
고유명사를 반드시 유지하세요. 일반적이거나
학술적인 질문으로 바꾸지 마세요."
# 원본 쿼리 + 분해 쿼리 모두 사용
results = search(original_query, weight=0.6)
for sub_query in sub_queries:
results += search(sub_query, weight=0.4/len(sub_queries))
# 원본 쿼리 결과에 더 높은 가중치
rrf_score = (
2.0 * rrf(original_results) + # 2배 가중치
1.0 * rrf(decomposed_results)
)
Query Decomposition은 강력한 도구이지만, 무분별한 사용은 오히려 검색 품질을 해칠 수 있습니다. 질문의 복잡도와 특성에 따라 선택적으로 적용하는 것이 중요합니다.