d01 - 2. AgenticRAG

S1 · Agentic RAG 개관 (이론)

Agentic RAG 실전 (14시간) · Day 1

이 교시는 이론 중심으로 과정 전체를 관통하는 큰 그림 — RAG의 한계, Agentic RAG가 그것을 넘는 방식, 앞으로 쌓아 갈 패턴 지도 — 를 정리한다. 코드는 제어 흐름 차이를 보여 주는 모의 실행이다.

목표

• Naive RAG의 구조적 한계를 구체적으로 짚는다.
• Agentic RAG의 핵심(검색=도구, LLM의 판단·분기·반복)을 정의한다.
• 과정에서 구현할 패턴 지도와 도입 판단 기준을 세운다.

 

1. RAG가 푸는 문제

LLM은 두 가지를 모른다: 학습 시점 이후의 정보(knowledge cutoff)와 공개되지 않은 사내 문서. 모르는 것을 물어도 "모른다" 대신 그럴듯하게 지어내는(환각) 경향이 있다.

RAG(Retrieval-Augmented Generation) 는 답의 근거가 될 문서를 먼저 검색해 프롬프트에 함께 넣고, 그 근거 위에서 답하게 한다.

1. Retrieve — 질문과 의미가 가까운 문서 조각을 검색(단어 일치가 아닌 의미 기반; 원리는 S2).
2. Augment — 검색 결과를 질문과 함께 프롬프트에 주입.
3. Generate — 근거에 기반해 답을 생성.

요점은 모델의 기억이 아니라 검색된 근거 위에서 답하게 만들어 최신성·정확성·출처를 확보하는 것이다.

 

 

2. Naive RAG의 한계

가장 단순한 RAG는 질문 종류와 무관하게 한 번 검색 → 바로 생성하는 고정 파이프라인이다. 구현이 쉽고 많은 경우 충분하지만, '고정'에서 오는 한계가 분명하다.

한계	내용
불필요한 검색	검색이 필요 없는 입력(인사 등)에도 검색 → 비용·지연 낭비
검색 실패에 무방비	결과가 엉뚱해도 그대로 생성 → 그럴듯한 오답(환각)
나쁜 질의 그대로 사용	모호·구어체 질의를 다듬지 않아 적중률 하락
단일 검색의 한계	비교·다단계 질문을 한 번의 검색으로 처리하지 못함
자기 점검 부재	생성한 답이 근거에 충실한지 확인하지 않음

 

본질은 상황에 따라 행동을 바꿀 수 없다는 점이다. 경로가 하나로 고정되어, 그 경로가 막히면 대처할 수단이 없다.

 

3. Agentic RAG — 판단하는 RAG

Agentic RAG는 검색을 고정 단계가 아니라 LLM이 상황에 따라 선택하는 도구로 둔다. 그 결과 매 순간 다음을 스스로 결정한다.

• 지금 검색이 필요한가, 아니면 바로 답할까?
• 결과가 부실하면 질의를 고쳐 다시 검색할까?
• 생성한 답이 근거에 충실한가, 부족하면 다시 만들까?

차이: Naive RAG는 정해진 경로, Agentic RAG는 판단하며 가는 경로다. 구현 관점의 핵심은 조건에 따른 분기와 부족하면 되돌아가는 반복(루프) 이며, 바로 이 부분을 LangGraph로 만든다.

 

4. 제어 흐름 비교 — 모의 실행

아래는 실제 LLM·검색이 아니라 제어 흐름의 차이만 드러내는 순수 파이썬 모의 코드다(키 불필요).

• naive_rag — 무조건 검색.
• agentic_rag — 검색 필요 여부를 먼저 판단하고, 결과가 비면 재검색으로 분기.

세 종류의 질의로 두 방식의 행동 차이를 비교한다.

# ── 아주 단순한 가짜 검색기(실제 벡터 검색 아님) ───────────────────────
def fake_search(query: str) -> str:
    # 등록된 주제어가 질의에 들어 있으면 그럴듯한 근거를 반환한다고 가정
    knowledge = {"연차": "연차는 15일입니다.", "배포": "배포는 카나리 방식입니다."}
    for key, val in knowledge.items():     # 등록된 키워드를 순회
        if key in query:                    # 질의에 키워드가 포함되면
            return val                      #   해당 근거를 반환
    return ""                               # 못 찾으면 빈 문자열

# ── Naive RAG: 질문 종류와 무관하게 '항상' 검색 ─────────────────────────
def naive_rag(query: str) -> str:
    context = fake_search(query)            # 무조건 검색 수행 (불필요해도)
    return f"[검색함] 근거='{context}' → 답변 생성"

