Method Article

Síntese de conhecimento baseada em evidências e validação de hipóteses: navegando em bases de conhecimento biomédico por meio de IA explicável e sistemas agenciais

DOI:

10.3791/67525

June 13th, 2025

In This Article

Summary

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

Este artigo descreve o RUGGED (Retrieval Under Graph-Guided Explainable disease Distinction), que integra a inferência do Large Language Model (LLM) com a Retrieval-Augmented Generation (RAG). Ele extrai evidências de bases de conhecimento biomédico com curadoria de especialistas e publicações biomédicas revisadas por pares para sintetizar novos conhecimentos a partir de informações atualizadas, identificar previsões explicáveis e acionáveis e identificar direções promissoras para investigações baseadas em hipóteses.

Abstract

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

A escala do conhecimento biomédico, abrangendo literatura científica e bases de conhecimento selecionadas, representa um desafio significativo para os investigadores no processamento, avaliação e interpretação eficaz dos resultados. Grandes Modelos de Linguagem (LLMs) surgiram como ferramentas poderosas para navegar neste complexo cenário de conhecimento, mas podem produzir respostas alucinatórias. A Geração Aumentada por Recuperação (RAG) é essencial para identificar informações relevantes para aumentar a precisão e a confiabilidade. Este protocolo apresenta o RUGGED (Retrieval Under Graph-Guided Explainable disease Distinction), um fluxo de trabalho abrangente projetado para apoiar a integração do conhecimento, mitigar o viés e explorar e validar novas direções de pesquisa. As informações biomédicas de publicações e bases de conhecimento são sintetizadas e analisadas por meio de análise de associação de mineração de texto e modelos de previsão de gráficos explicáveis para descobrir possíveis relações entre drogas e doenças. Essas descobertas, juntamente com o corpus do texto de origem e as bases de conhecimento, são incorporadas a uma estrutura que emprega LLMs aprimorados por RAG para permitir que os usuários explorem hipóteses e investiguem mecanismos subjacentes. Um caso de uso clínico demonstra a capacidade do RUGGED em avaliar e recomendar terapêuticas para cardiomiopatia arritmogênica (ACM) e cardiomiopatia dilatada (DCM), analisando medicamentos prescritos para interações moleculares e novas aplicações potenciais. A plataforma reduz as alucinações de LLM, destaca insights acionáveis e agiliza a investigação de novas terapêuticas.

Introduction

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

O processo de exploração de hipóteses no empreendimento biomédico é essencial para descobrir novas interdependências molécula-medicamento-doença subjacentes à patogênese e desbloquear o potencial terapêutico 1,2. Esse processo extrai evidências do conhecimento biomédico existente, sintetizando novas descobertas com base em pistas lógicas incorporadas à literatura revisada por pares (por exemplo, relatórios >36 do PubMed) e integrando evidências com curadoria de alta confiança enraizadas em bases de conhecimento biomédico. Avanços recentes reduzem o esforço manual trabalhoso aplicando mineração de texto na literatura corpra 3,4,5, bem como empregando análises baseadas em gráficos 6,7,8,9 para sintetizar informações relevantes e descobrir novos caminhos para investigação. Apesar desses esforços, as abordagens atuais muitas vezes não suportam uma compreensão contextual profunda devido a dados fragmentados. Além disso, eles não têm a capacidade de fazer inferências baseadas em evidências e explorar interativamente novas hipóteses.

Desenvolvimentos recentes em Large Language Models (LLMs) lançam uma nova luz sobre esses desafios, demonstrando compreensão contextual de alto nível por meio do treinamento em grandes quantidades de informações em várias disciplinas 10,11,12. No domínio biomédico, os LLMs mostraram um papel promissor na extração de informações do paciente13 e resposta a perguntas clínicas gerais14,15, enquanto as aplicações em respostas a perguntas específicas de domínio16 e utilidades na atenção clínica primária17 ainda precisam ser exploradas. Esses modelos exibem a capacidade de raciocinar e fazer inferências de conjuntos de dados complexos, tornando-os potencialmente adequados para a realização de exploração de hipóteses e síntese de conhecimento. Além disso, alguns modelos apresentam interação semelhante a um bate-papo para envolver os usuários e permitir a exploração dinâmica de tópicos, ultrapassando os limites convencionais dos mecanismos de pesquisa baseados em consulta e bases de conhecimento18,19.

Além desses potenciais, os LLMs enfrentam desafios significativos, como possível alucinação de informações, exibindo confiança injustificada em explicações potencialmente imprecisas, falta de interpretabilidade e sendo suscetíveis a conteúdo tendencioso ou impróprio 20,21,22,23,24 . Aplicadas diretamente para orientar a tomada de decisões clínicas, as respostas e previsões derivadas do LLM têm altos riscos; quaisquer erros podem resultar em experimentos laboratoriais dispendiosos ou afetar negativamente as trajetórias de saúde do paciente25,26. Assim, respostas confiáveis e confiáveis do LLM são primordiais, pois seus conselhos devem estar firmemente enraizados em evidências. Nesses cenários, a interpretabilidade não é um luxo, mas uma necessidade para entender por que esses modelos fazem as previsões que fazem.

Para esse fim, a Geração Aumentada por Recuperação (RAG) é um sistema projetado para minimizar as alucinações do LLM, fundamentando as respostas do LLM em evidências para aumentar sua precisão e confiabilidade27,28. Essa abordagem normalmente envolve a recuperação de passagens de texto relevantes, como a integração de um LLM (por exemplo, ChatGPT) com o PubMed, permitindo a identificação de citações relevantes para consultas de usuários29,30. Não se limitando ao texto, a recuperação em Gráficos de Conhecimento (KGs) mostra-se promissora na aplicação a LLMs para tarefas como verificação de fatos 31,32,33, raciocínio transparente 34,35,36, codificação de conhecimento37, melhoria da resposta a perguntas38 e conclusão de gráficos de conhecimento39. Ao codificar informações factuais de fontes verificadas, os KGs aumentam a precisão, transparência e confiabilidade das respostas do LLM. As técnicas de previsão de links nesses gráficos aproveitam o aprendizado profundo para identificar relações anteriormente ocultas entre moléculas, medicamentos e doenças 5,40,41. Avanços recentes nas previsões explicáveis de IA aumentam ainda mais a transparência e a interpretabilidade dessas tarefas de previsão de links, dando suporte potencial para interpretar hipóteses biomédicas como um caminho viável para investigação 42,43,44. Esses avanços garantem que as respostas geradas pelo LLM sejam equilibradas e extraídas das evidências, aumentando significativamente sua aplicabilidade no empreendimento biomédico.

Este protocolo apresenta o RUGGED (Retrieval Under Graph-Guided Explainable disease Distinction) como um fluxo de trabalho acessível e eficiente para a exploração e validação de insights terapêuticos clínicos (Figura 1). Este protocolo de fluxo de trabalho aproveita os vastos recursos da literatura biomédica e bases de conhecimento para a extração e validação de informações relevantes, permitindo processos de recuperação personalizados para consultas (Figura 2). Um modelo de previsão de inteligência artificial explicável é empregado para descobrir insights interpretáveis e acionáveis do conhecimento biomédico existente, aumentando assim a transparência e a utilidade dos modelos preditivos. O fluxo de trabalho concluído simplifica a exploração de gráficos de conhecimento e previsões de modelos por meio de LLMs habilitados para RAG, facilitando interações intuitivas e informadas para investigadores, médicos e profissionais clínicos.

