กำลังพัฒนา sqlite-vec ส่วนขยายค้นหาเวกเตอร์ใหม่สำหรับ SQLite

 (alexgarcia.xyz)
3 คะแนน โดย GN⁺ 2024-05-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพื่อแก้ข้อจำกัดของ sqlite-vss เดิม sqlite-vec กำลังถูกพัฒนาเป็น ส่วนขยายค้นหาเวกเตอร์แบบฝังตัว ที่ใช้ C ล้วน โดยมุ่งรองรับทุกสภาพแวดล้อมที่ SQLite ทำงานได้
  • โฟลว์การใช้งาน SQL ถูกทำให้ง่ายขึ้นโดยเน้น CREATE VIRTUAL TABLE, INSERT INTO, SELECT และรองรับ การค้นหาแบบ KNN รวมถึงอินพุตเวกเตอร์แบบ JSON และ compact binary
  • ตัดการพึ่งพา Faiss ออกไป จึงตั้งเป้ารองรับไม่เพียง Linux และ macOS แต่ยังรวมถึง Windows, WebAssembly, อุปกรณ์มือถือ และ Raspberry Pi พร้อมคาดว่าขนาดไบนารีจะอยู่ในระดับ หลายร้อย KB ซึ่งเล็กกว่าเดิมที่ 3MB~5MB
  • จัดเก็บเวกเตอร์เป็นหน่วย chunk ใน shadow table เพื่อลดความจำเป็นในการโหลดทั้งหมดขึ้น RAM และสามารถใช้ PRAGMA mmap_size เพื่อเพิ่มความเร็วการค้นหาบนหน่วยความจำได้
  • เวอร์ชันแรกจะมีเพียง exhaustive full-scan และยังไม่มี ANN โดยมีกำหนดปล่อย v0.1.0 หลังจากทำ TODO 246 รายการ ใน sqlite-vec.c เสร็จ

การค้นหาเวกเตอร์ใน SQLite ที่ sqlite-vec ต้องการเปลี่ยนแปลง

  • sqlite-vec เป็น ส่วนขยาย SQLite ใหม่ที่เขียนด้วย C ล้วน และเป็นโปรเจกต์ที่ตั้งใจมาแทนที่ sqlite-vss ซึ่งเปิดตัวในเดือนกุมภาพันธ์ 2023
  • ขอบเขตเป้าหมายครอบคลุมฟังก์ชัน SQL ที่ผู้ใช้กำหนดเองสำหรับการค้นหาเวกเตอร์ที่รวดเร็ว, virtual table, รวมถึงเครื่องมือและยูทิลิตีสำหรับงานเวกเตอร์
    • quantization
    • การแปลง JSON/BLOB/numpy
    • เลขคณิตเวกเตอร์
  • ผู้ใช้สามารถสร้างและค้นหา vector store ได้ด้วย SQL ล้วน
    • สร้าง virtual table สำหรับเวกเตอร์ด้วย CREATE VIRTUAL TABLE
    • แทรกเวกเตอร์ด้วย INSERT INTO
    • ค้นหาแบบ KNN ในรูป SELECT ... WHERE sample_embedding MATCH ... ORDER BY distance LIMIT ...
  • อินพุตเวกเตอร์สามารถใช้ได้ทั้ง สตริง JSON หรือรูปแบบ compact binary

C ล้วนและไร้ dependency เปิดทางสู่สภาพแวดล้อมการรันที่กว้างขึ้น

  • sqlite-vec ตั้งเป้าเป็นส่วนขยายแบบ C ล้วนไร้ dependency และทางเลือกนี้คือเงื่อนไขสำคัญที่ทำให้รองรับแพลตฟอร์มได้กว้างขึ้น
  • sqlite-vss เดิมมี dependency บน C++ จึงทำงานได้เสถียรเฉพาะบน Linux และ macOS และมีขนาดไบนารีอยู่ในช่วง 3MB~5MB
  • ส่วนขยายใหม่นี้ตั้งเป้าทำงานในสภาพแวดล้อมต่อไปนี้
    • Linux
    • macOS
    • Windows
    • WebAssembly ในเบราว์เซอร์
    • อุปกรณ์มือถือ
    • อุปกรณ์ขนาดเล็กอย่าง Raspberry Pi
  • ขนาดไบนารีที่คาดไว้คือระดับ หลายร้อย KB

