Method Article

Synthèse des connaissances fondées sur des données probantes et validation d’hypothèses : naviguer dans les bases de connaissances biomédicales via l’IA explicable et les systèmes agentiques

DOI:

10.3791/67525

⸱

June 13th, 2025

 ,  ,  ,  ,  ,  ,  ,  , 
1Department of Physiology, UCLA School of Medicine, 2Scalable Analytics Institute (ScAi) at Department of Computer Science, UCLA School of Engineering, 3Medical Informatics, University of California at Los Angeles (UCLA), 4Department of Medicine (Cardiology), UCLA School of Medicine

In This Article

Summary

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Cet article décrit RUGGED (Retrieval Under Graph-Guided Explainable disease Distinction), qui intègre l’inférence LLM (Large Language Model) à la génération augmentée par récupération (RAG). Il s’appuie sur des bases de connaissances biomédicales organisées par des experts et des publications biomédicales évaluées par des pairs afin de synthétiser de nouvelles connaissances à partir d’informations à jour, d’identifier des prédictions explicables et exploitables et d’identifier des directions prometteuses pour des investigations fondées sur des hypothèses.

Abstract

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

L’ampleur des connaissances biomédicales, qui englobent la littérature scientifique et les bases de connaissances organisées, pose un défi important aux chercheurs pour traiter, évaluer et interpréter efficacement les résultats. Les grands modèles de langage (LLM) sont apparus comme des outils puissants pour naviguer dans ce paysage complexe de connaissances, mais peuvent produire des réponses hallucinatoires. La génération augmentée par récupération (RAG) est essentielle pour identifier les informations pertinentes afin d’améliorer la précision et la fiabilité. Ce protocole introduit RUGGED (Retrieval Under Graph-Guided Explainable disease Distinction), un flux de travail complet conçu pour soutenir l’intégration des connaissances, atténuer les biais et explorer et valider de nouvelles orientations de recherche. Les informations biomédicales provenant de publications et de bases de connaissances sont synthétisées et analysées par le biais d’une analyse d’association par exploration de texte et de modèles de prédiction de graphiques explicables afin de découvrir des relations potentielles entre les médicaments et les maladies. Ces résultats, ainsi que le corpus de textes sources et les bases de connaissances, sont intégrés dans un cadre qui utilise des LLM améliorés par RAG pour permettre aux utilisateurs d’explorer des hypothèses et d’enquêter sur les mécanismes sous-jacents. Un cas d’utilisation clinique démontre la capacité de RUGGED à évaluer et à recommander des traitements pour la cardiomyopathie arythmogène (MCA) et la cardiomyopathie dilatée (CMD), en analysant les médicaments prescrits pour les interactions moléculaires et les nouvelles applications potentielles. La plateforme réduit les hallucinations liées au LLM, met en évidence des informations exploitables et rationalise l’investigation de nouvelles thérapies.

Introduction

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Le processus d’exploration d’hypothèses dans l’entreprise biomédicale est essentiel pour découvrir de nouvelles interdépendances molécules-médicament-maladie sous-jacentes à la pathogenèse et pour libérer le potentiel thérapeutique 1,2. Ce processus tire des données probantes des connaissances biomédicales existantes, synthétise les nouvelles découvertes sur des pistes logiques intégrées dans la littérature évaluée par des pairs (p. ex., >36 rapports de PubMed) et intègre des données probantes de haute confiance ancrées dans les bases de connaissances biomédicales. Les progrès récents réduisent les efforts manuels laborieux en appliquant l’exploration de texte sur les corpus de littérature 3,4,5 ainsi que l’utilisation d’analyses graphiques 6,7,8,9 pour synthétiser les informations pertinentes et découvrir de nouvelles voies d’investigation. Malgré ces efforts, les approches actuelles ne permettent souvent pas une compréhension contextuelle approfondie en raison de données fragmentées. De plus, ils n’ont pas la capacité de tirer des conclusions fondées sur des preuves et d’explorer de manière interactive de nouvelles hypothèses.

Les développements récents dans les grands modèles de langage (LLM) jettent un nouvel éclairage sur ces défis, démontrant une compréhension contextuelle de haut niveau par la formation sur de grandes quantités d’informations dans plusieurs disciplines 10,11,12. Dans le domaine biomédical, les LLM ont montré un rôle prometteur dans l’extraction d’informations sur les patients13 et de réponses à des questions cliniques générales14,15, tandis que les applications dans les réponses aux questions spécifiques à un domaine16 et les utilités dans les soins cliniques primaires17 restent à explorer. Ces modèles présentent la capacité de raisonner et de tirer des inférences à partir d’ensembles de données complexes, ce qui les rend potentiellement adaptés à la conduite d’hypothèses, d’exploration et de synthèse de connaissances. De plus, certains modèles proposent une interaction de type chat pour engager les utilisateurs et permettre une exploration dynamique des sujets, dépassant les limites conventionnelles des moteurs de recherche basés sur des requêtes et des bases de connaissances18,19.

En plus de ces potentiels, les LLM sont confrontés à des défis importants, tels que l’hallucination possible de l’information, l’affichage d’une confiance injustifiée dans des explications potentiellement inexactes, le manque d’intelligibilité et la sensibilité à un contenu biaisé ou inapproprié 20,21,22,23,24. Appliquées directement à l’orientation de la prise de décision clinique, les réponses et les prédictions dérivées de la LLM ont des enjeux élevés ; Toute erreur peut entraîner des expériences de laboratoire coûteuses ou affecter négativement les trajectoires de santé des patients25,26. Ainsi, des réponses LLM fiables et dignes de confiance sont primordiales, car leurs conseils doivent être fermement ancrés dans des preuves. Dans ces scénarios, l’interprétabilité n’est pas un luxe mais une nécessité pour comprendre pourquoi ces modèles font les prédictions qu’ils font.

À cette fin, la génération augmentée par récupération (RAG) est un système conçu pour minimiser les hallucinations LLM, en fondant les réponses LLM sur des preuves afin d’améliorer leur précision et leur fiabilité27,28. Cette approche implique généralement la récupération de passages de texte pertinents, comme l’intégration d’un LLM (par exemple, ChatGPT) à PubMed, permettant d’identifier les citations pertinentes aux requêtes des utilisateurs29,30. Non limitée au texte, la recherche sur les graphes de connaissances (KG) s’avère prometteuse pour l’application aux LLM pour des tâches telles que la vérification des faits 31,32,33, le raisonnement transparent 34,35,36, l’encodage des connaissances37, l’amélioration de la réponse aux questions38 et la complétion des graphes de connaissances 39. En codant des informations factuelles provenant de sources vérifiées, les KG améliorent l’exactitude, la transparence et la fiabilité des réponses LLM. Les techniques de prédiction de liens au sein de ces graphes exploitent l’apprentissage profond pour identifier des relations auparavant cachées entre les molécules, les médicaments et les maladies 5,40,41. Les progrès récents dans les prédictions explicables de l’IA améliorent encore la transparence et l’intelligibilité de ces tâches de prédiction de liens, apportant un soutien potentiel à l’interprétation des hypothèses biomédicales comme une voie viable pour l’investigation 42,43,44. Ces avancées garantissent que les réponses générées par le LLM sont équilibrées et tirées des preuves, ce qui augmente considérablement leur applicabilité dans les entreprises biomédicales.

Ce protocole présente RUGGED (Retrieval Under Graph-Guided Explainable disease Distinction) comme un flux de travail accessible et efficace pour l’exploration et la validation des connaissances thérapeutiques cliniques (Figure 1). Ce protocole de flux de travail exploite les vastes ressources de la littérature biomédicale et des bases de connaissances pour l’extraction et la validation d’informations pertinentes, permettant ainsi des processus de récupération adaptés aux requêtes (Figure 2). Un modèle de prédiction explicable par intelligence artificielle est utilisé pour découvrir des informations interprétables et exploitables à partir des connaissances biomédicales existantes, améliorant ainsi la transparence et l’utilité des modèles prédictifs. Le flux de travail complet rationalise l’exploration des graphes de connaissances et des prédictions de modèles via des LLM compatibles RAG, facilitant ainsi des interactions intuitives et éclairées pour les investigateurs, les cliniciens et les professionnels cliniques.

Cette section jette les bases du protocole, avec les étapes de mise en œuvre de cette approche décrites dans la section suivante. Ensuite, un cas d’utilisation clinique translationnelle est présenté pour démontrer cette approche, appliquée à l’évaluation de médicaments pour les interactions moléculaires ainsi qu’aux stratégies thérapeutiques pour la médecine cardiovasculaire. Enfin, les implications et la discussion de ce protocole sont discutées.

Protocol

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Ce protocole a été développé en Python 3.10 et implémenté en tant que conteneur Docker dans Windows. Les commandes fournies sont basées sur l’environnement Unix au sein du conteneur Docker. Le logiciel est disponible à l’adresse https://github.com/pinglab-utils/RUGGED. Le tableau 1 présente une estimation du temps de calcul pour toutes les étapes du protocole.

