AI Agent를 위한 OpenSearch 검색 품질 개선하기 (Part 2)

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, query, documents, top_n=10):
    """Cohere Rerank v3.5로 재정렬"""

    response = bedrock_client.invoke_model(
        modelId="cohere.rerank-v3-5:0",
        body=json.dumps({
            "api_version": 2,
            "query": query,
            "documents": [doc["text"][:500] for doc in documents],
            "top_n": top_n
        })
    )

    result = json.loads(response["body"].read())

    # 재정렬된 순서로 반환
    reranked = []
    for r in result["results"]:
        reranked.append({
            "document": documents[r["index"]],
            "relevance_score": r["relevance_score"]
        })

    return reranked

코드를 보면 문서를 500자로 잘라 넘기고 있습니다. Rerank 모델은 문서가 길수록 처리 비용과 지연시간이 늘어나기 때문에 실무에서는 문서 앞부분만 잘라 넘기는 경우가 많습니다. 다만 이렇게 자르면 뒷부분에 있는 핵심 문장을 놓칠 수 있어서 어디서 자를지는 문서 구조에 따라 판단이 필요합니다.

예상이 절반만 맞은 SciFact 결과

여기서는 1부의 네 데이터셋 중, 성격이 정반대라 대비가 뚜렷한 둘을 골라 살펴봅니다. 의미가 중요한 SciFact와, 정확한 키워드가 중요한 Touche-2020입니다.

먼저 1부에서 시멘틱 검색이 강했던 과학 논문 데이터셋 SciFact입니다. 쿼리 200개로 측정했습니다. (아래 하이브리드는 이 글에서 다루는 normalization 가중치 방식 기준이라, 1부의 RRF(Reciprocal Rank Fusion) 하이브리드 점수와는 조금 다릅니다.)

방식	NDCG@10	변화
BM25	0.560	–
BM25 + Rerank	0.666	+18.9%
Hybrid	0.712	–
Hybrid + Rerank	0.685	-3.8%

여기서 예상과 다른 부분이 발견됩니다. BM25 단독 검색에 Rerank를 얹었을 때는 +18.9%로 크게 개선됐습니다. BM25는 키워드만 보기 때문에 애초에 의미를 놓치는 경우가 많은데 Rerank가 그 뒤에서 의미 기반으로 순서를 바로잡아 주니 효과가 컸습니다.

그런데 같은 Rerank를 하이브리드에 붙이자 오히려 3.8% 떨어졌습니다. 하이브리드는 이미 BM25와 시멘틱을 섞어 0.712라는 좋은 순서를 만들어놨는데 Rerank가 그 순서를 다시 바꾼 것이 원인입니다. 이처럼 같은 데이터셋 안에서도 무엇에 붙이느냐에 따라 결과가 갈립니다.

양쪽 모두 나빠진 Touche-2020 결과

논쟁적 주제를 다루는 Touche-2020(쿼리 49개)에서는 더 분명했습니다.

방식	NDCG@10	변화
BM25	0.778	–
BM25 + Rerank	0.737	-5.3%
Hybrid	0.804	–
Hybrid + Rerank	0.732	-8.9%

여기서는 BM25에 붙였을 때조차 마이너스입니다. SciFact에서 +18.9%를 만들어준 그 Rerank가, 같은 코드와 같은 모델인데 결과가 뒤집혔습니다. 처음 이 숫자를 봤을 때는 코드가 잘못됐나 싶어 몇 번을 다시 돌려봤지만 결과는 그대로였습니다.

네 가지 조합을 나란히 놓고 보면 규칙이 보입니다(그림 2).

왜 이런 결과가 나왔을까

네 조합을 정리하면 규칙이 하나 보입니다.

조합	baseline NDCG@10	Rerank 효과
SciFact / BM25	0.560 (가장 낮음)	+18.9%
SciFact / Hybrid	0.712	-3.8%
Touche / BM25	0.778	-5.3%
Touche / Hybrid	0.804 (가장 높음)	-8.9%

기존 검색 품질이 낮을수록 Rerank가 도움이 되고 높을수록 오히려 해가 됩니다.

