검색 엔진 없이 Deep Search RL하기

들어가며

검색 에이전트를 강화학습(RL)으로 훈련하려면 수많은 rollout이 필요합니다. Rollout은 모델이 하나의 질문에 답하기 위해 검색하고 최종 답을 내놓는 한 번의 시도입니다. 하지만 실제 검색 API는 호출 비용과 rate limit 때문에 학습의 병목이 됩니다.

그래서 저희는 학습 중 외부 검색 서비스를 호출하는 대신, 약 100만 편의 논문으로 로컬 검색 환경을 만들었습니다. 이 글에서 말하는 “검색 엔진 없이”는 이런 방식을 뜻합니다.

처음으로 시도한 환경인 SearchGym에서는 실제 검색 성능이 오르지 않았지만, 검색 공간과 질문을 다시 설계한 Simulated Scholar Search(S3)에서는 생물학 논문 검색과 Google Search 모두에서 성능이 향상됐습니다.

이 글에서는 검색에 RL이 필요한 이유, 첫 번째 시뮬레이션이 실패한 원인, 그리고 실제 검색으로 전이되는 환경을 설계한 과정을 공유합니다.

S3의 검색 환경, 질문 생성, 평가 어댑터, 학습 통합 코드는 GitHub 에 공개했습니다. 학습에 사용한 데이터셋과 checkpoint는 Hugging Face 컬렉션 에서 보실 수 있습니다.

검색은 왜 RL 문제인가

검색은 본질적으로 연속적인 의사결정 과정입니다 [1]. 모델은 무엇을 모르는지 판단해 쿼리를 만들고, 검색 결과를 바탕으로 다시 검색할지 멈출지 결정합니다. 각 선택의 성패는 최종 답을 얻은 뒤에야 알 수 있습니다. 따라서 검색을 학습시킨다는 것은, 이렇게 뒤늦게 도착하는 신호로부터 앞선 행동을 교정하는 일이 됩니다.

학습 방법은 크게 지도 미세조정(Supervised Fine-Tuning, SFT)과 RL 둘로 나눌 수 있습니다. SFT는 잘하는 모델이 남긴 궤적(trajectory)의 표면적인 행동을 따라 하게 만듭니다. 하지만 그 행동이 왜 옳았는지, 결과가 나빴을 때 어떻게 되돌려야 하는지에 대한 학습이 어렵습니다. 모델은 스스로 만들어낸 검색 결과 위에서 다음 수를 정해야 하는데, 고정된 궤적만 학습한 SFT 모델은 그런 상황을 겪어본 적이 없어 한 번 길을 잘못 들면 좀처럼 되돌아오지 못합니다.

RL은 이 점이 다릅니다. 모델이 직접 검색하고 그 결과로 답의 성패까지 겪게 하여, 언제 다시 검색하고 어떻게 쿼리를 고쳐 되돌아올지를 학습시킵니다.

기존 연구 결과도 이를 뒷받침합니다. Search-R1에서 검증된 궤적으로 SFT한 모델은 7개 QA 데이터셋의 평균 정답 일치율(Exact Match, EM)이 0.207에 그쳤습니다. RL로 학습한 모델(0.431)은 물론, 검색 결과를 한 번 제공해 답하게 한 단순 RAG(0.304)보다도 낮았습니다 [2].

R1-Searcher에서도 같은 base model로 SFT와 RL을 비교했을 때 RL이 평균 약 10%p 앞섰습니다. 이 연구는 정답이 응답에 포함됐는지를 측정하는 CEM(Cover Exact Match)을 사용했습니다 [3].

차이는 검색의 타이밍과 판단에서 나타났습니다. SFT 모델은 자신 본래 가진 지식에 지나치게 기대는 탓에, 그 기억이 틀렸을 때조차 검색하지 않고 잘못된 답을 내놓았습니다.

저희 역시 검증된 궤적으로 SFT를 시도했지만 같은 벽에 부딪혔고, 실패 복구와 검색 중단 판단까지 가르치려면 고정된 궤적을 모방하는 것만으로는 부족하다고 판단했습니다.

Search RL의 병목은 검색 엔진이다

