Query Expansion (쿼리 확장)
사용자의 원래 쿼리를 확장하거나 변형하여 검색 recall을 높이는 기법입니다.HyDE (Hypothetical Document Embeddings)
LLM이 질문에 대한 가상의 답변 을 생성하고, 그 답변의 임베딩으로 검색합니다. 왜 효과적인가? 질문과 답변은 구조적으로 다릅니다. 질문(“Delta Lake를 어떻게 최적화하나요?”)은 짧고 의문형이지만, 실제 문서는 서술형(“Z-ORDER BY를 사용하여 데이터를 정렬하고…”)입니다. 임베딩 모델은 형태가 유사한 텍스트 끼리 벡터 공간에서 가까이 배치하는 경향이 있으므로, 서술형 가상 답변이 서술형 실제 문서와 더 가까운 벡터를 갖게 됩니다. 가상 답변의 사실 여부는 중요하지 않습니다. 핵심은 관련 용어와 문체가 실제 문서와 유사해지는 것입니다.Step-back Prompting
구체적인 질문을 더 일반적인(추상화된) 질문 으로 변환하여 검색하는 기법입니다. Google DeepMind가 2023년에 제안했습니다. 왜 필요한가? 지나치게 구체적인 질문은 검색 공간을 좁혀 관련 문서를 놓칠 수 있습니다. 예를 들어 “DLT에서 SCD Type 2 구현 방법”이라는 질문은 SCD Type 2와 DLT를 동시에 다루는 문서가 없으면 검색에 실패합니다. 반면 “Delta Live Tables의 데이터 변환 패턴”이라는 일반화된 질문은 더 넓은 범위의 관련 문서를 검색할 수 있고, 그 안에서 SCD Type 2 관련 내용을 찾을 가능성이 높아집니다. 동작 원리: LLM이 원래 질문에서 핵심 개념을 추출하고, 해당 개념의 상위 카테고리 에 해당하는 질문을 생성합니다. 원래 질문과 Step-back 질문 모두 로 검색을 수행한 뒤 결과를 합치면, 구체적 매칭과 넓은 범위의 문맥을 동시에 확보할 수 있습니다.Multi-Query (다중 쿼리 생성)
하나의 질문을 관점이 다른 여러 질문 으로 변환한 뒤, 각각에 대해 검색을 수행하고 결과를 합치는 기법입니다. 왜 필요한가? 동일한 정보 요구(information need)라도 표현 방식에 따라 검색 결과가 크게 달라집니다. 예를 들어 “Delta Lake 성능 개선”과 “Delta Lake 최적화 방법”은 같은 의도지만, 임베딩 공간에서 서로 다른 위치에 놓일 수 있습니다. 여러 표현으로 검색하면 단일 쿼리로는 놓칠 수 있는 관련 문서를 추가로 확보할 수 있습니다. 동작 원리: LLM에게 원래 질문과 의미는 같지만 표현이 다른 3~5개의 변형 질문을 생성하도록 요청합니다. 각 변형 질문으로 독립적으로 검색을 수행한 뒤, 모든 결과를 합치고 중복을 제거합니다. LangChain의MultiQueryRetriever가 이 패턴을 내장 지원합니다.
참고 Query Expansion은 검색 recall(재현율, 관련 문서를 빠뜨리지 않는 비율)을 높이지만, LLM 호출 비용이 추가됩니다. Multi-Query, HyDE, Step-back 중 하나를 선택하여 적용하고, 평가를 통해 효과를 검증하세요. 일반적으로 Multi-Query는 범용적이고, HyDE는 질문-문서 간 어휘 격차가 큰 경우에, Step-back은 지나치게 구체적인 질문이 많은 경우에 효과적입니다.
Pre-Query Processing (쿼리 전처리)
검색 쿼리가 Retriever에 도달하기 전에 수행하는 최적화 기법들입니다. Query Expansion이 “같은 의미를 여러 표현으로” 검색하는 데 초점을 맞춘다면, Pre-Query Processing은 쿼리 자체를 변환하거나, 검색 대상을 사전에 좁히거나, 질문을 적합한 소스로 라우팅 하는 등 검색 환경 전체를 최적화합니다. 아래 표는 주요 전처리 전략을 비교합니다.| 전략 | 설명 | ML 모델 | Databricks 지원 |
|---|---|---|---|
| 메타데이터 사전 필터링 | ”2023년”, “영업팀” 등 조건을 LLM으로 추출 후 벡터 검색 전에 필터 적용. 탐색 범위를 대폭 축소 | LLM | ✅ |
| Query Rewrite | 모호하거나 불완전한 질문을 검색에 최적화된 형태로 재작성. 대화 맥락 반영 | LLM | ✅ |
| Contextual Retrieval | Anthropic 제안. 각 청크에 전체 문서의 문맥 요약을 Prepend. 청킹 시 손실되는 정보를 보완 | LLM | ✅ |
| Query Routing | 질문의 의도를 분류하여 적합한 데이터 소스(SQL DB, 벡터 DB, 웹)로 라우팅 | LLM | ✅ |
| 다중 쿼리 분해 | 복잡한 질문을 여러 하위 질문으로 분해, 각각 검색 후 결과를 병합 | LLM | ✅ |
메타데이터 사전 필터링 (Self-Query)
Query Rewrite
Query Rewrite(쿼리 재작성) 는 사용자의 원래 질문을 검색 엔진이 더 잘 이해할 수 있는 형태로 변환하는 기법입니다. 왜 필요한가? 사용자가 챗봇에 입력하는 질문은 대부분 검색에 최적화되어 있지 않습니다. 특히 멀티턴 대화 에서 “그거 어떻게 해?”, “이전 거랑 비교해줘” 같은 대명사와 생략 이 빈번하게 등장합니다. 이런 질문을 그대로 벡터 검색에 넣으면, “그거”가 무엇인지 모르기 때문에 관련 없는 문서가 반환됩니다. 어떻게 동작하는가? LLM에게 대화 이력과 최신 질문을 함께 제공하고, 대명사를 구체적 용어로 치환하고 생략된 맥락을 복원하여 독립적으로 검색 가능한 쿼리 로 변환하도록 지시합니다.- LLM 호출이 매 검색마다 추가 되므로 지연 시간과 비용이 증가합니다 (일반적으로 200~500ms 추가)
- 재작성 과정에서 사용자 의도가 왜곡될 수 있으므로, 원래 질문도 함께 검색하는 폴백(fallback) 전략 을 권장합니다
- 단일 턴 대화에서는 효과가 제한적이며, 멀티턴 대화에서 가장 큰 효과 를 발휘합니다
Contextual Retrieval (Anthropic 제안)
Contextual Retrieval 은 Anthropic이 제안한 기법으로, 각 청크에 전체 문서의 맥락 요약 을 앞에 붙여(prepend) 청킹 과정에서 손실되는 문맥 정보를 보완합니다.참고 Contextual Retrieval은 청킹 단계에서 한 번만 수행하면 되므로, 검색 시점에 추가 LLM 호출이 발생하지 않습니다. 초기 인덱싱 비용은 증가하지만, 검색 품질 향상 효과가 큽니다. Anthropic의 벤치마크에서 검색 실패율을 49% 감소 시킨 것으로 보고되었습니다.