RAG 품질 ② 개선 — 임베딩·하이브리드·Rerank·Self-RAG 단계별 누적 개선 실험

📚 시리즈 — RAG 품질

• ① 평가 — MLflow Evaluation 기반 검색·생성 품질 정량 측정
• ② 개선 — 임베딩·하이브리드·Rerank·Self-RAG 단계별 누적 개선 실험 — 현재 글
• ③ 아키텍처 — LangGraph 기반 Agentic RAG 검색 처리 흐름

 

⚠️ 예시 안내 — 본 문서의 케이스별 수치·데이터셋은 실제 프로젝트 데이터를 공개 가능한 형태로 재구성한 예시값입니다. 실제 적용 시에는 먼저 도메인에 맞는 골드셋(평가 데이터셋)을 확보하고 품질을 측정한 뒤, 아래 실험 설계·누적 개선 절차를 틀로 활용하세요.

 

1. 실험 개요

Case-by-Case 측정 및 누적 개선 기록

목적: 동일한 평가 데이터셋 위에서 청킹 → 임베딩 → Retrieval → Reranking → Self-RAG 필터 → LLM 파이프라인을 누적형(Cumulative)으로 한 번에 변수 하나씩 교체하며, 각 변경이 RAG 품질에 주는 영향을 MLflow Evaluation으로 정량 측정하고 본 문서에 케이스별로 누적 기록합니다.

측정 방법론·Scorer 정의는 본 시리즈 ① 평가 편을 따르며, 본 문서는 실험 설계와 케이스별 결과 기록에 집중합니다.

 

1.1 실험 설계 원칙 — 누적형(Cumulative)

각 케이스는 직전 케이스까지의 최고 성능 구성을 그대로 이어받고, 변수 하나만 변경합니다. 한 번에 하나씩만 바꾸므로, 성능 변화의 원인을 변경 변수로 귀속시킬 수 있습니다.

 

1.2 변경 변수와 영향 지표 매트릭스

변경 변수가 어느 지표에 영향을 주는지 미리 선언해 두면, 측정 결과를 해석할 때 기대와 다른 변화가 생긴 지점을 빠르게 포착할 수 있습니다. 본 표는 측정 전 사전 기대이며, 실제 결과는 §2.3 매트릭스·§7~§8을 정본으로 합니다 — 일부는 기대와 다릅니다 (대표 사례: C8에서 RetrievalGroundedness는 기대(↑)와 달리 하락 → §7.8 해석).

변경 변수 구간	영향을 받는 지표 (기대)	고정(변동 없어야 할) 지표
Case 2~7 (검색 스택 변경)	RetrievalRelevance, RetrievalSufficiency, RetrievalGroundedness, Correctness, Completeness	Safety, RelevanceToQuery (대부분 불변)
Case 6 (동의어 사전)	RetrievalRelevance↑, RetrievalSufficiency↑(특히 약칭·도메인 용어 쿼리), Correctness	Safety. 사전 품질이 낮으면 RetrievalRelevance ↓ 위험 (합격 조건)
Case 8 (Self-RAG 필터)	RetrievalRelevance↑, RetrievalGroundedness↑, Correctness↑, Completeness	Safety. RetrievalSufficiency는 보통 유지되지만, 필터가 공격적이면 ↓ 위험 (합격 조건)
Case 9 (LLM 교체, 보류·미측정)	RetrievalGroundedness, Correctness, Completeness, RelevanceToQuery, Safety	RetrievalRelevance, RetrievalSufficiency (검색·필터 결과 동일)

Case 6 해석 가이드: 동의어 사전은 표면 키워드가 다르지만 의미가 같은 용어(약칭·도메인 용어·표기 흔들림)를 BM25가 잡도록 보강합니다. 사전 품질이 핵심 — 부정확한 동의어가 들어가면 RetrievalRelevance가 하락할 수 있으므로 도메인 전문가 검수와 사전 동결(평가 데이터셋 보고 튜닝 금지)이 합격 조건입니다.

Case 8 해석 가이드: 필터는 무관 문서를 제거해 정밀도(Relevance)를 끌어올리지만, 잘못 거르면 정답 문서를 버려 재현율(Sufficiency)이 떨어집니다. Sufficiency가 직전 베이스(Case 5 — Rerank 미채택) 대비 ≥ 유지되는지가 합격 조건입니다. 또한 옵션 A(가변 K)를 채택했으므로 LLM 전달 K가 0~5로 가변(단 RELEVANT 0건 시 상위 보충) — 다른 케이스와의 절대값 비교가 아닌 Δ 해석만 유효합니다.

Case 9 해석 가이드: 생성 LLM은 검색·필터 결과를 바꾸지 않으므로, Case 9에서 RetrievalRelevance / RetrievalSufficiency가 변동한다면 평가 데이터셋·Retrieval·필터 스택 쪽에 의도치 않은 변화가 섞인 것입니다.

---

 

2. 실험 결과 요약

📊 측정 완료 C6(동의어 사전)·C9(LLM 교체)는 보류로 미측정입니다. 본 시리즈의 누적 개선 경로를 한눈에 파악하기 위한 단일 결과 매트릭스이며, 자세한 케이스 간 비교·해석은 §8. 케이스 간 성능 비교를 참조하세요.

 

2.1 최종 Production 구성 (실험 결론)

본 시리즈 누적 실험(§2.2 추이·§2.3 매트릭스·§7~§8 케이스 상세)의 결론으로 실제 운영(Production)에 적용한 구성입니다. 채택 상태: ✅ 채택 · ❌ 미채택 · ⏸ 검증 보류 · ⚙️ 고정값.

파이프라인 구성

단계	구성 요소	채택	한 줄 근거 (상세)
임베딩	Qwen3 Embedding 0.6B	✅	32k 긴 컨텍스트 안정 — Cohere V3/V4 미채택 (§7.2)
검색	Self-managed Hybrid (Kiwi BM25 + Semantic)	✅	중복 색인 제거 + 키워드 컬럼 분리 (§7.3·§7.4)
융합	Min-Max (semantic_weight 0.5)	✅	필터 결합 시 RRF보다 안정 (§7.5)
Top-K	retriever별 10 → 최종 5	⚙️	FTS·Semantic 각 10건 → 융합 → 필터 → 최대 5건
동의어 사전	검색 시 자체 구축 사전	⏸	구축·구현 완료, 평가 데이터 부족으로 검증만 보류 (§7.6)
Reranking	Cohere Rerank 3.5	❌	필터와 간섭해 지표 하락 (§7.7)
증강	Self-RAG 필터 (관련성 판정)	✅	Correctness +8%p, Sufficiency 유지 (§7.8)
증강	적응 재검색 (LangGraph ReAct)	✅	INSUFFICIENT 시 중복 제외+힌트로 최대 2회 재검색
생성	Gemini 3 Flash	✅	LLM 교체 영향 낮아 유지, 속도·비용 우위 (§7.9)
청킹	문단 기반 JSON 청크	⚙️	시리즈 내 고정 변수

모델 엔드포인트 (소스 config.yaml)

역할	엔드포인트	소스 키
생성 LLM	databricks-gemini-3-flash	llm_endpoint
생성 fallback	databricks-claude-sonnet-4-6	fallback_llm_endpoint
임베딩	databricks-qwen3-embedding-0-6b	embedding_endpoint
Self-RAG 필터 LLM	databricks-gpt-5-4-nano	judge_model_endpoint
평가 Judge LLM	databricks-gpt-5-2	(MLflow 평가측, 소스 외부)

생성 파라미터: temperature 0.1 · top_p 0.5 · reasoning_effort high. 필터 LLM은 검색 라운드당 1회 단일 호출(문서당 최대 40k자), 생성·Judge LLM과 분리.

최종 품질: 자동 Scorer Correctness 77%(C8), 현업 정성평가 Correctness 80%(C10, 보수적 통과 기준 — 목표 충족). 운영 투입 가능 수준으로 확정했으며, 추가 제고는 §9.3 후속 실험 로드맵으로 진행합니다.

 

2.2 추이 그래프 (Case 1 → 10)

🎯 Correctness 단독 추이 — 본 시리즈의 ★ 핵심 지표. 목표선(≥ 80%) 대비 현재 위치와 케이스별 누적 개선폭을 한눈에 확인할 수 있습니다. 자동 Scorer 최고점은 C8(77%)이며, 현업 정성평가(C10, 보수적 '통과' 기준)에서 목표선 80%에 도달했습니다.

📈 측정값 갱신 시 rag-agent-improvement-cases/generate_trend_chart.py의 DATA 딕셔너리를 수정하고 재실행하면 차트가 갱신됩니다.

💡 임베딩으로 Qwen3를 선택한 이유: Case 2에서 Cohere Embed V3는 Qwen3와 지표가 대등했고, V3의 짧은 입력 길이 한도로 긴 문단 청크가 절단될 위험이 있었습니다. 대안 V4는 한국어 성능이 더 낮고 Databricks 미지원이라, 긴 컨텍스트(32k)를 안정적으로 지원하는 Qwen3를 유지했습니다. (상세 §7.2)

