Vector DB Testing

Lihat tolok ukur

Cara menggunakan

• Pastikan paket yang tepat diinstal. Pastikan yang berikut ini diinstal: kalimat_transformers TQDM panda pypdf2 torch asyncio concurrent re qdrant_client Pinecone pymilvus dotenv
• Unggah semua PDF ke /data /, atau direktori lain jika ditentukan.
  • Jika Anda memiliki file metadata untuk informasi lebih lanjut mengenai file pdf, unggah ke direktori home dan beri nama metadata.csv atau ubah namanya. Kode kemungkinan perlu diubah di get_metadata () di MacLoader untuk mengakomodasi file metadata spesifik Anda.
• Masukkan detail koneksi di .env. Lihat .Env-contoh untuk seperti apa .ENV Anda seharusnya.
  • Ini dapat dihindari jika Anda hanya ingin memasukkan detail sebagai bagian dari inisialisasi DB dalam kode sebagai gantinya.
• Buat file python indeks. Dari sini saya akan mendefinisikan logging yang sesuai. Dengan semua data, penting untuk mencari masalah apa pun. Semua penebangan dinamai dengan tepat menggunakan info, peringatan, kesalahan & kritis.
• Buat delete.txt, jangan menaruh apa pun di dalamnya.
• Impor file yang sesuai dari proyek dan inisialisasi dengan detail yang sesuai. Semua param yang tersedia didokumentasikan dengan baik dan harus ditampilkan oleh IDE Anda melalui melayang atau mengklik.
  • Contoh: from Loader import MacLoader & from databases.PineconeDB import PineconeDB
• Setelah menjalankan file Anda, lihat delete.txt dan lihat file mana yang memberikan masalah dengan pembaca PYPDF2. Jika Anda ingin menghapus file -file ini, gunakan utility.delete_bad_pdfs ()
• Nikmati, beri tahu saya cara meningkatkan proses ini!

Kunci takeaways

Pra-pemrosesan

Llama_index bagus, tetapi keandalan pada node adalah halangan yang nyata. TextNodes tampak sangat berguna, tetapi dengan itu datang banyak data yang tidak perlu yang Anda unggah dengan vektor Anda yang hanya mengambil penyimpanan dan kinerja. Karena alasan ini saja LLAMA_INDEX tidak dapat digunakan karena memperumit proses unggahan vektor. Data tambahan terlalu banyak ketika dalam dataset skala produksi. Saya juga tidak suka betapa menjengkelkannya menulis kode dengannya, begitu banyak aturan aneh dan langkah -langkah yang tidak perlu. TextNodes dapat menjadi aset yang sangat kuat jika semuanya dikelola dengan benar, dengan semua data tambahan disimpan secara lokal dan tidak menghambat kecepatan pengambilan atau memori.

Langchain membuat cara yang lebih mudah untuk menghubungkan data dengan aturan yang lebih sedikit (tergantung pada konteksnya). Saya pasti tidak berpikir langchain siap produksi dan pita pegangan harus digunakan sebagai gantinya. Memiliki kontrol penuh atas seluruh proses mungkin lebih disukai juga di lingkungan produksi.

Secara keseluruhan, saya tidak dapat menemukan sesuatu yang pas dengan mudah seperti yang saya inginkan. Inilah pemahaman saya tentang bagaimana saya pikir proses ini harus dilakukan:

Saat menyelesaikan program ini, saya menyadari itu hanya pengganti untuk dua alat di atas. Dua alat di atas dimaksudkan untuk diterapkan pada semua kasus penggunaan, saya hanya mengkodekan satu spesifik untuk saya.

Embeddings / Transformers

Memilih transformator kalimat tidak terlalu sulit.

• All-Minilm-V2 baik dan cepat tetapi saya khawatir tentang skalabilitas dengan sejumlah besar data. Bukan yang paling tepat tetapi masih bagus, hanya saja tidak untuk produksi.

• E5-Large-V2 gagal pengambilan data dasar dalam skala kecil dalam pengujian saya. Karena ini saya juga tidak akan mempertimbangkannya dalam skala yang lebih besar.

• Semuanya memakan waktu lebih lama dengan embeddings instruktur , tetapi mereka kemungkinan akan memberikan ketepatan data yang jauh lebih baik. Saya belum menguji ini dengan benar.

