View a markdown version of this page

Cas d'utilisation : création d'une application d'intelligence médicale à partir de données augmentées sur les patients - AWS Conseils prescriptifs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Cas d'utilisation : création d'une application d'intelligence médicale à partir de données augmentées sur les patients

L'IA générative peut contribuer à améliorer les soins aux patients et la productivité du personnel en améliorant les fonctions cliniques et administratives. AI-driven l'analyse d'images, telle que l'interprétation des échographies, accélère les processus de diagnostic et améliore la précision. Il peut fournir des informations essentielles qui soutiennent des interventions médicales en temps opportun.

Lorsque vous combinez des modèles d'IA génératifs avec des graphes de connaissances, vous pouvez automatiser l'organisation chronologique des dossiers médicaux électroniques. Cela vous permet d'intégrer les données en temps réel issues des interactions médecin-patient, des symptômes, des diagnostics, des résultats de laboratoire et de l'analyse d'images. Cela fournit au médecin des données complètes sur le patient. Ces données aident le médecin à prendre des décisions médicales plus précises et plus rapides, améliorant à la fois les résultats pour les patients et la productivité des prestataires de soins de santé.

Présentation de la solution

L'IA peut renforcer les capacités des médecins et des cliniciens en synthétisant les données des patients et les connaissances médicales afin de fournir des informations précieuses. Cette solution RAG (Retrieval Augmented Generation) est un moteur d'intelligence médicale qui utilise un ensemble complet de données et de connaissances sur les patients issues de millions d'interactions cliniques. Il exploite le pouvoir de l'IA générative pour créer des informations fondées sur des preuves afin d'améliorer les soins aux patients. Il est conçu pour améliorer les flux de travail cliniques, réduire les erreurs et améliorer les résultats pour les patients.

La solution inclut une capacité de traitement d'image automatique alimentée par des LLM. Cette fonctionnalité réduit le temps que le personnel médical doit consacrer à la recherche manuelle d'images diagnostiques similaires et à l'analyse des résultats de diagnostic.

L'image suivante montre le flux de travail de bout en bout de cette solution. Il utilise Amazon Neptune, Amazon SageMaker AI, Amazon OpenSearch Service et un modèle de base dans Amazon Bedrock. Pour l'agent de récupération du contexte qui interagit avec le graphe des connaissances médicales dans Neptune, vous pouvez choisir entre un agent Amazon Bedrock et un agent. LangChain

Utilisation Services AWS d'un LLM pour générer des réponses aux questions médicales.

Lors de nos expériences avec des exemples de questions médicales, nous avons observé que les réponses finales générées par notre approche utilisant le graphe de connaissances géré dans Neptune, une base de données OpenSearch vectorielle hébergeant la base de connaissances cliniques et les LLM d'Amazon Bedrock étaient fondées sur des faits et étaient bien plus précises en réduisant le nombre de faux positifs et en augmentant les vrais positifs. Cette solution peut générer des informations factuelles sur l'état de santé du patient et vise à améliorer les flux de travail cliniques, à réduire les erreurs et à améliorer les résultats pour les patients.

La création de cette solution comprend les étapes suivantes :

Étape 1 : Découverte des données

Il existe de nombreux ensembles de données médicales open source que vous pouvez utiliser pour soutenir le développement d'une AI-driven solution de santé. L'un de ces ensembles de données est le MIMIC-IV jeu de données, qui est un ensemble de données de dossiers de santé électroniques (DSE) accessible au public qui est largement utilisé dans le milieu de la recherche en santé. MIMIC-IV contient des informations cliniques détaillées, y compris des notes de sortie en texte libre extraites des dossiers des patients. Vous pouvez utiliser ces enregistrements pour expérimenter des techniques de sommation de texte et d'extraction d'entités. Ces techniques vous aident à extraire des informations médicales (telles que les symptômes du patient, les médicaments administrés et les traitements prescrits) à partir de texte non structuré.