7개 Scorer 간단 요약 — RAG 3단계(검색·증강·생성)에 매핑됩니다. 자세한 정의·Judge LLM·Pass 기준·예시는 본 시리즈 ① 평가 편을 참조하세요. - 검색 (Retrieval) - RetrievalRelevance — 검색된 각 문서가 질문과 관련 있는지 (문서별 정밀도) - RetrievalSufficiency — 검색 문서 전체가 정답을 구성하기에 충분한지 (재현율 관점, expected_facts 필요) - 증강 (Augmentation) - RetrievalGroundedness — 답변이 검색 문서에 근거하는지 (환각 방지) - 생성 (Generation) - Correctness ★ — expected_facts를 빠짐없이 포함하는지 (정답 일치, Ground Truth 필요) - Completeness — 질문에 포함된 모든 항목에 답했는지 (복합 질문 대응) - RelevanceToQuery — 답변이 질문에 직접 응답하는지 - Safety — 유해·부적절 응답이 없는지

 

2.3 매트릭스 표 (Case 1 → 10)

단계	Scorer	C1	C2	C3	C4	C5	C6	C7	C8	C9	C10	Δ(C8−C1)
검색	RetrievalRelevance	47.0%	46.0%	48.0%	58.0%	60.0%	(미측정)	63.0%	65.0%	(미측정)	—	+18.0%p
검색	RetrievalSufficiency	59.0%	58.0%	59.0%	72.0%	73.0%	(미측정)	75.0%	73.0%	(미측정)	—	+14.0%p
증강	RetrievalGroundedness	69.0%	68.0%	63.0%	68.0%	60.0%	(미측정)	62.0%	56.0%	(미측정)	—	−13.0%p
생성	Correctness	62.0%	61.0%	68.0%	70.0%	69.0%	(미측정)	71.0%	77.0%	(미측정)	80.0%	+15.0%p
생성	Completeness	79.0%	78.0%	79.0%	86.0%	83.0%	(미측정)	84.0%	81.0%	(미측정)	—	+2.0%p
생성	RelevanceToQuery	98.0%	98.0%	99.0%	98.0%	99.0%	(미측정)	99.0%	100.0%	(미측정)	—	+2.0%p
생성	Safety	99.0%	99.0%	99.0%	98.0%	99.0%	(미측정)	99.0%	99.0%	(미측정)	—	0.0%p

⚠️ C8·C10 컬럼 해석 주의: - C8 (Self-RAG 필터)부터 LLM 전달 K가 0~5로 가변(옵션 A)이므로 C1~C7의 K=5 컬럼과는 컨텍스트 조건이 다릅니다. 누적 추이는 Δ(전 Case 대비) 관점에서 해석하고, 절대값은 §7.x 각 Case 표의 "vs 직전 Case" 컬럼을 우선 참조하세요. Δ(C8−C1)은 자동 Scorer 기준 누적 개선폭입니다. - C10 (Human-in-the-loop) 은 자동 Scorer가 아닌 현업 3인 정성평가 결과로, Correctness 한 지표만 보수적 '통과' 기준으로 산출됩니다. 자동 Scorer 값과 직접 비교 대상이 아니라 교차 검증치로 해석하세요 (§7.10 참조). - C6·C9는 미측정 — C6(동의어 사전)은 사전 구축은 완료했으나 평가용 고객 데이터 부족으로 테스트를 보류, C9(LLM 교체)는 현 단계 보류입니다.

---

 

3. 평가 데이터셋 구성

본 평가 데이터셋 기준입니다.

항목	값
건수 (객실)	Golden Dataset 130건 입고 → 정답 확인이 어려운 쿼리 등 제외, 실제 평가 121건 사용
Ground Truth 형식	expected_facts (핵심 사실 리스트)
대화 방식	단일 턴 Q&A
언어	한국어
Tracing	검색 함수에 @mlflow.trace(span_type="RETRIEVER") 셋업 완료

데이터셋 버전 관리: 평가 데이터셋이 바뀌면 케이스 간 비교가 무의미해집니다. 질문을 추가하거나 expected_facts를 수정할 때마다 버전 태그(예: eval-v1.0, eval-v1.1)를 붙이고, 각 케이스의 MLflow Run 메모에 사용한 버전을 함께 기록하세요.

 

3.1 expected_facts 작성 원칙

• 정답을 구성하는 최소 핵심 사실을 원자 단위로 분해
• 문체·어순은 무관. Scorer(Correctness·RetrievalSufficiency)가 사실 포함 여부를 의미적으로 판정
• 모범 답안 전체를 쓰지 말 것 (그 용도는 expected_response이며 본 실험에서는 사용하지 않음)

{
  "inputs": {"query": "A항공의 마일리지 유효기간은 몇 년인가요?"},
  "expectations": {
    "expected_facts": [
      "A항공 마일리지 유효기간은 10년이다",
      "적립 시점의 년도를 기준으로 계산한다",
      "유효기간 경과 시 자동 소멸된다"
    ]
  }
}

---

 

4. 측정 지표

7개 Scorer를 매 케이스에 동일하게 적용합니다. 목표 Pass율은 예시값이며, 1차 측정 후 팀 합의로 재조정 가능합니다.

Judge LLM 고정: 모든 Scorer의 Judge LLM은 databricks-gpt-5-2 (Databricks 서빙)으로 전 Case 고정합니다. 생성 LLM·필터 LLM과 별개의 모델이므로, 케이스 간 지표 변동을 Judge 편향이 아닌 실제 파이프라인 품질 차이로 해석할 수 있습니다.

시스템 LLM 역할 분리: 본 시리즈에는 LLM이 세 가지 역할로 등장합니다 — 혼동을 막기 위해 항상 분리 표기합니다 (엔드포인트명은 소스 정본 config.yaml 기준). - 생성 LLM: 최종 답변 생성. Case 1~8·C10은 databricks-gemini-3-flash (fallback databricks-claude-sonnet-4-6), Case 9(보류)는 databricks-claude-sonnet-4-6 교체 후보. - 필터 LLM (Case 8~): Self-RAG 문서 관련성·추가 검색 필요 판정. databricks-gpt-5-4-nano 고정 (소스 judge_model_endpoint). 문서별 개별 호출이 아니라 검색 라운드당 1회 호출로 후보 전체를 한 프롬프트에 넣어 RELEVANT/NOT_RELEVANT와 SUFFICIENT/INSUFFICIENT를 동시 판정합니다. Case 9에서 생성 LLM이 교체되어도 필터 LLM은 변경하지 않음 (변수 통제). - Judge LLM (평가 전용): Scorer가 사용. databricks-gpt-5-2 전 Case 고정. 시스템 컴포넌트가 아니므로 운영에는 영향 없음.

※ 세 역할 모두 Databricks 서빙 엔드포인트입니다. 생성/필터는 에이전트 소스 config.yaml(llm_endpoint·fallback_llm_endpoint·judge_model_endpoint)에서 확인되며, 평가 Judge는 MLflow Evaluation 측 설정입니다.

#	단계	Scorer	목표(예시)	Ground Truth	주 관찰 포인트
1	검색	RetrievalRelevance	≥ 80%	불필요	각 문서 조각의 질문 관련성 (정밀도)
2	검색	RetrievalSufficiency	≥ 70%	expected_facts	검색 문서 전체가 정답을 구성하기에 충분한가 (재현율)
3	증강	RetrievalGroundedness	≥ 90%	불필요	답변이 검색 문서에 근거하는가 (환각 방지)
4	생성	Correctness	≥ 80%	expected_facts	expected_facts를 빠짐없이 포함하는가
5	생성	Completeness	≥ 85%	불필요	복합 질문의 모든 항목에 답했는가
6	생성	RelevanceToQuery	≥ 80%	불필요	질문에 직접 응답하는가
7	생성	Safety	≥ 90%	불필요	유해·부적절 응답이 없는가

제외 Scorer: Equivalence(엄격 동치 — Q&A RAG에 과도), Fluency(한국어 LLM 안정), Guidelines(본 실험 범위 밖).

---

 

5. 청킹 전략 (본 시리즈 내 고정 변수)

Case 1~9 비교에서 청킹은 변경하지 않습니다. 본 실험의 제어 변수가 아니라 시리즈 내 고정값으로 취급합니다. 청킹 단위 자체의 영향 분석은 §9.3 후속 실험 후보에서 별도로 다룹니다.

항목	설명
원본 포맷	Google Docs → JSON 변환
청크 단위	문서 구조상의 특정 문단/섹션을 하나의 청크로 사용 (예: "3단계" 하위 문단을 단일 청크로 묶음)
선택 이유	문단 단위로 의미가 완결되어 맥락 손실이 적고, 검색 시 불필요한 추가 컨텍스트가 덜 딸려옴

---

 

6. 케이스 설계 표

본 표는 실험 설계(각 케이스가 무엇을 테스트했는가) 입니다. 실측 결과 최종 채택된 Production 구성(Rerank 미채택, 임베딩 Qwen3 유지, 생성 LLM Gemini 유지 등)은 §2.1 최종 Production 구성을 정본으로 합니다.

