쿼리 최적화 및 변환 — Query Optimization

이전 글에서는 하이브리드 서치(Hybrid Search)로 찾아낸 문서들의 순위를 정밀하게 다시 매기는 깐깐한 문지기, 리랭커(Reranker)에 대해 알아보았습니다.

하지만 완벽한 벡터 DB와 똑똑한 리랭커를 갖추고도 RAG 시스템이 엉뚱한 대답을 내놓는 경우가 있습니다. 왜 그럴까요? 바로 사용자가 애초에 ‘질문을 대충 했기’ 때문입니다.

따라서 이번 글에서는 개떡 같은 질문을 찰떡같이 바꿔서 검색의 성공률을 높여주는 ‘쿼리 최적화 및 변환(Query Optimization & Transformation)’에 대해 작성해보겠습니다.

RAG의 딜레마: Garbage In, Garbage Out

컴퓨터 공학의 오랜 격언 중 “Garbage In, Garbage Out(쓰레기가 들어가면 쓰레기가 나온다)”이라는 말이 있습니다. RAG 시스템에서도 이 법칙은 정확히 적용됩니다.

아무리 내부에 방대한 전공 서적(VectorDB)이 잘 정리되어 있어도, 사용자가 검색창에 “그거 안 되는 이유”나 “어제 교수님이 말한 거”라고 너무 짧고 모호하게 질문(Query)을 던지면 시스템은 문맥을 파악할 수 없습니다.

우리가 원하는 문서를 잘 찾아오려면 질문 자체가 풍부한 단어와 명확한 의도를 담고 있어야 합니다. 사용자의 부실한 질문을 AI가 검색하기 좋은 ‘고품질 질문’으로 번역해 주는 과정이 바로 쿼리 최적화입니다.

기법 1. 멀티 쿼리 (Multi-Query)

멀티 쿼리는 하나의 질문에만 의존하지 않고, LLM을 이용해 비슷한 의미를 가진 여러 개의 질문으로 복제 및 변환하여 검색망을 넓히는 기법입니다.

• 검색어의 사각지대 없애기: 사용자가 “휴학하는 법”이라고 검색했을 때, 실제 학교 규정집에는 ‘휴학’이라는 단어 대신 ‘학업 일시 중단’이나 ‘휴적 처리’라는 단어로 적혀 있을 수 있습니다.
• 동작 방식: 시스템은 검색을 시작하기 전, LLM에게 “사용자의 질문을 3가지 다른 버전으로 바꿔줘”라고 요청합니다.

1. “휴학 신청 절차와 필요 서류”
2. “일반 휴학 및 군휴학 승인 조건”
3. “학기 중 학업 중단 신청 방법”
4. 이렇게 변환된 여러 질문을 동시에 벡터 DB에 던져서 검색한 뒤, 결과물들을 하나로 모아 중복을 제거합니다. 낚싯대를 하나만 드리우는 것이 아니라, 여러 개의 낚싯대를 던져서 정답을 낚을 확률을 극대화하는 방식입니다.

기법 2. HyDE (가설 기반 임베딩)

HyDE(Hypothetical Document Embeddings)는 쿼리 변환 기법 중에서도 발상의 전환이 돋보이는 매우 강력한 방법입니다. 짧고 모호한 ‘질문’으로 검색하는 대신, LLM이 미리 작성한 ‘가짜 정답(가설 문서)’으로 검색을 수행합니다.

• 질문보다 답변이 검색에 유리한 이유: “AI 시대에 대학생이 갖춰야 할 역량은?”이라는 짧은 질문과, 실제 그에 대한 답변인 “AI 시대에는 비판적 사고, 데이터 리터러시, 그리고 프롬프트 엔지니어링 능력이 필수적이며…”라는 긴 글 중 어느 것이 벡터 DB에서 더 정확한 문서를 찾아올까요? 당연히 풍부한 키워드와 문맥을 가진 ‘긴 답변’입니다.
• 동작 방식: 사용자의 질문이 들어오면, 시스템은 LLM에게 “이 질문에 대해 네가 아는 대로 일단 대답해 봐”라고 지시합니다. LLM은 환각(Hallucination)이 섞이더라도 그럴싸한 가짜 가설 문서를 만들어냅니다. 그리고 이 ‘가짜 문서’를 임베딩(숫자로 변환)하여 벡터 DB에서 이와 가장 유사한 ‘진짜 문서’를 찾아냅니다. 질문과 정답 사이의 간극을 줄여주기 때문에, 특히 추상적이거나 설명이 필요한 질문에서 압도적인 검색 성능을 보여줍니다.

쿼리 최적화의 트레이드오프 (Trade-off)

이렇게 똑똑한 쿼리 최적화 기법들에도 명확한 단점이 존재합니다. 바로 ‘비용(Cost)’과 ‘지연 시간(Latency)’입니다.

• LLM 호출 횟수의 증가: 기본 RAG는 ‘검색 -> 생성(LLM)’의 순서로 LLM을 한 번만 부르면 됩니다. 하지만 쿼리 최적화를 적용하면 ‘질문 변환(LLM) -> 검색 -> 최종 답변 생성(LLM)’ 순으로 진행되어 LLM을 두 번 이상 호출해야 합니다.
• 적용 전략: API 사용 비용이 2배로 들고 사용자가 답변을 받기까지 기다려야 하는 시간도 늘어납니다. 따라서 모든 질문에 HyDE나 멀티 쿼리를 남발해서는 안 됩니다. “도서관 운영시간” 같은 단순한 키워드 검색에는 기본 검색을 적용하고, 1차 검색에서 원하는 결과가 나오지 않았거나 질문이 10자 이상으로 길고 복잡할 때만 선택적으로 쿼리 최적화를 태우는 라우팅(Routing) 전략이 필요합니다.

마치며

이번 글에서는 검색의 퀄리티를 출발선에서부터 끌어올려 주는 ‘쿼리 최적화 및 변환(Query Optimization)’에 대해 알아보았습니다.

훌륭한 RAG 시스템은 방대한 지식을 잘 저장하는 것을 넘어, 사용자의 서툰 질문 이면에 숨겨진 ‘진짜 의도’를 파악하는 통역사 역할을 해내야 합니다. 멀티 쿼리로 다각도의 낚싯대를 던지고, HyDE를 통해 질문의 빈약한 문맥을 풍성하게 채워주는 이 과정은 “개떡 같은 질문”을 “찰떡 같은 정답”으로 바꿔주는 강력한 마법입니다.

결국 검색을 잘하기 위해서는 DB를 뒤지기 전에, “어떻게 물어볼 것인가”를 먼저 최적화해야 한다는 사실을 잊지 마시기 바랍니다.