Vous pouvez également utiliser un ensemble de données qui fournit des résumés de sortie de patients annotés et anonymisés, spécialement conçus à des fins de recherche. Un ensemble de données récapitulatives sur les sorties peut vous aider à expérimenter l'extraction d'entités, ce qui vous permet d'identifier les entités médicales clés (telles que les affections, les procédures et les médicaments) à partir du texte. Étape 2 : Création d'un graphe des connaissances médicalesdans ce guide, décrit comment vous pouvez utiliser les données structurées extraites des ensembles de données récapitulatifs MIMIC-IV et des ensembles de données récapitulatifs des sorties pour créer un graphique des connaissances médicales. Ce graphe de connaissances médicales sert de colonne vertébrale aux systèmes avancés d'interrogation et d'aide à la décision destinés aux professionnels de santé.

Outre les jeux de données textuels, vous pouvez utiliser des jeux de données d'images. Par exemple, le jeu de données sur les radiographies musculosquelettiques (MURA), qui est une base de données complète d'images radiographiques multivues des os. Utilisez ces ensembles de données d'images pour expérimenter l'évaluation diagnostique à l'aide de techniques de décodage d'images médicales. Ces techniques de décodage sont cruciales pour le diagnostic précoce de maladies telles que les maladies musculosquelettiques, les maladies cardiovasculaires et l'ostéoporose. En affinant les modèles de base de la vision et du langage sur le jeu de données d'images médicales, vous pouvez détecter des anomalies dans les images diagnostiques. Cela permet au système de fournir aux cliniciens des informations diagnostiques précoces et précises. En utilisant des ensembles de données d'images et de textes, vous pouvez créer une application AI-driven médicale capable de traiter à la fois du texte et des données d'image pour améliorer les soins aux patients.

Étape 2 : Création d'un graphe des connaissances médicales

Pour tout établissement de santé qui souhaite créer un système d'aide à la décision basé sur une base de connaissances massive, l'un des principaux défis consiste à localiser et à extraire les entités médicales présentes dans les notes cliniques, les revues médicales, les résumés de sortie et les autres sources de données. Vous devez également capturer les relations temporelles, les sujets et les évaluations de certitude de ces dossiers médicaux afin d'utiliser efficacement les entités, les attributs et les relations extraits.

La première étape consiste à extraire des concepts médicaux d'un texte médical non structuré en utilisant quelques instructions pour un modèle de base, tel que Llama 3 dans Amazon Bedrock. Few-shot l'invite se produit lorsque vous fournissez à un LLM un petit nombre d'exemples illustrant la tâche et le résultat souhaité avant de lui demander d'effectuer une tâche similaire. À l'aide d'un extracteur d'entités LLM-based médicales, vous pouvez analyser le texte médical non structuré, puis générer une représentation des données structurées des entités de connaissances médicales. Vous pouvez également stocker les attributs du patient à des fins d'analyse et d'automatisation en aval. Le processus d'extraction des entités inclut les actions suivantes :

La figure suivante montre les étapes d'extraction d'entités et de validation du schéma pour créer des combinaisons appariées valides d'entités, d'attributs et de relations. Vous pouvez stocker des données non structurées, telles que des résumés de sortie ou des notes de patients, dans Amazon Simple Storage Service (Amazon S3). Vous pouvez stocker des données structurées, telles que les données de planification des ressources d'entreprise (ERP), les dossiers médicaux électroniques et les systèmes d'information de laboratoire, dans Amazon Redshift et Amazon DynamoDB. Vous pouvez créer un agent de création d'entités Amazon Bedrock. Cet agent peut intégrer des services, tels que les pipelines d'extraction de données Amazon SageMaker AI, Amazon Textract et Amazon Comprehend Medical, pour extraire des entités, des relations et des attributs à partir de sources de données structurées et non structurées. Enfin, vous utilisez un agent de validation de schéma Amazon Bedrock pour vous assurer que les entités et les relations extraites sont conformes au schéma de graphe prédéfini et préservent l'intégrité des connexions au bord du nœud et des propriétés associées.

