Agentic retrieval with LangChain and Amazon Bedrock Knowledge Bases

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Managed Knowledge Bases와 LangChain의 표준·에이전트형 검색을 비교하며, 단일 의도 질문에는 한 번의 검색이 적합하지만 여러 의도를 포함한 질문에는 검색 계획과 근거 충분성 판단이 필요하다고 설명한다.

📌 핵심 요약

• checkout과 inventory를 온콜 에스컬레이션, 백업·복구 목표, 배포 롤백 절차로 비교하는 질문은 6개 의도를 포함한다. 표준 검색에서 결과 5개는 코퍼스의 10%를 가져와 4개 의도만 충족했고, 결과 10개는 코퍼스의 19%로 6개 의도를 모두 충족했지만 중복 근거와 관련 근거가 없는 청크도 포함했다.
• Amazon Bedrock Managed Knowledge Bases는 청킹, 임베딩, 저장, 검색을 관리하며 자체 벡터 저장소·임베딩·재순위화 모델 운영 부담을 줄인다. 예제는 Amazon S3를 데이터 소스로 사용하고 MANAGED 임베딩을 설정하며, 생성 요청에 storageConfiguration을 넣지 않는다.
• Retrieve API는 한 번의 하이브리드 검색으로 점수가 있는 청크를 반환하고, AgenticRetrieveStream API는 질문 분해, 검색, 근거 충분성 판단, 필요시 재검색을 수행하며 단계별 추적 이벤트를 스트리밍한다. langchain-aws에서는 각각 AmazonKnowledgeBasesRetriever와 별도 함수 agentic_retrieve로 사용한다.
• 실행 전제는 지원 리전의 AWS 계정, Python 3.12 이상, langchain-aws>=1.6.3, langchain>=1.0, boto3>=1.43.32, 주제가 겹치는 여러 S3 문서다. 지식 기반 서비스 역할과 API 호출자 권한을 분리하며, FullDocumentExpansion에 필요한 bedrock:GetDocumentContent가 빠지면 검색 도중 실패할 수 있다.
• 단일 의도 질문에는 표준 검색이 두 경로 중 지연 시간이 가장 낮고 답변 생성 제어를 유지하는 선택이라고 설명한다. 문서 저장·수집, 검색 호출, 기반 모델 추론에 비용이 발생할 수 있지만, 제공된 원문은 agentic_retrieve 호출 예시 뒤에서 끊겨 에이전트형 검색의 실제 추적 결과와 구체적인 비용 비교는 확인할 수 없다.

🧩 주요 포인트

1. 개 의도를 결과 5개로 검색할 때 근거가 누락되고 10개로 늘리면 중복이 발생한다 → 결과 수 확대는 사례의 누락을 해결하지만 질문별 근거 충분성 판단을 대신하지는 않는다.
2. Retrieve와 AgenticRetrieveStream은 검색 절차와 LangChain 연결 방식이 다르다 → 단일 의도에는 표준 검색을, 복합 질문에는 계획과 재검색이 가능한 경로를 검토할 근거가 된다.
3. MANAGED 구성으로 저장 계층 운영을 맡겨도 버전·권한 제약은 남는다 → boto3>=1.43.32와 bedrock:GetDocumentContent 같은 실행 조건이 정상 동작에 영향을 준다.

🧠 상세 정리

1. 복합 질문에서 드러나는 검색의 누락

원문은 LangChain으로 만든 RAG 지원 도우미에게 두 제품을 세 가지 기준으로 비교하도록 요청하면 사실상 여섯 질문을 동시에 던지는 셈이라는 문제에서 시작한다. 유사도 검색은 이 여러 의도를 하나의 질의 벡터에 담고, 검색기는 그 의도들의 평균에 가까운 결과를 찾는다고 설명한다. 이때 답변은 간결하고 검색 오류도 없으며 관련성 점수도 합리적으로 보일 수 있지만, 검색된 청크가 질문의 일부만 뒷받침할 수 있다. 따라서 주제상 관련성이 있다는 사실과 질문의 모든 부분에 필요한 근거가 있다는 사실을 구분해야 한다는 것이 글의 출발점이다. 글은 같은 복합 질문을 표준 검색과 에이전트형 검색에 넣어 비교하고, 모델의 검색 계획을 추적 이벤트로 살펴보며 비용과 선택 기준도 다루겠다고 예고한다.

2. 관리형 지식 기반과 두 검색 경로

Amazon Bedrock Managed Knowledge Bases는 Amazon Bedrock의 완전관리형 RAG 기능으로, 사용자가 벡터 저장소와 임베딩 및 재순위화 모델을 직접 운영하는 부담을 제거한다고 소개된다. 데이터 소스를 설정하면 서비스가 청킹, 임베딩, 저장, 검색을 처리하며, 이 예제에서는 Amazon Simple Storage Service인 Amazon S3를 사용한다. Retrieve API는 한 번의 하이브리드 검색을 수행해 점수가 부여된 청크를 반환하고, AgenticRetrieveStream API는 계획 반복 과정을 수행하면서 각 단계를 추적 이벤트로 스트리밍한다. 에이전트형 경로는 질문을 하위 질의로 나누고 검색한 다음, 확보한 근거가 충분한지 판단해 부족하면 다시 검색한다. 두 경로 모두 지식 기반의 문서 청크를 반환하며, 애플리케이션은 이를 근거로 답변을 생성하는 구조다. langchain-aws는 표준 경로를 LangChain 검색기로, 에이전트형 경로를 별도 함수로 제공한다.

