Query Decomposition

김동준·2025년 11월 26일

LLM

목록 보기
50/50

Query Decomposition (쿼리 분해)

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 등 사용)]
    ↓
최종 답변 생성

구체적인 예시

예시 1: 기술 비교 질문

원본 질문:
"React와 Vue.js의 성능, 학습곡선, 커뮤니티 크기를 비교해줘"

분해:
1. "React 성능 특징"
2. "Vue.js 성능 특징"
3. "React 학습 난이도"
4. "Vue.js 학습 난이도"
5. "React 커뮤니티 규모"
6. "Vue.js 커뮤니티 규모"

장점: 각 측면을 독립적으로 깊이 있게 검색 가능

예시 2: 시간적 인과관계 질문

원본 질문:
"코로나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 신제품 고객 반응" ✓

RRF 점수 희석(Dilution) 문제

시나리오:

원본 질문: "삼성전자 갤럭시 S24 배터리 수명"

적절한 검색 (분해 없이):

  • 문서 A (갤럭시 S24 리뷰): 순위 1위
  • 문서 B (배터리 테스트): 순위 2위
  • RRF 점수가 집중됨

과도한 분해:
1. "삼성전자 역사" → 문서 X, Y, Z
2. "갤럭시 시리즈 특징" → 문서 P, Q, R
3. "스마트폰 배터리 기술" → 문서 L, M, N
4. "S24 배터리 수명" → 문서 A, B

문제:

  • 정작 핵심 문서 A, B의 RRF 점수가 희석됨
  • 관련성 낮은 문서들(X, Y, Z, P, Q, R, L, M, N)과 섞임
  • 최종 순위에서 A, B가 하위로 밀려날 수 있음

점수 계산으로 보는 희석 효과

분해 전 (단일 쿼리):

  • 문서 A: 1/(60+1) = 0.0164
  • 문서 B: 1/(60+2) = 0.0161

과도한 분해 후 (4개 서브쿼리):

  • 문서 A: 1/(60+5) + 1/(60+8) + 1/(60+12) + 1/(60+1) = 0.0614 (다른 쿼리에서도 등장)
  • 문서 X: 1/(60+1) + 1/(60+2) = 0.0325 (관련성 낮지만 점수 얻음)
  • 문서 Y: 1/(60+3) + 1/(60+4) = 0.0315

결과: 관련성 낮은 문서들이 상위권에 진입

Query Decomposition의 장단점

장점

  1. 복잡한 질문 처리: 다면적 질문을 체계적으로 분석
  2. 검색 커버리지 증가: 여러 각도에서 정보 수집
  3. 부분 답변 가능: 일부 서브쿼리만 답변 가능해도 유용

단점

  1. 비용 증가: 검색 호출 횟수 증가 (예: 1회 → 5회)
  2. 지연 시간: 여러 검색을 순차/병렬 처리 시간
  3. 희석 효과: 핵심 문서의 중요도가 분산될 수 있음
  4. 일반화 위험: 구체적인 질문이 추상적으로 변질

최적화 전략

1. 선택적 분해

# 복잡도 판단
if is_complex_query(query):
    sub_queries = decompose(query)
else:
    # 단순 질문은 분해하지 않음
    sub_queries = [query]

2. 구체성 유지 프롬프트

"다음 질문을 분해할 때, 원본의 구체적인 맥락과 
고유명사를 반드시 유지하세요. 일반적이거나 
학술적인 질문으로 바꾸지 마세요."

3. 하이브리드 접근

# 원본 쿼리 + 분해 쿼리 모두 사용
results = search(original_query, weight=0.6)
for sub_query in sub_queries:
    results += search(sub_query, weight=0.4/len(sub_queries))

4. 적응형 RRF 가중치

# 원본 쿼리 결과에 더 높은 가중치
rrf_score = (
    2.0 * rrf(original_results) +  # 2배 가중치
    1.0 * rrf(decomposed_results)
)

Query Decomposition은 강력한 도구이지만, 무분별한 사용은 오히려 검색 품질을 해칠 수 있습니다. 질문의 복잡도와 특성에 따라 선택적으로 적용하는 것이 중요합니다.

profile
Story Engineer

0개의 댓글