이유는 Rerank 모델의 성격에 있습니다. Cohere Rerank는 의미적 유사성을 기준으로 순서를 다시 매깁니다. BM25 단독처럼 애초에 의미를 못 보는 검색에서는, Rerank의 개선폭이 큽니다. 반면 이미 시멘틱을 섞어 좋은 순서를 만들어둔 하이브리드에서는, Rerank가 더 보탤 정보가 없는데도 순서를 바꾸기 때문에 성능을 손해봅니다.

Touche-2020이 특히 불리한 건 데이터 성격 때문입니다. 1부에서 봤듯 이 데이터는 “tenure”, “vaping” 같은 정확한 용어의 일치 여부가 순위를 좌우합니다. 이런 데이터셋에서 의미 유사성으로 순서를 다시 매기면 키워드로 잘 잡아둔 순서가 오히려 흐트러집니다. 그래서 BM25 단독에서도 마이너스가 나왔습니다.

여기서 얻은 교훈은 분명합니다. Rerank는 강력한 도구이지만 만능이 아닙니다. 이미 잘 튜닝된 검색에 얹으면 오히려 성능이 떨어질 수 있습니다. 어느 쪽인지 미리 알 방법은 자기 데이터에서 직접 재보는 것뿐입니다. 1부에서 만든 평가 시스템이 바로 그 측정을 담당합니다.

하이브리드 가중치 자동 튜닝

두 번째 기법은 하이브리드 검색의 가중치 조정입니다. 1부에서는 순위만으로 결합하는 RRF 방식을 썼지만 OpenSearch는 두 검색 점수를 정규화한 뒤 가중치를 곱해 섞는(normalization) 방식도 제공합니다. 이 방식은 BM25와 k-NN의 비율(기본값은 대개 0.5:0.5)을 데이터에 맞게 바꿀 수 있어 비율만 잘 고르면 성능이 오를 여지가 생깁니다. Rerank와 달리 추가 API 호출이 없어 비용이 들지 않는다는 점도 매력적입니다.

Grid Search로 최적 가중치 찾기

문제는 “그럼 몇 대 몇이 최적이냐”입니다. 이건 정답을 미리 알 수 없어서 여러 비율을 실제로 다 돌려보고 가장 좋은 값을 고르는 Grid Search 방식을 씁니다. 먼저 넓은 간격으로 훑어 대략의 위치를 잡고 그다음 그 근처를 0.05 간격으로 촘촘히 다시 훑는 2단계 방식이 효율적입니다. 실제 탐색 결과는 그림 3과 같습니다.

튜닝 결과

설정	BM25 : k-NN	NDCG@10	기본 대비
기본값	0.50 : 0.50	0.8039	기준 (최고값)
두 번째	0.65 : 0.35	0.8009	-0.4%
세 번째	0.55 : 0.45	0.8002	-0.5%

12개 비율을 모두 시도했지만 기본값 0.5:0.5보다 높은 값은 없었습니다. 어느 한쪽 비중을 높여도 점수가 떨어졌습니다. 튜닝으로 얻은 것은 “튜닝할 게 없다”는 확인뿐입니다.

그래도 이건 실패가 아닙니다. “이 데이터에서는 가중치를 건드릴 필요가 없다”는 사실을 확인한 것 자체가 결과입니다. 측정하지 않았다면 며칠을 가중치 조정에 썼을 수도 있습니다.

이유는 단순합니다. Touche-2020은 이미 하이브리드 기본 설정에서 0.80이라는 높은 성능을 내고 있었습니다. BM25(0.778)와 k-NN(0.757)의 성능이 비슷해서 반반씩 섞는 것이 자연스럽게 최적점이 된 것입니다. 이미 잘 맞춰진 설정을 미세 조정해봐야 얻을 것이 별로 없습니다.

