KEY POINT

- 아마존 베드락이 복합 질문 해결을 위해 질문 분해와 검색-평가-반복 루프를 자동화하는 `AgenticRetrieveStream` API를 출시했다.

- 멀티홉 질문 벤치마크인 MuSiQue에서 단일 검색 대비 리콜(Recall)을 20% 절대 향상시키며 복잡한 정보 탐색 능력을 입증했다.

- 사용자는 질문의 복잡도와 허용 지연 시간, 예산에 따라 `Retrieve`와 `AgenticRetrieveStream` 중 최적의 API를 선택해야 한다.

#AmazonBedrock #RAG #에이전틱워크플로우 #지식베이스 #검색정확도

MuSiQue 벤치마크 리콜 20% 높인 AgenticRetrieveStream의 필요성

아마존 베드락이 여러 단계의 정보를 거쳐 답을 찾아야 하는 멀티홉(Multi-hop) 질문의 정확도를 높이기 위해 `AgenticRetrieveStream` API를 도입했다. 기존의 싱글샷 리트리벌(Single-shot retrieval) 방식은 PDF, 슬라이드, 티켓, 전사 기록 등 다양한 문서에 흩어진 정보를 통합해야 하는 복합 질문에서 맥락을 놓치는 한계를 보였다. 특히 "2020년과 2023년의 전략을 비교하라"와 같은 다중 의도 질문은 임베딩 공간에서 하나의 벡터로 표현하기 어려워, 검색 결과가 여러 하위 의도의 평균값으로 수렴하며 정답률이 떨어지는 문제가 발생했다.

이러한 한계를 극복하기 위해 도입된 에이전틱 리트리벌은 실제 분석가가 정보를 찾는 방식인 '질문 분해 $\rightarrow$ 검색 $\rightarrow$ 결과 검토 $\rightarrow$ 재검색' 과정을 자동화한다. 아마존은 공공 멀티홉 질문 벤치마크인 MuSiQue를 통해 성능을 검증했으며, 그 결과 단일 검색 대비 리콜(Recall)이 20% 절대적으로 향상되는 성과를 거두었다. 질문에 포함된 단계가 많고 복잡할수록 성능 개선 효과가 뚜렷하게 나타나며, 이는 단순 검색으로는 도달할 수 없는 정보의 공백을 메우는 핵심 기제로 작동한다.

계획-검색-평가 루프로 동작하는 에이전틱 리트리벌 구조

`AgenticRetrieveStream` API는 파운데이션 모델이 질문을 하위 과제로 분해하고 검색된 증거의 충분성을 판단하는 계획 루프를 실행한다. 모델은 사용자의 질문을 분석해 검색 가능한 작은 단위로 쪼개고, 각 부분에 대해 개별적으로 정보를 찾은 뒤, 수집된 정보가 최종 답변을 내기에 충분한지 스스로 평가한다. 만약 정보가 부족하다고 판단되면 플래너는 검색 계획을 수정하여 다시 검색을 수행하며, 충분한 증거가 확보될 때까지 이 과정을 반복한다.

개발자는 이 루프의 모든 단계를 순서가 지정된 트레이스 이벤트(Trace events) 스트림으로 확인할 수 있다. 각 이벤트에는 실행 단계와 상태가 포함되어 있어, 플래너가 왜 해당 하위 질문을 생성했고 어떤 판단 경로를 거쳤는지 실시간으로 디버깅이 가능하다. 데이터 처리 과정에서는 최종 결과 이벤트에서만 중복 제거(Deduplication)를 적용하여, 여러 하위 쿼리가 동일한 청크(Chunk)를 찾아내더라도 최종 결과물에는 한 번만 나타나도록 설계했다.

또한 시스템은 기본적으로 검색과 근거 기반 응답 생성을 동일한 호출 내에서 처리한다. 만약 모델의 추가 추론 없이 리트리버가 찾아낸 원문 결과물만 즉시 반환받아 외부 모델로 합성하고 싶다면, `generateResponse=False` 옵션을 설정하여 검색된 데이터 셋만 빠르게 확보할 수 있다.

최대 5개 지식베이스 라우팅과 maxAgentIteration 설정

에이전틱 리트리벌은 단일 API 호출 내에서 최대 5개의 관리형 지식베이스(Managed Knowledge Base) 리트리버를 등록하고 쿼리를 분배하는 멀티 KB 라우팅 기능을 제공한다. 플래너는 각 지식베이스에 설정된 자연어 설명(Description)을 읽고, 분해된 하위 쿼리를 가장 적절한 저장소로 라우팅한다. 이때 지식베이스 설명은 플래너가 라우팅을 수행하는 계약서 역할을 하므로, 각 저장소의 성격을 한 문장의 피치 형태로 명확하게 정의해야 라우팅 정확도를 높일 수 있다.