3. 실행 환경과 문서 구성의 전제

예제를 실행하려면 Amazon Bedrock Managed Knowledge Bases와 에이전트형 검색을 지원하는 리전에서 Amazon Bedrock에 접근할 수 있는 AWS 계정이 필요하다. 설명과 코드는 US East (N. Virginia) 리전인 us-east-1을 전제로 하며, 다른 리전의 가용성과 지원 여부는 AWS 문서에서 확인하도록 안내한다. Python은 3.12 이상이어야 하고 패키지 조건은 langchain-aws>=1.6.3, langchain>=1.0, boto3>=1.43.32로 제시된다. 특히 agentic_retrieve_stream은 Boto3 1.43.32 이전에 존재하지 않았으므로 해당 버전 조건이 실제 API 호출 가능 여부에 영향을 준다. S3 버킷에는 주제가 서로 겹치는 여러 문서가 있어야 비교 질문의 검색 계획을 보여줄 수 있으며, 하나의 평면적인 문서만으로는 이를 시연할 수 없다고 설명한다.

4. 서비스 역할과 호출자 권한의 분리

권한은 지식 기반이 문서를 읽고 임베딩 모델을 호출하는 서비스 역할과, 애플리케이션이 AWS STS 호출자 자격으로 API를 실행하는 권한으로 나뉘며 서로의 권한을 공유할 필요가 없다고 설명한다. 직접 서비스 역할을 제공한다면 Amazon Bedrock이 역할을 맡을 수 있는 신뢰 정책을 두고 aws:SourceAccount와 aws:SourceArn으로 범위를 제한하며, S3의 s3:ListBucket과 s3:GetObject에도 aws:ResourceAccount 조건을 적용한다. 지식 기반 생성 후에는 knowledge-base/* 범위를 구체적인 지식 기반 ID로 좁히도록 안내한다. 호출자의 bedrock:AgenticRetrieveStream과 bedrock:InvokeModelWithResponseStream은 지식 기반 ARN으로 범위를 제한할 수 없지만, bedrock:Retrieve와 bedrock:GetDocumentContent는 제한할 수 있다. 특히 FullDocumentExpansion이 전체 문서를 요청할 때 bedrock:GetDocumentContent가 없으면 질의 처리 중간에 실패할 수 있고, 지식 기반 생성·관리 및 가드레일 사용에는 별도 권한도 필요하다. 실험에는 문서 저장·수집, 검색 호출, 기반 모델 추론 비용이 발생할 수 있으므로 가격 정보를 확인하고 종료 후 자원을 삭제하도록 안내한다.

5. 지식 기반 생성과 비동기 문서 수집

지식 기반 생성 예시는 knowledgeBaseConfiguration의 type을 MANAGED로 지정하고 managedKnowledgeBaseConfiguration 안의 embeddingModelType도 MANAGED로 설정한다. 이 구성은 서비스가 관리하는 임베딩 모델을 사용하며, 생성 응답에서 knowledgeBaseId를 얻어 이후 작업에 활용한다. 요청에는 storageConfiguration이 없는데, 원문은 자체 관리형 지식 기반에서는 벡터 저장소 구성을 전달하는 반면 관리형 지식 기반에서는 Amazon Bedrock이 저장 계층을 소유한다는 차이를 강조한다. 다음 단계는 S3 버킷을 데이터 소스로 연결하고 수집 작업을 시작하는 것으로, 수집이 비동기이므로 고정 시간만 기다리지 말고 종료 상태까지 조회해야 한다. 예제 함수는 15초마다 상태를 확인해 COMPLETE이면 반환하고 FAILED 또는 STOPPED이면 실패 사유와 함께 오류를 발생시키며, 기본 제한 시간인 1,800초를 넘으면 시간 초과로 처리한다. 전체 데이터 소스 구성과 오류 처리는 샘플 저장소에 있다고 안내하지만, 그 내용 자체는 제공된 원문에 포함되지 않는다.

6. 표준 LangChain 검색기의 설정과 용도

AmazonKnowledgeBasesRetriever는 Retrieve API를 감싸며 일반적인 LangChain 검색기처럼 체인에 넣어 사용할 수 있다. Amazon Bedrock Managed Knowledge Bases에서는 retrieval_config에 managedSearchConfiguration을 전달해야 하며, 기존 예제에서 흔히 보이는 vectorSearchConfiguration은 사용자가 벡터 저장소를 운영하는 지식 기반의 경로라고 구분한다. 예제는 checkout 서비스의 복구 시간 목표를 묻는 단일 의도 질문에 numberOfResults를 5로 설정해 검색한다. 반환값은 LangChain Document이고 관련성 점수는 metadata["score"], 원본 문서의 메타데이터는 충돌을 피하도록 이름을 바꾼 metadata["source_metadata"]에 들어간다. 낮은 신뢰도의 결과를 제외하려면 사후 필터링보다 검색기의 min_score_confidence 설정을 사용하도록 안내한다. 원문은 명확한 단일 의도 질문에는 한 번의 호출로 끝나고 두 경로 중 지연 시간이 가장 낮으며 답변 생성 제어도 유지하는 표준 검색이 적합하고, 이런 질문에 계획 반복을 적용하면 시간과 비용을 낭비한다고 주장한다.

7. 결과 수 확대의 효과와 구조적 한계

복합 질문 예시는 checkout과 inventory 서비스를 온콜 에스컬레이션, 백업·복구 목표, 배포 롤백 절차라는 세 차원에서 비교해 차이를 묻는다. 두 서비스와 세 차원의 조합으로 여섯 의도가 생기지만, 표준 검색은 질문 전체를 나타내는 하나의 임베딩에 대해 하이브리드 점수로 청크를 정렬한다. numberOfResults가 5일 때는 청크 5개, 코퍼스의 10%를 가져와 여섯 의도 중 네 개만 충족했고 checkout 온콜과 inventory 복구 근거가 빠졌다. 결과 수를 10으로 늘리면 청크 10개, 코퍼스의 19%로 여섯 의도를 모두 충족했지만, 두 하위 의도는 중복으로 다뤄지고 한 청크는 어느 하위 의도의 근거도 담지 않았다. 원문은 이를 검색기의 실행 실패가 아니라 여러 의도를 하나의 벡터로 표현하는 구조와 반환 근거의 충분성을 확인하는 단계가 없다는 한계로 해석한다. 이 사례는 결과 수 확대가 누락을 해결할 수 있어도 불필요한 검색 결과까지 함께 늘어날 수 있음을 보여준다.

8. 에이전트형 검색 호출과 확인 가능한 범위

에이전트형 검색은 LangChain 검색기 자체가 아니라 Amazon Bedrock Managed Knowledge Bases의 기능이며, langchain-aws는 이를 agentic_retrieve라는 독립 함수로 노출한다. 기반 API가 결과를 스트리밍해 동기식 BaseRetriever 인터페이스에 맞지 않기 때문에 AmazonKnowledgeBasesRetriever의 플래그를 바꿔 활성화하는 방식은 제공되지 않는다. 예제는 langchain_aws.retrievers.bedrock에서 함수를 가져와 같은 복합 질문에 knowledge_base_id, region_name, generate_response=True, number_of_results=10을 전달한다. 이어 result["generatedResponse"]["answer"]를 출력하는 코드를 보여주지만, 제공된 원문은 generate_response=True일 때 서비스가 반환하는 내용을 설명하려는 문장 도중에 끝난다. 따라서 실제 하위 질의, 반복 검색 횟수, 추적 이벤트의 구체적인 내용이나 에이전트형 검색의 근거 충족 결과는 이 자료만으로 확인할 수 없다. 도입부에서 예고한 두 경로의 구체적 비용 비교 역시 제공 범위에 없으므로, 표준 검색과 에이전트형 검색의 일반적인 선택 논리까지를 확인 가능한 설명으로 남겨야 한다.

🧾 핵심 주장 / 시사점

• 검색 오류가 없고 관련성 점수가 합리적으로 보여도 복합 질문의 근거가 모두 확보됐다고 판단할 수는 없다. 원문 사례처럼 하위 의도별 근거 충족 여부를 살펴봐야 누락을 발견할 수 있다.
• 관리형 지식 기반은 저장·임베딩 운영 부담을 줄이지만, managedSearchConfiguration 선택과 API별 권한 범위 같은 통합 조건까지 없애지는 않는다.
• 에이전트형 검색의 계획·재검색 기능은 복합 질문의 한계에 대응하는 방식으로 제시되지만, 제공된 원문에는 실제 실행 결과와 비용 수치가 없어 개선 폭이나 경제성을 확정할 수 없다.

✅ 액션 아이템

• 단일 의도 질문에는 Retrieve를 우선 적용하고, 6개 의도 같은 복합 질문에는 AgenticRetrieveStream의 계획·재검색 경로 적용을 검토한다.
• 결과 5개와 10개에서 나타난 근거 누락·중복을 기준으로, 복합 질문의 하위 의도별 근거 충족 여부를 확인한다.
• 실행 전 boto3>=1.43.32 등 버전 조건과 bedrock:GetDocumentContent 권한을 확인하고, 지식 기반 서비스 역할과 API 호출자 권한을 분리한다.

❓ 열린 질문

• AgenticRetrieveStream은 checkout과 inventory의 6개 의도에 대해 표준 검색에서 나타난 누락과 중복을 얼마나 줄이는가?
• 표준 검색과 agentic_retrieve의 실제 추적 결과 및 구체적인 비용 비교는 어떠한가?
• 단일 의도에는 표준 검색을 적용하고 복합 질문에는 계획·재검색 경로를 적용할 때, 지연 시간과 비용을 고려한 선택 기준은 무엇인가?