한 가지 덧붙이면, 작은 차이를 봤을 때는 그게 진짜 개선인지 따져보는 습관이 필요합니다. 이 실험의 쿼리는 49개뿐입니다. NDCG@10은 쿼리별 점수의 평균이라, 표본이 이렇게 작으면 쿼리 한두 개가 우연히 흔들리는 것만으로 평균이 0.003 정도는 쉽게 움직입니다. 실제로 기본값과 0.65:0.35를 쿼리별로 짝지어 대응표본 t-검정을 돌려보니 p-value 0.64로, 두 설정은 통계적으로 구분되지 않았습니다(49개 중 13개는 상위 10개 결과가 완전히 동일했고 나머지도 개선 17개와 악화 19개로 뒤섞여 있었습니다). 만약 grid search가 우연히 0.65를 최고값으로 뽑았고 그걸 믿고 운영 설정을 바꿨다면, 아무것도 개선하지 못하면서 설정만 건드린 꼴이 됐을 겁니다. 몇 %의 차이가 노이즈인지 실체인지는 통계로 가려내야 합니다.

이 결과가 오히려 중요한 정보를 알려줍니다. 가중치 튜닝은 언제 효과적인가를 판단하는 것입니다.

상황	튜닝 효과
BM25와 k-NN의 성능 차이가 클 때	크다 (우세한 쪽에 비중을 더 주면 됨)
두 검색의 성능이 비슷할 때	없다 (Touche-2020이 이 경우)
데이터 특성이 뚜렷할 때 (키워드형 vs 의미형)	크다

즉 튜닝은 비용이 안 드는 방법이지만 항상 성능 개선이 있지는 않습니다. 성능 차이가 큰 두 검색을 섞을 때 장점이 크고 이미 균형이 잘 잡힌 경우엔 필요 없을 수도 있습니다. 그리고 어느 경우인지는 테스트 해보기 전까지 알 수 없습니다.

AI 코딩 어시스턴트로 자동화하기

지금까지의 과정을 돌아보면 패턴이 보입니다. 현재 성능 측정 → 기법 적용 → 다시 측정 → 비교 후 결정. 이 루프를 사람이 손으로 돌리면 지루하고 실수도 잦습니다. 그런데 이건 AI 코딩 어시스턴트가 잘하는 일입니다.

각 단계에서 실제로 하는 일은 다음과 같습니다(그림 4).

현재 성능 측정: 기법을 붙이기 전의 기준점(baseline)을 만드는 단계입니다. 평가용 쿼리셋으로 run_evaluation()을 돌려 NDCG@10을 기록해 둡니다. 이 값이 없으면 뒤의 비교가 아예 성립하지 않습니다.
개선 기법 적용: Rerank를 얹거나 하이브리드 가중치를 바꿔 보는 단계입니다. 한 번에 한 가지만 바꾸는 것이 중요합니다. 둘을 동시에 건드리면 어느 쪽이 효과를 냈는지 가려낼 수 없습니다.
개선 후 재측정: 같은 쿼리셋과 같은 지표로 다시 재는 단계입니다. 쿼리셋이나 채점 조건이 달라지면 1단계의 baseline과 비교할 수 없으니 측정 조건을 그대로 유지합니다.
비교 후 결정: 두 수치를 견줘 적용 여부를 정하는 단계입니다. 개선 폭이 미리 정한 임계값을 넘으면 반영하고 나빠졌으면 되돌립니다. Touche-2020처럼 원래 설정이 이미 최적이라면 “바꾸지 않는다”도 정상적인 결론입니다.

자동화 코드 예시

이 루프를 함수 하나로 정리하면 다음과 같습니다. AI 어시스턴트에게 “이런 함수를 만들어줘”라고 지시하면 아래와 비슷한 코드를 만들어내고 실행 결과까지 해석해 줍니다.