• All-Mpnet-V2 hanya ada di sekitar terbaik dalam hal kecepatan dan kinerja, mungkin tidak setepat embeddings instruktur tetapi kecepatan dan kinerja mungkin lebih disukai dalam lingkungan produksi.

• Embeddings ADA (OpenAI) akan jauh lebih mahal daripada transformator kalimat lokal yang khas. Di masa lalu, saya memiliki masalah memproses kumpulan data besar karena batasan tingkat dan pembatasan lain yang dikenakan oleh model mereka. Memiliki data yang dikirim dalam potongan akan menyelesaikan masalah ini.

  • Penting untuk mempertimbangkan bahwa ADA embed dalam dimensi 1536 juga. Ini akan mengarah pada waktu pencarian semantik yang lebih tinggi karena matematika tambahan yang diperlukan untuk lebih banyak dimensi. Sekali lagi ini akan mengarah pada presisi yang lebih tinggi juga, tetapi model lain juga dapat melakukan embedding dimensi tinggi tanpa menggunakan API eksternal yang mahal.
  • Jika penggunaan transformator kalimat lokal membatasi atau tidak nyaman, ini adalah pengganti yang bagus.

Pilihan akhir: Tidak ditentukan. Saya perlu menyelesaikan pra-pemrosesan terlebih dahulu sebelum memilih antara instruksi atau mpnet

Database vektor

Database yang Ditolak

• Chroma
  • Tidak memiliki opsi penyebaran server. Untuk proyek kecil ini akan selalu menjadi pilihan terbaik meskipun saya pikir.
• Pgvektor
  • Berkinerja sangat buruk dalam tolok ukur untuk beberapa alasan. Mungkin tidak mewakili kinerja dunia nyata. Lihat di sini
  • Jika database POSTRESQL sudah direncanakan untuk digunakan, atau praktis untuk data yang diberikan, saya tidak ragu bahwa pGVector akan menjadi pilihan terbaik. Namun, saya tidak akan menggunakan pustaka pgvector sendiri atau beralih ke postresql untuk itu.
• Elastis
  • Lambat dan kikuk
• Weaviate
  • Saya sebelumnya telah merencanakan untuk mengevaluasi ini, tetapi ketika mencoba mengimplementasikan ini dalam program ini saya memiliki lebih banyak kesulitan dibandingkan dengan yang lainnya.
    • Dokumentasi untuk klien Python tidak hebat sama sekali, itu tidak sulit sulit tetapi kurangnya dokumentasi mengkhawatirkan.
    • Kasing penggunaan saya berencana untuk menggunakan cloud yang dikelola, dan WC membuat saya benar -benar khawatir. Tampaknya tidak ada banyak keamanan, bahkan tidak ada 2FA. Saya secara pribadi tidak mempercayai WCS, dan itu memiliki UI terburuk dibandingkan dengan database lainnya.
    • Jika direncanakan untuk digunakan dalam wadah Docker, Weaviate harus dipertimbangkan kembali dan diberi bidikan yang adil tetapi untuk saat ini saya tidak terus mengevaluasinya.

Sedang menyelidiki

• Pinecone
• Milvus
• Qdrant

Pertimbangan dari seluruh proses

• PDF memiliki begitu banyak sampah dan sebagian besar loader memakannya. Untuk pengupasan teks dari PDF, ada banyak sampah terutama saat menggunakan solusi membaca dari Langchain atau llama_index. Tidak memiliki kendali atas proses itu membuatnya lebih sulit daripada membuat direktori khusus PDF loader.
  • Saya pikir hampir semua format lain lebih unggul daripada PDF untuk membaca dari sejumlah besar data. Begitu banyak masalah dengan pengkodean, karakter sampah dan teks merusak PDF yang tidak dapat dibaca dan mengganggu pipa.
• Data teks dapat disimpan di semua database vektor jika diperlukan. Ini secara drastis akan menyederhanakan proses penyimpanan. Banyak database vektor akan memungkinkan ini dalam bentuk metadata, tetapi tidak memungkinkan penyimpanan teks yang terpisah yang bisa menjadi masalah. Teks terlalu besar dan intensif memori untuk juga disimpan dalam memori, dan metadata dapat disimpan pada disk tetapi kemudian pemfilteran metadata tidak akan tersedia.
  • Jika database vektor tidak menangani ini dengan benar, proses unggahan vektor dapat disederhanakan dengan hanya mengunggah vektor dan ID. Saat pencarian semantik dilakukan, cari basis data lokal atau NoSQL dari ID terkait.