검색 결과의 양이 늘면 답에 필요한 근거도 함께 늘어날 것 같지만, 모델이 처리할 정보가 많아진 만큼 판단이 쉬워지는 것은 아니다. 같은 자료를 두고도 검색 이후의 선택을 누가 어떤 방식으로 맡느냐에 따라 답의 품질이 달라진다.
많이 넣는다고 잘 찾는 건 아니다
일반적인 RAG는 검색기가 고른 top-k(점수가 높은 상위 k개 결과) 문서를 모델에 한꺼번에 건넨다. 에이전틱 RAG도 대개 사람이 짠 순서대로 움직인다. 어느 쪽이든 모델은 검색 방법이나 중단 시점을 직접 정하지 못한다. A-RAG가 지적한 한계다.
이 구조에서는 모델을 바꿔도 검색 성능이 함께 좋아지기 어렵다. 인덱스와 컨텍스트를 키우는 데도 한계가 있다. 인덱스는 검색용으로 미리 가공해 둔 문서 집합이고, 컨텍스트는 모델에 실제로 넣는 입력 정보라는 점에서 다르다. 프런티어(당대 최상위 성능) 모델 18종은 과제와 입력 위치에 따라 하락 폭이 다르지만, 입력 한도에 닿기 전부터 정확도가 최대 30~50%까지 떨어지는 사례도 있었다.
검색 절차를 모델에 맡기면 어떨까. A-RAG는 무엇을 어떻게 찾고 읽을지 모델이 정한다. 여러 문서에 흩어진 단서를 연결해 답해야 하는 세 질의응답 벤치마크에서 GPT-5-mini로 HotpotQA 94.5%, 2WikiMultiHopQA 89.7%, MuSiQue 74.1%를 기록해 HippoRAG2를 각각 9.7%, 7.7%, 12.4% 앞섰다. HotpotQA에서 읽은 토큰도 나이브 RAG의 5,358개보다 적은 2,737개였다.
검색이 좋아지자 다음 병목도 드러났다. MuSiQue 오답 100건 중 82%는 자료 부족이 아니라 추론 오류였다. 자료를 더 찾기보다 찾은 자료를 정확히 읽어내는 능력이 관건으로 떠올랐다.
목록부터 보고, 본문은 골라 읽는다
A-RAG는 세 도구를 쓴다.
keyword_search는 정확히 일치하는 표현을,semantic_search는 의미가 가까운 문장을 찾는다.- 모델은 이 목록에서 필요한 항목만
chunk_read로 열어 본문을 읽는다.
목록과 본문을 나눠 놓은 구조가 토큰 사용을 갈랐다. 일반적인 나이브 RAG와 달리 A-RAG Naive는 임베딩 검색(문장의 의미를 수치 벡터로 바꿔 유사한 항목을 찾는 방식) 하나만 자유롭게 쓰도록 제한한 구성이다. 이 구성은 데이터셋에 따라 2만2,391~5만6,360토큰을 읽었다. 세 단계를 나눈 Full 버전은 2,737~7,678토큰만 쓰고도 더 정확했다. 모델에 자율성을 주는 것만큼, 값싼 목록부터 보여주는 설계가 중요하다.
하나씩 뺀 실험에서 정확도는 의미 검색 없이 최대 4.7%, 키워드 검색 없이 1.5%, 청크 읽기 없이 1.0% 낮아져 도구마다 기여도가 달랐다. 비슷한 선택은 코드 에이전트에서도 보인다. Claude Code가 벡터 인덱스 대신 Glob, Grep, Read를 택한 것도 모델이 다루기 쉬운 도구를 앞세운 사례다. 벡터 인덱스를 함께 쓰면 재현율(관련 자료를 빠뜨리지 않고 찾아낸 비율)을 유지하면서 토큰을 40% 이상 줄일 수 있었다는 자체 시험 결과도 있어, 한 방식에만 의존할 필요는 없다.
도구를 무엇으로 부르느냐도 결과에 영향을 준다. 같은 조건에서 Claude Sonnet 5의 정확도는 개별 JSON 도구 호출 80.8%에서 코드로 여러 도구를 한 번에 부르는 프로그래매틱 호출 96.2%로 올랐다. JSON 호출은 도구를 하나씩 요청하고 응답을 기다리는 방식이고, 프로그래매틱 호출은 코드 안에서 여러 도구를 한꺼번에 병렬로 부른다. 프로그래매틱 호출은 100개 요청도 빠짐없이 처리했다. EDA(전자설계자동화) 에이전트 연구에서도 같은 진척을 내는 데 필요한 토큰 효율이 최대 141배 차이 났다.
그만 찾는 것도 검색 능력이다
같은 검색을 반복한다고 놓친 문서가 잡힐까. 같은 질의를 같은 벡터 공간에 반복해 보내면 놓친 문서를 계속 놓치기 쉽다. 질문과 문서의 표현이 다르면 자료가 있어도 유사도 순위 밖으로 밀리기 때문이다. 이때는 재검색보다 전략 변경이 필요하다.
Skill-RAG는 바로 이 지점에서 실패를 감지하면 질의를 다시 쓰거나, 질문을 나누거나, 증거에 집중하거나, 검색을 포기한다. 이 네 전략은 모델의 표현 공간(내부 상태를 수치 벡터로 나타낸 공간)에서도 뚜렷이 구분됐다. 답을 찾기 어려운 질의에서 일찍 중단하자 검색은 평균 1.42회 줄었고 정확도는 0.6%만 낮아졌다.
중단 시점과 마찬가지로, 추가 예산도 모델이 판단할 때 더 효과적이다. A-RAG의 허용 단계를 5회에서 20회로 늘리자 GPT-5-mini는 약 8%, GPT-4o-mini는 약 4% 향상됐다. 추론 강도를 minimal에서 high로 높이면 GPT-5-mini와 GPT-5 모두 약 25% 좋아졌다. 고정 절차를 오래 반복하는 대신 다음 도구와 종료 시점을 바꿀 수 있었기 때문이다.
모든 RAG를 에이전트로 바꿀 필요는 없다
질의 범위와 필요한 문서 크기가 일정하면 기존 top-k가 빠르고 저렴하다. 반대로 질의마다 키워드 검색, 의미 검색, 본문 확인의 비중이 다르다면 고정된 k값과 청크 크기가 오히려 성능을 떨어뜨린다. 기준은 멀티홉(여러 문서의 단서를 단계적으로 이어 답하는 방식) 여부보다 ‘검색 절차를 미리 정할 수 있는가’다.
에이전틱 RAG는 일반 파이프라인보다 토큰을 3~10배, 시간을 2~5배 더 쓴다는 보고도 있어, 단순 조회까지 여러 단계로 처리하면 그만큼 낭비가 커진다. 반면 A-RAG처럼 목록을 먼저 보고 본문을 고르면 일부 벤치마크에서는 정확도를 높이면서 읽은 토큰을 절반가량 줄이기도 했다.
단순 질의는 top-k로 보내고, 검색 범위와 깊이를 판단해야 하는 질의는 에이전트로 보내는 혼합 운영이 현실적이다. 벡터 DB도 버리지 않고 키워드 검색, 본문 읽기와 나란히 둔 도구로 쓰면 된다.
언제 고정 파이프라인을 의심해야 할까. 코퍼스(검색 대상 문서 모음)에 있는 자료를 자주 놓치거나, 도메인마다 청크 크기와 k값을 계속 손봐야 하거나, 모델을 바꿔도 정확도가 그대로라면 고정 파이프라인이 병목일 수 있다. 이런 조짐은 로그에서 드러난다. 이때는 recall@k(상위 k개 결과가 관련 문서를 얼마나 포함하는지 나타내는 지표)와 함께 읽은 토큰당 정답률, 검색을 중단한 시점의 정확도, 스텝 예산에 따른 성능 변화도 살펴야 한다.
고정 RAG는 검색기가 고른 문서를 모델에 건넨다. 계층형 검색 인터페이스를 갖춘 에이전틱 RAG는 검색 도구와 본문 열람 권한을 주고, 무엇을 읽을지는 모델이 정하게 한다. 검색 성능은 더 많은 자료가 아니라 더 나은 선택권에 달려 있다.
도구의 성능을 비교할 때도 단일 검색 결과보다 모델과 검색기가 나누어 맡는 일을 함께 봐야 한다. 같은 검색기라도 후보를 보여주는 방식과 본문을 여는 권한에 따라 효율 차이가 났다.