검색 결과로 반환되는 각 청크에는 `sourceRetriever` ID가 포함되어, 어떤 하위 질문이 어떤 지식베이스를 통해 해결되었는지 개별적으로 식별할 수 있다. 이는 여러 저장소를 동시에 참조하는 환경에서 정보의 출처를 명확히 구분하고 답변의 신뢰성을 검증하는 기준이 된다.

루프의 효율성을 제어하기 위해 개발자는 `maxAgentIteration` 파라미터를 통해 계획 및 검색의 최대 반복 횟수를 설정한다. 단일 지식베이스를 사용할 때는 3회를 권장하며, 여러 지식베이스를 비교하거나 복합적인 쿼리를 처리할 때는 4~5회 설정을 권장한다. 플래너는 설정된 상한선에 도달하기 전이라도 평가 단계에서 증거가 충분하다고 판단하면 프로세스를 조기에 종료한다. 또한 `foundationModelType` 필드를 통해 서비스 관리형 모델을 사용할지, 혹은 `foundationModelConfiguration`을 통해 사용자 정의 CUSTOM 모델을 플래너로 사용할지 선택할 수 있다.

호출당 과금 체계와 단일 검색 대비 비용·지연 시간 변화

아마존은 에이전틱 리트리벌의 과금 체계를 호출당 비용과 하위 API 호출 비용의 합산 방식으로 정의했다. 관리형 모델을 사용할 경우 에이전틱 호출 1,000건당 4달러를 지불하며, 여기에 실제 수행된 하위 리트리브 API(Retrieve API) 호출 1,000건당 1달러가 추가로 부과된다. 커스텀 모델을 선택한 경우에는 선택한 아마존 베드락 모델의 표준 요금(Pass-through pricing)에 하위 리트리브 API 호출 비용 1,000건당 1달러를 추가로 지불한다.

전체 비용과 응답 지연 시간(Latency)을 결정하는 핵심 변수는 반복 횟수(Iteration count)다. 단일 검색 방식인 `Retrieve` API는 한 번의 유사도 검색으로 결과를 내놓으므로 비용이 가장 낮고 지연 시간이 가장 짧다. 반면 `AgenticRetrieveStream`은 질문 분석, 결과 확인, 쿼리 재생성 루프를 반복하며 여러 번의 모델 호출을 수행하므로, 반복 횟수가 늘어날수록 비용이 정비례하게 상승하고 응답 시간 또한 단일 검색보다 길어진다.

운영 환경에서 이러한 비용과 지연 시간을 관리하기 위해, 개발자는 스트림 형태의 트레이스 이벤트를 Amazon CloudWatch에 기록하여 비용 귀속 분석과 지연 시간 예산 책정, 디버깅에 활용해야 한다. 이는 내부 추론 과정을 투명하게 확인하여 예측 가능한 성능을 확보하는 필수적인 운영 절차다.

Retrieve와 AgenticRetrieveStream 도입 판단 기준

개발자는 질문의 형태와 요구되는 성능 수준에 따라 두 가지 쿼리 인터페이스 중 하나를 선택해야 한다. 단순한 사실 확인이나 검색 범위가 명확하여 한 번의 유사도 검색으로 충분한 짧은 질문에는 `Retrieve` API가 적합하다. 이는 플래너 과정이 없어 최저 비용과 최단 지연 시간을 보장하며, 답변 생성 과정을 개발자가 완전히 제어할 수 있다는 장점이 있다.

반면 질문이 여러 부분으로 나뉘어 있거나, 서로 다른 정보원 사이의 비교 분석이 필요하거나, 여러 지식베이스에 걸쳐 정보를 찾아야 하는 탐색적 질문에는 `AgenticRetrieveStream`을 도입해야 한다. 이 API는 비용이 더 높고 시간이 더 오래 걸리지만, 단일 검색이 놓치기 쉬운 증거를 찾아내어 답변의 정확도를 획기적으로 높인다.

**[API 선택 매트릭스]**

| 구분 | Retrieve API | AgenticRetrieveStream API |

| :--- | :--- | :--- |

| **질문 형태** | 단일 의도, 짧고 명확한 질문 | 다중 의도, 비교/탐색적 복합 질문 |

| **검색 범위** | 단일 지식베이스 내 유사도 검색 | 최대 5개 지식베이스 간 라우팅 및 통합 |

| **성능 특성** | 최저 지연 시간, 최저 비용 | 높은 리콜(Recall), 높은 지연 시간, 높은 비용 |

| **제어 방식** | 개발자가 직접 답변 합성 제어 | 모델이 계획-검색-평가 루프 자동 수행 |

| **추천 사례** | 단순 FAQ, 특정 문서 내 사실 확인 | 전략 비교 분석, 다수 문서 기반 종합 보고서 |

결론적으로, 단일 쿼리로 해결 가능한 단순 검색은 Retrieve를, 다중 단계의 추론과 여러 데이터원 통합이 필요한 복합 질문은 AgenticRetrieveStream을 선택하는 것이 비용과 성능의 최적 접점이다.