การควบคุมการใช้หน่วยความจำและความเร็วในการค้นหา

  • sqlite-vec ควบคุมการใช้หน่วยความจำด้วยการแบ่งเก็บเวกเตอร์เป็น chunk ภายใน shadow table
    • ระหว่างการค้นหา KNN จะอ่านเป็นหน่วย chunk โดยไม่ต้องโหลดเวกเตอร์ทั้งหมดขึ้น RAM พร้อมกัน
    • ไม่จำเป็นต้องให้เวกเตอร์ทั้งหมดค้างอยู่ในหน่วยความจำ
  • หากต้องการความเร็วแบบอิงหน่วยความจำ สามารถใช้ PRAGMA mmap_size ของ SQLite เพื่อทำให้การค้นหา KNN เร็วขึ้นได้

ฟีเจอร์เวกเตอร์ใหม่และข้อจำกัดช่วงแรก

  • sqlite-vec ต้องการรองรับฟีเจอร์ต่อไปนี้ให้ดีขึ้น โดยสะท้อนทิศทางของเครื่องมือและงานวิจัยด้านการค้นหาเวกเตอร์ล่าสุด
  • ฟีเจอร์เหล่านี้เป็นพื้นฐานสำหรับการปรับ ความเร็ว, ความแม่นยำ, และการใช้พื้นที่ดิสก์ ของเวกเตอร์ได้ละเอียดขึ้น
  • sqlite-vec เวอร์ชันแรกจะรองรับเฉพาะการค้นหาเวกเตอร์แบบ exhaustive full-scan
    • ช่วงแรกจะไม่มีตัวเลือก “approximate nearest neighbors”
    • IVF และ HNSW เป็นฟีเจอร์ที่หวังว่าจะเพิ่มในอนาคต

องค์ประกอบของเดโมบนเบราว์เซอร์

  • เดโมใช้ sqlite-vec ที่รันในเบราว์เซอร์
  • องค์ประกอบที่ตรวจสอบได้จากเครื่องมือนักพัฒนามีดังนี้
  • ใน movies.bit.db มี overview ของภาพยนตร์ 4,800 เรื่องในตาราง articles โดยอิงจาก เมทาดาทาภาพยนตร์ TMDB
  • virtual table แยกชื่อ vec_movies คือดัชนีเวกเตอร์ของ embedding จาก overview เหล่านั้น

ข้อมูลเดโมและโฟลว์การค้นหา KNN

  • ตาราง articles มีคอลัมน์อย่าง title, release_date, overview
  • คอลัมน์ overview เก็บเนื้อเรื่องย่อของภาพยนตร์เป็นประโยคสั้น ๆ และถูกใช้เป็นเป้าหมายสำหรับ embedding ในเดโม
  • virtual table vec_movies เก็บ embedding ของ articles.overview ไว้ในคอลัมน์ overview_embeddings
    • เวกเตอร์เป็น binary vector 768 มิติ
    • ขนาดการจัดเก็บคือ 768 / 8 = 96 หรือ 96 ไบต์
  • เมื่อผู้ใช้เลือกภาพยนตร์ด้วยปุ่ม radio ID ภาพยนตร์ที่เลือกจะถูกเติมลงในพารามิเตอร์ :selected_movie ของคิวรี SQL แบบ KNN
  • ผลการค้นหาคือภาพยนตร์ 10 เรื่องที่ใกล้กับภาพยนตร์ที่เลือกมากที่สุด
    • เนื่องจากเป็น binary vector จึงใช้ hamming distance ในการคำนวณระยะทาง
    • ผลลัพธ์ที่ใกล้ที่สุดจะเป็นภาพยนตร์เรื่องเดียวกันเสมอ และมีระยะทางเป็น 0
  • ผลจากการทำ embedding ให้เรื่องย่อสั้น ๆ และชุดข้อมูลภาพยนตร์ขนาดเล็กไม่ได้มีคุณภาพสูงสุด อีกทั้ง binary quantization ก็ยอมลดคุณภาพลงอีก แต่จุดเน้นคือการแสดงให้เห็นการค้นหาเวกเตอร์ที่เร็วและ “ดีพอ” ภายในเบราว์เซอร์
  • หากต้องการตรวจสอบการทำงานภายใน ให้เติม EXPLAIN QUERY PLAN หน้า SELECT แล้วจะเห็น “index” 0:knn ที่ vec_movies ใช้