저희는 Search RL을 대규모로 수행한 DR Tulu를 베이스라인으로 검토했습니다 [4]. DR Tulu는 8B 모델에 웹 검색과 페이지 열람 도구를 제공하고, 여러 자료를 종합한 장문 답변을 만들도록 RL로 학습한 공개 Deep Research 시스템입니다. 학습이 진행되면서 모델이 새로 발견한 정보를 평가 기준에 반영하는 것이 특징입니다.

이 방식은 모델이 Google Search로 문제를 푸는 rollout을 반복해야 하므로, 검색 비용과 API 처리량이라는 두 가지 병목이 생깁니다.

검색할 때마다 비용이 발생한다

DR Tulu의 최종 학습은 4,000 step 동안 약 102만 개의 rollout을 생성했고, rollout 하나당 평균 3~4회의 tool call을 사용했습니다. Google Search의 정확한 비중은 공개되지 않았지만, Serper API를 1,000회당 1달러로 계산하면 검색 비중에 따라 한 번의 training run에 수백에서 수천 달러가 필요합니다. 여러 실험과 ablation을 반복하면 비용은 계속 누적됩니다.

더 큰 문제는 rate limit이다

비용보다 더 근본적인 문제는 외부 API의 처리량입니다. RL rollout은 대규모로 병렬화되지만, 검색 API가 허용하는 동시 요청 수와 초당 처리량에는 상한이 있습니다.

DR Tulu는 asynchronous tool calling과 caching으로 대기 시간을 최대한 효율화했지만, 저자들은 다음과 같이 보고했습니다.

“Increasing compute did not improve RL training speed, due to being limited by API rate-limits during rollouts.” - Appendix G.2 Further Training Details

즉 GPU를 더 투입해도 학습 속도가 빨라지지 않았습니다. 병목이 model inference가 아니라 외부 API에 있었기 때문입니다. 그 결과, 최종 학습은 4,000 step을 수행하는 데 70일이나 소요되었습니다.

정리하면, 실제 검색 엔진/API 기반 Search RL은 호출 횟수에 따라 비용이 증가하고, 외부 API의 처리량 때문에 compute를 추가하더라도 학습 속도를 충분히 높이기 어렵습니다. 전체 학습 시스템의 확장성을 결정하는 것은 모델만이 아니라, 모델이 상호작용하는 검색 엔진이 됩니다.

그렇다면 모델에게 검색을 가르치기 위해 반드시 실제 검색 엔진을 사용해야 할까요?

검색 엔진 없이 Search RL하기

저희의 가설은 검색 도구가 달라도 모델이 익혀야 할 의사결정 구조는 같다는 것이었습니다.

Google Search, Semantic Scholar, 사내 문서 검색은 서로 다른 문서와 결과를 보여줍니다. 하지만 모델이 반복하는 일은 같습니다. 질문에서 부족한 정보를 찾고, 이를 쿼리로 표현하고, 검색 결과를 읽어 다음 검색을 계획하며, 충분한 근거를 모으면 멈춥니다.

그렇다면 이 과정을 연습하는 동안 검색 결과를 반드시 외부 서비스에서 받아올 필요는 없습니다. 이 글에서는 Google이나 Semantic Scholar를 직접 호출하는 방식을 Real Search, 미리 구축한 문서 모음과 검색 시스템이 결과를 제공하는 방식을 Simulated Search라고 부릅니다. 모델이 보는 쿼리와 검색 결과의 형식은 같고, 결과를 돌려주는 주체만 다릅니다.

Simulated Search의 문서가 반드시 가상으로 생성될 필요도 없습니다. Wikipedia나 논문처럼 실제 문서를 내려받아 로컬 환경을 만들 수 있습니다. 외부 API를 호출하지 않으므로 비용과 rate limit 없이 rollout을 생성할 수 있고, 어떤 문서와 결과를 보여줄지도 직접 통제할 수 있습니다.

하지만 비용과 속도만 해결한다고 해서 좋은 학습 환경이 되는 것은 아닙니다. Simulated Search 안에서 높은 reward를 얻는 행동이 실제 검색에서도 유효해야 합니다. 그렇지 않으면 모델은 검색 능력이 아니라, 특정 시뮬레이션에서만 통하는 shortcut을 학습하게 됩니다.

저희가 처음 사용한 SearchGym은 바로 이 문제를 보여주었습니다.

실패 사례: Knowledge Graph 기반 SearchGym

