Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

Criando fluxos de trabalho de IA duráveis com o Temporal e o MongoDB Atlas

Essa arquitetura de referência descreve como criar fluxos de trabalho de IA duráveis no MongoDB Atlas com o Temporal para ingestão orientada por eventos, recuperação semântica e execução agente.

Ele oferece suporte a equipes que precisam de geração aumentada de recuperação (RAG) e fluxos de trabalho de IA em várias etapas para continuar de forma confiável em meio a falhas, novas tentativas e operações de longa duração.

A arquitetura suporta dois padrões de ingestão. No padrão de fluxo de eventos, as atualizações de origem fluem através do Kafka e Atlas Stream Processing antes de invocar o Temporal. No padrão direto, as atualizações de origem acionam fluxos de trabalho Temporais imediatamente. Em ambos os casos, o MongoDB Atlas armazena dados operacionais, conhecimento semântica e estado do aplicação , enquanto o Temporal coordena operações de extração, agrupamento, incorporação, indexação e recuperação.

Esse padrão é adequado para ambientes que já usam o Kafka para transporte de evento , propagação de alterações ou integração desacoplada de sistemas. O Kafka fornece uma camada de entrada padrão para atualizações de alto volume ou variedade de fontes, enquanto o Atlas Stream Processing transforma e roteia eventos antes de invocar o Temporal. Essa separação é importante quando a ingestão deve ser dimensionada independentemente da execução do fluxo de trabalho ou quando as equipes desejam um backlink de evento comum em vários consumidores downstream, além do pipeline de IA. As atualizações de conteúdo são originadas de diversas plataformas, como S3, APIs, banco de dados ou sistema de mensagens.

O diagrama a seguir mostra esse fluxo.

Ingestão por meio do Atlas Stream Processing

figura 1. Ingestão por meio do Atlas Stream Processing

clique para ampliar

As etapas a seguir descrevem esse fluxo:

  1. Os sistemas de origem produzem ou expõem conteúdo

    O conteúdo se origina de sistemas upstream, como Amazon S3, plataformas IoT e bancos de dados operacionais. Esses sistemas fornecem os documentos, registros ou eventos brutos que o pipeline processa. Quando um conteúdo novo ou atualizado fica disponível, o sistema de origem emite um evento para o Conector do coletor Kafka, que o grava na coleção sources do MongoDB .

  2. Conector do coletor Kafka

    O conector Kafka Sink é a transferência de mensagens durável entre a camada de streaming e o MongoDB. Ele consome eventos dos tópicos do Kafka e os grava no MongoDB Atlas como documentos. Esse componente fornece duas coisas que o trigger direto não oferece: ele alimenta em fontes múltiplas e diversas em um fluxo ordenado e armazena contra a pressão de retorno.

  3. MongoDB (Atlas, Stream Processing e Vector Search)

    O MongoDB executa um papel duplo nesta arquitetura, aparecendo em dois pontos diferentes no fluxo.

    1. O MongoDB Atlas é a zona de aterrissagem dos eventos do Kafka Sink Connector. Documentos de origem brutos que o Conector de pia escreve ficam no Atlas como o registro de preparação do que chegou do mundo externo.

      O Atlas Stream Processing atua como o trigger entre essa zona de aterrissagem e o Temporal. Ele observa os documentos recebidos por meio de change streams e inicia o fluxo de trabalho downstream. Isso transforma o MongoDB de um armazenamento passivo em uma fonte de evento ativa, removendo a necessidade de um loop de pesquisa e fazendo a transferência para o Temporal orientada por eventos em vez de agendada.

    2. O Atlas Vector Search fornece o caminho de leitura para o agente, executando a pesquisa por similaridade semântica como um estágio de pipeline de agregação nativo, sem banco de dados vetorial separado e sem query multisistema.

    O MongoDB aparece em ambos os lados do fluxo de dados: ele recebe eventos brutos e atende aos vetores incorporados finais. O Atlas Stream Processing conecta os dois.

  4. Incorporação de IA temporal e de viagem

    O Atlas Stream Processing invoca o Temporal, em vez de o Temporal receber o evento diretamente. O núcleo de processamento é o mesmo da Solução 2: os fluxos de trabalho temporais fornecem uma orquestração durável e retomável, e a incorporação do Voyage AI é executada como atividades que podem ser repetidas de forma independente dentro desses fluxos de trabalho.

    Nesta solução, o Temporal consome eventos MongoDB em vez de receber eventos de origem diretamente. Ele só recebe um trigger limpo e normalizado do Atlas Stream Processing, independentemente de esse trigger ser originado de S3, IoT ou banco de dados. Esse estágio é bidirecional: o Temporal grava os blocos indexados e incorporados de volta na coleção de conhecimento do MongoDB assim que o processamento for concluído.

