검색을 추론으로 — Retrieval as Reasoning 논문 정리

arXiv:2605.25480 Retrieval as Reasoning을 GeekNews 요약으로 접하고 정리. 앞 글에서 다룬 Karpathy의 LLM Wiki 패턴이 “그렇게 하면 좋다”는 제안이었다면, 이 논문은 “실제로 더 낫다”를 수치로 보인 쪽임.

RAG가 놓치는 것 — 조각 사이의 관계

RAG의 기본 동작은 문서를 잘게 잘라 벡터로 넣고, 질문과 비슷한 조각 몇 개를 꺼내 붙이는 것임. 문제는 자르는 순간 조각들 사이의 관계가 사라진다는 점.

그래서 여러 문서를 이어야 답이 나오는 멀티홉 질문에 약함. “A가 B에 영향을 주고 B가 C를 바꾼다”를 알려면 A·B·C 조각을 각각 꺼내는 걸론 부족하고, 그 사이의 연결이 필요한데 청크화가 그걸 날려버림.

논문의 발상은 검색을 조각 꺼내기가 아니라 추론 과정으로 보는 것. 읽고 → 링크 따라가고 → 모자라면 다시 검색하며 여러 번 되짚어 답을 맞춰 감.

즉 지식을 미리 그래프로 엮어두고, 에이전트가 그 위를 **탐색(navigation)**하며 답을 구성함.

무엇을 빼면 성능이 얼마나 떨어지는지가 이 논문의 핵심임. F1 손실(HotpotQA / MuSiQue / 2Wiki):

순서: 순회 > 구조 > 교정. 순회가 구조보다 두 배쯤 중요함.

직관과 어긋나는 지점이 여기임. 보통 위키를 만들면 구조(어떻게 잘 엮을까)에 공을 들이는데, 정작 성능을 가르는 건 **에이전트가 답을 만들며 얼마나 읽고 되짚느냐(순회)**였음. 잘 지은 서고보다, 그 서고를 얼마나 부지런히 오가느냐가 더 중요했다는 것.

여기 옮긴 벤치마크·ablation 숫자는 2차 요약(GeekNews)에서 가져온 것임. 방향성은 신뢰하되, 도입 근거로 쓰기 전엔 논문 원문을 직접 확인해야 함. 요약은 요약일 뿐.

앞 글에서 나는 Claude Code memory를 위키처럼 쓴다고 했음. 이 논문이 그 습관에 어디에 힘을 줘야 하는지를 알려줌.

논문은 순회를 답을 만들 때 썼지만, 실무에선 노트를 쓰기 전에 무엇을 읽을지의 규칙으로 가져올 수 있음. 관련 오픈소스(llm-wiki-newsroom)가 이걸 읽기 사다리로 구현했는데, 대략:

쓰기 전에 어디까지 읽나 —
 ① 페이지가 적어둔 의존성
 ② 인덱스(index)
 ③ 빌드가 미리 계산해둔 링크
 ④ 콘텐츠 검색
 ⑤ 위키 전체

핵심은 순서대로 올라가지 않는다는 것. “지금 근거가 모자라다”는 신호가 있을 때만 그 신호가 가리키는 칸으로 바로 감. 매번 전부 읽는(=비싼) 것도, 한 줄만 읽고 쓰는(=얕은) 것도 아닌, 근거 부족에 반응해 탐색을 넓히는 규칙.

내가 memory를 쓰며 막연히 “관련 메모랑 인덱스 먼저 보고 시작”하던 걸, 논문이 “그게 제일 중요한 부분(순회)“이라고 뒷받침해줌. 구조를 예쁘게 짜는 것보다, 쓰기 전에 제대로 읽는 규칙 하나가 더 값질 수 있음.

RAG는 청크를 꺼내 붙임 → 조각 사이 관계가 소실 → 멀티홉에 약함.
Retrieval as Reasoning = 문서를 링크된 위키로 컴파일 + 에이전트가 search/read/link로 순회 추론 + Error Book으로 자가 교정.
벤치마크 우위(멀티홉 +2.0~8.1 F1)보다 ablation이 핵심 — 순회 > 구조 > 교정. 잘 짓는 것보다 잘 오가는 게 중요.
실무 적용: ‘순회’를 쓰기 전 읽기 규칙(근거 부족 신호에 반응하는 단계적 읽기)으로. 단, 벤치마크 수치는 원문 확인 후 인용.

원문: arXiv:2605.25480 · 요약: GeekNews · 구현: llm-wiki-newsroom