8.3.6 쿼리 확장(Query Expansion) 및 재작성(Rewrite) 결과의 적합성 검증

사용자가 프론트엔드 채팅창에 나태하고 급하게 타이핑하여 서버로 밀어넣는 원본 질문(Raw Query) 텐서는 대부분 처참할 정도로 엉망이다. 문법이 파괴되어 있고, 주어가 모호하게 생략되어 있으며, 시스템에 등록된 정확한 도메인 전문 용어(예: “연차 유급 휴가”) 대신 비공식적인 일상어(예: “연차”)가 섞여 있다. 이런 저질 쿼리를 그대로 멍청하게 Vector DB에 던지면 검색 품질은 나락으로 곤두박질친다.

이를 아키텍처 레벨에서 해결하기 위해 최신 엔터프라이즈 RAG 파이프라인은 검색 엔진 레이어에 쿼리를 전송하기 바로 전 단계에 가벼운 소형 LLM(예: Claude Haiku)을 중간 미들웨어로 개입시킨다. 이 미들웨어는 유저의 불친절한 질문을 읽고, 검색 엔진이 위상 공간에서 맵핑하기 가장 유리한 형태로 동의어를 덧붙여 풍성하게 부풀리거나 문장을 아예 새로 교정하는 쿼리 확장(Query Expansion) 및 쿼리 재작성(Query Rewrite) 기법을 광범위하게 백엔드 표준으로 사용한다.
하지만 이 LLM 주도의 ‘부풀리기’ 과정 역시 본질적으로 비결정론적 모델이 개입하는 매우 위험한 지표 조작 지대이므로, 오라클의 냉혹하고 엄격한 교차 검증을 반드시 통과해야만 한다.

1. 쿼리 드리프트(Query Drift) 탐지와 방향성 이탈 통제 제약

쿼리 확장 파이프라인에서 발생하는 가장 흔하면서도 치명적인 부작용은 ‘의도의 완전한 왜곡(Semantic Query Drift)’ 현상이다.
예를 들어 유저가 챗봇에 “최근 A사와의 솔루션 납품 계약에서 조율 중인 페널티 조항“을 짧게 물었는데, 재작성을 담당한 프록시 LLM 모델이 ’페널티’라는 자극적인 단어 토큰에 과도하게 어텐션(Attention)이 꽂혀서, 원본 쿼리를 “소프트웨어 결함 발생 시 A사에 법적으로 청구할 수 있는 모든 형사적/민사적 페널티와 징벌적 손해배상 및 국제 소송 판례“로 무지막지하고 호전적으로 확장해 버렸다고 가정해 보자.
이어지는 검색 엔진은 이 왜곡된 거대 쿼리에 주파수를 맞춰 엉뚱하게 글로벌 소송 판례나 법무팀 일반 규정 수백 개를 긁어오며 시스템의 메모리를 낭비할 것이다.

오라클은 이 드리프트 현상을 막기 위해 원본 유저 쿼리 벡터 \vec{q}_{raw}와 프록시가 재작성한 확장 쿼리 집합 벡터 \vec{q}_{expanded} 간의 코사인 유사도를 백그라운드 인퍼런스로 항시 채점한다. 이 유사도 스코어가 **사전에 지정된 안전 임계치(예: 0.8) 밑으로 떨어지면, 오라클은 즉시 이 확장을 ’위험한 과대망상(Hallucinatory Expansion)’으로 취급하여 거부(Reject)하고 파이프라인을 원본 쿼리로 강제 롤백(Rollback)**시키는 제어 릴레이를 가동한다.

2. 하위 쿼리(Sub-query) 구조 분해의 논리적 무결성 오라클 평가

인간 유저의 복잡다단한 질문(예: “작년 대비 올해 2분기 플랫폼 영업이익률의 급증 원인과, 이에 대응하기 위한 하반기 마케팅 전략은?”)은 단 한 번의 무식한 Vector 쿼리 검색으로는 절대 정답 블록을 포괄할 수 없다. 따라서 진보된 파이프라인은 이를 4개의 독립적인 하위 쿼리(Sub-query) 배열로 물리 탐색 트리를 분해한다. (1. 올해 2분기 영업이익 규정, 2. 작년 2분기 영업이익 관련 문서, 3. 영업이익 증감 원인 분석 리포트, 4. 마케팅 대응 방안 가이드라인)

이때 오라클의 메타-검증 역할은, 프록시 언어 모델이 수행한 이 분해(Decomposition) 과정이 맥킨지 컨설팅의 로직 점검 지표인 MECE(Mutually Exclusive, Collectively Exhaustive: 상호 배제와 전체 포괄) 원칙의 교집합을 이탈 없이 위배하지 않았는지 차갑게 채점하는 것이다.

• 분해 무결성 패널티(Decomposition Integrity Penalty): 파생된 하위 쿼리 1~4번의 텍스트 토큰 집합 머지를 모두 합쳤을 때, 원본 쿼리의 핵심 엔터티 키워드(예: ‘플랫폼’) 토큰이 분해 과정 중 단 하나라도 공기 중으로 휘발되어 누락(Missing)되었다면, 오라클은 쿼리 라우팅 페이즈에 즉시 ‘기능적 완전성 훼손 트리거’ 에러를 리턴하고 파이프라인을 블락(Block) 처리한다.

3. 능동적이고 자가 치유적인 쿼리 오라클의 루프백(Loop-back) 시나리오

검색 단계에 배치된 오라클이, 앞서 진행된 1차 검색 결과 뭉치의 품질(MRR, NLI 점수 등)이 형편없다고 0점 평가를 내렸을 때, 그냥 바보처럼 포기하고 화면에 “답변 모릅니다” 에러를 출력하며 죽어버리는 것만이 능사는 결코 아니다. 고도화된 스탠더드의 **능동형 오라클(Active Oracle)**은 검색 실패 상황에서 곧바로 죽지 않고, 과거 채팅의 쿼리(History) 메타데이터와 직전의 ’실패한 검색 결과 객체 찌꺼기’를 혼합하여 파이프라인 엔진에게 스스로 쿼리를 다시 재작성하도록 강제 지시하는 루프백 라우터 엔진(Loop-back Router)을 2차 가동한다.

능동 오라클 로직은 이렇게 프롬프트 엔진을 채찍질한다. “주목하라. 방금 네가 1차 트라이로 던진 쿼리 ’프로젝트 X 일정’으로 Vector망이 가져온 Top-5 문서들은 전부 ‘개발 기술 스펙 코드’ 문단들 뿐이라서 내 NLI 점수를 통과하지 못했다. 명백한 검색 실패다. 유저 질문의 핵심 의도가 코드 스펙이 아니라 ‘일정(Schedule)’ 자체임에 수학적으로 주목하여, 다음 2차 쿼리 페이로드에는 강제로 ‘타임라인’, ‘데드라인’, ‘간트차트’, ‘마일스톤’ 등 스케줄 관련 가중치 토큰을 대거 펜싱(Fencing) 주입하여 다시 한번 재검색(Retrival 2nd Try)을 실시하라.”
이 멈추지 않는 반복적이고 결벽적인 자가 치유적 쿼리 재작성 링(Self-healing Rewrite Ring) 아키텍처 로직이야말로, 비정형 데이터의 바다에서 RAG 오라클이 구사할 수 있는 가장 징그럽고 강력한 비동기적(Asynchronous) 무결성 무기다.