1. Installation du logiciel

  1. Installez le logiciel requis en suivant les instructions de la Table des matériaux.
    REMARQUE : Ce protocole nécessite le contrôle de version, la conteneurisation, une base de données de graphes et un ou plusieurs services de modèle de langage volumineux (LLM). Le contrôle de version et la conteneurisation sont facultatifs, mais peuvent simplifier le processus de configuration. la base de données de graphes et les services LLM peuvent être remplacés par des outils similaires si l’utilisateur est techniquement compétent.
    1. Configurer la mise en réseau inter-conteneurs. Configurez les conteneurs Docker pour qu’ils soient connectés à d’autres services sur l’appareil (par exemple, d’autres conteneurs Docker). Tapez la commande suivante dans le terminal : docker network create rugged_network
  2. Configurez des services de modèles de langage volumineux (LLM). Choisissez le service LLM approprié pour le cas d’utilisation, parmi les services LLM commerciaux ou les services d’un modèle local s’exécutant sur l’appareil de l’utilisateur. Assurez-vous qu’au moins un service LLM est spécifié, bien que les agents puissent être mélangés et appariés pour tirer parti de différents modèles.
    1. Démarrez le service LLM local. Si vous utilisez Ollama à l’aide d’une interface utilisateur graphique (GUI), exécutez l’exécutable de l’interface graphique (par exemple, ollama.exe). Si vous utilisez Docker, exécutez : 'docker run -name ollama --net rugged_network d -v ollama :/root/.ollama -p 11434:11434 ollama/ollama'. Si vous utilisez Docker avec l’accélération GPU, assurez-vous que le pilote GPU est installé et exécutez : 'docker run -name ollama --net rugged_network -d --gpus=all -v ollama :/root/.ollama -p 11434:11434 ollama/ollama'.
    2. Initialisez le modèle LLM local. Déterminez le modèle à utiliser parmi les modèles pris en charge (par exemple, Recommandé : llama3, mistral, mixtral. Si vous utilisez Docker, tapez 'docker exec run ollama run ' dans la ligne de commande ; si vous utilisez l’interface graphique Ollama, tapez 'ollama run ', en remplaçant par le nom du modèle pour chacun.
  3. Démarrez le service de base de données de graphes. Sélectionnez un service de base de données de graphes parmi un conteneur Docker, une application de bureau ou un service web en ligne. Suivez les instructions d’installation dans les matériaux supplémentaires pour terminer la configuration.
  4. Configurez l’environnement RUGGE. Vérifiez les images Docker téléchargées en tapant docker images. Assurez-vous que toutes les images Docker de l’étape précédente sont répertoriées. Exécutez ces commandes dans le terminal pour télécharger l’image et le code Docker RUGGED :
    docker pull pinglabutils/rugged :latest
    REMARQUE : git clone https://github.com/pinglab-utils/RUGGED
    1. Configurer le service LLM commercial. Si vous utilisez des services LLM commerciaux, assurez-vous que le compte et la clé API associée disposent de fonds suffisants. Modifiez les fichiers de configuration RUGGED en modifiant le fichier de configuration dans 'RUGGED/config/openai_key.txt' et en ajoutant la clé API au fichier.
    2. Configurer les agents commerciaux. Déterminez quels agents LLM du système de RRUGGED utiliseront ce service. Modifiez le fichier de configuration dans 'RUGGED/config/llm_agents.json' et mettez à jour les champs de l’agent pour spécifier la version du modèle. Modèles recommandés : gpt-3.5-turbo, gpt-4o.
    3. Configurer le service LLM local. Si vous utilisez un point de terminaison de service différent de celui par défaut pour Ollama à 'http://localhost:11434', modifiez et mettez à jour le champ 'OLLAMA_URI' dans les fichiers de configuration à 'RUGGED/config/ollama_config.json.
    4. Configurer les agents LLM locaux. Déterminez quels agents LLM du système de RRUGGED utiliseront ce service. Modifiez le fichier de configuration dans 'RUGGED/config/llm_agents.json' et mettez à jour les champs de l’agent pour spécifier 'ollama' comme modèle sélectionné.
    5. Configurez le point de terminaison de la base de données de graphes. Si vous modifiez le mot de passe et le nom d’utilisateur par défaut pour Neo4j, modifiez le fichier de configuration 'RUGGED/config/neo4j_config.json' pour mettre à jour les champs 'uri', 'nom d’utilisateur' et 'mot de passe'.
  5. Démarrez le service RUGGED en exécutant la commande :
    docker run --name rugged -it --net rugged_network --gpus=all -v \RUGGED\ :/data ping-lab-
    utils :RUGGED /bin/bash
    REMARQUE : Pour vérifier que les services fonctionnent comme prévu, accédez au répertoire RUGGED et exécutez les étapes 1.4.1. à l’étape 1.4.4. dans cette fenêtre de terminal.
    1. Vérifiez la fonctionnalité du service LLM. Accédez au dossier test dans le répertoire RUGGED et exécutez les commandes suivantes pour vérifier que les services OpenAI et/ou Ollama fonctionnent :
      python test_openai.py
      python test_ollama.py
    2. Vérifiez la fonctionnalité du service de reconnaissance d’entités nommées. Exécutez test_ner.py pour vérifier que le code de la reconnaissance d’entité nommée des requêtes utilisateur fonctionne correctement.
    3. Vérifiez la fonctionnalité du service Neo4j. Exécutez des scripts de test pour vérifier que le service Neo4j fonctionne comme prévu en tapant 'python test_neo4j.py'
    4. (Facultatif) Vérifiez l’accès HTTP à la base de données de graphes. Ouvrez un navigateur Web et visitez l’interface utilisateur de Neo4j.
      REMARQUE : Pour Neo4j dans Docker ou Desktop, l’URL par défaut est 'http://localhost:7474. Pour Neo4j AuraDB, utilisez le lien fourni lors de l’installation.
  6. (Facultatif) Résoudre les problèmes. Assurez-vous que les services prenant en charge RUGGED sont vérifiés lors de la configuration du logiciel afin d’anticiper les problèmes. Résoudre les problèmes liés aux tests infructueux à partir de l’étape 1.4. S’ils existent, suivez les messages d’erreur signalés par les scripts de test décrivant les problèmes.
    1. Vérifiez les conteneurs Docker. Vérifiez que tous les conteneurs Docker sont en cours d’exécution à l’aide de « docker ps » dans le terminal, y compris le conteneur docker RUGGED, le conteneur docker Neo4j (facultatif) et le conteneur docker Ollama (facultatif).
    2. Vérifiez les ports réseau. Pour les services Docker, assurez-vous que les ports corrects sont ouverts et vérifiez les journaux avec « docker logs neo4j » ou « docker logs ollama ».
      NOTE : Par défaut, Neo4j utilise les ports 7474 pour http et 7687 pour son interface bolt ; Ollama utilise le port 11434.
    3. Vérifiez les applications de service. Pour les applications installées directement sur l’appareil (par exemple, Ollama et Neo4j Desktop), ouvrez les applications pour confirmer qu’elles sont en cours d’exécution.
    4. Vérifiez les services Web. Pour Neo4j AuraDB, connectez-vous au site Web et vérifiez que le service est en cours d’exécution.
    5. Vérifiez les règles de pare-feu. Modifiez les règles de pare-feu de l’appareil pour vous assurer que le pare-feu ne bloque aucun service externe.
    6. Redémarrez l’appareil. Si les problèmes ne sont pas résolus, redémarrez l’appareil et réessayez à partir de l’étape 1.5.1.
    7. Ouvrez un problème. Si les problèmes persistent, veuillez ouvrir un problème sur le GitHub RUGGED (https://github.com/pinglab-utils/RUGGED).

2. Accès aux connaissances biomédicales et à l’information d’extraction

REMARQUE : Ces étapes décrivent deux pipelines d’extraction de connaissances en tant qu’informations sous-jacentes constituant le système de génération augmentée de récupération (RAG) de RUGGED : (1) le pipeline d’exploration de texte biomédical CaseOLAP LIFT5 et (2) le flux de travail de construction du graphe de connaissances Know2BIO9. Pour utiliser RUGGED avec des données personnalisées, passez à l’étape 4.

  1. Extraire de la littérature biomédicale. Identifiez les documents pertinents et les relations protéiques-maladies de haut niveau à l’aide de CaseOLAP LIFT, un protocole informatique conçu pour étudier les protéines subcellulaires et leurs associations avec la maladie par le biais de l’exploration de textes dans la littérature biomédicale. Complétez cette étape pour préparer les informations nécessaires pour informer le flux de travail RAG avec des informations ciblées à partir de ces rapports.
    1. Exécutez l’analyse d’exploration de texte CaseOLAP LIFT. Visitez le protocole CaseOLAP LIFT JoVE (les étapes 4 et 5 ne sont pas nécessaires pour cette analyse).
    2. Déplacer des documents texte traités. Assurez-vous que les documents biomédicaux analysés (pubmed.json) et leur texte intégral (pmid2full_text_sections.json) de l’étape 3 se trouvent dans le dossier de données CaseOLAP LIFT . Déplacez ces fichiers dans le dossier de données RUGGED à l’aide des commandes ci-dessous :
      mv /caseolap_lift/caseolap_lift_shared_folder/data/pubmed.json /RUGGED/data/text_corpus
      mv /caseolap_lift/caseolap_lift_shared_folder/data/ pmid2full_text_sections.json /RUGGED/data/text_corpus
    3. Déplacer les résultats de l’exploration de texte. Vérifiez que le fichier de graphe de connaissances (merged_edge_list.tsv) contenant les associations protéine-maladie a été généré dans le dossier result/kg. Vérifiez que le nombre d’associations est conforme aux attentes, en fonction des paramètres sélectionnés aux étapes 1 à 3 (voir le tableau 2 par exemple). Déplacez ce fichier dans le dossier de données de RUGGED :
      mv /caseolap_lift/caseolap_lift_shared_folder/result/graph_data/ merged_edge_list.tsv /RUGGED/data/knowledge_graph
  2. Extraire des connaissances biomédicales. Assemblez un graphe de connaissances biomédicales à l’aide du logiciel Know2BIO , qui intègre des données provenant de 30 bases de connaissances biomédicales. Effectuez cette étape pour vous assurer que les informations relatives à ces relations biomédicales et aux données multimodales sont traitées pour prendre en charge le flux de travail RAG en aval.
    1. Clonez le dépôt Know2BIO. Clonez le référentiel en tapant dans la ligne de commande, à l’aide de la commande ci-dessous. Accédez au référentiel Know2BIO.
      git clone https://github.com/Yijia-Xiao/Know2BIO.git.
    2. Préparer les données et les licences. Accédez au dossier du jeu de données et suivez les instructions du fichier README.md. Complétez la création nécessaire des comptes utilisateurs pour accéder aux différentes ressources en ligne (ex. : thésaurus UMLS, banque de médicaments).
    3. Téléchargez les ressources de la base de connaissances. Exécutez le script « python create_edge_files.py » et surveillez la progression du pipeline d’extraction du graphe de connaissances. Assurez-vous que le fichier .csv dans le dossier « Know2BIO/dataset/output » représentant les relations biomédicales a été généré.
    4. Construire un graphe de connaissances. Exécutez le script « python prepare_kgs.py » pour intégrer les informations extraites à l’étape précédente afin de combiner automatiquement les relations extraites dans un graphe de connaissances unifié, en formatant le graphique par source de données et par domaine.
    5. Vérifiez le résultat. Vérifiez que les fichiers terminés sont présents dans le fichier 'whole_kg.txt' dans le répertoire 'Know2BIO/dataset/know2bio_dataset. Vérifiez que le nombre d’arêtes dans le fichier est conforme aux attentes ; voir le tableau 3, qui a donné plus de 6 millions d’arêtes. Passez à l’étape suivante, car les autres étapes du fichier README Know2BIO ne sont pas nécessaires pour cette analyse.
      REMARQUE : Les relations de Know2BIO dans le tableau 3 proviennent de 31 sources, y compris ATC (Organisation mondiale de la santé), Bgee45, CTD46, ClinGen47, ClinVar48, DOID49, DisGeNET50, DrugBank51, GRNdb52, Gene Ontology53, HGNC54, Hetionet3, Inxight Drugs55, KEGG56, MeSH57, Mondo58, MyChem.info59 MyDisease.info59, MyGene.info59, OMIM60, PathFX61, PharmGKB62, PubMed, Reactome63, SIDER64, SMPDB65, STRING66, TTD67, UMLS68, Uberon69 et UniProt70.
    6. Déplacer les résultats du graphe de connaissances. Déplacez le fichier dans le répertoire '/data/knowledge_graph/' du répertoire ROGGED.
      mv /Know2BIO/dataset/know2bio/whole_kg.txt /RUGGED/data/knowledge_graph
  3. Construisez un graphe de connaissances combiné. Intégrez le graphique de l’étape précédente avec les relations protéine-maladie de haut niveau de l’exploration de texte de l’étape 2.1 dans un seul graphe de connaissances unifié.
    1. Vérifiez les résultats dans le répertoire ROGGED. Vérifiez que le fichier de résultats de construction du graphe de connaissances (whole_kg.txt) et les résultats de la relation d’exploration de texte (merged_edge_list.tsv) se trouvent dans le répertoire knowledge_graph du dossier data.
    2. Intégrez les résultats. Exécutez un script « combine_kg_results.py » pour fusionner les relations et les entités extraites de l’analyse d’exploration de texte et de la construction du graphe de connaissances en un seul graphe de connaissances cohérent. Suivez l’exemple de commande ci-dessous :
      python robuste/knowledge_graph/combine_kg_results.py ./data/knowledge_graph/merged_edge_list.tsv ./data/knowledge_graph/whole_kg.txt --output_dir ./data/rugged_knowledge_graph
  4. Filtrer le graphe de connaissances. (Facultatif) Échantillonnez un sous-ensemble du graphe de connaissances qui sera utilisé pour l’analyse prédictive. Cette étape ne conserve que les relations étroitement liées et réduit les ressources de calcul nécessaires à l’exécution des prédictions de Deep Learning.
    1. Identifiez les nœuds pertinents. Déterminez les entités biomédicales d’intérêt pour l’analyse prédictive à l’étape 3 en examinant le graphe de connaissances et en identifiant les nœuds pertinents.
      REMARQUE : Ce protocole se concentre sur les ganglions pathologiques de la cardiomyopathie arythmogène (MCA) et de la cardiomyopathie dilatée (CMD), comme MeSH_Disease : D019571 et MeSH_Disease : D002311, respectivement. Les nœuds cibles doivent être adaptés au cas d’utilisation prévu.
    2. Exemple du graphe de connaissances. Utilisez le script 'filter.py' pour extraire le sous-graphe de graphe de connaissances accessible dans k-hop à partir des nœuds d’intérêt sélectionnés. Suivez l’exemple de commande ci-dessous, qui filtre le graphique accessible à moins de 2 nœuds des nœuds de maladie sélectionnés :
      python ./rugged/knowledge_graph/kg_filter.py --k 2 --disease « MeSH_Disease :D019571,MeSH_Disease :D002311 » --input_file ./data/rugged_knowledge_graph/rugged_knowledge_graph_edges.csv —output_dir ./data/rugged_knowledge_graph/filtered_kg/.
      REMARQUE : L’augmentation de la valeur k-hop (--k) élargit la portée des données dans le graphique pour l’analyse de prédiction, mais nécessite également des ressources de calcul plus importantes.

3. Analyse des prédictions explicables

REMARQUE : Exécutez GNNExplainer44 sur un modèle de réseau convolutif de graphe pour prédire les arêtes potentielles (relations) dans le graphe de connaissances et fournir des informations sur des associations jusqu’alors inconnues.

  1. Assurez-vous que le conteneur Docker RUGGED est en cours d’exécution. Si la fenêtre de terminal précédente était fermée, connectez-vous au conteneur Docker avec la commande 'docker exec --it rugged /bin/bash'. Une fois connecté au conteneur Docker, accédez au répertoire RUGGED.
  2. Déterminez le(s) bord(s) à prévoir. Fournissez les arêtes sous forme de paires de nœuds dans un fichier .txt (par exemple, edges_to_predict.txt). Les arêtes déjà existantes dans le graphe de connaissances seront filtrées des prédictions.
  3. Exécutez le script d’analyse de prédiction . Spécifiez les arêtes à prédire et le graphe de connaissances d’entrée en tant qu’arguments de ligne de commande pour la prédiction. Arguments clés : -p (chemin d’accès au fichier d’arêtes), -i (graphe de connaissances d’entrée), -o (répertoire de sortie), -n (principales prédictions, par exemple, 5), -k (principales arêtes à visualiser, par exemple, 10). Exemple de commande :
    python robuste/predictive_analysis/generate_explainable_prediction.py -o sortie -n 5 -k 10 -p ./sortie/edges_to_predict.txt -i ./données/rugged_knowledge_graph/filtered_kg/filtered_k2_edges.csv
  4. Évaluez les performances du modèle. Examinez la sortie du terminal ou le fichier « output.log » généré à partir de l’étape précédente pour évaluer les performances du modèle en divisant le graphe de connaissances filtré en ensembles d’entraînement, de validation et de test avec un rapport de 85:5:10. Ajustez les arguments du modèle si les performances ne sont pas celles attendues, en utilisant le Tableau 4 comme exemple.
  5. Vérifiez que les résultats se trouvent dans le dossier de sortie. Examinez les résultats du modèle dans 'prediction_results.csv' et examinez les n principales prédictions dans le dossier de sortie. Passez en revue les n principales prédictions dans le dossier de sortie. Pour chaque prédiction, une visualisation graphique illustre les arêtes les plus pertinentes contribuant à chaque prédiction et leurs scores d’importance relative.
  6. Déplacez les résultats de l’analyse prédictive. Une fois satisfait des résultats de l’analyse prédictive, déplacez les résultats dans les « données/prédictions/ » du répertoire RUGGED.

4. Génération d’hypothèses

  1. Connectez-vous au conteneur Docker RUGGED.
    1. Assurez-vous que le conteneur Docker RUGGED est en cours d’exécution. Si la fenêtre de terminal précédente était fermée, connectez-vous au conteneur Docker.
    2. Accédez au répertoire ROGGED. Une fois connecté, tapez cd /workspace/RUGGED pour accéder au répertoire. Exécutez les étapes restantes dans cette fenêtre de ligne de commande.
    3. Vérifiez que les services de support sont en cours d’exécution. Si vous utilisez Ollama et Neo4j dans Docker, assurez-vous que les conteneurs fonctionnent en tapant 'docker ps'. Répétez l’étape 1.7 pour vérifier que les services fonctionnent correctement et l’étape 1.4 pour résoudre les problèmes s’ils existent.
  2. Préparez les données RAG. Préparez le graphe de connaissances et le corpus de texte pour la récupération.
    REMARQUE : Ces données peuvent être remplacées par des données définies par l’utilisateur en les plaçant respectivement dans les répertoires « data/knowledge_graph/ » et « data/text_corpus/ ». Ces données doivent suivre le format du référentiel GitHub (https://github.com/pinglab-utils/RUGGED/tree/main/data).
    1. Vérifiez les ressources. Assurez-vous que le corpus de texte se trouve dans le répertoire « data/text_corpus/ », que le graphe de connaissances avec le fichier de prédictions d’exploration de texte se trouve dans le répertoire data/knowledge_graph/ et que les résultats de la prédiction se trouvent dans le répertoire data/predictions/ (à partir des étapes 2.1.2., 2.3.2 et 3.5. respectivement).
    2. Remplissez la base de données de graphes. Exécutez la commande 'python ./neo4j/prepare_neo4j.py' pour créer les nœuds, les arêtes et les fonctionnalités de nœud nécessaires.
    3. Indexez le corpus de textes. Exécutez la commande 'python ./text/prepare_corpus.py' pour indexer le corpus de texte et permettre à RUGGED de récupérer des documents texte pertinents en fonction des requêtes de l’utilisateur en divisant les documents en sections de 500 jetons pour créer une base de données vectorielle à l’aide de BART71.
    4. Facultatif) Testez l’extraction de la base de données de graphes. Envoyez une requête de test à la base de données Neo4j pour vous assurer qu’elle est correctement remplie et qu’elle peut renvoyer les résultats attendus. Vérifiez que la sortie correspond aux noeuds et aux relations attendus dans la base de données. Exemple de commande :
      python ./test/test_neo4j_retrieval.py --query « MATCH (n) RETURN n LIMIT 5 »
    5. (Facultatif) Testez la récupération du corpus RAG. Envoyez une requête de test au corpus de texte RAG pour vous assurer que le système de recherche de texte fonctionne. Vérifiez que les documents récupérés sont pertinents pour la requête et que les plongements fonctionnent comme prévu. Exemple de commande : python ./test/test_literature_retrieval.py --query « Quels documents sont liés à l’utilisation de bêta-bloquants pour traiter les maladies cardiovasculaires ? »
  3. Interagissez avec RUGGED. Démarrez RUGGED dans l’interface de ligne de commande pour interagir avec le système. Exécutez la commande 'python rugged.py'. Interrogez le système pour récupérer des informations pertinentes à l’aide de commandes spécifiques pour interagir avec le graphe de connaissances et le corpus de texte.
    1. Interrogez le graphe de connaissances. Extrayez des informations spécifiques du graphe de connaissances en posant la question en langage naturel, en commençant par le mot-clé « query ». Par exemple:
      « Quels sont les médicaments actuellement prescrits classés comme bêta-bloquants, antiarythmiques et antifibrotiques ? »
    2. Explorez les prédictions. Explorez les analyses de prédiction de liens à partir de l’étape 3 et demandez à rechercher une relation spécifique, en commençant par le mot-clé « prédire ». Par exemple:
      prédire : « Lequel de ces médicaments pourrait potentiellement être utilisé pour traiter l’ACM et/ou le DCM qui n’est pas connu actuellement ? »
    3. Explorez la recherche documentaire. Explorez les documents liés à un sujet biomédical particulier de l’étape 2. Posez la question en langage naturel, en commençant par le mot-clé « rechercher ». Par exemple:
      « Quelles preuves documentaires soutiennent l’affirmation selon laquelle ces médicaments prédits pourraient être utilisés pour traiter l’ACM et/ou la DCM ? »
    4. Itérez et affinez la requête. Répondez directement en ligne de commande pour itérer et affiner les demandes à l’aide de l’interface de type chat de RUGGED. Reportez-vous aux conversations utilisateur-système précédentes pour réviser et affiner les questions et les requêtes.
    5. Relancez les commandes de chiffrement dans Neo4j. (Facultatif) Affinez les résultats de la requête du graphe de connaissances en ajustant la commande Cypher fournie utilisée pour récupérer les informations. Réexécutez ou modifiez cette commande en visitant l’interface du navigateur Neo4j à partir de l’étape 1.4.4 (par exemple, à l’http://localhost:7474). Collez et modifiez les commandes Cypher si nécessaire pour affiner les requêtes et recueillir des informations plus spécifiques.
    6. Résumer la conversation. Passez en revue les informations récupérées et résumez la conversation avec RUGGED. Tapez le mot-clé summarize pour générer un résumé de l’interaction dans un fichier texte en vue d’une analyse ultérieure. La réponse en texte intégral s’affiche dans le terminal.
    7. Effectuez un examen humain dans la boucle pour améliorer la précision du résultat en inspectant et en modifiant les réponses du système pour en vérifier la lisibilité et la brièveté avant de finaliser le résumé.
    8. Consultez les journaux de discussion. Inspectez le texte complet de l’interaction dans le dossier journal de RUGGED. Conservez ces commandes intermédiaires et ces conversations entre les agents LLM au sein de RUGGED pour le dépannage et la reproductibilité.
  4. Arrêt et redémarrage de RUGGED.
    1. Obtenez les ID de conteneur Docker. Utilisez la commande 'docker ps' pour lister tous les conteneurs en cours d’exécution et obtenir les ID de conteneur pour RUGGED, Neo4j et Ollama. Pour toutes les commandes suivantes, remplacez , et par les ID de conteneur réels.
    2. Arrêtez les conteneurs Docker. Arrêtez RUGGED et les conteneurs Docker associés à l’aide de leurs ID de conteneur.
      Docker Stop
      Docker Stop
      Docker Stop
      REMARQUE : Il est recommandé d’arrêter ces conteneurs avant d’éteindre l’appareil pour éviter une perte de données potentielle et s’assurer que tous les processus se ferment correctement.
    3. Redémarrez les conteneurs Docker. Pour redémarrer le système RUGGE, utilisez les ID de conteneur pour démarrer les conteneurs Docker nécessaires.
      Docker Start
      Docker Start
      Docker Start
    4. Rattachez-le au réseau Docker. Si nécessaire, utilisez ces commandes pour rattacher les conteneurs au réseau.
      Connexion réseau Docker rugged_network
      Connexion réseau Docker rugged_network
      Connexion réseau Docker rugged_network
    5. Vérifiez le fonctionnement du service. Au redémarrage, répétez les étapes 1.4 et 1.5 pour vous assurer que le logiciel fonctionne comme prévu.

Results

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Ces résultats représentatifs ont été obtenus en suivant la procédure décrite dans le présent protocole. Une analyse d’association de fouille de texte a été réalisée selon le protocole CaseOLAP LIFT5 avec des paramètres par défaut, en étudiant huit grandes catégories de maladies cardiovasculaires72 et leur association avec les protéines mitochondriales (GO :0005739). Au total, 635 696 rapports jusqu’en mai 2024 ont été jugés pertinents pour ces maladies ; Parmi elles, 4 655 associations protéine-maladie à haut niveau de confiance ont été identifiées pour éclairer les analyses en aval. Un graphe de connaissances biomédicales a été construit à l’aide du code logiciel de Know2BIO en utilisant les paramètres par défaut en mai 20249. Le graphe de connaissances résultant se compose de 219 450 nœuds, 6 323 257 arêtes, ainsi que des caractéristiques de nœud pour 189 493 nœuds avec des descriptions de nœuds, des séquences de protéines/gènes, une structure chimique, etc. le cas échéant. Une estimation du temps de calcul pour toutes les étapes du protocole est présentée dans le tableau 1.

Le système RUGGED a été initialisé en construisant les bases de données vectorielles pour les nœuds et les caractéristiques du graphe de connaissances, ainsi que pour les publications pertinentes en matière de CVD. Tous les nœuds, arêtes et caractéristiques de nœud du graphe de connaissances ont été traités avec une taille de bloc de 20 jetons avec le modèle d’intégration BART71 pour préparer la recherche vectorielle RAG. De même, les contributions originales et les articles de synthèse ont été traités à l’aide d’un bloc de 500 jetons et du modèle d’intégration BART pour se préparer à la recherche vectorielle RAG. Pour la recherche documentaire, les publications en texte intégral de plus de 500 jetons ont été résumées hiérarchiquement en fonction des sections individuelles d’une publication par le modèle d’intégration BART. Le modèle GPT-4o a été utilisé pour les autres agents LLM du système.

Ces résultats représentatifs présentent un exemple de cas d’utilisation pour étudier des traitements médicamenteux potentiels pour la cardiomyopathie arythmogène (MCA) et la cardiomyopathie dilatée (CMD), identifiées respectivement comme MeSH_Disease : D019571 et MeSH_Disease : D002311. La figure 3 présente une série de demandes de renseignements, avec des exemples de réponses modèles illustrés à la figure 4 et la réponse complète présentée dans le fichier supplémentaire 1, section A. L’orientation de l’enquête a été adaptée aux réponses validées par l’enquêteur, en élaborant des requêtes ultérieures basées sur les résultats des réponses précédentes. L’analyse a révélé 11 candidats médicaments classés sous bêta-bloquants et antiarythmiques. De nouvelles avenues de traitement thérapeutique ont été évaluées à l’aide d’un modèle de prédiction de lien de réseau neuronal convolutif sur un sous-ensemble du graphe de connaissances complet, y compris les nœuds à 1 bond des nœuds de la maladie et du médicament à l’étude et leurs interconnexions, les paramètres d’évaluation étant présentés dans le tableau 4. Les 10 principales arêtes pertinentes pour chaque prédiction du modèle ont été examinées plus en détail par un module d’explicabilité de graphe, GNNExplainer44, afin d’identifier les nœuds et les arêtes supérieurs contribuant à chaque prédiction, respectivement. Le coût total de l’utilisation de LLM commercial pour toutes les étapes du protocole RUGGED pour ce cas d’utilisation est estimé à 1,50 $ au moment de la rédaction.

figure-results-1
Figure 1 : Récupération dans le cadre du flux de travail RUGGED (Graph-guided Explainable disease Distinction). RUGGED se compose de quatre composants principaux : (1) assembler et traiter des données à partir de ressources provenant de sources éthiques et gérées par des professionnels (par exemple, PubMed et des bases de connaissances biomédicales organisées), (2) intégrer les résultats de recherches évaluées par des pairs dans un graphe de connaissances unifié, (3) structurer les données textuelles et graphiques dans les services de base de données, (4) modéliser et prédire les relations explicables entre les entités biomédicales dans le graphe de connaissances, et (5) la récupération et la synthèse des connaissances par le biais d’un flux de travail de génération augmentée (RAG) (Figure 2) pour valider des relations moléculaires complexes et explorer les prédictions de maladies basées sur l’IA. Une étape de révision humaine peut être effectuée par l’utilisateur pour améliorer la précision du résultat. Veuillez cliquer ici pour voir une version agrandie de cette figure.

figure-results-2
Figure 2 : Architecture de recherche et flux de travail d’atténuation des biais. Le cadre RAG (Retrieval Augmented Generation) utilise plusieurs agents LLM, chacun exécutant des tâches spécifiques pour prendre en charge l’accès aux informations pertinentes en fonction de la requête de l’utilisateur. Ce système fournit des preuves documentées de l’agent de raisonnement basé sur GPT destiné à l’utilisateur, facilitant l’interaction utilisateur-agent et la synthèse des connaissances. (1) Récupération de textes biomédicaux : Les contributions originales évaluées par des pairs et les articles de synthèse sont filtrés en fonction de leur pertinence pour comprendre les associations de maladies. Une base de données vectorielle est construite pour les preuves textuelles validées par l’auteur et l’éditeur, pondérées en fonction de la section correspondante de la publication, respectivement : 70 % de résumé, 10 % de résultats, 10 % de métadonnées et 10 % pour toutes les autres sous-sections. Une recherche par mot-clé et une recherche de similarité par rapport à l’intégration de texte de la requête de l’utilisateur permettent d’identifier ensemble les documents pertinents. Les résumés de chaque document sont générés à l’aide d’un résumateur basé sur BERT, l’agent d’évaluation de texte basé sur GPT affinant la recherche pour valider la pertinence du document de requête. (2) Récupération du graphe de connaissances : un module de reconnaissance d’entités nommées et d’extraction de relations basé sur BERT connecte la requête de l’utilisateur aux entités pertinentes dans le graphe de connaissances. Une recherche de similarité dans une base de données vectorielle identifie les nœuds et les arêtes pertinents. Les données sont extraites de la base de données Neo4j via des requêtes Cypher générées par l’agent de requête Cypher basé sur GPT et affinées par l’agent de vérification des requêtes. (3) Les réponses individuelles des pipelines Biomedical Text Retrieval ou Knowledge Graph Retrieval sont présentées à l’agent de raisonnement, qui synthétise une réponse concise avec un biais minimal par rapport à la requête de l’utilisateur. Ce système est guidé de manière à maintenir l’exactitude et l’impartialité dans la présentation d’informations factuelles. Veuillez cliquer ici pour voir une version agrandie de cette figure.

figure-results-3
Figure 3 : Cas d’utilisation de la synthèse de connaissances et de l’exploration d’hypothèses via unecascade de requêtes tierces. Cette figure présente un cas d’utilisation mis en évidence en se concentrant sur une chaîne de questions et de concepts connexes qu’un investigateur et/ou un professionnel de la santé pourraient poser au système RUGGE. Les requêtes de l’utilisateur sont présentées au système dans l’ordre numérique, avec des flèches représentant le raisonnement logique déduit et le raisonnement spécifique au domaine entre chaque question. Le système récupère à partir de l’information implicite et pertinente (source indiquée en bleu), en répondant à la requête. Des exemples de réponses du système sont présentés à la figure 4. Veuillez cliquer ici pour voir une version agrandie de cette figure.

figure-results-4
Figure 4 : Cas d’utilisation de la pathologie cardiovasculaire : élucidation de la pathogenèse des MCV. Les paires requête-réponse entre l’utilisateur et le système RUGGED sont affichées. Dans le panneau supérieur gauche, les questions 1 à 6 récupèrent des informations en extrayant des informations de la base de données du graphe de connaissances pour formuler des réponses fondées sur des preuves. La question 7 utilise une prédiction de lien graphique explicable pour identifier les traitements les mieux notés. La requête déclenche une analyse de prédiction, qui est exécutée et traitée automatiquement par le système, et les résultats clés sont résumés succinctement. La question 8 évalue les preuves documentaires du corpus de données textuelles défini qui sont récupérées en tant que preuves pertinentes pour vérifier, valider et corroborer la constatation prédite. Les réponses du système ont été examinées par un processus d’inspection humain et modifiées pour plus de lisibilité et de brièveté. Une transcription complète de ces résultats est détaillée dans le Dossier supplémentaire 1. Veuillez cliquer ici pour voir une version agrandie de cette figure.

EscalierDescriptionHeure
Accès aux connaissances biomédicales30 % au total
Préparer un corpus de littérature biomédicaleConnectez-vous à PubMed et PubMed Central, téléchargez et analysez les données de publication pour les tâches en aval.20%
Préparer les données de la base de connaissancesConnectez-vous aux bases de connaissances biomédicales, téléchargez et analysez les informations nécessaires aux tâches en aval.5%
Extraction d’informations30 % au total
CaseOLAP LIFT Analyse de l’exploration de texteIdentifier les relations maladie-protéine de haut niveau dans le corpus de textes biomédicaux.25%
Construction de graphes de connaissancesConnectez et intégrez des informations disparates provenant de bases de connaissances biomédicales dans un graphe de connaissances unifié.5%
Analyse des prédictions10 % au total
Réseau neuronal de graphe d’entraînementEntraînez le modèle sur les données du graphe de connaissances biomédicales pour apprendre des modèles cachés dans le graphe.5%
Analyse du classement par pertinenceAppliquez le module d’explicabilité pour mettre en évidence les nœuds et les arêtes les plus pertinents pour étudier la maladie.2.5%
Prédiction de lienUtilisez le module d’explicabilité pour identifier les nœuds et les arêtes clés contribuant aux nouvelles arêtes prédites.2.5%
Génération et/ou validation d’hypothèses30 % au total
Configuration de la base de données pour la génération augmentée d’extractionInitialisez la base de données de graphes pour l’interrogation du graphe de connaissances et la base de données vectorielle pour la recherche de texte.25%
Exploration des hypothèsesPermettez à l’utilisateur d’interagir avec RUGGED pour accéder et examiner les informations pertinentes pour l’exploration d’hypothèses.5%

Tableau 1 : étapes de limitation du flux de travail et du débit Ce tableau fournit des estimations approximatives du temps de calcul requis pour chaque étape du flux de travail. Les étapes de limitation du débit comprennent l’accès, l’extraction et l’indexation des connaissances biomédicales nécessaires à la génération augmentée par récupération. L’exploration des hypothèses peut être répétée en continu sans qu’il soit nécessaire de réexécuter les étapes de limitation de débit.

Catégorie de maladieNuméros d’arbres MeSH# PMID# Contributions originales# Articles de revue
Cardiomyopathies (MC)Réf. C14.280.238132,531102,33719,942
Réf. C14.280.434
Arythmies cardiaques (ARR)Réf. C14.280.067125,28692,37413,854
Réf. C23.550.073
Cardiopathies congénitales (CHD)Réf. C14.280.40082,00654,0236,379
Maladies des valves cardiaques (VD)Réf. C14.280.48472,01650,1195,743
Ischémie myocardique (IHD)Réf. C14.280.647256,986210,04230,223
Maladie de la conduction cardiaque (CCD)Réf. C14.280.12353,05035,3994,363
Obstruction de l’écoulement ventriculaire (VOO)Réf. C14.280.95522,24415,5041,686
Autres maladies cardiaques (OTH)C14.280.195 C14.280.282 C14.280.383 C14.280.470 C14.280.945 C14.280.459 C14.280.720114,08577,30211,799
Total635,696478,40469,690

Tableau 2 : Statistiques de la littérature biomédicale. Ce tableau détaille les catégories de maladies de l’étude avec leurs numéros d’arbre MeSH correspondants et le nombre de documents PubMed récupérés jusqu’en mai 2024, utilisés comme corpus pour l’exploration de texte. Un sous-ensemble de ces publications, composé d’articles de recherche originaux et d’articles de synthèse, est indexé dans une base de données vectorielle pour être récupéré par RUGGED lors de la génération d’hypothèses.

CatégorieNombre de nœudsNombre d’arêtesSource(s) de données
Anatomie5,049122,533Bgee, PubMed, MeSH, Uberon, 
Processus biologique27,047108,106Ontologie génétique
Composant cellulaire4,05752,238Ontologie génétique
Composé27,2783,292,028DrugBank, MeSH, CTD, UMLS, KEGG, TTD, SIDER, Inxight Drugs, Hetionet, PathFX, MyChem.info
Maladie21,938311,773PubMed, MeSH, DisGeNET, SIDER, ClinVar, ClinGen, PharmGKB, MyDisease.info, PathFX, UMLS, OMIM, Mondo, DOID, KEGG
Classe de médicament5,7218,283ATC
Gène29,810943,419HGNC, GRNdb, KEGG, ClinVar, ClinGen,
Fonction moléculaire11,15147,086SMPDB, DisGENET, PharmGKB, MyGene.info
Voie52,012234,944Ontologie génétique
Protéine20,7401,074,809Réactome, KEGG, SMPDB
Réaction14,647128,038UniProt, Reactome, TTD, SMPDB, STRING, HGNC
Sous-total219,4506,323,257Réactome
Associations de fouille de texte84,670
Total219,4586,327,927

Tableau 3 : Statistiques du graphe de connaissances. Ce tableau détaille 11 grandes catégories biomédicales composant le graphe de connaissances Know2BIO construit, enrichi d’arêtes supplémentaires dérivées de l’analyse de fouille de texte et de l’analyse prédictive. Le graphe de connaissances et les prédictions qui en résultent sont gérés par la base de données de graphes Neo4j pour être récupérés par RUGGED lors de la génération d’hypothèses.

ExactitudePrécisionRappelerScore F1AUROCAUPRC
Validation0.71580.66390.87430.75470.84370.8637
Test0.7030.63670.94550.7610.89610.9094

Tableau 4 : Évaluation du modèle d’IA explicable. Ce tableau présente les métriques d’évaluation de la prédiction de lien de graphe de connaissances à l’aide d’un réseau neuronal convolutif à deux couches. Les métriques ont été évaluées en partitionnant les bords du graphe en 85 % d’entraînement, 5 % de validation et 10 % d’ensembles de données de test. La précision indique la proportion de prédictions correctement classées. La précision indique la proportion de prédictions positives correctes parmi toutes les prédictions positives. Le rappel mesure la proportion de prédictions positives correctes parmi les bords positifs réels. Le score F1 est la moyenne harmonique de la précision et de la mémorisation, équilibrant les deux métriques. AUROC évalue la capacité du modèle à différencier les prédictions positives et négatives. L’AUPRC quantifie le compromis entre la précision et le rappel à travers différents seuils. Avec toutes les métriques, des valeurs plus élevées indiquent de meilleures performances du modèle.

Dossier supplémentaire 1 : Ce fichier détaille la réponse complète du modèle de RUGGED et une comparaison avec GPT-4o. La section A présente l’ensemble de l’interaction homme-machine avec RUGGED, en développant l’approche de la chaîne d’interrogation décrite à la figure 3 et en fournissant la réponse complète au-delà du résumé mis en évidence à la figure 4. La section B évalue les réponses de GPT-4o sans récupération par rapport à celles de RUGGED, en évaluant des attributs tels que la précision, la profondeur, le score de confiance, la fiabilité des preuves et le coût. Veuillez cliquer ici pour télécharger ce fichier.

Discussion

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Le protocole RUGGED s’appuie sur des modèles de langage modernes avec des informations à jour pour permettre aux chercheurs d’explorer de manière dynamique le paysage biomédical en évolution et de découvrir de nouvelles connaissances. Cette interaction homme-machine propulse un processus innovant qui illustre l’efficacité de la machine (RUGGED) et l’expertise et le jugement de l’enquêteur. Ce protocole est conçu pour être exécuté dans l’ordre décrit. L’étape 1 détaille l’installation du logiciel. Les étapes 2 et 3 sont essentielles pour la préparation de la littérature et des ressources biomédicales, tandis que l’étape 4 indexe ces informations pour la génération augmentée de la récupération et l’interaction de l’utilisateur avec le système LLM. Les étapes chronophages peuvent s’exécuter simultanément et/ou séquentiellement. Par exemple, la création du graphe Neo4j (étape 4.2.2) peut commencer lors de l’analyse de prédiction (étape 3), et l’indexation peut commencer après la construction du graphe de connaissances (étape 2.3) et l’exploration de texte (étape 2.1). Ces étapes doivent être répétées pour obtenir le résultat final de ces résultats intermédiaires. Bien qu’il soit conçu pour la recherche d’informations biomédicales, ce protocole, avec des modifications mineures, peut également traiter d’autres données textuelles et graphiques, telles que des données internes, des notes cliniques ou des dossiers de santé électroniques. Les détails du formatage des données se trouvent à l’étape 4.2.

Le fonctionnement de cette plateforme repose sur la bonne installation et l’interconnexion de plusieurs technologies, notamment les modèles de langage, les bases de données de graphes et les bases de données vectorielles (voir Table des matériaux). Pour vérifier que ces services sont correctement installés et connectés, des scripts de test sont fournis dans le dossier « test » du référentiel GitHub. Les services externes peuvent entraîner des frais, dont les prix sont susceptibles d’être modifiés par le vendeur. Ces services optionnels ont également des alternatives hébergées localement, ne nécessitant que des ressources de calcul suffisantes. Cependant, ces alternatives peuvent avoir un impact sur les performances et/ou la commodité du modèle, ce qui les rend inadaptées à certains scénarios d’utilisation.

Avec l’évolution rapide du paysage LLM, de nouveaux modèles de référence et des modèles spécifiques à des tâches sont publiés régulièrement. Au moment de la rédaction de ce rapport, les modèles les plus appropriés ont été choisis pour la tâche. Les utilisateurs peuvent choisir le LLM à utiliser en mettant à jour le fichier de configuration en conséquence (voir les étapes 1.3.2-1.3.4). La sélection des modèles dépend de leur pertinence par rapport à un cas d’utilisation particulier. Par exemple, l’intégration de modèles visant à garantir que les réponses des modèles sont équitables, censurées et exemptes de discours de haine 73,74,75,76,77,78 dans ce flux de travail est essentielle pour les considérations éthiques. De plus, une ingénierie rapide est essentielle pour guider un comportement fiable et responsable du LLM 79,80,81,82. Les invites conçues pour le flux de travail RUGGED sont adaptées aux modèles utilisés et présentent des cas d’utilisation. Pour affiner les invites pour un autre cas d’utilisation, les utilisateurs peuvent modifier les invites dans le flux de travail RUGGED dans le dossier « configuration » du fichier « prompts.json ».

Bien que les systèmes RAG visent à réduire les hallucinations dans les LLM en fondant les réponses sur des preuves, ces modèles peuvent toujours conduire à des informations inexactes ou à des réponses généralement vraies et non spécifiques. Une comparaison comparative comparative de RUGGED par rapport à GPT-4o est fournie dans le fichier supplémentaire 1, section B. Les hallucinations du modèle se produisent souvent lorsque les informations récupérées dépassent la fenêtre contextuelle du modèle, analogue à la démence avec perte de mémoire et incapacité à localiser le contenu des données, entraînant des réponses inexactes 83,84,85. Le choix d’un modèle LLM approprié permet d’atténuer ce problème. Par exemple, GPT-4o a une limite contextuelle de 128k jetons, nettement plus que la limite de 16k jetons de GPT-3.5 Turbo, bien qu’à un coût plus élevé pour l’utilisateur. De plus, les LLM affinés avec une connaissance spécifique du domaine peuvent potentiellement améliorer la précision et la spécificité des réponses dans les applications biomédicales 86,87,88. Malgré ces mesures, il est essentiel de recouper les informations avant de procéder à des expériences coûteuses en laboratoire humide.

RUGGED exploite l’IA explicable au sein d’un pipeline RAG pour examiner les prédictions de liens, en identifiant les relations fiables et non découvertes auparavant. Alors que les systèmes RAG traditionnels reposent sur une récupération basée sur la similarité en vrac, cette approche associe l’explicabilité à une augmentation ciblée de la réponse. Le tableau 4 met en évidence les solides performances du modèle, démontrant un rappel élevé (validation : 0,975, test : 0,976) et des scores F1 équilibrés (validation : 0,796, test : 0,797), indiquant la fiabilité dans l’identification des vrais positifs, bien qu’avec un taux plus élevé de faux positifs. La robustesse du modèle est également renforcée par ses valeurs AUROC (validation : 0,963, test : 0,964) et AUPRC (validation : 0,971, test : 0,972). La précision (validation : 0,673, test : 0,674), cependant, pourrait bénéficier d’un réglage de seuil, d’incorporer des fonctionnalités de nœud détaillées ou d’une meilleure gestion du déséquilibre de classe. L’efficacité du modèle dépend fortement du graphe de connaissances d’entrée ; Le surajustement est un risque avec des graphiques plus petits, tandis que les graphiques plus grands exigent des ressources de calcul plus importantes. Cependant, toute approche basée sur le RAG dépend fortement de la qualité des données sous-jacentes à l’extraction. Par exemple, la construction d’un graphe de connaissances demande souvent beaucoup de temps et de main-d’œuvre en raison du bruit intrinsèque sur le graphique d’origine. Cela nécessite un effort manuel de débruitage et d’étiquetage, ainsi que des coûts permanents de maintenance et de mise à jour des bases de données.

RUGGED est principalement utilisé dans la synthèse des connaissances et l’exploration d’hypothèses. En étudiant diverses relations cachées, telles que les mécanismes de la maladie et les traitements médicamenteux, RUGGED effectue efficacement le triage de la littérature. Pour réduire la charge de calcul, la plupart des applications peuvent être hébergées sur un serveur (par exemple, AWS ou serveur de calcul) et configurées pour être mises à jour périodiquement avec les dernières informations. De plus, ce flux de travail peut être adapté pour réaliser des applications spécifiques à un domaine, par exemple en servant de plate-forme pour inclure les données des patients avec des modèles locaux afin de préserver la sécurité, la confidentialité et la confidentialité. Au-delà de la recherche biomédicale, la conception modulaire de RRUGGED lui permet de prendre en charge des tâches de recherche, d’inférence et de synthèse d’informations en personnalisant le pipeline RAG et en proposant des stratégies d’ingénierie adaptées au domaine cible. Une adaptation réussie nécessite un examen minutieux des défis spécifiques à un domaine, tels que le prétraitement de divers formats de données et l’évaluation des modèles appropriés aux besoins spécifiques à la tâche et au domaine.

Disclosures

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Les auteurs n’ont rien à divulguer.

Acknowledgements

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Les auteurs tiennent à remercier le Dr Alex Bui pour ses conseils et sa discussion réfléchie. De plus, nous remercions le Dr Ding Wang pour ses discussions utiles. Ce travail a été soutenu en partie par NIH 1U54HG012517-01 à P.P., K.W. et W.W. ; NIH T32 HL13945 à A.R.P. ; le stage de recherche de la National Science Foundation (NRT) 1829071 à A.R.P. ; et la dotation TC Laubisch à P.P. à UCLA.

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
Matériel/Logiciel - Carte graphique et pilote logicielNvidiahttps://www.nvidia.comUne carte graphique et son pilote associé sont fortement recommandés pour réduire considérablement le temps d’exécution des tâches nécessitant des calculs intensifs, telles que les analyses LLM locales et prédictives. Pour les appareils équipés d’un GPU NVIDIA RTX, téléchargez et installez les pilotes nécessaires et CUDA Toolkit à partir du site Web de NVIDIA (https://developer.nvidia.com/cuda-downloads).
OpenAIhttps://openai.comRUGGED prend en charge l’API OpenAI pour des modèles tels que GPT-3.5 et GPT-4o. Pour configurer à l’aide de modèles OpenAI, obtenez d’abord une clé API OpenAI. Rendez-vous sur le site Web d’OpenAI (https://openai.com/blog/openai-api) pour créer un compte, charger des fonds et obtenir une clé API. Cette clé API est nécessaire pour permettre à RUGGED d’utiliser les modèles OpenAI. Déterminez quels agents LLM au sein du système de RRUGGED utiliseront les modèles OpenAI à partir de leur documentation (https://platform.openai.com/docs/models).
REMARQUE : L’API OpenAI est un service payant. Au moment de la publication, le coût de GPT-4o est de 5,00 $ par million de jetons d’entrée et de 2,50 $ par 1 million de jetons de sortie (pour en savoir plus, visitez https://openai.com/pricing).
Dockerhttps://www.docker.comDocker aide à maintenir un environnement d’exécution de calcul cohérent, en rationalisant l’installation et l’exécution des logiciels sur différentes machines. Pour installer Docker, rendez-vous sur le site Web de Docker (https://www.docker.com/), cliquez sur 'Démarrer', téléchargez et installez la version appropriée pour le système d’exploitation. Vérifiez l’installation en tapant 'docker --version' dans le terminal ; l’installation réussie signale la version de Docker installée.
Logiciel - Base de données de graphesNeo4jhttps://neo4j.comNeo4j est un logiciel de base de données de graphes qui gère et interroge efficacement les nœuds et les relations basés sur des graphes. RUGGED prend en charge Neo4j sous plusieurs formes : conteneur Docker, Neo4j Desktop ou serveur en ligne Neo4j AuraDB. Choisissez l’option la mieux adaptée au cas d’utilisation.
Configuration de Neo4j en tant que conteneur Docker. Exécutez ces commandes pour configurer Neo4j dans Docker, avec le chemin d’accès au fichier du dossier (par exemple, /Users/username/RUGGED) comme 'PATH_TO_FOLDER'. Pour plus de détails sur le dépannage, reportez-vous au site Web Neo4j Docker (https://hub.docker.com/_/neo4j).
docker pull neo4j
docker run &ndash ; nom neo4j --net rugged_network --publish=7474:7474 --publish=7687:7687 -d -v 'PATH_TO_FOLDER'\neo4j\data :/data neo4j
REMARQUE : Initialisez Neo4j dans Docker pour la première fois en définissant un nom d’utilisateur et un mot de passe. Exécutez le script neo4j_setup.py (par exemple, python neo4j_setup.py) ou via l’interface web à l’adresse http://localhost:7474.
Configuration de Neo4j Desktop. Si vous utilisez Neo4j Desktop, téléchargez et installez à partir du site Web de Neo4j (https://neo4j.com/). Créez un nouveau projet en cliquant sur « Nouveau », puis cliquez sur « Ajouter » pour créer un nouveau système de gestion de base de données (SGBD). Sélectionnez « SGBD local », définissez un mot de passe, cliquez sur « Créer », puis cliquez sur « Démarrer ». Un texte vert « ACTIVE » indique qu’il est en cours d’exécution.
Configuration de Neo4j AuraDB. Rendez-vous sur le site de Neo4j à l’adresse (https://neo4j.com/cloud/aura-free/) pour créer un compte et vous connecter. Sélectionnez « Nouvelle instance » pour créer une instance vide et enregistrez l’URI et le mot de passe initial pour accéder à l’interface bolt (par exemple, bolt://myurl.neo4j.com). Cliquez sur le bouton de lecture pour démarrer l’instance, qui affichera l’URI de connexion dans la boîte d’information.
REMARQUE : Neo4j AuraDB offre un niveau gratuit jusqu’à 200 000 nœuds et 400 000 relations. Pour des graphiques plus grands, consultez les tarifs de Neo4j (https://neo4j.com/pricing).
Logiciel - Local Large Language Model ServiceOllamahttps://ollama.comRUGGED prend en charge l’utilisation de modèles locaux à l’aide d’Ollama (par exemple, Llama3). Pour l’activer, installez d’abord Ollama sur l’appareil ou téléchargez le conteneur Docker. Pour installer Ollama, rendez-vous sur le site Web d’Ollama (https://ollama.com/download) et suivez les instructions d’installation. Pour installer Ollama sur Docker, exécutez la commande suivante :
docker pull ollama/ollama
REMARQUE : Au moment de la publication, il n’existe pas de version stable pour Ollama sur le système d’exploitation Windows.
Logiciel - Contrôle de versionGithttps://www.git-scm.comLe logiciel de contrôle de version permet une installation et une mise à jour efficaces du logiciel. Pour installer Git, rendez-vous sur le site Web de Git (https://www.git-scm.com/), cliquez sur 'Téléchargements', téléchargez et installez la version appropriée pour le système d’exploitation. Vérifiez l’installation en tapant 'git --version' dans le terminal ; une installation réussie signalera la version de Git installée.

References

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  1. Bioinformatics in translational drug discovery. Biosci Rep. 37 (4), BSR20160180(2017).">Wooller, S. K., Benstead-Hume, G., Chen, X., Ali, Y., Pearl, F. M. G. Bioinformatics in translational drug discovery. Biosci Rep. 37 (4), BSR20160180(2017).
  2. Computational approaches streamlining drug discovery. Nature. 616 (7958), 673-685 (2023).">Sadybekov, A. V., Katritch, V. Computational approaches streamlining drug discovery. Nature. 616 (7958), 673-685 (2023).
  3. Systematic integration of biomedical knowledge prioritizes drugs for repurposing. eLife. 6, e26726(2017).">Himmelstein, D. S., et al. Systematic integration of biomedical knowledge prioritizes drugs for repurposing. eLife. 6, e26726(2017).
  4. Text mining and expert curation to develop a database on psychiatric diseases and their genes. Database (Oxford). 2017, bax043(2017).">Gutiérrez-Sacristán, A., et al. Text mining and expert curation to develop a database on psychiatric diseases and their genes. Database (Oxford). 2017, bax043(2017).
  5. A knowledge graph approach to elucidate the role of organellar pathways in disease via biomedical reports. J Vis Exp. (200), e65084(2023).">Pelletier, A. R., et al. A knowledge graph approach to elucidate the role of organellar pathways in disease via biomedical reports. J Vis Exp. (200), e65084(2023).
  6. A knowledge graph to interpret clinical proteomics data. Nat Biotechnol. 40 (5), 692-702 (2022).">Santos, A., et al. A knowledge graph to interpret clinical proteomics data. Nat Biotechnol. 40 (5), 692-702 (2022).
  7. PharmKG: A dedicated knowledge graph benchmark for bomedical data mining. Briefings in Bioinformatics. 22 (4), bbaa344(2021).">Zheng, S., et al. PharmKG: A dedicated knowledge graph benchmark for bomedical data mining. Briefings in Bioinformatics. 22 (4), bbaa344(2021).
  8. Biomedical knowledge graph-optimized prompt generation for large language models. Bioinformatics. 40 (9), btae560(2023).">Soman, K., et al. Biomedical knowledge graph-optimized prompt generation for large language models. Bioinformatics. 40 (9), btae560(2023).
  9. ArXiv. , (2023).">Xiao, Y., et al. Know2BIO: A comprehensive dual-view benchmark for evolving biomedical knowledge graphs. ArXiv. , (2023).
  10. Large language models in medicine. Nat Med. 29 (8), 1930-1940 (2023).">Thirunavukarasu, A. J., et al. Large language models in medicine. Nat Med. 29 (8), 1930-1940 (2023).
  11. ArXiv. , (2023).">Lehman, E., et al. Do we still need clinical language models. ArXiv. , (2023).
  12. Large language models encode clinical knowledge. Nature. 620, 172-180 (2022).">Singhal, K., et al. Large language models encode clinical knowledge. Nature. 620, 172-180 (2022).
  13. ArXiv. , (2022).">Agrawal, M., Hegselmann, S., Lang, H., Kim, Y., Sontag, D. Large language models are few-shot clinical information extractors. ArXiv. , (2022).
  14. Assessing the accuracy and reliability of AI-generated medical responses: An evaluation of the Chat-GPT model. Res Sq. , (2023).">Johnson, D., et al. Assessing the accuracy and reliability of AI-generated medical responses: An evaluation of the Chat-GPT model. Res Sq. , (2023).
  15. Evaluation of ChatGPT on biomedical tasks: A zero-shot comparison with fine-tuned generative transformers. Jahan, I., Laskar, M. T. R., Peng, C., Huang, J. The 22nd Workshop on Biomedical Natural Language Processing and BioNLP Shared Tasks, , 326-336 (2023).
  16. Assessing the accuracy of responses by the language model ChatGPT to questions regarding bariatric surgery. Obes Surg. 33 (6), 1790-1796 (2023).">Samaan, J. S., et al. Assessing the accuracy of responses by the language model ChatGPT to questions regarding bariatric surgery. Obes Surg. 33 (6), 1790-1796 (2023).
  17. Trialling a large language model (ChatGPT) in general practice with the applied knowledge test: observational study demonstrating opportunities and limitations in primary care. JMIR Med Educ. 9, e46599(2023).">Thirunavukarasu, A. J., et al. Trialling a large language model (ChatGPT) in general practice with the applied knowledge test: observational study demonstrating opportunities and limitations in primary care. JMIR Med Educ. 9, e46599(2023).
  18. ArXiv. , (2023).">Sun, W., et al. Is ChatGPT Good at search? Investigating large language models as re-ranking agents. ArXiv. , (2023).
  19. ArXiv. , (2023).">Xu, R., Feng, Y., Chen, H. ChatGPT vs. Google: A comparative study of search performance and user experience. ArXiv. , (2023).
  20. TruthfulQA: Measuring how models mimic human falsehoods. Lin, S., Hilton, J., Evans, O. Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers, , 3214-3252 (2022).
  21. ArXiv. , (2023).">Manakul, P., Liusie, A., Gales, M. J. F. SelfCheckGPT: Zero-resource black-box hallucination detection for generative large language models. ArXiv. , (2023).
  22. FActScore: Fine-grained atomic evaluation of factual precision in long form text generation. Min, S., et al. Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, , 12076-12100 (2023).
  23. Is ChatGPT fair for recommendation? Evaluating fairness in large language model recommendation. Proceedings of the 17th ACM Conference on Recommender Systems. , 993-999 (2023).">Zhang, J., et al. Is ChatGPT fair for recommendation? Evaluating fairness in large language model recommendation. Proceedings of the 17th ACM Conference on Recommender Systems. , 993-999 (2023).
  24. Building an ethical and trustworthy biomedical AI ecosystem for the translational and clinical integration of foundation models. Bioengineering. 11 (10), 984(2024).">Sankar, B. S., et al. Building an ethical and trustworthy biomedical AI ecosystem for the translational and clinical integration of foundation models. Bioengineering. 11 (10), 984(2024).
  25. ChatGPT and Other large language models are double-edged swords. Radiology. 307 (2), e230163(2023).">Shen, Y., et al. ChatGPT and Other large language models are double-edged swords. Radiology. 307 (2), e230163(2023).
  26. Ethics of large language models in medicine and medical research. Lancet Digit Health. 5 (6), e333-e335 (2023).">Li, H., et al. Ethics of large language models in medicine and medical research. Lancet Digit Health. 5 (6), e333-e335 (2023).
  27. ArXiv. , (2020).">Lewis, P., et al. Retrieval-augmented generation for knowledge-intensive NLP tasks. ArXiv. , (2020).
  28. ArXiv. , (2023).">Gao, Y., et al. Retrieval-augmented generation for large language models: A survey. ArXiv. , (2023).
  29. PubTator central: Automated concept annotation for biomedical full text articles. Nucleic Acids Res. 47 (W1), W587-W593 (2019).">Wei, C. -H., Allot, A., Leaman, R., Lu, Z. PubTator central: Automated concept annotation for biomedical full text articles. Nucleic Acids Res. 47 (W1), W587-W593 (2019).
  30. ArXiv. , (2024).">Wei, C. -H., et al. PubTator 3.0: An AI-powered literature resource for unlocking biomedical knowledge. ArXiv. , (2024).
  31. Comparative Reasoning for knowledge graph fact checking. Liu, L., Ji, H., Xu, J., Tong, H. 2022 IEEE International Conference on Big Data (Big Data), , 2309-2312 (2022).
  32. Knowledge Graph reasoning and its applications. Liu, L., Tong, H. Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, , 5813-5814 (2023).
  33. ArXiv. , (2024).">Liu, L., et al. Logic query of thoughts: Guiding large language models to answer complex logic queries with knowledge graphs. ArXiv. , (2024).
  34. Barack's wife hillary: Using Knowledge graphs for fact-aware language modeling. Logan, R., Liu, N. F., Peters, M. E., Gardner, M., Singh, S. Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics, , 5962-5971 (2019).
  35. ArXiv. , (2024).">Sun, J., et al. Think-on-graph: Deep and responsible reasoning of large language model on knowledge graph. ArXiv. , (2024).
  36. ArXiv. , (2024).">Wen, Y., Wang, Z., Sun, J. MindMap: Knowledge Graph prompting sparks graph of thoughts in large language models. ArXiv. , (2024).
  37. ArXiv. , (2020).">Wang, C., Liu, X., Song, D. Language models are open knowledge graphs. ArXiv. , (2020).
  38. QA-GNN: Reasoning with Language Models and Knowledge Graphs for Question Answering. Yasunaga, M., Ren, H., Bosselut, A., Liang, P., Leskovec, J. Proceedings of the 2021 Conference of the North American Chapter of the, , 535-546 (2021).
  39. SimKGC: Simple contrastive knowledge graph completion with pre-trained language models. Wang, L., Zhao, W., Wei, Z., Liu, J. Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers, , 4281-4294 (2022).
  40. FLAIRS. 36, (2023).">Lazar, A. Graph neural networks for link prediction. FLAIRS. 36, (2023).
  41. ArXiv. , (2018).">Zhang, M., Chen, Y. Link prediction based on graph neural networks. ArXiv. , (2018).
  42. XGNN: Towards model-level explanations of graph neural networks. Yuan, H., Tang, J., Hu, X., Ji, S. Proceedings of the 26th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, , (2020).
  43. CFGExplainer: Explaining graph neural network-based malware classification from control flow graphs. Herath, J. D., Wakodikar, P., Yang, P., Yan, G. 2022 52nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), , 172-184 (2022).
  44. GNNExplainer: Generating explanations for graph neural networks. Adv Neural Inf Process Syst. 32, 9240-9251 (2019).">Ying, R., Bourgeois, D., You, J., Zitnik, M., Leskovec, J. GNNExplainer: Generating explanations for graph neural networks. Adv Neural Inf Process Syst. 32, 9240-9251 (2019).
  45. The Bgee suite: Integrated curated expression atlas and comparative transcriptomics in animals. Nucleic Acids Res. 49 (D1), D831-D847 (2021).">Bastian, F. B., et al. The Bgee suite: Integrated curated expression atlas and comparative transcriptomics in animals. Nucleic Acids Res. 49 (D1), D831-D847 (2021).
  46. Comparative Toxicogenomics Database (CTD): Update 2023. Nucleic Acids Res. 51 (D1), D1257-D1262 (2023).">Davis, A. P., et al. Comparative Toxicogenomics Database (CTD): Update 2023. Nucleic Acids Res. 51 (D1), D1257-D1262 (2023).
  47. ClinGen - The clinical genome resource. N Engl J Med. 372 (23), 2235-2242 (2015).">Rehm, H. L., et al. ClinGen - The clinical genome resource. N Engl J Med. 372 (23), 2235-2242 (2015).
  48. ClinVar: Improvements to accessing data. Nucleic Acids Res. 48 (D1), D835-D844 (2020).">Landrum, M. J., et al. ClinVar: Improvements to accessing data. Nucleic Acids Res. 48 (D1), D835-D844 (2020).
  49. The human disease ontology 2022 update. Nucleic Acids Res. 50 (D1), D1255-D1261 (2022).">Schriml, L. M., et al. The human disease ontology 2022 update. Nucleic Acids Res. 50 (D1), D1255-D1261 (2022).
  50. The DisGeNET cytoscape app: Exploring and visualizing disease genomics data. Comput Struct Biotechnol J. 19, 2960-2967 (2021).">Piñero, J., Saüch, J., Sanz, F., Furlong, L. I. The DisGeNET cytoscape app: Exploring and visualizing disease genomics data. Comput Struct Biotechnol J. 19, 2960-2967 (2021).
  51. DrugBank 6.0: The DrugBank knowledgebase for 2024. Nucleic Acids Res. 52 (D1), D1265-D1275 (2024).">Knox, C., et al. DrugBank 6.0: The DrugBank knowledgebase for 2024. Nucleic Acids Res. 52 (D1), D1265-D1275 (2024).
  52. GRNdb: Decoding the gene regulatory networks in diverse human and mouse conditions. Nucleic Acids Res. 49 (D1), D97-D103 (2021).">Fang, L., et al. GRNdb: Decoding the gene regulatory networks in diverse human and mouse conditions. Nucleic Acids Res. 49 (D1), D97-D103 (2021).
  53. The Gene Ontology resource: enriching a GOld mine. Nucleic Acids Res. 49 (D1), D325-D334 (2021).">Gene Ontology Consortium. The Gene Ontology resource: enriching a GOld mine. Nucleic Acids Res. 49 (D1), D325-D334 (2021).
  54. Genenames.org: The HGNC resources in 2023. Nucleic Acids Res. 51 (D1), D1003-D1009 (2023).">Seal, R. L., et al. Genenames.org: The HGNC resources in 2023. Nucleic Acids Res. 51 (D1), D1003-D1009 (2023).
  55. NCATS Inxight Drugs: A comprehensive and curated portal for translational research. Nucleic Acids Res. 50 (D1), D1307-D1316 (2022).">Siramshetty, V. B., et al. NCATS Inxight Drugs: A comprehensive and curated portal for translational research. Nucleic Acids Res. 50 (D1), D1307-D1316 (2022).
  56. KEGG: New perspectives on genomes, pathways, diseases and drugs. Nucleic Acids Res. 45 (D1), D353-D361 (2017).">Kanehisa, M., Furumichi, M., Tanabe, M., Sato, Y., Morishima, K. KEGG: New perspectives on genomes, pathways, diseases and drugs. Nucleic Acids Res. 45 (D1), D353-D361 (2017).
  57. Medical Subject Headings (MeSH). Bull Med Libr Assoc. 88 (3), 265-266 (2000).">Lipscomb, C. E. Medical Subject Headings (MeSH). Bull Med Libr Assoc. 88 (3), 265-266 (2000).
  58. medRxiv. , (2022).">Vasilevsky, N. A., et al. Mondo: Unifying diseases for the world, by the world. medRxiv. , (2022).
  59. BioThings SDK: A toolkit for building high-performance data APIs in biomedical research. Bioinformatics. 38 (7), 2077-2079 (2022).">Lelong, S., et al. BioThings SDK: A toolkit for building high-performance data APIs in biomedical research. Bioinformatics. 38 (7), 2077-2079 (2022).
  60. OMIM.org: Leveraging knowledge across phenotype-gene relationships. Nucleic Acids Res. 47 (D1), D1038-D1043 (2019).">Amberger, J. S., Bocchini, C. A., Scott, A. F., Hamosh, A. OMIM.org: Leveraging knowledge across phenotype-gene relationships. Nucleic Acids Res. 47 (D1), D1038-D1043 (2019).
  61. PathFX provides mechanistic insights into drug efficacy and safety for regulatory review and therapeutic development. PLoS Comput Biol. 14 (12), e1006614(2018).">Wilson, J. L., et al. PathFX provides mechanistic insights into drug efficacy and safety for regulatory review and therapeutic development. PLoS Comput Biol. 14 (12), e1006614(2018).
  62. PharmGKB, an Integrated resource of pharmacogenomic knowledge. Curr Protoc. 1 (8), e226(2021).">Gong, L., Whirl-Carrillo, M., Klein, T. E. PharmGKB, an Integrated resource of pharmacogenomic knowledge. Curr Protoc. 1 (8), e226(2021).
  63. The reactome pathway knowledgebase 2022. Nucleic Acids Res. 50 (D1), D687-D692 (2022).">Gillespie, M., et al. The reactome pathway knowledgebase 2022. Nucleic Acids Res. 50 (D1), D687-D692 (2022).
  64. The SIDER database of drugs and side effects. Nucleic Acids Res. 44 (D1), D1075-D1079 (2016).">Kuhn, M., Letunic, I., Jensen, L. J., Bork, P. The SIDER database of drugs and side effects. Nucleic Acids Res. 44 (D1), D1075-D1079 (2016).
  65. SMPDB 2.0: Big improvements to the small molecule pathway database. Nucleic Acids Res. 42 (Database issue), D478-D484 (2014).">Jewison, T., et al. SMPDB 2.0: Big improvements to the small molecule pathway database. Nucleic Acids Res. 42 (Database issue), D478-D484 (2014).
  66. STRING v11: Protein-protein association networks with increased coverage, supporting functional discovery in genome-wide experimental datasets. Nucleic Acids Res. 47 (D1), D607-D613 (2019).">Szklarczyk, D., et al. STRING v11: Protein-protein association networks with increased coverage, supporting functional discovery in genome-wide experimental datasets. Nucleic Acids Res. 47 (D1), D607-D613 (2019).
  67. Therapeutic target database update 2022: Facilitating drug discovery with enriched comparative data of targeted agents. Nucleic Acids Res. 50 (D1), D1398-D1407 (2022).">Zhou, Y., et al. Therapeutic target database update 2022: Facilitating drug discovery with enriched comparative data of targeted agents. Nucleic Acids Res. 50 (D1), D1398-D1407 (2022).
  68. The Unified Medical Language System (UMLS): Integrating biomedical terminology. Nucleic Acids Res. 32 (Database issue), D267-D270 (2004).">Bodenreider, O. The Unified Medical Language System (UMLS): Integrating biomedical terminology. Nucleic Acids Res. 32 (Database issue), D267-D270 (2004).
  69. Unification of multi-species vertebrate anatomy ontologies for comparative biology in Uberon. J Biomed Semantics. 5, 21(2014).">Haendel, M. A., et al. Unification of multi-species vertebrate anatomy ontologies for comparative biology in Uberon. J Biomed Semantics. 5, 21(2014).
  70. UniProt: the Universal Protein Knowledgebase in 2023. Nucleic Acids Res. 51 (D1), D523-D531 (2023).">UniProt Consortium. UniProt: the Universal Protein Knowledgebase in 2023. Nucleic Acids Res. 51 (D1), D523-D531 (2023).
  71. Denoising sequence-to-sequence pre-training for natural language generation, translation, and comprehension. Lewis, M., et al. Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics, , 7871-7880 (2020).
  72. Cloud-based phrase mining and analysis of user-defined phrase-category association in biomedical publications. J Vis Exp. (144), e59108(2019).">Sigdel, D., et al. Cloud-based phrase mining and analysis of user-defined phrase-category association in biomedical publications. J Vis Exp. (144), e59108(2019).
  73. FM. ArXiv. , (2023).">Ferrara, E. Should ChatGPT be biased? Challenges and risks of bias in large language models. FM. ArXiv. , (2023).
  74. ArXiv. , (2023).">Gallegos, I. O., et al. Bias and fairness in large language models: A Survey. ArXiv. , (2023).
  75. Fighting reviewer fatigue or amplifying bias? Considerations and recommendations for use of ChatGPT and other large language models in scholarly peer review. Res Integr Peer Rev. 8 (1), 4(2023).">Hosseini, M., Horbach, S. P. J. M. Fighting reviewer fatigue or amplifying bias? Considerations and recommendations for use of ChatGPT and other large language models in scholarly peer review. Res Integr Peer Rev. 8 (1), 4(2023).
  76. Kotek, H., Dockum, R., Sun, D. Gender bias and stereotypes in Large Language Models. Proceedings of The ACM Collective Intelligence Conference, , 12-24 (2023).
  77. Prompting techniques for reducing social bias in LLMs through System 1 and System 2 Cognitive Processes. ArXiv. , (2024).">Kamruzzaman, M., Kim, G. L. Prompting techniques for reducing social bias in LLMs through System 1 and System 2 Cognitive Processes. ArXiv. , (2024).
  78. ArXiv. , (2024).">Raza, S., Raval, A., Chatrath, V. MBIAS: Mitigating bias in large language models while retaining context. ArXiv. , (2024).
  79. ArXiv. , (2023).">Chen, B., Zhang, Z., Langrené, N., Zhu, S. Unleashing the potential of prompt engineering in Large Language Models: A comprehensive review. ArXiv. , (2023).
  80. ArXiv. , (2023).">White, J., et al. A prompt pattern catalog to enhance prompt engineering with ChatGPT. ArXiv. , (2023).
  81. Prompt engineering as an important emerging skill for medical professionals: Tutorial. J Med Internet Res. 25, e50638(2023).">Meskó, B. Prompt engineering as an important emerging skill for medical professionals: Tutorial. J Med Internet Res. 25, e50638(2023).
  82. ArXiv. , (2023).">Wang, J., et al. Prompt Engineering for Healthcare: Methodologies and applications. ArXiv. , (2023).
  83. ArXiv. , (2023).">Luo, Y., et al. An empirical study of catastrophic forgetting in large language models during continual fine-tuning. ArXiv. , (2023).
  84. Retrieval meets Long Context Large Language Models. ArXiv. , (2023).">Xu, P., et al. Retrieval meets Long Context Large Language Models. ArXiv. , (2023).
  85. ArXiv. , (2023).">Chen, S., Wong, S., Chen, L., Tian, Y. Extending context window of Large Language Models via positional interpolation. ArXiv. , (2023).
  86. ArXiv. , (2024).">Labrak, Y., et al. BioMistral: A collection of open-source pretrained large language models for medical domains. ArXiv. , (2024).
  87. BioGPT: Generative pre-trained transformer for biomedical text generation and mining. Brief Bioinform. 23 (6), bbac409(2022).">Luo, R., et al. BioGPT: Generative pre-trained transformer for biomedical text generation and mining. Brief Bioinform. 23 (6), bbac409(2022).
  88. ArXiv. , (2024).">Wang, C., et al. A survey for large language models in biomedicine. ArXiv. , (2024).

Reprints and Permissions

Request permission to reuse the text or figures of this JoVE article

Request Permission

Tags

Biomedical Knowledge BasesExplainable AIKnowledge GraphRetrieval Augmented GenerationLarge Language ModelsText Mining AnalysisHypothesis ValidationDrug Disease RelationshipsAgentic SystemsCardiomyopathy Therapeutics

Related Articles