SearchGym은 가상의 개체와 관계로 검증 가능한 knowledge graph를 만들고, 각 개체에 대응하는 wiki-style 문서를 생성합니다. 이후 graph에서 다양한 형태의 추론 경로를 뽑아 질문과 정답으로 변환합니다. 하나의 문서만 찾으면 풀 수 있는 간단한 문제부터, 여러 문서의 정보를 순서대로 연결해야 하는 복잡한 문제까지 자동으로 만들 수 있습니다.

지식이 모두 가상으로 생성되기 때문에 모델은 기억만으로 답을 맞힐 수 없습니다. 문서 사이의 관계가 그래프에 명시되어 있어 문제 생성과 정답 검증도 쉽습니다.

SearchGym의 Sim-to-Real Transfer를 재현해보기

SearchGym 논문은 시뮬레이션에서 배운 검색 능력이 실제 웹 검색으로 전이된다고 보고합니다. 저희는 이 결과를 직접 재현했습니다.

SearchGym은 두 단계로 학습합니다. Stage 1에서는 1~6단계의 비교적 단순한 추론 문제로 기본적인 검색 행동을 익히고, Stage 2에서는 여러 경로를 함께 추적해야 하는 더 복잡한 문제를 추가합니다.

저희도 Qwen2.5-7B를 같은 방식으로 학습했습니다. 각 checkpoint에서 학습에 사용하지 않은 실제 검색 문제 Bamboogle, Musique, GAIA의 성능을 측정하고 평균을 구했습니다.

SearchGym 내부의 reward는 두 단계 모두에서 꾸준히 상승했습니다. 반면 실제 검색 benchmark의 평균 성능은 학습 초반에 잠시 좋아진 뒤 다시 하락했고, Stage 2에서는 학습하지 않은 base model보다 낮은 결과도 나타났습니다.

즉 모델은 SearchGym의 문제를 점점 더 잘 풀게 되었지만, 그 과정에서 익힌 행동이 실제 웹 검색에서는 그대로 통하지 않았습니다.

SearchGym에서의 학습은 왜 실패했을까?

원인을 찾기 위해 학습 후반부의 rollout을 살펴봤습니다.

When is Ophix Silverhelm born?

모델은 먼저 Ophix Silverhelm을 검색했고, 첫 번째 결과에서 이미 정답인 1982를 찾았습니다. 하지만 답을 제출하지 않고 born in 1982를 다시 검색한 뒤, 같은 문서를 반복해서 읽으며 정답을 여러 번 확인했습니다.

SearchGym의 약 3,600개 문서 안에서는 이 전략이 잘 작동했습니다. born in 1982처럼 넓은 검색어를 사용해도 후보가 많지 않아 같은 정답 문서를 쉽게 다시 찾을 수 있었기 때문입니다.

하지만 실제 웹에서는 같은 검색어로 1982년에 태어난 수많은 사람과 문서가 나타납니다. 정답 문서는 비슷해 보이는 결과들 사이에 묻힐 수 있고, 반복 검색은 새로운 정보를 제공하지 않습니다.

실제로 학습이 진행될수록 모델은 GAIA에서도 지나치게 포괄적인 검색어를 사용하고, 이미 확인한 문서를 반복해서 읽으며, 답을 제출하기 전에 불필요한 검증을 이어가는 경향을 보였습니다.

이 사례는 시뮬레이션의 reward만으로 실제 검색 능력의 향상을 판단하기 어렵다는 점을 보여줍니다. 중요한 것은 시뮬레이션 점수 자체가 아니라, 그 과정에서 배운 행동이 실제 검색에서도 유효한가였습니다.

Simulated Scholar Search (S3)

SearchGym은 로컬 검색 시스템을 만드는 것만으로는 충분하지 않다는 사실을 보여주었습니다. 실제 검색으로 전이되려면 모델이 접근할 정보와 행동뿐 아니라, 어떤 탐색 전략을 요구할 질문까지 함께 설계해야 했습니다.

좋은 검색 환경의 조건

먼저 검색 학습에 적합한 corpus가 갖춰야 할 조건을 네 가지로 정리했습니다.