#	변경 포커스	청킹	임베딩	Retrieval	동의어 사전	Top-K	Reranking	Self-RAG 필터	생성 LLM
1	Baseline	문단 기반	databricks-qwen3-embedding-0-6b	Managed / Semantic	—	5	—	—	databricks-gemini-3-flash
2	임베딩 교체	←	Cohere Embed Multilingual V3 (cohere.embed-multilingual-v3, Bedrock)	Managed / Semantic	—	5	—	—	←
3	Managed Hybrid	←	Case 1·2 중 우수(→ Qwen3 유지)	Managed / Hybrid w/ Kiwi (모든 string 컬럼)	—	5	—	—	←
4	Self-managed RRF	←	←	Self-managed / Hybrid w/ Kiwi + RRF (토크나이즈 컬럼만)	—	K′=20 → top-5	—	—	←
5	Self-managed Min-Max	←	←	Self-managed / Hybrid w/ Kiwi + Min-Max (토크나이즈 컬럼만)	—	K′=20 → top-5	—	—	←
6	동의어 사전 (구축 완료·평가 보류)	←	←	Case 4·5 중 최고	Query time 동의어 확장 (구축 완료)	K′=20 → top-5	—	—	←
7	Reranking (단독 측정 후 미채택)	←	←	←	←	20 → top-5	Cohere Rerank 3.5 (Bedrock)	—	←
8	Self-RAG 필터	←	←	←	←	20 → top-5 → 필터 → 0~5	←	databricks-gpt-5-4-nano, 옵션 A(가변 K)	←
9	LLM 교체 (보류·미측정)	←	←	←	←	20 → top-5 → 필터 → 0~5	←	← (필터 LLM 고정)	databricks-claude-sonnet-4-6

Top-K 정책 - Case 1~7: LLM 전달 K=5 전 케이스 동일 → 비교는 "어떤 5개를 선별하느냐"의 순수 차이 - Case 4·5·6의 K′=20: FTS와 Semantic을 개별로 호출 후 결합하는 앙상블 구조. 두 리스트 합쳐 중복 제거 후 고유 후보 25~35개 확보 → RRF·Min-Max가 의미 있는 재정렬을 수행할 수 있는 pool - Case 7의 후보 20: Cohere Rerank 3.5의 통상 권장 후보치. 베이스가 Case 3이면 단일 Hybrid 호출에서 20을 가져오고, Case 4~6이면 K′=20 앙상블 → fuse → top-20을 Rerank 입력으로 사용 - Case 8~9: LLM 전달 K가 0~5로 가변 (옵션 A) — Rerank top-5를 필터에 입력하고 통과한 문서만 LLM에 전달. K=5 동일 전제가 깨지므로 Case 1~7과의 절대값 비교가 아닌 Δ 해석만 유효함을 §8.6/§8.7에 명시.

동의어 사전 정책 (Case 6~) - 방식: Query time 동의어 확장. 사용자 쿼리를 Kiwi 토큰화 → 동의어 사전 룩업 → BM25 쿼리에 OR로 확장. Index time 방식과의 비교는 §9.3 후속 로드맵에서 별도 검토. - 사전 구축: 완료 — 구축 절차·검증은 한국어 RAG 검색 (Kiwi) 시리즈 정본 참조 (IATA 등 도메인 사전 포함). 다만 동의어 효과를 검증할 평가용 고객 데이터가 부족해 본 라운드 측정(테스트)은 보류했습니다. - 적용 범위: Self-managed Hybrid의 BM25 쿼리에만 적용. Semantic 검색에는 영향 없음.

Self-RAG 필터 정책 (Case 8~) — 소스 정본 ensemble_retriever.py·agent.py 기준 - 입력: Self-managed Hybrid(Min-Max) Claim-Check 후 후보 문서 (Rerank 미채택이므로 Case 5 베이스). - 판정 (단일 호출): 필터 LLM이 후보 전체를 한 프롬프트로 묶어 1회 호출(temperature=0)하여, ① 문서별 RELEVANT/NOT_RELEVANT([IsRel]) ② RETRIEVAL: SUFFICIENT/INSUFFICIENT([Retrieve]) ③ REASON(재검색 힌트)를 동시 출력합니다. 문서별 병렬 호출이 아닙니다. - 출력: RELEVANT만 LLM에 전달(num_results 상한). 0~5개로 가변(옵션 A)이되, RELEVANT 0건이면 상위 num_results건을 보충(NOT_RELEVANT_SUPPLEMENTED)하므로 실질 하한은 0이 아닙니다(빈 컨텍스트 방지). - 적응 재검색 ([Retrieve]): INSUFFICIENT 판정 시 에이전트(LangGraph ReAct)가 이미 본 문서를 제외(exclude_ids)하고 REASON 힌트를 다음 쿼리에 반영해 최대 max_iterations회(현재 2회) 자동 재검색합니다. - 필터 LLM 고정: databricks-gpt-5-4-nano — Case 9에서 생성 LLM이 교체되어도 필터 LLM은 그대로 유지 (변수 통제). 이로써 Case 9의 지표 변동은 순수하게 생성 LLM 차이로 귀속됨.

모델 엔드포인트 (소스 정본 config.yaml 기준) - 생성 LLM: databricks-gemini-3-flash (llm_endpoint) — Databricks 서빙 Gemini. fallback databricks-claude-sonnet-4-6 (fallback_llm_endpoint). - 임베딩: databricks-qwen3-embedding-0-6b (embedding_endpoint) — Databricks Model Serving 커스텀 배포. (Case 2의 cohere.embed-multilingual-v3(Cohere Embed Multilingual V3, Bedrock)는 비교 측정 후 미채택) - Self-RAG 필터 LLM: databricks-gpt-5-4-nano (judge_model_endpoint) — Databricks 서빙. - 평가 Judge LLM: databricks-gpt-5-2 — MLflow Evaluation 측 설정 (에이전트 소스 외부). - Reranker: Cohere Rerank 3.5 (Bedrock) — Case 7 단독 측정용. 최종 미채택이라 소스에는 미구현(향후 슬롯).

---

 

7. 케이스별 상세

각 케이스는 변경 이유 → 기대 효과 → MLflow Run → 실측 지표 → 해석 → 다음 액션 순으로 기록합니다. 미측정 케이스(C6 동의어·C9 LLM 교체)는 (미측정), MLflow Run ID/URL 등 아직 기재되지 않은 메타데이터는 (TBD)로 표기합니다.

 

7.1 Case 1 — Baseline (Qwen3 + Managed Semantic)

구성 - 임베딩: databricks-qwen3-embedding-0-6b (Databricks 서빙) - Retrieval: Databricks Vector Search / Semantic search only - Top-K: 5 (LLM 전달 K=5) - LLM: databricks-gemini-3-flash

목적 · 변경 이유 가장 단순한 구성으로 기준선을 확보. 이후 모든 개선은 이 값과의 차이로 평가됩니다.

기대 효과 - 단일 벡터 유사도 기반이므로 의미가 유사한 문서는 잘 잡지만, 고유명사·코드·한국어 형태소가 중요한 쿼리에서는 놓칠 가능성이 있음. - RetrievalRelevance·Correctness가 이후 케이스 대비 낮게 나올 것으로 예상.

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	vs Baseline	판정
RetrievalRelevance	47.0%	≥ 80%	— (기준)	—
RetrievalSufficiency	59.0%	≥ 70%	— (기준)	—
RetrievalGroundedness	69.0%	≥ 90%	— (기준)	—
Correctness	62.0%	≥ 80%	— (기준)	—
Completeness	79.0%	≥ 85%	— (기준)	—
RelevanceToQuery	98.0%	≥ 80%	— (기준)	—
Safety	99.0%	≥ 90%	— (기준)	—

해석 Semantic 단독 구성의 기준선은 Correctness 62%, RetrievalRelevance 47%로, 목표(각 80%)에 크게 못 미쳤습니다. 특히 문서별 정밀도(RetrievalRelevance 47%)가 낮아, 의미는 유사하나 정답과 다른 문서가 상위에 올라오는 한계가 확인됐습니다. 반면 RelevanceToQuery(98%)·Safety(99%)는 생성 LLM 자체 품질에 기인해 처음부터 높았습니다.

다음 액션 Case 2에서 임베딩 모델을 교체하여 의미 검색의 표현력 한계를 먼저 제거.

---

 

7.2 Case 2 — 임베딩 교체 (Cohere Embed V3 via Bedrock)

구성 (Case 1 대비 변경점) - 임베딩: databricks-qwen3-embedding-0-6b (Databricks 서빙) → cohere.embed-multilingual-v3 (Cohere Embed Multilingual V3, Amazon Bedrock에서 사전 계산 후 컬럼에 주입) - 인덱스 운영: Delta Sync 방식은 Case 1과 동일, 인덱스에 들어가는 embedding 값만 외부 산출물로 교체 - Top-K: 5 (Case 1과 동일) - 나머지: Case 1과 동일

변경 이유 - Cohere Embed Multilingual V3(cohere.embed-multilingual-v3)는 공개 벤치마크(MIRACL nDCG@10 79.9 — Cohere Embed V4 78.3·OpenAI text-embedding-3-large 74.6)상 한국어 retrieval에 강점이 있어 후보로 검토했습니다. V4는 한국어 단일 성능이 V3보다 낮고 Databricks External Model 경로 비호환(invocation 시 500 오류) 이슈가 있어 V3로 비교했습니다. - 외부 임베딩을 컬럼에 직접 주입하는 방식이라, Databricks 관리형 인덱스의 운영 편의성을 유지한 채 임베딩 모델만 교체할 수 있음.

기대 효과 - RetrievalRelevance · RetrievalSufficiency 상승 - 이에 따라 Correctness도 연쇄 상승 가능

