이 참조 아키텍처는 이벤트 리드인, 의미론 검색 및 에이전틱 실행을 위해 Temporal를 사용하여 MongoDB Atlas에서 지속형 AI 워크플로를 빌드하는 방법을 설명합니다.
검색 증강 생성(RAG)과 다단계 AI 워크플로우가 작업 실패, 재시도 및 장기 작업에서 신뢰할 수 있도록 지속되는 필요한 팀을 지원합니다.
이 아키텍처는 두 가지 수집 패턴을 지원합니다. 이벤트 스트림 패턴에서 소스 업데이트는 Kafka와 Atlas Stream Processing을 통해 흐릅니다. Temporal을 호출하기 전에. 직접 패턴에서 소스 업데이트는 Temporal 워크플로우를 즉시 trigger합니다. 두 경우 모두 MongoDB Atlas는 운영 데이터, 의미론적 지식 및 애플리케이션 상태를 저장하고 Temporal은 추출, 청크, 임베딩, 인덱싱 및 검색 작업을 조정합니다.
해결책 1: Kafka와 Atlas Stream Processing을 통한 수집
이 패턴은 이벤트 전송, 변경 전파 또는 분리된 시스템 통합을 위해 Kafka를 이미 사용하는 환경에 적합합니다. Kafka는 고요량 또는 다양한 소스 업데이트를 위한 표준 입력 계층을 제공하며, Atlas Stream Processing은 Temporal을 호출하기 전에 이벤트를 변환하고 라우팅합니다. 이러한 분리는 수집이 워크플로우 실행과 독립적으로 확장되어야 하는 경우 또는 팀이 AI 파이프라인 외에도 여러 다운스트림 소비자에 걸쳐 있는 공통 이벤트 백본을 원하는 경우 중요합니다. 컨텐츠 업데이트는 S3, API 또는 데이터베이스 또는 메시지징 시스템과 같은 다양한 플랫폼에서 시작됩니다.
다이어그램
다음 다이어그램은 이 흐름을 보여줍니다.
그림 1. Kafka 및 Atlas Stream Processing을 통한 수집
데이터 흐름
다음 단계는 이 플로우를 설명합니다.
소스 시스템이 콘텐츠를 생성하거나 노출합니다.
콘텐츠는 Amazon S3, IoT 플랫폼 및 운영 데이터베이스와 같은 업스트림 시스템에서 온 것입니다. 이 시스템은 파이프라인이 처리하는 원본 문서, 기록 또는 이벤트를 제공합니다. 새 컨텐츠 또는 업데이트된 컨텐츠를 사용할 수 있게 되면 소스 시스템은 이벤트를 Kafka Sink Connector에 발생하고, 이는 이벤트를 MongoDB
sources컬렉션에 쓰기 합니다.Kafka Sink Connector
Kafka Sink Connector는 스트리밍 계층과 MongoDB 사이의 지속형 메시지 핸드오프입니다. Kafka 주제에서 이벤트를 소비하고 문서로 MongoDB Atlas에 쓰기를 수행합니다. 이 컴포넌트는 직접 trigger가 제공하지 않는 두 가지를 제공합니다. 즉, 여러 가지 소스를 하나의 정렬된 스트리밍으로 팬인하고 백프레시어에 대한 버퍼링을 수행합니다.
MongoDB(Atlas, Stream Processing 및 벡터 검색)
MongoDB는 이 아키텍처에서 흐름의 두 개 다른 지점에 나타나면서 이중 역할을 합니다.
MongoDB Atlas는 Kafka Sink Connector 이벤트의 랜딩 구역입니다. Sink Connector가 쓰는 원본 소스 문서는 외부에서 도착한 내용의 스테이징 기록으로 Atlas에 있습니다.
Atlas Stream Processing 해당 랜딩 구역 과 Temporal 사이의 trigger 역할을 합니다. 변경 스트림을 통해 수신 문서를 감시하고 다운스트림 워크플로를 시작합니다. 이렇게 하면 MongoDB 패시브 저장 에서 액티브 이벤트 소스로 전환되어 폴링 루프가 필요하지 않고 예약이 아닌 Temporal 이벤트 기반으로 핸드오프가 이루어집니다.
Atlas Vector Search 별도의 벡터 데이터베이스 나 교차 시스템 쿼리 팬아웃 없이 시맨틱 유사성 검색 네이티브 집계 파이프라인 단계로 실행 에이전트 에 대한 읽기 경로를 제공합니다.
MongoDB는 데이터 플로우의 양측에 모두 나타납니다. 원시 이벤트를 수신하고 최종 내장 벡터를 제공합니다. Atlas Stream Processing은 이 두 개를 연결합니다.
Temporal 및 Voyage AI 임베딩
Atlas Stream Processing은 Temporal이 이벤트를 직접 수신하는 대신 Temporal을 호출합니다. 처리 코어는 해결 2의 경우와 동일합니다. Temporal 워크플로우는 지속형 재개가 가능한 오케스트레이션을 제공하고 Voyage AI 임베딩은 이러한 워크플로우 내에서 독립적으로 재시도할 수 있는 작업으로 실행됩니다.
이 해결책에서 Temporal은 소스 이벤트를 직접 수신하는 대신 MongoDB 이벤트를 소비합니다. 이 trigger가 S3, IoT 또는 데이터베이스에서 시작되었는지 여부에 관계없이 Atlas Stream Processing에서 깨끗하고 정규화된 trigger만 수신합니다. 이 단계는 양방향입니다. 처리가 완료되면 Temporal은 이벤드된 인덱스 청크를 MongoDB 지식 컬렉션에 다시 쓰기합니다.
해결책 2: 데이터 소스를 Temporal에 직접 수집
이 패턴은 객체, API 또는 애플리케이션 이벤트를 직접 워크플로우 trigger로 발사할 수 있는 시스템에 적합합니다. 이로써 아키텍처 계층이 줄어들고 수집 경로가 간단해지면서도 장기 수행 추출 및 임베딩 단계에 대한 재개시작 가능성은 유지됩니다. 워크플로우가 원시 참조로 트리거되는 경우 하위 파이프라인은 원시 알리지 않게 유지되며 최소한 오케스트레이션 변경으로 추가 상위 시스템을 지원할 수 있습니다.
다이어그램
다음 다이어그램은 이 흐름을 보여줍니다.
그림 2. 데이터 소스를 시간적으로 직접 수집
데이터 흐름
다음 단계는 이 플로우를 설명합니다.
소스 시스템이 콘텐츠를 생성하거나 노출합니다.
콘텐츠는 Amazon S3, IoT 플랫폼 및 운영 데이터베이스와 같은 업스트림 시스템에서 온 것입니다. 이 시스템은 파이프라인이 처리하는 원본 문서, 기록 또는 이벤트를 제공합니다. 새 또는 업데이트된 콘텐츠를 사용할 수 있게 되면 소스 시스템은 AWS Lambda, 웹훅 또는 커넥터와 같은 가별운 어댑터에 이벤트를 발생합니다. 어댑터는 Temporal 워크플로우를 시작하고 소스 참조 및 필요한 메타데이터만 전달합니다. 이렇게 하면 워크플로우 외부에 소스 특정 노직이 있어 하위 파이프라인을 변경하지 않고도 새 소스 유형을 추가할 수 있습니다.
Temporal은 수집 수명 주기를 관리합니다.
워크플로우가 시작되면 Temporal은 수집 단계에서 실행, 재시도 및 복구를 조정합니다. 이로인해 처리 경로가 지속형이 되어 장기 작업이 실패 또는 재시작에 서도 신뢰할 수 있게 계속됩니다. 워크플로우는 소스 콘텐츠를 조회하여 하위 AI 처리를 위한 정규형으로 변환하여 의미 변환이 시작되기 전에 소스 유형에 걸쳐 일관적인 표현을 만듭니다.
Voyage AI는 워크플로 내부에서 임베딩을 생성합니다.
Voyage AI 임베딩은 워크플로우의 일부로 실행되며 외부에서 실행되는 일회성 단계가 아닙니다. 이렇게 하면 동일한 실행 경로 내에서 임베딩을 관찰하고 복구할 수 있으며, 임베딩의 의미론적 변환이 수집 수명 주기와 강력하게 연결됩니다.
MongoDB Atlas에는 콘텐츠, 메타데이터 및 임베딩이 저장됩니다.
MongoDB Atlas는 처리된 콘텐츠, 관련 메타데이터 및 임베딩 벡터를 단일 플랫폼에 지속형으로 유지합니다. 이로써 입력 쓰기 (write) 경로와 하위 검색 경로 모두를 지원하는 지속형 지식 계층이 생성됩니다.
Atlas Vector Search를 통해 지식을 검색할 수 있습니다.
Atlas Vector Search는 임베딩된 콘텐츠를 인덱스하여 의미적 유사성으로 쿼리할 수 있습니다. 임베딩과 운영 메타데이터가 동일한 플랫폼에 있으므로 이후 애플리케이션 및 에이전트 요청은 별도의 벡터 저장소 또는 동기화 계층 없이 관련 컨텍스트를 조회합니다.
에이전트 요청 흐름
이 플로우는 두 가지 수집 솔루션에 모두 적용됩니다. 에이전트 실행을 단기간 API 요청으로 처리하는 대신 수집과 동일한 내구성 원칙을 사용합니다. 아키텍처는 검색과 추론을 관찰, 재시도 및 재개할 수 있는 워크플로우 기반 작업으로 실행합니다. 에이전트가 여러 개의 검색 호출을 수행하거나 외부 도구를 호출하거나 최종 결과 전에 점진적 상태 업데이트를 반환해야 할 때 이것이 중요합니다.
다이어그램
다음 다이어그램은 에이전트의 구성 요소를 보여줍니다.
그림 3. 에이전트 아키텍처 연구
데이터 흐름
다음 단계는 이 플로우를 설명합니다.
에이전트 연구 요청 시작
에이전트 API가 UI를 통해 사용자 쿼리를 수신하면 지속형 Temporal 워크플로우가 시작됩니다. 시스템은 워크플로우 식별자를 즉시 반환하므로 연구 에이전트가 문맥을 조회하고 답변을 추론하는 동안 UI는 진행 상태를 추적할 수 있습니다.
MongoDB Atlas Vector Search에서 컨텍스트 조회
MongoDB Atlas는 메타데이터, 벡터 임베딩 및 의미 인덱스를 호스팅합니다. 사용자 상호 작용 중에 에이전트는 쿼리를 임베딩하고 MongoDB Atlas Vector Search를 사용하여 관련 컨텍스트를 조회하며, 최종 합성 전에 재순위 계층을 적용하는 경우가 많습니다. 인덱싱 및 쿼리 패턴에 대해서는 Atlas Vector Search 문서를 참조하세요.
지속형 연구 결과 반환
연구 워크플로우는 도구 실행, 모델 작용 및 최종 합성을 조정합니다. Temporal은 재시도 및 상태 지속성을 통해 프로세스를 유지하므로 UI는 유효성이 검증된 답변을 제공합니다. 지속형 실행에 대한 자세한 내용은 Temporal 문서를 참조하십시오.
구성 요소
다음 구성 요소는 이 아키텍처를 구현합니다.
MongoDB Atlas
MongoDB Atlas를 사용하여 수집 파이프라인의 스테이징 및 이벤디드된 청크, MongoDB Atlas Vector Search 인덱스 및 에이전트의 상태를 단일 데이터베이스에 저장합니다. 에이전트는 수집 파이프라인이 쓰는 동일한 데이터를 읽으므로 동기화할 별도의 메모리 저장소가 없습니다.
Atlas Stream Processing
Atlas Stream Processing를 사용하여 스트리밍 소스와 Temporal 워크플로우 간에 선택 사항인 이벤트 기반 통합 경로를 제공합니다. 이는 높은 처리량 아키텍처를 위해 수신 이벤트의 실시간 변환 및 라우팅을 처리합니다. 이를 통해 직접 소스-Temporal 연결을 선택하는 경우 Kafka 없이도 거의 실시간 수집을 구현할 수 있습니다.
Voyage AI
Voyage AI를 사용하여 이 아키텍처에 대한 임베딩을 생성하고 결과를 다시 순위를 매기세요. 임베딩과 다시 순위 매기는 워크플로우 오케스트레이션과 별개되므로 팀은 수집 및 검색 파이프라인과 동리적으로 모델을 업그레이드할 수 있습니다.
Atlas Vector Search
MongoDB Atlas Vector Search을 사용하여 시맨틱 인덱싱을 통해 문서 컨텍스트와 에이전트 메모리를 조회합니다. 연구 에이전트는 프라이머리 저장에 사용되는 동일한 MongoDB Atlas 클러스터를 쿼리하므로 조회에 현재 운영 데이터가 사용됩니다.
임시
소스 시스템, MongoDB Atlas 및 외부 AI 서비스에 걸쳐 인제스터션 및 에이전트 워크플로우의 지속형 실행 계층으로 Temporal을 사용합니다. 추출, 청크, 임베딩 및 인덱싱과 같은 장기 실행 단계를 조정하고 내장 재시도, 체크포인트 및 복구를 제공합니다. 이를 통해 워크플로우는 실패 또는 중단 후 다시 시작하는 대신 마지막으로 성공한 상태에서 재개될 수 있습니다. 오케스트레이션을 지속형으로 만들어 Temporal은 팀이 생산 AI 파이프라인을 신뢰할 수 있게 운영, 백필 및 진화하는 데 도움을 줍니다.
예외, 주의 사항 및 장단점
이 아키텍처를 채택하기 전에 직접 수집과 Kafka 기반 수집 간의 트레이드오프를 고려하세요. 직접 소스에서 Temporal에 연결하면 작업할 부분이 적습니다. Kafka 기반 경로에는 메시지 브로커가 추가되어 추가 인프라스트럭처가 생기지만, 조직에서 이미 Kafka를 통해 소스 업데이트를 보내는 경우 자연스럽습니다.
구현 및 자세히 알아보기
배포 지침 및 기술 문서는 mdb-temporal-pra Github 리포지토리를 참조하십시오.