• 각 문서가 충분한 정보를 담고 있으면서 서로 구분되어야 한다.
• 문서 사이의 관계를 추적할 수 있어야 한다.
• 전체를 직접 읽는 방식이 통하지 않을 만큼 충분히 커야 한다.
• 모델이 검색 없이 기억만으로 답하기 어려운 정보가 풍부해야 한다. (Long-tail Knowledge)

이 기준으로 웹, 사내 문서, Wikipedia, 논문을 비교했습니다.

웹은 규모와 최신성은 충분하지만, 광고와 중복 문서가 많고 문서 간 관계를 체계적으로 추적하기 어렵습니다. 사내 문서는 잘 정리되어 있지만 규모가 작아 충분한 오답 후보를 만들기 어렵습니다. Wikipedia는 구조와 규모가 좋지만, 모델이 이미 알고 있는 정보가 많아 검색 행동을 정확히 평가하기 어렵습니다.

논문은 네 조건을 모두 만족했습니다. 각 문서는 고유한 연구 기여를 담고 있고, 문서 사이의 관계는 논문의 인용과 같습니다. 규모도 충분하며, 실험 수치와 학습 설정 같은 세부 정보는 모델이 기억만으로 맞히기 어렵습니다.

또한 같은 분야의 논문들은 비슷한 용어와 배경 이론을 공유하면서도 방법과 결과는 서로 다릅니다. 따라서 모델은 키워드가 비슷한 문서를 찾는 데서 그치지 않고, 여러 후보를 비교해 정확한 근거가 있는 문서를 골라야 합니다.

이런 특성 덕분에 논문은 모델이 넓은 후보군을 탐색하고, 비슷한 문서를 비교하며, 여러 문서에 흩어진 근거를 연결하도록 만들기에 적합했습니다.

저희는 약 100만 편의 논문을 기반으로 새로운 검색 환경인 **Simulated Scholar Search(S3)**를 구축했습니다.

논문 백만 편을 검색 엔진으로 만들기

S3는 Allen Institute for AI가 공개한 Semantic Scholar Open Research Corpus를 기반으로 구축했습니다. 이 가운데 전산학 분야의 약 100만 편의 논문을 사용했습니다.

검색 환경은 실제 논문 검색에서 자주 사용하는 흐름을 그대로 따르도록 구성했습니다. 먼저 제목과 초록을 기준으로 관련 논문을 찾고, 필요한 경우 논문 본문 안에서 특정 문장이나 실험 결과를 다시 검색합니다. 이후 후보 논문의 본문을 직접 읽거나, 인용과 피인용 관계를 따라 다른 논문으로 이동할 수 있습니다.

이를 위해 검색 대상을 두 층으로 나눴습니다.

• 논문 단위 검색: 제목, 초록, 요약을 바탕으로 관련 논문 후보를 찾습니다.
• 본문 단위 검색: 논문 본문을 약 400-token 길이로 나누고, 세부 실험 결과나 설정이 포함된 구간을 찾습니다.

논문 단위 검색에는 키워드 검색과 벡터 검색을 함께 사용했습니다. 의미가 비슷한 논문을 찾는 능력과 정확한 용어가 일치하는 논문을 찾는 능력을 결합하기 위해서입니다. 검색 과정에서는 연도, 학회, 인용 수 같은 metadata도 함께 사용할 수 있도록 했습니다.

논문의 full text와 section 정보는 별도로 저장했고, citation graph는 메모리에서 빠르게 탐색할 수 있도록 구성했습니다. 이를 통해 모델은 단순한 키워드 검색뿐 아니라 다음과 같은 행동을 할 수 있습니다.

• 관련 논문을 검색한다.
• 특정 논문의 본문을 읽는다.
• 논문 안에서 원하는 표현이나 수치를 찾는다.
• 해당 논문이 인용한 연구를 따라간다.
• 이후 이 논문을 인용한 연구를 찾아간다.
• 주제나 인용 관계가 비슷한 논문을 탐색한다.

Agent에게는 다음과 같은 tool interface를 제공했습니다. 각 tool은 연구자가 논문을 찾고 확인하는 행동을 작은 단위로 나눈 것이며, 내부적으로는 Milvus, DuckDB, citation graph를 감싼 Python 함수로 구현했습니다.

모든 검색은 외부 API가 아니라 클러스터 내부에서 처리됩니다. 따라서 검색 횟수가 늘어나더라도 추가 비용이 거의 들지 않고, 대규모 rollout을 병렬로 생성할 수 있습니다.