측정 범위 노트 - managed VS endpoint 가 색인·검색 호출 시 input_type 을 어떻게 처리하는지(search_document/search_query 자동 분기 여부)는 구현 시 검증이 필요합니다. single input_type 으로 동작할 경우 V3 의 비대칭 인코딩 advantage 가 본 케이스에서는 부분 활용에 그칠 수 있습니다. - V3 의 input_type 비대칭이 명확히 활용되는 구성은 Case 4 (Self-managed 전환) 에서 다룹니다 (색인 시 search_document, 검색 시 search_query 분기 호출). - input_type 분기 패턴은 임베딩 모델 문서를 참조하세요.

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	Case 1 대비	판정
RetrievalRelevance	46.0%	≥ 80%	−1.0%p	미달
RetrievalSufficiency	58.0%	≥ 70%	−1.0%p	미달
RetrievalGroundedness	68.0%	≥ 90%	−1.0%p	미달
Correctness	61.0%	≥ 80%	−1.0%p	미달
Completeness	78.0%	≥ 85%	−1.0%p	미달
RelevanceToQuery	98.0%	≥ 80%	0.0%p	충족
Safety	99.0%	≥ 90%	0.0%p	충족

해석 측정 결과 Cohere Embed Multilingual V3(cohere.embed-multilingual-v3)는 본 프로젝트 구성에서 Qwen3와 대등하거나 근소 열위(RetrievalRelevance·Correctness 각 −1%p 수준)였고, 입력 길이 한도가 짧아(평가 환경에서 ~700토큰 수준 관측) 문단 단위 청크(긴 컨텍스트)를 온전히 인코딩하지 못하는 한계가 있었습니다. Cohere Embed V4는 한국어 단일 성능이 V3보다 낮은 데다 Databricks External Model 경로 미지원이었습니다. 따라서 긴 컨텍스트(32k)를 안정적으로 지원하는 Qwen3를 유지했습니다.

다음 액션 (임베딩 승자 선정) - Case 3 이후 임베딩 = databricks-qwen3-embedding-0-6b (Qwen3, Context 32k) 유지 확정. 검색 성능이 대등하면서 긴 컨텍스트를 안정적으로 지원하는 점을 우선했습니다.

---

 

7.3 Case 3 — Managed Hybrid Search (Kiwi)

구성 (Case 2 대비 변경점) - Retrieval: Semantic only → Managed Hybrid Search (벡터 + Full-text) - Full-text 토크나이저: Kiwi (한국어 형태소) - Full-text 검색 대상 컬럼: 모든 string 컬럼 (관리형 인덱스의 기본 동작) - Top-K: 5 (단일 Hybrid 호출, 내부 결합 후 상위 5개 반환)

변경 이유 — 왜 Hybrid인가 - Semantic 단독은 표현은 유사하지만 정답과 다른 문서를 상위에 올리는 경우가 있음. 반대로 BM25 단독은 동의어·의역에 약함. - 한국어는 조사·어미·복합명사 분해가 품질을 좌우하므로 Kiwi 형태소 분석기를 BM25 토크나이저로 사용.

Case 3의 특징 — Full-text 대상이 "모든 string 컬럼" - Databricks 관리형 hybrid 인덱스는 설정을 단순화하기 위해 string 타입 컬럼 전반을 full-text 대상으로 취급. - 이로 인해 임베딩 원본 텍스트 컬럼과 Kiwi 토크나이즈 컬럼이 거의 중복되어 색인됨. 운영은 간편하지만 색인 용량과 가중치 튜닝 자유도 면에서는 불리.

기대 효과 - RetrievalRelevance 상승 (특히 고유명사·숫자·코드 쿼리) - RetrievalSufficiency 소폭 상승

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	Case 1 대비	판정
RetrievalRelevance	48.0%	≥ 80%	+1.0%p	미달
RetrievalSufficiency	59.0%	≥ 70%	0.0%p	미달
RetrievalGroundedness	63.0%	≥ 90%	−6.0%p	미달
Correctness	68.0%	≥ 80%	+6.0%p	미달
Completeness	79.0%	≥ 85%	0.0%p	미달
RelevanceToQuery	99.0%	≥ 80%	+1.0%p	충족
Safety	99.0%	≥ 90%	0.0%p	충족

베이스 = Case 1: 임베딩 승자가 Qwen3(=Case 1)로 확정됐으므로, Managed Hybrid 추가 효과는 Case 1 대비로 측정합니다 (Case 2의 Cohere V3는 미채택).

해석 Managed Hybrid(벡터 + Kiwi BM25) 전환으로 Correctness가 62%(C1)→68%로 상승했습니다. 다만 RetrievalRelevance(48%)는 C1과 거의 같고 RetrievalGroundedness(63%)는 오히려 하락했는데, 모든 string 컬럼을 full-text 대상으로 삼는 관리형 기본 동작 탓에 임베딩 원본과 Kiwi 토큰 컬럼이 중복 색인되어 노이즈가 섞인 것으로 해석됩니다. 키워드 채널 도입의 방향성은 맞으나, 색인 구조 정리가 필요함을 시사합니다.

다음 액션 중복 색인을 제거하고 가중치 튜닝 자유도를 확보하는 Self-managed 구성(Case 4·5)으로 이동.

---

 

7.4 Case 4 — Self-managed Hybrid (Kiwi + RRF)

구성 (Case 3 대비 변경점) - Retrieval: Managed Hybrid → Self-managed Hybrid (LangChain EnsembleRetriever) - Full-text 검색 대상 컬럼: 모든 string 컬럼 → Kiwi 토크나이즈 전용 컬럼만 - 결합 방식: RRF (Reciprocal Rank Fusion) - Top-K: FTS K′=20 + Semantic K′=20 → RRF → top-5 (앙상블에서 각 리트리버가 개별 호출되므로 K′를 확대)

변경 이유 — Case 3 대비 - §7.3 "다음 액션"에서 제시한 중복 색인 제거와 가중치 튜닝 자유도 확보를 실행. - 임베딩용 원본 컬럼과 Kiwi 토큰 컬럼의 역할을 분리 → 한국어 토큰화 품질을 Full-text에 집중 반영. - EnsembleRetriever로 이동하면서 가중치·결합 방식을 실험자가 제어 가능.

아키텍처 전환의 필연성: Managed 인덱스는 FTS 검색 대상 컬럼을 사용자가 제어할 수 없고 모든 string 컬럼을 대상으로 함. FTS 컬럼 범위를 축소하려면 Self-managed embedding으로의 전환이 기술적 전제. 따라서 Case 4의 "Self-managed 전환"과 "컬럼 범위 축소"는 독립된 두 변수가 아니라 같은 설계 결정(컬럼 축소)의 양면. 관측되는 성능 변화는 두 요인을 합친 "컬럼 축소 가능한 구조로의 전환"의 총 효과로 해석해야 함.

RRF란 - 문서별로 각 리트리버의 순위를 받아 1 / (k + rank)를 합산. 점수 스케일 차이에 강건하고 파라미터가 적음 (보통 k=60). - 단점: 절대 유사도 정보를 버림 → 점수 분포를 활용한 튜닝은 불가.

기대 효과 - Case 3 대비 RetrievalRelevance 유지 또는 소폭 상승 - 색인 구조가 명확해져 이후 가중치 튜닝(Case 5)으로의 이행이 용이

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	Case 3 대비	판정
RetrievalRelevance	58.0%	≥ 80%	+10.0%p	—
RetrievalSufficiency	72.0%	≥ 70%	+13.0%p	—
RetrievalGroundedness	68.0%	≥ 90%	+5.0%p	—
Correctness	70.0%	≥ 80%	+2.0%p	—
Completeness	86.0%	≥ 85%	+7.0%p	—
RelevanceToQuery	98.0%	≥ 80%	−1.0%p	—
Safety	98.0%	≥ 90%	−1.0%p	—

해석 Self-managed 전환 + Kiwi 토크나이즈 전용 컬럼으로 색인을 정리하자 검색 지표가 큰 폭으로 상승했습니다 (RetrievalRelevance +10%p, RetrievalSufficiency +13%p, Completeness +7%p). 중복 색인 제거와 컬럼 범위 축소(§7.4 callout의 "같은 설계 결정의 양면")가 본 시리즈에서 가장 큰 검색 품질 개선 구간으로 확인됩니다. Correctness도 70%로 상승했고, RetrievalSufficiency(72%)는 이 시점에 처음 목표(70%)를 넘었습니다.

다음 액션 동일 컬럼 구성에서 결합 방식만 RRF → Min-Max로 바꿔 Case 5와 직접 비교.

---

 

7.5 Case 5 — Self-managed Hybrid (Kiwi + Min-Max 정규화)

구성 (Case 4 대비 변경점) - 결합 방식: RRF → Min-Max 정규화 후 가중합 - 컬럼 구성은 Case 4와 동일 (Kiwi 토크나이즈 전용 컬럼) - Top-K: FTS K′=20 + Semantic K′=20 → Min-Max → top-5 (K′은 Case 4와 동일, 결합 방식만 차이)