def auto_optimize_search(index_name, test_queries, qrels):
    """AI 에이전트가 호출하는 자동 최적화 함수"""

    results = {}

    # 1. Baseline 측정
    baseline_score = evaluate_hybrid(
        index_name, test_queries, qrels,
        bm25_weight=0.5, use_rerank=False
    )
    results["baseline"] = baseline_score
    print(f"Baseline NDCG@10: {baseline_score:.4f}")

    # 2. Rerank 테스트
    rerank_score = evaluate_hybrid(
        index_name, test_queries, qrels,
        bm25_weight=0.5, use_rerank=True
    )
    results["with_rerank"] = rerank_score

    rerank_improvement = (rerank_score - baseline_score) / baseline_score * 100
    print(f"With Rerank: {rerank_score:.4f} ({rerank_improvement:+.1f}%)")

    # 3. Weight Grid Search
    best_weight = 0.5
    best_score = baseline_score

    for bm25_w in [0.3, 0.4, 0.5, 0.6, 0.7]:
        score = evaluate_hybrid(
            index_name, test_queries, qrels,
            bm25_weight=bm25_w, use_rerank=False
        )
        if score > best_score:
            best_score = score
            best_weight = bm25_w

    results["tuned_weight"] = best_weight
    results["tuned_score"] = best_score

    # 4. 최종 결정
    recommendations = []

    if rerank_score > baseline_score * 1.05:  # 5% 이상 개선
        recommendations.append(f"Rerank 적용 권장 (+{rerank_improvement:.1f}%)")
    elif rerank_score < baseline_score * 0.95:  # 5% 이상 악화
        recommendations.append(f"Rerank 비권장 ({rerank_improvement:.1f}%)")

    if best_weight != 0.5:
        weight_improvement = (best_score - baseline_score) / baseline_score * 100
        recommendations.append(
            f"Weight 조정 권장: {best_weight:.1f}:{1-best_weight:.1f} (+{weight_improvement:.1f}%)"
        )

    return {
        "results": results,
        "recommendations": recommendations
    }

코드에서 눈여겨볼 부분은 마지막 결정 로직입니다. 5% 이상 개선되면 적용을 권하고 5% 이상 나빠지면 명시적으로 “비권장”을 반환합니다. 앞서 Touche-2020에서 Rerank가 -8.9%였던 상황이 정확히 이 “비권장” 조건에 걸립니다. 즉 이 임계값이 있어야 앞선 Rerank 역효과 같은 함정을 자동으로 걸러낼 수 있습니다. 임계값을 몇 %로 둘지는 서비스의 민감도에 따라 조정할 부분입니다.

테스트에서 사용한 대화 방식

AI 코딩 에이전트에 대해 익숙하지 않으신 분들을 위해서 실제 작업 대화를 그대로 옮겨봅니다.

나: Touche-2020에서 최적의 검색 설정을 찾아줘. Rerank랑 Weight 튜닝 둘 다 테스트해봐.

AI:
테스트 진행하겠습니다.

--- Baseline ---
Hybrid (0.5:0.5): NDCG@10 = 0.8039

--- Rerank 테스트 ---
Hybrid + Rerank: NDCG@10 = 0.7321 (-8.9%)
BM25   + Rerank: NDCG@10 = 0.7369 (-5.3%)
→ 두 경우 모두 Rerank가 성능을 악화시킵니다.

--- Weight Grid Search (12개 비율) ---
0.35:0.65 → 0.7916
0.45:0.55 → 0.7977
0.50:0.50 → 0.8039 (최고)
0.55:0.45 → 0.8002
0.65:0.35 → 0.8009

결론:
- Rerank: 적용하지 마세요 (-5~9%)
- Weight: 기본값 0.5:0.5가 이미 최적입니다. 어느 쪽으로 기울여도 떨어집니다.
- 이 데이터셋은 현재 설정을 그대로 유지하는 것을 권장합니다

이렇게 자연어로 지시하면 테스트부터 결론까지 한 번에 얻습니다. 다만 여기서 강조하고 싶은 건, AI가 이 결론을 낼 수 있는 이유가 뒤에 신뢰할 만한 평가 시스템이 있기 때문이라는 점입니다. 측정이 부정확하면 AI는 잘못된 결론을 자신 있게 내놓습니다. 자동화의 품질은 결국 평가의 품질에 달려 있습니다.

한 걸음 더 나아가 Agent가 스스로 검색을 고치게 하기

지금까지의 Rerank/가중치 튜닝은 검색 파이프라인 자체를 개선하는 방법이었습니다. 그런데 Agent라면 한 가지 선택지가 더 있습니다. 검색 결과를 Agent가 스스로 점검하고 부족하면 다시 검색하게 만드는 것입니다. 사람이 검색했는데 결과가 별로면, 검색어를 바꿔 다시 찾는 것과 같은 행동을 Agent에게 시키는 셈입니다.

