Vector DB Testing

Veja Benchmarks

Como usar

• Verifique se os pacotes apropriados estão instalados. Certifique -se de que o seguinte esteja instalado: sentença_transformers tqdm pandas pypdf2 tocha asyncio concorrente re QDrant_client Pinecone pymilvus dotenv
• Carregue todos os PDFs em /dados /, ou outro diretório, se especificado.
  • Se você tiver um arquivo de metadados para obter mais informações sobre arquivos PDF, faça o upload no diretório da casa e nomeie -o metadata.csv ou altere o nome. O código provavelmente precisará ser alterado em get_metadata () no MacLoader para acomodar seu arquivo de metadados específicos.
• Detalhes da conexão de entrada em .env. Veja .Env-Exemplo de como sua .ENV deve parecer.
  • Isso pode ser evitado se você deseja apenas inserir os detalhes como parte da inicialização do banco de dados no código.
• Crie um arquivo Python índice. A partir daqui, eu definiria o registro apropriado. Com todos os dados, é importante cuidar de quaisquer problemas. Todo o registro é nomeado adequadamente usando informações, aviso, erro e crítico.
• Crie delete.txt, não coloque nada nele.
• Importe arquivos apropriados do projeto e inicialize -os com os detalhes apropriados. Todos os parâmetros disponíveis estão bem documentados e devem ser mostrados pelo seu IDE por meio de pau ou clicar.
  • EX: from Loader import MacLoader e from databases.PineconeDB import PineconeDB
• Depois de fazer uma execução de seus arquivos, consulte Delete.txt e veja quais arquivos estão dando problemas com o leitor do PypDF2. Se você deseja remover esses arquivos, use o utilitário.delete_bad_pdfs ()
• Aproveite, deixe -me saber como melhorar esse processo!

Takeaways -chave

Pré-processamento

LLAMA_INDEX é ótimo, mas é confiabilidade nos nós é um obstáculo real. O TextNodes parece muito útil, mas com ele vêm muitos dados desnecessários que você carrega com o seu vetor, o que apenas ocupa o armazenamento e o desempenho. Devido a esse motivo sozinho, llama_index não deve ser usado para complicar o processo de upload do vetor. Os dados extras são demais quando em um conjunto de dados em escala de produção. Também não gosto de como é irritante escrever código com ele às vezes, tantas regras estranhas e etapas desnecessárias. O TextNodes pode ser um ativo poderoso valioso se tudo for gerenciado corretamente, com todos os dados extras sendo armazenados localmente e não impedindo a velocidade de recuperação ou a memória.

Langchain facilita a interface dos dados com menos regras (depende do contexto). Definitivamente, não acho que Langchain esteja pronto para a produção e a fita adesiva deve ser usada. Ter controle total sobre todo o processo também pode ser preferido em um ambiente de produção.

No geral, não consigo encontrar algo que se encaixe facilmente exatamente como eu quero. Aqui está o meu entendimento de como acho que esse processo deve ir:

Ao terminar este programa, percebi que era apenas um substituto para as duas ferramentas acima. As duas ferramentas acima devem se aplicar a todos os casos de uso, acabei de codificar um específico para o meu.

Incorporação / transformadores

Escolher transformadores de frases não foi muito difícil.

• O Minilm-V2 foi bom e rápido, mas eu estava preocupado com a escalabilidade com grandes quantidades de dados. Não é o mais preciso, mas ainda bom, apenas não para produção.

• E5-Large-V2 Falha na recuperação de dados básicos em pequena escala nos meus testes. Devido a isso, também não o considerarei em uma escala maior.

• Tudo leva mais tempo com as incorporações do instrutor , mas provavelmente darão uma precisão de dados muito melhor. Ainda não os testei corretamente.

• O All-MPNET-V2 é o melhor em termos de velocidade e desempenho, talvez não tão preciso quanto as incorporações de instrutores, mas a velocidade e o desempenho podem ser preferidos em um ambiente de produção.

• As incorporações ADA (OpenAI) serão muito mais caras do que os transformadores típicos das frases locais. No passado, tive problemas de processamento de conjuntos de dados maciços devido a limites de taxa e outras restrições impostas por seu modelo. Ter dados enviados em pedaços resolverá esse problema.

  • É importante considerar que a ADA incorpora em uma dimensão de 1536 também. Isso levará a tempos de pesquisa semânticos mais altos devido à matemática extra necessária para muito mais dimensões. Novamente, isso também levaria a uma maior precisão, mas outros modelos também podem fazer incorporação de alta dimensão sem o uso de uma API externa cara.
  • Se o uso de um transformador de frase local for limitante ou inconveniente, este é um ótimo substituto.

Escolha final: indeterminado. Preciso terminar o pré-processamento primeiro antes de escolher entre instrução ou mpnet

Bancos de dados vetoriais

Bancos de dados rejeitados

• Chroma
  • Falta opções de implantação do servidor. Para pequenos projetos, essa sempre será a melhor escolha, embora eu pense.
• PGVECTOR
  • O desempenho é muito ruim em benchmarks por algum motivo. Pode não ser representativo do desempenho do mundo real. Veja aqui
  • Se o banco de dados postresql já estiver planejado para ser usado, ou for prático para os dados fornecidos, não tenho dúvidas de que o PGVector seria a melhor opção. No entanto, eu não usaria a biblioteca PGVector por conta própria ou mudaria para Postresql para ela.
• Elástico
  • Lento e desajeitado
• Tecelava
  • Eu já havia planejado avaliar isso, mas, ao tentar implementar isso neste programa, tive muito mais dificuldade em comparação com todos os outros.
    • A documentação para o cliente Python não é ótima, não foi difícil, mas a falta de documentação é preocupante.
    • Meu caso de uso está planejando usar uma nuvem gerenciada, e o WCS me deixou realmente preocupado. Não parece haver muita segurança, não há nem o 2FA. Eu pessoalmente não confio no WCS, e ele tinha a pior interface do usuário em comparação com qualquer um dos outros bancos de dados.
    • Se planejado usar em um recipiente do Docker, o Weaviate deve ser reconsiderado e recebe uma foto justa, mas por enquanto não estou continuando a avaliá -lo.

Atualmente investigando

• Pinecone
• Milvus
• QDRANT

Considerações de todo o processo

• Os PDFs têm tanta lixo e a maioria dos carregadores come isso. Para retirar o texto dos PDFs, há muito lixo, especialmente ao usar uma solução de leitura em Langchain ou LLAMA_Index. Não ter controle sobre esse processo tornou mais difícil do que seria fazer um carregador de PDF de diretório personalizado.
  • Eu acho que quase qualquer outro formato é superior ao PDFS para a leitura de quantidades em massa de dados. Muitos problemas com a codificação, personagens de lixo e não ilegíveis em arruinando o texto e tocando o oleoduto.
• Os dados de texto podem ser armazenados em todos os bancos de dados do vetor, se necessário. Isso simplificará drasticamente o processo de armazenamento. Muitos bancos de dados vetoriais permitirão isso na forma de metadados, mas não permitir o armazenamento separado do texto que pode ser um problema. O texto é muito grande e a memória intensiva para também ser armazenada na memória, e os metadados podem ser armazenados no disco, mas a filtragem de metadados não estará disponível.
  • Se o banco de dados vetorial não lidar com isso corretamente, o processo de upload do vetor poderá ser simplificado apenas pelo upload dos vetores e um ID. Quando a pesquisa semântica for executada, pesquise um banco de dados local ou NoSQL no ID associado.