변경 이유 — RRF 대비 Min-Max가 유리할 수 있는 시나리오 - RRF는 순위만 사용하므로 "semantic 유사도가 압도적으로 높은 문서"와 "근소하게 앞서는 문서"를 구분하지 못함. - Min-Max 정규화 후 가중합은 점수 분포를 보존하므로, 의미 유사도가 확실한 경우 더 공격적으로 상위에 배치 가능. - 대신 이상치에 민감하며, 쿼리마다 분포가 달라 가중치 튜닝이 필요.

비교 포인트 - 한국어 사내 문서 검색에서 어느 결합 방식이 우수한지의 실증. - Case 4 vs Case 5의 차이는 결합 방식 단 하나이므로, 성능 차이를 결합 방식에 귀속시킬 수 있음.

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	Case 4 대비	판정
RetrievalRelevance	60.0%	≥ 80%	+2.0%p	—
RetrievalSufficiency	73.0%	≥ 70%	+1.0%p	—
RetrievalGroundedness	60.0%	≥ 90%	−8.0%p	—
Correctness	69.0%	≥ 80%	−1.0%p	—
Completeness	83.0%	≥ 85%	−3.0%p	—
RelevanceToQuery	99.0%	≥ 80%	+1.0%p	—
Safety	99.0%	≥ 90%	+1.0%p	—

해석 결합 방식만 RRF→Min-Max로 바꾼 결과, 검색 지표(RetrievalRelevance +2%p, RetrievalSufficiency +1%p)는 소폭 개선됐으나 RetrievalGroundedness(−8%p)·Correctness(−1%p)는 하락했습니다. 단일 비교에서는 RRF(C4)가 근소 우위로 보입니다. 그러나 점수 분포를 보존하는 Min-Max가 이후 Self-RAG 필터와 결합되는 최종 파이프라인(Case 8)에서 더 안정적이라는 점(RRF는 결합 시 지표 하락 — §8.3)이 최종 채택 근거가 됐습니다. 소스 정본 config.yaml의 fusion_method도 min_max입니다.

다음 액션 (Retrieval 승자 선정) - Case 6 이후 베이스 Retrieval = Self-managed Hybrid (Kiwi + Min-Max). 단일 지표는 RRF가 근소 우위이나, 최종 파이프라인 안정성을 근거로 Min-Max를 최종 퓨전 룰로 채택했습니다 (소스 fusion_method: min_max).

---

 

7.6 Case 6 — 동의어 사전 (Query time, 잠정)

측정 상태: 평가 보류 (사전 구축은 완료). 동의어 사전은 한국어 RAG 검색 (Kiwi) 시리즈 절차대로 구축을 마쳤고, 동의어 확장 인프라(synonym_dir)도 에이전트 소스에 구현되어 있습니다. 다만 동의어 효과를 검증할 평가용 고객 데이터가 부족해 본 라운드의 측정(테스트)만 보류했습니다. 데이터 확보 시 사전 동결 상태 그대로 바로 측정할 수 있습니다.

방식 검토 중: 본 케이스는 Query time 동의어 확장으로 잠정 진행합니다. Index time 방식(Kiwi 사용자 사전 등록)과의 성능·운영 비교는 §9.3 후속 로드맵에서 별도로 다룹니다. Index time으로 결정 시 본 §7.6과 §6 케이스 설계 표를 함께 갱신하세요.

전제 - 베이스 Retrieval = Self-managed Hybrid (Case 4·5 중 우수). Case 3 (Managed Hybrid)이 우승하면 본 케이스 스킵.

구성 (Case 5 대비 변경점) - 검색 흐름: 사용자 쿼리 → Kiwi 토큰화 → 동의어 사전 룩업 → BM25 쿼리에 OR로 확장 → 기존 RRF/Min-Max 결합 그대로 - 예: "마일리지 알려줘" → BM25 검색 시 (마일리지 OR 포인트 OR 적립금) 알려줘로 확장 - Semantic 검색에는 영향 없음 (벡터 유사도 그대로) - Top-K: Case 4·5와 동일 (FTS K′=20 + Semantic K′=20 → fuse → top-5) - 사전 보관: 별도 컴포넌트 (예: YAML 파일 또는 Delta 테이블)

변경 이유 — 왜 동의어 사전인가 - Qwen3 임베딩 + Kiwi BM25 조합도 표면 키워드가 다른 동의어 관계에선 여전히 약점. 임베딩이 의미를 어느 정도 흡수하지만, BM25는 표면 매칭이라 약칭·코드·표기 흔들림에서 누락 발생. - 한국어 사내 문서에서 빈번한 패턴: - 약칭 ↔ 풀네임 (KE ↔ A항공/KAL) - 도메인 용어 ↔ 일반 용어 (마일리지 ↔ 포인트 ↔ 적립금) - 영문 코드 ↔ 한국어 명칭 (PNR ↔ 예약번호) - 표기 흔들림 (보딩패스/탑승권, 항공편/비행편)

구축 절차 (측정 시작 전 선결) 1. 도메인 전문가(KE 운영팀) 인터뷰로 1차 사전 작성 (목표 50~200쌍) 2. 운영 로그·FAQ에서 보강 후보 추출 3. 사전 동결 — 평가 데이터셋을 보고 사전을 튜닝하면 과적합. 동결 후 측정 시작. 4. 측정 후 사전을 수정하면 결과 무효화. 사전 변경 시 별도 Run으로 분리 측정.

기대 효과 - RetrievalRelevance ↑ — 약칭·도메인 용어 쿼리에서 누락 감소 - RetrievalSufficiency ↑ — 정답 문서가 다른 표기로 들어있는 경우 잡음 - Correctness 연쇄 상승

리스크 / 합격 조건 - 사전 품질이 결과를 좌우. 부정확한 동의어(예: 동음이의어 잘못 매핑)가 들어가면 노이즈 증가로 RetrievalRelevance ↓ 위험. - 합격 조건: Case 5 대비 RetrievalRelevance · RetrievalSufficiency 모두 ≥ 유지 또는 상승. 한쪽이라도 떨어지면 사전 검수 후 재측정, 재차 떨어지면 동의어 사전 미채택.

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	Case 5 대비	판정
RetrievalRelevance	(미측정)	≥ 80%	↑ 기대 (사전 품질 양호 시)	—
RetrievalSufficiency	(미측정)	≥ 70%	↑ 기대	—
RetrievalGroundedness	(미측정)	≥ 90%	—	—
Correctness	(미측정)	≥ 80%	↑ 기대	—
Completeness	(미측정)	≥ 85%	—	—
RelevanceToQuery	(미측정)	≥ 80%	—	—
Safety	(미측정)	≥ 90%	변동 없어야 함	—

보조 진단 지표 - 사전 적중률: 평가 쿼리 중 동의어 확장이 일어난 쿼리 비율. 너무 낮으면 사전 커버리지 부족. - 확장 쿼리 평균 토큰 수: 과도한 확장은 BM25 노이즈 증가. 적정 수준 모니터링.

해석 평가 보류 (사전 구축 완료). 베이스 Retrieval은 §7.5 결론대로 Self-managed Hybrid(Min-Max)이며, 사전은 이미 구축되어 있으므로 평가용 고객 데이터가 확보되면 바로 Case 6을 재개합니다.

다음 액션 평가용 데이터 확보 후 동결된 사전 그대로 Case 5 대비 RetrievalRelevance·RetrievalSufficiency Δ를 측정. 합격 조건(둘 다 ≥ 유지) 충족 시 채택, 미충족 시 미채택. 측정 여부와 무관하게 Case 7 (Rerank) 비교는 Case 5 베이스로 진행했습니다.

---

 

7.7 Case 7 — Reranking (Cohere Rerank 3.5 via Bedrock)

구성 (Case 6 대비 변경점) - 베이스 Retrieval: Case 6 (동의어 사전 적용 Self-managed Hybrid) 또는 Case 3 (Managed Hybrid가 우승해 Case 6 스킵된 경우) - Rerank: Cohere Rerank 3.5 (Amazon Bedrock) - Top-K: 후보 20 → Rerank → top-5 - 베이스가 Case 3 (Managed Hybrid) 우승: 단일 Hybrid 호출 K=20 → Rerank → top-5 - 베이스가 Case 6 (동의어 사전 적용 Ensemble): FTS K′=20 (동의어 확장 포함) + Semantic K′=20 → fuse → top-20 → Rerank → top-5

변경 이유 - Retrieval 단계는 재현율(Sufficiency) 우선으로 넉넉히 가져오고, Rerank 단계에서 정밀도(Relevance)를 끌어올리는 2단 구조가 실무에서 가장 안정적. - Cohere Rerank 3.5는 한국어 포함 다국어에 강하며, Query-Document cross-encoder 방식이라 앞단 bi-encoder의 한계를 보완.

기대 효과 - RetrievalRelevance 대폭 상승 - Correctness · Completeness 동반 상승 - Latency는 소폭 증가 (Rerank 호출 추가) — 평가 품질과 별도 관리

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	베이스(C5) 대비	판정
RetrievalRelevance	63.0%	≥ 80%	+3.0%p	미달
RetrievalSufficiency	75.0%	≥ 70%	+2.0%p	충족
RetrievalGroundedness	62.0%	≥ 90%	+2.0%p	미달
Correctness	71.0%	≥ 80%	+2.0%p	미달
Completeness	84.0%	≥ 85%	+1.0%p	미달
RelevanceToQuery	99.0%	≥ 80%	0.0%p	충족
Safety	99.0%	≥ 90%	0.0%p	충족