Esse padrão é adequado para sistemas que podem emitir eventos de objeto confiável, API ou aplicação diretamente em um acionador de fluxo de trabalho. Ele reduz as camadas arquitetônicas e mantém o caminho de ingestão simples, ao mesmo tempo em que preserva a capacidade de retomada para etapas de extração e incorporação de longa duração. Como o fluxo de trabalho é acionado com uma referência de origem em vez de conteúdo bruto, o pipeline downstream permanece independente da origem e pode oferecer suporte a sistemas upstream adicionais com alterações mínimas na orquestração.

O diagrama a seguir mostra esse fluxo.

Ingerir fontes de dados diretamente no temporal

figura 2. Ingerir fontes de dados diretamente no temporal

clique para ampliar

As etapas a seguir descrevem esse fluxo:

  1. Os sistemas de origem produzem ou expõem conteúdo

    O conteúdo se origina de sistemas upstream, como Amazon S3, plataformas IoT e bancos de dados operacionais. Esses sistemas fornecem os documentos, registros ou eventos brutos que o pipeline processa. Quando um conteúdo novo ou atualizado fica disponível, o sistema de origem emite um evento para um adaptador leve, como o AWS Lambda, um webhook ou um conector. O adaptador inicia o fluxo de trabalho Temporal e passa apenas a referência de origem e os metadados necessários. Isso mantém a lógica específica da origem fora do fluxo de trabalho, para que você possa adicionar novos tipos de origem sem alterar o pipeline downstream.

  2. O Temporal gerencia o ciclo de vida da ingestão

    Após o início do fluxo de trabalho, o Temporal coordena a execução, as novas tentativas e a recuperação nas etapas de ingestão. Isso torna o caminho de processamento durável, portanto, as operações de longa duração continuam de forma confiável em caso de falhas ou reinicializações. O fluxo de trabalho recupera o conteúdo de origem e o converte em uma forma normalizada para processamento de IA downstream, criando uma representação consistente entre tipos de fonte antes do início da transformação semântica.

  3. A IA do Voyage gera incorporações dentro do fluxo de trabalho

    A incorporação do Voyage AI é executada como parte do fluxo de trabalho e não como uma etapa externa do tipo fire-and-forget. Isso mantém a incorporação observável e recuperável dentro do mesmo caminho de execução e mantém a transformação semântica fortemente atada ao ciclo de vida de ingestão.

  4. O MongoDB Atlas armazena conteúdo, metadados e incorporações

    O MongoDB Atlas persiste o conteúdo processado, metadados relacionados e vetores incorporados em uma única plataforma. Isso cria uma camada de conhecimento durável que oferece suporte tanto ao caminho de gravação de ingestão quanto ao caminho de recuperação downstream.

  5. O Atlas Vector Search torna o conhecimento recuperável

    O Atlas Vector Search indexa o conteúdo incorporado para que você possa consultá-lo por similaridade semântica. Como as incorporações e os metadados operacionais permanecem na mesma plataforma, as solicitações posteriores do aplicação e do agente recuperam o contexto relevante sem um armazenamento de vetor ou camada de sincronização separado.