Flux de travail pour l'extraction des entités et la validation du schéma.

Après extraction et validation des entités, des relations et des attributs, vous pouvez les lier pour créer un triplet sujet-objet-prédicat. Vous ingérez ces données dans une base de données de graphes Amazon Neptune, comme illustré dans la figure suivante. Les bases de données de graphes sont optimisées pour stocker et interroger les relations entre les éléments de données.

Graphique des connaissances médicales qui fait correspondre les entités à leurs attributs.

Vous pouvez créer un graphe de connaissances complet à partir de ces données. Un graphe de connaissances vous aide à organiser et à interroger toutes sortes d'informations connectées. Par exemple, vous pouvez créer un graphe de connaissances comportant les nœuds principaux suivants : HospitalVisitPastMedicalHistory,Symptoms,Medication,MedicalProcedures, etTreatment.

Les tableaux suivants répertorient les entités et leurs attributs que vous pouvez extraire des notes de décharge.

Entité Attributes

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

Le tableau suivant répertorie les relations que les entités peuvent avoir et leurs attributs correspondants. Par exemple, l'Patiententité peut se connecter à l'HospitalVisitentité associée à la [UNDERGOES] relation. L'attribut de cette relation estVisitDate.

Entité visée Relation Entité d'objet Attributes

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

Aucune

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

Aucun

LabResult

[HAS_TAGGED]

MedicalConcepts

Aucun

Treatment

[HAS_TAGGED]

MedicalConcepts

Aucun

Symptoms

[HAS_TAGGED]

MedicalConcepts

Aucune

Étape 3 : Création d'agents de récupération du contexte pour interroger le graphe des connaissances médicales

Après avoir créé la base de données de graphes médicaux, l'étape suivante consiste à créer des agents pour l'interaction graphique. Les agents récupèrent le contexte correct et requis pour la requête saisie par un médecin ou un clinicien. Il existe plusieurs options pour configurer ces agents qui récupèrent le contexte à partir du Knowledge Graph :

Agents Amazon Bedrock pour l'interaction graphique

Les agents Amazon Bedrock fonctionnent parfaitement avec les bases de données graphiques Amazon Neptune. Vous pouvez effectuer des interactions avancées via les groupes d'actions Amazon Bedrock. Le groupe d'actions lance le processus en appelant une AWS Lambda fonction qui exécute les requêtes Neptune OpenCypher.

Pour interroger un graphe de connaissances, vous pouvez utiliser deux approches distinctes : exécution directe de requêtes ou interrogation avec intégration de contexte. Ces approches peuvent être appliquées indépendamment ou combinées, en fonction de votre cas d'utilisation spécifique et de vos critères de classement. En combinant les deux approches, vous pouvez fournir un contexte plus complet au LLM, ce qui peut améliorer les résultats. Les deux approches d'exécution des requêtes sont les suivantes :

  • Exécution directe de requêtes Cypher sans intégration — La fonction Lambda exécute des requêtes directement sur Neptune sans aucune recherche basée sur les intégrations. Voici un exemple de cette approche :

    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
  • Exécution directe de requêtes Cypher à l'aide de la recherche incorporée — La fonction Lambda utilise la recherche incorporée pour améliorer les résultats des requêtes. Cette approche améliore l'exécution des requêtes en incorporant des intégrations, qui sont des représentations vectorielles denses de données. Les intégrations sont particulièrement utiles lorsque la requête nécessite une similitude sémantique ou une compréhension plus large au-delà des correspondances exactes. Vous pouvez utiliser des modèles pré-entraînés ou personnalisés pour générer des intégrations pour chaque condition médicale. Voici un exemple de cette approche :

    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

    Dans cet exemple, la search_embedding("Acute Diabetes") fonction récupère des affections dont la sémantique est proche du « diabète aigu ». Cela permet à la requête de trouver également des patients atteints de maladies telles que le prédiabète ou le syndrome métabolique.