S3의 목표는 Semantic Scholar의 화면이나 ranking algorithm을 그대로 복제하는 것이 아니었습니다. 중요한 것은 모델이 실제 논문 검색에서 필요한 행동을 충분히 연습할 수 있도록, 논문 찾기 → 본문 읽기 → 관계 따라가기 → 근거 확인하기의 흐름을 하나의 환경 안에 제공하는 것이었습니다.

검색 능력은 질문이 만든다

검색 환경을 잘 구축하는 것만으로는 충분하지 않습니다. 같은 corpus와 같은 검색 도구를 사용하더라도, 어떤 질문을 주느냐에 따라 모델이 배우는 검색 행동은 달라집니다.

논문 이름을 그대로 알려주고 세부 정보를 묻는다면, 모델은 제목을 검색해 본문을 읽는 법만 익히면 됩니다. 반면 여러 조건을 모두 만족하는 논문을 찾거나, 한 논문에서 출발해 인용 관계를 따라가야 하는 문제를 주면 후보를 좁히고 탐색 경로를 계획하는 능력이 필요합니다.

따라서 질문 생성은 단순히 학습 데이터의 양을 늘리는 작업이 아닙니다. 모델에게 어떤 검색 전략을 가르칠지 결정하는 과정에 가깝습니다.

저희는 검색 문제를 두 부분으로 나누어 보았습니다.

1. 문서 식별(Identification): 정답에 필요한 문서를 찾는 과정
2. 정보 종합(Synthesis): 찾은 문서의 정보를 종합해 답을 만드는 과정

두 번째 능력은 정답 문서를 직접 제공한 상태에서도 별도로 학습할 수 있습니다. 반면 첫 번째 능력을 가르치려면, 모델이 실제로 검색하고 후보를 비교하며 필요한 문서에 도달하도록 환경을 구성해야 합니다.

따라서 저희는 이 중 정답에 필요한 문서를 찾아가는 능력에 초점을 맞췄습니다.

논문 안의 정보는 세 층으로 나뉜다

질문의 난이도를 조절하려면, 질문이 정답 논문을 얼마나 직접적으로 가리키는지 통제할 수 있어야 합니다.

저희는 논문에 담긴 정보를 세 층으로 나누었습니다.

• L1: 분야 전반에서 공유되는 배경 지식
  • 여러 논문에서 반복해서 등장하는 이론, 연구 분야, 일반적인 문제 설정입니다. Transformer 구조 같은 것들이 L1에 해당됩니다.
• L2: 특정 논문을 대표하는 기여
  • 논문이 새롭게 제안한 방법이나 개념입니다. 이름이 붙어 있거나 후속 연구에서 인용되기 때문에 다른 논문에서도 발견될 수 있습니다. 예를 들어, 최근 저희 회사에서 나온 모바일 GUI world model인 gWorld [6]가 L2에 해당됩니다.
• L3: 원 논문 본문에만 있는 세부 정보
  • 실험 결과, 학습 설정, ablation 수치처럼 해당 논문을 직접 읽어야 확인할 수 있는 정보입니다.

질문에서 L2의 이름을 그대로 보여주면 정답 논문을 비교적 쉽게 찾을 수 있습니다. 반대로 이름을 숨기고 기여를 설명하거나, L3의 세부 정보만 단서로 주면 검색 난이도가 높아집니다.

이 구조를 이용해 서로 다른 검색 전략을 요구하는 여섯 가지 질문 유형을 만들었습니다.

각 유형은 최종 답을 맞히기 위해 서로 다른 탐색 전략을 요구합니다. 이를 통해 모델이 하나의 검색 패턴에 의존하지 않고, 질문에 따라 검색어와 탐색 경로를 바꾸도록 학습시켰습니다.

최종 답은 의미적 일치로 채점한다

문자열 exact match는 표현만 다른 정답까지 오답으로 처리할 수 있습니다. 이를 피하기 위해 gpt-oss-120b가 예측과 기준 답의 의미적 일치 여부를 판정하도록 하고, 그 결과를 reward로 사용했습니다.

검색 횟수나 특정 tool 사용에 별도의 점수를 주지는 않았습니다. 검색 행동을 직접 보상하는 대신, 최종 답을 맞히려면 원하는 탐색이 필요하도록 환경과 질문을 구성했습니다.