ข้อจำกัดของ sqlite-vss และ dependency บน Faiss

  • การพัฒนาและการนำ sqlite-vss ไปใช้มีอุปสรรคหลายอย่าง
    • ทำงานได้เฉพาะบน Linux และ macOS ไม่รองรับ Windows, WASM, อุปกรณ์มือถือ ฯลฯ
    • เก็บเวกเตอร์ทั้งหมดไว้ ในหน่วยความจำ
    • มีบั๊กและปัญหาเกี่ยวกับ transaction
    • คอมไพล์ยากมากและใช้เวลานาน
    • ขาดงานเวกเตอร์ทั่วไปอย่าง scalar/binary quantization
  • ปัญหาเกือบทั้งหมดนี้มีต้นตอมาจาก dependency บน Faiss
  • บางปัญหาอาจแก้ได้หากทุ่มเวลาและความพยายามมากพอ แต่หลายปัญหาอาจติดข้อจำกัดเพราะ Faiss
  • โซลูชันระดับต่ำที่ไร้ dependency จึงกลายเป็นทางเลือกที่น่าสนใจ และ sqlite-vec ก็เริ่มต้นขึ้นจากการมองว่าการค้นหาเวกเตอร์เองไม่ได้ซับซ้อนมากนัก

สถานะการปล่อยเวอร์ชันและการขอสปอนเซอร์

  • ฟีเจอร์หลักของ sqlite-vec ทำงานได้แล้ว แต่การจัดการข้อผิดพลาดและการทดสอบยังขาดอยู่มาก
  • ไฟล์ sqlite-vec.c ยังมี TODO 246 รายการ เหลืออยู่
    • todo_assert() 191 จุด
    • คอมเมนต์ // TODO 41 จุด
    • todo panic 14 จุด
    • ความคืบหน้ารวมแสดงเป็น 0/246, 0% สำหรับ sqlite-vec v0
  • เมื่อ TODO 246 รายการเสร็จ จะมีการปล่อย v0.1.0 รุ่นแรก
    • เอกสาร
    • เดโม
    • binding
    • องค์ประกอบอื่น ๆ จะถูกจัดมาให้พร้อมกัน
  • เป้าหมายเวลาอยู่ที่ราวหนึ่งเดือน แต่ยังไม่ใช่กำหนดการที่ยืนยันแล้ว
  • กำลังมองหาสปอนเซอร์จากบริษัทที่สนใจความสำเร็จของ sqlite-vec และสามารถติดต่อสอบถามได้ทางอีเมล

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-04
ความคิดเห็นจาก Hacker News

  • ผมเป็นผู้เขียน — ถ้ามีคำถามก็ถามมาได้เลย นี่มีลักษณะเป็น “กำลังทำโปรเจกต์ใหม่อยู่” มากกว่าจะเป็นรีลีสอย่างเป็นทางการ และตัวส่วนขยายเองก็ยังอยู่ระหว่างพัฒนา ลิงก์โปรเจกต์คือ https://github.com/asg017/sqlite-vec
    ผมมีภาพค่อนข้างชัดเจนว่า v0.1.0 ของส่วนขยายนี้จะหน้าตาเป็นอย่างไร แต่กว่าจะไปถึงจุดนั้นน่าจะต้องใช้อีกสองสามสัปดาห์ บทความนี้มีเป้าหมายหลักเพื่อแจ้งให้ผู้ใช้ sqlite-vss ซึ่งเป็นส่วนขยายค้นหาเวกเตอร์สำหรับ SQLite ที่ผมทำไว้ก่อนหน้านี้รู้ว่าอะไรจะตามมา และเมื่อพร้อมแล้วจะมีรีลีสที่ใหญ่กว่านี้ออกมา
    โดยรวมแล้วผมตื่นเต้นมากที่จะมี ทางเลือกสำหรับการค้นหาเวกเตอร์ ที่ฝังเข้าไปได้ง่าย จุดที่ดีเป็นพิเศษคือมันรันได้บนทุกระบบปฏิบัติการ, WASM, อุปกรณ์มือถือ, Raspberry Pi ฯลฯ และโดยส่วนตัวผมกำลังลองทำแอปค้นหาเชิงความหมายเล็ก ๆ บน Beepy อยู่ เลยสนุกดี
    [0] https://beepy.sqfmi.com/

    • อยากรู้ว่ารองรับ ฟังก์ชันระยะทาง อะไรบ้าง ดูเหมือนว่าจะรองรับเวกเตอร์ไบนารีแล้ว เลยอยากรู้ว่ารองรับ Hamming distance ด้วยหรือไม่
      และอยากรู้ประสิทธิภาพเมื่อเทียบกับ sqlite-vss ด้วย อยากเห็นตัวเลข profiling ทั้งด้านความเร็วในการ query และการใช้หน่วยความจำ
      โดยรวมดูยอดเยี่ยมจริง ๆ และผมชอบทิศทางนี้
      แนวทางที่ว่าในตอนแรก sqlite-vec จะรองรับเฉพาะการค้นหาเวกเตอร์แบบสแกนทั้งหมดโดยตรง ยังไม่มีตัวเลือก approximate nearest neighbor (ANN) แต่ภายหลังอยากเพิ่ม IVF และ HNSW นั้น ผมเห็นด้วย 1000% ชอบตรงที่ไม่ทำให้ซับซ้อนเกินไปตั้งแต่แรก
      ผมเคยปล่อยระบบค้นหาเวกเตอร์บนอุปกรณ์มาแล้ว และกับชุดเวกเตอร์ไบนารี 128 บิต + Hamming distance ต่อให้ฐานข้อมูลมีมากกว่า 200,000 รายการ ก็เร็วพอที่จะรันการค้นหาระยะแบบ brute-force เต็มรูปแบบทุกเฟรมของกล้องได้ บนมือถือราคาถูกก็ได้เกิน 10fps และบนมือถือดี ๆ ก็ลื่นมาก มีหลายกรณีจนน่าประหลาดใจที่ brute force ก็เพียงพอแล้ว
      อย่างไรก็ตาม ถ้าจะ implement อัลกอริทึม ANN อย่าง HNSW ได้ในรูปแบบ พาราไดม์ของดัชนีตาราง ก็น่าจะยอดเยี่ยม แบบนั้นการเปลี่ยนจากการค้นหาแบบ brute force ไปเป็น ANN จะง่ายเท่ากับการสร้างดัชนีให้ตาราง และการทดลองอัลกอริทึม ANN หลายแบบกับพารามิเตอร์ต่าง ๆ ก็ทำได้โดยปรับพารามิเตอร์ตอนสร้างดัชนี อาจกำลังเป็นแนวทางนั้นอยู่แล้วก็ได้ แต่ขอพูดเผื่อไว้
    • อยากรู้ว่ามีแผนจะ implement กลยุทธ์การทำดัชนี อย่าง HNSW ด้วยหรือไม่ การสแกนเชิงเส้นเป็นจุดเริ่มต้นที่ดีอยู่แล้ว และถ้าข้อมูลถูกจัดเรียงในลำดับที่สมเหตุสมผล เช่น ขนาดต่ำกว่า 10MB ก็อาจเร็วพอ จึงดูไม่ใช่เหตุผลที่จะขวางการปล่อยเบต้า
      และอยากรู้ว่าบิลด์ร่วมกับ sqlite-httpvfs ด้วยหรือไม่ โปรเจกต์นี้น่าจะเข้ากันได้ดี: https://github.com/phiresky/sql.js-httpvfs
    • ชอบมากที่มี Wasm เข้ามา ปกติแล้วในเบราว์เซอร์ใช้งานการค้นหาเวกเตอร์ใน SQLite ได้ยาก
      อยากรู้ว่าเคยพิจารณาทำให้ เข้ากันได้ทางไวยากรณ์กับ pgvector เพื่อเป็น SQL vector DSL ร่วมกันหรือไม่ ผมคิดว่าข้อเสียอาจไม่ได้เล็กกว่าข้อดีมากนัก แต่ก็อยากรู้ว่าเป็นไปได้ไหม
    • จะ implement สิ่งนี้ด้วย Rust ได้ไหม และอยากรู้ว่าโปรเจกต์ sqlite-loadable-rs รองรับ WASM หรือไม่
      https://observablehq.com/@asg017/introducing-sqlite-loadable...
    • ก่อนหน้านี้ผมเคยเพิ่ม sqlite-vss เข้าไปใน Langchain ในฐานะ vector store แล้ว อยากรู้ว่าเห็นว่าโปรเจกต์ใหม่นี้โตพอที่จะเพิ่มเข้า Langchain แล้วหรือยัง หรือควรรออีกหน่อย
      ตอนนี้ sqlite-vss ก็ถูกใช้งานได้ดีในหลายโปรเจกต์แล้ว

  • ตรงที่ว่า “เป็นเวกเตอร์ไบนารี 768 มิติ จึงใช้พื้นที่ 96 ไบต์ (768 / 8 = 96)” ทำให้สับสน ปัญหาที่ vector store ส่วนใหญ่เจออย่าง คำสาปแห่งมิติ ก็คือเรื่องแบบนี้ และผมมองว่าเป็นปัญหาก่อนถึงขั้นการทำดัชนีเสียอีก
    ตอนแรกผมนึกว่าอาจหมายถึง 768 มิติ * 8 ไบต์ (f64) เท่ากับ 6144 ไบต์ โดยปกติจะยอมเสียความแม่นยำเล็กน้อยแล้วลดลงเป็น f32 หรือ f16 หรือ representation ที่เล็กกว่านั้น
    ถ้ามีวิธีบีบอัดหรือวิธี amortization คล้าย trie ที่ทำให้ยัด 768 มิติลงใน 96 ไบต์ได้ ก็อยากอ่านเป็นบทความแยกต่างหาก ถ้าหมายถึงการมองแต่ละมิติเป็น 1 บิตก็เข้าใจได้ แต่ถ้าเป็นแบบนั้นก็ยังมีข้อสงสัยเรื่องคุณภาพการค้นหาอยู่

    • ผมเป็นผู้เขียน — ในที่นี้ เวกเตอร์ไบนารี หมายถึงการ quantize แต่ละมิติเป็น 1 บิต โดยปกติจะต้องใช้ 4 * จำนวนมิติ ไบต์ต่อหนึ่งเวกเตอร์ โดย 4 ตรงนี้คือ sizeof(float)
      embedding model บางตัว เช่น nomic v1.5[0] หรือโมเดลใหม่ของ mixedbread[1] ถูกฝึกมาเป็นพิเศษเพื่อให้ยังคงคุณภาพไว้ได้หลัง binary quantization ไม่ใช่ทุกโมเดลจะเป็นแบบนั้น ดังนั้นผลลัพธ์อาจแตกต่างกัน โดยทั่วไป ในเวกเตอร์ขนาดใหญ่มากอย่าง embedding model ขนาดใหญ่ 3072 มิติของ OpenAI ดูเหมือนว่าจะยังใช้ได้ในระดับหนึ่ง แม้จะไม่ได้ถูกฝึกมาเป็นพิเศษเพื่อสิ่งนี้ก็ตาม
      [0] https://twitter.com/nomic_ai/status/1769837800793243687
      [1] https://www.mixedbread.ai/blog/binary-mrl
    • คำว่าไบนารีหมายถึงการ quantize แต่ละมิติให้เป็น +1 หรือ -1
      ถ้าใช้ดัชนี FAISS กับข้อมูลและใช้ Product Quantization ก็สามารถลองเวกเตอร์ไบนารีในรูปแบบอย่าง PQ768x1 สำหรับฟีเจอร์ไบนารีได้ และยังเปรียบเทียบวิธีอย่างการ quantize ให้เป็นหนึ่งในสี่ค่าต่อเวกเตอร์แต่ละคู่ได้ด้วย: https://github.com/facebookresearch/faiss/wiki/The-index-fac...
    • สำหรับข้อมูลอ้างอิง คำสาปแห่งมิติ หากพูดอย่างเคร่งครัด หมายถึงพื้นที่มิติสูงจะค่อนข้างเบาบาง และหากต้องการเติมเต็มพื้นที่นั้น ปริมาณข้อมูลต้องเพิ่มขึ้นแบบเอ็กซ์โปเนนเชียล ซึ่งไม่เกี่ยวข้องกับความจุในการจัดเก็บ
      โดยทั่วไปในฐานข้อมูลเวกเตอร์ จะบีบอัดหรือฉายข้อมูลไปยังพื้นที่มิติที่ต่ำกว่าก่อนจัดเก็บ จึงกลับช่วยให้สถานการณ์นี้ดีขึ้น

  • เพราะ sqlite-vss ทำให้ได้เรียนรู้ว่า RAG ทำงานอย่างไร และสามารถนำไปใช้ในโปรเจกต์ของเล่นได้ การดีบักยากอยู่บ้าง แต่ถ้าจูนให้ถูกต้องก็ทำงานบน Ubuntu ได้อย่างไร้ที่ติ และยังใช้อยู่จนถึงตอนนี้
    ดีใจที่กำลังทำเวอร์ชันใหม่ที่ดีกว่าโดยไม่ต้องมี dependency ที่จำกัดมากนัก

  • อยากรู้ว่ามีแผนจะใช้เฉพาะ SQLite API สาธารณะหรือไม่ หรือคาดว่าจะเป็นรูปแบบที่ผนวกเข้ากับ SQLite amalgamation
    สนใจฟีเจอร์แบบนี้แน่นอน แต่ต้องคิดว่าจะกระจายแยกจาก SQLite ใน Go binding ที่ใช้ Wasm อย่างไร จนถึงตอนนี้เรามักรวม C code ทั้งหมดไปด้วย เพราะมันง่ายกว่า “dynamic linking” บน Wasm มาก
    อีกอย่าง เห็นพูดถึง incremental BLOB I/O ซึ่งคงรู้อยู่แล้ว แต่ต้องจำไว้ว่าสำหรับ BLOB ขนาดใหญ่นั้นจะถูกเก็บเป็น linked list ของ page ดังนั้น BLOB I/O จึงไม่ใช่ random access อย่างเด็ดขาด

    • ตั้งใจจะใช้เฉพาะ SQLite API สาธารณะ ดังนั้นไม่จำเป็นต้องผนวกเข้ากับ amalgamation
      ชอบ wazero SQLite binding มาก จริง ๆ แล้วมีแผนจะให้ 1) CGO binding สำหรับ sqlite-vec และ 2) WASI build sqlite-vec แบบ custom ที่ใช้กับ go-sqlite3 ได้โดยตรง เดิมทีตั้งใจจะใช้ build script ของ repository นั้นเพื่อสร้างไฟล์ sqlite3.wasm ถ้าอยากรองรับโดยตรงในโปรเจกต์ ก็น่าจะเพียงแค่ใส่ไฟล์ sqlite-vec.c/h เข้าไปใน go-sqlite3/sqlite3 ก็ได้
      ได้เรียนรู้เรื่อง incremental BLOB I/O มาแบบเจ็บตัว มันเป็นปัจจัยจำกัดต่อความเร็ว query ของ sqlite-vec อย่างชัดเจน การรักษา chunk size ให้ค่อนข้างเล็กในระดับ MB ต่ำ ๆ และเพิ่ม page_size ทำให้ได้สมดุลที่พอใช้ได้ แต่โดยเฉพาะ page_size มีผลข้างเคียงอยู่ PRAGMA mmap_size ก็ช่วยได้มาก เพราะดูเหมือนจะทำให้ page ค้างอยู่ในหน่วยความจำและทำให้การ lookup overflow เร็วขึ้น แต่แน่นอนว่าการใช้หน่วยความจำเพิ่มขึ้นมาก เป็นสมดุลที่ยาก
    • ถ้าฟีเจอร์นี้เข้าไปอยู่ใน Wasm Go binding ได้ จะสนใจมากจริง ๆ

  • วันนี้ DuckDB ประกาศส่วนขยาย “Vector Similarity Search in DuckDB”
    https://duckdb.org/2024/05/03/vector-similarity-search-vss.h...

    • น่า期待มาก น่าจะช่วยทำให้โปรเจกต์ HNSW เล็ก ๆ ที่เคยทำบน CDN ง่ายขึ้นมาก: https://github.com/jasonjmcghee/portable-hnsw
      ถ้าใช้ DuckDB VSS ก็ดูเหมือนว่าจะทำ embedding แล้วเก็บในรูปแบบ DuckDB จากนั้นรัน SQL ภายใน CDN ได้

  • ชอบโปรเจกต์สไตล์นี้ เป็น โอเพนซอร์สโปรเจกต์ ที่เล็งแก้ปัญหาเฉพาะมาก ๆ เลยดี
    ใน ecosystem ของ TypeScript/Next.js/React ก็คิดอยู่เรื่อย ๆ ว่าจะสร้างอะไรที่มีประโยชน์มากในช่องว่างเชิงเทคนิคได้ไหม แต่ยังไม่มีแรงบันดาลใจ

  • ในแอป AI RAG อย่าง https://github.com/rnadigital/agentcloud เคยใช้ Qdrant vector DB สำหรับ automation แบบ end-to-end เลยตื่นเต้นที่มีคนทำภาคต่อ อยากรู้ว่าจะพร้อมให้ใช้งานประมาณเมื่อไร และมี quick start guide หรือไม่
    น่าจะช่วยเขียนบล็อกได้ด้วย

    • v0.1.0 ตั้งเป้าไว้อีกประมาณหนึ่งเดือน มีแผนจะใส่เอกสารและ quick start guide ไว้เยอะ ๆ
      มีแพ็กเกจ pip sqlite-vec ที่ยังไม่ได้ทำเอกสารไว้ ดังนั้นถ้าอยากเรียกใช้โดยตรงจาก “Agent Backend” ใน Python ตอนนี้ก็น่าจะลองได้

  • สิ่งนี้ค่อนข้างใกล้กับสิ่งที่จินตนาการว่า “README-driven development” จะหน้าตาเป็นอย่างไร อยากรู้ว่าผู้เขียน เริ่มจากเอกสารก่อน หรือเปล่า

    • เริ่มจากโค้ดก่อน ตัว extension เองเขียนไปเกือบหมดแล้ว[0]
      แต่ยังอยู่ในสภาพ “ทำได้ 80% ด้วยความพยายาม 20%” ดังนั้นส่วน 20% ที่เหลืออย่าง error handling, fuzz testing และ correctness testing น่าจะกินเวลา 80% อย่างไรก็ตาม ผู้คนถามถึงสถานะปัจจุบันของ sqlite-vss กันอยู่แล้ว เลยคิดว่าบล็อกโพสต์ “กำลังทำอยู่” นี้น่าจะตอบคำถามบางอย่างได้
      ก็ชอบไอเดียเริ่มจากเอกสารก่อนเหมือนกัน โดยเฉพาะใน SQLite extension นั้น SQL API หน้าตาเป็นอย่างไร เช่น scalar function และ virtual table สำคัญมาก ก่อนเขียนโค้ดส่วนใหญ่ ได้ร่างไว้ค่อนข้างเยอะว่าส่วน SQL ของ sqlite-vec ควรหน้าตาเป็นอย่างไร
      [0] https://github.com/asg017/sqlite-vec/blob/main/sqlite-vec.c

  • ดูเหมือนจะใกล้เคียงกับคำตอบต่อ GitHub issue ที่เคยเปิดไว้ใน SQLite-vss เมื่อหลายเดือนก่อน แม้พูดอย่างเคร่งครัดแล้วจะไม่ใช่คำตอบของ issue นั้นก็ตาม
    https://github.com/asg017/sqlite-vss/issues/124

    • ใช่เลย ขอโทษที่ไม่ได้ตอบ follow-up ที่นั่น
      จริง ๆ ตอนอ่าน ticket นั้นครั้งแรก ก็ทำให้ดำดิ่งไปกับคำถามว่า “จะทำให้ sqlite-vss ดีขึ้นได้อย่างไร” และสุดท้ายก็นำไปสู่ “ควรทำ sqlite-vec” ขอบคุณที่ช่วยพามาทางนี้
      ถ้าใช้ built-in binary quantization ของ sqlite-vec ก็ทำได้ประมาณนี้:
      CREATE VIRTUAL TABLE vec_files USING vec0 ( contents_embedding bit[1536] );
      INSERT INTO vec_files(rowid,contents_embedding) VALUES ((1, vec_quantize_binary( /* 1536-dimension float vector here*/)))

  • อยากทราบว่าเมื่อรันในเบราว์เซอร์ sqlite-vec สามารถทำให้ข้อมูลคงอยู่ใน IndexedDB ซึ่งเป็นเนทีฟของเบราว์เซอร์ได้หรือไม่ หรือว่าส่วนนี้ผู้ใช้ต้องจัดการเอง
    แม้คำตอบจะเป็นว่ายังไม่ได้คิดถึงเรื่องนี้ ก็จะขอบคุณมากหากช่วยแชร์แนวคิดในทิศทางนั้น

    • อาจเป็นไปได้ เนื่องจากอิงกับบิลด์ SQLite WASM อย่างเป็นทางการ จึงน่าจะใช้ ตัวเลือกการทำให้ข้อมูลคงอยู่[0] แบบเดียวกับที่มีให้จากตรงนั้นได้
      ยังไม่แน่ใจว่า IndexedDB รองรับโดยเฉพาะหรือไม่ แต่สามารถใช้ localStorage/OPFS VFS ได้
      [0] https://sqlite.org/wasm/doc/trunk/persistence.md#kvvfs