Casos de uso: Inteligência artificial
Setores: Manufatura e Mobilidade, Mobile e Edge
Produtos: MongoDB Atlas, MongoDB Atlas Vector Search, MongoDB Atlas Triggers, Voyage AI
Parceiros: ObjectBox
Visão Geral da Solução
Os veículos conectados geram continuamente dados de sensores para motoristas que esperam suporte imediato e sem as mãos. No entanto, quando a conectividade cai em estacionamentos, túneis ou rotas secundárias, qualquer assistente que confie na nuvem falha quando ela é mais crítica.
Essa solução executa um co-pilato de IA na borda para garantir a assistência contínua no veículo durante interrupções na rede. Ele usa um banco de dados ObjectBox no dispositivo para armazenar a telemetria do veículo ao vivo junto com o manual do proprietário. Em seguida, ele processa consultas usando um agente LLM local que não exige uma conexão de rede ativa. Após a reconexão, o servidor de sincronização do ObjectBox sincroniza automaticamente esses dados de borda de volta ao MongoDB Atlas.
O MongoDB Atlas serve como o sistema de nuvem centralizado de registro. Ele realiza pesquisa vetorial no conteúdo manual, mantém o histórico de telemetria dentro de coleções de séries temporais e processa cada snapshot sincronizado em um documento totalmente consultável por meio de um Atlas Trigger.
Arquiteturas de referência
A arquitetura para criar um assistente no veículo que forneça respostas precisas sem conectividade com a Internet é divisão em duas camadas: uma camada de borda no veículo e uma camada de nuvem do MongoDB Atlas .
Gráfico 1. Fluxo de usuário de ponta a ponta da solicitação de sincronização com o MongoDB Atlas e as collections de saída do Atlas Trigger
Arquitetura de camada de borda
A camada de borda no veículo constitui um tempo de execução autônomo em que os serviços Cockpoint, backend, agente local e ObjectBox se comunicam diretamente no veículo. Essa pilha permite que o assistente recupere conhecimento e opere sem o MongoDB Atlas, enquanto os dados locais são sincronizados com o MongoDB Atlas quando a conectividade retornar. A camada de borda usa os seguintes componentes:
UI do Cockpoint: construída com Next.js, essa interface exibe medidores ao vivo, um mostrador de códigos de falhas, um painel de bate-papo e um mapa, restringindo todas as chamadas do navegador para rotas de API da mesma origem.
Backend do Python: expõe endpoints REST e eventos enviados pelo servidor para lidar com proxy de telemetria, conversões de voz para texto e texto para voz e orquestração de agente .
agente LangChain : comunica-se com um LLM local via Ollama, gerenciando gráficos duplos pré-compilados para caminhos de execução online e offline discretos.
Pipeline de incorporação: o manual do veículo é primeiro dividido em blocos de texto menores. Cada chunk é então convertido em uma incorporação 1,024-dimensional usando o modelo de viagem-4-nano da Voyage AI, com a incorporação resultante armazenada junto com seu chunk correspondente.
Serviços do ObjectBox: Distribuídos por C++, três clientes de sincronização distintos armazenam chunks do manual do usuário e suas incorporações, telemetria do veículo e histórico de diálogos localmente.
Pesquisa de vetor HNSW do ObjectBox: o ObjectBox mantém um índice de vetor HNSW sobre as incorporações manuais armazenadas localmente. O índice resultante permite pesquisas aproximadas do vizinho mais próximo diretamente no veículo, permitindo que o assistente recupere conteúdo manual relevante enquanto estiver offline e sem depender da conectividade do MongoDB Atlas .
Gerador de telemetria: captura e salva instantâneos de VSS diretamente no armazenamento de telemetria local em intervalos de dois segundos.
Arquitetura de camada da nuvem
O MongoDB Atlas atua como a contraparte conectada do armazenamento ObjectBox local do veículo. Quando a conectividade está disponível, ela recebe chunks e incorporações manuais sincronizados, telemetria do veículo e histórico de diálogos, fornecendo persistência baseada na nuvem enquanto a camada de borda permanece operacional offline. A camada de nuvem usa os seguintes componentes:
Replicação de dados: o servidor do ObjectBox Sync se conecta à nuvem, sincronizando os armazenamentos de dados de borda diretamente no MongoDB Atlas por meio do conector do MongoDB . A sincronização inclui os chunks manuais, suas incorporações, telemetria e histórico de diálogos.
Cluster MongoDB Atlas : Mantém as collections de dados replicadas e fornece mais capacidade de armazenamento do que o armazenamento local do ObjectBox. A sincronização com o MongoDB Atlas permite que a solução retenha volumes maiores de conteúdo manual, telemetria, histórico de diálogos e outros dados de longo prazo sem ser limitado pela capacidade de armazenamento local do veículo.
Atlas Vector Search: indexa as incorporações manuais sincronizadas e fornece pesquisa vetorial no lado da nuvem sobre o conteúdo manual completo quando a conectividade está disponível.
Atlas Triggers: transforma automaticamente os snapshots de telemetria recebidos em documentos de status enquanto estende um registro de histórico de séries temporais dedicado.
Fluxo de execução para solicitações
Com os níveis de borda e nuvem estabelecidos, o fluxo de execução descreve como a solicitação de um driver se move pelo sistema, do Cockpoint ao backend e agente local. A sincronização na nuvem ocorre quando a conectividade está disponível.
Quando o driver digita ou fala, o backend alimenta o fluxo de solicitações diretamente para o agente. O agente avalia a query usando o LangGraph e decide qual ferramenta chamar.
O manual do carro é dividido em blocos e incorporado com o modelo 1,024-dimensional preference-4-nano do MongoDB Voyage. A mesma representação de incorporação é armazenada localmente no ObjectBox e replicada para o MongoDB Atlas, onde é indexada para a MongoDB Atlas Vector Search. Na borda, o índice HNSW do ObjectBox suporta a recuperação local aproximada do vizinho mais próximo sobre as incorporações manuais do carro. Na nuvem, o MongoDB Atlas Vector Search fornece o recurso de pesquisa vetorial correspondente sobre o conteúdo manual sincronizado.
Quando um pedido envolve informações do veículo, o agente determina qual ferramenta de telemetria é mais apropriada para a questão do condutor e a invoca. Dependendo da solicitação, a ferramenta selecionada recupera o estado atual do veículo, sinais VSS relevantes, códigos de falha ou informações de status derivadas do armazenamento de telemetria apropriado. Se a ferramenta selecionada retornar um DTC, o agente poderá invocar a ferramenta de tradução dedicada para converter o código e seus sinais associados em uma explicação clara do sistema afetado, significado, gravidade e próximas etapas.
Abordagem do modelo de dados
O modelo de documento armazena essas formas em um banco de dados:
Telemetria estruturada
Gráfico 2. Modelo de dados de telemetria
clique para ampliarBlocos manuais de texto livre
Gráfico 3. Modelo de dados manual do carro
clique para ampliarHistórico do chat
Gráfico 4. Modelo de dados de conversa de chat
clique para ampliarDados de telemetria de série temporal
Último status do carro
Gráfico 5. Modelo de dados de status de telemetria
clique para ampliar
Cada snapshot de telemetria é um documento. Um snapshot contém a árvore completa do veículo VSS, sobre sinais 1300 em muitos domínios, armazenados como JSON aninhado. O modelo não precisa de esquema fixo nesses domínios.
A ObjectBox armazena a carga útil de telemetria como uma string. O conector do MongoDB o expande para um documento nativo aninhado no Atlas por meio do tipo externo JsonToNative, de modo que as queries da nuvem endereçem os campos pelo caminho exato do VSS.
Collections
Juntos, esses modelos de dados representam os principais domínios da solução: conhecimento manual pesquisável, histórico de conversas, telemetria bruta do veículo, status atual do veículo e telemetria histórica. A separação desses tipos de dados permite a recuperação eficiente, suporta queries de estado de veículo em tempo real, preserva o contexto da conversa e mantém o histórico de telemetria de longo prazo escalável e consultável no MongoDB Atlas. As coleções para esta solução incluem:
manual_chunks: Blocos de texto do manual do proprietário com uma incorporação de IA Voyage de 1024dimensão para pesquisa vetorial.conversations: Histórico de bate-papo, que inclui a resposta do ser humano e do assistente, juntamente com as ferramentas que cada assistente usa para responder a uma pergunta.objectbox_telemetry: um snapshot bruto por documento, sincronizado a partir da borda.telemetry-status: o estado atual do veículo, um documento por veículo, escrito pelo trigger.telemetry-data: Uma coleção de séries temporais do MongoDB . O Atlas Trigger acrescenta um registro por snapshot, para que as queries de histórico permaneçam eficientes à medida que os dados crescem.
Construir a solução
Verifique o README no repositório GitHub para obter detalhes completos da implementação. As etapas a seguir explicam como criar o aplicação:
Gráfico 6. A UI do dashboard com medidores em tempo real, chat, o mostrador de códigos de falhas e o painel de sincronização online e offline
Principais Aprendizados
Mantenha a autoridade de borda: o armazenamento de ObjectBox no dispositivo atende leituras e aceita gravações sem conexão, portanto, o assistente trabalha com baixa conectividade.
Execute a pesquisa vetorial onde a query está: Um modelo de incorporação de IA do MongoDB Voyage (dimensõesvoyage-4-nano, 1024) alimenta a pesquisa vetorial ObjectBox na borda e o MongoDB Atlas Vector Search na nuvem, para que as respostas permaneçam consistentes entre os modos .
Armazenar histórico de telemetria como série temporal: um MongoDB Atlas Trigger grava cada snapshot em uma coleção de séries temporais do MongoDB .
Modele um snapshot como um documento: o modelo de documento flexível armazena sinais VSS sem um esquema fixo entre domínios.
Serviços de design para tolerar a perda de conectividade: os buffers de borda gravam enquanto estão off-line e se reconciliam com o MongoDB Atlas na reconexão.
Autores
Timóteo Marques, MongoDB
Dorottya Nyárády, MongoDB