이 접근은 Self-RAG(Self-Reflective Retrieval-Augmented Generation)라는 이름으로 알려져 있습니다. 핵심 아이디어는 검색과 생성 사이에 “이 문서들이 정말 쓸 만한가?”를 판정하는 단계를 하나 끼워 넣는 것입니다. 흐름은 이렇습니다.

검색: 하이브리드 검색으로 후보 문서를 넉넉히(예: 상위 10개) 가져옵니다.
관련성 판정: LLM이 각 문서가 질문에 실제로 관련 있는지 관련/무관으로 채점합니다. 무관한 문서는 컨텍스트에서 버립니다.
충분성 판정: 남은 문서만으로 답변하기에 정보가 충분한지 확인합니다.
부족하면 재검색: 충분하지 않으면, 이미 본 문서는 제외하고 쿼리를 바꿔 다시 검색합니다. (무한 반복을 막기 위해 보통 2회 정도로 제한합니다.)
충분하면 생성: 확보된 문서를 근거로 최종 답변을 만듭니다.

이 판정에 쓰는 LLM은 최종 답변을 만드는 LLM과 분리하는 것이 좋습니다. 답변용 모델보다 가볍고 빠른 모델(예: Claude Haiku 계열)을 채점기로 두면 비용과 지연 부담이 적고 답변 모델이 “자기가 고른 문서를 자기가 평가하는” 편향도 피할 수 있습니다. 1부에서 만든 LLM Judge와 같은 발상입니다. 다만 여기서는 평가가 아니라 실시간 파이프라인의 일부로 들어간다는 점이 다릅니다.

OpenSearch 검색 위에 이 필터를 얹는 구조는 대략 이렇게 표현할 수 있습니다.

def agentic_search(query, max_retries=2):
    """검색 → 관련성 필터 → 부족하면 재검색하는 Agentic 루프"""
    seen_ids = set()

    for attempt in range(max_retries + 1):
        # 1. 하이브리드 검색 (이미 본 문서는 제외)
        candidates = hybrid_search(query, k=10, exclude=seen_ids)
        seen_ids.update(doc["_id"] for doc in candidates)

        # 2. 관련성 판정: 무관 문서 제거 (가벼운 Judge 모델)
        relevant = [doc for doc in candidates if judge_relevant(query, doc)]

        # 3. 충분성 판정: 이 문서들로 답할 수 있는가?
        verdict = judge_sufficiency(query, relevant)
        if verdict.is_sufficient or attempt == max_retries:
            return relevant

        # 4. 부족하면 판정이 준 힌트로 쿼리를 재작성해 다시 검색
        query = verdict.suggested_query

    return relevant

이 방식이 매력적인 이유는, 검색 엔진을 바꾸지 않고도 Agent의 답변 품질을 끌어올릴 수 있다는 점입니다. 무관한 문서를 걸러내면 LLM이 노이즈에 휘둘리지 않아 환각이 줄고 재검색 덕분에 한 번에 못 찾은 정답을 다음 시도에서 잡을 수 있습니다. 1부에서 본 Recall 문제(“정답이 상위 k개 밖에 있으면 Agent가 놓친다”)를 재검색으로 일부 만회하는 셈입니다.

다만 공짜는 아닙니다. 판정과 재검색마다 LLM 호출과 검색이 추가되므로 지연시간과 비용이 늘어납니다. 그리고 관련성 필터가 지나치게 엄격하면 정답 문서까지 버려서 오히려 Recall을 떨어뜨릴 수 있습니다. 그래서 이 기법도 앞선 Rerank/가중치 튜닝과 똑같은 원칙이 적용됩니다. 붙이기 전에, 그리고 붙인 뒤에 반드시 측정해서 정말 좋아졌는지 확인해야 합니다. 1부에서 만든 평가 시스템이 여기서도 그대로 판단 기준이 됩니다.

