에이전트 시리즈 (7): 지식 베이스 통합 — 에이전트가 RAG를 사용하는 올바른 방법

RAG와 에이전트의 만남 — 단순히 "LLM에게 검색창을 주는 것" 그 이상입니다

대부분의 사람들은 다음과 같은 형태의 RAG를 접합니다: 사용자가 질문함 → 지식 베이스(Knowledge Base)에서 검색 → 결과를 프롬프트(Prompt)에 삽입 → LLM이 답변 생성.

이것이 바로 **파이프라인 RAG (Pipeline RAG)**입니다. 작동은 합니다. 하지만 근본적인 문제가 있습니다 — 생각을 하지 않는다는 점입니다.

파이프라인 RAG는 질문이 "WonderBot의 가격은 얼마인가요?"(실제로 KB가 필요한 경우)인지, 아니면 "Python 리스트의 평균을 어떻게 구하나요?"(LLM이 이미 알고 있는 경우)인지와 상관없이 모든 질문에 대해 검색(Retrieval)을 실행합니다. 이는 도구가 하나뿐인 작업자와 같습니다. 어떤 업무가 주어지든 일단 창고에 다녀와야 하는 것과 같습니다.

**에이전틱 RAG (Agentic RAG)**는 이 문제를 해결합니다: 에이전트가 언제 검색할지, 무엇을 검색할지, 그리고 결과가 충분히 좋은지를 직접 결정하게 합니다.

이 글은 세 가지 핵심 역량에 집중합니다:

1. 검색 결정 (Retrieval decision): 이 질문에 정말로 KB 조회가 필요한가?
2. 멀티 KB 라우팅 (Multi-KB routing): 검색이 필요하다면 — 어떤 지식 베이스에서 가져와야 하는가?
3. 품질 게이팅 및 폴백 (Quality gating + fallback): 결과를 얻었다면 — 그것이 충분히 좋은가? 아니라면, 다음 단계는 무엇인가?

파이프라인 RAG vs 에이전틱 RAG: 아키텍처의 차이

Pipeline RAG (항상 검색 수행):
  사용자 질문
    ↓
...

핵심적인 차이점은 다음과 같습니다: LLM은 하류의 텍스트 생성기가 아니라, 컨트롤 센터(Control Center) 역할을 합니다.

데모 1: 파이프라인 RAG vs 에이전틱 RAG

다섯 가지 테스트 질문: 세 가지는 실제로 지식 베이스가 필요하고, 두 가지는 필요하지 않습니다 (일반 상식, 산술).

파이프라인 RAG

def pipeline_rag(question: str) -> dict:
    """Pipeline RAG: 항상 검색 → 삽입 → 생성 수행."""
    docs = unified_retriever.invoke(question)
...

에이전틱 RAG