# ── Agentic RAG: '검색이 필요한지' 먼저 판단 ───────────────────────────
def agentic_rag(query: str) -> str:
    needs_search = any(k in query for k in ["연차", "휴가", "배포", "장애", "정책", "근무"])  # 검색 필요 여부 판단
    if not needs_search:                    # 인사·일반 질문이면
        return "[검색 안 함] 바로 답변"       #   검색을 건너뜀 (비용 절약)
    context = fake_search(query)            # 필요할 때만 검색
    if not context:                         # 검색이 비었으면
        return "[재검색 필요] 질의를 다듬어 다시 시도"   # 교정 루프로 진입(개념)
    return f"[검색함] 근거='{context}' → 답변 생성"

for q in ["안녕하세요", "연차 정책 알려줘", "외계인 정책은?"]:   # 세 가지 질의로 비교
    print(f"Q: {q}")
    print("  Naive  :", naive_rag(q))       # 항상 검색
    print("  Agentic:", agentic_rag(q))     # 판단 후 행동
    print()

Q: 안녕하세요
  Naive  : [검색함] 근거='' → 답변 생성
  Agentic: [검색 안 함] 바로 답변

Q: 연차 정책 알려줘
  Naive  : [검색함] 근거='연차는 15일입니다.' → 답변 생성
  Agentic: [검색함] 근거='연차는 15일입니다.' → 답변 생성

Q: 외계인 정책은?
  Naive  : [검색함] 근거='' → 답변 생성
  Agentic: [재검색 필요] 질의를 다듬어 다시 시도

 

 

🔍 관찰 포인트

• "안녕하세요" : Naive는 불필요한 검색을 수행하고, Agentic은 건너뛴다.
• "외계인 정책은?" : 자료에 없는 질의. Naive는 빈 근거로 답을 생성한다(환각이 발생하는 지점). Agentic은 [재검색 필요]로 분기해 질의를 다듬을 길을 연다.
• 이 모의의 if 판단을 LLM의 판단으로 대체한 것이 실제 Agentic RAG다(S5부터 LangGraph로 구현).

 

5. 패턴 지도 — 앞으로 만들 것

한 단계씩 쌓아 올릴 전체 그림이다.

            ┌──────────────── 사용자 질문 ────────────────┐
            ▼
   [검색할까? 직답할까?]  ── 직답 ──▶ 답변            (S5: 기본 결정)
            │ 검색
            ▼
   [질의 분류 / 재작성]   ───────────────────────────  (S7: 라우팅·Adaptive)
            ▼
   [검색]  ──▶ [관련성 평가] ── 부적합 ──▶ 재검색/재작성  (S8: CRAG)
            ▼ 적합
   [재순위로 정밀화]      ───────────────────────────  (S9: Rerank)
            ▼
   [답변 생성] ──▶ [환각/근거 점검] ── 미흡 ──▶ 재생성   (S8: Self-RAG)
            ▼ 충분
          최종 답변 ──▶ [평가: RAGAS]                    (S10)

• S5 검색/직답 기본 결정 · S6 create_agent 표준 패턴
• S7 라우팅 + 쿼리 재작성(Adaptive RAG) · S8 자기 교정(CRAG, Self-RAG)
• S9 재순위·하이브리드 · S10 프로덕션(영속성·HITL·스트리밍)·평가 · S11 통합 캡스톤

 

6. 언제 에이전트화할 것인가

에이전트화는 공짜가 아니다. 판단·재시도가 늘수록 지연·토큰·복잡도가 커진다. 따라서 도입은 선택의 문제다.

유리한 경우

• 질문 유형이 다양해 "검색이 필요한지"부터 판단해야 할 때
• 검색 실패가 잦거나 질의 품질이 들쭉날쭉할 때
• 여러 번 찾아 비교·종합해야 하는 질문이 많을 때
• 정확성·근거 충실성이 약간의 비용·지연보다 중요할 때

단순 RAG가 나은 경우

• 항상 검색이 필요하고 질의 형태가 정형화되어 있을 때
• 지연·비용에 매우 민감하고 약간의 오답을 감수할 수 있을 때

원칙: 단순하게 시작하고, 필요한 만큼만 에이전트 로직을 더한다. 이 과정도 그 순서(S5 → … → S11)로 쌓는다.

정리

• LLM의 한계 → RAG → Naive RAG의 한계 → Agentic RAG로 이어지는 큰 그림을 그렸다.
• 핵심은 검색을 도구로 두고, LLM이 분기·반복으로 판단한다는 것이다.
• 다음(S2): 의미 기반 검색을 떠받치는 벡터 데이터베이스(Pinecone) 의 원리를 다룬다.