Vector DB Testing

ดูเกณฑ์มาตรฐาน

วิธีใช้

• ตรวจสอบให้แน่ใจว่ามีการติดตั้งแพ็คเกจที่เหมาะสม ตรวจสอบให้แน่ใจว่ามีการติดตั้งต่อไปนี้: sentence_transformers tqdm pandas pypdf2 torch asyncio พร้อมกัน re qdrant_client pinecone pymilvus dotenv
• อัปโหลด PDF ทั้งหมดเข้าสู่ /data /หรือไดเรกทอรีอื่น ๆ หากระบุ
  • หากคุณมีไฟล์ข้อมูลเมตาสำหรับข้อมูลเพิ่มเติมเกี่ยวกับไฟล์ PDF ให้อัปโหลดไปยังไดเรกทอรีที่บ้านและตั้งชื่อมัน metadata.csv หรือเปลี่ยนชื่อ รหัสน่าจะต้องมีการเปลี่ยนแปลงใน get_metadata () ใน macloader เพื่อรองรับไฟล์เมตาดาต้าเฉพาะของคุณ
• รายละเอียดการเชื่อมต่ออินพุตใน. env ดู. env ตัวอย่างสำหรับสิ่งที่. env ของคุณควรมีลักษณะ
  • สิ่งนี้สามารถหลีกเลี่ยงได้หากคุณต้องการป้อนรายละเอียดเป็นส่วนหนึ่งของการเริ่มต้น DB ในรหัสแทน
• สร้างไฟล์ Python ดัชนี จากที่นี่ฉันจะกำหนดการบันทึกที่เหมาะสม ด้วยข้อมูลทั้งหมดสิ่งสำคัญคือต้องระวังปัญหาใด ๆ การบันทึกทั้งหมดมีชื่ออย่างเหมาะสมโดยใช้ข้อมูลคำเตือนข้อผิดพลาดและวิกฤต
• สร้าง delete.txt อย่าใส่อะไรไว้ในนั้น
• นำเข้าไฟล์ที่เหมาะสมจากโครงการและเริ่มต้นด้วยรายละเอียดที่เหมาะสม พารามิเตอร์ที่มีอยู่ทั้งหมดได้รับการบันทึกไว้อย่างดีและควรแสดงโดย IDE ของคุณผ่านการโฮเวอร์หรือคลิก
  • ตัวอย่าง: from Loader import MacLoader & from databases.PineconeDB import PineconeDB
• หลังจากทำการเรียกใช้ไฟล์ของคุณให้ตรวจสอบ delete.txt และดูว่าไฟล์ใดที่ให้ปัญหากับตัวอ่าน PYPDF2 หากคุณต้องการลบไฟล์เหล่านี้ให้ใช้ utility.delete_bad_pdfs ()
• สนุกแจ้งให้เราทราบวิธีปรับปรุงกระบวนการนี้!

ประเด็นสำคัญ

การประมวลผลล่วงหน้า

LLAMA_INDEX นั้นยอดเยี่ยม แต่ความน่าเชื่อถือของโหนดเป็นอุปสรรคที่แท้จริง TextNodes ดูเหมือนจะมีประโยชน์มาก แต่ด้วยข้อมูลที่ไม่จำเป็นมากมายที่คุณอัปโหลดด้วยเวกเตอร์ของคุณซึ่งเพิ่งใช้พื้นที่จัดเก็บและประสิทธิภาพ เนื่องจากเหตุผลนี้เพียงอย่างเดียว LLAMA_INDEX จึงไม่ควรใช้สำหรับกระบวนการอัพโหลดเวกเตอร์ที่ซับซ้อน ข้อมูลพิเศษนั้นมากเกินไปเมื่ออยู่ในชุดข้อมูลระดับการผลิต ฉันยังไม่ชอบว่ามันน่ารำคาญที่จะเขียนโค้ดด้วยบางครั้งกฎแปลก ๆ และขั้นตอนที่ไม่จำเป็น TextNodes อาจเป็นสินทรัพย์ที่มีประสิทธิภาพหากทุกอย่างได้รับการจัดการอย่างถูกต้องด้วยข้อมูลพิเศษทั้งหมดที่ถูกจัดเก็บไว้ในเครื่องและไม่ขัดขวางความเร็วในการดึงข้อมูลหรือหน่วยความจำ

