sy/dev
Paper Review
12 min read

[논문 리뷰] DynaKRAG — multi-hop RAG를 evidence control 문제로 보기

Multi-hop RAG의 병목은 검색 횟수가 아니라 다음 evidence operation을 고르는 제어 정책이다.

DynaKRAG: A Unified Framework for Learnable Evidence Control in Multi-Hop Retrieval-Augmented Generation

Yaqi Wu et al. (2026)- arXiv

arXiv

한 줄 요약

DynaKRAG는 multi-hop RAG를 “검색을 몇 번 할 것인가”가 아니라 현재 evidence state에서 어떤 evidence operation을 실행할 것인가라는 순차 제어 문제로 다시 정의한다.

핵심은 꽤 실용적이다. Multi-hop 질문에서는 첫 검색 결과가 답을 바로 주기보다 다음에 무엇을 찾아야 하는지를 바꾼다. bridge entity가 보일 수도 있고, 현재 query가 틀렸다는 신호가 나올 수도 있고, 이미 답변하기 충분하다는 신호가 생길 수도 있다. 이때 고정 파이프라인으로 retrieve -> rerank -> generate를 반복하는 것은 둔하다. DynaKRAG는 이 선택을 학습 가능한 controller에게 맡긴다.

왜 지금 중요한가

RAG 시스템을 운영하다 보면 “top-k를 늘리면 좋아지겠지”라는 유혹이 강하다. 하지만 multi-hop RAG에서는 더 많은 문맥이 항상 이득이 아니다.

  • 관련 없는 문서가 들어오면 reasoning path가 흐려진다.
  • query rewrite가 필요한데 retrieval만 반복하면 같은 오류를 반복한다.
  • 이미 충분한 근거가 있는데 더 검색하면 latency와 token 비용만 늘어난다.
  • bridge entity를 따라가야 하는 질문과 missing fact를 찾아야 하는 질문은 다른 action이 필요하다.

내 의견으로는 이 논문의 좋은 점은 RAG를 “retrieval 성능” 문제가 아니라 runtime policy 문제로 본다는 데 있다. Agentic RAG를 진짜 제품에 넣으려면 retriever, reranker, generator 각각의 성능보다 “다음 행동을 언제, 왜 고를 것인가”가 더 중요해진다.

기존 adaptive RAG의 한계

논문은 기존 방식들이 query reformulation, evidence critique, sufficiency judging, iterative retrieval 같은 유용한 동작을 이미 갖고 있지만, 대개 특정 방법론 안에 고정된 pipeline으로 묶여 있다고 본다.

문제는 이렇다.

  1. 어떤 시스템은 계속 검색할지는 판단하지만 query rewrite와 경쟁시키지 못한다.
  2. 어떤 시스템은 sufficiency check를 하지만 bridge expansion과 stop action 사이를 함께 조정하지 못한다.
  3. 각 방법이 state 표현과 action schedule을 따로 정의해서, 서로 다른 evidence operation을 같은 기준으로 비교하기 어렵다.

DynaKRAG의 출발점은 이 파편화를 풀자는 것이다. 모든 동작을 하나의 shared evidence state 위에서 실행되는 atomic operation으로 바꾸고, 현재 valid한 action 중 무엇이 가장 유용한지 고르게 한다.

DynaKRAG의 핵심 구조

논문이 제안하는 구조는 크게 세 부분이다.

1. Evidence state

Evidence state는 단순히 “검색된 문서 목록”이 아니다. 논문 설명 기준으로 아래 정보를 포함한다.

  • 원 질문
  • 검색된 문서
  • retrieval frontier
  • query/action history
  • bridge candidate
  • diagnostic feedback

이 state가 중요하다. Multi-hop RAG에서 다음 action은 원 질문만 보고 고를 수 없다. 방금 검색한 문서가 어떤 entity를 열었는지, 어떤 gap을 남겼는지, 이미 충분한지까지 봐야 한다.

2. Atomic evidence operations

DynaKRAG는 heterogeneous RAG 행동을 atomic operation으로 쪼갠다.

  • frontier retrieval
  • query rewriting
  • bridge-entity expansion
  • gap-directed retrieval
  • sufficiency checking
  • stop
  • terminal evidence compression

이 목록에서 눈에 띄는 것은 stop과 sufficiency checking이 first-class action이라는 점이다. 많은 RAG 구현은 “검색을 어떻게 더 잘할까”에는 신경 쓰지만 “이제 그만 검색해도 되는가”를 별도 정책으로 다루지 않는다. 운영 비용 관점에서는 후자가 꽤 중요하다.

3. Validity layer와 learned controller 분리

DynaKRAG의 설계에서 가장 마음에 드는 부분은 action validity와 action utility를 분리한 점이다.

  • validity layer: 현재 state에서 실행 불가능하거나 아직 이른 action을 hard rule로 제거한다.
  • learned controller: 남은 valid action 중 기대 효용이 높은 것을 고른다.

이 분리는 실무적으로도 괜찮은 패턴이다. 모든 것을 LLM/controller에게 맡기면 invalid transition이 생긴다. 반대로 모든 것을 rule로 고정하면 질문별 동적 선택이 어렵다. 규칙은 안전한 action space를 만들고, 학습 정책은 그 안에서 우선순위를 정하는 구조가 더 낫다.

실험 결과에서 봐야 할 숫자

