RAG 시스템에서 답변 품질이 낮을 때 모델만 바꾸는 팀이 많습니다. 하지만 실제 원인은 생성 모델보다 검색 단계인 경우가 흔합니다. 검색 결과 상위 5개 문서에 정답 근거가 없으면, 아무리 좋은 LLM도 추측하게 됩니다. Hugging Face에 공개된 Ettin Reranker 계열은 이 문제를 비용 안에서 다루기 좋은 선택지입니다. 17M부터 1B까지 여섯 가지 크기의 CrossEncoder reranker가 제공되고, retrieve-then-rerank 구조에 바로 넣을 수 있습니다.
출처: Hugging Face Blog, “Introducing the Ettin Reranker Family”, 2026-05-19.
일반적인 벡터 검색은 query와 document를 각각 embedding으로 바꾼 뒤 cosine similarity나 dot product로 후보를 찾습니다. 빠르고 확장성이 좋지만, query와 document가 서로 모든 토큰 수준에서 상호작용하지는 않습니다. 그래서 단어가 비슷하지만 의미가 다른 문서가 올라오거나, 정답 근거가 포함된 문서가 20위 밖으로 밀리는 일이 생깁니다.
Reranker, 특히 CrossEncoder는 query와 document 쌍을 함께 입력받아 relevance score를 냅니다. 문서마다 한 번씩 모델을 돌려야 하므로 전체 corpus에 직접 적용하기는 비쌉니다. 대신 production에서는 retrieve-then-rerank 패턴을 씁니다. embedding retriever가 top 50 또는 top 100 후보를 빠르게 가져오고, reranker가 그 후보만 다시 정렬합니다.
이 구조의 장점은 비용이 예측 가능하다는 점입니다. corpus가 100만 문서든 1억 문서든 reranker가 보는 문서 수는 top-K로 제한됩니다. RAG 답변 품질을 올리고 싶지만 대형 reranker 비용이 부담되는 팀에게 작은 reranker 계열은 의미가 큽니다.
공개된 모델은 17M, 32M, 68M, 150M, 400M, 1B 여섯 가지입니다. 모두 Johns Hopkins University의 Ettin encoder를 기반으로 하며, ModernBERT 스타일 구조와 최대 8192 토큰 컨텍스트를 지원합니다. Hugging Face 글에 따르면 google/embeddinggemma-300m 등 여러 embedder와 조합해 MTEB Retrieval benchmark에서 평가됐고, 68M 모델도 평균 NDCG@10 기준으로 꽤 높은 위치를 보였습니다.
실무 선택 기준은 단순합니다. latency가 아주 중요하고 문서 길이가 짧다면 32M 또는 68M부터 시작합니다. 품질이 더 중요하고 GPU 여유가 있으면 150M 또는 400M을 봅니다. 1B는 가장 좋은 품질 후보지만, 대부분의 서비스에서는 비용 대비 개선폭을 따져야 합니다. 중요한 것은 “가장 큰 모델”이 아니라 “현재 retriever의 실패를 충분히 고치는 최소 모델”입니다.
또 하나의 포인트는 Flash Attention 2와 bfloat16 설정입니다. 글에서는 model_kwargs에 dtype bfloat16, attn_implementation flash_attention_2를 넣으면 모델 크기와 sequence length에 따라 1.7배에서 8.3배까지 속도 개선을 기대할 수 있다고 설명합니다. 이 수치는 환경에 따라 달라지지만, reranker는 문서 K개를 반복 평가하므로 추론 최적화가 체감 비용에 바로 반영됩니다.
가장 흔한 RAG pipeline은 다음 순서입니다. 첫째, 문서를 chunk로 나눕니다. 둘째, embedding을 만들어 vector DB에 저장합니다. 셋째, 사용자 query가 들어오면 top 50100개 chunk를 가져옵니다. 넷째, reranker가 query와 각 chunk를 함께 평가합니다. 다섯째, 상위 510개만 LLM context에 넣습니다.
Python에서는 Sentence Transformers의 CrossEncoder API로 시작할 수 있습니다. 예를 들어 CrossEncoder("cross-encoder/ettin-reranker-68m-v1")를 로드하고, (query, document) 쌍 리스트를 predict 또는 rank에 넣으면 점수를 얻습니다. 여기서 중요한 것은 top-K 값을 무작정 크게 잡지 않는 것입니다. top 100을 rerank하면 품질은 좋아질 수 있지만 latency와 비용도 늘어납니다. 먼저 top 50, rerank 후 top 8 같은 설정으로 시작하고 평가 결과에 따라 조정하는 편이 좋습니다.
문서 길이도 관리해야 합니다. Ettin 계열이 8K token context를 지원한다고 해서 chunk를 8K로 만들면 RAG가 느려집니다. 대부분의 질의응답에서는 300~800 token chunk가 다루기 쉽습니다. 긴 문서가 필요하면 parent document retrieval 구조를 씁니다. 작은 chunk로 검색하고, rerank 후 선택된 chunk의 주변 문맥만 확장합니다.
Reranker를 붙였는데 답변 품질이 떨어지는 경우도 있습니다. 이유는 여러 가지입니다. 첫째, retriever top-K에 정답 문서가 아예 없으면 reranker가 할 수 있는 일이 없습니다. 둘째, chunk가 너무 작아 근거가 끊기면 reranker도 relevance를 잘못 판단합니다. 셋째, query rewriting이 잘못되어 원래 의도를 잃을 수 있습니다. 넷째, reranker 점수와 LLM prompt 구성 방식이 맞지 않을 수 있습니다.
따라서 적용 전 평가셋이 필요합니다. 최소 100개 이상의 실제 사용자 질문을 모으고, 각 질문마다 정답 근거 문서 또는 chunk를 표시합니다. 그런 다음 retriever-only의 recall@50, rerank 후 NDCG@10, 최종 답변의 groundedness를 측정합니다. “좋아 보인다”가 아니라 정답 근거가 상위 몇 개에 들어오는지를 봐야 합니다.
운영 로그도 같이 봐야 합니다. 사용자가 같은 질문을 반복하는지, 답변 후 검색을 다시 하는지, thumbs down이 특정 카테고리에 몰리는지 확인합니다. RAG 품질 문제는 모델 하나로 해결되는 게 아니라 chunking, embedding, reranking, prompt, citation UI가 함께 맞아야 해결됩니다.
첫 번째 팁은 rerank cache입니다. 같은 query가 반복되거나 query rewriting 결과가 같다면 reranker 점수를 캐시할 수 있습니다. 문서가 자주 바뀌지 않는 지식베이스에서는 효과가 큽니다. 단, 문서 업데이트 시 cache invalidation을 설계해야 합니다.
두 번째 팁은 two-tier reranking입니다. 32M 모델로 top 100을 빠르게 줄이고, 150M 모델로 top 20만 다시 보는 구조입니다. 모든 서비스에 필요한 것은 아니지만, 품질과 비용을 동시에 맞춰야 할 때 유용합니다.
세 번째 팁은 query type별 전략입니다. “가격 정책 알려줘”처럼 정답 문서가 명확한 질문은 작은 top-K로 충분합니다. “우리 상황에서 어떤 플랜이 맞아?”처럼 비교와 판단이 필요한 질문은 더 많은 문맥이 필요할 수 있습니다. query classifier를 앞에 두고 top-K와 reranker 크기를 다르게 설정하면 비용을 줄일 수 있습니다.
Ettin Reranker의 실용성은 “최고 성능 모델”이라는 주장보다 “작은 모델부터 큰 모델까지 선택지가 있고, 표준 CrossEncoder 형태로 붙일 수 있다”는 데 있습니다. RAG 품질을 올리고 싶다면 생성 모델 교체 전에 retrieval funnel부터 숫자로 확인하는 편이 훨씬 싸고 빠릅니다.