def agentic_rag(question: str) -> dict:
    """Agentic RAG: 먼저 결정한 후, (선택적으로) 검색 수행."""
    decision = _ask(
...

측정 결과

질문 유형 | 파이프라인 검색 | 에이전틱 검색 | 질문
─────────────────────────────────────────────────────────────────
제품 기능 |    ✓ (3 docs)     |    ✓ (3 docs)    | WonderBot Basic 플랜 — 월간 API 호출 횟수?
...

5개의 질문 모두에 대해 Pipeline RAG가 검색을 수행했습니다. 여기에는 KB (Knowledge Base, 지식 베이스) 콘텐츠가 전혀 가치가 없는 "1024 나누기 32는 무엇인가요?"라는 질문도 포함되었습니다. Agentic RAG (에이전트형 RAG)는 일반 상식 질문 두 개에 대해서는 검색을 올바르게 건너뛰었습니다.

모든 질문이 창고까지 달려가 확인할 가치가 있는 것은 아닙니다.

데모 2: 멀티 지식 베이스 라우팅 (Multi-Knowledge-Base Routing)

실제 기업용 배포 환경에서는 일반적으로 제품 문서, 운영 매뉴얼, 사용자 FAQ 등 여러 개의 지식 베이스를 유지합니다. 질문의 성격에 따라 서로 다른 KB에 속하게 됩니다.

세 개의 지식 베이스

PRODUCT_DOCS = [
    Document(page_content="WonderBot Pro 가격: Basic ¥99/월, Pro ¥299/월, Enterprise 맞춤형."),
    Document(page_content="API 제한: Basic 월 1만 회, Pro 월 10만 회; 초과 사용량은 호출당 ¥0.01로 청구됨."),
...

LangGraph 라우팅 (Routing)

def route_node(state: RoutingState) -> RoutingState:
    """1단계: LLM이 대상 지식 베이스를 선택합니다"""
    decision = _ask(
...

그래프 토폴로지 (Topology)는 최소한의 구조입니다:

route → retrieve → generate

route_node의 출력이 retrieve_node가 어떤 리트리버 (Retriever)를 사용할지 결정합니다.

측정된 라우팅 정확도

6개의 질문 (지식 베이스당 2개씩), 실제 실행 결과:

Expected KB    | Actual Route | Match | Question
─────────────────────────────────────────────────────────────────────
→ product      |  product     |  ✓   | Pro 플랜 월간 가격은? 지원되는 LLM은 무엇인가요?
...

검토할 가치가 있는 두 가지 오라우팅 (Misroute) 사례:

• "데이터는 어디에 저장되나요 / 보안 인증" → ops로 라우팅됨 (product여야 함): LLM이 "데이터 저장"을 제품 기능 대신 인프라/운영 (Infrastructure/Operations)과 연관 지었습니다.
• "우리 회사를 위한 부가가치세(VAT) 인보이스" → ops로 라우팅됨 (faq여야 함): 질문에 포함된 "회사 (company)\

질문: "API 타임아웃(timeout) 문제를 어떻게 해결하나요?" → ops로 라우팅됨, 검색 및 생성됨:

라우팅 대상: ops_kb
답변: API 타임아웃 문제 해결을 위해 다음 단계를 따르십시오:
1. 네트워크 연결이 정상인지 확인하기 위해 LLM 서비스 연결 상태를 점검합니다.
...

KB(지식 베이스) 매칭은 정확했으며, 답변은 ops 문서의 문제 해결 단계를 직접 참조하고 있습니다.

데모 3: 품질 게이팅 (Quality Gating) + 쿼리 재작성 (Query Rewriting) 폴백 (Fallback)

검색(retrieval) 품질이 낮을 때, 저품질 컨텍스트(context)를 바탕으로 맹목적으로 생성하면 잘못된 답변이 만들어집니다. 더 나은 접근 방식은 다음과 같습니다: 쿼리를 재작성(rewrite)하고 다시 시도하는 것입니다.

핵심 흐름 (Core Flow)

retrieve → evaluate_quality
                 ├─ score ≥ 0.6 → generate
                 └─ score < 0.6 and retries < 2 → rewrite_query → retrieve (루프 복귀)

LangGraph 구현

QUALITY_THRESHOLD = 0.6
MAX_RETRIES = 2

...

측정 결과

매우 모호한 세 가지 질문:

원래 질문             | 재시도 횟수 | 최종 품질 | 실행 경로
─────────────────────────────────────────────────────────────────────
"how much does it cost" |    2    |    0.00      | retrieve → eval(0.50) → rewrite → retrieve → eval(0.00) → rewrite → retrieve → eval(0.00) → generate
...

"how much does it cost"에 대한 상세 추적(trace):

원래 쿼리:  "how much does it cost"
  ↓ retrieve  → 백업 / 배포 / 환불 관련 문서 추출 (관련 없음)
  ↓ evaluate  → 품질 점수 0.50 (LLM이 약간의 관련성이 있다고 판단)
...

이 결과는 중요한 교훈을 줍니다: 쿼리 재작성(query rewriting)이 근본적으로 정보가 부족한 질문을 해결할 수는 없다는 점입니다. "how much does it cost"를 "product price range query"로 재작성했을 때 제품명 문맥(context)을 완전히 잃어버렸고, 이로 인해 검색 품질이 개선되기는커녕 더 악화되었습니다.

더 근본적인 해결책은 품질이 지속적으로 낮게 유지될 경우 **명확화 단계 (clarification step)**를 추가하는 것입니다:

# 더 나은 접근 방식: 루프를 도는 대신 사용자에게 명확화를 요청합니다
if state["attempts"] >= MAX_RETRIES and state["quality_score"] < 0.3:
    return "clarify"   # 새로운 노드: "어떤 제품/서비스에 대해 질문하고 계신가요?"라고 요청

이것이 Agentic RAG (에이전트형 RAG)에서의 진정한 과제입니다. 낮은 검색 품질 (low retrieval quality)이 항상 검색 전략의 문제인 것은 아닙니다. 때로는 질문 자체에 정보가 누락되어 있을 수도 있습니다.

Agentic RAG 설계 체크리스트

Agentic RAG 시스템을 구축할 때의 주요 결정 사항들입니다:

검색 결정 레이어 (Retrieval Decision Layer)

• 어떤 질문 유형이 검색을 필요로 하는지 정의 (도메인 특화 지식 vs 일반 지식)
• 모호성을 줄이기 위해 결정 프롬프트 (decision prompt)에 구체적인 경계 사례 (boundary examples) 포함
• 명시적인 skip_retrieval 카테고리 정의: 순수 수학, 코딩 구문, 일반적 사실

지식 베이스 라우팅 레이어 (Knowledge Base Routing Layer)

• 각 지식 베이스 (KB)에 대한 명확한 설명 작성 (유형 + 전형적인 질문 + 경계 사례)
• 라우팅 정확도가 80% 미만인 경우, 퓨샷 예시 (Few-shot examples)를 추가하거나 전용 분류기 (classifier) 사용
• 질문이 여러 도메인에 걸쳐 있는 경우 교차 지식 베이스 (cross-KB) 검색 지원

품질 게이팅 레이어 (Quality Gating Layer)

• 합리적인 임계값 (threshold) 설정 (0.6이 적절한 시작점입니다)
• 최대 재시도 횟수 제한 (보통 2회가 충분합니다 — 그 이후에는 수익 체감의 법칙이 적용됩니다)
• 향후 개선을 위해 모든 재작성 (rewrite) 및 품질 점수를 로그로 기록
• 품질이 지속적으로 낮게 유지될 경우, 환각 (hallucination)을 일으키기보다 사용자 명확화 (user clarification) 단계로 격상

운영 고려 사항 (Production Concerns)

• 문제가 되는 엣지 케이스 (edge cases)를 위해 라우팅 프롬프트에 도메인 특화 예시 추가
• 기본 품질을 향상시키기 위해 하이브리드 검색 (vector + BM25) 고려
• 어떤 질문이 검색을 건너뛰고 어떤 질문이 재작성을 유발하는지 추적 — 이 데이터를 사용하여 반복 개선

요약

다섯 가지 핵심 결론:

1. Pipeline RAG의 문제는 검색(Retrieval)이 아니라 판단력의 부재입니다: 모든 질문에 대해 검색을 실행하는 것은 리소스를 낭비하며, LLM (Large Language Model)을 혼란스럽게 만드는 무관한 콘텐츠를 유입시킵니다.
2. Agentic RAG의 핵심은 LLM-as-scheduler입니다: 검색(Retrieval), 라우팅(Routing), 평가(Evaluation)는 모두 하드코딩된 파이프라인 단계가 아니라 LLM의 결정에 의해 이루어집니다.
3. 단순한 프롬프트만으로는 다중 지식 베이스(Multi-KB) 라우팅 정확도에 한계가 있습니다: 한 문장으로 된 라우팅 프롬프트를 사용할 경우 67%의 베이스라인 성능을 보이는 것이 일반적입니다. 프로덕션 환경에서는 Few-shot 예시나 전용 모델이 필요합니다.
4. 품질 게이팅(Quality gating) + 쿼리 재작성(Query rewriting)이 만능 해결책은 아닙: 극도로 모호한 질문은 오히려 더 나쁜 재작성 결과를 초래할 수 있습니다. 진정한 해결책은 사용자에게 질문하는 것입니다.
5. LangGraph를 사용하면 Agentic RAG를 쉽게 확장할 수 있습니다: 새로운 지식 베이스(KB)를 추가할 때 구조적 변경 없이 새로운 노드 하나와 업데이트된 라우팅 프롬프트만 추가하면 됩니다.

다음 편: 컨텍스트 엔지니어링 (Context Engineering) — 토큰 예산 관리, 동적 컨텍스트 조립, 그리고 128K 컨텍스트 윈도우(Context window)에서 모든 토큰을 효율적으로 사용하는 방법에 대해 다룹니다.

References

• LangGraph Agentic RAG Tutorial
• LangChain RAG Conceptual Guide
• CRAG Paper (Corrective RAG)
• 이 시리즈의 전체 데모 코드: agent-06-agentic-rag

더 유용한 지식과 흥미로운 제품은 저의 Homepage에서 확인하세요.