베이스 Case 대비 컬럼 의미: Case 6(동의어 사전)이 미측정이므로 베이스 = Case 5 (Self-managed Hybrid + Min-Max) 입니다.

해석 Cohere Rerank 3.5를 단독 적용하자 검색·생성 지표가 전반적으로 소폭 상승했습니다 (RetrievalRelevance +3%p, RetrievalSufficiency +2%p, Correctness +2%p). cross-encoder 재정렬의 방향성 자체는 유효함을 확인했습니다. 그러나 이후 Self-RAG 필터와 파이프라인으로 결합했을 때(Case 8-1) 오히려 지표가 하락하는 간섭 현상이 관측됐습니다 — Rerank(정밀도 향상)와 LLM 관련성 필터가 같은 목적을 중복 수행하면서 충돌하는 것으로 해석됩니다. 이 때문에 최종 아키텍처에서는 Rerank를 제외했습니다 (소스에도 미구현 — 향후 슬롯).

다음 액션 Rerank는 단독으로는 유효하나 필터와 결합 시 하락하므로 미채택. Case 8은 Rerank 없이 Case 5(Min-Max) 베이스 위에 Self-RAG 필터를 적용한 구성으로 측정합니다.

---

 

7.8 Case 8 — LLM 기반 Self-RAG 필터 (GPT-5-4-nano)

Self-RAG 구현 범위: 본 에이전트는 Self-RAG(Asai et al., 2023)의 [IsRel](문서별 관련성 판정)과 [Retrieve](추가 검색 필요 판정) 두 critique를 차용합니다. 근거 지지 [IsSup]·유용성 [IsUse] critique와 전용 fine-tuned 모델은 도입하지 않습니다. 구체적으로 필터 LLM이 한 번의 호출로 ① 문서별 RELEVANT/NOT_RELEVANT(IsRel) ② RETRIEVAL: SUFFICIENT/INSUFFICIENT(Retrieve) ③ REASON(검색 힌트)를 출력하고, INSUFFICIENT일 때 에이전트(LangGraph ReAct)가 이미 본 문서를 제외(exclude_ids)하고 힌트를 반영해 최대 max_iterations회(현재 2회) 자동 재검색합니다. 본 평가 케이스(C8)는 이 구성에서 관련성 필터(IsRel)의 분리 기여도를 측정한 것입니다. full Self-RAG(IsSup/IsUse)·CRAG는 §9.3 후속 실험 후보.

구성 (베이스 = Case 5 Min-Max, Rerank 제외) - 검색 파이프라인 끝단에 Self-RAG 필터 추가: Self-managed Hybrid(Min-Max) 후보 → 필터 → 0~5개를 LLM에 전달 (옵션 A, 가변 K) - 필터 LLM: databricks-gpt-5-4-nano (생성 LLM databricks-gemini-3-flash·평가 Judge databricks-gpt-5-2와 모두 별개 — 역할 분리는 §4 "시스템 LLM 역할 분리" 참조) - 필터 호출 방식: 후보 문서 전체를 한 프롬프트로 묶어 Judge LLM 1회 호출(temperature=0). 출력은 JUDGMENTS(문서별 RELEVANT/NOT_RELEVANT) + RETRIEVAL(SUFFICIENT/INSUFFICIENT) + REASON 구조 (문서별 병렬 호출 아님) - 적응 재검색: INSUFFICIENT 시 exclude_ids로 중복 제외 + 힌트 반영해 최대 2회 재검색 (§4·§6 정책 참조) - Rerank 제외: Case 7의 Rerank를 필터와 결합한 조합(Case 8-1)은 간섭으로 지표가 하락(§7.7 해석)했으므로, 최종 채택 구성에서는 Rerank를 빼고 Case 5(Min-Max) 위에 필터만 적용 - 임베딩·Hybrid·동의어 사전 미적용 상태는 Case 5와 동일, Judge LLM·생성 LLM도 동일

변경 이유 - Rerank는 점수 기준 순위만 매길 뿐 무관 문서를 컨텍스트에서 제외하지 못함. top-5 안에도 노이즈가 섞여 들어가 RetrievalGroundedness·Correctness를 끌어내릴 수 있음. - LLM이 문서별 관련성을 한 번 더 판정해 컨텍스트를 정화하면, 생성 단계에서 환각·산만한 답변이 줄어듦. - 한국어 사내 문서처럼 표면 키워드는 일치하지만 의미가 빗나간 문서가 자주 등장하는 도메인에서 효과가 큼 (Cross-encoder Rerank로도 못 거르는 케이스를 LLM 추론으로 보완).

필터 LLM 선정 근거 — 왜 GPT-5-4-nano인가 - 검색 라운드마다 호출 (적응 재검색 시 라운드당 1회씩 추가) + 대용량 컨텍스트(후보 문서를 한 프롬프트에, 문서당 최대 40k자) 입력이라 경량·저비용 모델이 비용·레이턴시 측면에서 유리. - 평가 Judge LLM(databricks-gpt-5-2)·생성 LLM(databricks-gemini-3-flash)과 모두 분리 — Judge와 같은 모델을 쓰면 Judge가 자기가 거른 컨텍스트를 다시 평가하는 self-evaluation bias 위험. - 구조화 판정(RELEVANT/NOT_RELEVANT + SUFFICIENT/INSUFFICIENT)에 충분한 추론 능력.

옵션 A (가변 K) 채택 사유 - 필터 후 부족분을 보충(옵션 B)하면 "필터의 노이즈 제거 효과"가 희석되어 변수 통제가 약해짐. - 가변 K는 Case 1~7과의 절대값 비교는 불가하나, Case 5 → Case 8 Δ 해석으로 필터 효과를 순수하게 측정 가능. 단 RELEVANT 0건 시 상위 문서 보충(§6 정책)이 동작하므로 실질 하한은 0이 아닙니다.

필터 프롬프트 작성 원칙 (과적합 방지) - "확실히 무관한 문서만 제거"하는 보수적 톤. 애매하면 통과시킴 (재현율 우선). - 평가 데이터셋을 보고 튜닝하지 말 것 — 일반 원칙 → 동결 → 측정 순서 엄수. - 동일 (질문, 문서) 쌍에서 일관된 판정을 내는지 별도 검증 (temperature=0 + 샘플 50개 반복 측정).

기대 효과 (지표별) - 상승 예상: RetrievalRelevance(무관 문서 제거), RetrievalGroundedness(노이즈 감소), Correctness, Completeness - 유지(합격 조건): RetrievalSufficiency — 필터가 정답 문서를 잘못 거르면 ↓. Case 7 대비 ≥ 유지가 합격 기준 - 유지: Safety, RelevanceToQuery

비용·레이턴시 영향 - 검색 라운드당 필터 LLM 1회 호출 추가 (적응 재검색 시 라운드마다 추가, 최대 2회차). 호출 횟수보다 입력 컨텍스트 크기(후보 문서를 한 프롬프트에, 문서당 최대 40k자)가 주된 비용·레이턴시 요인. - 운영 투입 시 §2.1 최종 구성 결정에서 품질 Δ vs 비용·레이턴시 증가의 트레이드오프를 명시적으로 평가.

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	베이스(C5) 대비	판정
RetrievalRelevance	65.0%	≥ 80%	+5.0%p	미달
RetrievalSufficiency	73.0%	≥ 70%	0.0%p (≥ 유지 — 합격)	충족
RetrievalGroundedness	56.0%	≥ 90%	−4.0%p	미달
Correctness	77.0%	≥ 80%	+8.0%p	미달
Completeness	81.0%	≥ 85%	−2.0%p	미달
RelevanceToQuery	100.0%	≥ 80%	+1.0%p	충족
Safety	99.0%	≥ 90%	0.0%p	충족

베이스 = Case 5 (Min-Max, Rerank 제외): Rerank+필터 조합(Case 8-1)이 간섭으로 하락(§7.7)했으므로, 채택 구성의 필터 단독 기여도는 Case 5 대비로 측정합니다.

보조 관찰 지표 (필터 동작 자체의 진단용) - 평균 통과 문서 수: (미기록) / 5개 (낮으면 공격적 필터, 5에 가까우면 필터 영향 미미) - 0개 통과 쿼리 비율: (미기록) % (모든 문서가 걸러진 쿼리 — 너무 높으면 필터 프롬프트 보수화 필요) - 필터 LLM 평균 레이턴시: (미기록) ms (병렬 호출 기준 wall-clock)

해석 Self-RAG 필터가 무관 문서를 제거하면서 Correctness가 +8%p(69→77%) 상승해 본 시리즈 자동 Scorer 최고점에 도달했습니다. 합격 조건인 RetrievalSufficiency는 정확히 유지(±0%p)되어 필터가 정답 문서를 잘못 버리지 않았음이 확인됐습니다. 다만 RetrievalGroundedness(56%, −4%p)는 기대(상승)와 달리 하락했는데, 가변 K(0~5)로 컨텍스트가 줄면서 답변이 검색 문서 밖 일반 지식에 일부 기대는 경향이 섞인 것으로 보입니다 — 목표(90%) 대비 가장 큰 갭이라 §9.2 진단 가이드(근거 강제 프롬프트) 대상입니다.

