

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Caso de uso: criação de um aplicativo de inteligência médica com dados de pacientes aumentados
<a name="case-1"></a>

A IA generativa pode ajudar a aumentar o atendimento ao paciente e a produtividade da equipe, aprimorando as funções clínicas e administrativas. AI-driven a análise de imagens, como a interpretação de ultrassonografias, acelera os processos de diagnóstico e melhora a precisão. Ele pode fornecer informações críticas que apoiam intervenções médicas oportunas.

Ao combinar modelos generativos de IA com gráficos de conhecimento, você pode automatizar a organização cronológica dos registros eletrônicos dos pacientes. Isso ajuda você a integrar dados em tempo real de interações médico-paciente, sintomas, diagnósticos, resultados de laboratório e análise de imagens. Isso equipa o médico com dados abrangentes do paciente. Esses dados ajudam o médico a tomar decisões médicas mais precisas e oportunas, melhorando os resultados dos pacientes e a produtividade do profissional de saúde.

## Visão geral da solução
<a name="case-1-overview"></a>

A IA pode capacitar médicos e clínicos sintetizando dados de pacientes e conhecimento médico para fornecer informações valiosas. Essa solução Retrieval Augmented Generation (RAG) é um mecanismo de inteligência médica que consome um conjunto abrangente de dados e conhecimentos de pacientes de milhões de interações clínicas. Ele aproveita o poder da IA generativa para criar insights baseados em evidências para melhorar o atendimento ao paciente. Ele foi projetado para aprimorar os fluxos de trabalho clínicos, reduzir erros e melhorar os resultados dos pacientes.

A solução inclui um recurso automatizado de processamento de imagens baseado em LLMs. Esse recurso reduz a quantidade de tempo que a equipe médica deve gastar procurando manualmente imagens de diagnóstico semelhantes e analisando os resultados do diagnóstico.

A imagem a seguir mostra o fluxo de trabalho completo dessa solução. Ele usa o Amazon Neptune, o SageMaker Amazon AI, o OpenSearch Amazon Service e um modelo básico no Amazon Bedrock. Para o agente de recuperação de contexto que interage com o gráfico de conhecimento médico em Neptune, você pode escolher entre um agente Amazon Bedrock e um agente. LangChain

![Usando Serviços da AWS um LLM para gerar respostas a questões médicas.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/enterprise-cognitive-brain.png)


Em nossos experimentos com exemplos de perguntas médicas, observamos que as respostas finais geradas por nossa abordagem usando o gráfico de conhecimento mantido em Neptune OpenSearch, banco de dados vetoriais que abriga a base de conhecimento clínico, e os Amazon Bedrock LLMs foram baseadas na factualidade e são muito mais precisas ao reduzir os falsos positivos e aumentar os verdadeiros positivos. Essa solução pode gerar insights baseados em evidências sobre o estado de saúde do paciente e visa aprimorar os fluxos de trabalho clínicos, reduzir erros e melhorar os resultados dos pacientes.

