빠른 RAG는 질문이 언제 안정되는지부터 봐야 한다

제일 먼저 든 생각

RAG 시스템을 만들다 보면 “검색을 더 빨리 붙이면 사용자 경험이 좋아진다”는 말이 자연스럽게 나온다. 그런데 이 논문은 그 말을 조금 차갑게 쪼갠다. 스트리밍 RAG(streaming retrieval-augmented generation)는 사용자가 질문을 다 입력하기 전에 검색 도구를 미리 호출해 지연 시간을 숨기려는 방식이다. 하지만 미리 검색이 도움이 되려면 조건이 있다. 질문의 핵심 의도가 입력 중간에 이미 안정되어야 한다.

저자는 이를 도구 의도 안정화(tool-intent stabilization)라고 부른다. 질문의 어느 지점부터 부분 입력만으로도 최종 검색 결과나 정답 근거 문서에 수렴하는지를 측정한다. 이건 새 모델을 제안하는 논문이라기보다, 스트리밍 도구 사용이 어느 업무에서 실제로 값어치가 있는지 가늠하는 측정 논문에 가깝다.

검색을 먼저 날리는 것보다 중요한 질문은 “결정적인 단어가 언제 등장하는가”다. 의도가 늦게 안정되는 질문은 아무리 빠른 트리거를 붙여도 이득이 작다.

모든 질문이 미리 검색될 수 있는 것은 아니다

논문은 CRAG 벤치마크 1,371개 검증 질문을 대상으로, 부분 입력이 늘어날 때 검색 결과가 언제 안정되는지 본다. 예를 들어 결정적인 단어가 질문 앞부분에 있으면 남은 입력 시간 동안 검색 지연을 숨길 수 있다. 반대로 결정적인 단어가 마지막에 나오면, 조기 검색은 틀린 방향으로 달릴 가능성이 커진다.

“추측은 올바른 도구 질의가 사용자가 말하거나 입력을 끝내기 전에 결정될 수 있을 때만 도움이 된다.”

“speculation can only help when the correct tool query becomes determinable before the user stops speaking or typing.”

이 말은 업무 자동화에도 그대로 온다. 사내 지식검색 챗봇에서 “이번 분기 영업팀 교육 만족도…”처럼 초반에 주제가 뚜렷한 질문은 미리 검색해도 될 수 있다. 하지만 “그때 김 과장이 말한, 작년에 바꿨던 그 기준이 뭐였지?”처럼 결정적 단서가 뒤늦게 붙는 질문은 스트리밍 검색의 이득이 작거나 오히려 비용이 될 수 있다.

73.9%라는 숫자를 조심해서 읽기

논문은 현실적인 설정으로 도구 지연 600ms, 입력 속도 3 words/s, 지연 80% 이상 은닉 기준을 놓았을 때 전체 벤치마크의 73.9% 질문에서 상당한 latency hiding이 가능하다고 보고한다. 다만 이 숫자는 여러 조건이 섞인 값이다. 금 표준 근거가 원문 그대로 있고 BM25로 검색 가능한 유리한 21.3% 구간에서는 95.2%가 streamable로 나타났지만, 나머지에 대해서는 다른 안정화 기준을 함께 쓴다.

“도구 의도 안정화는 스트리밍 도구 사용이 언제, 얼마나 도움 되는지를 제한하는 질의 고유의 모델 비의존적 양이다.”

“Tool-intent stabilization is a query-intrinsic, model-agnostic quantity that bounds when streaming tool use can help and by how much.”

그래서 이 논문을 “스트리밍 RAG를 붙이면 70% 이상 빨라진다”로 읽으면 곤란하다. 더 좋은 해석은 “우리 업무 질문 집합에서 의도가 일찍 안정되는 비율을 먼저 재보자”다.

에이전트 워크플로에 붙이면, 트리거보다 분류가 먼저다

AI agent나 RAG 자동화를 만들 때는 대개 트리거를 잘 만들고 싶어진다. 언제 검색할지, 언제 DB를 조회할지, 언제 계산 도구를 부를지 말이다. 이 논문은 그 전에 질문 유형별로 기대 이득을 나눠보라고 말한다.

Deciflow식으로 옮기면 다음처럼 설계할 수 있다.

• 자주 들어오는 질문 200개를 모아, 결정적 단서가 앞·중간·뒤 어디에 나오는지 표시한다.
• 질문 prefix만으로 검색 결과가 바뀌지 않는 지점을 측정한다.
• 의도가 빨리 안정되는 유형만 스트리밍 검색 후보로 둔다.
• 늦게 안정되는 유형은 사용자가 입력을 마친 뒤 검색하거나, 되묻기 질문을 먼저 한다.
• 조기 호출이 틀렸을 때 버리는 비용과 사용자가 체감하는 지연 감소를 함께 계산한다.

이렇게 보면 “빠른 RAG”는 모델의 속도 문제가 아니라 업무 질문의 문법 문제이기도 하다. 조직 안의 질문이 늘 앞부분에 프로젝트명·고객명·문서명이 먼저 나오는지, 아니면 마지막에야 핵심 제약이 붙는지에 따라 설계가 달라진다.

작은 실험으로 바꾼다면

사내 검색 봇을 고치기 전에, 실제 질문 로그에서 50개만 뽑아도 충분하다. 각 질문을 한 단어씩 잘라가며 검색을 돌리고, 어느 prefix부터 최종 검색 결과와 같아지는지 본다. 그 분포가 앞쪽으로 몰려 있으면 streaming RAG는 검토할 가치가 있다. 뒤쪽 꼬리가 두껍다면 트리거를 복잡하게 만들기보다 질문 재작성, 슬롯 입력, 후속 질문 설계가 먼저다.

오늘 남길 질문은 이것이다.

우리의 RAG 자동화는 사용자의 질문이 안정되기 전에 너무 빨리 달려나가고 있지 않은가?

원문 정보

• 제목: When Does Streaming Tool Use Help? Characterizing Tool-Intent Stabilization in Streaming Retrieval-Augmented Generation
• 저자: Elroy Galbraith
• 연도/게시일: 2026
• 게재/출처: arXiv
• arXiv: 2606.20113v1
• PDF: https://arxiv.org/pdf/2606.20113

원문 논문: When Does Streaming Tool Use Help? Characterizing Tool-Intent Stabilization in Streaming Retrieval-Augmented Generation