이 글에서는 Self-RAG를 개념과 설계 수준으로만 소개했습니다. 실제로 OpenSearch와 Bedrock 위에 이 루프를 구현하고 데이터셋별로 효과를 측정하는 것은 그 자체로 하나의 실험 주제라, 기회가 되면 따로 다뤄보려 합니다.

운영 환경에서의 지속적 평가

지금까지는 한 번 실험하고 끝나는 일회성 테스트였습니다. 하지만 실제 운영 환경은 다릅니다. 문서가 계속 추가되고 사용자의 검색 패턴도 시간이 지나며 바뀝니다. 어제까지 잘 나오던 검색이 오늘 새 데이터가 들어오면서 나빠질 수도 있습니다. 그래서 검색 품질도 한 번 재고 끝낼 게 아니라 지속적으로 지켜봐야 합니다.

평가 루프 자동화

핵심은 정기적으로 자동 측정하고 기준 아래로 떨어지면 알림을 받는 구조를 만드는 것입니다. 전체 흐름은 그림 5와 같습니다. Amazon EventBridge가 주기적으로 AWS Lambda 함수를 호출하면 Lambda가 Amazon OpenSearch Service에 대표 쿼리셋을 질의해 NDCG@10을 계산하고 그 값을 Amazon CloudWatch 지표로 기록합니다. 지표가 임계값 아래로 떨어지면 Amazon Simple Notification Service(Amazon SNS)로 알림을 보냅니다.

AWS Lambda 기반 주기적 평가

이 흐름은 AWS Lambda 함수 하나로 구현할 수 있습니다.

# lambda_function.py
import json
import boto3
from evaluation import evaluate_search_quality

cloudwatch = boto3.client('cloudwatch')
sns = boto3.client('sns')

def lambda_handler(event, context):
    """주간 검색 품질 평가"""

    # 샘플 쿼리셋으로 평가
    results = evaluate_search_quality(
        index_name="production-index",
        sample_queries=load_sample_queries(),  # 대표 쿼리 100개
        use_llm_judge=True  # Gold qrels 없으면 LLM Judge 사용
    )

    # CloudWatch 지표 전송
    cloudwatch.put_metric_data(
        Namespace='SearchQuality',
        MetricData=[
            {'MetricName': 'NDCG@10', 'Value': results['ndcg'], 'Unit': 'None'},
            {'MetricName': 'Precision@10', 'Value': results['precision'], 'Unit': 'None'}
        ]
    )

    # 성능 저하 시 알림
    if results['ndcg'] < 0.6:  # 임계값
        sns.publish(
            TopicArn='arn:aws:sns:ap-northeast-2:123456789012:search-quality-alert',
            Message=f"검색 품질 저하 감지: NDCG@10 = {results['ndcg']:.4f}"
        )

    return {'statusCode': 200, 'body': json.dumps(results)}

여기서 중요한 대목은 use_llm_judge=True입니다. 운영 데이터에는 대개 사람이 만든 정답 레이블(Gold qrels)이 없습니다. 이때 1부에서 검증한 LLM Judge가 정답의 빈자리를 메웁니다. 1부에서 채점기를 미리 검증해둔 덕분에, 운영 환경에서도 사람 손 없이 품질을 계속 잴 수 있는 것입니다. 두 글이 이렇게 이어집니다.

새 데이터 배포 시 자동 검증

정기 평가와 더불어, 새 데이터를 색인할 때마다 품질을 검사해 기준 미달이면 배포 자체를 막는 방법도 유용합니다. 색인 파이프라인의 마지막 단계에 평가를 넣고 NDCG가 기준선 아래면 배포를 중단시키는 방식입니다.

# buildspec.yml (AWS CodeBuild)
version: 0.2

phases:
  build:
    commands:
      - echo "새 데이터 색인..."
      - python scripts/index_new_data.py

  post_build:
    commands:
      - echo "검색 품질 평가..."
      - python scripts/evaluate_search.py --output results.json
      # 품질 게이트
      - |
        NDCG=$(jq '.ndcg' results.json)
        BASELINE=0.65
        if (( $(echo "$NDCG < $BASELINE" | bc -l) )); then
          echo "품질 저하 감지: $NDCG < $BASELINE"
          exit 1  # 배포 중단
        fi
      - echo "품질 검증 통과. 배포 진행."