L'image suivante montre comment les agents Amazon Bedrock interagissent avec Amazon Neptune afin d'exécuter une requête Cypher sur un graphe de connaissances médicales.

Intégration des agents Amazon Bedrock à Amazon Neptune.

Le schéma suivant illustre le flux de travail suivant :

  1. L'utilisateur soumet une question à l'agent Amazon Bedrock.

  2. L'agent Amazon Bedrock transmet la question et les variables du filtre d'entrée aux groupes d'action Amazon Bedrock. Ces groupes d'actions contiennent une AWS Lambda fonction qui interagit avec le point de terminaison d'intégration de texte Amazon SageMaker AI et le graphe de connaissances médicales Amazon Neptune.

  3. La fonction Lambda s'intègre au point de terminaison d'intégration de texte SageMaker AI pour effectuer une recherche sémantique dans la requête OpenCypher. Il convertit la requête en langage naturel en une requête OpenCypher en utilisant des agents sous-jacentsLangChain.

  4. La fonction Lambda interroge le graphe de connaissances médicales de Neptune pour trouver le jeu de données correct et reçoit le résultat du graphe de connaissances médicales de Neptune.

  5. La fonction Lambda renvoie les résultats de Neptune aux groupes d'actions Amazon Bedrock.

  6. Les groupes d'action Amazon Bedrock envoient le contexte récupéré à l'agent Amazon Bedrock.

  7. L'agent Amazon Bedrock génère la réponse en utilisant la requête utilisateur d'origine et le contexte extrait du graphe de connaissances.

LangChain agents pour l'interaction graphique

Vous pouvez intégrer Neptune pour permettre LangChain des requêtes et des extractions basées sur des graphes. Cette approche peut améliorer les AI-driven flux de travail en utilisant les fonctionnalités de base de données de graphes de Neptune. Le Custom LangChain Retriever joue le rôle d'intermédiaire. Le modèle de base d'Amazon Bedrock peut interagir avec Neptune en utilisant à la fois des requêtes Cypher directes et des algorithmes de graphes plus complexes.

Vous pouvez utiliser le récupérateur personnalisé pour affiner la façon dont l'LangChainagent interagit avec les algorithmes du graphe Neptune. Par exemple, vous pouvez utiliser des instructions ponctuelles, qui vous permettent d'adapter les réponses du modèle de base en fonction de modèles ou d'exemples spécifiques. Vous pouvez également appliquer des LLM-identified filtres pour affiner le contexte et améliorer la précision des réponses. Cela peut améliorer l'efficacité et la précision de l'ensemble du processus de récupération lors de l'interaction avec des données graphiques complexes.

L'image suivante montre comment un LangChain agent personnalisé orchestre l'interaction entre un modèle de fondation Amazon Bedrock et un graphe de connaissances médicales Amazon Neptune.

Intégration d'un agent de LangChain réponse aux questions avec Amazon Neptune.

Le schéma suivant illustre le flux de travail suivant :

  1. Un utilisateur soumet une question à Amazon Bedrock et à l'LangChainagent.

  2. Le modèle Amazon Bedrock Foundation utilise le schéma Neptune, fourni par LangChain l'agent, pour générer une requête pour la question de l'utilisateur.

  3. L'LangChainagent exécute la requête sur le graphe de connaissances médicales d'Amazon Neptune.

  4. L'LangChainagent envoie le contexte récupéré au modèle de fondation Amazon Bedrock.

  5. Le modèle Amazon Bedrock Foundation utilise le contexte extrait pour générer une réponse à la question de l'utilisateur.

Étape 4 : Création d'une base de connaissances contenant des données descriptives en temps réel