Esta seção estabelece as bases para o protocolo, com as etapas para implementar essa abordagem descritas na seção a seguir. Em seguida, um caso de uso clínico translacional é apresentado para demonstrar essa abordagem, aplicada à avaliação de medicamentos para interações moleculares, bem como estratégias terapêuticas para medicina cardiovascular. Por fim, são discutidas as implicações e a discussão desse protocolo.

Protocol

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

Este protocolo foi desenvolvido em Python 3.10 e implementado como um contêiner Docker no Windows. Os comandos fornecidos são baseados no ambiente Unix dentro do contêiner do Docker. O software está disponível em https://github.com/pinglab-utils/RUGGED. A Tabela 1 apresenta uma estimativa do tempo computacional para todas as etapas do protocolo.

1. Instalando o software

  1. Instale o software de pré-requisito seguindo as instruções na Tabela de Materiais.
    NOTA: Este protocolo requer controle de versão, conteinerização, um banco de dados gráfico e serviços LLM (large language model). O controle de versão e a conteinerização são opcionais, mas podem simplificar o processo de configuração; banco de dados gráfico e serviços LLM podem ser substituídos por ferramentas semelhantes se o usuário for tecnicamente proficiente.
    1. Configure a rede entre contêineres. Configure os contêineres do Docker para serem conectados a outros serviços no dispositivo (por exemplo, outros contêineres do Docker). Digite o seguinte comando no terminal: docker network create rugged_network
  2. Configure serviços de LLMs (Large Language Models). Escolha o serviço LLM apropriado para o caso de uso, entre serviços LLM comerciais ou serviços de um modelo local em execução no dispositivo do usuário. Certifique-se de que um mínimo de um serviço LLM seja especificado, embora os agentes possam ser combinados e combinados para aproveitar diferentes modelos.
    1. Inicie o serviço LLM local. Se estiver usando o Ollama usando uma interface gráfica do usuário (GUI), execute o executável da GUI (por exemplo, ollama.exe). Se estiver usando o Docker, execute: 'docker run -name ollama --net rugged_network d -v ollama:/root/.ollama -p 11434:11434 ollama/ollama'. Se estiver usando o Docker com aceleração de GPU, certifique-se de que o driver da GPU esteja instalado e execute: 'docker run -name ollama --net rugged_network -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama'.
    2. Inicialize o modelo LLM local. Determine qual modelo usar entre os modelos suportados (por exemplo, Recomendado: llama3, mistral, mixtral. Se estiver usando o Docker, digite 'docker exec run ollama run ' na linha de comando; se estiver usando a GUI do Ollama, digite 'ollama run ', substituindo pelo nome do modelo para cada um.
  3. Inicie o serviço de Banco de Dados do Graph. Selecione um serviço de banco de dados gráfico entre o contêiner do Docker, o aplicativo da área de trabalho ou o serviço Web online. Siga as instruções de instalação nos Materiais Suplementares para concluir a configuração.
  4. Configure o ambiente RUGGED. Verifique as imagens do Docker baixadas digitando docker images. Certifique-se de que todas as imagens do Docker da etapa anterior estejam listadas. Execute estes comandos no terminal para baixar a imagem e o código do RUGGED Docker:
    docker pull pinglabutils / rugged: mais recente
    NOTA: git clone https://github.com/pinglab-utils/RUGGED
    1. Configure o serviço LLM comercial. Se estiver usando serviços comerciais de LLM, certifique-se de que a conta e a chave de API associada tenham fundos suficientes. Modifique os arquivos de configuração RUGGED editando o arquivo de configuração em 'RUGGED/config/openai_key.txt' e adicionando a chave de API ao arquivo.
    2. Configure agentes comerciais. Determine quais agentes LLM dentro do sistema da RUGGED usarão este serviço. Modifique o arquivo de configuração em 'RUGGED/config/llm_agents.json' e atualize os campos do agente para especificar a versão do modelo. Modelos recomendados: gpt-3.5-turbo, gpt-4o.
    3. Configure o serviço LLM local. Se estiver usando um ponto de extremidade de serviço diferente do ponto de extremidade padrão para Ollama em 'http://localhost:11434', modifique e atualize o campo 'OLLAMA_URI' nos arquivos de configuração em 'RUGGED/config/ollama_config.json'.
    4. Configure agentes LLM locais. Determine quais agentes LLM dentro do sistema da RUGGED usarão este serviço. Modifique o arquivo de configuração em 'RUGGED/config/llm_agents.json' e atualize os campos do agente para especificar 'ollama' como o modelo selecionado.
    5. Configure o ponto de extremidade do banco de dados gráfico. Se modificado a partir da senha e nome de usuário padrão do Neo4j, edite o arquivo de configuração 'RUGGED/config/neo4j_config.json' para atualizar os campos 'uri', 'nome de usuário' e 'senha'.
  5. Inicie o serviço RUGGED executando o comando:
    docker run --name rugged -it --net rugged_network --gpus=all -v \RUGGED\:/data ping-lab-
    utilitários:RUGGED /bin/bash
    NOTA: Para verificar se os serviços estão funcionando conforme o esperado, navegue até o diretório RUGGED e execute as etapas 1.4.1. através da etapa 1.4.4. nesta janela do terminal.
    1. Verifique a funcionalidade do serviço LLM. Navegue até a pasta de teste no diretório RUGGED e execute os seguintes comandos para verificar se os serviços OpenAI e/ou Ollama estão funcionando:
      test_openai.py python
      test_ollama.py python
    2. Verifique a funcionalidade do serviço de reconhecimento de entidade nomeada. Execute 'test_ner.py' para verificar se o código para o Reconhecimento de Entidade Nomeada de consultas de usuário está funcionando corretamente.
    3. Verifique a funcionalidade do serviço Neo4j. Execute scripts de teste para verificar se o serviço Neo4j está funcionando conforme o esperado digitando 'python test_neo4j.py'
    4. (Opcional) Verifique o acesso HTTP ao banco de dados gráfico. Abra um navegador da Web e visite a interface de usuário do Neo4j.
      NOTA: Para Neo4j no Docker ou Desktop, o URL padrão é 'http://localhost:7474'. Para Neo4j AuraDB, use o link fornecido durante a configuração.
  6. (Opcional) Solucione problemas. Certifique-se de que os serviços que suportam o RUGGED sejam verificados durante a configuração do software para antecipar problemas. Solucione problemas de testes malsucedidos da etapa 1.4. Se existirem, siga as mensagens de erro relatadas pelos scripts de teste que descrevem os problemas.
    1. Verifique os contêineres do Docker. Confirme se todos os contêineres do Docker estão em execução usando 'docker ps' no terminal, incluindo o contêiner do docker RUGGED, o contêiner do docker Neo4j (opcional) e o contêiner do docker Ollama (opcional).
    2. Verifique as portas de rede. Para serviços do Docker, certifique-se de que as portas corretas estejam abertas e verifique os logs com 'docker logs neo4j' ou 'docker logs ollama'.
      NOTA: Por padrão, o Neo4j usa as portas 7474 para http e 7687 para sua interface bolt; Ollama usa a porta 11434.
    3. Verifique os aplicativos de serviço. Para aplicativos instalados diretamente no dispositivo (por exemplo, Ollama e Neo4j Desktop), abra os aplicativos para confirmar se estão em execução.
    4. Verifique os serviços da Web. Para o Neo4j AuraDB, faça login no site e verifique se o serviço está em execução.
    5. Verifique as regras de firewall. Modifique as regras de firewall do dispositivo para garantir que o firewall não esteja bloqueando nenhum serviço externo.
    6. Reinicie o dispositivo. Se os problemas não forem resolvidos, reinicie o dispositivo e tente novamente a partir da etapa 1.5.1.
    7. Abra um problema. Se os problemas persistirem, abra um problema no RUGGED GitHub (https://github.com/pinglab-utils/RUGGED).

2. Acesso ao conhecimento biomédico e informações de extração

NOTA: Essas etapas descrevem dois pipelines de extração de conhecimento como as informações subjacentes que constituem o sistema de Geração Aumentada de Recuperação (RAG) do RUGGED: (1) o pipeline de mineração de texto biomédico CaseOLAP LIFT5 e (2) o fluxo de trabalho de construção do gráfico de conhecimento Know2BIO9. Para usar o RUGGED com dados personalizados, vá para a etapa 4.

  1. Extraia a literatura biomédica. Identifique documentos relevantes e relações proteína-doença de alto nível usando o CaseOLAP LIFT, um protocolo computacional projetado para investigar proteínas subcelulares e suas associações com doenças por meio da mineração de texto da literatura biomédica. Conclua esta etapa para preparar as informações necessárias para informar o fluxo de trabalho RAG com insights direcionados desses relatórios.
    1. Execute a análise de mineração de texto CaseOLAP LIFT. Visite o Protocolo CaseOLAP LIFT JoVE (as etapas 4-5 não são necessárias para esta análise).
    2. Mova documentos de texto processados. Certifique-se de que os documentos biomédicos analisados (pubmed.json) e seu texto completo (pmid2full_text_sections.json) da etapa 3 estejam na pasta de dados CaseOLAP LIFT . Mova esses arquivos para a pasta de dados RUGGED usando os comandos abaixo:
      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. Mova os resultados da mineração de texto. Verifique se o arquivo do gráfico de conhecimento (merged_edge_list.tsv) com associações proteína-doença foi gerado na pasta result/kg. Verifique se o número de associações é o esperado, dependendo das configurações selecionadas nas etapas 1 a 3 (consulte a Tabela 2 , por exemplo). Mova este arquivo para a pasta de dados do RUGGED:
      mv /caseolap_lift/caseolap_lift_shared_folder/result/graph_data/ merged_edge_list.tsv /RUGGED/data/knowledge_graph
  2. Extraia conhecimento biomédico. Monte um gráfico de conhecimento biomédico usando o software Know2BIO , que integra dados de 30 bases de conhecimento biomédicas. Conclua esta etapa para garantir que as informações dessas relações biomédicas e dados multimodais sejam processadas para dar suporte ao fluxo de trabalho RAG downstream.
    1. Clone o repositório Know2BIO. Clone o repositório digitando na linha de comando, usando o comando abaixo. Navegue até o repositório Know2BIO.
      git clone https://github.com/Yijia-Xiao/Know2BIO.git.
    2. Preparar dados e licenças. Navegue até a pasta do conjunto de dados e siga as instruções no arquivo 'README.md'. Conclua a criação necessária de contas de usuário para acessar vários recursos online (por exemplo, dicionário de sinônimos UMLS, Banco de Medicamentos).
    3. Baixe os recursos da base de conhecimento. Execute o script 'python create_edge_files.py' e monitore o progresso do pipeline de extração do gráfico de conhecimento. Certifique-se de que o arquivo .csv na pasta 'Know2BIO/dataset/output' que representa as relações biomédicas foi gerado.
    4. Construa o gráfico de conhecimento. Execute o script 'python prepare_kgs.py' para integrar as informações extraídas na etapa anterior para combinar automaticamente os relacionamentos extraídos em um gráfico de conhecimento unificado, formatando o gráfico por fonte de dados e domínio.
    5. Verifique a saída. Verifique se os arquivos concluídos estão presentes no arquivo 'whole_kg.txt' no diretório 'Know2BIO/dataset/know2bio_dataset'. Confirme se o número de bordas no arquivo é o esperado; consulte a Tabela 3, que resultou em mais de 6 milhões de bordas. Prossiga para a etapa seguinte, pois as etapas restantes no README do Know2BIO não são necessárias para esta análise.
      NOTA: As relações do Know2BIO na Tabela 3 foram fontes de 31 fontes, incluindo ATC (Organização Mundial da Saúde), 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 e UniProt70.
    6. Mover os resultados do gráfico de conhecimento. Mova o arquivo para o '/data/knowledge_graph/' do diretório RUGGED.
      mv /Know2BIO/dataset/know2bio/whole_kg.txt /RUGGED/data/knowledge_graph
  3. Construa um gráfico de conhecimento combinado. Integre o gráfico da etapa anterior com as relações proteína-doença de alto nível da mineração de texto da etapa 2.1 em um único gráfico de conhecimento unificado.
    1. Verifique os resultados no diretório RUGGED. Verifique se o arquivo de resultados de construção do gráfico de conhecimento (whole_kg.txt) e os resultados da relação de mineração de texto (merged_edge_list.tsv) estão no diretório knowledge_graph dentro da pasta de dados.
    2. Integre os resultados. Execute o script 'combine_kg_results.py' para mesclar os relacionamentos e entidades extraídos da análise de mineração de texto e da construção do gráfico de conhecimento em um único gráfico de conhecimento coeso. Siga o comando de exemplo abaixo:
      python robusto/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. Filtre o gráfico de conhecimento. (Opcional) Faça uma amostra de um subconjunto do gráfico de conhecimento que será usado para a análise preditiva. Essa etapa retém apenas relacionamentos intimamente relacionados e reduz os recursos computacionais necessários para executar as previsões de aprendizado profundo.
    1. Identifique os nós relevantes. Determine as entidades biomédicas de interesse para a análise preditiva na etapa 3, revisando o gráfico de conhecimento e identificando os nós relevantes.
      NOTA: Este protocolo se concentra nos linfonodos da doença para Cardiomiopatia Arritmogênica (ACM) e Cardiomiopatia Dilatada (DCM), conforme MeSH_Disease: D019571 e MeSH_Disease: D002311, respectivamente. Os nós de destino precisam ser adaptados ao caso de uso pretendido.
    2. Exemplo do gráfico de conhecimento. Use o script 'filter.py' para extrair o subgrafo do gráfico de conhecimento alcançável dentro do k-hop dos nós de interesse selecionados. Siga o comando de exemplo abaixo, que filtra o gráfico alcançável em 2 nós dos nós da doença selecionados:
      python ./rugged/knowledge_graph/kg_filter.py --k 2 --doença "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/.
      NOTA: Aumentar o valor k-hop (--k) expande o escopo dos dados dentro do gráfico para análise de previsão, mas também exige maiores recursos computacionais.

3. Análise de previsão explicável

NOTA: Execute GNNExplainer44 em um modelo de rede convolucional de grafo para prever possíveis arestas (relacionamentos) no gráfico de conhecimento e fornecer insights sobre associações anteriormente desconhecidas.

  1. Certifique-se de que o contêiner RUGGED Docker esteja em execução. Se a janela do terminal anterior foi fechada, conecte-se ao contêiner do Docker com o comando 'docker exec --it rugged /bin/bash'. Uma vez conectado ao contêiner do Docker, navegue até o diretório RUGGED.
  2. Determine a(s) borda(s) a prever. Forneça as arestas como pares de nós em um arquivo .txt (por exemplo, edges_to_predict.txt). As bordas já existentes no gráfico de conhecimento serão filtradas das previsões.
  3. Execute o script de análise de previsão . Especifique as bordas a serem previstas e o gráfico de conhecimento de entrada como argumentos de linha de comando para a previsão. Argumentos-chave: -p (caminho para o arquivo de bordas), -i (gráfico de conhecimento de entrada), -o (diretório de saída), -n (principais previsões, por exemplo, 5), -k (bordas superiores a serem visualizadas, por exemplo, 10). Exemplo de comando:
    python robusto/predictive_analysis/generate_explainable_prediction.py -o saída -n 5 -k 10 -p ./saída/edges_to_predict.txt -i ./dados/rugged_knowledge_graph/filtered_kg/filtered_k2_edges.csv
  4. Avalie o desempenho do modelo. Examine a saída do terminal ou o arquivo 'output.log' gerado na etapa anterior para avaliar o desempenho do modelo com base na divisão do gráfico de conhecimento filtrado em conjuntos de treinamento, validação e teste com uma proporção de 85:5:10. Ajuste os argumentos do modelo se o desempenho não for o esperado, usando a Tabela 4 como exemplo.
  5. Verifique se os resultados estão na pasta de saída. Examine os resultados do modelo em 'prediction_results.csv' e examine as n principais previsões na pasta de saída. Revise as n principais previsões na pasta de saída. Para cada previsão, uma visualização de gráfico ilustra as arestas mais pertinentes que contribuem para cada previsão e suas pontuações de importância relativa.
  6. Mova os resultados da análise preditiva. Quando estiver satisfeito com os resultados da análise preditiva, mova os resultados para os 'dados/previsões/' do diretório RUGGED.

4. Geração de hipóteses

  1. Conecte-se ao contêiner RUGGED Docker.
    1. Certifique-se de que o contêiner RUGGED Docker esteja em execução. Se a janela do terminal anterior foi fechada, conecte-se ao contêiner do Docker.
    2. Navegue até o diretório RUGGED. Uma vez conectado, digite cd /workspace/RUGGED para navegar até o diretório. Emita as etapas restantes nesta janela de linha de comando.
    3. Verifique se os serviços de suporte estão em execução. Se estiver usando Ollama e Neo4j no Docker, verifique se os contêineres estão em execução digitando 'docker ps'. Repita a etapa 1.7 para verificar se os serviços estão funcionando corretamente e a etapa 1.4 para solucionar problemas, se eles existirem.
  2. Prepare os dados RAG. Prepare o gráfico de conhecimento e o corpus de texto para recuperação.
    NOTA: Esses dados podem ser substituídos por dados definidos pelo usuário, colocando-os nos diretórios 'data/knowledge_graph/' e 'data/text_corpus/', respectivamente. Esses dados devem seguir o formato do repositório GitHub (https://github.com/pinglab-utils/RUGGED/tree/main/data).
    1. Verifique os recursos. Verifique se o corpus de texto está no diretório 'data/text_corpus/', se o gráfico de conhecimento com o arquivo de previsões de mineração de texto está no diretório data/knowledge_graph/ e se os resultados da previsão estão no diretório data/predictions/ (das etapas 2.1.2., 2.3.2. e 3.5., respectivamente).
    2. Preencha o banco de dados de grafos. Execute o comando 'python ./neo4j/prepare_neo4j.py' para criar os nós, bordas e recursos de nó necessários.
    3. Indexe o corpus de texto. Execute o comando 'python ./text/prepare_corpus.py' para indexar o corpus de texto e permitir que o RUGGED recupere documentos de texto relevantes com base nas consultas do usuário, dividindo os documentos em seções de 500 tokens para criar um banco de dados vetorial usando o BART71.
    4. Opcional) Teste a recuperação do banco de dados gráfico. Envie uma consulta de teste para o banco de dados Neo4j para garantir que ele seja preenchido corretamente e possa retornar os resultados esperados. Verifique se a saída corresponde aos nós e relacionamentos esperados no banco de dados. Exemplo de comando:
      python ./test/test_neo4j_retrieval.py --query "MATCH (n) RETURN n LIMIT 5"
    5. (Opcional) Teste a recuperação do corpus RAG. Envie uma consulta de teste para o corpus de texto RAG para garantir que o sistema de recuperação de texto esteja funcionando. Verifique se os documentos recuperados são relevantes para a consulta e se as incorporações estão funcionando conforme o esperado. Exemplo de comando: python ./test/test_literature_retrieval.py --query "Quais documentos estão relacionados ao uso de betabloqueadores para tratar doenças cardiovasculares?"
  3. Interaja com o RUGGED. Inicie o RUGGED na interface de linha de comando para interagir com o sistema. Execute o comando 'python rugged.py'. Consulte o sistema para recuperar informações relevantes usando comandos específicos para interagir com o gráfico de conhecimento e o corpus de texto.
    1. Consulte o gráfico de conhecimento. Extraia informações específicas do gráfico de conhecimento colocando a pergunta em linguagem natural, começando com a palavra-chave "consulta". Por exemplo:
      pergunta "Quais são os medicamentos atualmente prescritos classificados como betabloqueadores, antiarrítmicos e antifibróticos?"
    2. Explore as previsões. Explore as análises de previsão de links da etapa 3 e peça para pesquisar um relacionamento específico, começando com a palavra-chave "predict". Por exemplo:
      prever: "Qual desses medicamentos poderia ser usado para tratar ACM e/ou DCM que não é conhecido atualmente?"
    3. Explore a recuperação da literatura. Explore documentos relacionados a um tópico biomédico específico da etapa 2. Faça a pergunta em linguagem natural, começando com a palavra-chave "pesquisar". Por exemplo:
      pesquisa, "Que evidências da literatura apóiam a alegação de que esses medicamentos previstos poderiam ser usados para tratar ACM e/ou DCM?"
    4. Iterar e refinar a consulta. Responda diretamente na linha de comando para iterar e refinar as consultas usando a interface de bate-papo do RUGGED. Consulte as conversas anteriores do sistema do usuário para revisar e refinar questionamentos e consultas.
    5. Execute novamente os comandos Cypher no Neo4j. (Opcional) Refine os resultados da consulta do gráfico de conhecimento ajustando o comando Cypher fornecido usado para recuperar as informações. Execute novamente ou modifique este comando visitando a interface do navegador Neo4j a partir da Etapa 1.4.4 (por exemplo, em http://localhost:7474). Cole e modifique os comandos Cypher conforme necessário para refinar consultas e coletar insights mais específicos.
    6. Resuma a conversa. Revise as informações recuperadas e resuma a conversa com RUGGED. Digite a palavra-chave summarize para gerar um resumo da interação em um arquivo de texto para análise posterior. A resposta de texto completo será exibida no terminal.
    7. Realize uma revisão human-in-the-loop para aumentar a precisão da saída, inspecionando e modificando as respostas do sistema para legibilidade e brevidade antes de finalizar o resumo.
    8. Revise os registros de bate-papo. Inspecione o texto completo da interação na pasta de log em RUGGED. Mantenha esses comandos intermediários e conversas entre os agentes do LLM no RUGGED para solução de problemas e reprodutibilidade.
  4. Desligando e reiniciando o RUGGED.
    1. Obtenha IDs de contêiner do Docker. Use o comando 'docker ps' para listar todos os contêineres em execução e obter as IDs de contêiner para RUGGED, Neo4j e Ollama. Para todos os comandos a seguir, substitua , e pelas IDs de contêiner reais.
    2. Pare os contêineres do Docker. Desligue o RUGGED e os contêineres do Docker associados usando suas IDs de contêiner.
      docker parar
      docker parar
      docker parar
      NOTA: Recomenda-se interromper esses contêineres antes de desligar o dispositivo para evitar possíveis perdas de dados e garantir que todos os processos sejam fechados corretamente.
    3. Reinicie os contêineres do Docker. Para reiniciar o sistema RUGGED, use as IDs do contêiner para iniciar os contêineres do Docker necessários.
      docker iniciar
      docker iniciar
      docker iniciar
    4. Anexe novamente à rede do Docker. Se necessário, use esses comandos para reconectar os contêineres à rede.
      Docker Network Connect rugged_network
      Docker Network Connect rugged_network
      Docker Network Connect rugged_network
    5. Verifique a funcionalidade do serviço. Ao reiniciar, repita as etapas 1.4 a 1.5 para garantir que o software esteja funcionando conforme o esperado.

Results

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

Esses resultados representativos foram obtidos seguindo o procedimento descrito neste protocolo. Uma análise de associação de mineração de texto foi realizada seguindo o protocolo CaseOLAP LIFT5 com parâmetros padrão, estudando oito grandes categorias de doenças cardiovasculares72 e sua associação com proteínas mitocondriais (GO:0005739). No total, 635.696 relatórios até maio de 2024 foram determinados como relevantes para essas doenças; Entre eles, 4.655 associações proteína-doença de alta confiança foram identificadas para informar as análises a jusante. Um gráfico de conhecimento biomédico foi construído usando o código do software Know2BIO usando as configurações padrão em maio de 20249. O gráfico de conhecimento resultante consiste em 219.450 nós, 6.323.257 arestas, bem como características de nós para 189.493 nós com descrições de nós, sequências de proteínas/genes, estrutura química, etc., quando disponíveis. Uma estimativa do tempo computacional para todas as etapas do protocolo é apresentada na Tabela 1.

O sistema RUGGED foi inicializado pela construção de bancos de dados vetoriais para nós e recursos de gráficos de conhecimento, bem como para publicações relevantes para CVD. Todos os nós, bordas e recursos de nó do gráfico de conhecimento foram processados com um tamanho de bloco de 20 tokens com o modelo de incorporação BART71 para se preparar para a pesquisa vetorial RAG. Da mesma forma, contribuições originais e artigos de revisão foram processados usando um tamanho de bloco de 500 tokens e o modelo de incorporação BART para se preparar para a pesquisa vetorial RAG. Para recuperação de literatura, publicações de texto completo com mais de 500 tokens foram resumidas hierarquicamente com base nas seções individuais de uma publicação pelo modelo de incorporação BART. O modelo GPT-4o foi usado para os demais agentes LLM no sistema.

Esses resultados representativos mostram um exemplo de caso de uso para investigar possíveis terapias medicamentosas para cardiomiopatia arritmogênica (ACM) e cardiomiopatia dilatada (DCM), identificadas como MeSH_Disease: D019571 e MeSH_Disease: D002311, respectivamente. Uma série de perguntas é descrita na Figura 3, com exemplos destacados de respostas de modelo mostradas na Figura 4 e resposta completa relatada no Arquivo Suplementar 1, Seção A. A direção da investigação foi adaptada às respostas validadas pelo investigador, elaborando perguntas subsequentes com base nos resultados das respostas anteriores. A análise revelou 11 candidatos a medicamentos classificados como betabloqueadores e antiarrítmicos. Novos caminhos para o tratamento terapêutico foram avaliados usando um modelo de previsão de link de rede neural convolucional de gráfico em um subconjunto do gráfico de conhecimento completo, incluindo nós dentro de 1 salto da doença do estudo e nós de medicamentos e suas interconexões, com métricas de avaliação relatadas na Tabela 4. As 10 principais arestas relevantes para cada previsão pelo modelo foram examinadas por um módulo de explicabilidade de grafos, GNNExplainer44, para identificar os principais nós e arestas que contribuem para cada previsão, respectivamente. O custo total do uso do LLM comercial para todas as etapas do protocolo RUGGED para este caso de uso é estimado em US$ 1,50 no momento da redação.

figure-results-1
Figura 1: Recuperação sob o fluxo de trabalho RUGGED. O RUGGED consiste em quatro componentes principais: (1) reunir e processar dados de recursos de origem ética e gerenciados profissionalmente (por exemplo, PubMed e bases de conhecimento biomédico com curadoria), (2) integrar resultados de pesquisas revisadas por pares em um gráfico de conhecimento unificado, (3) estruturar o texto e os dados do gráfico em serviços de banco de dados, (4) modelar e prever relações explicáveis entre entidades biomédicas dentro do gráfico de conhecimento, e (5) recuperar e sintetizar conhecimento por meio de um fluxo de trabalho de Geração Aumentada de Recuperação (RAG) (Figura 2) para validar relações moleculares complexas e explorar previsões de doenças orientadas por IA. Uma etapa de revisão human-in-the-loop pode ser conduzida pelo usuário para aumentar a precisão da saída. Clique aqui para ver uma versão maior desta figura.

figure-results-2
Figura 2: Arquitetura de recuperação e fluxo de trabalho de mitigação de viés. A estrutura RG (Retrieval Augmented Generation) emprega vários agentes LLM, cada um executando tarefas específicas para dar suporte ao acesso a informações relevantes com base na consulta do usuário. Este sistema fornece evidências documentadas para o Agente de Raciocínio baseado em GPT voltado para o usuário, facilitando a interação usuário-agente e a síntese de conhecimento. (1) Recuperação de texto biomédico: Contribuições originais revisadas por pares e artigos de revisão são filtrados com base em sua relevância para a compreensão das associações de doenças. Um banco de dados vetorial é construído para evidências de texto validadas pelo autor e pelo editor, ponderadas com base na seção correspondente da publicação, respectivamente: 70% Resumo, 10% Resultados, 10% Metadados e 10% para todas as outras subseções. Uma pesquisa por palavra-chave e uma pesquisa de similaridade em relação à incorporação de texto da consulta do usuário identificam documentos relevantes. Os resumos de cada documento são gerados usando um resumidor baseado em BERT, com o Text Evaluator Agent baseado em GPT refinando a pesquisa para validar a relevância do documento de consulta. (2) Recuperação do Gráfico de Conhecimento: Um módulo de reconhecimento de entidade nomeada baseado em BERT e extração de relação baseado em GPT conecta a consulta do usuário a entidades relevantes no gráfico de conhecimento. Uma pesquisa de similaridade em um banco de dados vetorial identifica nós e arestas pertinentes. Os dados são recuperados do banco de dados Neo4j por meio de consultas Cypher geradas pelo Cypher Query Agent baseado em GPT e refinadas pelo Query Verification Agent. (3) As respostas individuais dos pipelines Biomedical Text Retrieval ou Knowledge Graph Retrieval são apresentadas ao Reasoning Agent, que sintetiza uma resposta concisa com o mínimo de viés para a consulta do usuário. Este sistema é orientado para manter a precisão e a imparcialidade na apresentação de informações factuais. Clique aqui para ver uma versão maior desta figura.

figure-results-3
Figura 3: Caso de uso sobre síntese de conhecimento e exploração de hipóteses por meiode cascata de consultas integradas. Esta figura mostra um caso de uso destacado com foco em uma cadeia de perguntas e conceitos relacionados que um investigador e/ou profissional de saúde pode fazer ao sistema RUGGED. As consultas do usuário são apresentadas ao sistema em ordem numérica, com setas representando o raciocínio lógico e específico do domínio inferido entre cada pergunta. O sistema recupera das informações implícitas e relevantes (fonte mostrada em azul), respondendo à consulta. Exemplos de respostas do sistema são apresentados na Figura 4. Clique aqui para ver uma versão maior desta figura.

figure-results-4
Figura 4: Caso de uso cardiopatologista: elucidando a patogênese da DCV. Os pares de resposta de consulta entre o usuário e o sistema RUGGED são mostrados. No painel superior esquerdo, as perguntas de 1 a 6 recuperam informações extraindo informações do banco de dados do gráfico de conhecimento para formular respostas baseadas em evidências. A questão 7 emprega uma previsão de link gráfico explicável para identificar as terapias de melhor pontuação. A consulta solicita uma análise de previsão, que é executada e processada automaticamente pelo sistema, e as principais descobertas são resumidas de forma sucinta. A questão 8 avalia as evidências da literatura do corpus de dados de texto definido que são recuperados como evidências relevantes para verificar, validar e corroborar o achado previsto. As respostas do sistema foram revisadas por um processo de inspeção human-in-the-loop e modificadas para facilitar a leitura e a brevidade. Uma transcrição completa dessas descobertas é detalhada no Arquivo Suplementar 1. Clique aqui para ver uma versão maior desta figura.

PassosDescriçãoHora
Acesso ao conhecimento biomédico30% total
Preparar corpus de literatura biomédicaConecte-se ao PubMed e ao PubMed Central, baixe e analise dados de publicação para tarefas downstream.20%
Preparar dados da base de dados de conhecimentoConecte-se a bases de conhecimento biomédicas, baixe e analise as informações necessárias para tarefas posteriores.5%
Extração de informações30% total
Análise de mineração de texto CaseOLAP LIFTIdentifique relações doença-proteína de alto nível dentro do corpus de texto biomédico.25%
Construção de Gráfico de ConhecimentoConecte e integre informações díspares de bases de conhecimento biomédico em um gráfico de conhecimento unificado.5%
Análise de previsão10% total
Treinar Rede Neural de GrafoTreine o modelo nos dados do gráfico de conhecimento biomédico para aprender padrões ocultos no gráfico.5%
Análise de Ranking de RelevânciaAplique o módulo de explicabilidade para destacar os nós e arestas mais pertinentes relevantes para estudar a doença.2.5%
Previsão de linkUtilize o módulo de explicabilidade para identificar os principais nós e bordas que contribuem para novas bordas previstas.2.5%
Geração e/ou validação de hipóteses30% total
Configuração de banco de dados para geração aumentada de recuperaçãoInicialize o banco de dados de grafos para consultar o grafo de conhecimento e o banco de dados de vetores para recuperação de texto.25%
Exploração de hipótesesPermita a interação do usuário com o RUGGED para acessar e examinar informações relevantes para exploração de hipóteses.5%

Tabela 1: Etapas de fluxo de trabalho e limitação de taxa. Esta tabela fornece estimativas aproximadas do tempo computacional necessário para cada estágio do fluxo de trabalho. As etapas de limitação de taxa incluem acessar, extrair e indexar o conhecimento biomédico necessário para a geração aumentada por recuperação. A exploração de hipóteses pode ser repetida continuamente sem a necessidade de executar novamente as etapas de limitação de taxa.

Categoria da doençaNúmeros das árvores MeSH# PMIDs# Contribuições Originais# Artigos de revisão
Cardiomiopatias (MC)C14.280.238132,531102,33719,942
C14.280.434
Arritmias cardíacas (ARR)C14.280.067125,28692,37413,854
C23.550.073
Cardiopatias Congênitas (DCC)C14.280.40082,00654,0236,379
Doenças das Valvas Cardíacas (DV)C14.280.48472,01650,1195,743
Isquemia Miocárdica (DIC)C14.280.647256,986210,04230,223
Doença do Sistema de Condução Cardíaca (CCD)C14.280.12353,05035,3994,363
Obstrução do Fluxo de Saída Ventricular (VOO)C14.280.95522,24415,5041,686
Outras doenças cardíacas (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

Tabela 2: Estatísticas da literatura biomédica. Esta tabela detalha as categorias de doenças do estudo com seus números de árvore MeSH correspondentes e o número de documentos PubMed recuperados até maio de 2024, usados como corpus para mineração de texto. Um subconjunto dessas publicações, consistindo em artigos de pesquisa de contribuição original e artigos de revisão, é indexado em um banco de dados vetorial para recuperação pelo RUGGED durante a geração de hipóteses.

CategoriaNúmero de nósNúmero de arestasFonte(s) de dados
Anatomia5,049122,533Bgee, PubMed, MeSH, Uberon, 
Processo biológico27,047108,106Ontologia Genética
Componente Celular4,05752,238Ontologia Genética
Composto27,2783,292,028DrugBank, MeSH, CTD, UMLS, KEGG, TTD, SIDER, Inxight Drugs, Hetionet, PathFX, MyChem.info
Doença21,938311,773PubMed, MeSH, DisGeNET, SIDER, ClinVar, ClinGen, PharmGKB, MyDisease.info, PathFX, UMLS, OMIM, Mondo, DOID, KEGG
Classe de Medicamentos5,7218,283ATC
Gene29,810943,419HGNC, GRNdb, KEGG, ClinVar, ClinGen,
Função molecular11,15147,086SMPDB, DisGENET, PharmGKB, MyGene.info
Caminho52,012234,944Ontologia Genética
Proteína20,7401,074,809Reatoma, KEGG, SMPDB
Reação14,647128,038UniProt, Reactome, TTD, SMPDB, STRING, HGNC
Subtotal219,4506,323,257Reator
Associações de mineração de texto84,670
Total219,4586,327,927

Tabela 3: Estatísticas do gráfico de conhecimento. Esta tabela detalha 11 categorias biomédicas amplas que compõem o gráfico de conhecimento Know2BIO construído, enriquecido com arestas adicionais derivadas da análise de mineração de texto e análise preditiva. O gráfico de conhecimento e as previsões resultantes são gerenciados pelo banco de dados de gráficos Neo4j para recuperação pelo RUGGED durante a geração de hipóteses.

ExatidãoPrecisãoLembrarPontuação F1AUROCAUPRC
Validação0.71580.66390.87430.75470.84370.8637
Teste0.7030.63670.94550.7610.89610.9094

Tabela 4: Avaliação explicável do modelo de IA. Esta tabela relata as métricas de avaliação para a previsão de link do gráfico de conhecimento usando uma rede neural convolucional de gráfico de duas camadas. As métricas foram avaliadas particionando as bordas do gráfico em 85% de treinamento, 5% de validação e 10% de conjuntos de dados de teste. A precisão indica a proporção de previsões classificadas corretamente. A Precision relata a proporção de previsões positivas corretas entre todas as previsões positivas. O recall mede a proporção de previsões positivas corretas entre as arestas positivas reais. A pontuação F1 é a média harmônica de precisão e recall, equilibrando as duas métricas. O AUROC avalia a capacidade do modelo de diferenciar entre previsões positivas e negativas. O AUPRC quantifica o trade-off entre precisão e recall em diferentes limites. Com todas as métricas, valores mais altos indicam melhor desempenho do modelo.

Arquivo suplementar 1: Este arquivo detalha a resposta completa do modelo do RUGGED e uma comparação com o GPT-4o. A Seção A apresenta a interação homem-computador completa com o RUGGED, expandindo a abordagem de cadeia de consulta descrita na Figura 3 e fornecendo a resposta completa além do resumo destacado na Figura 4. A Seção B avalia as respostas do GPT-4o sem recuperação em relação às do RUGGED, avaliando atributos como precisão, profundidade, pontuação de confiança, confiabilidade de evidências e custo. Clique aqui para baixar este arquivo.

Discussion

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

O protocolo RUGGED aproveita modelos de linguagem modernos com informações atualizadas para capacitar os investigadores a explorar dinamicamente o cenário biomédico em evolução e descobrir novos conhecimentos. Essa interação humano-computador impulsiona um processo inovador que exemplifica a eficiência da máquina (RUGGED) e a experiência e julgamento do investigador. Este protocolo foi projetado para ser executado na sequência descrita. A etapa 1 detalha a instalação do software. As etapas 2 e 3 são essenciais para preparar a literatura e os recursos biomédicos, enquanto a etapa 4 indexa essas informações para geração aumentada por recuperação e interação do usuário com o sistema LLM. Etapas demoradas podem ser executadas simultaneamente e/ou sequencialmente. Por exemplo, a criação do gráfico Neo4j (etapa 4.2.2) pode começar durante a análise de previsão (etapa 3) e a indexação pode começar após a construção do gráfico de conhecimento (etapa 2.3) e mineração de texto (etapa 2.1). Essas etapas devem ser repetidas para obter o resultado final desses resultados intermediários. Embora projetado para recuperação de informações biomédicas, este protocolo, com pequenas modificações, também pode lidar com outros dados de texto e gráficos, como dados internos, notas clínicas ou registros eletrônicos de saúde. Os detalhes da formatação de dados estão na etapa 4.2.

A operação desta plataforma depende da instalação e interconexão adequadas de várias tecnologias, incluindo modelos de linguagem, bancos de dados gráficos e bancos de dados vetoriais (ver Tabela de Materiais). Para verificar se esses serviços estão instalados e conectados corretamente, os scripts de teste são fornecidos na pasta 'test' no repositório GitHub. Os serviços externos podem incorrer em custos, com preços sujeitos a alterações pelo fornecedor. Esses serviços opcionais também possuem alternativas hospedadas localmente, exigindo apenas recursos computacionais suficientes. No entanto, essas alternativas podem afetar o desempenho e/ou a conveniência do modelo, tornando-as inadequadas para alguns cenários de caso de uso.

Com o cenário de LLM em rápida evolução, novos modelos de referência e modelos específicos de tarefas são lançados regularmente. No momento deste relatório, os modelos mais adequados foram escolhidos para a tarefa. Os usuários podem escolher qual LLM usar atualizando o arquivo de configuração de acordo (consulte as etapas 1.3.2-1.3.4). A seleção do modelo depende de sua relevância para um caso de uso específico. Por exemplo, incorporar modelos focados em garantir que as respostas do modelo sejam justas, censuradas e livres de discurso de ódio 73,74,75,76,77,78, neste fluxo de trabalho é essencial para considerações éticas. Além disso, a engenharia rápida é essencial para orientar o comportamento confiável e responsável do LLM 79,80,81,82. Os prompts criados para o fluxo de trabalho RUGGED são adaptados aos modelos empregados e aos casos de uso apresentados. Para ajustar os prompts para um caso de uso diferente, os usuários podem editar prompts no fluxo de trabalho RUGGED na pasta 'configuration' dentro do arquivo 'prompts.json'.

Embora os sistemas RAG tenham como objetivo reduzir as alucinações em LLMs, fundamentando as respostas em evidências, esses modelos ainda podem levar a informações imprecisas ou respostas geralmente verdadeiras e não específicas. Uma comparação de referência do RUGGED com o GPT-4o é fornecida no Arquivo Suplementar 1, Seção B. As alucinações do modelo geralmente ocorrem quando as informações recuperadas excedem a janela de contexto do modelo, análoga à demência com perda de memória e incapacidade de localizar o conteúdo dos dados, resultando em respostas imprecisas 83,84,85. A escolha de um modelo de LLM adequado ajuda a mitigar esse problema. Por exemplo, GPT-4o tem um limite de contexto de 128k tokens, significativamente mais do que GPT-3.5 Turbo Além disso, os LLMs ajustados com conhecimento de domínio específico podem potencialmente aumentar a precisão e a especificidade das respostas em aplicações biomédicas 86,87,88. Apesar dessas medidas, é essencial verificar as informações antes de prosseguir com experimentos caros em laboratório úmido.

O RUGGED aproveita a IA explicável em um pipeline RAG para examinar as previsões de links, identificando relacionamentos confiáveis e não descobertos anteriormente. Enquanto os sistemas RAG tradicionais dependem da recuperação baseada em similaridade em massa, essa abordagem conecta a explicabilidade com um aumento de resposta direcionado. A Tabela 4 destaca o forte desempenho do modelo, demonstrando alto recordatório (validação: 0,975 teste: 0,976) e escores F1 equilibrados (validação: 0,796, teste: 0,797), indicando confiabilidade na identificação de verdadeiros positivos, embora com maior taxa de falsos positivos. A robustez do modelo é ainda apoiada por seus valores AUROC (validação: 0,963, teste: 0,964) e AUPRC (validação: 0,971, teste: 0,972). A precisão (validação: 0,673, teste: 0,674), no entanto, pode se beneficiar do ajuste de limite, incorporando recursos detalhados de nó ou tratamento aprimorado do desequilíbrio de classe. A eficácia do modelo é altamente dependente do gráfico de conhecimento de entrada; O sobreajuste é um risco com gráficos menores, enquanto gráficos maiores exigem maiores recursos computacionais. No entanto, qualquer abordagem baseada em RAG depende muito da qualidade dos dados subjacentes à recuperação. Por exemplo, a construção de um gráfico de conhecimento geralmente exige muito tempo e trabalho devido ao ruído intrínseco no gráfico original. Isso requer esforço manual para reduzir o ruído e rotular, bem como custos contínuos de manutenção e atualização dos bancos de dados.

O uso principal do RUGGED's é na síntese de conhecimento e exploração de hipóteses. Ao investigar várias relações ocultas, como mecanismos de doenças e tratamentos medicamentosos, o RUGGED conduz com eficiência a triagem da literatura. Para reduzir a carga computacional, a maioria dos aplicativos pode ser hospedada em um servidor (por exemplo, AWS ou servidor computacional) e configurada para ser atualizada periodicamente com as informações mais recentes. Além disso, esse fluxo de trabalho pode ser adaptado para realizar aplicativos específicos de domínio, como servir como uma plataforma para incluir dados de pacientes com modelos locais para manter a segurança, a privacidade e a confidencialidade. Além da pesquisa biomédica, o design modular do RUGGED permite que ele ofereça suporte a tarefas de recuperação, inferência e resumo de informações, personalizando o pipeline RAG e estratégias de engenharia imediatas adaptadas ao domínio de destino. A adaptação bem-sucedida requer uma consideração cuidadosa dos desafios específicos do domínio, como o pré-processamento de diversos formatos de dados e a avaliação dos modelos apropriados para necessidades específicas de tarefas e domínios.

Disclosures

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

Os autores não têm nada a divulgar.

Acknowledgements

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

Os autores gostariam de agradecer ao Dr. Alex Bui por sua orientação e discussão cuidadosa. Além disso, agradecemos ao Dr. Ding Wang por suas discussões úteis. Este trabalho foi apoiado em parte pelo NIH 1U54HG012517-01 para P.P., K.W. e W.W.; NIH T32 HL13945 para ARP; Estágio de Pesquisa da National Science Foundation (NRT) 1829071 para ARP; e o TC Laubisch Endowment para PP na UCLA.

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
Hardware/Software - Placa gráfica e driver de softwareNvidiahttps://www.nvidia.comUma placa gráfica e seu software de driver associado são altamente recomendados para reduzir significativamente o tempo de execução de tarefas com uso intensivo de computação, como LLM local e análises preditivas. Para dispositivos equipados com uma GPU NVIDIA RTX, baixe e instale os drivers necessários e o CUDA Toolkit no site da NVIDIA (https://developer.nvidia.com/cuda-downloads).
Software - Serviço comercial de modelo de linguagem grandeOpenAIhttps://openai.comRUGGED suporta a API OpenAI para modelos como GPT-3.5 e GPT-4o. Para configurar usando modelos OpenAI, primeiro obtenha uma chave de API OpenAI. Prossiga para o site da OpenAI (https://openai.com/blog/openai-api) para criar uma conta, carregar fundos e obter uma chave de API. Essa chave de API é necessária para permitir que o RUGGED use modelos OpenAI. Determine quais agentes LLM dentro do sistema da RUGGED usarão modelos OpenAI de sua documentação (https://platform.openai.com/docs/models).
NOTA: A API OpenAI é um serviço pago. No momento da publicação, o custo do GPT-4o é de US$ 5,00 por 1 milhão de tokens de entrada e US$ 2,50 por 1 milhão de tokens de saída (para saber mais, visite https://openai.com/pricing).
Software - ConteinerizaçãoO Dockerhttps://www.docker.comDocker ajuda a manter um ambiente de tempo de execução computacional consistente, simplificando a instalação e a execução de software em diferentes máquinas. Para instalar o Docker, visite o site do Docker (https://www.docker.com/), clique em 'Começar', baixe e instale a versão apropriada para o sistema operacional. Verifique a instalação digitando 'docker --version' no terminal; a instalação bem-sucedida relata a versão do Docker instalada.
Software - Banco de dados gráficoNeo4jhttps://neo4j.comNeo4j é um software de banco de dados gráfico que gerencia e consulta com eficiência nós e relacionamentos baseados em gráficos. O RUGGED suporta Neo4j em várias formas: contêiner Docker, Neo4j Desktop ou servidor online Neo4j AuraDB. Escolha a opção mais adequada ao caso de uso.
Configurando o Neo4j como um contêiner do Docker. Execute esses comandos para configurar o Neo4j no Docker, com o caminho do arquivo para a pasta (por exemplo, /Users/username/RUGGED) como 'PATH_TO_FOLDER'. Para obter mais detalhes sobre a solução de problemas, consulte o site do Neo4j Docker (https://hub.docker.com/_/neo4j).
docker pull neo4j
docker run – nome neo4j --net rugged_network --publish=7474:7474 --publish=7687:7687 -d -v 'PATH_TO_FOLDER'\neo4j\data:/data neo4j
NOTA: Inicialize o Neo4j no Docker pela primeira vez definindo um nome de usuário e senha. Execute o script neo4j_setup.py (por exemplo, python neo4j_setup.py) ou via interface web em http://localhost:7474.
Configurando o Neo4j Desktop. Se estiver usando o Neo4j Desktop, baixe e instale a partir do site do Neo4j (https://neo4j.com/). Crie um novo projeto clicando em "Novo" e, em seguida, clique em "Adicionar" para criar um novo Sistema de Gerenciamento de Banco de Dados (DBMS). Selecione "DBMS local", defina uma senha, clique em "Criar" e clique em "Iniciar". Um texto verde "ACTIVE" indica que ele está em execução.
Configurando o Neo4j AuraDB. Visite o site do Neo4j em (https://neo4j.com/cloud/aura-free/) para criar uma conta e fazer login. Selecione "Nova instância" para criar uma instância vazia e salve o URI e a senha inicial para acessar a interface bolt (por exemplo, bolt://myurl.neo4j.com). Clique no botão play para iniciar a instância, que exibirá o URI da conexão na caixa de informações.
NOTA: O Neo4j AuraDB oferece um nível gratuito de até 200.000 nós e 400.000 relacionamentos. Para gráficos maiores, visite Preços do Neo4j (https://neo4j.com/pricing).
Software - Serviço de Modelo de Linguagem Grande LocalOllamahttps://ollama.comRUGGED suporta o uso de modelos locais usando Ollama (por exemplo, Llama3). Para habilitar, primeiro instale o Ollama no dispositivo ou baixe o contêiner do Docker. Para instalar o Ollama, visite o Ollama weblocal (https://ollama.com/download) e siga as instruções de instalação. Para instalar o Ollama no Docker, execute o seguinte comando:
docker pull ollama/ollama
NOTA: No momento da publicação, não há versão estável para o Ollama no sistema operacional Windows.
Software - Controle de versãoGithttps://www.git-scm.comO software de controle de versão permite a instalação e atualização eficientes do software. Para instalar o Git, visite o site do Git (https://www.git-scm.com/), clique em 'Downloads', baixe e instale a versão apropriada para o sistema operacional. Verifique a instalação digitando 'git --version' no terminal; a instalação bem-sucedida relatará a versão do Git instalada.

References

Loading...
$$\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