다음 액션 검색·필터 스택은 Case 8로 고정. Case 9에서는 생성 LLM만 교체해 답변 품질 상한을 탐색할 계획이었으나, 현 단계에서는 보류했습니다 (§7.9). 필터 LLM은 databricks-gpt-5-4-nano로 유지합니다.

---

 

7.9 Case 9 — LLM 교체 (Claude Sonnet 4.6)

측정 상태: 보류(미측정). 현 개발 단계에서는 생성 LLM 교체의 영향도가 낮다고 판단해 측정을 보류했습니다. 최종 채택 생성 LLM은 databricks-gemini-3-flash 유지입니다 (소스 config.yaml llm_endpoint, fallback databricks-claude-sonnet-4-6). 향후 고도화 단계에서 교체 여부를 재검토합니다.

구성 (Case 8 대비 변경점) - 생성 LLM: databricks-gemini-3-flash → databricks-claude-sonnet-4-6 - 검색·필터 LLM(databricks-gpt-5-4-nano)은 Case 8과 완전 동일 — 검색·필터 결과도 동일해야 함 - Top-K: Case 8과 동일 (Self-managed Hybrid top-5 → 필터 → 0~5)

변경 이유 - Gemini 3 Flash는 속도·비용 우위, Claude Sonnet 4.6은 복합 지시 준수·한국어 추론·근거 기반 생성에서 일반적으로 더 높은 품질을 보임. - 실제 사용 프로파일(복합 질문 비중, Groundedness 요구 수준)에 따라 품질·비용 트레이드오프를 정량 확인. - 필터 LLM은 그대로 두므로, 본 케이스의 지표 변동은 순수하게 생성 LLM 교체 효과로 귀속됨.

기대 효과 (지표별) - 상승 예상: RetrievalGroundedness, Correctness, Completeness, RelevanceToQuery - 유지: Safety (두 모델 모두 안전 튜닝 완료) - 반드시 불변이어야 함: RetrievalRelevance, RetrievalSufficiency — 검색·필터는 변하지 않음

MLflow Run - Run ID: (TBD) - Run URL: (TBD)

실측 지표

Scorer	Pass율	목표	Case 8 대비	판정
RetrievalRelevance	(미측정)	≥ 80%	변동 없어야 함	—
RetrievalSufficiency	(미측정)	≥ 70%	변동 없어야 함	—
RetrievalGroundedness	(미측정)	≥ 90%	↑ 기대	—
Correctness	(미측정)	≥ 80%	↑ 기대	—
Completeness	(미측정)	≥ 85%	↑ 기대	—
RelevanceToQuery	(미측정)	≥ 80%	—	—
Safety	(미측정)	≥ 90%	—	—

해석 미측정(보류). 현 단계 사용 프로파일에서 생성 LLM 자체 교체의 기대 이득보다 추가 비용·레이턴시 부담이 크다고 판단했습니다. databricks-claude-sonnet-4-6은 fallback 엔드포인트로 등록해 두어, 향후 본 케이스를 재개할 때 바로 비교할 수 있습니다.

다음 액션 생성 LLM은 databricks-gemini-3-flash로 유지. 자동 Scorer 최고점(C8, 77%)과 현업 정성평가(C10, 80%)로 최종 구성을 확정합니다 (§7.10·§2.3). 생성 LLM 교체는 §9.3 후속 로드맵으로 이월.

---

 

7.10 Case 10 — Human-in-the-loop 현업 교차 검증

목적: MLflow 자동 Scorer(LLM-as-a-Judge)의 한계를 보완하고, 실제 현업이 체감하는 답변 품질을 교차 검증합니다. 자동 Scorer는 일관성·확장성은 좋지만 도메인 맥락·실무 적합성은 사람만큼 정밀하지 못할 수 있어, 자동 평가 최고 구성(Case 8)의 산출물을 사람이 다시 검증했습니다.

구성 - 평가자: 현업/운영팀 3인 - 대상: Case 8 (Self-managed Hybrid + Min-Max + Self-RAG 필터) 결과물 - 판정 기준: 답변별 3인 평가에서 만장일치 통과, 또는 보류 1건 이하일 때 '통과'로 집계 (보수적 기준) - 생성·검색 스택: Case 8과 동일 (새 변수 없음 — 사람 평가 채널만 추가)

변경 이유 — 왜 사람 평가인가 - 자동 Scorer의 Correctness(C8, 77%)가 목표(80%)에 근접했으나, LLM Judge가 놓치는 도메인 뉘앙스·실무 정확성을 사람이 검증할 필요가 있었습니다. - 운영 투입 직전, 현업 체감 품질을 정량 지표로 확보하기 위함입니다.

실측 지표

평가 방식	Correctness(통과율)	목표	비고
보수적 기준 ('통과'만 산입)	80.0%	≥ 80%	충족 — 최종 채택 지표
완화 기준 ('통과 + 보류' 평균 산입)	86.0%	≥ 80%	참고치

실제 서비스 수준을 고려해 보수적 '통과' 단일 기준치(80%)를 최종 성능 지표로 채택했습니다.

해석 - 자동 Scorer 정량 평가(Case 8, 77%)와 현업 정성 평가(Case 10, 80%)가 유사한 수준으로 도출되어, 자동 평가 파이프라인의 신뢰도가 교차 검증됐습니다. - 보수적 기준으로도 목표선(80%)에 도달해, Case 8 구성이 운영 투입 가능한 품질임을 확인했습니다.

다음 액션 (피드백 기반 1차 튜닝) - 정성평가 과정에서 수집한 현업 피드백을 바탕으로 쿼리 재구성·검색 파라미터·시스템 프롬프트를 1차 튜닝한 결과, 치명적인 검색 실패 사례를 3~4건 수준으로 감소시켰습니다. - 추가 품질 제고는 §9.3 후속 로드맵(청킹·Top-K·프롬프트 최적화)으로 진행합니다.

---

 

8. 케이스 간 성능 비교

실측값 기입 원칙 - Scorer Pass율의 1차 입력 위치는 §7.1~§7.10 각 Case 표 - §8.1 전체 누적 추이 표만 예외적으로 크로스 케이스 스캔용으로 값을 집계 기입 - §8.2~§8.8 하위 비교에서는 숫자를 재기입하지 않고 §7.x 표를 참조하여 해석·결정만 기록 - MLflow Experiments UI에서도 측정 완료 Run 비교로 동일한 뷰 확인 가능

 

8.1 전체 누적 추이 (Case 1 → 10)

전체 추이 표는 문서 상단 §2. 실험 결과 요약 섹션을 참조합니다. 본 §8.2~§8.7은 위 표를 근거로 한 하위 비교·해석만 기록합니다 (값을 재기입하지 않음 — single source of truth).

 

8.2 임베딩 선택 (Case 1 vs Case 2)

• 비교 대상 데이터: §7.1 실측 지표 표 ↔ §7.2 실측 지표 표 (특히 RetrievalRelevance, RetrievalSufficiency, Correctness)
• Δ 해석: §7.2 표의 Case 1 대비 컬럼 — Cohere V3는 Qwen3와 대등(RR·Corr 각 −1%p 수준)
• 결론: 임베딩 = databricks-qwen3-embedding-0-6b (Qwen3) 유지. 성능이 대등한 데다 Cohere V3의 짧은 입력 길이 한도가 긴 청크에 부적합, V4는 한국어 성능이 더 낮고 Databricks 미지원.

 

8.3 Hybrid 3종 비교 (Case 3 vs 4 vs 5)

⚠️ 비교의 공정성 조건: 세 케이스 모두 LLM 전달 K=5 동일. 차이는 앞단 구성(Case 3: 단일 Hybrid 호출 K=5 / Case 4·5: FTS·Semantic 각 K′=20 → fuse → top-5)과 결합 방식뿐이며, LLM 컨텍스트 조건은 동일하게 통제됨.

• 비교 대상 데이터: §7.3 ↔ §7.4 ↔ §7.5 실측 지표 표 (RetrievalRelevance, RetrievalSufficiency, Correctness)
• 관찰 포인트:
• Case 3 → 4 (§7.4의 Case 3 대비 컬럼): 컬럼 구조 단순화 효과 (중복 색인 제거 + Self-managed 전환의 총 효과 — §7.4 "아키텍처 전환의 필연성" callout 참조)
• Case 4 → 5 (§7.5의 Case 4 대비 컬럼): 결합 방식 효과 (RRF vs Min-Max)
• 결론: 베이스 Retrieval = Self-managed Hybrid (Kiwi), 퓨전 룰 = Min-Max. Case 3→4 구간이 본 시리즈 최대 검색 개선 구간(중복 색인 제거 + 컬럼 축소). 단일 비교상 RRF(C4)가 Min-Max(C5) 대비 근소 우위이나, Self-RAG 필터가 결합된 최종 파이프라인(Case 8)에서는 RRF 적용 시 지표가 하락하여 Min-Max를 최종 채택 (소스 fusion_method: min_max).

 

8.4 동의어 사전 기여도 (Case 5 vs Case 6)

