검색이 안 되는 건 문서 탓이 아니라 질문 탓일 수 있습니다
RAG 시스템을 열심히 구축해서 문서도 잘 넣고 벡터 데이터베이스도 갖췄는데, 막상 질문을 던지면 엉뚱한 답이 돌아오는 경험, 해보셨나요? 많은 분이 이 문제를 해결하려고 청킹 전략을 바꾸거나 리랭킹 모델을 추가하는 데 집중합니다. 물론 중요한 접근이지만, 사실 검색 품질을 가장 극적으로 바꿀 수 있는 지점은 그보다 훨씬 앞단에 있습니다. 바로 RAG 쿼리 변환(Query Transformation)입니다. 사용자가 입력한 질문을 검색에 최적화된 형태로 변환해주는 이 기법은, 같은 인프라에서도 검색 정확도를 20~40%까지 끌어올리는 사례가 보고될 만큼 강력합니다.
이 글에서는 2026년 현재 실무에서 가장 많이 쓰이는 RAG 쿼리 변환 기법 4가지를 하나씩 뜯어봅니다. 각 기법이 어떤 원리로 작동하고, 어떤 상황에서 효과적이며, 실제로 어떻게 구현하는지를 구체적으로 안내해 드리겠습니다. 청킹이나 리랭킹을 이미 적용한 분이라면, 쿼리 변환을 추가하는 것만으로 체감할 수 있는 품질 향상을 경험하실 수 있을 것입니다.
사용자 질문을 그대로 검색하면 안 되는 이유
RAG 파이프라인에서 사용자의 질문은 곧바로 임베딩 모델을 거쳐 벡터로 변환되고, 이 벡터와 가장 유사한 문서 청크들이 검색됩니다. 문제는 사용자가 일상어로 던지는 질문과 실제 문서에 담긴 표현 사이에 상당한 괴리가 있다는 점입니다. 이 괴리를 흔히 시맨틱 갭(Semantic Gap)이라고 부릅니다.
예를 들어볼까요? 사내 문서 RAG 시스템에 누군가 이렇게 질문합니다.
- “지난달 매출 관련된 거 좀 찾아줘”
이 질문에는 여러 문제가 숨어 있습니다. 첫째, “지난달”이 구체적으로 몇 월인지 시스템은 알 수 없습니다. 둘째, “매출 관련된 거”라는 표현이 너무 모호합니다. 매출 보고서를 원하는 것인지, 매출 분석 자료를 원하는 것인지, 매출 목표 대비 실적을 원하는 것인지 구분이 안 됩니다. 셋째, 실제 문서에는 “2026년 6월 월간 매출 실적 보고”처럼 공식적인 제목이 붙어 있을 텐데, 구어체 질문의 임베딩과 이런 공식 문서 제목의 임베딩은 벡터 공간에서 상당히 떨어져 있을 수 있습니다.
이런 문제가 발생하는 근본 원인은 세 가지입니다.
- 표현의 불일치: 사용자는 구어체로, 문서는 전문 용어와 공식 표현으로 작성됩니다. “서버가 느려요”와 “응답 지연 현상 분석 보고서”는 같은 내용을 다루지만 표현이 완전히 다릅니다.
- 정보의 불완전성: 사용자는 머릿속 맥락을 생략한 채 질문합니다. 자신이 어떤 프로젝트에 대해, 어떤 기간의, 어떤 측면을 궁금해하는지 다 풀어쓰지 않습니다.
- 질문과 답변의 구조적 차이: 질문은 “왜 ~하나요?”처럼 의문형이고, 문서는 “~의 원인은 다음과 같다”처럼 서술형입니다. 임베딩 모델이 아무리 좋아도 이 구조적 차이를 완벽히 극복하기는 어렵습니다.
쿼리 변환은 이 세 가지 문제를 검색 이전 단계에서 선제적으로 해결합니다. 사용자 질문을 받아서, LLM의 언어 이해 능력을 활용해 검색에 더 적합한 형태로 바꿔주는 것입니다. 마치 도서관에서 사서가 “그 책 있어요?”라는 막연한 질문을 듣고 “아, 이런 주제의 이런 종류 책을 찾으시는 거죠?”라고 구체화해주는 것과 같은 역할입니다.
기법 1: 쿼리 재작성(Query Rewriting)
가장 직관적이고 구현도 간단한 첫 번째 기법은 쿼리 재작성입니다. 사용자가 입력한 자연어 질문을 LLM에게 넘겨서, 검색에 더 적합한 형태로 다시 작성하게 하는 방법입니다.
단일 쿼리 재작성
가장 기본적인 형태는 사용자의 질문 하나를 개선된 질문 하나로 바꾸는 것입니다. LLM에게 “다음 사용자 질문을 문서 검색에 최적화된 형태로 재작성해주세요”라는 시스템 프롬프트를 주고, 사용자 질문을 전달합니다.
예를 들어 사용자가 “우리 앱에서 로그인이 안 될 때 어떻게 해야 해?”라고 물으면, LLM은 이를 “애플리케이션 로그인 실패 시 문제 해결 방법 및 인증 오류 대응 절차”처럼 검색 친화적인 문장으로 변환할 수 있습니다. 구어체 표현이 사라지고, 관련 키워드(인증 오류, 문제 해결, 대응 절차)가 추가되면서 문서와의 시맨틱 매칭 확률이 높아집니다.
구현은 매우 간단합니다. RAG 파이프라인의 검색 단계 직전에 LLM 호출을 하나 추가하면 됩니다. 시스템 프롬프트에는 “원래 의미를 보존하면서 검색에 유리한 키워드와 전문 용어를 포함하여 재작성하라”는 지시를 넣고, 사용자 질문을 입력으로 전달합니다. 반환된 재작성 쿼리로 벡터 검색을 수행하면 됩니다.
멀티 쿼리 확장(Multi-Query Expansion)
단일 재작성에서 한 걸음 더 나아간 것이 멀티 쿼리 확장입니다. 하나의 사용자 질문을 서로 다른 관점에서 바라본 3~5개의 쿼리로 확장하는 기법입니다. 각각의 쿼리로 독립적으로 검색을 수행한 뒤, 결과를 합치고 중복을 제거합니다.
“머신러닝 모델의 과적합을 어떻게 방지하나요?”라는 질문을 예로 들면, 멀티 쿼리 확장은 다음과 같은 변형을 만들어냅니다.
- “머신러닝 과적합(overfitting) 방지 기법과 정규화 방법”
- “딥러닝 모델 일반화 성능 향상을 위한 드롭아웃과 데이터 증강 전략”
- “학습 데이터 부족 시 모델 과적합 문제 해결 방법론”
- “교차 검증과 조기 종료를 활용한 과적합 탐지 및 예방”
각 쿼리는 같은 주제를 다른 용어와 관점으로 표현하고 있습니다. 첫 번째 쿼리로는 정규화 관련 문서가, 두 번째로는 드롭아웃 관련 문서가, 세 번째로는 데이터 관련 문서가 검색될 수 있습니다. 이렇게 하면 단일 쿼리로는 놓쳤을 관련 문서들까지 폭넓게 잡아낼 수 있습니다.
멀티 쿼리의 결과를 합칠 때는 주로 Reciprocal Rank Fusion(RRF) 알고리즘을 씁니다. 여러 검색 결과 목록에서 공통으로 상위에 등장하는 문서에 높은 점수를 부여하는 방식인데, 하이브리드 검색에서도 많이 쓰이는 검증된 기법입니다.
쿼리 재작성의 장점과 한계
쿼리 재작성의 가장 큰 장점은 구현이 쉽다는 것입니다. 기존 RAG 파이프라인에 LLM 호출 한 줄만 추가하면 되므로, 인프라 변경 없이 즉시 적용할 수 있습니다. 특히 멀티 쿼리 확장은 다양한 관점을 커버하므로, 사용자가 어떤 식으로 질문하든 관련 문서를 찾을 확률이 높아집니다.
반면 한계도 분명합니다. LLM이 재작성한 쿼리가 원래 의도에서 벗어날 수 있고, 멀티 쿼리의 경우 검색 횟수가 3~5배로 늘어나면서 지연 시간이 증가합니다. 또한 모호한 질문을 재작성해도 여전히 모호할 수 있다는 근본적 한계가 있습니다. 질문 자체에 정보가 부족하면 LLM도 마법을 부릴 수는 없으니까요.
기법 2: HyDE, 가상 답변으로 검색 정확도 끌어올리기
두 번째 기법은 조금 발상의 전환이 필요합니다. HyDE(Hypothetical Document Embeddings)는 질문을 직접 검색에 쓰는 대신, LLM에게 먼저 가상의 답변을 생성하게 하고, 그 답변의 임베딩으로 검색하는 기법입니다. 2022년 카네기멜론 대학 연구팀이 논문으로 발표한 이후 빠르게 실무에 확산됐습니다.
HyDE가 작동하는 원리
왜 질문 대신 가상 답변으로 검색하면 더 잘 될까요? 핵심은 임베딩 공간에서의 유사도에 있습니다.
임베딩 모델은 의미가 비슷한 텍스트를 벡터 공간에서 가까이 배치합니다. 그런데 “질문”과 “답변”은 의미적으로 관련되어 있지만, 문장 구조가 완전히 다릅니다. 질문은 의문형이고 답변은 서술형입니다. 실제로 “Python에서 리스트를 정렬하는 방법은?”이라는 질문과 “Python 리스트 정렬은 sort() 메서드 또는 sorted() 함수를 사용합니다”라는 답변은 벡터 공간에서 생각보다 멀리 떨어져 있을 수 있습니다.
반면, 가상 답변과 실제 문서는 둘 다 서술형 텍스트이므로 구조적으로 훨씬 비슷합니다. LLM이 생성한 가상 답변이 비록 정확하지 않더라도, 실제 정답이 담긴 문서와 비슷한 단어와 문장 구조를 사용할 확률이 높습니다. 그 결과 임베딩 공간에서 더 가까이 위치하게 되고, 검색 정확도가 올라가는 것입니다.
HyDE의 단계별 프로세스
HyDE의 실행 흐름은 다음과 같습니다.
- 1단계 — 가상 답변 생성: 사용자 질문을 LLM에 전달합니다. 이때 프롬프트는 “다음 질문에 대해 관련 문서에 있을 법한 답변을 한 문단으로 작성해주세요. 정확하지 않아도 괜찮으니 그럴듯한 내용을 작성해주세요”와 같이 구성합니다. 정확성보다는 문서 스타일의 텍스트를 생성하는 것이 목적입니다.
- 2단계 — 임베딩 변환: LLM이 생성한 가상 답변을 임베딩 모델에 통과시켜 벡터로 변환합니다.
- 3단계 — 벡터 검색: 이 벡터를 쿼리 벡터로 사용하여 벡터 데이터베이스에서 유사 문서를 검색합니다.
- 4단계 — 답변 생성: 검색된 실제 문서 청크들을 LLM에 전달하여 최종 답변을 생성합니다.
주의할 점은 1단계에서 생성된 가상 답변은 검색 키 역할만 할 뿐, 최종 답변에는 사용되지 않는다는 것입니다. 최종 답변은 반드시 3단계에서 검색된 실제 문서를 기반으로 생성됩니다.
HyDE의 장점과 주의점
HyDE의 가장 큰 장점은 질문-문서 간의 구조적 불일치를 우아하게 해결한다는 것입니다. 특히 기술 문서, 학술 자료, 법률 문서처럼 전문적이고 서술적인 문서가 대상일 때 효과가 극대화됩니다. 벤치마크에서도 일반 쿼리 검색 대비 Recall@10 기준 10~25% 개선이 보고된 바 있습니다.
하지만 주의할 점도 있습니다. 첫째, LLM이 가상 답변을 생성하는 데 추가 시간과 비용이 듭니다. 둘째, LLM이 생성한 가상 답변이 질문의 의도에서 크게 벗어나면 오히려 검색 품질이 떨어질 수 있습니다. 이를 환각 전파(Hallucination Propagation)라고 부르는데, LLM의 환각이 검색 단계로 전파되는 현상입니다. 셋째, 팩트 체크성 질문(“X 회사의 2025년 매출은?”)처럼 구체적인 수치를 묻는 경우에는 가상 답변이 엉뚱한 숫자를 포함할 수 있어 오히려 검색을 방해합니다.
이런 한계를 보완하기 위해 실무에서는 원래 질문의 임베딩과 HyDE 임베딩을 함께 사용하는 하이브리드 방식을 많이 씁니다. 두 벡터의 가중 평균을 검색 벡터로 사용하거나, 둘 다로 검색한 뒤 결과를 합치는 방식입니다.
기법 3: 서브 쿼리 분해로 복합 질문 정복하기
세 번째 기법은 서브 쿼리 분해(Sub-query Decomposition)입니다. 복잡한 질문 하나를 여러 개의 단순한 하위 질문으로 쪼개고, 각각에 대해 독립적으로 검색한 뒤 결과를 종합하는 방법입니다.
왜 질문을 쪼개야 할까
실제 업무 환경에서 사용자들은 생각보다 복잡한 질문을 던집니다. 다음과 같은 경우를 생각해보세요.
- “삼성전자와 SK하이닉스의 2025년 반도체 매출을 비교하고, 성장률이 더 높은 쪽의 주요 전략을 알려줘”
이 하나의 질문 안에는 최소 세 가지 정보 요구가 담겨 있습니다. 삼성전자의 2025년 반도체 매출, SK하이닉스의 2025년 반도체 매출, 그리고 성장률이 높은 쪽의 전략입니다. 이 복합 질문을 하나의 벡터로 만들어 검색하면, 세 가지 주제가 뒤섞인 애매한 벡터가 만들어져서 어느 하나도 제대로 검색하지 못할 가능성이 높습니다.
서브 쿼리 분해는 이 복합 질문을 독립적인 하위 질문들로 나눕니다.
- 서브 쿼리 1: “삼성전자 2025년 반도체 사업부 매출 실적”
- 서브 쿼리 2: “SK하이닉스 2025년 반도체 매출 실적”
- 서브 쿼리 3: “삼성전자 반도체 사업 성장 전략” 또는 “SK하이닉스 반도체 사업 성장 전략” (이전 검색 결과에 따라 결정)
각 서브 쿼리는 단일 주제에 집중하므로, 벡터 검색에서 관련 문서를 정확하게 찾을 확률이 크게 높아집니다.
순차적 분해 vs 병렬 분해
서브 쿼리를 처리하는 방식은 크게 두 가지입니다.
병렬 분해는 모든 서브 쿼리를 동시에 검색합니다. 서브 쿼리 간에 의존 관계가 없을 때 적합합니다. 위 예시에서 서브 쿼리 1과 2는 서로 독립적이므로 동시에 검색할 수 있습니다. 병렬 처리를 하면 총 지연 시간을 크게 줄일 수 있습니다.
순차적 분해는 이전 서브 쿼리의 검색 결과를 참고하여 다음 서브 쿼리를 생성하거나 검색합니다. 위 예시에서 서브 쿼리 3은 서브 쿼리 1, 2의 결과를 비교한 뒤에야 어느 쪽의 전략을 검색할지 결정할 수 있으므로, 순차적 처리가 필요합니다. 이 방식은 더 정확하지만 시간이 더 걸립니다.
실무에서는 둘을 혼합하는 경우가 많습니다. 독립적인 서브 쿼리들은 병렬로 처리하고, 의존 관계가 있는 서브 쿼리는 순차적으로 처리하는 하이브리드 방식입니다.
서브 쿼리 분해의 장점과 한계
이 기법은 복합 질문에서 특히 강력합니다. 비교, 대조, 인과 관계 분석, 다단계 추론이 필요한 질문에서 검색 품질이 크게 향상됩니다. 또한 각 서브 쿼리의 검색 결과를 따로 확인할 수 있어, 디버깅과 품질 모니터링이 용이하다는 장점도 있습니다.
한계는 LLM 호출 횟수가 늘어난다는 점입니다. 분해 자체에 LLM 호출 1회, 서브 쿼리 수만큼의 검색, 최종 종합에 LLM 호출 1회가 필요하므로 비용과 지연 시간이 증가합니다. 또한 LLM이 질문을 잘못 분해하면 불필요한 검색이 수행되거나 핵심 요소가 빠질 수 있습니다. 단순한 질문에 이 기법을 적용하면 오히려 오버헤드만 늘어나므로, 질문의 복잡도를 먼저 판단하는 라우팅 로직이 필요합니다.
기법 4: Step-back Prompting으로 맥락 넓히기
네 번째 기법은 Step-back Prompting입니다. 2023년 Google DeepMind 연구팀이 제안한 이 기법은 구체적인 질문에서 한 발 물러서 더 넓은 상위 개념의 질문을 만들어내는 방법입니다. 원래 질문과 상위 질문 모두로 검색하여 세부 정보와 배경 맥락을 함께 확보합니다.
Step-back의 작동 방식
사용자가 “Python 3.12에서 GIL이 선택적으로 비활성화 가능한 이유는 무엇인가요?”라고 묻는다고 합시다. 이 질문은 매우 구체적입니다. 벡터 검색으로 이 특정 버전의 특정 기능에 대한 문서를 찾으면 좋겠지만, 문서 컬렉션에 정확히 이 내용을 다룬 문서가 없을 수도 있습니다.
Step-back Prompting은 이 질문에서 한 걸음 물러나서 상위 개념의 질문을 만듭니다.
- Step-back 질문: “Python GIL(Global Interpreter Lock)의 역할과 역사적 변천 과정은?”
이 상위 질문은 GIL 전반을 다루므로, GIL의 기본 개념부터 최신 변경 사항까지 포괄하는 문서들이 검색될 확률이 높습니다. 시스템은 원래 질문과 Step-back 질문 모두로 검색을 수행하고, 두 결과를 합칩니다. 원래 질문의 검색 결과는 구체적인 세부 정보를, Step-back 질문의 검색 결과는 전체적인 맥락과 배경 지식을 제공합니다. LLM은 이 두 가지를 종합하여 정확하면서도 맥락이 풍부한 답변을 생성할 수 있습니다.
Step-back이 빛나는 상황
Step-back Prompting은 다음과 같은 경우에 특히 효과적입니다.
- 매우 구체적인 기술 질문: 특정 버전, 특정 설정, 특정 에러 코드에 대한 질문. 정확히 매칭되는 문서가 없더라도 상위 주제 문서에서 관련 정보를 찾을 수 있습니다.
- 인과 관계 질문: “왜 X가 Y를 초래하는가?” 형태의 질문. 원인을 이해하려면 배경 지식이 필요한데, Step-back 질문이 그 배경을 확보해줍니다.
- 최신 변경사항에 대한 질문: 최신 기능에 대한 문서가 아직 적을 때, 상위 개념 문서로 맥락을 보완할 수 있습니다.
Step-back의 주의점
이 기법은 상위 질문이 너무 넓어지면 검색 결과에 관련 없는 문서가 많이 섞일 수 있습니다. “Python GIL”을 묻는 질문의 Step-back이 “프로그래밍 언어의 동시성 처리”까지 넓어지면 너무 일반적인 문서가 검색됩니다. LLM에게 Step-back 질문을 생성시킬 때 “한 단계만 추상화하라”는 지시를 명확히 해야 합니다. 또한 이미 충분히 일반적인 질문에는 이 기법이 불필요하므로, 질문의 구체성 수준을 판단하는 로직이 있으면 좋습니다.
4가지 기법을 실전에서 조합하는 전략
지금까지 살펴본 쿼리 재작성, HyDE, 서브 쿼리 분해, Step-back Prompting은 각각 다른 종류의 문제를 해결합니다. 실전에서는 이 기법들을 상황에 맞게 선택하거나 조합해서 사용해야 합니다.
질문 유형별 기법 선택 가이드
모든 질문에 모든 기법을 적용하는 것은 비효율적입니다. 질문의 특성에 따라 가장 효과적인 기법이 달라집니다.
- 모호하거나 구어체인 질문 → 쿼리 재작성이 가장 효과적입니다. 핵심 키워드를 추출하고 전문 용어로 변환하는 것만으로 큰 개선을 얻을 수 있습니다.
- 전문 문서에 대한 일반적 질문 → HyDE가 적합합니다. 질문-문서 간 구조적 차이가 클수록 HyDE의 효과가 커집니다.
- 여러 주제를 비교하거나 조합하는 복합 질문 → 서브 쿼리 분해가 필수적입니다. 각 주제를 분리해서 검색해야 정확한 정보를 모을 수 있습니다.
- 매우 구체적이거나 최신 사항에 대한 질문 → Step-back Prompting으로 맥락을 보강합니다.
- 단순하고 명확한 질문 → 변환 없이 원본 쿼리를 그대로 사용하는 것이 가장 좋습니다. 불필요한 변환은 지연과 비용만 추가합니다.
쿼리 라우터 구현하기
질문 유형에 따라 적절한 기법을 자동으로 선택하는 쿼리 라우터(Query Router)를 만들면 비용과 품질의 균형을 맞출 수 있습니다. 쿼리 라우터는 LLM에게 질문을 분류하게 하는 방식으로 구현합니다.
시스템 프롬프트에 “다음 질문의 유형을 판단해주세요: SIMPLE(단순 사실 질문), AMBIGUOUS(모호한 질문), TECHNICAL(전문 기술 질문), COMPLEX(복합 비교 질문), SPECIFIC(매우 구체적인 질문)”과 같은 분류 기준을 제시합니다. LLM이 반환한 유형에 따라 해당하는 쿼리 변환 기법을 적용합니다.
좀 더 가벼운 방식으로는 규칙 기반 라우터를 쓸 수도 있습니다. 질문에 비교 표현(“~와 ~의 차이”, “비교해줘”)이 포함되면 서브 쿼리 분해를, 질문이 10단어 미만으로 짧으면 멀티 쿼리 확장을, 특정 버전 번호나 날짜가 포함되면 Step-back을 적용하는 식입니다. 정교하지는 않지만 LLM 호출 한 번을 절약할 수 있어 지연 시간에 민감한 환경에서 유용합니다.
기법 조합의 실전 예시
기법들을 순차적으로 조합할 수도 있습니다. 가장 검증된 조합 중 하나는 쿼리 재작성 + HyDE 하이브리드입니다. 먼저 사용자 질문을 쿼리 재작성으로 다듬은 뒤, 다듬어진 질문으로 HyDE를 수행합니다. 재작성으로 모호함을 제거하고, HyDE로 질문-문서 구조 차이까지 해소하는 이중 보정입니다.
또 다른 강력한 조합은 서브 쿼리 분해 + 개별 쿼리 재작성입니다. 복합 질문을 먼저 하위 질문들로 분해한 뒤, 각 하위 질문에 대해 쿼리 재작성을 적용합니다. 복잡한 질문에서 검색 품질을 극대화할 수 있지만, LLM 호출 횟수가 많아지므로 비용을 고려해야 합니다.
비용 대비 효과 판단하기
RAG 쿼리 변환 기법을 적용할 때 항상 고려해야 하는 것이 비용 대비 효과입니다. 각 기법의 추가 비용을 정리하면 다음과 같습니다.
- 쿼리 재작성(단일): LLM 호출 1회 추가. 입출력 토큰이 적어 비용 미미. 지연 시간 200~500ms 추가.
- 멀티 쿼리 확장: LLM 호출 1회 + 검색 3~5회 추가. 검색 비용과 결과 병합 시간 증가.
- HyDE: LLM 호출 1회 추가. 가상 답변 생성이므로 출력 토큰이 상대적으로 많아 비용 약간 상승. 지연 시간 500ms~1초 추가.
- 서브 쿼리 분해: LLM 호출 1회(분해) + 서브 쿼리 수만큼 검색 + LLM 호출 1회(종합). 가장 비용이 높은 기법.
- Step-back: LLM 호출 1회 + 검색 1회 추가. 비용 증가 중간 수준.
일반적으로 가장 먼저 시도할 것을 권장하는 기법은 쿼리 재작성입니다. 최소 비용으로 즉각적인 개선을 얻을 수 있기 때문입니다. 그 다음으로 멀티 쿼리 확장이나 HyDE를 추가해보고, 복합 질문이 많은 환경이라면 서브 쿼리 분해를 도입하는 단계적 접근을 추천합니다.
쿼리 변환 성능 측정하기
기법을 도입한 후에는 실제로 효과가 있는지 측정해야 합니다. 쿼리 변환의 효과를 측정하는 가장 직접적인 방법은 변환 전후의 검색 결과를 비교하는 것입니다. 동일한 질문 세트에 대해 원본 쿼리 검색 결과와 변환된 쿼리 검색 결과의 Recall@K, MRR(Mean Reciprocal Rank), 또는 nDCG를 비교합니다.
더 실용적인 방법은 최종 답변 품질을 비교하는 것입니다. 쿼리 변환 적용 전후로 LLM이 생성한 답변의 정확성, 완전성, 관련성을 평가합니다. 이때 자동 평가(LLM-as-Judge) 방식을 쓰면 대량의 질문에 대해 빠르게 비교할 수 있습니다.
하나 더 중요한 지표는 검색 실패율입니다. 관련 문서를 하나도 찾지 못하는 경우의 비율을 쿼리 변환 전후로 비교하면, 기법의 효과를 가장 직관적으로 확인할 수 있습니다. 잘 설계된 쿼리 변환은 이 검색 실패율을 눈에 띄게 줄여줍니다.
마무리: 좋은 검색은 좋은 질문에서 시작됩니다
RAG 시스템의 성능을 논할 때 우리는 임베딩 모델, 벡터 데이터베이스, 청킹 전략, 리랭킹 모델 같은 인프라 구성 요소에 주목하기 쉽습니다. 하지만 아무리 좋은 도서관이라도 무엇을 찾는지 정확히 모르면 원하는 책을 찾기 어렵듯이, RAG에서도 쿼리의 품질이 답변 품질의 상한선을 결정합니다.
오늘 살펴본 4가지 RAG 쿼리 변환 기법을 정리하면 다음과 같습니다. 쿼리 재작성은 모호한 질문을 검색 친화적으로 다듬어주고, HyDE는 질문-문서 간 구조적 괴리를 해소합니다. 서브 쿼리 분해는 복합 질문을 정복하는 데 핵심이고, Step-back Prompting은 너무 구체적인 질문에 맥락을 보충해줍니다.
시작점으로는 쿼리 재작성부터 도입해보세요. 기존 파이프라인에 LLM 호출 한 줄만 추가하면 되므로 부담이 적고, 그것만으로도 체감할 수 있는 검색 품질 향상을 경험하실 수 있습니다. 그 효과를 확인한 뒤 멀티 쿼리나 HyDE로 확장하고, 질문 유형에 따라 기법을 자동 선택하는 라우터까지 갖추면, 여러분의 RAG 시스템은 한 단계 더 진화할 것입니다.
