LlamaIndex를 이용한 Router Agent 개발: 다중 데이터 소스를 자율적으로 전환하는 에이전트 RAG 구현 방법

기업의 지식 관리(Knowledge Management)에 있어, LLM을 이용한 RAG (Retrieval-Augmented Generation) 도입이 급속도로 진행되고 있습니다. 하지만 단일한 거대 벡터 데이터베이스에서 한 번에 검색을 수행하는 기존의 「Naive RAG」 방식으로는, 사내 규정이나 PC 대여 규칙 등 다종다양한 문서가 혼재하는 경우 검색 노이즈가 증가하여 검색 정밀도 저하나 할루시네이션 (Hallucination, 근거 없는 답변)을 초래한다는 과제가 있습니다.

이 과제를 해결하는 획기적인 접근법이 LlamaIndex를 이용한 **「Router Agent (에이전트 RAG)」**입니다. 도메인별로 인덱스를 분할하고, 사용자의 질문을 LLM이 분석하여 최적의 지식 소스(Knowledge Source)를 자율적으로 선택·실행하게 함으로써 검색 정밀도를 비약적으로 향상시킬 수 있습니다. 본 기사에서는 LlamaIndex를 이용한 Router Agent의 구축 방법과 외부 지식을 효율적으로 도입하기 위한 구현 로드맵을 해설합니다.

Router Agent를 구축함에 있어 이해해 두어야 할 주요 컴포넌트는 다음 4가지입니다.

• QueryEngine: 각 데이터 소스(취업 규칙, PC 대여 규칙 등)에 대해 개별적으로 구축된 RAG 검색 엔진입니다.
• QueryEngineTool: 쿼리 엔진을 에이전트용 「도구 (Tool)」로 캡슐화하는 클래스입니다. LLM이 자율적으로 선택할 수 있도록 도구의 역할을 「설명 (description)」으로 기술합니다.
• OpenAIAgentWorker: OpenAI의 Function Calling 기능을 이용하여, 어떤 도구를 어떤 인자(Argument)로 호출해야 하는지에 대한 「자율적인 사고」를 관리하는 추론 모듈입니다.
• AgentRunner: 에이전트의 상태 관리나 사용자와의 대화 루프를 컨트롤하는 실행기입니다.

자율적으로 데이터 소스를 전환하는 에이전트 RAG는 다음 4가지 단계로 구현합니다.

1. 성질이 다른 문서(취업 규칙 PDF나 PC 대여 규칙 텍스트 등)를 각각 개별적으로 읽어 들여, 개별적인 벡터 인덱스 (VectorStoreIndex)로 구축합니다.
2. 작성한 각 인덱스로부터 자연어로 질의가 가능한 QueryEngine을 생성합니다.
3. 각 쿼리 엔진을 도구로 변환합니다. 이때, description에 상세한 역할을 기재하는 것이 매우 중요합니다. LLM은 이 설명을 읽고 사용자의 질문에 대해 어느 도구를 사용해야 할지 판단합니다.
4. OpenAIAgentWorker에 도구 군을 전달하고, AgentRunner로 에이전트를 기동합니다. 이를 통해 사용자의 질문에 응하여 자율적으로 소스를 전환하며 답변하는 대화 에이전트가 완성됩니다.

다음은 LlamaIndex (v0.10.x 이후)를 이용한 Router Agent의 구체적인 구현 예시입니다.

import os
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex, Settings
from llama_index.llms.openai import OpenAI
...

구축한 Router Agent를 실무 수준으로 스케일 업하여, 보다 복잡한 사내 문서나 방대한 지식 베이스에 대응하기 위해서는 효율적으로 외부 지식을 도입하기 위한 접근법이 필요합니다.

취업 규칙이나 신청 절차서와 같은 기업 문서는 PDF 형식으로 기술되어 있는 경우가 많으며, 그 안에는 도표나 복잡한 레이아웃이 포함되어 있습니다. 단순히 텍스트로서 추출하면 문서의 구조가 무너져 검색 정밀도가 현저히 저하됩니다. 이 과제에 대해서는 LlamaIndex 공식에서 제공하는 **LlamaParse**를 이용합니다. 데이터를 Markdown 형식으로 파싱한 후 인덱스화함으로써, 도표나 헤더의 구조를 유지한 고품질의 지식 소스를 구축하여 에이전트의 이해도를 향상시킬 수 있습니다.

등록하는 도구의 수가 「경비 정산」, 「보안 규정」, 「출장 신청」 등 수십 개 이상으로 늘어나면, 모든 도구의 설명을 LLM의 컨텍스트 (Prompt)에 포함할 수 없게 됩니다. 이는 API 비용의 증가나, LLM이 망설여 적절한 선택을 하지 못하게 되는 정밀도 저하를 초래합니다. 이 경우에는 LlamaIndex의 ObjectIndex

**기능을 사용합니다. 도구(Tool) 자체를 벡터 인덱스(Vector Index)화함으로써, 사용자의 질문과 친화성이 높은 '상위 몇 개의 도구'만을 동적으로 가져와 LLM에 전달하는 구성으로 만들 수 있습니다.

보다 복잡한 자율형 RAG, 예를 들어 "검색 결과가 불충분할 경우, 검색 쿼리를 다시 작성하여 다른 도구로 재실행하는" 것과 같은 "자기 수정 루프 (Self-correction loop)"를 포함하는 고도화된 에이전트를 구축하고 싶은 경우가 있습니다. 이처럼 복잡한 상태 관리(State management)나 반복 처리를 제어하고 싶을 때는, LlamaIndex의 데이터 연결 기능과 상태 관리 프레임워크인 **LangGraph**를 협조시키는 설계가 강력한 해결책이 됩니다.