chat with pennsieve

Converse com Pennsieve

Descrição do projeto

Este é o componente do projeto de pesquisa desenvolvido sob a orientação do Dr. Zachary Ives. O objetivo inicial é desenvolver uma camada gráfica no topo do banco de dados Pennsieve e ativar o aprendizado de máquina através da extração eficaz de dados de dados médicos de formatos de arquivo complexos e versáteis. Este componente permite a interação da linguagem natural com o banco de dados.

Nota : Todos os métodos foram implementados no gráfico subjacente criado no Neo4J usando outro repositório que será vinculado quando for público. Este projeto está pronto para ser usado fora da caixa, no entanto, sem o gráfico subjacente preenchido, você não obterá nenhum resultado.

Estrutura do projeto

app/

• __init__.py : inicializa o pacote de aplicativos.
  • Objetivo : marca o diretório como um pacote python. Adicione as importações no nível do pacote aqui, se necessário.
• config.py : lida com variáveis ​​de configuração e ambiente.
  • Objetivo : carrega variáveis ​​de ambiente e define as definições de configuração.
  • Aprimoramentos : implemente o tratamento de erros para obter variáveis ​​de ambiente ausentes, se necessário.
• database.py : gerencia a conexão de banco de dados Neo4J.
  • Objetivo : a função setup_neo4j_graph() retorna um gráfico NEO4J configurado com URL, nome de usuário e senha fornecidos no arquivo .env .
  • Documentação : setup_neo4j_graph() retorna o wrapper Langchain Neo4J. Métodos importantes usados: query() e refresh_schema() . Documentação de Langchain Neo4jgraph
• main.py : ponto de entrada do aplicativo. Passe a consulta do usuário e recupere o resultado chamando run_query(user_query: str) de qa_chain.py . Ele abstrava todas as complexidades e fornece uma interface simples para interagir com o sistema.
• dataguide.py : extrai caminhos de dataguida do banco de dados e os formam em caminhos de cifra.
  • Métodos :
    1. extract_dataguide_paths(graph: Neo4jGraph) : Extrai os caminhos de dataguida da raiz para a folha usando uma consulta de cifra.
    2. format_paths_for_llm(results: List[Dict[str, Any]]) : os formatos resultam de extract_dataguide_paths em caminhos de cifra válidos para consultas de correspondência.
• test.py : Testes a conexão com o gráfico NEO4J, a extração de caminhos de dataguida e formatando -os. Produz o tempo necessário para cada parte.
  • Aprimoramentos : adicione testes de unidade ou teste outros métodos manualmente.
• prompt_generator.py : Este módulo é responsável por criar e combinar o sistema Langchain e os prompts humanos em langchain.prompts.ChatPromptTemplate . É uma parte crucial do projeto, pois define como os avisos são estruturados e usados ​​na estrutura Langchain.
  • Métodos :
    • get_cypher_prompt_template() : Este método retorna a instância ChatPromptTemplate criada neste arquivo. Ele combina o sistema e os avisos humanos em um único modelo que pode ser usado para gerar consultas de cifra a partir de GraphCypherQAChain em qa_chain.py .
  • Documentação :
    • PromptTemplate: Esta classe é usada para definir a estrutura dos prompts. Os parâmetros principais utilizados são input_variables , que especificam as variáveis ​​a serem incluídas no prompt e template , que define o texto do prompt.
    • SystemMessagePromptTemplate: Esta classe é usada para criar mensagens do sistema no prompt. O parâmetro principal usado é prompt , que define o texto da mensagem do sistema.
    • HumanMessagePromptTemplate: Esta classe é usada para criar mensagens humanas no prompt. O parâmetro principal usado é prompt , que define o texto da mensagem humana.
    • ChatPromptTemplate: Esta classe combina o sistema e as mensagens humanas em um único prompt de bate -papo. O método principal usado é from_messages() , que leva uma lista de modelos de mensagem e os combina em um prompt de bate -papo.
• qa_chain.py : define a função run_query(user_query: str) , que integra todos os componentes do projeto e executa um GraphCypherQAChain na consulta do usuário.
  • Documentação :
    • GraphCypherQachain
    • Chatopenai
    • NOTA: Substitua ChatOpenAI por AzureChatopenai, se necessário.

Paths_VectordB/

• __init__.py : inicializa o pacote de aplicativos.
  • Objetivo : marca o diretório como um pacote python. Adicione as importações no nível do pacote aqui, se necessário.
• generate_descriptions.py : define o prompt do sistema para gerar descrições a partir de LLMS para caminhos de cifra.
  • Métodos :
    • generate_path_descriptions(all_paths: List[str]) : gera descrições para os caminhos fornecidos usando o LLM. Produz uma lista de descrições.
    • generate_embedding(path_description: str) : gera incorporação para a descrição do caminho fornecido usando a API de incorporação do OpenAI.
  • Documentação : OpenAiEmbddings
• random_path_generator.py : fornece métodos para gerar caminhos aleatórios a partir do banco de dados e formatá -los em caminhos de cifra.
• vectorDB_setup.py : fornece métodos para iniciar o contêiner Milvus, conectar -se a ele, definir esquema de coleta, criar coleta, inserir dados e conduzir pesquisas de similaridade vetorial.
  • Documentação : Pymilvus
