Agentic RAG

RAG 시스템이 성숙할수록 성능을 끌어올리는 강력한 방법이 agentic workflow 도입이다. agentic workflow란 RAG 전반에서 여러 LLM을 쓰되 각 LLM이 한 단계씩 책임지게 하는 것이다. 사실 query expansion·prompt rewriting·citation generation에서 이미 본 아이디어다. 이런 compound system은 매우 다양하게 조립할 수 있다.

 

 

1. agentic이 바꾸는 두 가지

보통 LLM은 프롬프트를 넣으면 응답을 뱉는다. agentic system에서는 두 가지가 달라진다. 첫째, 작업이 여러 단계와 의사결정의 연속으로 취급되고 각 단계를 서로 다른 LLM 호출로 완료한다. 둘째, LLM에게 더 다양한 도구 — code interpreter, web browser, RAG라면 참조용 vector database — 접근권을 준다.

그림 1. agentic — 작업을 단계·의사결정으로 나누고, 각 LLM에 외부 도구(코드·웹·벡터 DB) 접근권을 준다.

 

 

 

2. agentic RAG 예시

한 가지 가능한 흐름은 이렇다. 사용자 프롬프트가 먼저 작은 router LLM을 거친다. 이 LLM은 프롬프트가 정말 vector database 호출이 필요한지 판단하도록 특별히 튜닝돼, yes/no만 출력한다. no면 곧장 응답 생성 LLM으로 간다. yes면 검색 후 evaluator LLM이 검색된 문서가 답하기에 충분한지 판단하고, 부족하면 추가 검색을 요청한다. 충분해지면 augmented prompt를 만들어 응답을 생성하고, 마지막으로 별도 LLM이 citation을 추가한다.

그림 2. agentic RAG 예시 — router(검색 필요?) → 검색 → evaluator(충분?) → 응답 생성 → citation LLM.

 

 

 

3. flowchart로 설계하고, 단계마다 다른 모델

여기서 두 가지 핵심이 드러난다. 첫째, agentic system 설계는 본질적으로 flowchart를 그리는 것이다. 각 LLM은 여전히 텍스트를 받아 텍스트를 낼 뿐이지만, 프롬프트 여정에서 하나의 작업만 완료하도록 배치된다. 둘째, 단계마다 같은 LLM을 쓸 필요가 없다 — router·evaluator는 단순·단일 작업이라 빠르고 싼 경량 모델을, 초안 응답엔 더 큰 모델을, citation엔 그 작업에 특화된 모델을 고를 수 있다.

그림 3. agentic = flowchart. 각 LLM은 한 작업만 담당하고, 단계별로 경량/대형/특화 모델을 섞어 쓴다.

 

 

 

4. 대표 패턴 네 가지

Sequential (순차)

출력을 여러 LLM을 거쳐 선형적으로 이동시킨다. 예: 모든 프롬프트가 query parser → query rewriter → citation generator를 차례로 통과. 각 LLM이 한 단계에 집중해 특화된다.

그림 4. Sequential — 출력이 여러 LLM을 선형으로 거친다(parser → rewriter → citation …).

 

Conditional (조건 분기)

LLM이 프롬프트가 어느 경로로 갈지 결정한다. 앞의 router LLM(검색 필요 여부)이 그 예다. 강점이 다른 여러 LLM 중 어떤 모델로 응답을 생성할지 고르는 데도 쓸 수 있다.

그림 5. Conditional — LLM(router)이 프롬프트의 경로를 결정한다.

 

Iterative (반복 루프)

conditional과 비슷하지만 프롬프트를 이전 지점으로 되돌려 loop를 만든다. 예로 기존 코드베이스와 통합되는 코드를 생성한다면 여러 번 시도가 필요할 수 있는데, evaluator LLM이 (code interpreter 도움을 받아) 각 초안을 평가하고 적합해질 때까지 피드백을 준다.

그림 6. Iterative — evaluator LLM이 적합하다고 판단할 때까지 이전 단계로 되돌려 반복한다.

 

Parallel (병렬)

orchestrator LLM이 프롬프트를 여러 독립 작업으로 나눠 각각 다른 LLM에 할당하고, 반대편에서 synthesizer LLM이 결과를 다시 결합한다. 예로 두 논문의 핵심 통찰을 비교한다면, 두 LLM이 각각 요약·평가하고 orchestrator가 결과를 합친다.

그림 7. Parallel — orchestrator가 작업을 분할해 병렬 처리하고, synthesizer가 결과를 결합한다.

 

사고방식의 전환. 단순한 agentic system은 workflow logic을 직접 구현하면 되고, 복잡해지면 이를 돕는 도구·라이브러리·플랫폼이 많다. 핵심은 LLM을 독립 솔루션이 아니라 더 큰 workflow의 modular piece로 보게 된다는 점이다. 그러면 작거나 몇 가지 작업에만 뛰어난 모델도 기꺼이 쓰게 된다 — 담당 부분과 능력이 잘 맞기 때문이다.

 

다음 글은 Module 4의 마지막 — 언제 RAG를 쓰고 언제 파인튜닝(fine-tuning)을 쓸지, 둘을 어떻게 함께 쓸지를 다룬다.