쿼리 재작성은 검색 시스템이 사용자의 질문을 자료 검색에 적합한 표현으로 고치는 과정입니다. 오타를 고치거나 질문에 생략된 맥락을 보완하면, 실제 검색에 쓰는 질의가 사용자의 입력과 달라집니다. 원래 질문을 그대로 검색하거나 원 질의와 재작성한 질의를 함께 쓰는 구현도 있습니다.
무엇을 고쳐서 검색하나
재작성은 오타를 바로잡는 데서부터 대화 내용을 반영하는 데까지 쓰입니다. 한 시스템 안에서 여러 방식을 결합할 수도 있습니다.
- 오타 교정과 동의어 확장: 철자가 틀린 단어를 고치거나 같은 뜻의 다른 표현을 검색에 반영합니다. Google은 검색어와 정확히 같은 단어가 없는 문서도 찾을 수 있도록 동의어 시스템을 운영합니다.
- 검색할 자료에 맞춘 표현: RAG에서 사용자의 질문을 검색에 쓸 질의로 바꿉니다. 일상적인 질문 표현과 문서에 적힌 용어가 다를 때 관련 자료를 찾는 데 도움이 될 수 있습니다.
- 대화 맥락 반영: “그건 얼마야?”처럼 앞 대화를 알아야 이해할 수 있는 질문에 대상을 넣습니다. 재작성한 질문만으로도 무엇의 가격을 찾는지 알 수 있게 만듭니다.
2023년 EMNLP에 발표된 Ma 등의 논문은 질문을 재작성한 뒤 검색하고, 검색한 문서를 읽어 답하는 Rewrite-Retrieve-Read 프레임워크를 제안했습니다. LLM이 검색어를 만들고 웹 검색엔진에서 자료를 가져오는 방식입니다. 이는 LLM을 활용한 연구 사례이며, 오타 교정과 동의어 확장을 포함한 모든 쿼리 재작성이 LLM을 쓰는 것은 아닙니다.
원 질의도 검색에 남을 수 있습니다
Azure AI Search의 쿼리 재작성은 선택적으로 켜는 미리보기 기능입니다. 생성 모델이 원 질의의 변형을 만들면 검색 서비스가 원 질의와 변형을 함께 검색에 씁니다. 이 기능에는 시맨틱 순위 지정 설정이 필요합니다.
Microsoft는 재작성한 질의에 원래 단어가 모두 남는 것은 아니라고 안내합니다. 제품 코드나 고유 식별자가 빠지면 다른 대상을 검색할 수 있으므로, 정확히 일치하는 값을 찾아야 하는 질문은 별도로 시험해야 합니다.
쿼리 팬아웃과 다른 점
쿼리 팬아웃은 질문에서 여러 하위 주제를 찾아 관련 검색으로 넓히는 방식입니다. 재작성은 검색할 질문의 표현을 고치는 작업입니다. 같은 질문을 여러 표현으로 바꾸는 재작성도 있으므로, 만들어진 검색어 개수만으로 두 방식을 구분하지는 않습니다.
두 작업을 한 시스템에 결합할 수는 있습니다. 다만 Google이 AI Mode의 쿼리 팬아웃을 설명했다고 해서 Azure나 특정 RAG 프레임워크의 재작성 절차를 그대로 사용한다고 볼 수는 없습니다.
오타와 RAG, 후속 질문 재작성 예시
| 입력 | 재작성 예시 | 범위 |
|---|---|---|
| “서치콘솔 색이 요청” | “서치콘솔 색인 요청” | 오타 교정 |
| “반품 언제까지 돼” | “반품 가능 기간” | 사내 문서 검색용 재작성 |
| 앞서 제주 지역의 추가 배송비를 물은 뒤 “그럼 도서는?” | “도서 지역 추가 배송비는 얼마인가” | 대화 맥락을 반영한 질의 |
위 표는 작동 방식을 설명하기 위한 예시입니다. 원래 질문이나 앞 대화에 없던 “무료” 같은 조건을 넣으면 검색 대상이 달라질 수 있습니다. 재작성한 문장이 자연스러운지뿐 아니라 질문의 대상과 조건을 보존했는지도 봐야 합니다.
재작성 결과를 확인하는 방법
Google 검색에서는 오타 교정 안내처럼 화면에 드러난 일부 변화만 볼 수 있습니다. 내부에서 실행한 모든 질의를 사용자가 확인할 수는 없습니다.
자체 RAG를 운영한다면 원 질의, 재작성 질의, 검색한 문서, 최종 답변을 나란히 기록해 비교합니다. 재작성한 문장은 그럴듯한데 필요한 문서가 검색 결과에서 빠질 수 있기 때문입니다.
- 원 질의와 재작성 질의에서 대상, 기간, 제품 코드가 달라지지 않았는지 봅니다.
- 각 질의로 찾은 상위 문서와 점수를 비교하고, 답에 필요한 문서가 어느 쪽에서 검색됐는지 확인합니다.
- 최종 답변에 사용한 문서까지 추적해, 검색에서 찾은 근거가 답변에 반영됐는지 확인합니다.
Azure AI Search에서는 테스트 요청의 debug를 queryRewrites로 설정하면 재작성 정보를 받을 수 있습니다. 응답의 inputQuery는 생성 모델에 전달한 질의로, 사용자가 search에 넣은 원문과 다를 수 있습니다. 두 값을 같은 것으로 기록하지 않아야 합니다. Microsoft는 이 디버그 설정을 운영 환경에서는 사용하지 않도록 권장합니다.
키워드 전략에서는 어떻게 활용하나
검색어의 오타나 어순이 다르다고 각각의 페이지를 만들 필요는 없습니다. 시맨틱 검색과 동의어 처리는 표현이 달라도 관련 있는 문서를 찾는 데 쓰입니다. 검색자가 찾는 대상과 필요한 답이 같다면 한 페이지에서 다룰 수 있습니다.
브랜드명, 제품명, 모델 코드는 정확히 적어야 합니다. 특히 이름이 비슷한 제품은 규격과 호환 조건까지 밝혀 어느 제품을 설명하는지 명확히 합니다. 검색 시스템이 표현을 고쳐 준다고 해서 잘못된 모델명까지 의도대로 해석해 줄 것으로 기대해서는 안 됩니다.
자주 묻는 질문
내가 입력한 검색어가 그대로 검색되는 게 아닌가요?
그대로 검색할 수도 있고, 오타를 고치거나 동의어를 반영해 검색할 수도 있습니다. Azure AI Search처럼 원 질의와 생성 모델이 만든 변형을 함께 쓰는 구현도 있습니다.
쿼리 팬아웃과는 뭐가 다른가요?
재작성은 질의 표현을 고치고 팬아웃은 여러 관련 검색이나 하위 질문으로 확장합니다. 재작성도 여러 변형을 만들 수 있으므로 단순히 검색어 개수만으로 구분하지 않습니다.
그럼 키워드 최적화는 의미가 없어지나요?
아닙니다. 페이지가 무엇을 다루는지 제목과 본문에 분명히 적어야 관련 질문에 답할 수 있습니다. 오타와 동의어마다 페이지를 늘릴 필요는 없지만, 제품명이나 모델 코드처럼 대상을 특정하는 정보는 정확히 써야 합니다.
재작성은 전부 AI가 하나요?
전부 생성형 AI가 하는 것은 아닙니다. 오타 교정과 동의어 확장은 LLM이 널리 쓰이기 전부터 검색에 활용됐습니다. LLM은 재작성에 쓸 수 있는 방법 중 하나입니다.
함께 알아두면 좋은 용어
- 쿼리 팬아웃: 하나의 질문을 여러 하위 주제와 관련 검색으로 확장하는 방식
- 시맨틱 검색: 단어의 일치뿐 아니라 질의와 문서의 의미를 고려하는 검색 방식
- RAG: 검색한 외부 자료를 생성 모델에 제공해 답변을 작성하는 방식
- 검색 의도: 검색자가 검색으로 해결하려는 목적