Agentic Evidence Gathering
Agentic Evidence Gathering은 LLM 에이전트가 쿼리를 분석해 검색 계획을 동적으로 수립하고, 검색 결과를 평가하며 필요하면 추가 검색을 반복 실행해 충분한 증거를 수집하는 자율적인 RAG 방식이다. 고정된 파이프라인 대신 에이전트가 루프 안에서 능동적으로 검색 전략을 조정한다.
핵심 개념
기존 RAG는 쿼리 → 검색 → LLM 생성의 단방향 파이프라인이다. Agentic Evidence Gathering은 LLM이 이 루프의 제어자가 된다. 에이전트는 "지금 가진 정보로 답할 수 있는가?"를 스스로 판단하고, 부족하면 어떤 정보가 더 필요한지 추론해 다음 검색 쿼리를 생성한다.
User Query
│
▼
[LLM] 계획 수립: 어떤 정보가 필요한가?
│
▼
[Tool: Retriever] 검색 실행
│
▼
[LLM] 결과 평가: 충분한가? 다음 단계는?
├── 충분 → 최종 답변 생성
└── 부족 → 파생 쿼리 생성 → 다시 검색
핵심 구성 요소
쿼리 분해 (Query Decomposition)
복잡한 쿼리를 단계적으로 답할 수 있는 서브 쿼리로 분해한다. 각 서브 쿼리는 독립적으로 검색 가능한 단위다.
원본: "2024년 매출이 가장 높은 회사의 CEO는 어느 대학 출신인가?"
분해:
1. "2024년 매출 상위 기업 순위"
2. "{회사명}의 CEO는 누구인가"
3. "{CEO 이름}의 학력"
검색 도구 선택 (Tool Selection)
에이전트는 여러 검색 도구(retriever) 중 현재 서브 쿼리에 가장 적합한 것을 선택한다.
tools = [
Tool(name="vector_search", func=dense_retriever.search,
description="의미 기반 검색. 개념·맥락 설명이 필요할 때 사용"),
Tool(name="keyword_search", func=bm25_retriever.search,
description="정확한 용어·고유명사 검색. 제품명, 인명, 코드 검색에 적합"),
Tool(name="sql_query", func=text_to_sql.query,
description="정형 데이터 조회. 숫자, 날짜, 집계가 필요할 때 사용"),
]증거 평가 (Evidence Assessment)
수집된 문서가 현재 서브 쿼리를 해결하기에 충분한지 에이전트가 판단한다. 충분하지 않으면 다른 쿼리 전략이나 다른 도구로 전환한다.
반복 루프 종료 조건
무한 루프를 방지하기 위한 종료 조건을 명시적으로 설정해야 한다.
- 최대 반복 횟수(max iterations) 초과
- 에이전트가 "충분한 증거 확보" 판단
- 검색 결과가 이전과 동일 (수렴 감지)
구현 패턴
ReAct 패턴
Reasoning(추론)과 Acting(행동)을 번갈아 수행한다. LLM이 Thought → Action → Observation 사이클을 반복한다.
Thought: 먼저 2024년 매출 상위 기업을 찾아야 한다.
Action: vector_search("2024년 연간 매출 상위 기업")
Observation: [검색 결과: 삼성전자 300조, SK하이닉스 ...]
Thought: 삼성전자가 1위다. CEO가 누구인지 찾아야 한다.
Action: keyword_search("삼성전자 CEO 2024")
Observation: [검색 결과: 이재용 ...]
Thought: 이제 이재용의 학력을 검색한다.
Action: vector_search("이재용 학력 출신 대학")
...
Plan-and-Execute 패턴
ReAct와 달리, 에이전트가 실행 전에 전체 계획을 먼저 수립한 뒤 순서대로 실행한다. 계획이 명확한 쿼리에 효율적이다.
# 1단계: 계획 수립
plan = planner_llm.plan(query)
# plan = ["서브쿼리1", "서브쿼리2", "서브쿼리3"]
# 2단계: 순차 실행
evidence = []
for subquery in plan:
results = retriever.search(subquery)
evidence.extend(results)
# 3단계: 증거 기반 답변 생성
answer = answer_llm.generate(query, evidence)다른 RAG 방식과의 차이
| 항목 | 기존 RAG | Agentic Evidence Gathering |
|---|---|---|
| 검색 횟수 | 1회 고정 | 동적 (필요에 따라 반복) |
| 검색 쿼리 | 원본 쿼리 | LLM이 파생 생성 |
| 도구 선택 | 사전 고정 | 동적 선택 |
| 멀티홉 지원 | 제한적 | 자연스럽게 지원 |
| 레이턴시 | 낮음 | 높음 |
장단점
| 항목 | 내용 |
|---|---|
| 장점 | 복잡한 멀티홉 쿼리 처리, 적응적 검색으로 누락 정보 최소화 |
| 단점 | 레이턴시 높음, LLM 호출 횟수 증가로 비용 증가 |
| 단점 | 에이전트 루프의 예측 불가능성, 디버깅 어려움 |
적합한 상황
- 답변에 여러 출처의 정보를 종합해야 하는 복잡한 질문
- 사전에 검색 전략을 고정하기 어려운 동적 환경
- 정확성이 레이턴시보다 훨씬 중요한 도메인 (법률, 의료, 금융 분석)
관련 개념
- Hierarchical Retrieval: 구조화된 계층적 검색 (Agentic보다 예측 가능하고 비용이 낮음)
- Multi-RAG Orchestration: 복수 파이프라인을 조율하는 상위 아키텍처
- RAG Routing: 단일 쿼리의 경로 결정 (Agentic은 다중 쿼리를 동적으로 생성)