에이전틱 RAG는 단일 검색을 루프로 대체한다. 모델이 검색하고, 읽고, 더 필요하다고 판단하고, 다시 검색하고, 이를 만족할 때까지 반복한다. 각 홉은 완전한 모델 왕복에 검색 하나를 더한 것이며, 각 홉이 이전 홉에 의존하기 때문에 순차적으로 진행된다. 대부분의 질문에서 이것은 잘 구성된 쿼리 하나면 같은 컨텍스트를 한 번에 얻었을 것을 몇 배의 지연을 치르고 아주 조금 더 나은 답으로 바꿔치기하는 셈이다. 멀티홉 검색은 좁은 부류의 질문에는 진짜 유용한 도구이지만, 그 외의 모든 곳에서는 조용히 응답 시간을 세 배로 만드는 기본값이다.

재구성은 이렇다. 에이전틱 검색은 지연을 대가로 실행 시점에 질문을 분해할 수 있는 능력을 산다. 그 거래는 질문이 실제로 분해가 필요할 때만 그만한 값어치를 한다. 대부분은 그렇지 않으며, 단일 쿼리로 답할 수 있는 질문에 루프 세금을 내는 것이야말로 RAG 시스템이 아무 이득 없이 느려지는 가장 흔한 방식이다.

지연은 어디서 오는가

단일 패스 RAG는 임베딩 한 번, 벡터 검색 한 번, 모델 호출 한 번이다. 에이전틱 RAG는 루프이며, 그 루프는 구조상 순차적이다. 모델은 첫 번째 쿼리의 결과를 읽기 전에는 두 번째 쿼리를 낼 수 없다. 따라서 실제 소요 시간은 검색 하나 더하기 생성 하나가 아니라, 각 홉의 검색, 다음에 무엇을 할지 결정하는 각 홉의 모델 호출, 그리고 마지막 생성을 모두 더한 값이다. 세 홉이면 대략 세 배의 왕복이며, 각 모델 호출이 누적된 컨텍스트를 다시 읽기 때문에 홉당 비용은 일정하게 유지되기보다 커지는 경향이 있다.

이 중 어느 것도 사용자가 요청한 숨겨진 작업이 아니다. 사용자 입장에서는 2초 걸리던 하나의 질문이 이제 8초가 걸릴 뿐이다. 그 8초가 눈에 띄게 더 나은 답을 사지 못했다면, 우리는 지연 예산을 아무것도 아닌 곳에 쓴 것이다.

잘 만든 쿼리 하나가 대개는 영리한 루프를 이긴다

놀라울 정도로 많은 에이전틱 RAG가 약한 첫 쿼리를 보완하기 위해 존재한다. 초기 검색이 잘못된 청크를 끌어오면 루프의 임무는 "컨텍스트가 나쁘다는 것을 알아채고 더 나은 컨텍스트를 가져오라"가 되는데, 이는 비용이 많이 드는 오류 복구다. 쿼리를 고치면 루프가 할 일이 사라지는 경우가 많다.

멀티홉에 손을 뻗기 전에 단일 패스에 노력을 쏟아라.

  • 쿼리를 다시 써라. 지저분한 사용자 질문을 깔끔한 검색 쿼리로 바꾸는 저렴한 모델 호출 한 번이, 두 번째 홉보다 훨씬 적은 지연으로 검색 품질을 더 많이 개선한다.
  • 더 많이 검색하고 재순위를 매겨라. 순차적으로 여러 번 좁게 검색하는 대신, 한 번의 검색으로 더 넓은 후보 집합을 뽑아 재순위로 좁혀라.
  • 청크를 고쳐라. 나쁜 검색의 대부분은 청킹 문제다. 더 나은 청크는 첫 쿼리를 적중시키고, 그러면 루프가 불필요해진다.

이것들은 모두 단일 패스 개선이다. 루프가 추가하는 순차적 왕복 없이 답변 품질을 끌어올린다. 루프가 하는 일과는 정반대다.

에이전틱 검색이 실제로 이길 때

루프는 두 번째 쿼리가 첫 번째 쿼리의 답에 의존하기 때문에 진짜로 단일 쿼리로 답할 수 없는 질문에 대해 그 지연 값을 한다. 가장 명확한 사례는 연쇄로 이어야 하는 사실들에 대한 멀티홉 추론이다. "새 규제의 영향을 받는 지역에 있는 우리 벤더 중 이번 분기 갱신 예정인 곳은 어디인가"는 사실상 각각이 다음을 좁혀 가는 세 번의 조회이며, 단일 검색으로는 결합된 답을 담아낼 수 없다.

주목해야 할 패턴은 검색 사이의 진짜 의존성이다. 첫 번째 결과를 알기 전에는 두 번째 쿼리를 쓸 수 없는 경우다. 그 의존성이 실재할 때 루프는 필요한 작업을 하고 있는 것이며, 지연은 그렇지 않으면 얻을 수 없었을 답의 대가다. 그 의존성이 없을 때, 그리고 대개는 없는데, 루프는 단일 쿼리로 끝났을 질문을 위한 정교한 기계 장치일 뿐이다.

시스템 단위가 아니라 질문 단위로 결정하라

실패는 모든 요청에 에이전틱 검색을 기본값으로 삼는 것이다. 더 나은 설계는 라우팅한다. 저렴한 질문은 단일 패스를 타고, 분해 신호를 보이는 질문, 즉 다중 엔티티, 연쇄 조건, 명시적인 "~간 비교"만 루프로 격상시킨다. 검색 앞에 작은 분류기나 심지어 휴리스틱 하나만 있어도 이 판단을 내릴 수 있다. 목표는 멀티홉 세금을 그만한 값을 하는 질문에만 정확히 물리고, 그렇지 않은 질문에는 절대 물리지 않는 것이다.

결론

에이전틱 RAG는 틀린 것이 아니라 과용되고 있다. 검색을 모델 왕복의 순차 루프로 바꾸며, 단일 쿼리로 충분히 답할 수 있는 대다수의 질문에서는 그 루프가 순전히 지연일 뿐이다. 먼저 단일 패스에 노력을 쏟아라. 쿼리를 다시 쓰고, 더 넓게 검색해서 재순위를 매기고, 청크를 고쳐라. 멀티홉은 검색 사이에 진짜 의존성이 있는 질문을 위해 아껴 두고, 시스템 전체를 거기로 기본값 설정하는 대신 질문별로 라우팅하라. 가장 빠른 RAG 시스템은 질문이 실제로 두 번째 검토를 요구할 때만 루프를 도는 시스템이다.

이어서 읽으면 좋은 글

대규모 저지연 검색 인프라에 관한 내용은 ercan.cloud의 클라우드 현장 노트에서 다루고, 허브는 ercanermis.com에 있다.