S3에서 배운 검색 능력은 전이될까?

S3는 전산학 논문으로 구성된 로컬 검색 환경입니다. 여기서 학습한 모델이 실제로 유용하려면, 같은 corpus 안에서만 점수가 오르는 데 그쳐서는 안 됩니다. 학습에 사용하지 않은 분야와 다른 검색 도구에서도 성능이 이어져야 합니다.

저희는 이를 두 단계로 확인했습니다. 먼저 실제 논문 검색 환경에서 평가하고, 이후 웹 검색으로 범위를 넓혔습니다.

실제 논문 검색으로 옮겨보기

첫 번째 평가는 LitQA2에서 진행했습니다. LitQA2는 biology 논문의 본문을 직접 찾아 읽어야 풀 수 있는 질의응답 benchmark입니다.

학습은 S3에서 진행했지만, 평가에서는 Semantic Scholar Full-Text API를 통해 실제 biology 논문을 검색하게 했습니다. 학습과 평가 사이에는 두 가지 차이가 있었습니다.

• 로컬에 구축한 Simulated Search에서 실제 검색 API로 환경이 바뀌었습니다.
• Computer science에서 biology로 논문 분야가 바뀌었습니다.

학습 데이터는 논문 본문을 읽어야 풀 수 있는 문제로 구성했고, 지나치게 쉽거나 어려운 문제를 제외한 약 1,600개 문항을 사용했습니다. Qwen3-4B와 저희가 개발 중인 Gravity 30B를 각각 RL로 학습하고, 중간 checkpoint마다 LitQA2 성능을 측정했습니다.

Qwen3-4B의 정확도는 학습 전 0.173(17.3%)에서 최고 0.453(45.3%)까지 상승했습니다. 이는 훨씬 큰 Qwen3-235B-A22B의 0.373(37.3%)보다 높은 결과였습니다.

Gravity 30B 역시 0.347(34.7%)에서 0.480(48.0%)까지 상승했습니다.

Figure 9는 모델 크기와 LitQA2 정확도를 함께 비교합니다. 왼쪽 위에 위치할수록 적은 파라미터로 높은 정확도를 낸 모델이며, 별표로 표시한 S3 checkpoint들은 base model의 성능 경계보다 위에 놓였습니다.

성능 향상과 함께 살펴본 것은 학습 reward와 실제 평가 성능의 관계였습니다. S3 reward가 상승하는 구간에서는 LitQA2 성능도 함께 좋아졌고, reward가 정체되거나 하락한 뒤에는 평가 성능 역시 비슷한 흐름을 보였습니다.

SearchGym에서는 simulation reward가 계속 오르는 동안 실제 검색 성능이 떨어졌습니다. 반면 S3에서는 두 지표가 비교적 함께 움직였습니다. 즉 S3 reward는 실제 논문 검색 능력의 변화를 더 잘 반영했습니다.

웹 검색으로도 옮겨보기

논문 검색 안에서 전이가 일어난다는 것을 확인했으니, 도메인이 다른 웹 검색에서도 S3에서 익힌 행동이 도움이 되는지 확인해보았습니다.

이를 위해 Gravity 모델을 GAIA에서 평가했습니다. GAIA는 웹에서 여러 단서를 찾고 도구를 사용해 답해야 하는 문제로 구성되어 있습니다. 이 중 파일 없이 웹 검색만으로 해결할 수 있는 103개 문항을 사용했습니다.

평가 시에는 Google Search 기반의 web_search와 웹페이지 본문을 읽는 fetch_url 도구를 제공했습니다. 모델은 학습 중 Google Search를 한 번도 사용하지 않았습니다.

가장 좋은 checkpoint의 정확도는 0.282에서 0.369로 상승했습니다. 상대적으로 약 31%의 개선입니다. 답을 제출한 비율도 0.922에서 0.981로 높아졌습니다.

이는 모델이 특정 논문 검색 도구의 사용법만 외운 것이 아님을 보여줍니다. 질문에서 필요한 정보를 식별하고, 검색어를 만들고, 결과를 읽어 다음 행동을 결정하는 능력은 검색 대상과 도구가 바뀌어도 일부 유지되었습니다.

무엇이 달랐을까

