วงการฐานข้อมูลโอเพนซอร์สมีผู้เล่นรายใหม่กับการเปิดตัวของ HelixDB ซึ่งเป็นฐานข้อมูลแบบ graph-vector ที่เขียนด้วยภาษา Rust ออกแบบมาเฉพาะสำหรับ RAG (Retrieval Augmented Generation) และแอปพลิเคชัน AI สิ่งที่ดึงดูดความสนใจของชุมชนคือการกล่าวอ้างเรื่องประสิทธิภาพที่โดดเด่นและแนวทางที่เป็นเอกลักษณ์ในการผสมผสานฟังก์ชันการทำงานของ graph และ vector
 |
|---|
| หน้า GitHub ของ HelixDB นี้แสดงให้เห็นโครงสร้างของมันในฐานะฐานข้อมูลกราฟ-เวกเตอร์แบบโอเพนซอร์สสำหรับแอปพลิเคชัน AI |
การกล่าวอ้างเรื่องประสิทธิภาพที่สร้างความสงสัย
ทีมพัฒนา HelixDB อ้างว่าฐานข้อมูลของพวกเขาเร็วกว่า Neo4j 1000 เท่าและเร็วกว่า TigerGraph 100 เท่า ในขณะที่มีประสิทธิภาพเทียบเท่ากับ Qdrant สำหรับ vectors การกล่าวอ้างนี้ทำให้สมาชิกในชุมชนขอหลักฐาน โดยมีผู้ใช้คนหนึ่งถามตรงๆ ถึงการทดสอบประสิทธิภาพเพื่อสนับสนุนข้อกล่าวอ้างเหล่านี้ ทีม HelixDB ยอมรับว่าพวกเขาได้ทำการทดสอบประสิทธิภาพแล้ว แต่ยังไม่ได้เผยแพร่ก่อนการประกาศโครงการ และสัญญาว่าจะเพิ่มข้อมูลประสิทธิภาพโดยละเอียดในเอกสารประกอบ
คุณสมบัติหลักของ HelixDB
- รวดเร็วและมีประสิทธิภาพ: อ้างว่าเร็วกว่า Neo4j 1000 เท่า, เร็วกว่า TigerGraph 100 เท่า, และมีความเร็วเทียบเท่ากับ Qdrant สำหรับข้อมูลเวกเตอร์
- ออกแบบมาเพื่อ RAG: รองรับข้อมูลประเภทกราฟและเวกเตอร์โดยเฉพาะ
- การผสมผสานกราฟและเวกเตอร์: รองรับความสัมพันธ์ระหว่างโหนด, เวกเตอร์, หรือทั้งโหนดและเวกเตอร์
- การจัดเก็บข้อมูล: ขับเคลื่อนด้วย LMDB (Lightning Memory-Mapped Database)
- รองรับ ACID: รับประกันความสมบูรณ์และความสอดคล้องของข้อมูล
- มิติเวกเตอร์: ปัจจุบันไม่มีการจำกัด แต่ในอนาคตอาจจะจำกัดที่ประมาณ 64,000 มิติ
- ภาษาสำหรับคิวรี: DSL แบบกำหนดเองพร้อมการตรวจสอบประเภทข้อมูล
- ใบอนุญาต: AGPL (Affero General Public License)
ความสามารถด้าน Vector และมิติ
ฐานข้อมูลนี้ดูเหมือนจะมีการรองรับ vector ที่แข็งแกร่ง โดยนักพัฒนายืนยันว่าปัจจุบันไม่มีการจำกัดมิติของ vector พวกเขากล่าวว่าในอนาคตอาจจะมีการกำหนดขีดจำกัดที่ประมาณ 64,000 มิติ คล้ายกับฐานข้อมูล vector อื่นๆ เช่น Qdrant และ Pinecone ทีมยังเปิดเผยแผนการที่จะใช้ binary quantization ในอีกไม่กี่เดือนข้างหน้าเพื่อปรับปรุงประสิทธิภาพกับ vector ที่มีมิติสูงขึ้น แสดงให้เห็นถึงความตระหนักในการแลกเปลี่ยนประสิทธิภาพที่เกี่ยวข้องกับการดำเนินการ vector
การผสมผสาน Graph-Vector ที่ทำให้แตกต่าง
สิ่งที่ทำให้ HelixDB แตกต่างจากคู่แข่งเช่น KuzuDB คือแนวทางในการผสมผสานฟังก์ชันการทำงานของ graph และ vector ตามที่นักพัฒนากล่าว HelixDB รองรับการทำ incremental indexing บน vector ซึ่งอนุญาตให้มีการอัปเดตโดยไม่จำเป็นต้องทำการ re-indexing ของ vector ทั้งหมด นี่แก้ปัญหาที่มีอยู่ในบางโซลูชันที่มีอยู่ซึ่ง vector index แยกออกจากโครงสร้าง graph อย่างสมบูรณ์ ซึ่งต้องการการ re-indexing ทั้งหมดเมื่อมีการอัปเดต
Pretty much the same way you would with any graph DB, with the added benefit of being able to treat a vector as a node by creating those explicit relationships between them.
ภาษาคิวรี่ที่กำหนดเองสร้างการถกเถียง
ภาษาคิวรี่ที่กำหนดเองของ HelixDB ได้สร้างปฏิกิริยาที่หลากหลาย ผู้ใช้บางคนแสดงความกังวลเกี่ยวกับการต้องเรียนรู้ภาษาเฉพาะทาง (DSL) ใหม่ โดยเฉพาะอย่างยิ่งเกี่ยวกับความสามารถในการใช้งานกับ LLM สำหรับการสร้างคิวรี่ นักพัฒนาได้ปกป้องทางเลือกนี้ โดยอธิบายว่าไม่มีภาษาที่มีอยู่ใดที่รวมฟังก์ชันการทำงานของ graph และ vector ได้อย่างเหมาะสม และพวกเขาต้องการสร้างภาษาคิวรี่ที่มีความปลอดภัยในเรื่องประเภท (type-safe) พวกเขากล่าวว่ากำลังทำงานเพื่อรวมไวยากรณ์ของพวกเขาเข้ากับโค้ด LLaMa CPP เพื่อให้แน่ใจว่า LLM สามารถสร้างคิวรี่ที่ถูกต้องตามหลักไวยากรณ์ในภาษาของพวกเขา
ความเข้ากันได้กับเบราว์เซอร์และการใช้งานแบบฝังตัว
ผู้ใช้หลายคนสอบถามเกี่ยวกับการเรียกใช้ HelixDB ในเบราว์เซอร์ผ่าน WebAssembly (WASM) สำหรับแอปพลิเคชันที่เน้นความเป็นส่วนตัวและเกี่ยวกับการใช้งานเป็นฐานข้อมูลแบบฝังตัวคล้ายกับ SQLite ทีมยอมรับว่า LMDB ซึ่งเป็นเครื่องมือจัดเก็บข้อมูลปัจจุบันของพวกเขา เป็นอุปสรรคต่อความเข้ากันได้กับเบราว์เซอร์ แต่กล่าวว่าพวกเขามีแผนที่จะพัฒนาเครื่องมือจัดเก็บข้อมูลของตัวเองที่รองรับ WASM ในขณะนี้ HelixDB ไม่สามารถทำงานเป็นฐานข้อมูลแบบฝังตัวได้ ซึ่งจำกัดกรณีการใช้งานที่เป็นไปได้บางอย่าง
รายการแผนงาน
- การขยายความสามารถของประเภทข้อมูลเวกเตอร์สำหรับแอปพลิเคชัน RAG
- การปรับปรุงภาษาคิวรีด้วยการตรวจสอบประเภทที่แข็งแกร่งมากขึ้น
- การใช้งานชุดทดสอบสำหรับการทดสอบคิวรีแบบครบวงจร
- การสร้างเครื่องมือทดสอบการจำลองแบบกำหนดได้
- การเพิ่มการบีบอัดแบบไบนารีเพื่อประสิทธิภาพที่ดีขึ้น
- การใช้งาน BM25 สำหรับการค้นหาแบบสปาร์ส
- การพัฒนาเครื่องมือจัดเก็บกราฟ-เวกเตอร์ภายในองค์กร (เพื่อทดแทน LMDB)
- การสร้างโปรโตคอลเครือข่ายและไลบรารีการแปลงข้อมูลภายในองค์กร
การพัฒนาในอนาคตและแผนงาน
ทีม HelixDB ได้วางแนวทางฟีเจอร์ที่กำลังจะมาถึงหลายอย่าง รวมถึงการค้นหาแบบ sparse โดยใช้ BM25 โดยมีสมาชิกในชุมชนบางคนแนะนำให้พิจารณาโมเดล SPLADE สำหรับความสามารถในการค้นหาที่เพิ่มขึ้น แผนงานของพวกเขายังรวมถึงการขยายความสามารถด้าน vector การเพิ่มประสิทธิภาพภาษาคิวรี่ การใช้งานชุดทดสอบ การสร้างเครื่องมือทดสอบการจำลองแบบกำหนดได้ และในที่สุดก็พัฒนาเครื่องมือจัดเก็บข้อมูล graph-vector ของตัวเองเพื่อแทนที่ LMDB
เมื่อ HelixDB เข้าสู่พื้นที่การแข่งขันที่เพิ่มขึ้นของฐานข้อมูล vector และ graph การกล่าวอ้างเรื่องประสิทธิภาพและแนวทางที่เป็นเอกลักษณ์ในการรวมฟังก์ชันการทำงานเหล่านี้ได้ดึงดูดความสนใจอย่างแน่นอน ชุมชนดูเหมือนจะมีความหวังอย่างระมัดระวัง โดยหลายคนแสดงความสนใจที่จะลองใช้ฐานข้อมูลและให้ข้อเสนอแนะ ยังไม่ชัดเจนว่า HelixDB จะแตกต่างจากผู้เล่นที่มีอยู่และผู้มาใหม่รายอื่นๆ ในระยะยาวอย่างไร แต่การมุ่งเน้นที่ประสบการณ์ของนักพัฒนาและประสิทธิภาพสำหรับแอปพลิเคชัน AI ดูเหมือนจะได้รับการตอบรับที่ดีจากผู้ใช้ที่มีศักยภาพ
อ้างอิง: HelixDB/helix-db