14.4 RAG 오케스트레이션: 라우팅 및 에이전트

하이브리드 검색, 재순위화(Re-ranking), 쿼리 변환과 같은 고급 검색 기술을 마스터한 후의 다음 과제는 이 모든 컴포넌트들을 조율하는 시스템을 구축하는 것입니다. 이를 RAG 오케스트레이션 (RAG Orchestration) 이라고 합니다.

프로덕션 환경에서는 모든 쿼리를 모든 검색 파이프라인에 무조건 실행할 수 없습니다. 이는 너무 비용이 많이 들고 느립니다. 사용자의 의도(Intent)에 따라 무엇을 해야 할지 결정하는 지능적인 컨트롤러가 필요합니다.

1. 쿼리 라우팅 (Query Routing)

쿼리 라우팅은 들어오는 쿼리를 분류하여 가장 적절한 검색 파이프라인이나 데이터 소스로 안내하는 프로세스입니다.

모든 쿼리가 동일하게 생성되는 것은 아닙니다:

“프랑스의 수도는 어디인가요?” -> 검색이 필요 없음 (모델의 파라미터 지식 활용).
“어제 내 계좌 잔액이 얼마였지?” -> SQL 데이터베이스 쿼리 필요.
“XJ-992 에러는 어떻게 고치나요?” -> 기술 매뉴얼에 대한 벡터 검색 필요.

LLM 기반 라우팅

쿼리를 라우팅하는 가장 유연한 방법은 작고 빠른 LLM을 라우터로 사용하는 것입니다. LLM에게 사용 가능한 도구/소스 목록을 제공하고 어디로 가야 할지 결정하는 JSON을 출력하도록 요청합니다.

import json
from openai import OpenAI

client = OpenAI()

def route_query(query: str) -> dict:
    prompt = f"""
    Classify the following user query and route it to the best source.
    Available sources:
    1. 'parametric': For general knowledge questions the model already knows.
    2. 'vector_db': For technical documentation, manuals, and guides.
    3. 'sql_db': For structured user data like balances, order history.
    
    Query: "{query}"
    
    Output JSON in this format: {{"source": "source_name", "reason": "why"}}
    """
    
    response = client.chat.completions.create(
        model="gpt-4o-mini", # 라우팅을 위해 빠른 모델 사용
        messages=[{{"role": "user", "content": prompt}}],
        response_format={{"type": "json_object"}}
    )
    
    return json.loads(response.choices[0].message.content)

# 실행 예시
print(route_query("포털에서 비밀번호를 어떻게 재설정하나요?"))
# 출력: {'source': 'vector_db', 'reason': 'Asking for instructions in the documentation.'}

라우팅은 단순 분류가 아니라 예산 배분 문제다

실제 프로덕션에서 라우팅은 의미 분류만의 문제가 아닙니다. 지연 시간, 비용, 신뢰도, 권한까지 함께 판단하는 운영 정책의 문제입니다.

모델 파라미터 지식으로 바로 답하면 빠르지만, 빠르게 바뀌는 사실에는 위험할 수 있습니다.
SQL 경로는 정확할 수 있지만, 사용자가 인증되어 있고 필요한 필터를 제대로 제공했을 때만 안전합니다.
벡터 검색 경로가 적절해 보여도, retrieval budget과 evidence quality가 충분하지 않다면 오히려 낭비일 수 있습니다.

좋은 오케스트레이터는 질의의 주제 만이 아니라, freshness 요구사항, 접근 권한, 예상 latency, 그리고 clarification 없이 답해도 되는지 같은 운영 정책 까지 함께 보고 라우팅합니다.

2. 컨텍스트 관리 및 “Lost in the Middle” 현상

문서를 검색한 후에는 이를 LLM의 컨텍스트 윈도우에 맞춰야 합니다. 그러나 단순히 가능한 한 많은 문서를 밀어 넣는 것은 성능 저하로 이어집니다.

”Lost in the Middle” 현상 [1]

연구에 따르면 LLM은 컨텍스트 윈도우의 맨 처음과 맨 끝에 있는 정보를 가장 잘 활용합니다. 가운데에 배치된 정보는 무시되거나 잊혀지는 경우가 많습니다.

컨텍스트 관리를 위한 모범 사례:

순위 인식 배치 (Rank-Aware Placement): 가장 관련성이 높은 문서(재순위화 점수가 가장 높은 문서)를 컨텍스트 윈도우의 처음 과 끝 에 배치하고, 가운데에는 배치하지 마십시오.
정보 밀도 (Information Density): 검색된 청크를 생성 모델에 제공하기 전에 요약하여 압축하십시오.
동적 절단 (Dynamic Truncation): 윈도우를 억지로 채우기보다는 관련성 임계값을 충족하면 문서 추가를 중단하십시오.

컨텍스트 조립도 하나의 정책 계층이다

그래서 강한 RAG 시스템은 컨텍스트 조립을 단순 연결(concatenation) 단계로 보지 않습니다. 오케스트레이터는 다음과 같은 결정을 내릴 수 있습니다.

먼저 짧은 answer-first summary를 두고, 뒤에 근거 문서를 붙인다
구조화된 사실과 자유 서술 문단을 분리해서 넣는다
서로 모순되는 문서는 나란히 두고 비교하도록 명시한다
툴 결과나 대화 상태를 위해 컨텍스트 일부를 비워 둔다

즉, 오케스트레이션은 retrieval 결과를 실제로 쓸 수 있는 프롬프트 예산으로 바꾸는 단계입니다.