SearchGym과 S3 모두 실제 검색 엔진을 호출하지 않고 학습한 Simulated Search 환경이었습니다. 하지만 실제 환경으로의 전이는 크게 달랐습니다.

저희는 그 차이가 검색 결과의 정확한 일치보다, 학습 환경에서 어떤 행동이 유리했는가에 있다고 보았습니다.

S3는 약 100만 편의 실제 논문으로 구성되어 있습니다. 넓은 검색어를 사용하면 비슷한 분야의 수많은 논문이 나타나고, 같은 용어를 공유하지만 질문의 조건을 만족하지 않는 후보도 많습니다. 모델이 정답에 도달하려면 검색어를 좁히고, 여러 후보를 비교하며, 본문의 구체적인 근거까지 확인해야 합니다.

SearchGym에서는 작은 corpus 덕분에 넓은 검색어와 반복적인 확인도 효과적일 수 있었습니다. S3에서는 그런 방식만으로 제한된 turn 안에 정답을 찾기 어렵습니다. 시뮬레이션 안에서 효율적인 전략과 실제 검색에서 효율적인 전략의 차이가 줄어든 것입니다.

두 환경이 같은 query에 같은 문서를 반환한 것은 아닙니다. 그런데도 성능이 전이됐다는 사실은 개별 검색 결과까지 재현할 필요는 없음을 시사합니다.

더 중요한 것은 두 환경이 다음과 같은 구조를 공유하는지입니다.

• 모호한 검색어에는 많은 유사 후보가 나타난다.
• 구체적인 검색어를 사용할수록 후보가 효과적으로 줄어든다.
• 비슷해 보이지만 틀린 문서를 구별해야 한다.
• 여러 문서와 본문 구간을 비교해야 정답을 확인할 수 있다.
• 반복 검색보다 새로운 정보를 얻는 행동이 유리하다.

Conclusion

SearchGym의 reward가 올라도 실제 검색 성능은 좋아지지 않았습니다. 작은 corpus에서는 넓은 검색어와 반복적인 확인도 보상받았지만, 같은 행동은 실제 검색의 수많은 유사 문서 사이에서 통하지 않았습니다. 이 실패를 통해 저희는 검색 결과를 똑같이 재현하는 것보다, 실제 검색에서 유효한 행동이 시뮬레이션에서도 보상받도록 만드는 것이 중요하다고 보았습니다.

이 원칙으로 약 100만 편의 논문을 활용한 Simulated Scholar Search(S3)를 만들었습니다. 실제 검색 API를 한 번도 사용하지 않고 학습했지만, Qwen3-4B의 LitQA2 정확도는 0.173에서 0.453으로, Gravity의 GAIA 정확도는 0.282에서 0.369로 상승했습니다. 논문 분야와 검색 도구가 바뀌어도 검색어를 좁히고, 후보를 비교하고, 새로운 근거를 찾는 행동이 이어졌습니다.

이 결과가 모든 검색 환경으로의 전이를 보장하지는 않습니다. 다만 외부 검색 엔진을 학습 중 직접 호출하지 않아도, 현실과 유사한 선택을 요구하는 환경에서는 다른 정보 공간으로 전이되는 검색 능력을 RL로 학습할 수 있음을 확인했습니다.

Search RL의 확장성을 결정하는 것은 실제 검색 엔진에 대한 접근 자체가 아니라, 새로운 검색 환경에서도 통하는 탐색 행동을 가르칠 수 있는 학습 환경이었습니다.

References

[1] Zhang, G., et al. The Landscape of Agentic Reinforcement Learning for LLMs: A Survey. arXiv:2509.02547, 2025.

[2] Jin, B., et al. Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning. arXiv:2503.09516, 2025.

[3] Song, H., et al. R1-Searcher: Incentivizing the Search Capability in LLMs via Reinforcement Learning. arXiv:2503.05592, 2025.

[4] Shao, R., et al. DR Tulu: Reinforcement Learning with Evolving Rubrics for Deep Research. arXiv:2511.19399, 2025.

[5] Zhang, et al. SearchGym: Bootstrapping Real-World Search Agents via Cost-Effective and High-Fidelity Environment Simulation. ACL 2026.

[6] Trillion Labs. Generative Visual Code Mobile World Models. arXiv:2602.01576, 2026.