.webp){kind=small}
Apresentado pela MongoDB. Construir IA precisa, segura e confiável é uma grande façanha de engenharia para organizações sujeitas às obrigações de conformidade que regem os setores de saúde, serviços financeiros e transporte. O desafio de fornecer produtos orientados por IA é agravado pelo fato de que a tecnologia nesses setores tende a ficar atrás de outros setores, porque a regulamentação exige que as organizações ajam com cautela — e lentamente. Agora, muitas também estão enfrentando projetos de modernização da infraestrutura de dados, enquanto tentam acompanhar a demanda atual por IA. A Heidi, parceira australiana em IA para cuidados de saúde, oferece um exemplo de modernização bem-sucedida.
Seu principal produto, o Heidi Scribe, agora automatiza grande parte do trabalho administrativo que consome o dia a dia dos médicos em mais de 190 países, dando suporte a aproximadamente 2,7 milhões de interações com pacientes por semana. Essa expansão se baseia em decisões de infraestrutura tomadas anos antes de a empresa atingir escala global, afirma Yu Liu, cofundador e diretor de tecnologia da Heidi. "Na maioria dos setores, um recurso de IA que falha em 2% das vezes é considerado um inconveniente, enquanto na área da saúde, essa mesma taxa de erro se torna um problema de segurança clínica", diz Liu. “A arquitetura precisa ser construída em torno da premissa de que cada resultado pode ser examinado, auditado e utilizado no cuidado do paciente.” Para a Heidi, a residência de dados é uma condição prévia, e não um recurso.
Um médico em Sydney, Londres, Tóquio ou Denver opera sob diferentes regimes regulatórios, incluindo os Princípios de Privacidade Australianos, GDPR, PI e HIPAA, e os dados de seus pacientes precisam estar localizados na região. A Heidi executa implantações de produção totalmente isoladas logicamente em todo o mundo, portanto, a residência é imposta pela arquitetura. A auditabilidade também precisa ser incorporada desde o primeiro dia, porque uma organização precisa ser capaz de responder o que o modelo viu, o que ele produziu e o que o médico alterou, para qualquer sessão, meses depois, quando solicitado. “O impacto das mudanças precisa ser minimizado”, diz Liu.
“Em setores menos regulamentados, você pode lançar rapidamente e corrigir problemas em seguida, mas na área da saúde investimos muito em tornar as mudanças seguras por padrão, com pontos de integração contínua em classes de mudanças de risco, lançamentos canary e tratando até mesmo alterações de esquema e índice de banco de dados como código que passa por revisão. Nossa velocidade é um produto dessa segurança, e não algo que conquistamos apesar dela.” Heidi lida com um conjunto diversificado de dados médicos coletados de múltiplas fontes, incluindo formulários, encaminhamentos e anotações de médicos, todos os quais precisavam ser consolidados em um formato consistente e em um único local para se conectar perfeitamente com os fluxos de trabalho de IA. Linhas e colunas rígidas seriam inadequadas para essa carga de trabalho.
Para Heidi, esses requisitos fizeram de um banco de dados de documentos a escolha natural. O MongoDB deu à equipe a flexibilidade para acomodar dados de IA em rápida mudança sem remodelar constantemente o banco de dados subjacente. “O modelo representa talvez 20% do sistema, e a arquitetura de dados é o que determina se os outros 80% suportam a carga clínica real”, diz Liu. Uma sessão do AI Scribe não é um único dado. É uma coleção de transcrições, notas estruturadas, modelos, documentos, contexto do paciente, estado de integração do EHR e dezenas de outros artefatos relacionados que mudam de semana para semana. O MongoDB permite que os dados de uma sessão coexistam em formatos que correspondem à maneira como os médicos realmente trabalham e permite que Heidi evolua esses formatos sem um congelamento de migração sempre que o produto for atualizado.
"O MongoDB Atlas se destacou porque combinou o poder do modelo de documento, que permite escalabilidade perfeita, flexibilidade e alto desempenho, com recursos integrados prontos para IA, como o MongoDB Vector Search", diz Liu. “Isso significa que a Heidi não precisa de outro banco de dados vetorial complementar para ampliar sua plataforma existente.” Com mais de 130 regiões de nuvem globalmente, além de opções locais e híbridas, o MongoDB Atlas é a plataforma de banco de dados distribuída globalmente mais amplamente disponível, e sua API de consulta unificada permite que os desenvolvedores criem pesquisas de texto completo, análises em tempo real e experiências orientadas a eventos sem complicar sua arquitetura.
“O Heidi Scribe converte grandes volumes de documentos médicos em embeddings vetoriais por meio do LangChain no Atlas, permitindo a pesquisa semântica que conecta os termos médicos transcritos diretamente ao conhecimento externo correspondente”, acrescenta Liu. “A migração para o Atlas reduziu a latência em APIs importantes em quase 33%.” “A recuperação é um problema de arquitetura de dados antes de ser um problema de IA”, diz Liu.
“No RAG para o consumidor, você recupera da web aberta e torce para que funcione, enquanto na área da saúde, o que você recupera é a superfície de conformidade.” O Heidi Evidence recupera dados de bases de conhecimento clínico licenciadas, incluindo parceiros como BMJ Best Practice, NICE CKS e MIMS, e leva em consideração a jurisdição, de modo que um médico do Reino Unido recebe orientações do Reino Unido e um médico australiano recebe formulários australianos, porque a resposta correta em um país pode ser a resposta errada em outro.
Os embeddings e índices vetoriais do Heidi residem no MongoDB Vector Search, dentro das mesmas implantações isoladas regionalmente que o restante de seus dados, o que significa que a recuperação não pode fisicamente cruzar uma fronteira de residência e eles não estão operando um banco de dados vetorial separado com sua própria história de segurança e conformidade. As citações são um contrato rígido em vez de uma sugestão, porque o modelo só vê blocos recuperados que já estão vinculados a registros de origem. “Cada região é uma implantação de produção completa e isolada com seus próprios clusters MongoDB Atlas, seu próprio poder computacional e sua própria chave”, diz Liu.
“É isso que nos permite entrar em um sistema de saúde dos EUA, um fundo fiduciário do NHS ou um grupo hospitalar australiano e dar uma resposta clara sobre residência, porque ela é garantida pela infraestrutura, e não apenas prometida por contrato”, explica ele. “Operar várias regiões isoladas com uma equipe enxuta só funciona porque a camada de banco de dados é gerenciada e consistente. Também somos multicloud, o que significa que uma nova região pode implementar outra solução na infraestrutura que já construímos.”