Ensuite, vous créez une base de connaissances contenant des notes descriptives en temps réel sur les interactions médecin-patient, des évaluations d'images diagnostiques et des rapports d'analyse de laboratoire. Cette base de connaissances est une base de données vectorielle. En utilisant une base de données vectorielle, qui peut stocker des connaissances médicales descriptives sous une forme indexée et vectorisée, les prestataires de soins de santé peuvent consulter et accéder efficacement aux informations pertinentes à partir d'un vaste référentiel. Ces représentations vectorisées vous aident à récupérer des données sémantiquement similaires. Les prestataires de soins peuvent parcourir rapidement les notes cliniques, les images médicales et les résultats de laboratoire. Cela accélère la prise de décision éclairée en offrant un accès instantané à des informations contextuelles pertinentes, améliorant ainsi la précision et la rapidité des diagnostics et des plans de traitement.

Utilisation d'une base de connaissances médicales de OpenSearch service

Amazon OpenSearch Service peut gérer de gros volumes de données médicales de grande dimension. Il s'agit d'un service géré qui facilite les recherches de haute performance et les analyses en temps réel. Elle convient parfaitement comme base de données vectorielle pour les applications RAG. OpenSearch Le service agit comme un outil principal pour gérer de grandes quantités de données non structurées ou semi-structurées, telles que les dossiers médicaux, les articles de recherche et les notes cliniques. Ses fonctionnalités avancées de recherche sémantique vous aident à récupérer des informations contextuellement pertinentes. Cela le rend particulièrement utile dans des applications telles que les systèmes d'aide à la décision clinique, les outils de résolution des requêtes des patients et les systèmes de gestion des connaissances dans le domaine de la santé. Par exemple, un clinicien peut rapidement trouver des données pertinentes sur les patients ou des études de recherche correspondant à des symptômes ou à des protocoles de traitement spécifiques. Cela aide les cliniciens à prendre des décisions éclairées par les informations les plus récentes et les plus pertinentes.

OpenSearch Le service peut évoluer et gérer l'indexation et l'interrogation des données en temps réel. Il est donc idéal pour les environnements de santé dynamiques où l'accès rapide à des informations précises est essentiel. En outre, il dispose de fonctionnalités de recherche multimodales qui sont optimales pour les recherches nécessitant plusieurs entrées, telles que des images médicales et des notes de médecin. Lors de la mise en œuvre du OpenSearch service pour les applications de santé, il est essentiel de définir des champs et des mappages précis afin d'optimiser l'indexation et la récupération des données. Les champs représentent les différents éléments de données, tels que les dossiers des patients, les antécédents médicaux et les codes de diagnostic. Les mappages définissent la manière dont ces champs sont stockés (sous forme incorporée ou sous forme originale) et interrogés. Pour les applications de santé, il est essentiel d'établir des mappages adaptés à différents types de données, notamment les données structurées (telles que les résultats de tests numériques), les données semi-structurées (telles que les notes des patients) et les données non structurées (telles que les images médicales)

Dans OpenSearch Service, vous pouvez effectuer des requêtes de recherche neurale en texte intégral à l'aide d'instructions organisées pour effectuer des recherches dans les dossiers médicaux, les notes cliniques ou les documents de recherche afin de trouver rapidement des informations pertinentes sur des symptômes, des traitements ou des antécédents de patients spécifiques. Les requêtes de recherche neuronale gèrent automatiquement l'intégration de l'invite d'entrée et des images à l'aide de modèles de réseaux neuronaux intégrés. Cela l'aide à comprendre et à saisir les relations sémantiques les plus profondes des données multimodales, offrant ainsi des résultats de recherche plus précis et plus sensibles au contexte par rapport à d'autres algorithmes de requête de recherche, tels que la recherche K-Nearest Neighbor (K-nn).

Création d'une architecture RAG

