4장이 들보를 올렸다면 5장은 문살을 짜 넣는 장이다. 베 짜는 이가 날실만으로는 옷감을 못 짜듯, 검색도 벡터 하나만으로는 완성되지 않는다. 벡터의 씨실에 어휘의 날실을 엮고, 재순위화로 올을 고르고, 질의 변환으로 실 끝을 다듬는다 — 2026년의 프로덕션 검색이란 이 다섯 단의 베틀 위에서 짜이는 것이다.
대기업을 고객으로 둔 한 조달 인텔리전스 플랫폼이 창업자들이 대표 기능으로 여기던 것 — 공급업체 계약과 구매 주문 전반에 걸친 자연어 검색 — 을 안고 정식 출시에 나섰다. 셀링 포인트는 단순했다. 질문을 평이한 영어로 치면 관련 계약 조항이 돌아온다, PDF 더미를 몇 시간씩 뒤지지 마라. 베타는 시리즈 B를 닫을 만큼 성공적이었고, 프로덕션 출시는 모든 것이 하나로 모이는 순간이어야 했다.
출시 사흘 뒤, 고객사의 최고조달책임자가 질의를 친다. "팬데믹 사태를 배제하는 불가항력 조항이 든 우리 계약을 전부 보여 달라." 시스템은 여덟 건을 자신 있게 내놓았다. 이십 년 경력의 그는 목록에서 뭔가 어긋남을 알아챘고, 팀을 시켜 문서 관리 시스템에서 불가항력 조항이 든 계약을 손으로 전부 뽑게 했다. 실제 수는 마흔일곱. 시스템은 여덟을 돌려주었다.
돌아온 여덟은 조항에 "force majeure"라는 문구가 그대로 들어 있으면서 임베딩 모델이 질의와 의미적으로 가깝다고 여긴 언어를 곁들인 계약들이었다. 나머지 서른아홉 — "act of God", "impossibility of performance", "frustration of contract", 혹은 그저 "unforeseen circumstances"라는 등가 표현을 쓴 — 은 벡터 유사도에 보이지 않았다. 질의와 계약이 같은 법률적 내용을 다른 어휘로 말하고 있었고, 순수 벡터 검색은 그 간극을 잇지 못했다. 반대로 "force majeure"라는 문구를 전혀 무관한 맥락에 담은 계약들 — 이를테면 접객 벤더 MSA에 박힌 호텔 예약 정책의 불가항력 배제 — 이 자신만만한 일치로 회수되었다.
피해를 가늠하러 불려 온 고객사 변호사들은 지난 6주 동안 조달 팀이 불가항력 익스포저의 전모를 보고 있었다면 다르게 내려졌을 상업적 결정을 적어도 셋 찾아냈다. 그 결정들의 계약 가치는 고객사 스스로의 표현으로 "중대(material)"했다. 수습은 2주가 걸렸고 내용은 아키텍처 변경 하나 — 하이브리드 검색 — 였다. 불가항력 질의군의 재현율은 20% 아래에서 90% 위로 올라섰다. 벡터 단독의 실패는 임베딩 모델의 실패도, 벡터 데이터베이스의 실패도, 청킹의 실패도 아니었다. 아키텍처적 완결성의 실패였다. 팀은 검색 시스템의 절반을 지었던 것이고, 나머지 절반을 짓기 전까지는 가진 절반을 아무리 조율해도 간극이 닫히지 않았을 것이다.
이 장이 그 나머지 절반이다. 임베딩 모델과 인덱스와 청크가 다 잘 공학되어 있어도 벡터 검색 단독은 프로덕션에 구조적으로 불충분하다. 2026년에 하이브리드 검색은 최적화가 아니라 아키텍처의 기본값이다. 재순위화는 융합된 후보 집합을 하류가 의지하는 정밀한 top-k로 바꾸고, 질의 변환은 남은 간극을 질의 쪽에서 닫는다. 이 장을 마칠 즈음, 조달 플랫폼의 2주짜리 수습은 오후 한나절의 아키텍처 결정 — 출시 전에 내렸어야 할 — 으로 보일 것이다.
하이브리드 검색은 벡터 유사도 검색과 어휘 검색 — 통상 BM25 — 을 하나의 검색 시스템으로 결합해 두 방법의 융합으로 결과 집합을 내는 패턴이다. 2026년 프로덕션 RAG의 아키텍처 기본값이며, 그 근거는 이론이 아니라 경험이다. 벤치마크와 프로덕션 배포를 가로질러 하이브리드 검색은 어느 단독 방법보다 도메인에 따라 검색 재현율 기준 10~40%를 꾸준히 앞선다. 벡터 단독으로 출시하는 팀은 상당한 재현율을 탁자 위에 버려두는 것이고, 대개 조달 책임자가 찾았어야 할 계약을 세어 보기 전까지는 그 사실을 모른다.
하이브리드가 통하는 이유는 두 검색이 다르게 실패하기 때문이다. 벡터 검색은 임베딩 모델이 질의 어휘와 말뭉치 어휘의 등가성을 배우지 못했을 때 — 2장이 깊이 살핀 의미적 간극에서 — 실패한다. 어휘 검색은 뜻이 같아도 낱말이 다를 때 실패한다. 두 실패 양식은 대체로 독립적이며, 바로 그 성질이 결합을 어느 단독보다 훨씬 강하게 만든다. 벡터가 놓친 관련 문서를 어휘가 자주 붙잡고, 어휘가 놓친 환언을 벡터가 자주 찾는다. 결합은 각자가 찾을 수 있는 것의 합집합을 붙잡는다.
조달 플랫폼의 불가항력 실패가 정전의 예다. 벡터 검색은 "팬데믹 사태를 배제하는 불가항력 조항"에 의미적으로 가까운 언어의 계약 — 사실상 "force majeure" 문구를 그대로 쓴 계약 — 만 찾았다. 법률 어휘의 제대로 된 동의어 확장을 곁들인 어휘 검색이었다면 "act of God"과 "impossibility of performance" 등 어휘 변형을 쓴 계약들을 찾았을 것이다. 어느 방법도 단독으로는 재현율 90%에 닿지 못했고, 결합은 닿았다.
두 구성요소를 보자. 벡터 검색은 2026년쯤 대부분의 팀이 이해하는 쪽이다. 질의를 임베딩하고, 근사 최근접 탐색으로 인덱싱된 말뭉치 임베딩과 견주고, 코사인 유사도 상위 k개를 돌려준다. 환언·동의어·개념 대응에는 잘 통하고, 정확한 식별자·희귀 용어·극성 민감 질의에는 서툴다. 어휘 검색 — 통상 BM25, 다중 필드 문서에는 그 변형 BM25F — 은 많은 팀이 과소평가하는 쪽이다. BM25는 항 빈도, 역문서 빈도, 문서 길이 정규화의 가중 결합으로 점수를 매긴다. 질의에 "acetaminophen"이 있으면 BM25는 "acetaminophen"이 든 문서를 찾는다. 질의와 결과 사이에 끼어드는 임베딩 모델도, 용어를 소리 없이 잃을 압축층도 없다. 대가는 동의어와 환언을 스스로 잇지 못한다는 것이다.
현대의 어휘 검색은 원래의 BM25 명세가 시사하는 것보다 유능하다. 어간 추출, 표제어 추출, 불용어 처리는 표준 전처리이고, 선별된 사전을 통한 동의어 확장 — 용어의 등가성이 안정된 도메인 특화 응용에서 특히 중요하다 — 은 어휘 검색의 실효 재현율을 몇 배로 불린다. 일부 프로덕션 시스템은 SPLADE 같은 학습된 희소 검색기를 쓴다 — 정확 일치와 학습된 확장을 하나의 희소 벡터에 담는 것이다. 알아 둘 가치가 있는 확장들이되, 바탕의 아키텍처 논점은 같다. 어휘 검색은 벡터 검색의 보완이고, 현대의 프로덕션은 둘을 결합한다.
결합이 가장 극적으로 이기는 곳은 질의 어휘와 말뭉치 어휘가 구조적으로 갈라지는 도메인 — 법률, 의료, 금융, 기술, 그리고 상당한 전문 용어를 지닌 모든 분야 — 이다. 임베딩 모델이 의미적으로 변별적임을 알아보지 못하는 식별자·코드·고유명사가 낀 질의에서도, 극성이 관건인데 임베딩이 그 구별을 뭉개는 부정 민감 질의에서도, 어떤 면은 정확 일치가 어떤 면은 의미 유사가 가장 잘 섬기는 다면 질의에서도 이긴다. 요컨대 대부분의 프로덕션 질의에서 이기며, 그 이득은 추가 공학 투자가 손익분기에 근접하는 일조차 드물 만큼 크다.
하이브리드 검색은 둘 이상의 검색 방법 — 통상 벡터 유사도와 어휘 BM25 — 을 융합 알고리즘이 만드는 단일 결과 집합으로 결합하는 것이다. 두 방법은 병렬로 돌고, 출력은 통합된 순위로 병합된다.
하이브리드 검색의 정의적 성질은 방법들이 다르게 실패한다는 것이다. 벡터 결과가 나쁜 질의가 어휘 결과는 좋기 일쑤고, 그 반대도 마찬가지다. 융합 알고리즘은 이 독립성을 활용한다 — 어느 한쪽에서 잘 순위되는 문서는 관련되기 쉽고, 양쪽 모두에서 잘 순위되는 문서는 거의 확실히 관련된다.
벡터와 어휘를 둘 다 돌리기로 했다면 다음 물음은 결과를 어떻게 합치느냐다. 프로덕션을 지배하는 방법은 둘이고, 저마다 트레이드오프가 있으며, 옳은 선택은 점수 보정 데이터가 있는지와 조율에 얼마나 공학을 들일지에 달렸다.
상호 순위 융합(RRF)이 둘 중 더 단순하고 더 강건하다. 어느 결과 목록에든 나타나는 각 문서에 대해, 목록에서의 순위 위치에 기반한 점수를 계산해 목록들에 걸쳐 합산한다. 공식은 간명하다 — 각 목록에서 순위 r의 문서는 총점에 1/(k+r)을 보태며, k는 점수가 순위에 따라 얼마나 가파르게 떨어지는지를 다스리는 상수(통상 60)다. 양쪽 목록의 위쪽에 나타나는 문서가 가장 높은 총점을 쌓는다. RRF의 핵심 성질은 점수 보정 없이 작동한다는 것이다. 바탕 점수가 아니라 순위 위치만 쓰므로, 벡터 코사인 유사도와 BM25가 비교 불가능한 척도의 점수를 낸다는 사실에 면역이다. 그래서 RRF가 대부분의 프로덕션에 옳은 기본값이다 — 상자에서 꺼내자마자 돌고, 조율이 필요 없고, 거동을 추론하기 쉽다. 2026년의 프로덕션 하이브리드 검색 대부분이 RRF나 그 근연 변형을 쓴다.
# 상호 순위 융합 — 프로덕션의 기본값 from collections import defaultdict def reciprocal_rank_fusion(result_lists, k=60): """ result_lists: (doc_id, score) 튜플이 순위순(최고 먼저)으로 담긴 목록들의 목록. k: 평활 상수, 통상 60. 클수록 뒷순위 문서의 영향이 커진다. 반환: fused_score 내림차순의 (doc_id, fused_score) 목록. """ fused_scores = defaultdict(float) for results in result_lists: for rank, (doc_id, _) in enumerate(results, start=1): fused_scores[doc_id] += 1.0 / (k + rank) return sorted(fused_scores.items(), key=lambda x: x[1], reverse=True) # 하이브리드 검색 파이프라인에서의 사용 vector_results = vector_store.search(query, k=50) lexical_results = bm25_index.search(query, k=50) fused = reciprocal_rank_fusion([vector_results, lexical_results], k=60) top_candidates = fused[:20] # 리랭커로 보낸다
가중 점수 융합은 보정 데이터가 있을 때 쓸 수 있는 더 강력한 대안이다. 순위 위치에 기대는 대신, 각 방법의 원점수를 공통 척도로 정규화(통상 후보 집합에 대한 최소-최대 정규화)한 뒤 명시적 가중치로 결합한다. 결합 점수는 가중합 — 정규화된 벡터 점수의 α배에 정규화된 어휘 점수의 (1−α)배를 더한 것으로, α는 0과 1 사이의 조율 파라미터다. 장점은 순위 순서만이 아니라 점수 크기를 활용할 수 있다는 것 — 임베딩 모델이 한 문서에 매우 높은 유사도를, 다른 문서에 중간 유사도를 냈을 때 그 정보가 가중 융합에서는 살고 RRF에서는 죽는다. 단점은 조율이 필요하고 — α와 정규화 방법의 선택 — 그 조율이 도메인 특정적이라는 것이다. 잘못된 α는 가중 융합을 어느 순수 방법보다도 못하게 만든다.
실무에서 가중 융합이 옳은 것은 α를 조율할 레이블된 평가 집합이 있을 때, 근소하게 높은 정밀도의 값어치가 공학 투자를 정당화할 때, 조율된 가중치가 유효하게 남을 만큼 도메인 특성이 안정적일 때다. 그 밖의 모든 경우에는 RRF가 옳고 — 오늘의 프로덕션에서 그것은 대부분의 팀이다.
프로덕션 배포들을 가로지르는 경험적 패턴은 이렇다. RRF는 조율 노력 없이 최적 하이브리드 검색의 80~90%까지 데려다주고, 제대로 조율된 가중 점수 융합이 나머지 10~20%를 채운다. 대부분의 팀에게는 그 80~90%로 족하며, 제대로 된 조율에 들일 공학은 대개 더 큰 이득을 내는 재순위화와 질의 변환에 쓰는 편이 낫다. RRF로 시작하라. RRF로 검색 성능을 재고, 잔여 격차가 응용에 중요함을 확인하고, 제대로 조율할 평가 인프라를 갖췄을 때만 가중 융합으로 옮겨라.
하이브리드 검색이 후보 50~100건을 돌려준 뒤에도 일은 남아 있다. 후보 집합의 재현율은 높지만(관련 문서가 그 안에 있을 공산이 크지만) 정밀도는 중간이다(최상위 문서들이 가장 관련된 것이 아닐 수 있다). 이 집합을 소비하는 언어 모델은 상위 몇 건만 본다 — 순위 5나 10 너머는 사실상 보이지 않는다. 재순위화는 후보 집합을 받아 가장 관련된 문서가 꼭대기로 오도록 재정렬하는 연산이다. 중간 정밀도의 검색을 생성이 실제로 의지하는 고정밀 입력으로 바꾸는 2단 필터다.
바이 인코더 대 크로스 인코더. 지금까지의 검색 방법 — 벡터 검색과 BM25 — 이 계산상 싼 것은 질의와 각 문서를 직접 견주기를 피하기 때문이다. 벡터 검색은 미리 계산된 임베딩을 비교하고, BM25는 항 통계를 조회한다. 어느 쪽도 질의와 후보 문서를 함께 처리하는 신경망을 돌리지 않는다. 그래서 수백만 문서 위의 1단 검색에 충분히 빠르다. 재순위화는 이 트레이드오프를 뒤집는다. 크로스 인코더 리랭커는 질의와 각 후보 문서를 이어 붙여 트랜스포머를 그 결합쌍 위에 돌려 관련성 점수를 낸다. 모델이 질의와 문서에 함께 주의를 기울일 수 있으므로 바이 인코더(벡터 검색)와 어휘 방법이 놓치는 미묘한 관련 신호를 잡아낸다. 대가는 계산이다 — 후보 50건 위의 크로스 인코더는 문서 100만 건 위의 벡터 검색보다 수백 배 비싸다. 이 거래가 성립하는 것은 오직 크로스 인코더가 1단 검색이 무거운 여과를 끝낸 뒤의 작은 후보 집합 위에서 돌기 때문이다.
프로덕션의 리랭커 선택지는 2026년에 세 갈래가 지배한다. 첫째, 상용 API — Cohere Rerank, Voyage Rerank, 그리고 점점 Anthropic과 OpenAI도 재순위화 엔드포인트를 낸다. 편리하고 고품질이며 속도 제한이 있다. 지연이 완만해도 되고, API 비용이 예산에 맞고, ML 인프라 자체 운영이 팀의 강점이 아닐 때 옳다. 둘째, 오픈소스 크로스 인코더 — BAAI의 BGE Reranker 계열과 Sentence-BERT의 크로스 인코더가 지배한다. 공개 벤치마크 대부분에서 상용 API에 필적하고, 상용 GPU에 자체 호스팅하면 규모에서 질의당 비용이 훨씬 싸다. 볼륨으로 운영하며 모델 서빙 스택을 유지할 공학 역량이 있는 팀에 옳다. 셋째, ColBERT류 후기 상호작용 모델 — 검색과 재순위화의 경계에 걸터앉아, 토큰별 임베딩을 만들고 토큰 수준 최댓값의 합으로 관련성을 계산한다. 바이 인코더 검색에 가까운 속도로 리랭커급 정밀도를 내며, 전용 인프라 투자(저장이 더 들고 서빙이 다소 커스텀)가 정당화되는 고위험 응용에 옳다.
파이프라인 속의 재순위화. 표준 프로덕션 파이프라인은 1단 검색과 최종 문서 선택 사이에서 재순위화를 돌린다. 하이브리드 1단 검색이 재현율 높은 후보 50~100건을 돌려주면, 리랭커가 전부를 질의에 대해 채점해 정밀도 높은 상위 5~20건을 돌려주고, 그것이 언어 모델의 컨텍스트 창에 들어간다. 캐스케이드를 다스리는 파라미터는 둘이다 — 재순위화로 보내는 후보 집합 크기 k1(클수록 리랭커에 재료가 많아져 상위 정밀도가 오르되 재순위화 지연이 커지며, 대부분의 프로덕션에 50~100이 최적 지대)과, 재순위화가 돌려주는 최종 top-k k2(언어 모델이 실제로 보는 것으로, 컨텍스트 창과 추가 맥락의 한계 효용에 제약된다).
재순위화는 대부분의 프로덕션 말뭉치에서 1단 검색 단독 대비 top-k 정밀도를 20~50% 끌어올린다. 하이브리드 1단과 결합하면 개선이 복리로 붙는다 — 하이브리드 검색과 재순위화를 함께 쓰는 파이프라인은, 벡터 단독이 top-5 정밀도 40~50%를 내던 말뭉치에서 80~90% 범위를 예사로 낸다. 이 복리 개선이 2부의 기초와 3부의 고급 패턴 사이에 놓인 가장 큰 단일 아키텍처 지렛대다.
벡터나 하이브리드 검색을 재순위화 없이 돌리는 많은 팀이 자기들에게는 필요 없다고 믿는다. 1단 결과가 대충 훑어보기에 그럴듯하고, 언어 모델이 그럴듯한 답을 내기 때문이다. 현재 성능과 재순위화가 가져다줄 성능 사이의 격차는 비교 대상이 없어서 보이지 않는다. 격차는 실재하고, 크고, 거의 모든 프로덕션 배포에서 공학 투자의 값어치가 있다. 리랭커를 배포하지 않았다면 검색 정밀도의 3분의 1을 탁자 위에 버려두고 있는 것이다. 이를 입증하는 이틀짜리 평가는 프로덕션 RAG를 운영하는 모든 팀이 해 볼 가치가 있다.
하이브리드 검색과 재순위화는 문서 쪽에서 일한다 — 주어진 질의에 문서를 더 잘 맞추는 것이다. 질의 변환은 질의 쪽에서 일한다 — 검색 전에 질의를 고쳐, 고쳐진 질의가 말뭉치와 더 효과적으로 만나게 하는 것이다. 두 접근은 상보적이며, 프로덕션급 시스템은 둘 다 쓴다.
가장 단순한 변환 — 언어 모델이 사용자 질의를 더 검색 친화적인 변형 하나 이상으로 고쳐 쓴다. "구독을 어떻게 해지하나"라는 자연어 질의가 "구독 해지 정책 절차"라는 검색 표적형 정식화가 된다. 재작성은 대화체 틀을 벗기고, 줄인 어휘를 펼치고, 말뭉치가 내용을 표현할 법한 형태에 가깝게 질의를 구조화한다. 통하는 이유는 사용자 질의와 말뭉치 내용이 다른 문체로 쓰이기 때문이다 — 사용자는 대화체 군더더기와 인칭대명사가 섞인 질문으로 묻고, 말뭉치는 권위적인 3인칭 산문으로 쓰인다. 현대 프로덕션 대부분은 재작성을 빠른 언어 모델에의 작은 프롬프트 호출로 구현한다 — 수백 밀리초의 지연, 질의당 1센트 미만의 비용, 흔히 5~15%의 재현율 개선.
재작성보다 더 나아간다 — 재작성된 질의 하나가 아니라 여러 변형을 만들어 각각 독립적으로 검색하고 결과를 융합한다. 확장은 동의어, 관련어, 대안 표현을 보탤 수 있다. 이 장 서두의 조달 플랫폼이라면 "force majeure"를 "act of God", "impossibility of performance", "frustration of contract"로 넓히는 확장 — 검색 쪽에 맡기는 대신 질의 쪽에서 어휘 간극을 잇는 도메인 확장 — 의 덕을 봤을 것이다. 확장은 선별 가능한 안정된 용어 등가성이 있는 도메인에서 가장 강력하다 — 법률 확장 어휘집, 의료 동의어 목록(UMLS가 정전의 예), 금융 용어 매핑. 언어 모델을 통한 범용 동의어 확장도 유용하되 품질이 들쭉날쭉하다. 프로덕션은 흔히 둘을 결합한다 — 팀이 이해하는 고위험 용어에는 선별 확장, 긴 꼬리에는 언어 모델 확장.
벡터 검색의 구조적 문제를 겨눈 영리한 변환이다. 문제는 이것 — 질문의 임베딩과 그 답의 임베딩은 같은 내용을 다뤄도 구문·담화 구조가 달라 벡터 공간에서 그리 가깝지 않은 일이 잦다. HyDE는 언어 모델로 질문에 대한 가설적 답을 생성하고, 그 가설 답을 임베딩해, 질문 임베딩 대신 가설 답 임베딩으로 검색한다. 직관은 이렇다 — 가설 답은 세부가 틀렸더라도 말뭉치의 실제 답들과 구조적으로 닮았고, 따라서 그 임베딩이 질문의 임베딩보다 실제 답들에 가깝다. 놀랄 만큼 잘 통하며, 질문과 답의 표면형이 크게 다른 도메인에서 특히 그렇다. 비용은 질의당 언어 모델 호출 한 번, 통상 수백 밀리초. 이득은 더 단순한 재작성 기법을 흔히 웃도는 재현율 개선이다.
여러 변환을 하나의 검색 연산으로 묶는다. 사용자 질의를 서너다섯 변형 — 서로 다른 재작성, 확장판, HyDE판 — 으로 고쳐 각각 독립 검색하고, RRF류로 융합한다. 검색은 각 변형이 찾을 것의 합집합이 된다. 계산은 단일 질의보다 비싸지만 — 통상 1단 검색 비용의 3~5배 — 검색들이 병렬로 돌 수 있어 지연 영향은 완만하다. 어느 한 표현도 검색 의도 전체를 담지 못하는 복잡한 질의에서 재현율 개선이 상당하다. 대부분의 프로덕션은 멀티쿼리를 선별적으로 쓴다 — 복잡한 질의에는 발동하고, 단순 조회에는 더 싼 단일 질의 검색을 쓴다.
# 멀티쿼리 검색 — 프로덕션 패턴 from concurrent.futures import ThreadPoolExecutor def generate_query_variants(query, llm): """사용자 질의의 검색 표적형 변형 3개를 생성한다.""" prompt = f"""Generate 3 alternative phrasings of this question that would be useful for searching a document corpus. Cover different vocabulary, granularity, and phrasing styles. Question: {query} Return as a JSON list of strings.""" response = llm.complete(prompt) return json.loads(response) # 변형 질의 3개의 목록 def multi_query_retrieve(query, llm, retriever, k_per_query=20): variants = [query] + generate_query_variants(query, llm) with ThreadPoolExecutor(max_workers=len(variants)) as pool: # 각 변형이 병렬로 질의한다 futures = [pool.submit(retriever.search, v, k=k_per_query) for v in variants] result_lists = [f.result() for f in futures] # 네 개의 순위 목록을 하나로 융합한다 fused = reciprocal_rank_fusion(result_lists, k=60) return fused
검색 파이프라인에는 이제 여러 단이 있다 — 질의 변환, 하이브리드 1단 검색, 재순위화, 최종 선택. 그림을 완성하는 한 층이 더 있다. 메타데이터 필터링이다. 필터링은 유사도 점수와 무관하게 특정 기준을 만족하는 문서로 결과를 제한하는 하드 제약을 검색에 건다. 범용 검색을 응용 인지 검색으로 바꾸는 기제이며, 전적으로 4장에서 설계한 메타데이터 스키마에 의지한다. 필터링은 파이프라인의 세 지점에 걸 수 있고, 저마다 트레이드오프가 다르다.
유사도 검색 전에 제약을 걸어 벡터·어휘 검색이 도는 후보 공간을 줄인다. 특정 문서 유형이나 특정 시간 창으로 제한된 질의는 말뭉치의 1% 미만에 해당할 수 있고, 사전 필터링은 유사도 검색이 그 작은 부분집합에 집중하게 한다. 단점 — 일부 벡터 데이터베이스에서 사전 필터링과 근사 벡터 검색의 궁합이 나쁘다. 인덱스가 전체 말뭉치에 최적화되어 있어 작은 부분집합으로의 제한이 재현율을 해칠 수 있다. Qdrant와 Weaviate는 고선택 사전 필터링을 잘 다루고, 어떤 것들은 이 패턴에서 크게 퇴화한다.
유사도 검색 뒤에 제약을 걸어 메타데이터 기준에 어긋나는 일치 문서를 제거한다. 유사도 검색은 전체 인덱스를 돌고, 필요보다 많은 후보를 돌려주고, 필터가 탈락자를 걸러 낸다. 표준 패턴은 1단에서의 과잉 회수 — 상위 50 대신 100을 가져와 후보 집합에 필터를 걸어 사후 필터링된 top-k가 여전히 넉넉히 차 있게 하는 것이다.
어떤 필터는 검색 전에, 어떤 필터는 검색 후에 건다. 문서 유형(고선택 — 사전)과 최근성(저선택 — 사후)으로 거르는 질의가 양쪽의 장점을 다 얻는다. 필터 차원이 여럿이 되면 대부분의 프로덕션 시스템이 결국 하이브리드 필터링 패턴에 이른다.
질의 변환(재작성, 확장, HyDE) → 질의를 고치고 때로 여럿으로 불린다. 1단 검색(하이브리드 벡터+어휘, RRF 융합) → 고재현율 후보 50~100건을 낸다. 메타데이터 필터링(사전·사후) → 스키마의 하드 제약을 강제한다. 재순위화(크로스 인코더) → 후보 집합을 고정밀 top-k로 재정렬한다. 최종 선택 → 언어 모델이 소비할 상위 5~20건을 돌려준다.
각 단은 독립적으로 공학 가능하며, 함께 2026년의 프로덕션 검색 아키텍처를 이룬다.
이 5단 캐스케이드가 조달 플랫폼이 처음부터 출시했어야 할 프로덕션 아키텍처다. 각 단이 최종 품질에 독립적으로 기여하며, 어느 단을 건너뛰든 시스템은 저마다의 특징적 방식으로 부진해진다. 질의 변환을 건너뛰면 사용자가 말뭉치 친화적 표현으로 물어 주기를 시스템이 기대게 된다. 하이브리드를 건너뛰면 의미 유사가 이을 수 없는 어휘 일치를 놓친다. 필터링을 건너뛰면 낡거나 범위 밖의 문서가 현행 관련 콘텐츠와 경쟁한다. 재순위화를 건너뛰면 언어 모델에 전달되는 top-k가 고정밀이 아니라 중간 정밀에 머문다.
캐스케이드의 조율은 노련한 검색 엔지니어의 일이다. 중요한 파라미터들 — k1(1단 후보 집합 크기), k2(재순위화 후 최종 top-k), 융합 알고리즘의 선택, 리랭커 모델, 질의 변환의 공격성, 필터 순서 — 은 모두 상호작용한다. 옳은 조율은 구체적인 말뭉치, 구체적인 질의 분포, 구체적인 지연·비용 제약에 달렸다. 9장이 이 조율을 어림짐작이 아니라 체계로 만드는 평가 방법론을 세운다.
벡터 단독 검색으로 프로덕션 RAG를 출시하는 것은 이 분야에서 가장 흔한 단일 아키텍처 실수다. 흔한 질의에서는 그런대로 돌아 격차가 보이지 않다가, 도메인 전문가가 재현율을 감사하고 나서야 용어 민감 질의에서 관련 문서의 80%를 놓치고 있음이 드러난다.
처방 — 하이브리드 검색은 어떤 프로덕션 배포에서도 협상의 여지가 없다. 할 수 있는 가장 싼 개선의 하나이자 가장 임팩트 큰 개선의 하나다.
임베딩 모델과 리랭커가 같은 모델 계열 — 비슷한 훈련 데이터, 비슷한 트랜스포머 구조 — 이면 리랭커가 가져올 수 있는 새 정보가 줄어든다. 둘이 같은 실수를 하기 때문이다.
처방 — 임베딩 모델과 다른 계열이거나 다른 데이터로 훈련된 리랭커를 써서 두 단이 독립적인 실패 양식을 갖게 하라. 다른 혈통의 크로스 인코더가 가장 중요한 사례들에서 같은 계열 리랭커를 통상 앞선다.
변환을 무차별로 적용하는 것 — 모든 질의를 재작성·확장·HyDE에 다 통과시키는 것 — 은 필요 없던 단순 질의에 지연을 낭비하고, 이미 잘 만들어진 질의를 왜곡할 위험을 진다.
처방 — 질의 특성에 따라 선별 적용하라. 짧은 키워드 질의에는 대개 변환이 아니라 어휘 검색이 필요하고, 긴 자연어 질의는 재작성의 덕을 자주 보고, 복잡한 다면 질의는 멀티쿼리 확장의 덕을 본다. 라우팅 로직을 지어라. 모든 변환을 모든 질의에 걸지 마라.
하이브리드 검색 — 벡터 유사도와 어휘 BM25의 결합 — 이 2026년 프로덕션 RAG의 아키텍처 기본값이다. 두 방법은 다르게 실패하고, 결합은 각자가 찾을 수 있는 것의 합집합을 붙잡는다. 벡터 단독 검색은 프로덕션에 구조적으로 불충분하며, 그 격차는 결과에 실질적으로 영향을 줄 만큼 크다.
상호 순위 융합(RRF)이 서로 다른 검색의 순위 목록을 합치는 옳은 기본값이다. 점수 보정 없이 돌고, 비교 불가능한 점수 척도에 강건하며, 가중 점수 융합이 줄 수 있는 이득의 80~90%를 조율 비용 0에 낸다. 잔여 격차가 중요함이 측정으로 드러날 때만 가중으로 옮겨라.
크로스 인코더 재순위화는 1단 검색 단독 대비 top-k 정밀도를 20~50% 끌어올린다. 계산 비용은 실재하지만 1단 여과 뒤의 작은 후보 집합 위에서 돌므로 거래가 유리하다. 재순위화 없는 프로덕션급 RAG는 상당한 정밀도를 탁자 위에 버려두고 있다.
질의 변환은 의미적 간극을 질의 쪽에서 닫는다. 재작성, 확장, HyDE, 멀티쿼리가 저마다 간극의 다른 면을 겨눈다. 무차별이 아니라 질의 특성에 따라 선별 적용하라 — 짧은 키워드 질의에 맞는 변환과 복잡한 자연어 질문에 맞는 변환은 다르다.
완전한 검색 캐스케이드 — 질의 변환, 하이브리드 1단, 메타데이터 필터링, 재순위화, 최종 선택 — 가 2026년의 프로덕션 아키텍처다. 각 단이 독립적으로 기여하고, 어느 하나를 건너뛰면 특징적인 실패 양식이 나타난다. 조달 플랫폼의 2주짜리 수습이 실제로 지은 것이 이 캐스케이드이며, 처음부터 지었어야 할 것도 이것이다.
위 문헌 목록은 원서 5장의 Further Reading을 그대로 옮긴 것이다. 서지 사항의 최종 확인은 원 출처를 통해 하는 것이 옳다.
6장은 3부의 문을 연다 — 프로덕션 RAG를 하이브리드 검색 파이프라인에서 이 책의 제목이 약속하는 에이전틱 시스템으로 끌어올리는 고급 패턴들이다. 출발은 GraphRAG — 문서 자체에서 추출한 지식 그래프로 말뭉치를 보강해 멀티홉 불충분의 한계를 겨누는 아키텍처 패턴이다. 이 장에서 지은 검색 캐스케이드는 그대로 토대로 남고, GraphRAG는 텍스트 단독 방법이 따를 수 없는 구조적 검색 능력으로 그것을 확장한다. 3부의 세 장은 2부의 캐스케이드를 지식 그래프, 자기교정, 오케스트레이션된 멀티 에이전트 검색으로 승격시킨다 — 검색이 마침내 시스템이 되는 곳이다. 문살을 짜 넣었으니 이제 단청을 올릴 차례다.