Langchain ทำให้วิธีที่ง่ายขึ้นในการเชื่อมต่อข้อมูลที่มีกฎน้อยลง (ขึ้นอยู่กับบริบท) ฉันไม่คิดว่า Langchain จะพร้อมการผลิตและควรใช้เทปยึดแทน การมีการควบคุมอย่างเต็มที่ในกระบวนการทั้งหมดอาจเป็นที่ต้องการเช่นกันในสภาพแวดล้อมการผลิต

โดยรวมแล้วฉันไม่สามารถหาสิ่งที่เหมาะกับมันได้อย่างง่ายดายตามที่ฉันต้องการ นี่คือความเข้าใจของฉันว่าฉันคิดว่ากระบวนการนี้ควรไปอย่างไร:

ในขณะที่เสร็จสิ้นโปรแกรมนี้ฉันรู้ว่ามันเป็นเพียงการแทนที่เครื่องมือสองตัวข้างต้น เครื่องมือทั้งสองข้างต้นมีไว้เพื่อนำไปใช้กับกรณีการใช้งานทั้งหมดฉันเพิ่งเขียนรหัสเฉพาะกับฉัน

ฝัง / หม้อแปลงไฟฟ้า

การเลือกหม้อแปลงประโยคนั้นไม่ยากเกินไป

• ทั้งหมดมิลม์-V2 นั้นดีและรวดเร็ว แต่ฉันกังวลเกี่ยวกับความสามารถในการปรับขนาดด้วยข้อมูลจำนวนมาก ไม่ใช่สิ่งที่แม่นยำที่สุด แต่ก็ยังดีไม่ใช่เพื่อการผลิต

• E5-Large-V2 ล้มเหลวในการดึงข้อมูลพื้นฐานในขนาดเล็กในการทดสอบของฉัน ด้วยเหตุนี้ฉันจะไม่พิจารณาในระดับที่ใหญ่กว่าเช่นกัน

• ทุกอย่างใช้เวลานานขึ้นด้วยการฝัง ผู้สอน แต่พวกเขาน่าจะให้ความแม่นยำของข้อมูลที่ดีขึ้นมาก ฉันยังไม่ได้ทดสอบสิ่งเหล่านี้อย่างถูกต้อง

• All-MPNET-V2 นั้นดีที่สุดในแง่ของความเร็วและประสิทธิภาพอาจไม่แม่นยำเท่ากับการฝังผู้สอน แต่ความเร็วและประสิทธิภาพอาจเป็นที่ต้องการในสภาพแวดล้อมการผลิต

• ADA (OpenAI) EMBEDDINGS จะมีราคาแพงกว่าหม้อแปลงประโยคท้องถิ่นทั่วไป ในอดีตฉันมีปัญหาในการประมวลผลชุดข้อมูลขนาดใหญ่เนื่องจากการ จำกัด อัตราและข้อ จำกัด อื่น ๆ ที่กำหนดโดยแบบจำลองของพวกเขา การมีข้อมูลที่ส่งเป็นชิ้นจะช่วยแก้ปัญหานี้ได้

  • มันเป็นสิ่งสำคัญที่จะต้องพิจารณาว่า ADA ฝังในมิติ 1536 เช่นกัน สิ่งนี้จะนำไปสู่เวลาการค้นหาความหมายที่สูงขึ้นเนื่องจากคณิตศาสตร์พิเศษที่จำเป็นสำหรับมิติที่มากขึ้น อีกครั้งสิ่งนี้จะนำไปสู่ความแม่นยำที่สูงขึ้นเช่นกัน แต่รุ่นอื่น ๆ ก็สามารถทำการฝังมิติที่สูงได้โดยไม่ต้องใช้ API ภายนอกที่มีราคาแพง
  • หากการใช้หม้อแปลงประโยคท้องถิ่น จำกัด หรือไม่สะดวกนี่เป็นสิ่งทดแทนที่ดี

ตัวเลือกสุดท้าย: ไม่ได้กำหนด ฉันต้องเสร็จสิ้นการประมวลผลล่วงหน้าก่อนที่จะเลือกระหว่างคำแนะนำหรือ mpnet

ฐานข้อมูลเวกเตอร์

ฐานข้อมูลที่ถูกปฏิเสธ

• โครมา
  • ขาดตัวเลือกการปรับใช้เซิร์ฟเวอร์ สำหรับโครงการขนาดเล็กนี่จะเป็นตัวเลือกที่ดีที่สุดเสมอแม้ว่าฉันจะคิด