3. 에이전틱 RAG (Agentic RAG): 선형 파이프라인을 넘어

전통적인 RAG는 검색(Retrieve) -> 증강(Augment) -> 생성(Generate)의 선형적인 파이프라인입니다. 에이전틱 RAG (Agentic RAG) 는 첫 번째 시도가 불충분할 경우 LLM이 추가 정보를 검색하기로 결정할 수 있는 루프를 도입합니다.

ReAct 프레임워크 (Reasoning + Acting)

에이전트는 사고(Thought), 행동(Action), 관찰(Observation) 의 루프를 사용합니다.

사고: “2024년 선거에서 누가 이겼는지 알아내야 해.”
행동: search("2024 election winner")
관찰: “후보자들은 보여주지만 최종 승자는 나와 있지 않음.”
사고: “인증 뉴스를 확인해야겠어.”
행동: search("2024 election certification")

이를 통해 시스템은 단일 검색 단계로는 처리할 수 없는 복잡한 다단계 문제를 해결할 수 있습니다.

에이전틱 RAG에는 중단 조건이 필요하다

에이전틱 retrieval loop는 강력하지만, 중단 조건이 없으면 비용이 큰 실패 증폭기로 바뀌기 쉽습니다. 실무적인 오케스트레이터는 보통 다음에 상한을 둡니다.

최대 retrieval 라운드 수
전체 토큰 또는 tool budget
답을 내놓을지, 한 번 더 찾을지, clarification을 물을지에 대한 confidence threshold
사람에게 넘기거나 fallback workflow로 전환하는 조건

여기가 보기 좋은 데모와 실제 운영 가능한 시스템의 차이입니다. 오케스트레이션 계층은 “더 찾아볼까?”만 결정하는 것이 아니라, 언제 검색을 멈추고 아직 grounding이 부족하다고 인정할지도 결정합니다.

4. 요약

RAG 오케스트레이션을 통해 우리는 정적인 파이프라인에서 동적이고 지능적인 시스템으로 나아갑니다. 쿼리 라우팅을 구현함으로써 비용을 절감하고 지연 시간을 줄입니다. 컨텍스트 관리를 이해함으로써 “Lost in the Middle” 함정을 피합니다. 그리고 에이전틱 RAG를 수용함으로써 모델이 복잡한 다중 홉 문제를 자율적으로 해결할 수 있도록 합니다.

다음 섹션에서는 구조화된 검색의 궁극적인 형태인 GraphRAG 를 탐구하며, 텍스트 청크를 넘어 지식 그래프의 관계를 탐색하는 방법을 알아봅니다.

Quizzes

Quiz 1: RAG 시스템에서 Query Routing(쿼리 라우팅)을 구현할 때 얻을 수 있는 가장 큰 이점은 무엇인가?

모든 쿼리를 비용이 많이 드는 모든 검색 파이프라인에 실행하는 대신, 사용자의 의도에 따라 가장 적절한 특화된 소스로 쿼리를 안내(또는 검색 생략)함으로써 비용을 절감하고 지연 시간(latency)을 줄일 수 있습니다.

Quiz 2: “Lost in the Middle” 현상이 무엇인지 설명하고, 이를 컨텍스트 관리에서 완화하는 방법을 서술하시오.

“Lost in the Middle” 현상은 LLM이 긴 컨텍스트 창의 중간에 위치한 정보를 무시하거나 잊어버리고, 맨 앞과 맨 끝에 있는 정보를 가장 잘 활용하는 경향을 말합니다. 이를 완화하기 위해 가장 관련성이 높은 문서를 컨텍스트 창의 맨 앞과 맨 끝에 배치하거나, 정보를 요약하여 밀도를 높이거나, 임계값을 충족하면 문서 추가를 중단하는 동적 절단(dynamic truncation)을 사용할 수 있습니다.

Quiz 3: Agentic RAG는 전통적인 선형 RAG 파이프라인과 어떻게 다른가?

전통적인 RAG는 검색 -> 보강 -> 생성의 엄격한 선형 파이프라인을 따릅니다. 반면 Agentic RAG는 LLM이 추론(예: ReAct 프레임워크)을 통해 첫 번째 시도가 불충분할 경우 더 많은 정보를 검색하거나 다른 도구를 사용하기로 결정할 수 있는 루프를 도입하여, 복잡하고 여러 단계가 필요한 문제를 해결할 수 있게 합니다.

Quiz 4: 일반적인 벡터 DB가 아닌 특화된 SQL 도구를 호출하도록 결정하는 LLM 라우터의 확률론적 분류 논리를 수식으로 정식화하고, 논리적 라우팅 임계값을 규정하시오.

라우터는 불연속 도구 $T \in \{SQL, Vector, Parametric\}$ 에 대한 의도 분류 문제를 해결합니다. 임베딩된 질의 $E(Q)$ 와 도구별 학습 벡터 $w_T$ 를 사용하여 소프트-로짓(Soft-logits) 확률을 도출합니다: $P(T=SQL | Q) = \frac{\exp(w_{SQL}^T E(Q))}{\sum_{T'} \exp(w_{T'}^T E(Q))}$ . 시스템은 $P(T=SQL | Q) \ge \theta_{threshold}$ 임계값을 만족하고 동시에 논리적 구조 파라미터들이 정상적으로 파싱되었을 때만 SQL 툴 파이프라인을 호출합니다. 이러한 정식화는 엔지니어들이 임계값 설정을 통해 환각에 의한 불필요한 고비용 도구 호출을 방지할 수 있게 돕습니다.

References

Liu, N. F., et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172.