การเปิดตัวของ Vectroid ซึ่งเป็น vector database แบบ serverless ใหม่ ได้จุดประกายการอภิปรายที่น่าสนใจในชุมชนนักพัฒนาเกี่ยวกับสถานการณ์ที่กระจัดกระจายของเทคโนโลยี vector search ในขณะที่ Vectroid สัญญาว่าจะแก้ไขปัญหาการแลกเปลี่ยนแบบดั้งเดิมระหว่างความเร็ว ความแม่นยำ และต้นทุน นักพัฒนากำลังตั้งคำถามใหญ่เกี่ยวกับแนวทางของอุตสาหกรรมในการสร้าง vector database
การเรียกร้อง Universal Vector Engine
การอภิปรายที่น่าสนใจที่สุดที่เกิดขึ้นจากการประกาศของ Vectroid มุ่งเน้นไปที่การขาดไลบรารี vector search แบบมาตรฐานที่สามารถฝังตัวได้ นักพัฒนาชี้ให้เห็นว่าภูมิทัศน์ปัจจุบันบังคับให้ทีมต้องเลือกระหว่างการรวมความสามารถ vector เข้ากับฐานข้อมูลที่มีอยู่เช่น PostgreSQL หรือสร้างระบบแยกต่างหากทั้งหมดเช่น Milvus และตอนนี้ Vectroid
ชุมชนกำลังเรียกร้องสิ่งที่คล้ายกับ Apache DataFusion ซึ่งเป็นไลบรารีที่ทำหน้าที่เป็น IR ของฐานข้อมูลแต่สำหรับการดำเนินการ vector สิ่งนี้จะช่วยให้ระบบฐานข้อมูลต่างๆ สามารถรวม vector search คุณภาพสูงโดยไม่ต้องคิดค้นอัลกอริทึมหลักใหม่ทุกครั้ง แนวคิดนี้ได้รับความนิยม โดยนักพัฒนาหลายคนชี้ไปที่ไลบรารีที่มีอยู่เช่น USearch และ FAISS เป็นรากฐานที่มีศักยภาพ แม้ว่าสิ่งเหล่านี้จะไม่ค่อยตรงจุดที่เหมาะสมในการเป็นคอมโพเนนต์ที่พร้อมสำหรับฐานข้อมูล
DataFusion: เฟรมเวิร์กการดำเนินการ query ที่ให้ความสามารถในการวางแผนและดำเนินการ SQL query ที่สามารถฝังตัวเข้าไปในระบบอื่นได้
ไลบรารีการค้นหาเวกเตอร์ที่มีอยู่ที่ได้กล่าวถึง
- USearch: ไลบรารี C++11 แบบ single header ที่ใช้ใน DuckDB-VSS extension และ ClickHouse
- FAISS: ไลบรารีของ Facebook Research สำหรับการค้นหาความคล้ายคลึง
- pgvector: PostgreSQL extension สำหรับการดำเนินการเวกเตอร์
- DataFusion: Apache query execution framework (อ้างอิงเป็นแบบจำลองสำหรับไลบรารีเวกเตอร์ที่ต้องการ)
ความท้าทายด้านสถาปัตยกรรมนอกเหนือจากอัลกอริทึม
ในขณะที่การอภิปรายเริ่มต้นด้วยการเรียกร้องไลบรารีที่ดีกว่า นักพัฒนาที่มีประสบการณ์ได้เน้นย้ำอย่างรวดเร็วว่าความท้าทายที่แท้จริงอยู่ที่สถาปัตยกรรมระบบแบบกระจาย อัลกอริทึมหลักเช่น HNSW (Hierarchical Navigable Small Worlds) เป็นที่เข้าใจกันดีแล้ว แต่การคิดออกว่าจะสมดุลต้นทุน ความแม่นยำ และความเร็วในระดับขนาดใหญ่ต้องการการตัดสินใจด้านสถาปัตยกรรมที่ซับซ้อน
แนวทางของ Vectroid ในการแยกการเขียนออกจากการอ่านและปรับขนาดแยกกันแสดงถึงหนึ่งในวิธีแก้ไขความท้าทายเหล่านี้ ทีมงานที่อยู่เบื้องหลัง Vectroid รวมถึงผู้ร่วมก่อตั้งของ Hazelcast ได้สร้างระบบของพวกเขาบน Apache Lucene เวอร์ชันที่ดัดแปลงพร้อมการปรับแต่งแบบกำหนดเองสำหรับ vector workload พวกเขาได้สร้างระบบไฟล์แบบกำหนดเองที่ทำงานโดยตรงกับ Google Cloud Storage โดยข้าม storage layer แบบดั้งเดิมเพื่อประสิทธิภาพที่ดีกว่า
HNSW: อัลกอริทึมแบบกราฟสำหรับการค้นหา approximate nearest neighbor ที่ให้สมดุลที่ดีระหว่างความเร็วและความแม่นยำ
ส่วนประกอบของสถาปัตยกรรมทางเทคนิค
- อัลกอริทึม: HNSW (Hierarchical Navigable Small Worlds) สำหรับการค้นหาเวกเตอร์
- แบ็กเอนด์: Apache Lucene ที่ได้รับการปรับแต่งพร้อมการเพิ่มประสิทธิภาพแบบกำหนดเอง
- การจัดเก็บข้อมูล: การเชื่อมต่อโดยตรงกับ Google Cloud Storage ( S3 จะเปิดให้บริการเร็วๆ นี้)
- การขยายระบบ: ไมโครเซอร์วิสแยกต่างหากสำหรับการอ่านและการเขียน
- โครงสร้างพื้นฐาน: การปรับใช้ Kubernetes ที่จัดการผ่าน Terraform/Helm
- ภาษาโปรแกรม: การใช้งาน Java แบบบริสุทธิ์
การอ้างสิทธิ์ด้านประสิทธิภาพและการตรวจสอบความเป็นจริง
การอ้างสิทธิ์ benchmark ของ Vectroid ได้ดึงดูดทั้งความสนใจและความสงสัย บริษัทรายงานว่าสามารถจัดทำดัชนี vector 1 พันล้านตัวใน 48 นาที และบรรลุ P99 latency 34 มิลลิวินาทีบนชุดข้อมูลขนาดใหญ่ อย่างไรก็ตาม สมาชิกชุมชนกำลังตั้งคำถามว่าคอลเลกชัน vector ขนาดใหญ่มากเช่นนี้มีประโยชน์ในทางปฏิบัติหรือไม่ โดยอ้างอิงงานวิจัยล่าสุดที่ชี้ให้เห็นว่าความแม่นยำของ embedding ลดลงอย่างมีนัยสำคัญในระดับขนาดใหญ่มาก
โครงสร้างต้นทุนก็ทำให้เกิดข้อสงสัยเช่นกัน ในขณะที่ Vectroid อ้างว่าสามารถจัดทำดัชนีชุดข้อมูล Deep1B ในราคาต่ำกว่า 12 ดอลลาร์สหรัฐ โดยใช้ Google Cloud spot instances นักพัฒนาบางคนโต้แย้งว่าสำหรับกรณีการใช้งานหลายๆ กรณี แนวทางที่เรียบง่ายกว่าอาจคุ้มต้นทุนมากกว่าการสร้างระบบแบบกระจายที่ซับซ้อน
เกณฑ์มาตรฐานประสิทธิภาพของ Vectroid
- จัดทำดัชนีเวกเตอร์ 1 พันล้านตัวใน 48 นาที
- P99 latency: 34ms บนชุดข้อมูล MS Marco (เวกเตอร์ 138 ล้านตัว, 1024 มิติ)
- ต้นทุนการจัดทำดัชนี: <$12 USD สำหรับชุดข้อมูล Deep1B โดยใช้ 6x n2-standard-96 spot instances
- รักษาการเรียกคืนข้อมูล >90% ในขณะที่ขยายขนาดไปยัง 10 query threads ต่อวินาที
ความแตกแยกระหว่าง Open Source กับ Proprietary
การประกาศนี้ได้จุดประกายการถกเถียงเกี่ยวกับแนวทาง proprietary เทียบกับ open-source ในพื้นที่ vector database อีกครั้ง สมาชิกชุมชนบางคนแสดงความหงุดหงิดกับโซลูชันแบบ closed-source อีกตัวที่เข้าสู่ตลาดที่มีทางเลือก open อยู่แล้ว อย่างไรก็ตาม ผู้ก่อตั้ง Vectroid โต้แย้งว่าการคงสถานะ closed-source ในช่วงแรกช่วยให้พวกเขาเคลื่อนไหวได้เร็วขึ้น ในขณะที่สัญญาว่าจะมี data portability เพื่อลดความกังวลเรื่อง lock-in
ความตึงเครียดนี้สะท้อนคำถามที่กว้างขึ้นเกี่ยวกับวิธีที่นวัตกรรมเกิดขึ้นในซอฟต์แวร์โครงสร้างพื้นฐาน ในขณะที่โซลูชัน open-source ให้ความโปร่งใสและการมีส่วนร่วมของชุมชน โซลูชัน proprietary มักจะเคลื่อนไหวได้เร็วกว่าและสามารถสนับสนุนความพยายามในการปรับแต่งที่ก้าวร้าวมากขึ้น
บทสรุป
การเปิดตัว Vectroid ได้กลายเป็นตัวเร่งสำหรับการอภิปรายที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับทิศทางอนาคตของระบบนิเวศ vector database ว่าอุตสาหกรรมต้องการไลบรารีมาตรฐานที่ดีกว่า นวัตกรรมด้านสถาปัตยกรรมมากขึ้น หรือเพียงแค่การปรับแต่งแนวทางที่มีอยู่ให้ดีขึ้น ยังคงเป็นคำถามที่เปิดอยู่ สิ่งที่ชัดเจนคือขณะที่แอปพลิเคชัน AI ขับเคลื่อนความต้องการสำหรับ vector search ชุมชนกำลังแสวงหาโซลูชันที่ไม่บังคับให้เกิดการแลกเปลี่ยนที่เจ็บปวดระหว่างประสิทธิภาพ ต้นทุน และความแม่นยำอย่างแข็งขัน
อ้างอิง: Why & how we built Vectroid