A criação dessa solução consiste nas seguintes etapas:
+ [Etapa 1: Descobrindo dados](#case-1-step-1)
+ [Etapa 2: Construindo um gráfico de conhecimento médico](#case-1-step-2)
+ [Etapa 3: Construindo agentes de recuperação de contexto para consultar o gráfico de conhecimento médico](#case-1-step-3)
+ [Etapa 4: Criar uma base de conhecimento de dados descritivos em tempo real](#case-1-step-4)
+ [Etapa 5: Usando LLMs para responder perguntas médicas](#case-1-step-5)

## Etapa 1: Descobrindo dados
<a name="case-1-step-1"></a>

Há muitos conjuntos de dados médicos de código aberto que você pode usar para apoiar o desenvolvimento de uma AI-driven solução de saúde. Um desses conjuntos de dados é o [MIMIC-IV conjunto](https://physionet.org/content/mimiciv/3.1/) de dados, que é um conjunto de dados de registro eletrônico de saúde (EHR) disponível ao público que é amplamente usado na comunidade de pesquisa em saúde. MIMIC-IV contém informações clínicas detalhadas, incluindo notas de alta em texto livre dos prontuários dos pacientes. Você pode usar esses registros para experimentar técnicas de soma de texto e extração de entidades. Essas técnicas ajudam a extrair informações médicas (como sintomas do paciente, medicamentos administrados e tratamentos prescritos) de texto não estruturado.

Você também pode usar um conjunto de dados que forneça resumos de alta de pacientes anotados e não identificados, selecionados especificamente para fins de pesquisa. Um conjunto de dados resumidos de alta pode ajudá-lo a fazer experiências com a extração de entidades, permitindo identificar as principais entidades médicas (como condições, procedimentos e medicamentos) a partir do texto. [Etapa 2: Construindo um gráfico de conhecimento médico](#case-1-step-2)neste guia, descrevemos como você pode usar os dados estruturados extraídos dos conjuntos de dados resumidos MIMIC-IV e de alta para criar um gráfico de conhecimento médico. Esse gráfico de conhecimento médico serve como base para sistemas avançados de consulta e suporte à decisão para profissionais de saúde.

Além dos conjuntos de dados baseados em texto, você pode usar conjuntos de dados de imagem. Por exemplo, o conjunto de dados [Musculoskeletal Radiographs (MURA), que é um banco de dados](https://stanfordmlgroup.github.io/competitions/mura/) abrangente de imagens radiográficas de ossos com várias visualizações. Use esses conjuntos de dados de imagem para experimentar a avaliação diagnóstica por meio de técnicas de decodificação de imagens médicas. Essas técnicas de decodificação são cruciais para o diagnóstico precoce de doenças, como doenças musculoesqueléticas, doenças cardiovasculares e osteoporose. Ao ajustar os modelos básicos de visão e linguagem no conjunto de dados de imagens médicas, você pode detectar anormalidades nas imagens de diagnóstico. Isso ajuda o sistema a fornecer aos médicos informações diagnósticas precoces e precisas. Ao usar conjuntos de dados de imagem e texto, você pode criar um aplicativo de AI-driven saúde capaz de processar dados de texto e imagem para melhorar o atendimento ao paciente.

## Etapa 2: Construindo um gráfico de conhecimento médico
<a name="case-1-step-2"></a>

Para qualquer organização de saúde que queira criar um sistema de apoio à decisão com base em uma enorme base de conhecimento, um dos principais desafios é localizar e extrair as entidades médicas que estão presentes nas notas clínicas, nos periódicos médicos, nos resumos de alta e em outras fontes de dados. Você também precisa capturar as relações temporais, os assuntos e as avaliações de certeza desses registros médicos para usar com eficácia as entidades, atributos e relacionamentos extraídos.

A primeira etapa é extrair conceitos médicos do texto médico não estruturado usando um prompt de poucos passos para um modelo básico, como o Llama 3 no Amazon Bedrock. *Few-shot solicitação* é quando você fornece a um LLM um pequeno número de exemplos que demonstram a tarefa e a saída desejada antes de solicitar que ele execute uma tarefa semelhante. Usando um extrator de entidades LLM-based médicas, você pode analisar o texto médico não estruturado e, em seguida, gerar uma representação de dados estruturada das entidades de conhecimento médico. Você também pode armazenar os atributos do paciente para análise e automação posteriores. O processo de extração da entidade inclui as seguintes ações:
+ Extraia informações sobre conceitos médicos, como doenças, medicamentos, dispositivos médicos, dosagem, frequência do medicamento, duração do medicamento, sintomas, procedimentos médicos e seus atributos clinicamente relevantes.
+ Capture características funcionais, como relações temporais entre entidades extraídas, assuntos e avaliações de certeza.
+ Expanda os vocabulários médicos padrão, como os seguintes:
  + [Identificadores de conceito (RxCUI) do banco de dados RxNorm ](https://www.nlm.nih.gov/research/umls/rxnorm/docs/rxnormfiles.html)
  + Códigos da [Classificação Internacional de Doenças, 10ª Revisão, Modificação Clínica () ICD-10-CM](https://www.cdc.gov/nchs/icd/icd-10-cm/)
  + Termos do [Medical Subject Headings (MeSH)](https://www.nlm.nih.gov/mesh/meshhome.html)
  + Conceitos da [Nomenclatura Sistematizada da Medicina, Termos Clínicos](https://www.snomed.org/value-of-snomedct) (SNOMED CT)
  + Códigos do [Sistema Unificado de Linguagem Médica (UMLS](https://www.nlm.nih.gov/research/umls/index.html))
+ Resuma as notas de alta e obtenha informações médicas a partir das transcrições.

A figura a seguir mostra as etapas de extração de entidades e validação do esquema para criar combinações emparelhadas válidas de entidades, atributos e relacionamentos. Você pode armazenar dados não estruturados, como resumos de alta ou notas de pacientes, no Amazon Simple Storage Service (Amazon S3). Você pode armazenar dados estruturados, como dados de planejamento de recursos corporativos (ERP), registros eletrônicos de pacientes e sistemas de informações laboratoriais, no Amazon Redshift e no Amazon DynamoDB. Você pode criar um agente de criação de entidades Amazon Bedrock. Esse agente pode integrar serviços, como os pipelines de extração de dados de SageMaker IA da Amazon, o Amazon Textract e o Amazon Comprehend Medical, para extrair entidades, relacionamentos e atributos das fontes de dados estruturadas e não estruturadas. Por fim, você usa um agente de validação de esquema do Amazon Bedrock para garantir que as entidades e relacionamentos extraídos estejam em conformidade com o esquema gráfico predefinido e mantenham a integridade das conexões de borda do nó e das propriedades associadas.

![Fluxo de trabalho para extração de entidades e validação de esquemas.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/entity-extraction-schema-validation.png)


Depois de extrair e validar as entidades, relações e atributos, você pode vinculá-los para criar um trio sujeito-objeto-predicado. Você ingere esses dados em um banco de dados gráfico do Amazon Neptune, conforme mostrado na figura a seguir. Os [bancos de dados gráficos](https://docs.aws.amazon.com/neptune/latest/userguide/graph-get-started.html#graph-database) são otimizados para armazenar e consultar as relações entre os itens de dados.

![Gráfico de conhecimento médico que mapeia entidades de acordo com seus atributos.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/entity-attribute-mapping.png)


Você pode criar um gráfico de conhecimento abrangente com esses dados. Um [gráfico de conhecimento](https://aws.amazon.com/neptune/knowledge-graphs-on-aws/) ajuda você a organizar e consultar todos os tipos de informações conectadas. Por exemplo, você pode criar um gráfico de conhecimento com os seguintes nós principais: `HospitalVisit` `PastMedicalHistory``Symptoms`,`Medication`,`MedicalProcedures`,, `Treatment` e.

As tabelas a seguir listam as entidades e seus atributos que você pode extrair das notas de descarga.


****  

| Entidade | Atributos | 
| --- | --- | 
| `Patient` | `PatientID`, `Name`, `Age`, `Gender`, `Address`, `ContactInformation` | 
| `HospitalVisit` | `VisitDate`, `Reason`, `Notes` | 
| `HealthcareProvider` | `ProviderID`, `Name`, `Specialty`, `ContactInformation`, `Address`, `AffiliatedInstitution` | 
| `Symptoms` | `Description`, `RiskFactors` | 
| `Allergies` | `AllergyType`, `Duration` | 
| `Medication` | `MedicationID`, `Name`, `Description`, `Dosage`, `SideEffects`, `Manufacturer` | 
| `PastMedicalHistory` | `ContinuingMedicines` | 
| `MedicalCondition` | `ConditionName`, `Severity`, `TreatmentReceived`, `DoctorinCharge`, `HospitalName`, `MedicinesFollowed` | 
| `BodyVitals` | `HeartRate`, `BloodPressure`, `RespiratoryRate`, `BodyTemperature`, `BMI` | 
| `LabResult` | `LabResultID`, `PatientID`, `TestName`, `Result`, `Date` | 
| `ClinicalTrial` | `TrialID`, `Name`, `Description`, `Phase`, `Status`, `StartDate`, `EndDate` | 
| `GenomicData` | `GenomicDataID`, `PatientID`, `SequenceData`, `VariantInformation` | 
| `Treatment` | `TreatmentID`, `Name`, `Description`, `Type`, `SideEffects` | 
| `MedicalProcedure` | `ProcedureID`, `Name`, `Description`, `Risks`, `Outcomes` | 
| `MedicalConcepts` | `UMLSCodes`, `MedicalVocabularies` | 

A tabela a seguir lista os relacionamentos que as entidades podem ter e seus atributos correspondentes. Por exemplo, a `Patient` entidade pode se conectar à `HospitalVisit` entidade com o `[UNDERGOES]` relacionamento. O atributo desse relacionamento é`VisitDate`.


****  

| Entidade sujeita | Relacionamento | Entidade de objeto | Atributos | 
| --- | --- | --- | --- | 
| `Patient` | `[UNDERGOES]` | `HospitalVisit` | `VisitDate` | 
| `HospitalVisit` | `[VISIT_IN]` | `HealthcareProvider` | `ProviderName`, `Location`, `ProviderID`, `VisitDate` | 
| `HospitalVisit` | `[OBSERVED_CONDITION]` | `Symptoms` | `Severity`, `CurrentStatus`, `VisitDate` | 
| `HospitalVisit` | `[RECEIVED_TREATMENT]` | `Treatment` | `Duration`, `Dosage`, `VisitDate` | 
| `HospitalVisit` | `[PRESCRIBED]` | `Medication` | `Duration`, `Dosage`, `Adherence`, `VisitDate` | 
| `Patient` | `[HAS_HISTORY]` | `PastMedicalHistory` | Nenhum | 
| `PastMedicalHistory` | `[HAD_CONDITION]` | `MedicalCondition` | `DiagnosisDate`, `CurrentStatus` | 
| `HospitalVisit` | `[PARTICIPATES_IN]` | `ClinicalTrial` | `VisitDate`, `Status`, `Outcomes` | 
| `Patient` | `[HAS_GENOMIC_DATA]` | `GenomicData` | `CollectionDate` | 
| `HospitalVisit` | `[OBSERVED_ALLERGIES]` | `Allergies` | `VisitDate` | 
| `HospitalVisit` | `[CONDUCTED_LAB_TEST]` | `LabResult` | `VisitDate`, `AnalysisDate`, `Interpretation` | 
| `HospitalVisit` | `[UNDERGOES]` | `MedicalProcedure` | `VisitDate`, `Outcome` | 
| `MedicalCondition` | `[HAS_TAGGED]` | `MedicalConcepts` | Nenhum | 
| `LabResult` | `[HAS_TAGGED]` | `MedicalConcepts` | Nenhum | 
| `Treatment` | `[HAS_TAGGED]` | `MedicalConcepts` | Nenhum | 
| `Symptoms` | `[HAS_TAGGED]` | `MedicalConcepts` | Nenhum | 

## Etapa 3: Construindo agentes de recuperação de contexto para consultar o gráfico de conhecimento médico
<a name="case-1-step-3"></a>

Depois de criar o banco de dados de gráficos médicos, a próxima etapa é criar agentes para interação gráfica. Os agentes recuperam o contexto correto e necessário para a consulta inserida por um médico ou clínico. Há várias opções para configurar esses agentes que recuperam o contexto do gráfico de conhecimento:
+ [Amazon Bedrock Agents](#case-1-step-3-bedrock-agents)
+ [Agentes do LangChain](#case-1-step-3-langchain-agents)

### Agentes Amazon Bedrock para interação gráfica
<a name="case-1-step-3-bedrock-agents"></a>

[Os agentes](https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html) do Amazon Bedrock funcionam perfeitamente com os bancos de dados gráficos do Amazon Neptune. Você pode realizar interações avançadas por meio dos [grupos de ação](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-action-create.html) do Amazon Bedrock. O grupo de ação inicia o processo chamando uma AWS Lambda função, que executa consultas OpenCypher do Neptune.

Para consultar um gráfico de conhecimento, você pode usar duas abordagens distintas: execução direta de consultas ou consultas com incorporação de contexto. Essas abordagens podem ser aplicadas de forma independente ou combinada, dependendo do seu caso de uso específico e dos critérios de classificação. Ao combinar as duas abordagens, você pode fornecer um contexto mais abrangente ao LLM, o que pode melhorar os resultados. A seguir estão as duas abordagens de execução de consultas:
+ **Execução direta de consultas do Cypher sem incorporações** — A função Lambda executa consultas diretamente no Neptune sem nenhuma pesquisa baseada em incorporações. Veja a seguir um exemplo dessa abordagem:

  ```
  MATCH (p:Patient)-[u:UNDERGOES]->(h:HospitalVisit) WHERE h.Reason = 'Acute Diabetes' AND date(u.VisitDate) > date('2024-01-01')
  RETURN p.PatientID, p.Name, p.Age, p.Gender, p.Address, p.ContactInformation
  ```
+ **Execução direta da consulta Cypher usando a pesquisa incorporada** — A função Lambda usa a pesquisa incorporada para aprimorar os resultados da consulta. Essa abordagem aprimora a execução da consulta incorporando *incorporações*, que são representações vetoriais densas de dados. As incorporações são particularmente úteis quando a consulta exige semelhança semântica ou compreensão mais ampla além das correspondências exatas. Você pode usar modelos pré-treinados ou personalizados para gerar incorporações para cada condição médica. Veja a seguir um exemplo dessa abordagem:

  ```
  CALL { WITH "Acute Diabetes" AS query_term RETURN search_embedding(query_term) AS similar_reasons }
  
  MATCH (p:Patient)-[u:UNDERGOES]->(h:HospitalVisit) WHERE h.Reason IN similar reasons AND date(u.VisitDate) > date('2024-01-01')
  RETURN p.PatientID, p.Name, p.Age, p.Gender, p.Address, p.ContactInformation
  ```

  Neste exemplo, a `search_embedding("Acute Diabetes")` função recupera condições semanticamente próximas de “Diabetes Agudo”. Isso ajuda a consulta a encontrar também pacientes com doenças como pré-diabetes ou síndrome metabólica.

A imagem a seguir mostra como os agentes do Amazon Bedrock interagem com o Amazon Neptune para realizar uma consulta Cypher de um gráfico de conhecimento médico.

![Integração dos agentes do Amazon Bedrock com o Amazon Neptune.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/bedrock-agents-neptune.png)


O diagrama mostra o seguinte fluxo de trabalho:

1. O usuário envia uma pergunta para o agente Amazon Bedrock.

1. O agente do Amazon Bedrock passa as variáveis de pergunta e filtro de entrada para os grupos de ação do Amazon Bedrock. Esses grupos de ação contêm uma AWS Lambda função que interage com o endpoint de incorporação de texto do Amazon SageMaker AI e o gráfico de conhecimento médico do Amazon Neptune.

1. A função Lambda se integra ao endpoint de incorporação de texto de SageMaker IA para realizar uma pesquisa semântica na consulta OpenCypher. Ele converte a consulta de linguagem natural em uma consulta OpenCypher usando agentes subjacentes. LangChain

1. A função Lambda consulta o gráfico de conhecimento médico de Neptune para obter o conjunto de dados correto e recebe a saída do gráfico de conhecimento médico de Neptune.

1. A função Lambda retorna os resultados do Neptune para os grupos de ação do Amazon Bedrock.

1. Os grupos de ação do Amazon Bedrock enviam o contexto recuperado para o agente do Amazon Bedrock.

1. O agente Amazon Bedrock gera a resposta usando a consulta original do usuário e o contexto recuperado do gráfico de conhecimento.

### LangChain agentes para interação gráfica
<a name="case-1-step-3-langchain-agents"></a>

Você pode se integrar LangChain ao Neptune para permitir consultas e recuperações baseadas em gráficos. Essa abordagem pode aprimorar AI-driven os fluxos de trabalho usando os recursos de banco de dados gráficos do Neptune. O LangChain recuperador personalizado atua como intermediário. O modelo básico no Amazon Bedrock pode interagir com o Neptune usando consultas diretas do Cypher e algoritmos gráficos mais complexos.

Você pode usar o recuperador personalizado para refinar a forma como o LangChain agente interage com os algoritmos do gráfico Neptune. Por exemplo, você pode usar a solicitação de algumas etapas, que ajuda a personalizar as respostas do modelo básico com base em padrões ou exemplos específicos. Você também pode aplicar LLM-identified filtros para refinar o contexto e melhorar a precisão das respostas. Isso pode melhorar a eficiência e a precisão do processo geral de recuperação ao interagir com dados gráficos complexos.

A imagem a seguir mostra como um LangChain agente personalizado orquestra a interação entre um modelo da Amazon Bedrock Foundation e um gráfico de conhecimento médico do Amazon Neptune.

![Integração de um agente de LangChain resposta a perguntas com o Amazon Neptune.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/langchain-agents-neptune.png)


O diagrama mostra o seguinte fluxo de trabalho:

1. Um usuário envia uma pergunta para o Amazon Bedrock e para o agente. LangChain

1. O modelo da Amazon Bedrock Foundation usa o esquema Neptune, fornecido pelo agente, para gerar uma consulta para a pergunta LangChain do usuário.

1. O LangChain agente executa a consulta no gráfico de conhecimento médico do Amazon Neptune.

1. O LangChain agente envia o contexto recuperado para o modelo da fundação Amazon Bedrock.

1. O modelo da Amazon Bedrock Foundation usa o contexto recuperado para gerar uma resposta à pergunta do usuário.

## Etapa 4: Criar uma base de conhecimento de dados descritivos em tempo real
<a name="case-1-step-4"></a>

Em seguida, você cria uma base de conhecimento de notas descritivas de interação médico-paciente em tempo real, avaliações de diagnóstico por imagem e relatórios de análises laboratoriais. Essa base de conhecimento é um [banco de dados vetoriais](https://aws.amazon.com/what-is/vector-databases/). Ao usar um banco de dados vetorial, que pode armazenar conhecimento médico descritivo de forma indexada e vetorizada, os profissionais de saúde podem consultar e acessar com eficiência informações relevantes de um vasto repositório. Essas representações vetorizadas ajudam você a recuperar dados semanticamente semelhantes. Os profissionais de saúde podem navegar rapidamente pelas notas clínicas, imagens médicas e resultados laboratoriais. Isso acelera a tomada de decisão informada, oferecendo acesso instantâneo a informações contextualmente relevantes, aumentando a precisão e a velocidade dos diagnósticos e planos de tratamento.

### Usando uma base de conhecimento médico de OpenSearch serviços
<a name="case-1-step-4-opensearch"></a>

[O Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/what-is.html) pode gerenciar grandes volumes de dados médicos de alta dimensão. É um serviço gerenciado que facilita a pesquisa de alto desempenho e a análise em tempo real. É adequado como banco de dados vetoriais para aplicações RAG. OpenSearch O serviço atua como uma ferramenta de back-end para gerenciar grandes quantidades de dados não estruturados ou semiestruturados, como registros médicos, artigos de pesquisa e notas clínicas. Seus recursos avançados de pesquisa semântica ajudam você a recuperar informações contextualmente relevantes. Isso o torna particularmente útil em aplicações como sistemas de apoio à decisão clínica, ferramentas de resolução de consultas de pacientes e sistemas de gerenciamento de conhecimento em saúde. Por exemplo, um médico pode encontrar rapidamente dados relevantes de pacientes ou estudos de pesquisa que correspondam a sintomas ou protocolos de tratamento específicos. Isso ajuda os médicos a tomar decisões baseadas nas informações mais atualizadas e relevantes.

OpenSearch O serviço pode escalar e lidar com indexação e consulta de dados em tempo real. Isso o torna ideal para ambientes dinâmicos de assistência médica, onde o acesso oportuno a informações precisas é fundamental. Além disso, possui recursos de pesquisa multimodais que são ideais para pesquisas que exigem várias entradas, como imagens médicas e anotações médicas. Ao implementar o OpenSearch Service for Healthcare Applications, é fundamental que você defina campos e mapeamentos precisos para otimizar a indexação e a recuperação de dados. *Os campos* representam os dados individuais, como registros de pacientes, históricos médicos e códigos de diagnóstico. *Os mapeamentos* definem como esses campos são armazenados (na forma incorporada ou na forma original) e consultados. Para aplicativos de saúde, é essencial estabelecer mapeamentos que acomodem vários tipos de dados, incluindo dados estruturados (como resultados numéricos de testes), dados semiestruturados (como anotações de pacientes) e dados não estruturados (como imagens médicas)

No OpenSearch Service, você pode realizar consultas de [pesquisa neural](https://opensearch.org/docs/latest/search-plugins/neural-search/) em texto completo por meio de instruções selecionadas para pesquisar registros médicos, notas clínicas ou trabalhos de pesquisa para encontrar rapidamente informações relevantes sobre sintomas, tratamentos ou históricos de pacientes específicos. As consultas de pesquisa neural lidam automaticamente com a incorporação do prompt de entrada e das imagens usando modelos de rede neural integrados. Isso ajuda a entender e capturar as relações semânticas mais profundas em dados multimodais, oferecendo resultados de pesquisa mais precisos e sensíveis ao contexto em comparação com outros algoritmos de consulta de pesquisa, como a pesquisa k-Nearest Neighbor (k-NN).

### Criando uma arquitetura RAG
<a name="case-1-step-4-rag"></a>

Você pode implantar uma solução RAG personalizada que usa agentes do Amazon Bedrock para consultar uma base de conhecimento médico no OpenSearch Service. Para fazer isso, você cria uma AWS Lambda função que pode interagir e consultar o OpenSearch Serviço. A função Lambda incorpora a pergunta de entrada do usuário acessando um endpoint de incorporação de texto de SageMaker IA. O agente Amazon Bedrock passa parâmetros de consulta adicionais como entradas para a função Lambda. A função consulta a base de conhecimento médico no OpenSearch Service, que retorna o conteúdo médico relevante. Depois de configurar a função Lambda, adicione-a como um grupo de ação dentro do agente Amazon Bedrock. O agente Amazon Bedrock pega a entrada do usuário, identifica as variáveis necessárias, passa as variáveis e a pergunta para a função Lambda e, em seguida, inicia a função. A função retorna um contexto que ajuda o modelo básico a fornecer uma resposta mais precisa à pergunta do usuário.

![Integração dos agentes do Amazon Bedrock com um banco de dados de vetores médicos no Amazon OpenSearch Service.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/bedrock-agents-opensearch.png)


O diagrama mostra o seguinte fluxo de trabalho:

1. Um usuário envia uma pergunta para o agente Amazon Bedrock.

1. O agente Amazon Bedrock seleciona qual grupo de ação iniciar.

1. O agente Amazon Bedrock inicia uma AWS Lambda função e passa parâmetros para ela.

1. A função Lambda inicia o modelo de incorporação de texto do Amazon SageMaker AI para incorporar a pergunta do usuário.

1. A função Lambda passa o texto incorporado e os parâmetros e filtros adicionais para o Amazon OpenSearch Service. O Amazon OpenSearch Service consulta a base de conhecimento médico e retorna os resultados para a função Lambda.

1. A função Lambda repassa os resultados para o agente Amazon Bedrock.

1. O modelo básico no agente Amazon Bedrock gera uma resposta com base nos resultados e retorna a resposta ao usuário.

Para situações em que uma filtragem mais complexa está envolvida, você pode usar um LangChain recuperador personalizado. Crie esse recuperador configurando um cliente de pesquisa vetorial de OpenSearch serviço que é carregado diretamente noLangChain. Essa arquitetura permite que você passe mais variáveis para criar os parâmetros do filtro. Depois que o recuperador estiver configurado, use o modelo Amazon Bedrock e o recuperador para configurar uma cadeia de respostas a perguntas de recuperação. Essa cadeia orquestra a interação entre o modelo e o recuperador passando a entrada do usuário e os filtros potenciais para o recuperador. O recuperador retorna o contexto relevante que ajuda o modelo básico a responder à pergunta do usuário.

![Integração de um agente LangChain recuperador com um banco de dados de vetores médicos no OpenSearch Service.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/bedrock-langchain-opensearch.png)


O diagrama mostra o seguinte fluxo de trabalho:

1. Um usuário envia uma pergunta ao agente LangChain recuperador.

1. O agente LangChain recuperador envia a pergunta para o endpoint de incorporação de texto do Amazon SageMaker AI para incorporar a pergunta.

1. O agente LangChain recuperador passa o texto incorporado para o Amazon OpenSearch Service.

1. O Amazon OpenSearch Service devolve os documentos recuperados ao agente LangChain recuperador.

1. O agente LangChain recuperador passa a pergunta do usuário e o contexto recuperado para o modelo da Amazon Bedrock Foundation.

1. O modelo básico gera uma resposta e a envia ao usuário.

## Etapa 5: Usando LLMs para responder perguntas médicas
<a name="case-1-step-5"></a>

As etapas anteriores ajudam você a criar um aplicativo de inteligência médica que pode buscar os registros médicos de um paciente e resumir medicamentos relevantes e possíveis diagnósticos. Agora, você constrói a camada de geração. Essa camada usa os recursos generativos de um LLM no Amazon Bedrock, como o Llama 3, para aumentar a saída do aplicativo.

Quando um médico insere uma consulta, a *camada de recuperação de contexto* do aplicativo executa o processo de recuperação a partir do gráfico de conhecimento e retorna os principais registros relacionados ao histórico, dados demográficos, sintomas, diagnóstico e resultados do paciente. Do banco de dados vetoriais, ele também recupera notas descritivas de interação médico-paciente em tempo real, insights de avaliação de imagens diagnósticas, resumos de relatórios de análises laboratoriais e insights de um grande corpus de pesquisas médicas e livros acadêmicos. Esses principais resultados recuperados, a consulta do médico e os prompts (que são personalizados para selecionar respostas com base na natureza da consulta) são então passados para o modelo básico no Amazon Bedrock. Essa é a *camada de geração de resposta*. O LLM usa o contexto recuperado para gerar uma resposta à consulta do médico. A figura a seguir mostra o fluxo de trabalho completo das etapas dessa solução.

![Usando Serviços da AWS um LLM para gerar respostas a questões médicas.](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/rag-healthcare-use-cases/images/enterprise-cognitive-brain.png)


Você pode usar um modelo básico pré-treinado no Amazon Bedrock, como o Llama 3, para uma variedade de casos de uso que o aplicativo de inteligência médica precisa lidar. O LLM mais eficaz para uma determinada tarefa varia de acordo com o caso de uso. Por exemplo, um modelo pré-treinado pode ser suficiente para resumir conversas médico-paciente, pesquisar medicamentos e históricos de pacientes e recuperar insights de conjuntos de dados médicos internos e corpos de conhecimento científico. No entanto, um LLM aperfeiçoado pode ser necessário para outros casos de uso complexos, como avaliações laboratoriais em tempo real, recomendações de procedimentos médicos e previsões de resultados de pacientes. Você pode ajustar um LLM treinando-o em conjuntos de dados do domínio médico. Requisitos específicos ou complexos de saúde e ciências biológicas impulsionam o desenvolvimento desses modelos aperfeiçoados.

Para obter mais informações sobre como ajustar um LLM ou escolher um LLM existente que tenha sido treinado em dados do domínio médico, consulte [Usando grandes modelos de linguagem para casos de uso de saúde e ciências biológicas](https://docs.aws.amazon.com/prescriptive-guidance/latest/generative-ai-nlp-healthcare/llms.html).

## Alinhamento com o AWS Framework Well-Architected
<a name="case-1-waf-alignment"></a>

A solução se alinha com todos os seis pilares da [AWS Well-Architected Estrutura da seguinte](https://aws.amazon.com/architecture/well-architected/) forma:
+ **Excelência operacional** — A arquitetura é dissociada para monitoramento e atualizações eficientes. Agentes do Amazon Bedrock AWS Lambda ajudam você a implantar e reverter ferramentas rapidamente.
+ **Segurança** — Essa solução foi projetada para estar em conformidade com os regulamentos de saúde, como o HIPAA. Você também pode implementar criptografia, controle de acesso refinado e grades de proteção Amazon Bedrock para ajudar a proteger os dados dos pacientes.
+ **Confiabilidade** — serviços AWS gerenciados, como o Amazon OpenSearch Service e o Amazon Bedrock, fornecem a infraestrutura para a interação contínua do modelo.
+ **Eficiência de desempenho** — A solução RAG recupera dados relevantes rapidamente usando pesquisa semântica otimizada e consultas Cypher, enquanto um roteador agente identifica as rotas ideais para as consultas do usuário.
+ **Otimização de custos** — O modelo de pagamento por token na arquitetura Amazon Bedrock e RAG reduz os custos de inferência e pré-treinamento.
+ **Sustentabilidade** — Usar infraestrutura sem servidor e computação pay-per-token minimiza o uso de recursos e aumenta a sustentabilidade.