쿼리 재작성 (Query Rewriting)

쿼리 재작성(Query Rewriting)은 사용자의 검색 의도를 유지하면서 질문을 검색기가 처리하기 좋은 표현으로 바꾸는 과정입니다. 대화에서 생략된 대상을 보완하거나 검색에 필요한 용어를 명확히 해, 답변의 근거가 될 자료를 더 잘 찾는 데 목적이 있습니다.

질문을 그대로 검색하기 어려운 이유

사람은 앞선 대화를 기억하므로 “그건 언제까지 바꿀 수 있나요?”라는 질문을 이해할 수 있습니다. 검색기는 이 문장만 받으면 무엇을 바꾸려는지 알기 어렵습니다. 앞 대화가 특정 상품의 교환 조건에 관한 것이었다면, 필요한 맥락을 넣어 “해당 상품의 교환 가능 기간과 조건”처럼 검색할 수 있습니다. 다만 상품명이나 구매일을 알지 못한다면 임의로 만들어 넣어서는 안 됩니다. 검색에 유리한 표현으로 바꾸더라도 사용자가 묻는 대상과 조건은 유지해야 합니다.

대화형 검색의 쿼리 재작성 연구는 앞 대화에 의존하는 질문을 독립적으로 이해할 수 있는 질문으로 바꾸는 문제를 다룹니다. 모델이 직전 문장만 읽는지, 관련 대화까지 읽는지에 따라 재작성 결과가 달라질 수 있습니다. 예를 들어 사용자가 앞에서 배송지 변경을 물었다가 상품 교환으로 주제를 바꿨다면, 오래된 배송지 문맥을 그대로 넣으면 다른 자료를 찾게 됩니다. 대화 이력을 많이 넣는 것보다 현재 질문과 연결되는 대상을 구분하는 일이 중요합니다.

일반 검색에서도 사용자의 표현과 문서에 쓰인 용어는 다를 수 있습니다. 사용자는 “로그인이 계속 풀린다”고 쓰지만 기술 문서는 세션 만료나 인증 토큰 갱신을 설명할 수 있습니다. 재작성은 이런 관련 표현을 검색 후보로 사용할 수 있게 합니다. 그러나 증상을 곧바로 특정 원인으로 확정하면 검색 범위를 잘못 좁힐 수 있습니다. “세션 만료 또는 로그인 유지 문제”처럼 원인을 열어 둔 표현과 정확한 오류 코드를 함께 쓰는 방식도 검토할 수 있습니다.

RAG에서 어디에 들어가는가

RAG는 검색한 자료를 모델의 입력에 넣어 답을 생성합니다. 쿼리 재작성은 주로 그 검색에 앞서 어떤 질의를 보낼지 정하는 단계에 들어갑니다. Rewrite-Retrieve-Read 연구는 질문을 재작성한 뒤 검색하고, 검색 결과로 답하는 흐름을 제안했습니다. 검색기나 답변 모델을 바꾸는 대신 검색 질의와 필요한 지식 사이의 차이를 줄이는 접근입니다. 논문은 재작성 모델을 학습하는 방법도 다루지만, 모든 재작성 기능이 별도 학습을 요구하는 것은 아닙니다.

재작성 결과는 한 문장일 수도 있고 여러 대체 질의일 수도 있습니다. Azure AI Search의 재작성 기능은 원래 질의와 생성한 대체 질의를 함께 사용해 검색하는 제품 사례입니다. 오탈자를 고치거나 동의어로 표현을 넓힐 수 있습니다. 이 기능은 공식 문서에서 미리 보기로 안내되므로, 해당 서비스에 적용할 때는 지원 조건을 확인해야 합니다. 여기서 중요한 원리는 원문을 버리는 방식만 가능한 것이 아니라 원문과 변형을 함께 검색할 수도 있다는 점입니다.

쿼리 확장, 분해, 재작성은 겹치는 부분이 있지만 초점은 다릅니다. 확장은 관련 용어나 표현을 더하고, 분해는 복잡한 질문을 여러 하위 질문으로 나눕니다. 재작성은 검색하기 좋은 질의 표현을 만드는 데 초점을 둡니다. Microsoft의 RAG 검색 단계 안내는 이들을 함께 사용할 수 있는 질의 변환 방법으로 설명합니다. 가상 답변을 만든 뒤 그 임베딩으로 검색하는 HyDE도 소개하지만, 이는 질문 문장만 다듬는 재작성과는 다른 변형입니다.

여러 질의를 검색했다면 결과를 합치는 단계도 필요할 수 있습니다. 같은 문서가 반복됐는지 확인하고, 역순위 융합 같은 방법으로 후보 순위를 합친 뒤 리랭킹을 적용할 수 있습니다. 재작성은 검색 입력을 바꾸고, 리랭킹은 이미 찾은 후보의 순서를 다시 매깁니다. 재작성된 질의가 관련 자료를 전혀 찾지 못했다면, 뒤의 순위 조정만으로 누락된 자료가 생기지는 않습니다. 각 단계가 개선하려는 문제를 나눠 봐야 합니다.

의도 보존과 검색 효과를 함께 확인한다

정확한 이름과 식별자가 중요한 검색에서는 재작성이 오히려 방해가 될 수 있습니다. Azure 문서도 재작성 결과에 원래의 고유 용어나 제품 코드가 모두 남지 않을 수 있다고 설명합니다. 예를 들어 오류 코드의 하이픈이나 버전 번호를 평범한 단어로 바꾸면 엉뚱한 문서를 찾을 수 있습니다. 이런 항목은 그대로 유지하도록 지시하거나 별도의 정확 일치 검색 조건으로 다루는 방법을 검토해야 합니다.

재작성 문장이 자연스럽다는 사실만으로 효과를 판단하기는 어렵습니다. 원문 질의와 재작성 질의를 같은 질문 묶음에 적용하고, 필요한 근거가 검색 후보에 들어왔는지와 상위에 놓였는지를 비교해야 합니다. RAG라면 검색 결과뿐 아니라 최종 답변이 근거에 맞는지도 확인합니다. 검색 문서 수가 늘어도 관련 없는 내용이 많아지면 모델이 핵심 근거를 찾기 더 어려워질 수 있습니다.

모든 요청을 반드시 재작성할 필요도 없습니다. 이미 명확한 제품 코드 검색에는 원문이 더 나을 수 있고, 대명사가 많은 후속 질문에는 맥락 보완이 도움이 될 수 있습니다. 재작성에 언어 모델을 호출하면 지연과 토큰 사용량이 추가되므로, 어떤 질문 유형에서 이득이 생기는지 나눠 평가하는 편이 좋습니다. 앞선 대화형 검색 연구도 재작성 지연을 줄이기 위해 작은 모델로 능력을 옮기는 방법을 다뤘습니다.

검색 의도를 보존하는 일과 접근 권한을 지키는 일은 별개입니다. 재작성된 질의가 더 많은 자료를 찾더라도 사용자에게 허용된 문서 범위를 넘겨서는 안 됩니다. 사용자 질문, 실제 보낸 질의, 검색된 문서 식별자와 선택 이유를 필요한 범위에서 남기면, 답변이 빗나갔을 때 재작성 오류인지 검색 실패인지 구분하는 데 도움이 됩니다. 쿼리 재작성의 목적은 필요한 근거를 정확히 찾도록 검색 질문을 다듬는 것입니다.