논문 abstract와 본문 표 기준으로, Qwen2.5-7B-Instruct를 사용했을 때 DynaKRAG는 다음 F1을 보고한다.

  • HotpotQA: 0.5998
  • 2Wiki: 0.5340
  • MuSiQue: 0.3061

세 benchmark 모두에서 strongest controlled baseline보다 높다고 보고한다. 특히 2Wiki에서 개선 폭이 크다. 본문 설명 기준으로 Qwen2.5-7B에서는 strongest controlled baseline 대비 HotpotQA +2.88, 2Wiki +7.19, MuSiQue +0.62 F1 point 개선이다.

Ablation도 흥미롭다.

  • learned controller를 uniform-valid policy로 바꾸면 F1이 HotpotQA 4.79, 2Wiki 5.78, MuSiQue 3.96 point 감소한다.
  • sufficiency action을 제거하면 세 dataset 모두에서 성능이 떨어지고 controller가 step cap 쪽으로 밀린다.
  • retrieval cap 실험에서는 검색을 더 많이 허용한다고 항상 좋아지는 것은 아니라고 보고한다.

즉, 이 논문의 메시지는 “operation을 많이 넣자”가 아니다. valid한 operation을 많이 제공하는 것만으로는 부족하고, 그중 무엇을 언제 실행할지 학습해야 한다는 쪽에 가깝다.

실무 RAG 설계로 번역하기

이 논문을 그대로 production에 넣기는 쉽지 않다. support annotation, controller training, benchmark별 환경 구성이 필요하다. 하지만 설계 원칙은 바로 가져올 만하다.

1. RAG loop에 명시적인 state schema를 둔다

많은 RAG 코드는 검색 결과와 대화 기록을 prompt 문자열로만 들고 간다. 이러면 policy를 만들기 어렵다. 최소한 아래 정도는 구조화하는 편이 낫다.

rag-state.ts
type EvidenceState = {
  question: string;
  retrievedDocs: RetrievedDoc[];
  queryHistory: string[];
  actionHistory: EvidenceAction[];
  bridgeEntities: string[];
  missingFacts: string[];
  sufficiency: "unknown" | "insufficient" | "sufficient";
};

이 state가 있어야 “다시 검색”, “query rewrite”, “bridge 확장”, “중단”을 같은 인터페이스에서 비교할 수 있다.

2. 검색 action을 여러 종류로 쪼갠다

retrieve(query) 하나만 있으면 controller가 할 수 있는 일이 적다. 실제로는 아래 action들이 다르다.

  • 원 질문 기반 추가 검색
  • bridge entity 기반 검색
  • 빠진 사실을 겨냥한 검색
  • query rewrite 후 검색
  • 현재 evidence sufficiency 검사
  • 더 이상 검색하지 않고 답변 생성

이들을 같은 tool로 뭉개지 말고, 적어도 내부 action type으로 분리해야 로그와 평가가 가능해진다.

3. “더 검색하기”보다 “그만 검색하기”를 먼저 계측한다

RAG 비용 최적화는 cache나 embedding model만의 문제가 아니다. 언제 멈출지를 모르면 좋은 retriever를 써도 token을 태운다.

운영 지표로는 이런 것들이 필요하다.

  • 질문당 retrieval call 수
  • sufficiency check 후 실제 정답률
  • stop action 이후 hallucination rate
  • 추가 검색 1회당 F1 또는 human rating 개선량
  • retrieval 문서 수 증가에 따른 distractor 오류율

특히 agentic RAG에서는 final answer만 평가하면 부족하다. 중간 action trajectory를 같이 봐야 한다.

한계와 조심할 점

첫째, 논문 결과는 HotpotQA, 2Wiki, MuSiQue 같은 multi-hop QA benchmark 중심이다. 기업 문서 검색, 코드베이스 RAG, customer support RAG로 바로 일반화된다고 보면 안 된다. 실제 업무 문서는 더 지저분하고, 최신성·권한·문서 버전 문제가 섞인다.

둘째, controller training에 필요한 supervision을 어떻게 만들지가 관건이다. 논문은 support annotation과 evidence coverage 변화를 활용하지만, 사내 데이터에서는 이런 annotation이 없는 경우가 많다. 처음에는 learned controller보다 rule + lightweight scorer로 시작하는 편이 현실적일 수 있다.

셋째, terminal evidence compression은 별도 품질 게이트가 필요하다. 압축이 잘못되면 검색은 잘했는데 generator에 전달되는 근거가 망가진다. 이건 RAG 시스템에서 흔한 “중간 단계는 맞았는데 최종 prompt가 졌다” 유형의 실패다.

내 생각

DynaKRAG의 가치는 SOTA 숫자보다 프레이밍에 있다. Multi-hop RAG를 retrieval depth 문제가 아니라 evidence operation control 문제로 보는 순간, 설계해야 할 것이 명확해진다.

  • state를 구조화한다.
  • action space를 명시한다.
  • invalid action은 rule로 막는다.
  • valid action의 우선순위는 데이터로 학습하거나 최소한 로그 기반으로 조정한다.
  • stop/sufficiency를 검색 action만큼 중요하게 다룬다.

Agentic RAG를 만든다면 “검색을 몇 번 할까?”보다 “현재 상태에서 어떤 근거 조작이 가장 값어치 있나?”를 먼저 물어야 한다. 이 논문은 그 질문을 꽤 깔끔한 framework로 만든다.

참고 자료

Comments