• main.py : o wrapper funciona que combinam todas as funcionalidades deste diretório. Por exemplo, get_similar_paths_from_milvus é usado no app/qa_chain.py para realizar a pesquisa de similaridade vetorial com as consultas do usuário.
• test.py : métodos para testar várias funcionalidades. Atualmente comentado.
  • Aprimoramentos : adicione métodos de teste ou teste de unidade manualmente.
• write_read_data.py : métodos simples de gravação e leitura para armazenar caminhos e descrições de cifra gerados a partir de chamadas da API.
  • Objetivo : Ajuda na análise e economia de custos da API. O método fill_collection_with_random_paths em paths_vectorDB/main.py grava os caminhos e descrições gerados a partir de chamadas da API para data.txt .

Diretório raiz

• env.sample : faça uma cópia disso no diretório raiz do seu projeto e renomeie -o para .env . Preencha os valores.
• .gitignore : Especifica arquivos e diretórios a serem ignorados pelo Git.
• README.md : documentação do projeto.
• docker-compose.yml : arquivo Docker para Milvus DB. Se houver uma nova versão, substitua este arquivo. Certifique-se de ser chamado de docker-compose.yml e colocado no diretório raiz.
• requirements.txt : Dependências do Python e suas versões compatíveis usadas para desenvolvimento. Nota: O arquivo requirements.txt foi criado através pipenv .

Começando

Pré -requisitos

• Python 3.8+
• Docker
• NEO4J Desktop e Neo4J Database preenchida com gráfico e dataGuide (o código para isso será vinculado em breve)

Instalação

Introdução a este projeto é simples. Você pode seguir as etapas abaixo:

1. Clone o repositório :

   git clone https://github.com/hussainzs/chat-with-pennsieve.git
   cd project_root

   Nota: verifique se você está no diretório raiz do projeto antes de prosseguir com as próximas etapas.

2. Instale dependências :

   pip install -r requirements.txt

3. Configurar variáveis ​​de ambiente :

   • Copie env.sample e renomeie o arquivo para .env e preencha os valores necessários.

4. Configure a área de trabalho neo4j :

   • Faça o download e instale o Neo4J Desktop.
   • Observe o URL, o nome de usuário e a senha do banco de dados NEO4J que contém o gráfico e o dataGuide.
   • Atualize o arquivo .env com os detalhes da conexão Neo4J (URL, nome de usuário, senha). Os valores padrão foram preenchidos.

5. Execute app/main.py :

   • Navegue até o diretório app e execute main.py Verifique se a consulta do usuário desejada é passada como um argumento para a função run_query(user_query) .
   • Certifique-se de ter docker-compose.yml no diretório raiz. Quando você executa o app/main.py, os contêineres do MILVUS começam automaticamente executando os comandos do terminal. Confira paths_vectorDB/vectorDB_setup.py para obter mais informações.
   • Nota : Quando o contêiner Milvus é criado pela primeira vez, ele baixará e cria uma nova pasta no diretório raiz chamado volumes . A pasta contém 3 subpastas: milvus , minio e etcd
   • Para mais informações, consulte: Execute o Milvus usando o Docker Compose

NOTA : Para um esclarecimento adicional da saída esperada quando você executa app/main.py , estou anexando 2 PDFs de saída gerada a partir do sistema na pasta chamada saídas esperadas .

1. O arquivo chamado first_output.pdf mostra o que é esperado quando o usuário executa o app/main.py pela primeira vez em uma nova sessão com valores padrão. (Quando você o executa pela primeira vez, pode demorar um pouco para baixar tudo)
2. O regular_output.pdf mostra o que é esperado quando o usuário executa o app/main.py em uma sessão regular com valores padrão.

Aprimoramentos recomendados

1. Melhorar os avisos do sistema : aprimorar os avisos no app e paths_vectorDB pode melhorar significativamente o desempenho do LLM. Testemunhei que exemplos de alta qualidade no prompt do sistema aumentarão a qualidade da geração de descrição para caminhos. O prompt do sistema também afeta significativamente a resposta final do LLM.
2. Otimize o contexto para o LLM : em vez de enviar todos os caminhos de dataguida, envie os 10 principais caminhos relacionados do Milvus Vector DB para reduzir os custos da API e potencialmente melhorar o desempenho. Os avisos de sistema longos podem aumentar a alucinação e confunde LLM, consulte este artigo para obter mais informações: perdido no meio: como os modelos de idiomas usam contextos longos
3. Atualize MILVUS : Instale a versão mais recente do Milvus e altere a métrica de similaridade de "IP" (Produto Interior) para Cosine no Método search_similar_vectors dentro de paths_vectorDB/vectorDB_setup.py para obter melhores resultados.
4. Crie uma interface do usuário de bate -papo : use o streamlit ou sua biblioteca de interface do usuário favorita para criar uma interface básica de usuário para este projeto. Você pode usar o FASTAPI para criar uma API simples para enviar consultas de usuário e receber respostas do app/main.py.
5. Adicione a habilidade de conversação : permita que as interações de acompanhamento oriem o LLM para uma melhor geração de caminhos, embora isso possa aumentar os custos da API. Percebi que, frequentemente, quando o LLM estava errado, isso só estava errado em sua geração de caminho. Alguém com conhecimento de domínio do gráfico subjacente pode corrigi-lo facilmente com um acompanhamento básico.