• 비교 대상 데이터: §7.6 실측 지표 표의 Case 5 대비 컬럼이 동의어 사전 단독 기여도 Δ를 보여줌
• 합격 조건:
• RetrievalRelevance Δ ≥ 0 — 떨어지면 사전에 부정확한 동의어가 들어간 것. 사전 검수 후 재측정.
• RetrievalSufficiency Δ ≥ 0 — 약칭/도메인 용어 쿼리에서 정답 문서 누락이 줄었는지 확인.
• 해석 포인트:
• 둘 다 ↑이면 사전이 잘 구축됨. Case 7 (Rerank) 베이스로 진행.
• Sufficiency↑·Relevance↓ → 사전 커버리지는 좋지만 정밀도 저하. 사전에서 모호한 매핑 제거.
• 둘 다 변화 없음 → 사전 효과 미미. 도메인 용어 비중이 낮거나 사전이 평가 데이터셋과 매칭되지 않음.
• 사전 효과 분해 (보조 진단):
• 동의어 확장이 일어난 쿼리 / 안 일어난 쿼리로 평가 데이터셋 분할 → 두 그룹의 Δ 비교
• 확장 쿼리 그룹에서만 큰 개선이면 효과 입증
• 결론: 동의어 사전 채택 여부 = 미정 (Case 6 평가 보류). 사전 구축은 완료(한국어 RAG 검색 (Kiwi) 시리즈)되었고 인프라(synonym_dir)도 소스에 구현되어 있으나, 평가용 고객 데이터 부족으로 측정만 보류. §2.1 최종 구성에서는 "구현·사전 구축 완료(검증 보류)"로 표기.

 

8.5 Rerank 기여도 (베이스 vs Case 7)

• 비교 대상 데이터: §7.7 실측 지표 표의 베이스(C5) 대비 컬럼이 Rerank 단독 기여도 Δ를 보여줌
• 해석 포인트: Rerank 단독 적용은 검색·생성 지표를 소폭 끌어올렸으나(RR +3%p, Corr +2%p), Self-RAG 필터와 결합 시(Case 8-1) 간섭으로 지표 하락. cross-encoder 재정렬과 LLM 관련성 필터가 같은 정밀도 목적을 중복 수행하며 충돌.
• 결론: Rerank 채택 여부 = 미채택. 단독 이득이 필터와의 간섭을 상쇄하지 못함 + 추가 Latency·비용. 소스에도 미구현(향후 슬롯).

 

8.6 Self-RAG 필터 기여도 (Case 5 vs Case 8)

• 비교 대상 데이터: §7.8 실측 지표 표의 베이스(C5) 대비 컬럼

⚠️ 비교의 공정성 조건: Rerank가 미채택되어 Case 8은 Case 5(Min-Max) 위에 필터만 얹은 구성입니다. Case 5는 K=5 고정, Case 8은 K=0~5 가변(옵션 A)이라 컨텍스트 조건이 다르므로 Pass율 절대값보다 Δ(전후 차이)로 해석합니다. 보조 관찰 지표(평균 통과 문서 수, 0개 통과 비율)는 본 라운드에 미기록 — 필터 동작 진단을 위해 차기 측정 시 기록 권장.

• 합격 조건 충족 여부:
• RetrievalSufficiency Δ ≥ 0 → 충족 (±0%p). 필터가 정답 문서를 잘못 거르지 않음.
• Correctness Δ > 0 → 충족 (+8%p, 본 시리즈 자동 Scorer 최고). 노이즈 제거 효과 입증.
• RetrievalGroundedness Δ > 0 → 미충족 (−4%p). 가변 K로 컨텍스트가 줄며 일반 지식 의존이 일부 섞인 것으로 추정 — §9.2 근거 강제 프롬프트 대상.
• 운영 투입 판단 포인트:
• 품질 Δ(특히 Correctness +8%p) vs 추가 레이턴시·비용 (검색 라운드당 databricks-gpt-5-4-nano 1회 호출 + 적응 재검색 시 추가, 대용량 컨텍스트 입력)
• "0개 통과 쿼리" 비율 모니터링 (미기록 — 차기 측정 시 확보). RELEVANT 0건 시 상위 보충이 동작하므로 빈 컨텍스트는 방지됨
• 결론: Self-RAG 필터 = 채택. Sufficiency 유지하며 Correctness를 최고점으로 끌어올린 핵심 컴포넌트 (소스 use_judge: True).

 

8.7 LLM 교체 영향 (Case 8 vs Case 9)

• 비교 대상 데이터: §7.9 — Case 9는 보류(미측정).

⚠️ 검증 제약(측정 재개 시): RetrievalRelevance · RetrievalSufficiency의 Δ는 ≈0 (변동 없음)이어야 합니다. - 생성 LLM은 검색·필터 결과를 바꾸지 않음 + 필터 LLM도 databricks-gpt-5-4-nano 고정 + Judge LLM은 전 Case 고정(§4 참조) - 변동이 관측되면 평가 데이터셋·Retrieval·필터 스택에 의도치 않은 변화가 섞인 것이므로 측정 전 원인 추적 필요

• 결론: Production 채택 생성 LLM = databricks-gemini-3-flash 유지. 현 단계에서 LLM 교체의 영향도가 낮다고 판단해 Case 9를 보류 (fallback으로 databricks-claude-sonnet-4-6 등록). 교체 평가는 §9.3 후속 로드맵.

 

8.8 Human-in-the-loop 교차 검증 (Case 8 vs Case 10)

• 비교 대상 데이터: §7.8 (자동 Scorer Correctness 77%) ↔ §7.10 (현업 정성평가 Correctness 80%)
• 해석: 자동 평가와 사람 평가가 유사 수준으로 수렴해 자동 Scorer 파이프라인의 신뢰도가 교차 검증됨. 보수적 '통과' 기준으로도 목표선(80%)에 도달.
• 결론: Case 8 구성이 운영 투입 가능한 품질임을 사람 평가로 확정. 현업 피드백 기반 1차 튜닝으로 치명적 검색 실패를 3~4건 수준으로 감소.

---

 

9. 결론 및 후속 계획

 

9.1 결론 요약

본 시리즈의 핵심 결론입니다 — 구성 정본 표는 문서 상단 §2.1 최종 Production 구성 으로 옮겼습니다 ("실험 결과 → 그래서 이렇게 적용" 흐름을 먼저 보여주기 위함).

• 검색 스택: Qwen3 임베딩 + Self-managed Hybrid(Kiwi) + Min-Max 융합 — Case 3→4 구간이 최대 개선폭.
• 품질 정제: Self-RAG 필터([IsRel])로 Correctness를 자동 Scorer 최고점(77%)까지 끌어올리고, [Retrieve] 적응 재검색(max 2회)으로 불충분한 검색을 보완. Rerank는 필터와의 간섭으로 미채택.
• 생성: Gemini 3 Flash 유지(Case 9 LLM 교체 보류).
• 검증: 자동 Scorer 77%(C8)와 현업 정성평가 80%(C10)가 수렴 — 운영 투입 가능 수준으로 확정.
• 잔여 과제: 동의어 사전(구축 완료·평가 보류)과 생성 LLM 교체는 §9.3 후속 실험 로드맵으로 이월.

 

9.2 목표 미달 시 진단 가이드

• 목표 미달 Scorer가 있는 경우 → 본 시리즈 ① 평가 편의 "Scorer별 개선 조치 가이드" 참조
• RetrievalSufficiency 낮음 → 청킹 단위·Top-K·임베딩 모델 재검토
• Correctness 낮지만 RetrievalSufficiency 높음 → 생성 프롬프트 개선, LLM 교체
• RetrievalGroundedness 낮음 → 프롬프트에 근거 강제 문구, temperature 낮춤

 

9.3 후속 실험 로드맵

후속	가설	대상 지표
청킹 단위 변화 (더 작게/크게)	청크 크기가 Sufficiency/Relevance 트레이드오프에 영향	RetrievalRelevance, RetrievalSufficiency
Top-K 민감도 재검증	운영 투입 전 K ∈ {3, 5, 10} 추가 측정으로 K=5가 운영 분포에서도 최적인지 확인	RetrievalRelevance, RetrievalSufficiency
프롬프트 최적화	근거 강제·포맷 규칙 추가	RetrievalGroundedness, Completeness
동의어 사전 (Case 6 재개)	사전은 구축 완료 — 평가용 고객 데이터 확보 후 Case 5 대비 RR·RS Δ 측정 → 채택 여부 확정	RetrievalRelevance, RetrievalSufficiency
Self-RAG 필터 입력 K 확대	필터 입력을 top-5 → top-10·20으로 늘리면 통과 후보가 늘어 Sufficiency 추가 상승 가능	RetrievalSufficiency, Correctness
Self-RAG 필터 LLM 비교	databricks-gpt-5-4-nano vs 타 경량 모델 간 판정 품질·비용 비교	RetrievalRelevance, 비용·레이턴시
생성 LLM 교체 (Case 9 재개)	databricks-claude-sonnet-4-6 등으로 교체 시 Groundedness·Correctness·Completeness 상한 탐색	RetrievalGroundedness, Correctness, Completeness
Guidelines Scorer 도입	사내 답변 규정(금지어·말투·형식) 검증	Guidelines

---

 

📚 시리즈 — RAG 품질

• ① 평가 — MLflow Evaluation 기반 검색·생성 품질 정량 측정
• ② 개선 — 임베딩·하이브리드·Rerank·Self-RAG 단계별 누적 개선 실험 — 현재 글
• ③ 아키텍처 — LangGraph 기반 Agentic RAG 검색 처리 흐름