이렇게 해두면 새 문서를 넣었을 때 검색이 조용히 나빠지는 상황을 배포 단계에서 잡아낼 수 있습니다. 검색 품질을 단위 테스트처럼 다루는 셈입니다.

대시보드로 추세 보기

측정값을 시계열로 쌓으면 대시보드에서 추세를 볼 수 있습니다. 숫자 하나하나보다 추세와 이상 징후를 보는 게 운영에서는 훨씬 중요합니다. 아래는 이런 모니터링 대시보드를 직접 구성한 예시입니다. 상단에는 핵심 지표 네 개를, 가운데에는 주차별 NDCG 추세와 검색 방식별 비교를, 아래에는 주간 품질 리포트를 배치했습니다.

그림 6의 W23 주차를 보면 NDCG가 임계값인 0.65 아래로 잠깐 떨어졌다가 회복한 것을 확인할 수 있습니다. 이런 순간을 사람이 눈으로 지켜보고 있을 수는 없습니다. 그래서 이 지점에서 자동으로 알림이 나가도록 해두면, 검색 품질이 조용히 나빠지는 상황을 놓치지 않고 잡아낼 수 있습니다.

정리하며, 평가 없는 개선은 없다

테스트 결과 요약

대표적인 두 데이터셋(SciFact 200쿼리, Touche-2020 49쿼리)에 두 기법을 적용한 결과를 한눈에 정리하면 이렇습니다. Rerank가 이득을 준 건 네 조합 중 하나뿐이라는 게 이 표의 핵심입니다.

데이터셋	검색 방식	기본	+ Rerank	판단
SciFact	BM25	0.560	0.666 (+18.9%)	Rerank 적용
SciFact	Hybrid	0.712	0.685 (-3.8%)	기본 유지
Touche-2020	BM25	0.778	0.737 (-5.3%)	기본 유지
Touche-2020	Hybrid	0.804	0.732 (-8.9%)	기본 유지

가중치 튜닝은 Touche-2020에서 12개 비율을 훑었지만 기본값(0.5:0.5, NDCG 0.8039)이 최적이었습니다.

핵심 교훈

Rerank는 품질이 낮은 검색은 끌어올리지만 이미 품질이 높은 검색에서는 역효과를 냅니다. SciFact의 BM25(0.560)에 붙였을 때는 +18.9%였지만 같은 데이터의 하이브리드(0.712)에 붙이니 -3.8%였습니다. 기존 검색 품질이 높을수록 Rerank가 보탤 정보가 없어 순서만 흔들리고 점수는 내려갑니다. 적용 전 측정은 선택이 아니라 필수입니다.
Weight 튜닝은 안전하지만 이득이 없을 수도 있습니다. 추가 비용이 없어 부담 없이 시도할 수 있지만 두 검색의 성능이 비슷하면 기본값이 이미 최적입니다. 성능 차이가 큰 검색을 섞을 때 효과가 큽니다.
평가 시스템이 먼저입니다. 이 글의 모든 결정(Rerank를 쓸지, 가중치를 얼마로 할지, 배포를 막을지)은 결국 “믿을 수 있는 측정값”이 있어야 내릴 수 있습니다. 1부에서 평가 시스템에 공들인 이유가 바로 그것입니다.

지금 바로 시작해 보기

아직 1부를 보지 않으셨다면, 먼저 AI Agent를 위한 OpenSearch 검색 품질 평가하기 (Part 1)에서 측정 방법을 확인하시길 권합니다.
Rerank 모델을 직접 써보려면 Amazon Bedrock의 Cohere Rerank 문서를 참고하세요.
하이브리드 가중치 튜닝은 OpenSearch 하이브리드 검색 문서에서 설정 방법을 확인할 수 있습니다.

무엇보다, 지금 운영 중인 검색이나 AI Agent가 있다면 대표 쿼리 몇 개라도 골라 NDCG를 재보는 것부터 시작해 보시길 권합니다. 측정을 시작하는 순간, 성능 개선은 감이 아니라 눈에 보이는 숫자의 문제가 됩니다.

AWS 기술 블로그