A recuperação multimodal representa um desafio significativo nos sistemas modernos de IA. Sistemas de recuperação tradicionais têm dificuldades para buscar efetivamente em diferentes tipos de dados sem metadados ou marcações extensivas. Isso é particularmente problemático para empresas de saúde que gerenciam grandes volumes de conteúdo diverso, incluindo texto, imagens, áudio e mais, muitas vezes resultando em fontes de dados não estruturadas.
Qualquer pessoa que trabalhe na área de saúde entende a dificuldade de mesclar dados não estruturados com dados estruturados. Um exemplo comum disso é a documentação clínica, onde anotações clínicas manuscritas ou resumos de alta de pacientes são frequentemente enviados em PDFs, imagens, e formatos semelhantes. Isso precisa ser convertido manualmente ou processado usando Reconhecimento Óptico de Caracteres (OCR) para encontrar as informações necessárias. Mesmo após esta etapa, você deve mapear os dados para seus dados estruturados existentes para utilizá-los efetivamente.
Para este blog, vamos revisar o seguinte:
Ao final deste blog, você verá como os embeddings multimodais possibilitam o seguinte para a saúde:
Um espaço de incorporação (AWS | Azure | GCP) é uma representação matemática n-dimensional de registros que permite que uma ou mais modalidades de dados sejam armazenadas como vetores de números de ponto flutuante. O que torna isso útil é que em um espaço de incorporação bem construído, registros de significado semelhante ocupam um espaço semelhante. Por exemplo, imagine que tínhamos uma foto de um cavalo, a palavra "caminhão" e uma gravação de áudio de um cachorro latindo. Passamos esses três pontos de dados completamente diferentes para o nosso modelo de incorporação multimodal e obtemos o seguinte:
Aqui está uma representação visual de onde os números existiriam em um espaço de embedding:
Na prática, as dimensões do espaço de embedding estarão nas centenas ou milhares, mas para ilustração, vamos usar o espaço 3. Podemos imaginar que a primeira posição nesses vetores representa "animalidade", a segunda é "transporte" e a terceira é "volume". Isso faria sentido considerando os embeddings, mas normalmente, não sabemos o que cada dimensão representa. O importante é que eles representam o significado semântico dos registros.
Existem várias maneiras de criar um espaço de incorporação multimodal, incluindo o treinamento de vários codificadores simultaneamente (como o CLIP), usando mecanismos de atenção cruzada (como o DALL-E), ou usando vários métodos de alinhamento pós-treinamento. Esses métodos permitem que o significado do registro transcenda a modalidade original e ocupe um espaço compartilhado com outros registros ou formatos díspares.
Este espaço semântico compartilhado é o que permite poderosas capacidades de busca cross-modal. Quando uma consulta de texto e uma imagem compartilham representações vetoriais semelhantes, provavelmente compartilham significados semânticos semelhantes, permitindo-nos encontrar imagens relevantes com base em descrições textuais sem tags ou metadados explícitos.
Para implementar efetivamente a pesquisa multimodal, precisamos de modelos que possam gerar incorporações para diferentes tipos de dados dentro de um espaço vetorial compartilhado. Esses modelos são especificamente projetados para entender as relações entre diferentes modalidades e representá-las em um espaço matemático unificado.
Vários modelos poderosos de incorporação multimodal estão disponíveis a partir de junho de 2025:
Na Databricks, fornecemos a infraestrutura e as ferramentas para hospedar, avaliar e desenvolver uma solução de ponta a ponta, personalizável para o seu caso de uso. Considere os seguintes cenários ao começar a implantar este caso de uso:
Para a implementação completa desta solução, por favor, visite este repositório aqui: Link do Github
Este exemplo usará informações sintéticas de pacientes como nossos dados estruturados e amostras de explicações de benefícios em formato PDF como nossos dados não estruturados. Primeiro, dados sintéticos são gerados para uso com um Espaço Genie. Depois Modelo de incorporação multimodal Nomic, um modelo de incorporação multimodal de código aberto de última geração, é carregado no Databricks Model Serving para gerar incorporações em amostras de explicações de benefícios encontradas online.
Este processo parece complicado, mas o Databricks fornece ferramentas integradas que permitem uma solução completa de ponta a ponta. Em um nível alto, o processo se parece com o seguinte:
Este Espaço Genie será usado como uma ferramenta para converter linguagem natural em uma consulta SQL para consultar nossos dados estruturados.
Neste exemplo, a Biblioteca Faker será usada para gerar informações aleatórias de pacientes. Criaremos duas tabelas para diversificar nossos dados: Visitas de Pacientes e Locais de Prática, com colunas como motivos para a visita, provedores de seguro e tipos de seguro.
Para consultar dados usando linguagem natural, podemos utilizar um Espaços Genie Databricks (AWS | Azure | GCP) para converter nossa consulta em linguagem natural e recuperar dados relevantes do paciente. No UI do Databricks, basta clicar na aba Genie na barra à esquerda → Novo → selecionar as tabelas patient_visits e practice_locations.
Precisamos do ID do Espaço Genie para capturar o número que vem depois dos quartos. Você pode ver um exemplo abaixo:
Como estamos usando DSPy, tudo o que precisamos fazer é definir uma função Python.
É isso aí! Vamos configurar o fluxo de trabalho de Geração Multimodal agora.
Para esta etapa, usaremos o modelo totalmente aberto colNomic-embed-multimodal-7b do HuggingFace para gerar incorporações para nossos dados não estruturados, neste caso, PDFs. Selecionamos o modelo Nomic devido à sua licença Apache 2.0 e alto desempenho em benchmarks.
O método para gerar seus embeddings variará dependendo do seu caso de uso e modalidade. Revise as Melhores Práticas de Pesquisa Vetorial do Databricks (AWS | Azure | GCP) para entender o que é melhor para o seu caso de uso.
Precisamos que este modelo esteja disponível dentro do Catálogo Unity (UC), então usaremos o MLflow para carregá-lo do Huggingface e registrá-lo. Depois, podemos implantar o modelo em um endpoint de serviço de modelo.
O modelo Python inclui lógica adicional para lidar com entradas de imagem, que podem ser encontradas no completo repositório.
UC Volumes são projetados como sistemas de arquivos para hospedar qualquer arquivo e é onde armazenamos nossos dados não estruturados. Você pode usá-los no futuro para armazenar outros arquivos, como imagens, e repetir o processo conforme necessário. Isso inclui o modelo acima. No repositório, você verá que o cache se refere a um volume.
Você terá uma pasta chamada sample_pdf_sbc contendo alguns exemplos de resumos de benefícios e coberturas. Precisamos preparar esses PDFs para incorporá-los.
O modelo colNomic-embed-multimodal-7b é especificamente treinado para reconhecer texto e imagens dentro de uma imagem, uma entrada comum de PDFs. Isso permite que o modelo tenha um desempenho excepcionalmente bom na recuperação dessas páginas.
Este método permite que você utilize todo o conteúdo dentro de um PDF sem precisar de uma estratégia de fragmentação de texto para garantir que a recuperação funcione efetivamente. O próprio modelo pode incorporar bem essas imagens em seu próprio espaço de incorporação.
Usaremos pdf2image para converter cada página do PDF em uma imagem, preparando-a para incorporação.
Agora que temos as imagens em PDF, podemos gerar os embeddings. Ao mesmo tempo, podemos salvar as incorporações em uma tabela Delta com colunas adicionais que recuperaremos junto com nossa Busca Vetorial, como o caminho do arquivo para o local do Volume.
A criação de um índice de Busca Vetorial pode ser feita via UI ou API. O método API é mostrado abaixo.
Agora só precisamos juntar tudo com um Agente.
Usamos o DSPy para isso por causa de seu design declarativo e puramente em Python. Ele nos permite iterar e desenvolver rapidamente, testando vários modelos para ver quais funcionarão melhor para o nosso caso de uso. Mais importante, a natureza declarativa nos permite modularizar nosso Agente para que possamos isolar a lógica do Agente das ferramentas e nos concentrar em definir COMO o agente deve realizar sua tarefa.
E a melhor parte? Sem engenharia de prompt manual!
Esta assinatura especifica e impõe as entradas e saídas, além de explicar como a assinatura deve funcionar.
O módulo pegará as instruções da assinatura e criará um prompt otimizado para enviar ao LLM. Para este caso de uso específico, vamos construir um módulo personalizado chamado `MultiModalPatientInsuranceAnalyzer()`.
Este módulo personalizado dividirá as assinaturas como etapas, quase como “encadeando” chamadas, no método forward. Seguimos este processo:
Reveja quais ferramentas o Agente usou e o raciocínio que o Agente fez para responder à pergunta.
Uma vez que você tenha um Agente funcionando, recomendamos o seguinte:
O framework de avaliação será crucial para entender quão efetivamente o índice de Pesquisa Vetorial recupera informações relevantes para o seu agente RAG. Seguindo essas métricas, você saberá onde fazer ajustes, desde mudar o modelo de incorporação até ajustar os prompts que interagem com o LLM.
Você também deve monitorar para ver se a API do Modelo de Fundação (AWS | Azure | GCP) é suficiente para o seu caso de uso. Em determinado momento, você atingirá os limites da API para as APIs do Modelo de Fundação, então você precisará fazer a transição para o Throughput Provisionado (AWS | Azure | GCP) para ter um endpoint mais confiável para o seu LLM.
Além disso, fique de olho nos seus custos contra o modelo de serviço sem servidor (AWS | Azure | GCP). A maioria desses custos virá do modelo de serviço sem servidor Databricks SKU e pode aumentar à medida que você escala.
Confira estes blogs para entender como fazer isso na Databricks.
Além disso, os Arquitetos de Soluções de Entrega da Databricks (DSAs) ajudam a acelerar as iniciativas de Dados e IA em organizações. Os DSAs fornecem liderança arquitetônica, otimizam plataformas para custo e desempenho, aprimoram a experiência do desenvolvedor e conduzem a execução bem-sucedida do projeto. Eles preenchem a lacuna entre a implantação inicial e as soluções de produção, trabalhando de perto com várias equipes, incluindo engenharia de dados, líderes técnicos, executivos e outros stakeholders para garantir soluções personalizadas e um tempo de valor mais rápido. Entre em contato com sua Equipe de Conta Databricks para saber mais.
Comece construindo seu próprio App GenAI! Confira a documentação para começar.
Na Databricks, você tem todas as ferramentas de que precisa para desenvolver esta solução de ponta a ponta. Confira os blogs abaixo para aprender sobre como gerenciar e trabalhar com seu novo Agente com o Mosaic AI Agent Framework.
(This blog post has been translated using AI-powered tools) Original Post