100 lines
9.1 KiB
Markdown
100 lines
9.1 KiB
Markdown
---
|
|
id: context-recall
|
|
title: "Context Recall"
|
|
category: "10_Wiki/Topics"
|
|
status: "draft"
|
|
verification_status: "conceptual"
|
|
canonical_id: ""
|
|
aliases: []
|
|
duplicate_of: ""
|
|
source_trust_level: "B"
|
|
confidence_score: 0.85
|
|
created_at: 2026-06-08
|
|
updated_at: 2026-06-08
|
|
review_reason: ""
|
|
merge_history: []
|
|
tags: ["research", "RAG 아키텍처 및 파이프라인 기초"]
|
|
raw_sources: ["NotebookLM Synthesis"]
|
|
applied_in: ["Ragas Framework (v0.4.3)", "NVIDIA GenerativeAIExamples GitHub Repository", "Galileo Luna-2 Evaluation"]
|
|
github_commit: "v0.4.3"
|
|
---
|
|
|
|
# [[Context Recall]]
|
|
|
|
## 🎯 한 줄 통찰 (One-line insight)
|
|
Context Recall은 지식 베이스 내에 존재하는 정답 관련 정보를 누락 없이 얼마나 완벽하게 검색해냈는지를 측정하는 검색 성능의 '망라성' 지표이다 [1, 2].
|
|
|
|
## 🧠 핵심 개념 (Core concepts)
|
|
- **검색 재현율(Retrieval Coverage)**: 검색 시스템이 중요한 결과나 문서를 놓치지 않고 얼마나 많이 성공적으로 추출했는지를 의미한다 [1, 3].
|
|
- **지상검증(Ground Truth) 기반 평가**: 기준 정답(Reference)을 개별 명제(Claims)로 분해한 뒤, 각 명제가 검색된 컨텍스트에 포함되어 있는지 대조하여 계산한다 [2, 4, 5].
|
|
- **검색 격차(Retrieval Gaps) 식별**: 지식 베이스에는 정보가 실존하지만 검색기가 이를 찾아내지 못하는 지점을 포착하여 시스템의 근본적인 수집 능력을 평가한다 [2, 6].
|
|
- **명제 단위 분석(Claim-level Analysis)**: LLM 기반 Context Recall에서는 기준 정답의 문장들을 논리적 명제 단위로 나누어 검색된 컨텍스트에 귀속(Attribute)될 수 있는지 판단한다 [4, 7].
|
|
|
|
## 🧩 추출된 패턴 (Extracted patterns)
|
|
- **Reference-to-Context Mapping**: 정답 데이터와 검색된 청크 간의 매칭을 통해 수집 품질을 정량화하는 패턴을 보인다 [4, 5].
|
|
- **Adaptive Optimization Loop**: Recall이 낮을 경우 top-K 증가, 부모-자식 청킹 도입, 하이브리드 검색 전환 등의 순차적 해결책을 적용하는 전략적 패턴이 발견된다 [5, 8-10].
|
|
- **Metric-Driven Decision**: Context Precision과 함께 모니터링하여 검색의 노이즈와 커버리지 사이의 트레이드오프를 관리하는 의사결정 패턴을 형성한다 [2, 11, 12].
|
|
|
|
## 📖 세부 내용 (Details)
|
|
Context Recall은 RAG 파이프라인의 검색 단계에서 발생하는 결함을 진단하는 핵심 지표로, 특히 '검색 격차(Retrieval Gaps)'를 잡는 데 특화되어 있다 [6, 13]. 이 지표는 시스템이 정답을 생성하는 데 필요한 모든 정보를 지식 베이스에서 성공적으로 가져왔는지를 0과 1 사이의 점수로 환산하여 나타낸다 [1, 14, 15].
|
|
|
|
**1. 계산 공식 및 방식**
|
|
- **LLM 기반 방식**: 기준 정답 내 명제들 중 검색된 컨텍스트에 의해 지원되는 명제의 수를 전체 명제 수로 나누어 산출한다 [2, 16]. 이는 사람이 직접 컨텍스트를 주석 처리하는 번거로움을 줄이기 위해 기준 정답을 대리인(Proxy)으로 사용한다 [4].
|
|
- **Non-LLM 및 ID 기반 방식**: 검색된 컨텍스트와 기준 컨텍스트 간의 직접적인 문자열 비교나 문서 고유 ID 매칭을 통해 재현율을 계산한다 [10, 14, 15].
|
|
|
|
**2. 지표 저하 시의 원인 진단 및 해결**
|
|
- **Top-K 설정 미흡**: 검색 결과로 반환하는 청크 개수(top-K)가 너무 적어 필요한 정보가 누락될 수 있으며, 이를 해결하기 위해 top-K를 늘리고 재측정해야 한다 [5].
|
|
- **청킹 전략의 한계**: 정보가 문서 전체에 흩어져 있는 경우 단일 청크 검색으로는 한계가 있으며, 소형 청크로 매칭하고 부모 청크를 반환하는 '부모-자식 청킹' 또는 '계층적 분할'이 권장된다 [8, 9, 17].
|
|
- **임베딩 모델의 변별력 부족**: 고유 명사나 전문 용어 등 의미적 검색(Vector Search)이 놓치기 쉬운 키워드는 BM25와 같은 어휘 검색을 결합한 하이브리드 검색을 통해 보완할 수 있으며, 실제 오류를 49%까지 줄인 사례가 있다 [9, 18].
|
|
|
|
**3. 아키텍처 내 역할**
|
|
Context Recall은 검색 성능뿐만 아니라 생성기의 성능을 보장하는 기초 데이터의 질을 평가한다 [19]. 만약 Faithfulness(신뢰성)는 높지만 Answer Relevancy(답변 관련성)가 낮다면, 이는 생성 모델은 정직하나 검색된 컨텍스트 자체가 질문에 답하기에 부족한(낮은 Recall) 상황임을 시사한다 [20].
|
|
|
|
## ⚖️ 모순 및 업데이트 (Contradictions & updates)
|
|
- **API 변동 사항**: Ragas 프레임워크의 Context Recall API는 기존 Legacy 패턴에서 Collection 기반 API로 변경되었으며, 이전 API는 v0.4에서 Deprecated되고 v1.0에서 삭제될 예정이다 [16].
|
|
- **성능 트레이드오프**: Context Recall을 높이기 위해 검색 결과(top-K)를 무리하게 늘리면 검색된 정보의 밀도(Context Precision)가 떨어지는 부작용이 발생할 수 있으므로 두 지표를 균형 있게 관리해야 한다 [11].
|
|
- **LLM 판정의 한계**: Context Recall 측정에 사용되는 LLM 채점관은 위치 편향이나 프롬프트 구문에 민감할 수 있으므로, 임계치 설정 시 실제 인간의 주석과 대조하는 검증이 필요하다 [21].
|
|
|
|
## 🛠️ 적용 사례 (Applied in summary)
|
|
- **Ragas Framework (v0.4.3)**: `ContextRecall`, `NonLLMContextRecall`, `IDBasedContextRecall` 등 다양한 Recall 지표가 구현되어 실제 RAG 평가 도구로 사용되고 있다 [14, 15, 22].
|
|
- **NVIDIA GenerativeAIExamples**: 문서 수집, 전처리, 임베딩 저장으로 이어지는 RAG 파이프라인 구성 요소 중 문서 수집 및 검색 단계의 성능을 평가하는 데 활용된다 [23, 24].
|
|
- **Galileo Luna-2**: 수백 밀리초 미만의 낮은 지연 시간으로 Context Adherence와 함께 Recall 관련 속성을 실시간 평가하는 모델로 적용되어 있다 [25, 26].
|
|
|
|
## ✅ 검증 상태 및 신뢰도
|
|
- **상태:** draft
|
|
- **검증 단계:** conceptual (실제 적용 사례 발견 시 applied/validated로 승격 가능)
|
|
- **출처 신뢰도:** B (Official Documentation / Primary Source via NotebookLM)
|
|
- **중복 검사 결과:** 신규 생성 (New discovery)
|
|
|
|
|
|
## 🔗 관련 문서 링크 (Related document links)
|
|
|
|
### 상위/유사 개념
|
|
- [[RAG 아키텍처 및 파이프라인 기초]]
|
|
- 연결 이유: Context Recall은 RAG 전체 시스템 성능을 좌우하는 핵심 평가 축 중 하나이다 [13, 27].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 검색 시스템이 생성 모델에 제공하는 지식의 완결성을 파악할 수 있다 [7, 28].
|
|
- [[Context Precision]]
|
|
- 연결 이유: 검색된 정보 중 실제 유용한 정보의 비율을 측정하는 Recall의 상호보완적 지표이다 [12, 29].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 검색 효율성과 망라성 사이의 균형점을 찾을 수 있다 [2, 11].
|
|
|
|
### 심층 후속 질문 (Deeper Research Questions)
|
|
- Context Recall 지표를 높이기 위해 top-K를 늘릴 때, 생성 모델의 Context Window 제한과 비용 증가는 어떻게 최적화하는가? [5, 30]
|
|
- 하이브리드 검색(BM25 + Vector) 도입 시 두 검색 결과의 가중치를 어떻게 조정해야 Context Recall 개선을 극대화할 수 있는가? [9, 31]
|
|
- 부모-자식 청킹(Parent-Child Chunking) 아키텍처가 단순 고정 크기 분할 대비 Context Recall을 얼마나 유의미하게 향상시키는가? [9, 17]
|
|
- 기준 정답(Ground Truth)이 없는 실제 운영 환경에서 Context Recall을 대체하여 측정할 수 있는 신호는 무엇인가? [32, 33]
|
|
- LLM 기반 채점 방식에서 발생하는 위치 편향(Position Bias)이 Context Recall 점수 왜곡에 미치는 영향은 어느 정도인가? [21]
|
|
|
|
### 실무 적용 맥락 (Practical Application Contexts)
|
|
- **Implementation:** Ragas 라이브러리를 CI/CD 파이프라인에 통합하여 검색 성능의 변화를 자동 추적할 수 있다 [33, 34].
|
|
- **System Design:** 지식 베이스의 문서 업데이트 주기와 연동하여 최신 정보에 대한 Recall 누수를 방지하는 수집 작업(Scheduled Ingestion)을 설계해야 한다 [30, 35].
|
|
- **Operation / Maintenance:** 사용자 Complaints가 발생할 경우 Faithfulness와 Recall 점수를 대조하여 검색부와 생성부 중 어디를 수정할지 결정한다 [20, 36].
|
|
- **Learning Path:** 기본적인 벡터 검색 구현 후, RAGAS와 같은 프레임워크를 통해 객관적인 성능 지표를 측정하는 법을 익히는 단계에서 필수적이다 [27, 37].
|
|
|
|
### 인접 주변 주제 (Adjacent Topics)
|
|
- [[Faithfulness]]
|
|
- 확장 방향: 검색된 정보가 완벽하더라도(High Recall), 생성 모델이 이를 정확히 반영하는지는 별도의 검증이 필요하다 [7, 38].
|
|
- [[Chunking 전략]]
|
|
- 확장 방향: Recall 성능은 문서를 어떻게 쪼개느냐에 따라 결정적으로 달라지며, 문맥을 보존하는 분할 방식이 Recall 향상의 열쇠이다 [8, 39].
|
|
|
|
## 📝 변경 이력 (Change history)
|
|
- 2026-06-08: Initial draft generated via Datacollector_MAC P-Reinforce engine. |