Single-shot and agentic retrieval with Amazon Bedrock Managed Knowledge Base

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Managed Knowledge Base는 AgenticRetrieveStream의 maxAgentIteration을 0–5로 확장해, 하나의 API에서 원문 구절 반환·단일 검색 후 답변 생성·복잡한 질문을 위한 에이전트형 검색을 요청별로 선택하도록 지원한다.

📌 핵심 요약

• maxAgentIteration=1과 generateResponse=true를 사용하면 쿼리 재작성이나 에이전트형 계획 없이 한 번 검색하고 기반 모델을 한 번 호출해 답변을 생성한다. 범위가 명확한 직접 질문에 적합하며, 에이전트형 검색보다 지연 시간과 모델 사용량을 줄일 수 있다.
• maxAgentIteration=0은 기반 모델 호출 없이 한 번의 검색을 보장하고 관련 구절만 반환한다. generateResponse=false로 사용하며, generateResponse=true를 설정하면 답변 생성에 필요한 모델 호출이 허용되지 않아 4xx 오류가 발생한다.
• maxAgentIteration=2–5는 기존 에이전트형 검색 동작을 유지한다. 답변 생성을 활성화하면 값 n에 대해 최대 n−1회의 계획 라운드 후 답변을 생성하며, 복합 질문을 하위 질문으로 나누고 근거가 부족하면 검색을 보완할 수 있다.
• 세 모드 모두 여러 지식 기반을 지원한다. 반복 1회는 기반 모델 호출 1회이며, 첫 계획 단계에 앞서 실행되는 추측적 검색은 반복 한도에 포함되지 않는다. 모드 선택은 애플리케이션 로직의 책임이며, maxAgentIteration이 자동으로 요청을 분류하지는 않는다.
• 가상의 은행 정책 도우미는 단순 서류 조회에 maxAgentIteration=1, 정책 비교에 maxAgentIteration=4, 원문 검토에 maxAgentIteration=0을 사용하는 예를 제시한다. 이는 실제 고객 배포나 측정 결과가 아니며, 반복 한도는 대표 질문으로 평가해야 한다. 도우미는 계좌를 승인하거나 은행의 검토·인가 절차를 대체하지 않는다.

🧩 주요 포인트

1. 동일한 AgenticRetrieveStream에서 검색 노력 조절 → 단순 조회와 복합 비교를 위해 별도 API나 코드 경로를 유지할 필요를 줄인다.
2. 여러 지식 기반은 세 모드 모두 지원 → 에이전트형 검색의 차별점은 지식 기반 수가 아니라 질문 분해·근거 평가·반복 검색에 있다.
3. 반복 한도 확대는 추가 탐색 기회를 제공 → 높은 값이 항상 더 좋은 답변을 보장한다고 가정하지 않고, 대표 질문에서 정확도와 지연 시간을 함께 평가해야 한다.

🧠 상세 정리

1. 질문 복잡도에 맞춰 검색 노력을 조절해야 하는 이유

글은 은행 운영 직원이 내부 AI 도우미에 서로 다른 난도의 질문을 하는 상황에서 출발한다. 사업용 계좌 개설에 필요한 서류를 묻는 질문은 하나의 체크리스트로 답할 수 있지만, 개인사업자·LLC·복수 소유자가 있는 파트너십의 요건을 비교하려면 여러 정책 지침을 살펴봐야 한다. 같은 도우미가 첫 질문에는 빠르고 적은 비용으로, 두 번째 질문에는 충분한 근거를 모아 답해야 한다는 것이 문제의식이다. Amazon Bedrock Managed Knowledge Base는 기존 에이전트형 검색에 단일 검색 기반 RAG와 원문 구절만 반환하는 방식을 추가해 이 요구를 지원한다. 애플리케이션은 AgenticRetrieveStream이라는 동일한 API를 사용하면서 요청마다 검색과 답변 생성에 투입할 노력을 선택할 수 있다.

2. 에이전트형 검색의 기능과 이점

