Retrieve-for-Train은 어디를 빠르게 하나: 검색 확장 지연과 재학습 비용

Google Research의 Pengcheng Jiang과 Judith Yue Li는 2026년 3월 6일 제출된 논문 (https://arxiv.org/abs/2603.06397 (새 창))을 바탕으로, 2026년 9월 15일 Retrieve-for-Train 해설 (https://research.google/blog/bypassing-inference-bottlenecks-accelerating-complex-ai-search-with-retrieve-for-train/ (새 창))을 공개했다.

사내 검색에서 ‘새 서비스를 배포하기 전에 확인할 것’을 찾을 때는 비슷한 배포 안내 문서 열 개보다 권한 설정, 데이터 이전, 장애 복구, 운영 점검을 각각 다루는 문서가 필요하다. 개별 문서가 질문과 관련 있는지는 물론이고, 문서 묶음이 필요한 범위를 고루 다루는지도 함께 봐야 한다.

이처럼 하나의 질문을 여러 하위 검색어로 나누는 기법이 fan-out이다. 다만 문장 표현이 달라졌다고 해서 검색 결과의 역할까지 달라지지는 않는다. ‘배포 전 확인’, ‘출시 전 점검’, ‘서비스 오픈 체크’가 결국 같은 안내문만 반복해서 찾아낸다면, 호출 수는 늘어나도 확보한 근거의 범위는 그대로다.

따라서 실무에서 먼저 확인할 지표는 검색어 개수보다 중복 문서 비율과 누락된 근거의 종류다. 단일 검색만으로 필요한 문서가 모인다면 굳이 검색 확장을 추가할 이유가 없다. 반대로 여러 항목을 묻는 질문에서 특정 문서군만 반복해서 나온다면, 문서 묶음 단위로 검색 목표를 정의해야 한다.

공식 해설에서 설명하는 구조 (https://research.google/blog/bypassing-inference-bottlenecks-accelerating-complex-ai-search-with-retrieve-for-train/ (새 창))는 세 단계로 나뉜다. 먼저 결과 묶음 단위의 보상으로 fan-out 언어 모델을 학습하고, 그 모델로 합성 학습 쌍을 만들어 작은 확산 검색기에 지식을 옮긴다. 실제 검색 시에는 여러 임베딩 방향을 생성해 DB에서 가까운 항목을 찾는다. 무거운 언어 모델의 탐색 과정을 실시간 요청 경로 밖으로 빼낸 방식이다.

여기서 single-pass라는 표현은 주의해서 읽어야 한다. 논문 부록 F와 Table 3 (https://arxiv.org/html/2603.06397v1#A6 (새 창))을 보면 추론 solver가 256단계를 거친다고 나와 있다. 이는 여러 방향을 비자기회귀 방식으로 동시에 생성한다는 뜻이지, 신경망 연산 자체가 단 한 번만 일어난다는 뜻이 아니다.

이 차이는 운영 비용 추정에 직결된다. 검색 확장을 담당하던 언어 모델 호출을 없애더라도 새로운 검색기의 샘플링, 벡터 검색, 후속 처리는 여전히 남는다. 각 단계의 반환값과 시간 측정 범위를 명확히 기록해 두어야 모델 크기나 호출 횟수만 보고 비용을 오판하지 않는다.

논문 3.4절 (https://arxiv.org/html/2603.06397v1#S3.SS4 (새 창))은 fan-out 생성의 wall-clock latency를 비교한다. 배치 크기 8에서 자기회귀 모델은 1.46초, 확산 검색기는 0.07초가 걸려 12~20배 가속을 달성했다. 다만 이는 검색 확장 구간만 따로 떼어 측정한 값이며, 전체 검색 시간이나 RAG 답변 생성까지 같은 비율로 빨라졌다는 뜻은 아니다.

해당 절에는 지연 시간을 비교할 때 사용한 정확한 하드웨어 사양과 자기회귀 체크포인트, 검색 호출 포함 범위가 구체적으로 명시돼 있지 않다. 따라서 특정 GPU 서버나 상용 API 환경에서도 같은 수치가 재현된다고 단정하기 어렵다. 실제 서비스에 적용할 때는 요청 수신부터 결과 반환까지 전 구간을 다시 측정해야 한다.

문서 처리나 재정렬에 더 많은 시간이 걸리는 서비스라면 검색어 생성 시간을 줄여도 전체에서 얻는 이득은 작다. 반대로 검색 확장 단계가 대기 시간의 대부분을 차지한다면 이 구조를 도입할 이유가 커진다. 논문의 가속 배수를 전체 응답 시간에 단순 대입하기보다, 단계별 trace를 통해 현재 서비스의 병목 구간부터 찾아야 한다.

전체 지연에 미치는 영향은 모든 구간의 시간을 더해서 계산해야 한다. 예를 들어 설명용 서비스에서 검색 확장이 1.46초, 나머지 검색·재정렬이 0.54초 걸린다면 총 지연 시간은 2.00초다. 여기서 확장 시간만 0.07초로 줄이면 총 0.61초가 되어 전체 가속은 약 3.28배가 된다. 이는 논문의 확장 지연 수치를 가상의 나머지 구간에 대입해 본 계산일 뿐 실제 서비스 실험 결과가 아니다. 나머지 구간이 길어질수록 전체 지연 시간에서 얻는 이득은 줄어든다.

학습비 역시 전체 요청량으로 나누어 따져봐야 한다. 가상의 재학습 비용이 1,000이고 요청당 절감 비용이 0.02라면, 다른 비용이 동일하다는 조건에서 50,000회 요청을 처리한 뒤에야 학습비를 회수할 수 있다. 만약 원본 자료가 바뀌어 그전에 모델을 다시 학습해야 한다면, 요청당 추론비가 낮아지더라도 총비용은 오히려 늘어날 수 있다. 예시의 숫자 자체를 가격 전망치로 삼기보다, 자체적인 재학습 주기 안에 처리하는 요청 수를 분모로 두고 계산해야 한다.

공식 해설 (https://research.google/blog/bypassing-inference-bottlenecks-accelerating-complex-ai-search-with-retrieve-for-train/ (새 창))에서 다루는 open-ended retrieval의 보상은 DB 근접성, 다양성, 질문 정렬을 함께 고려하며, 실험 범위는 패션과 음악 검색에 한정되어 있다. 따라서 이 보상 점수가 개선되었다고 해서 사내 문서 검색의 정확성이나 사용자 만족도가 높아진다고 바로 치환할 수는 없다.

논문의 약한 참조 집합 평가 (https://arxiv.org/html/2603.06397v1#A2.SS2 (새 창))에 쓰인 Recall@5K는 가능한 정답 전체가 아니라 참조 항목 중 얼마나 회수했는지를 나타내는 비율이며, 답변의 정확도를 뜻하지 않는다. 정답이 열려 있는 과제에서는 참조 집합에 없더라도 유효한 결과가 나올 수 있으므로, 평가 점수는 실제 업무의 합격 조건과 함께 읽어야 한다.

문서 검색에 적용할 때는 다양성의 단위를 문서 제목이나 임베딩 거리만으로 정하면 안 된다. 제목이 달라도 같은 정책을 복사해 둔 문서일 수 있고, 임베딩 거리가 먼 문서가 실제로는 질문과 무관할 수도 있다. 배포 관련 질문이라면 ‘권한’, ‘이전’, ‘복구’처럼 필요한 역할을 먼저 정의한 뒤, 각 역할에 해당하는 근거가 실제로 회수됐는지 확인해야 한다.

접근 권한과 최신 버전 여부는 보상 항목에 섞기보다 별도의 통과 조건으로 분리한다. 다른 결과가 아무리 좋아도 열람 권한이 없는 문서나 폐기된 절차가 섞여 있으면 실무에 쓸 수 없기 때문이다. 보상을 높이는 모델 학습과 반환 가능한 결과의 경계를 지키는 작업은 따로 검증해야 한다.

도입 전 비교 실험은 현재 검색 환경에서 확장이 필요한 질문들을 추리는 것부터 시작한다. 필요한 문서가 한 종류인 질문과 여러 종류인 질문을 나누고, 단순히 표현만 바꾼 질문과 새로운 업무 유형의 질문을 분리한다. 학습에 사용한 질문을 그대로 쓰지 않고, 새로운 문서와 새로운 질문 표현에서도 필요한 근거를 제대로 찾아내는지 확인해야 한다.

비교 기준선은 원본 질문의 단일 검색과 온라인 LLM fan-out으로 두고, 두 방식의 차이를 확인한 뒤 학습형 검색 확장을 추가한다. 세 가지 구성에는 동일한 문서 스냅샷, 임베딩 모델, 접근 권한, 최종 반환 개수를 적용한다. 후보 수가 서로 다르면 검색 범위를 넓혀서 얻은 효과와 검색 방향 자체를 개선한 효과를 구분하기 어렵다.

품질: 필수 근거 회수율, 결과 중복률, 무관한 문서 비율, 권한·버전 위반 건수를 따로 집계한다.

온라인 비용: 확장·벡터 검색·재정렬 시간을 분리하고 전체 응답의 p50·p95와 요청당 비용을 측정한다.

갱신 비용: 새 문서를 반영한 뒤 합성 데이터와 검색기를 얼마나 다시 만들어야 하는지 기록한다.

각 항목의 합격 기준은 배포 전에 미리 정해 둔다. 검색 확장 시간이 줄었더라도 필수 근거 누락이 늘어나면 채택을 보류하고, 품질이 비슷하다면 학습 및 갱신 비용을 예상 요청량에 나눠 전체 비용을 비교한다.

문서가 자주 바뀌는 환경에서는 이전 스냅샷에 맞춰 학습한 검색 방향의 유효 기간도 확인해야 한다. 기존 모델로 새 DB를 검색하는 경우와 데이터를 갱신해 재학습한 경우를 비교해 보면 온라인 추론에서 얻는 이득을 유지하는 데 드는 비용이 드러난다. 이 부담이 크다면 현재 검색기에 중복 제거와 재정렬을 보강하는 작은 변경부터 비교한다.

Retrieve-for-Train 도입 여부를 판단할 때 출발점은 작은 확산 모델의 속도보다 현재 검색이 실패하는 형태다. 서로 다른 근거를 모아야 하는 질문에서 중복된 결과가 반복해서 나오고, 온라인 검색어 생성 단계가 실제 병목으로 확인될 때 비로소 계산 부담을 학습 단계로 옮길 이유가 생긴다.

실험에서는 결과 묶음이 채워야 할 역할을 먼저 정의하고, 기존 방식과 동일한 조건에서 품질·전체 지연·갱신 비용을 비교한다. 단일 검색만으로 충분한 질문에서는 기존 구조를 단순하게 유지하고, 검색 확장으로 해결되는 실패 사례가 확인된 범위에서만 학습형 검색기를 검토하는 편이 타당하다.

Google Research — Bypassing inference bottlenecks: Accelerating complex AI search with Retrieve-for-Train (새 창)

· 2026년 9월 15일 해설

Efficient, Property-Aligned Fan-Out Retrieval via RL-Compiled Diffusion (새 창)

· 2026년 3월 6일 제출

원논문 v1 본문 (새 창)

· 2절 구조 · 3.4절 지연 비교 · 부록 B 평가 · 부록 F 구현