Rerank와 Weight 튜닝, 그리고 예상과 다른 결과들 1부에서는 Amazon OpenSearch Service와 Amazon Bedrock으로 검색 품질을 측정하는 시스템을 만들었습니다. 이제 측정할 수 있게 됐으니, 고객들은 자연스럽게 “그래서 어떻게 개선하지?” 를 묻게 됩니다. 이번 글에서는 측정 결과를 바탕으로 검색 품질을 실제로 끌어올리는 방법을 다룹니다. 사실 저는 이 테스트를 시작할 때 “검색 성능은 Rerank를 붙이면 당연히 좋아지겠지?” 라고 […] || Rerank와 Weight 튜닝, 그리고 예상과 다른 결과들
1부에서는 Amazon OpenSearch Service와 Amazon Bedrock으로 검색 품질을 측정하는 시스템을 만들었습니다. 이제 측정할 수 있게 됐으니, 고객들은 자연스럽게 “그래서 어떻게 개선하지?” 를 묻게 됩니다. 이번 글에서는 측정 결과를 바탕으로 검색 품질을 실제로 끌어올리는 방법을 다룹니다.
사실 저는 이 테스트를 시작할 때 “검색 성능은 Rerank를 붙이면 당연히 좋아지겠지?” 라고 생각했습니다. 그런데 돌려보니 그 예상이 일부만 맞았습니다. 특정 상황에서는 Rerank가 검색 성능 +19% 개선을, 이미 잘 튜닝된 상황에서는 오히려 4~9% 악화를 가져왔습니다. 이런 결과를 보면서 1부에서 만든 평가 시스템이 꼭 필요하다는 것을 다시 확인했습니다. 만약 제가 이 성능을 측정하지 않았다면 계속 “Rerank 쓰면 좋아지겠지” 라고 생각하고 튜닝 시간을 낭비했을 겁니다.
1부에서 말씀드렸듯 이 시리즈의 테스트는 AI 코딩 어시스턴트와 함께 진행했습니다. Kiro, Codex, Cursor, Claude Code 같은 도구에 “Grid Search로 최적 가중치를 찾아줘”, “Rerank를 적용해 성능을 비교해줘” 같은 지시를 주면 스크립트 작성부터 실행, 결과 정리까지 이어집니다. 글 후반부에서는 이 자동화 방식과, 운영 환경에서 검색 품질을 주기적으로 확인할 수 있는 방법도 안내합니다.
세 가지 개선 기법
검색 품질을 끌어올리는 대표적인 방법은 세 가지이고 각각 비용과 효과가 다릅니다.
기법
하는 일
비용
Rerank
초기 검색 결과를 별도 모델로 다시 정렬
추가 API 호출, 지연시간 증가
Weight 튜닝
하이브리드 검색의 BM25 와 k-NN(k-Nearest Neighbor) 비율 조정
없음 (설정값만 변경)
임베딩 모델 교체
더 성능 좋은 임베딩 모델로 교체
전체 문서 재색인
세 번째인 임베딩 모델 교체는 효과가 클 수 있지만 전체 문서를 다시 색인해야 해서 운영 중인 서비스에서는 부담이 가장 큽니다. 그래서 이 글에서는 상대적으로 시도하기 쉬운 앞의 두 가지, Rerank와 Weight 튜닝을 실제로 적용하고 그 효과를 측정합니다.
테스트 파이프라인
두 기법을 어떻게 실험했는지 먼저 정리하면 그림 1과 같습니다. 하이브리드 검색으로 상위 20개를 뽑고 여기에 Rerank를 선택적으로 적용한 뒤 최종 상위 10개를 1부의 평가 방식으로 채점합니다. 채점 지표는 1부와 같은 NDCG@10 (Normalized Discounted Cumulative Gain)입니다.
Rerank, 기대와 현실
Rerank는 초기 검색으로 뽑은 상위 문서들(여기서는 Top 20)을 전용 모델에 다시 통과시켜 쿼리와의 관련성이 높은 순서로 재정렬하는 기법입니다. 초기 검색이 후보를 빠르고 넓게 모으는 역할이라면 Rerank는 그중에서 실제로 관련 있는 문서를 위로 올리는 정밀 작업에 가깝습니다. 일반적으로 검색 품질을 높인다고 알려져 있고 저도 그렇게 기대하고 테스트를 시작했습니다.
Cohere Rerank 적용 방법
Amazon Bedrock에서 Cohere Rerank 모델을 호출하는 코드는 생각보다 간단합니다. 검색으로 얻은 문서 목록과 원래 쿼리를 함께 넘기면, 모델이 재정렬된 순서와 관련성 점수를 돌려줍니다.
def rerank_with_cohere(bedrock_client,