쿼리 재작성은 왜 함부로 하면 안 되나
← 전체 목차 · 이전: RAG 검색 전략은 어떻게 설계하는가 — 3층 구조 · 다음: Top K는 도대체 어떻게 정하나 — 2단계 검색과 동적 임계값
쿼리 재작성의 가치는 "리콜을 높일 수 있다"에 있지 않고, 그것이 제약을 받는 검색 강화 단계라는 점에 있다. 한번 잘못 고치면 이후의 검색과 재정렬이 아무리 강해도 잘못된 방향에서 점점 더 정확하게 찾을 뿐이다.
| 재작성이 필요한 이유 | 재작성이 할 수 있는 것 | 레드라인 |
|---|
| 사용자 질문이 짧다 | 엔티티 보완 | 자유 창작 금지 |
| 구어체다 | 동의어 확장 | 반드시 리콜에 봉사할 것 |
| 생략이 있다 | 하위 질문으로 분해 | 사용자가 말하지 않은 조건을 지어내지 말 것 |
핵심 답변: 쿼리 재작성에는 경계가 있어야 하며, 핵심은 사용자 의도를 보존하고 검색 단서를 보완하는 것이지 사용자를 대신해 질문을 다시 만드는 것이 아니다.
엔지니어링적으로 5개의 하위 단계로 쪼갠다: 의도 인식 → 엔티티 추출 → 동의어 확장 → 시간 범위 보완 → 다중 쿼리 생성. 그리고 리콜 결과 + 평가 지표로 재작성이 정말 도움이 되었는지 역검증한다.
1층: 보수적 재작성 — 하드 엔티티는 차라리 안 고친다
| 사용자 입력 | 시스템 재작성 |
|---|
| ✅ 정답: 상태와 결합해 보완 | "이 정책은 언제 발효되나요" | "【구체적 정책명】은 언제 발효되나요" |
| ❌ 오답: 과도 확장·발산 | "이 정책은 언제 발효되나요" | "최신 세무 정책 해설" |
- 이름을 보완하는 근거는 현재 페이지나 대화 상태에서 오지 모델의 연상에서 오지 않는다.
- "대규모 모델로 여러 query를 생성한다"만 말하지 말고 재작성 불가 필드 목록을 보탤 것:
- 인명, 계약 번호, 주문 번호, 법규 번호 같은 하드 엔티티
- 이런 엔티티는 원문 그대로 보존할지언정 모델이 유의어로 바꾸게 두지 말 것
2층: 다경로 리콜 — 원래 질문은 언제나 백스톱이다
재작성된 query 하나로는 부족할 수 있으므로 4개 경로를 병렬로 돌린다.
- 원래 질문
- 키워드 버전
- 의미 버전
- 구조화 필터 버전
그다음 Rerank 또는 증거 점수로 결과를 병합한다.
| 원래 질문 | 재작성 질문 |
|---|
| 기초 백스톱 | 효과 강화 |
| 절대 버릴 수 없음 | 다차원 리콜 확장 |
3층: 평가 — 답변 만족도만 봐서는 안 된다
| 지표 | 무엇을 보나 |
|---|
| 리콜 적중률 | 재작성 후 올바른 문서를 건져 왔는가 |
| 첫 건 관련성 | Top-1이 정말 관련 있는가 |
| 증거 커버리지 | 답을 뒷받침할 증거가 갖춰졌는가 |
| 무답 거부율 | 거부해야 할 때 거부했는가 |
| 재작성 표류율 | 재작성이 원래 의도에서 벗어난 비율 |
기업 지식베이스의 특수 리스크: 잘못된 재작성은 모델에게 "유사하지만 적용되지 않는" 제도 문서를 쥐여준다. 최종 답변은 매우 전문적으로 보이지만 실제로는 틀렸다 — 가장 발견하기 어려운 유형의 장애다.
4층: 컨텍스트와 지시 대상 해소
- 일부 query 재작성은 현재 페이지 / 이력 대화 / 사용자가 선택한 파일을 읽어야 한다.
- 그러나 이런 컨텍스트는 출처를 명확히 표기해야 하며, 모델이 "기억에서 추측"하게 두어서는 안 된다.
- 예: "이 두 버전을 비교해 줘" → 시스템은 "이 두 개"가 어떤 두 문서 버전인지 알아야 한다.
- 원칙: 지시 대상 해소는 할 수 있지만, 매 해소마다 그 근거를 설명할 수 있어야 한다.
5층: 과도 확장 방지
반례: 사용자가 「배포 실패 원인」을 물었는데 모델이 「클라우드 네이티브 배포 모범 사례」로 바꿔 버린다.
과도 확장의 직접적 결과 3종:
- 관련 있어 보이는 거창한 자료를 쌓아 올린다
- 진짜 핵심인 하위 로그를 잃는다
- 재작성이 검색어가 아니라 기사 제목처럼 되어 버린다
대책: 후보 query 수량 제한 + 키워드 커버리지 검사 보존. 판정 기준은 "검색 목표에 더 가까운가"이지 "기사 제목에 더 가까운가"가 아니다.
백스톱: 롤백 가능 + 설명 가능
- 재작성된 query의 리콜 결과 신뢰도가 낮으면 → 시스템이 원래 query로 롤백할 수 있어야 한다.
- 또는 사용자에게 동시에 보여준다: "당신의 질문을 XXX로 이해했습니다. 맞지 않으면 보충해 주세요."
- 이유: 몰래 재작성한 뒤 틀린 답을 주는 것보다 믿을 만하다.
- 한 줄 원칙: 쿼리 재작성이 똑똑해질수록 그것을 설명 가능하고 롤백 가능하게 만들어야 한다.
프로덕션 함정: 재작성이 캐시를 오염시킨다
| 상황 | 문제 |
|---|
| 원래 질문이 다른데 같은 query로 재작성됨 | 같은 검색 결과에 잘못 적중 |
| 원래 질문이 같은데 컨텍스트가 다름 | 결과를 재사용하면 안 되는데 재사용됨 |
해법: 네 요소를 Cache Key에 결합할 것 — 재작성 결과 / 사용자 스코프 / 컨텍스트 출처 / 지식베이스 버전. 그렇지 않으면 캐시 적중률은 올라가는데 답변 신뢰도가 오히려 떨어진다.
표준 아키텍처: 4단 클로즈드 루프 재작성 파이프라인
| 단계 | 설명 |
|---|
| 원래 질문 보존 | 원래 의도와 컨텍스트를 앵커링 |
| 핵심 요소 추출 | 엔티티와 필터 조건을 정확히 추출 |
| 후보 Query 생성 | 소량이면서 고도로 설명 가능하게 |
| 리콜·재정렬 검증 | 최종 결과를 교차 검증 |
보충 원칙: 고위험 질문은 재작성이 실패하면 차라리 덜 답할지언정 조건을 지어내서는 안 된다.
핵심 통찰
- 재작성의 오류는 "방향성 오류"이며 하류가 보완할 수 없다 — 검색과 Rerank는 주어진 방향에서 정밀도를 올릴 뿐이므로, 방향이 틀리면 "잘못된 방향에서 점점 더 정확하게 찾는" 것이다. 그래서 재작성은 가장 엄격한 제약 아래 두어야지 프롬프트를 마음대로 조정할 수 있는 모듈로 여겨서는 안 된다.
- "의도 보존"과 "단서 보완"은 다른 두 가지이며 후자만이 재작성의 합법적 역할이다 — 합법 동작은 엔티티 보완, 시간 범위 보완, 하위 질문 분해다. 불법 동작은 사용자를 대신해 질문을 다시 만드는 것, 사용자가 말하지 않은 한정 조건을 추가하는 것이다.
- 원래 query는 언제나 리콜 집합 안에 있어야 한다 — 다경로 리콜의 본질은 "다양성"이 아니라 단일 재작성 실패에 퇴로를 남기는 것이다. 원래 질문을 백스톱 경로로 두고 재작성 경로는 강화만 담당하게 하면, 재작성 모듈의 실패율이 더 이상 시스템의 실패율이 아니게 된다.
- 재작성 모듈에는 자체 관측 지표가 있어야 하며 엔드투엔드 만족도에만 기대서는 안 된다 — 엔드투엔드 만족도는 재작성 장애를 "답변이 매끄럽다"는 인상 속에 가려 버린다. 리콜 적중률, 첫 건 관련성, 증거 커버리지, 무답 거부율, 재작성 표류율 다섯 가지가 재작성 자신의 지표다.
- 기업 지식베이스에서 가장 위험한 것은 "검색되지 않는 것"이 아니라 "유사하지만 적용되지 않는 것을 검색하는 것"이다 — 전자는 거부 응답을 트리거하지만, 후자는 전문적으로 보이면서 실제로는 틀린 답을 생성하며 아무 신호도 남기지 않는다.
- 컨텍스트 주입에는 출처 표기가 따라야 한다 — 재작성이 페이지/이력/선택 파일에 의존했다면 "이 정보가 어디서 왔는지"를 설명할 수 있어야 한다. 지시 대상 해소는 할 수 있되 설명 가능해야 하며, 이것이 "추측"을 "감사 가능한 추론"으로 바꾸는 관건이다.
- 롤백 가능함 > 소리 없는 정확함 — 몰래 재작성한 뒤 틀린 답을 주느니, 시스템의 이해를 사용자에게 명시적으로 노출해 바로잡게 하는 편이 낫다. 재작성이 똑똑해질수록 설명 가능하고 롤백 가능해야 한다.
- 재작성은 캐시의 등가류 정의를 바꾼다 — 재작성을 붙인 뒤로는 "두 요청이 등가인가"가 더 이상 원래 질문만으로 결정되지 않는다. Cache Key를 함께 갱신하지 않으면 캐시는 성능 최적화에서 정확성 취약점으로 변한다.
엔지니어링 실전 Tips
- 재작성 불가 필드 화이트리스트를 만들 것(인명, 계약 번호, 주문 번호, 법규 번호, SKU, 워크오더 번호…). 재작성 전에 엔티티 인식을 먼저 하고 이 조각들을 "못 박은" 뒤 나머지 부분만 모델이 고치게 할 것.
- 다경로 리콜의 경로 수를 무한정 늘리지 말 것: 후보 query 수량 제한이 명시적 요구다 — 경로 하나마다 지연과 비용이다.
- 키워드 커버리지 검사를 한 줄 추가할 것: 재작성된 query가 원래 질문의 키워드를 잃었다면 재작성 실패로 판정하고 원래 query로 갈 것.
- 재작성 표류율을 모니터링에 올릴 것: 원 query와 재작성 query의 의도 라벨을 샘플링 대조하고, 표류율이 급증하면 대개 재작성 프롬프트나 모델 버전이 바뀐 것이다.
- 저신뢰도 롤백에 명확한 임계값을 둘 것(Top-1 점수 / 증거 커버리지가 임계값 미만 등). 사람이 사후에 발견하게 두지 말 것.
- 캐시 마이그레이션 주의: 재작성을 붙인 뒤에는 옛 Cache Key(원래 질문 해시만 사용)를 전체 실효시켜야 한다. 그렇지 않으면 과거의 잘못된 결과에 적중한다.
- 지식베이스 버전 번호를 Cache Key에 넣는 것이 가장 놓치기 쉬운 한 항목이다 — 문서가 갱신된 뒤에도 옛 캐시가 만료된 제도 조항을 계속 내놓는다.
- 더 파고들 방향: 재작성 표류율의 자동 평가셋 구축(사람 라벨링 의도 vs LLM-as-Judge), 다경로 리콜의 융합 전략 비교(RRF vs Rerank 모델 vs 증거 점수), 하드 엔티티 보호의 구현(NER 모델 + 플레이스홀더 치환 vs 제약 디코딩), 저신뢰도 롤백의 임계값 보정과 그로 인한 추가 지연 예산.