Esse fluxo se aplica a ambas as soluções de ingestão. Ele usa os mesmos princípios de durabilidade da ingestão: em vez de tratar a execução do agente como uma solicitação de API de curta duração, a arquitetura executa a recuperação e o argumento como operações orientadas por fluxo de trabalho que você pode observar, tentar novamente e retomar. Isso é importante quando o agente realiza várias chamadas de recuperação, invoca ferramentas externas ou precisa retornar atualizações contínuas de status antes de um resultado final.

O diagrama a seguir mostra os componentes do agente.

Arquitetura do agente de pesquisa

figura 3. Arquitetura do agente de pesquisa

clique para ampliar

As etapas a seguir descrevem esse fluxo:

  1. Iniciar uma solicitação de pesquisa de agente

    Quando a API do agente recebe uma query do usuário por meio da interface do usuário, ela inicia um fluxo de trabalho temporal durável. O sistema retorna imediatamente um identificador de fluxo de trabalho, para que a interface do usuário possa acompanhar o progresso à medida que o agente de pesquisa recupera o contexto e as razões sobre uma resposta.

  2. Recuperar contexto do MongoDB Atlas Vector Search

    O MongoDB Atlas hospeda os metadados, incorporações vetoriais e índices semânticas. Durante uma interação com o usuário, o agente incorpora a query e usa o MongoDB Atlas Vector Search para recuperar o contexto relevante, geralmente aplicando uma camada de reclassificação antes da sintaxe final. Para padrões de indexação e query, consulte a documentação do Atlas Vector Search .

  3. Retornar um resultado de pesquisa durável

    O fluxo de trabalho de pesquisa coordena a execução da ferramenta, as interações do modelo e a sintaxe final. O Temporal mantém o processo por meio de novas tentativas e persistência de estado, para que a interface do usuário forneça uma resposta validada. Para saber mais sobre execução durável, consulte a documentação temporal.

Os componentes a seguir implementam essa arquitetura.

Use o MongoDB Atlas para armazenar os chunks testados e incorporados do pipeline de ingestão, o índice do MongoDB Atlas Vector Search e o estado do agente em um único banco de dados. Como o agente lê os mesmos dados que o pipeline de ingestão escreve, não há armazenamento de memória separado para manter a sincronização.

Use o Atlas Stream Processing para fornecer um caminho de integração opcional e orientado a eventos entre fontes de streaming e fluxos de trabalho temporais. Ele lida com a transformação em tempo real e o roteamento de eventos recebidos para arquiteturas de alto rendimento. Isso permite que você implemente a ingestão quase em tempo real sem exigir o Kafka se escolher uma conexão direta de origem para o Temporal.

Use a IA do Voyage para gerar as incorporações e executar a reclassificação de resultados para essa arquitetura. Como a incorporação e a reclassificação são separadas da orquestração do fluxo de trabalho, as equipes podem atualizar o modelo independentemente dos pipelines de ingestão e recuperação.

Use o MongoDB Atlas Vector Search para recuperar o contexto do documento e a memória do agente por meio da indexação semântica. O agente de pesquisa consulta o mesmo cluster do MongoDB Atlas usado para armazenamento primário, de modo que a recuperação use dados operacionais atuais.

Use o Temporal como a camada de execução durável para fluxos de trabalho de ingestão e agentes nos sistemas de origem, no MongoDB Atlas e nos serviços externos de IA. Ele coordena etapas de longa execução, como extração, agrupamento, incorporação e indexação, e fornece novas tentativas, ponto de verificação e recuperação integrados. Isso permite que os fluxos de trabalho sejam retomados do último estado bem-sucedido após uma falha ou interrupção, em vez de serem reiniciados. Ao tornar a orquestração durável, o Temporal ajuda as equipes a operar, preencher e desenvolver de forma confiável os pipelines de IA de produção.

Considere as trocas entre a ingestão direta e a baseada em Kafka antes de adotar essa arquitetura. Uma conexão direta de origem para o Temporal tem menos partes móveis para operar. Um caminho baseado no Kafka adiciona um corretor de mensagens, que introduz infraestrutura adicional, mas se encaixa naturalmente se a sua organização já direciona atualizações de origem por meio do Kafka.

Consulte o repositório GitHub mdb- temporal-prá para obter orientações de implantação e documentação técnica.