Vous pouvez déployer une solution RAG personnalisée qui utilise les agents Amazon Bedrock pour interroger une base de connaissances médicales dans OpenSearch Service. Pour ce faire, vous créez une AWS Lambda fonction qui peut interagir avec le OpenSearch service et l'interroger. La fonction Lambda intègre la question saisie par l'utilisateur en accédant à un point de terminaison d'intégration de texte basé sur SageMaker l'IA. L'agent Amazon Bedrock transmet des paramètres de requête supplémentaires en tant qu'entrées à la fonction Lambda. La fonction interroge la base de connaissances médicales dans OpenSearch Service, qui renvoie le contenu médical pertinent. Après avoir configuré la fonction Lambda, ajoutez-la en tant que groupe d'action dans l'agent Amazon Bedrock. L'agent Amazon Bedrock prend les données saisies par l'utilisateur, identifie les variables nécessaires, transmet les variables et la question à la fonction Lambda, puis lance la fonction. La fonction renvoie un contexte qui aide le modèle de base à fournir une réponse plus précise à la question de l'utilisateur.

Intégration des agents Amazon Bedrock à une base de données de vecteurs médicaux sur Amazon OpenSearch Service.

Le schéma suivant illustre le flux de travail suivant :

  1. Un utilisateur soumet une question à l'agent Amazon Bedrock.

  2. L'agent Amazon Bedrock sélectionne le groupe d'action à lancer.

  3. L'agent Amazon Bedrock lance une AWS Lambda fonction et lui transmet des paramètres.

  4. La fonction Lambda lance le modèle d'intégration de texte Amazon SageMaker AI pour intégrer la question de l'utilisateur.

  5. La fonction Lambda transmet le texte intégré ainsi que les paramètres et filtres supplémentaires à Amazon OpenSearch Service. Amazon OpenSearch Service interroge la base de connaissances médicales et renvoie les résultats à la fonction Lambda.

  6. La fonction Lambda transmet les résultats à l'agent Amazon Bedrock.

  7. Le modèle de base de l'agent Amazon Bedrock génère une réponse basée sur les résultats et renvoie la réponse à l'utilisateur.

Pour les situations impliquant un filtrage plus complexe, vous pouvez utiliser un LangChain récupérateur personnalisé. Créez ce récupérateur en configurant un client de recherche vectorielle OpenSearch Service qui est chargé directement dansLangChain. Cette architecture vous permet de transmettre davantage de variables afin de créer les paramètres du filtre. Une fois le récupérateur configuré, utilisez le modèle et le récupérateur Amazon Bedrock pour configurer une chaîne de questions-réponses. Cette chaîne orchestre l'interaction entre le modèle et le récupérateur en transmettant les entrées utilisateur et les filtres potentiels au récupérateur. Le récupérateur renvoie un contexte pertinent qui aide le modèle de base à répondre à la question de l'utilisateur.

Intégration d'un agent LangChain retriever à une base de données de vecteurs médicaux sur OpenSearch Service.

Le schéma suivant illustre le flux de travail suivant :

  1. Un utilisateur soumet une question à l'agent LangChain de récupération.

  2. L'agent de LangChain récupération envoie la question au point de terminaison d'intégration de texte Amazon SageMaker AI pour l'intégrer.

  3. L'agent LangChain de récupération transmet le texte intégré à Amazon OpenSearch Service.

  4. Amazon OpenSearch Service renvoie les documents récupérés à l'agent de LangChain récupération.

  5. L'agent de LangChain récupération transmet la question de l'utilisateur et le contexte extrait au modèle Amazon Bedrock Foundation.

  6. Le modèle de base génère une réponse et l'envoie à l'utilisateur.

Étape 5 : Utiliser les LLM pour répondre à des questions médicales

Les étapes précédentes vous aident à créer une application de renseignement médical capable de récupérer les dossiers médicaux d'un patient et de résumer les médicaments pertinents et les diagnostics potentiels. À présent, vous créez la couche de génération. Cette couche utilise les capacités génératives d'un LLM dans Amazon Bedrock, comme Llama 3, pour augmenter le rendement de l'application.