• pgvector
  • ดำเนินการได้ไม่ดีในการเปรียบเทียบด้วยเหตุผลบางอย่าง อาจไม่ใช่ตัวแทนของการแสดงในโลกแห่งความเป็นจริง ดูที่นี่
  • หากฐานข้อมูล PostresQL มีการวางแผนที่จะใช้งานแล้วหรือเป็นประโยชน์สำหรับข้อมูลที่กำหนดฉันไม่สงสัยเลยว่า PGVector จะเป็นตัวเลือกที่ดีที่สุด อย่างไรก็ตามฉันจะไม่ใช้ไลบรารี PGVector ด้วยตัวเองหรือเปลี่ยนเป็น postresQl สำหรับมัน
• ยืดหยุ่น
  • ช้าและเฉื่อยชา
• ทอผ้า
  • ก่อนหน้านี้ฉันได้วางแผนที่จะประเมินสิ่งนี้ แต่ในขณะที่พยายามใช้สิ่งนี้ในโปรแกรมนี้ฉันมีปัญหามากขึ้นเมื่อเทียบกับคนอื่น ๆ ทั้งหมด
    • เอกสารสำหรับไคลเอนต์ Python นั้นไม่ค่อยดีเลย แต่มันก็ไม่ยาก แต่การขาดเอกสารเป็นกังวล
    • กรณีการใช้งานของฉันกำลังวางแผนที่จะใช้คลาวด์ที่มีการจัดการและ WCS ทำให้ฉันกังวลจริงๆ ดูเหมือนจะไม่มีความปลอดภัยมากนักไม่มีแม้แต่ 2FA ฉันไม่ไว้วางใจ WCS เป็นการส่วนตัวและมันมี UI ที่แย่ที่สุดเมื่อเทียบกับฐานข้อมูลอื่น ๆ
    • หากวางแผนที่จะใช้ในคอนเทนเนอร์ Docker ควรทอผ้าใหม่และได้รับการยิงที่ยุติธรรม แต่ตอนนี้ฉันไม่ได้ประเมินมันต่อไป

กำลังสอบสวน

• Pinecone
• Milvus
• qdrant

ข้อพิจารณาจากกระบวนการทั้งหมด

• PDF มีขยะมากมายและรถตักส่วนใหญ่กินมันขึ้นมา สำหรับการลอกข้อความจาก PDF มีขยะมากมายโดยเฉพาะอย่างยิ่งเมื่อใช้วิธีการอ่านจาก Langchain หรือ Llama_Index การไม่สามารถควบคุมกระบวนการนั้นได้ยากกว่าที่จะทำโหลดไดเรกทอรี PDF แบบกำหนดเอง
  • ฉันคิดว่ารูปแบบอื่น ๆ เกือบจะดีกว่า PDFs สำหรับการอ่านจากข้อมูลจำนวนมาก ปัญหามากมายเกี่ยวกับการเข้ารหัสอักขระขยะและข้อความทำลายของ PDF ที่ไม่สามารถอ่านได้และติดขัดไปป์ไลน์
• ข้อมูลข้อความสามารถเก็บไว้ในฐานข้อมูลเวกเตอร์ทั้งหมดหากจำเป็น สิ่งนี้จะทำให้กระบวนการจัดเก็บง่ายขึ้นอย่างมาก ฐานข้อมูลเวกเตอร์จำนวนมากจะอนุญาตให้มีสิ่งนี้ในรูปแบบของข้อมูลเมตา แต่ไม่อนุญาตให้จัดเก็บข้อความแยกต่างหากซึ่งอาจเป็นปัญหา ข้อความมีขนาดใหญ่เกินไปและหน่วยความจำที่ต้องเก็บไว้ในหน่วยความจำและข้อมูลเมตาสามารถเก็บไว้ในดิสก์ได้ แต่จากนั้นการกรองข้อมูลเมตาจะไม่สามารถใช้ได้
  • หากฐานข้อมูลเวกเตอร์ไม่สามารถจัดการกับสิ่งนี้ได้อย่างถูกต้องกระบวนการอัปโหลดเวกเตอร์อาจง่ายขึ้นโดยอัปโหลดเฉพาะเวกเตอร์และ ID เท่านั้น เมื่อทำการค้นหาความหมายให้ค้นหาฐานข้อมูลท้องถิ่นหรือ NOSQL จาก ID ที่เกี่ยวข้อง