검색은 저렴하다, 코드를 보여줘: 실행 가능한 다중 홉 추론을 위한 Retrieval-Augmented Generation

다중 홉 QA는 여러 소스에서 증거를 차례로 연결해야 하는 문제이다. 자유형 텍스트로 중간 결과를 다루는 기존 방법은 중간 상태의 불투명성, 엔티티 드리프트, 자체 평가에 의한 잘못된 피드백 문제를 겪는다. PyRAG는 다중 홉 추론을 실행 가능 프로그램으로 형상화하여 중간 상태를 명시적으로 노출하고, 실행에서 얻는 deterministic 피드백으로 self-reflection의 한계를 제거하며, 실행 시점에 필요한 검색 범위를 조정하는 실행 기반 규칙을 가능하게 한다.

다중 홉 QA는 단계별 계산으로 구성된다. 기존 방식은 중간 상태를 텍스트로만 유지해 추론의 재현성과 검증이 어렵다. PyRAG는 이를 코드로 표현하고 실행하는 구조로 바꿔 각 단계의 결과를 변수로 보존하고, 실행 결과를 통해 결정적 피드백을 얻어 drift를 줄인다. 또한 plan이 컴파일-수정 루프를 거치며 점진적으로 개선되므로, 오탐이나 엔티티 drift를 감독 가능하게 만든다. 코드 기반 인터페이스는 증가하는 retrieval 필요 여부에 따라 실행 시점에 증거를 보강할 수 있도록 해준다.

세 가지 에이전트가 작동한다: Decomposition Agent는 입력을 atomic sub-queries로 분해한다. Plan Agent는 retrieve()와 answer() API를 이용해 실행 가능한 Python 프로그램 π를 합성한다. Execute 단계에서 π를 Python 인터프리터에서 한 단계씩 실행하고, 각 단계는 retrieval 또는 QA를 수행한다. 실행 중 오류가 나면 Compiler-Grounded Self-Repair를 통해 π를 수정하고 재실행하며, 중간 결과의 불충분한 증거가 감지되면 Execution-Driven Adaptive Retrieval로 일부 단계의 top-k를 확장한다. 증거가 충분히 확보되면 Answer Agent가 최종 답을 도출한다.

훈련 없이도 PyRAG는 5개 벤치마크에서 Vanilla RAG 대비 평균 EM을 올리고, 특히 2WikiMultihopQA와 Bamboogle에서 큰 이득을 보였다. 훈련 없는 설정에서 Qwen2.5-7B-Instruct 기준 평균 EM은 30.8로, Vanilla RAG 대비 +11.8 향상을 보였고, Bamboogle에서 +25.5의 개선을 달성했다. 72B 규모에서 평균 EM은 40.9로 증가했다. RL-finetuning(Pyrag-RL) 버전은 평균 EM 39.2로 다른 RL 기반 방법들보다 상회했고, Qwen3-4B 및 LLaMA-3.1-8B에서도 일반화 성능이 입증되었다(36.3, 40.9 평균 EM respectively). HotpotQA와 MuSiQue에서도 경쟁력 있는 성능을 보였다.

PyRAG는 Decompose/Plan/Execute의 3에이전트 구조를 채택한다. Plan 에서는 retrieve(query, topk)와 answer(query, docs) API를 이용해 실행 가능한 Python 프로그램을 합성한다. 실행은 Python Interpreter에서 단계별로 수행되며, 각 단계의 중간 결과는 env에 변수로 바인딩된다. 실행-기반 보강으로 증거가 부족한 경우 top-k를 높여 재검색하고, 컴파일-수정 피드백으로 코드의 구문/런타임 오류를 수정한다. RL 파인튜닝으로 에이전트의 질의 전략이 개선되며, 전체 파이프라인의 합리성과 비용-효율성을 동시에 향상시킨다.

창출된 실행 흐름의 한계로는 검색재현성의 한계, 검색 기억력의 품질 의존성, 정밀한 증거 기반 grounding의 어려움, sentinel 기반 adaptive retrieval의 brittleness, under-decomposition 시나리오에 대한 취약점 등이 있다.