에이전트형 검색에서는 기반 모델이 원래 질문을 하위 질문으로 나누고 관련 지식 기반을 검색한 뒤, 확보한 정보가 답변에 충분한지 평가한다. 근거가 부족하면 설정된 반복 한도 안에서 검색을 수정하거나 추가 증거를 가져올 수 있으며, 검색된 구절만으로 맥락이 부족할 때는 전체 문서를 가져올 수도 있다. 은행 사례에서는 개인사업자와 LLC의 요건을 각각 찾아 비교하는 식으로 복합 질문의 각 부분에 필요한 근거를 수집한다. 답변 생성을 활성화하면 검색 정보를 인용이 포함된 답변으로 결합하고, 추적 이벤트는 개발자가 계획과 검색 과정을 확인하도록 돕는다. 서비스가 계획·검색·평가·답변 생성 흐름을 관리하므로 애플리케이션이 이를 조정하는 자체 반복 루프를 구현할 필요도 줄어든다.

3. 반복 횟수의 의미와 여러 지식 기반 지원

원문에서 반복 1회는 검색 횟수가 아니라 기반 모델 호출 1회를 뜻하며, 답변을 생성하는 흐름에서는 마지막 호출이 응답 생성에 사용된다. 따라서 답변 생성이 활성화된 경우 maxAgentIteration 값이 n이면 최대 n−1회의 에이전트형 계획 라운드를 수행할 수 있고, 각 계획 라운드는 쿼리 재작성과 검색으로 구성된다. 첫 계획 단계보다 앞서 실행되는 추측적 검색은 모델 호출이 아니므로 반복 한도에 포함되지 않으며, 글은 이를 요청을 더 빠르게 만드는 검색으로 설명한다. 새 범위는 0–5이고, 0과 1을 포함한 세 모드 모두 여러 지식 기반을 지원하므로 단일 검색이 지식 기반 하나만 검색한다는 뜻은 아니다. 에이전트형 모드가 추가하는 것은 여러 지식 기반에 대한 독점적 접근이 아니라 질문 분해, 근거 평가, 반복 검색이다.

4. maxAgentIteration=1: 한 번 검색하고 답변 생성

maxAgentIteration=1은 한 번 검색한 뒤 한 번 답변을 생성하는 단일 검색 기반 RAG 설정이다. 에이전트형 계획이나 쿼리 재작성 없이 입력 쿼리로 관련 구절을 가져오고, generateResponse=true와 함께 사용하면 그 구절에 근거한 답변을 생성한다. 이는 기존에 이 API로 표현할 수 없었던 ‘한 번 검색한 뒤 응답 생성’ 패턴을 지원한다는 의미이며, 원문은 대부분의 요청이 범위가 명확한 직접 질문이라면 기본값으로 고려할 만하다고 설명한다. 기반 모델은 답변 생성을 위해 한 번 호출되므로 에이전트형 검색과 비교해 지연 시간과 모델 사용량을 줄일 수 있다. 은행 예시에서는 개인사업자의 사업용 당좌예금 계좌 개설 서류가 전용 체크리스트에 정리되어 있어, 별도의 계획 단계 없이 관련 구절을 검색하고 답변하는 방식이 적합하다.

5. maxAgentIteration=0: 모델 호출 없이 원문 구절 반환

maxAgentIteration=0은 한 번의 검색을 보장하면서 답변을 생성하지 않고 관련 원문 구절만 반환한다. 기반 모델을 전혀 호출하지 않으며, 원문은 이 동작을 Retrieve API를 직접 호출하는 것과 동등하다고 설명한다. 특히 이미 AgenticRetrieveStream을 표준으로 사용하는 호출자가 API를 바꾸는 대신 매개변수만 조정해 검색 전용 동작을 얻고자 할 때 유용하다. 이 설정에서는 모델 호출이 없으므로 생성할 답변도 없으며, generateResponse=true를 지정하면 답변 생성에 모델 호출이 필요하다는 제약 때문에 4xx 오류가 반환된다. 은행 직원이 생성된 요약보다 계좌 개설 절차의 정책 문구 자체를 검토하려는 경우에는 generateResponse=false로 요청하고, 애플리케이션이 반환된 구절과 출처 참조를 표시할 수 있다.

6. maxAgentIteration=2–5: 복합 질문에 대한 반복 검색

maxAgentIteration=2–5는 기존 에이전트형 검색의 동작을 유지하며, 기반 모델이 복잡한 질문을 집중된 하위 질문으로 나누어 여러 단계로 근거를 검색한다. 검색한 정보가 충분한지 평가하고 부족한 부분을 보완할 수 있어, 한 번의 검색으로 충분히 다루기 어려운 복합 질문이나 비교 질문의 검색 정확도를 높일 수 있다. 답변 생성을 활성화하면 설정값 n에 대해 최대 n−1회의 계획 라운드를 수행한 뒤 수집한 근거를 바탕으로 답변을 생성한다. 은행 사례에서는 개인사업자와 LLC의 계좌 개설 요건 차이, 비거주 소유자에게 적용되는 추가 확인 사항을 묻는 질문에 maxAgentIteration=4와 generateResponse=true를 사용해 최대 세 번의 계획 라운드를 허용한다. 다만 원문은 높은 값이 항상 더 좋은 답변을 만든다고 가정하지 말고, 대표 질문을 통해 적절한 반복 한도를 평가해야 한다고 강조한다.