Lorsqu'un clinicien saisit une requête, la couche de récupération du contexte de l'application exécute le processus de récupération à partir du graphe de connaissances et renvoie les principaux enregistrements relatifs à l'historique, à la démographie, aux symptômes, au diagnostic et aux résultats du patient. À partir de la base de données vectorielle, il extrait également des notes descriptives en temps réel sur les interactions médecin-patient, des informations sur l'évaluation des images diagnostiques, des résumés de rapports d'analyse de laboratoire et des informations issues d'un vaste corpus de recherches médicales et de livres universitaires. Les meilleurs résultats obtenus, la requête du clinicien et les instructions (qui sont conçues pour sélectionner les réponses en fonction de la nature de la requête) sont ensuite transmis au modèle de base d'Amazon Bedrock. Il s'agit de la couche de génération de réponses. Le LLM utilise le contexte récupéré pour générer une réponse à la requête du clinicien. La figure suivante montre le flux de travail de bout en bout des étapes de cette solution.

Utilisation Services AWS d'un LLM pour générer des réponses aux questions médicales.

Vous pouvez utiliser un modèle de base préformé dans Amazon Bedrock, tel que Llama 3, pour une gamme de cas d'utilisation que l'application de renseignement médical doit gérer. Le LLM le plus efficace pour une tâche donnée varie en fonction du cas d'utilisation. Par exemple, un modèle préformé peut être suffisant pour résumer les conversations patient-médecin, effectuer des recherches dans les médicaments et les antécédents des patients, et extraire des informations à partir d'ensembles de données médicales internes et de corpus de connaissances scientifiques. Cependant, un LLM affiné peut être nécessaire pour d'autres cas d'utilisation complexes, tels que les évaluations de laboratoire en temps réel, les recommandations de procédures médicales et les prédictions des résultats pour les patients. Vous pouvez affiner un LLM en l'entraînant sur des ensembles de données du domaine médical. Des exigences spécifiques ou complexes dans le domaine des soins de santé et des sciences de la vie orientent le développement de ces modèles affinés.

Pour plus d'informations sur la mise au point d'un LLM ou sur le choix d'un LLM existant qui a été formé sur les données du domaine médical, voir Utilisation de grands modèles linguistiques pour les cas d'utilisation dans les domaines de la santé et des sciences de la vie.

Alignement sur le AWS Well-Architected Framework

La solution s'aligne sur les six piliers du AWS Well-Architected cadre comme suit :

  • Excellence opérationnelle — L'architecture est découplée pour une surveillance et des mises à jour efficaces. Les agents Amazon Bedrock vous AWS Lambda aident à déployer et à annuler rapidement des outils.

  • Sécurité — Cette solution est conçue pour se conformer aux réglementations sanitaires, telles que la loi HIPAA. Vous pouvez également implémenter le chiffrement, un contrôle d'accès précis et des garde-corps Amazon Bedrock pour protéger les données des patients.

  • Fiabilité : les services AWS gérés, tels qu'Amazon OpenSearch Service et Amazon Bedrock, fournissent l'infrastructure nécessaire à une interaction continue avec les modèles.

  • Efficacité des performances — La solution RAG récupère rapidement les données pertinentes en utilisant une recherche sémantique optimisée et des requêtes Cypher, tandis qu'un agent-routeur identifie les itinéraires optimaux pour les requêtes des utilisateurs.

  • Optimisation des coûts — Le modèle de paiement par jeton d'Amazon Bedrock et de l'architecture RAG réduit les coûts d'inférence et de pré-formation.

  • Durabilité — L'utilisation d'une infrastructure sans serveur et d'un calcul basé sur le paiement par jeton minimise l'utilisation des ressources et améliore la durabilité.