7. 요청별 선택 기준과 애플리케이션의 책임

모드 선택의 기본 기준은 필요한 결과가 원문 구절인지 생성된 답변인지, 그리고 질문에 여러 단계의 탐색이 필요한지에 있다. 원문 구절만 필요하면 0, 범위가 명확한 직접 질문의 답변에는 1, 복합·비교·탐색 질문이나 여러 지식 기반을 아우르는 질문에는 2–5를 고려할 수 있다. 낮은 값은 더 빠르고 예측 가능한 호출에 유리하고, 높은 값은 어려운 질문을 분해하고 검색을 정교하게 할 수 있는 계획 기회를 늘린다. 다만 여러 지식 기반 검색 자체는 모든 모드가 지원하므로, 지식 기반 수만으로 에이전트형 모드의 필요성을 판단해서는 안 된다. 세 방식은 모두 AgenticRetrieveStream을 사용하지만, 요청에 어떤 모드를 적용할지는 애플리케이션 로직이 결정하며 이 매개변수가 자동 라우팅을 제공하는 것은 아니다.

8. 은행 예시의 범위와 제공된 구현 자료의 한계

원문에 등장하는 은행은 계좌 개설 절차, 서류 체크리스트, 정책 지침을 지식 기반으로 사용하는 가상의 조직이다. 세 업무 흐름은 직접적인 서류 질문에 답하기, 여러 정책 문서의 요건 비교하기, 생성 답변 없이 원문 구절 검토하기이며, 실제 고객 배포나 측정 결과를 설명하는 사례는 아니다. 도우미의 역할은 문서화된 정책의 조회와 비교를 지원하는 데 한정되며, 계좌를 승인하거나 은행의 검토 및 인가 절차를 대신하지 않는다. 이어지는 솔루션 설명은 에이전트형 요청을 먼저 보여주고 이를 단일 검색 RAG와 검색 전용 방식으로 조정하는 구성을 예고한다. 다만 제공된 본문은 messages와 retrievers를 포함한 요청 JSON의 지식 기반 설명 도중에 끝나므로, 전체 요청 코드나 이후 구현 세부 사항은 이 자료만으로 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 검색 방식의 통합은 모든 질문에 같은 처리량을 적용한다는 의미가 아니다. 동일한 AgenticRetrieveStream 안에서 질문의 복잡도와 원하는 출력에 맞춰 검색 노력을 조절하는 것이 핵심이다.
• 여러 지식 기반을 사용한다는 사실만으로 에이전트형 검색이 필요한 것은 아니다. 추가 계획이 유용한지는 질문 분해와 근거 보완이 필요한지에 달려 있다.
• 가상의 은행 사례는 설정 선택의 예시이며 성능 검증 자료는 아니다. 반복 한도의 효과는 대표 질문에서 평가해야 하고, 높은 값의 우월성을 전제로 삼아서는 안 된다.

✅ 액션 아이템

• 범위가 명확한 직접 질문에는 maxAgentIteration=1과 generateResponse=true의 기본 적용을 검토한다.
• 원문 구절만 필요한 요청에는 maxAgentIteration=0과 generateResponse=false를 적용하고, generateResponse=true로 인한 4xx 오류를 방지한다.
• 복합·비교 질문은 대표 질문으로 평가해 maxAgentIteration=2–5 범위에서 정확도와 지연 시간에 맞는 반복 한도를 선택한다.

❓ 열린 질문

• AgenticRetrieveStream을 사용하는 애플리케이션은 단순 조회와 복합 비교를 어떤 기준으로 구분해 모드를 선택할 것인가?
• 대표 질문에서 maxAgentIteration=1과 maxAgentIteration=4의 정확도와 지연 시간은 어떻게 달라지는가?
• 가상의 은행 정책 도우미에서 생성 답변보다 maxAgentIteration=0의 원문 구절 검토가 필요한 요청은 무엇인가?