ฐานข้อมูลเวกเตอร์: คู่มือเบื้องต้นทางเทคนิค [PDF]
(tge-data-web.nyc3.digitaloceanspaces.com)- เมื่อแอปพลิเคชัน AI จัดการข้อมูลที่ไม่มีโครงสร้างและมีมิติสูง ฐานข้อมูลเวกเตอร์ จึงมีความสำคัญมากขึ้นในฐานะระบบเฉพาะทางสำหรับจัดเก็บและค้นคืนข้อมูลในรูปแบบอาร์เรย์ตัวเลข
- หัวใจสำคัญคือการเชื่อมโยงเรกคอร์ดตาม ความคล้ายคลึงกัน ระหว่างคุณลักษณะของข้อมูล แทนที่จะอาศัยแถว-คอลัมน์หรือความสัมพันธ์แบบระบุชัด จึงสามารถใช้ประโยชน์จากความหมายโดยนัยได้
- เมื่อเข้ารหัสความสัมพันธ์เชิงความหมายเป็นเวกเตอร์หลายมิติ ก็จะสามารถทำงานวิเคราะห์อย่าง การค้นหาความคล้ายคลึง, การจัดกลุ่ม และการจำแนก ได้รวดเร็วยิ่งขึ้น
- ใน Generative AI ใช้เพื่อจัดการข้อมูลมิติสูงจำนวนมาก และปรับปรุงความเร็วของ การฝึกและการอนุมาน ตลอดจนผลลัพธ์แบบปรับเฉพาะบุคคลผ่านการค้นหาเวกเตอร์ที่คล้ายกัน
- การทำดัชนีขั้นสูงช่วยลดชุดข้อมูลที่ต้องค้นหาให้เหลือเพียงส่วนย่อยที่มีความเกี่ยวข้องสูง จึงลด เวลาค้นหา และทำให้รองรับคิวรีที่ซับซ้อนซึ่งผสานทั้งความคล้ายคลึงและเงื่อนไขอื่น ๆ ได้
รูปแบบข้อมูลที่ฐานข้อมูลเวกเตอร์จัดการ
- ฐานข้อมูลเวกเตอร์เป็นฐานข้อมูลเฉพาะทางสำหรับจัดเก็บ จัดการ และประมวลผลเวกเตอร์ ซึ่งเป็น การแทนข้อมูลแบบมิติสูง
- ต่างจากฐานข้อมูลแบบดั้งเดิมที่จัดเก็บข้อมูลเป็นแถวและคอลัมน์ ฐานข้อมูลเวกเตอร์จะจัดเก็บข้อมูลเป็นเวกเตอร์ใน พื้นที่หลายมิติ
- เวกเตอร์แต่ละตัวคืออาร์เรย์ตัวเลขที่แทนลักษณะหรือคุณสมบัติของจุดข้อมูล
การเชื่อมโยงตามความหมายและความคล้ายคลึง
- ฐานข้อมูลแบบดั้งเดิมกำหนดความสัมพันธ์ระหว่างองค์ประกอบโดยอิงจากลิงก์หรือโครงสร้างลำดับชั้นที่ระบุไว้อย่างชัดเจน
- ฐานข้อมูลเวกเตอร์เชื่อมโยงเรกคอร์ดเชิงอัลกอริทึมโดยอิงจาก ความคล้ายคลึงกัน ของคุณลักษณะข้อมูล
- วิธีนี้สามารถสร้างการเชื่อมโยงที่เป็นธรรมชาติมากขึ้นบนพื้นฐานของความหมายโดยนัยภายในองค์ประกอบของฐานข้อมูล
โครงสร้างที่ออกแบบมาสำหรับคิวรีเชิงวิเคราะห์
- เมื่อข้อมูลถูกเข้ารหัสเป็นเวกเตอร์หลายมิติหรืออาร์เรย์ตัวเลขที่สะท้อนความสัมพันธ์เชิงความหมาย ก็จะสามารถทำงานวิเคราะห์ขั้นสูงได้อย่างรวดเร็ว
- งานที่รองรับได้รวมถึง การค้นหาความคล้ายคลึง, การจัดกลุ่ม และการจำแนก
- โมเดลการคำนวณนี้เหมาะกับการตรวจจับรูปแบบ การวิเคราะห์เชิงพยากรณ์ และแอปพลิเคชันที่มีความต้องการด้านการวิเคราะห์สูง
การใช้งานใน AI และ Generative AI
- การแพร่หลายของ AI และแมชชีนเลิร์นนิง เป็นปัจจัยสำคัญที่ทำให้ความต้องการฐานข้อมูลเวกเตอร์เพิ่มขึ้น
- ในด้าน Generative AI ฐานข้อมูลเวกเตอร์ถูกออกแบบมาเพื่อจัดเก็บและจัดการข้อมูลมิติสูงจำนวนมากได้อย่างมีประสิทธิภาพ
- ด้วยความสามารถในการค้นหาและดึงผลลัพธ์ของเวกเตอร์ที่คล้ายกันได้อย่างรวดเร็ว จึงช่วยเร่งกระบวนการ การฝึกและการอนุมาน ของโมเดล Generative AI ได้อย่างมาก
- ยังถูกนำไปใช้เพื่อให้ระบบ Generative AI ส่งมอบคอนเทนต์ที่มีความเป็นส่วนบุคคลและเกี่ยวข้องกับผู้ใช้มากขึ้น
การทำดัชนีและเงื่อนไขการค้นหาที่ซับซ้อน
- ฐานข้อมูลเวกเตอร์ใช้เทคนิค การทำดัชนี ขั้นสูงเพื่อค้นหาและเรียกดูเวกเตอร์ที่คล้ายกันได้อย่างรวดเร็ว
- ดัชนีช่วยจำกัดขอบเขตการค้นหาให้แคบลงเหลือเพียงส่วนย่อยของเวกเตอร์ที่เล็กกว่าและมีความเกี่ยวข้องมากกว่า ทำให้ลดเวลาค้นหาได้อย่างมาก
- ยังสามารถประมวลผล คิวรีที่ซับซ้อน ซึ่งผสานเงื่อนไขด้านความคล้ายคลึงเข้ากับเกณฑ์การค้นหาอื่น ๆ ได้
- ความยืดหยุ่นนี้มีความสำคัญต่อแอปพลิเคชัน AI ขั้นสูงที่ต้องการความสามารถในการค้นหาที่ซับซ้อน
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
A Comprehensive Survey on Vector Database: Storage and Retrieval Technique, Challenge: https://arxiv.org/abs/2310.11703
Survey of Vector Database Management Systems: https://arxiv.org/abs/2310.14021
What are Embeddings: https://raw.githubusercontent.com/veekaybee/what_are_embeddi...
เครดิตแหล่งที่มา: https://twitter.com/eatonphil/status/1745524630624862314 และ https://twitter.com/ChristophMolnar/status/17457316026829826...
มีให้ทั้งสไลด์พร้อมคำอธิบายประกอบ และ วิดีโอ 38 นาที ที่เลือกดูได้
บทความ Wikipedia: https://en.wikipedia.org/wiki/Vector_database
Vector Database 101: https://zilliz.com/learn/introduction-to-unstructured-data
Approximate Nearest Neighbor และ similarity search: https://vinija.ai/concepts/ann-similarity-search/
ฐานข้อมูลแบบกระจาย: https://15445.courses.cs.cmu.edu/fall2021/notes/21-distribut...
ผมเองก็สงสัยตรงนี้เหมือนกัน เลยอยากได้เกณฑ์หรือ rule of thumb สักอย่าง
ช่วงหลังผมลองจัดการ embedding ด้วยเครื่องมือ
llmที่ยอดเยี่ยมของ Simon Willison และแนวทางนั้นเรียบง่ายที่สุด: เก็บ embedding ไว้ใน SQLite พร้อม UDF สองสามตัวสำหรับคำนวณระยะทางความเรียบง่ายแบบนี้น่าดึงดูด แต่พอทราฟฟิกและข้อมูลเกินระดับหนึ่ง ก็น่าจะต้องใช้ฐานข้อมูลที่เฉพาะทางกว่า เลยอยากรู้ว่าขอบเขตนั้นอยู่ราว ๆ ไหน
การค้นหาใช้วิธีง่ายที่สุดคือไล่ดูทั้งหมดแล้วเทียบด้วย Hamming distance (
xorกับpopcount) ซึ่งบน MBP รุ่นปี 2011 แบบคอร์เดียว สามารถสแกน แฮช 200,000 รายการ ได้ในไม่ถึง 10ms เพื่อหารายการที่คล้ายที่สุดโค้ดมีประมาณ 1,000 บรรทัด สุดท้ายเลยไม่ต้องใช้ฐานข้อมูลเวกเตอร์ภายนอก
แต่เกินกว่านั้น ตัวเลือกที่พอใช้ได้อย่าง Pinecone จะซับซ้อนขึ้น ช้าลง และแพงอย่างไร้เหตุผล
เท่าที่ผมรู้ ตัวเลือกที่ดีที่สุดคือ turbopuffer.com ซึ่งถูกกว่า Pinecone ราว 100 เท่า และดูเหมือนจะสเกลได้จริง
ในสไลด์ไม่มีรายชื่อ vector DB แนะนำตัวนี้ เลยขอโยนไว้เป็นคำแนะนำที่ใช้ได้
https://news.ycombinator.com/item?id=38703943
เลกเชอร์นี้ผสมทั้งทฤษฎีและเดโม ครอบคลุมแนวคิดพื้นฐานของเวกเตอร์ ฐานข้อมูลเวกเตอร์ ดัชนี และ similarity search และปิดท้ายด้วยเดโมฐานข้อมูล Pinecone กับ Weaviate
ในขั้นตอนนี้ การตัดสินของมนุษย์เข้ามาอย่างละเอียดอ่อนมาก บางครั้งแทบจะถูกมองข้าม จนทำให้ระบบที่ดูจากภายนอกเหมือนเป็นระบบ “ก็แค่คณิตศาสตร์” ที่อัตโนมัติมาก
ยกตัวอย่างเสียง เราจะดึงคุณลักษณะอะไรออกมาเพื่อสร้างเวกเตอร์ N มิติ? คำตอบง่าย ๆ อาจเป็น “ให้มากที่สุดเท่าที่ทำได้”
แต่ข้อแรก แม้แต่คุณลักษณะที่ตั้งชื่อได้ง่าย ก็อาจไม่มีทางเข้าถึงข้อมูลสำหรับ characterise คุณลักษณะนั้น
ข้อสอง ถ้าไม่มีความรู้เชิงโดเมนลึกพอ คุณอาจไม่รู้ด้วยซ้ำว่ามีคุณลักษณะแฝงใดบ้างที่ควรใช้
ข้อสาม แม้จะมีความรู้เชิงโดเมนลึก ก็ยังอาจไม่รู้ว่ามีคุณลักษณะแฝงใดที่ควรใช้
เช่น สมมติว่าคุณเป็นแฟนมินิมัลมิวสิกแบบ phase shifting สไตล์ Reich และต้องการค้นหาเพลงที่คล้ายกับเพลงตัวแทนของแนวนี้ เช่น Piano Phase โดย query ไปยังฐานข้อมูลเวกเตอร์แบบอ้อม ๆ
ฐานข้อมูลใช้คุณลักษณะด้านเสียงและดนตรีหลายอย่าง เช่น ความถี่เด่น ช่วงห่างระหว่างการเริ่มต้นของโน้ต ความดัง คุณลักษณะ timbre จากการกระจายความถี่ รากเสียงและสเกลที่รับรู้ได้ เป็นต้น
แต่ถ้าชุดคุณลักษณะของฐานข้อมูลไม่มี “ช่วงห่างระหว่างโน้ตกับโน้ตที่คงที่ตามเวลา” อยู่ด้วย คิวรีก็อาจหาเพลงที่มีโทนเสียง ฮาร์โมนี ทำนอง และจังหวะคล้ายกันได้ แต่การจะหาเพลงที่มีคุณลักษณะสำคัญร่วมกันคือ เฟสสัมพัทธ์ของเส้นทำนองสองเส้นเปลี่ยนไปอย่างสม่ำเสมอ ก็จะกลายเป็นเรื่องของโชคล้วน ๆ
ไม่ยากที่จะสร้างตัวอย่างคล้าย ๆ กันกับข้อมูลใด ๆ ไม่ว่าจะเป็นภาพ ข้อความ ตัวเลข ฯลฯ
แน่นอนว่านี่ไม่ได้หมายความว่าฐานข้อมูลเวกเตอร์และการจำแนกคุณลักษณะไร้ประโยชน์
หนึ่งในคำถามแรก ๆ ที่ควรถามเมื่อค้นพบหรือค้นไม่พบรูปแบบที่ตรงกันในชุดข้อมูลหนึ่ง ๆ คือ มีการรับประกันอย่างหนักแน่นหรือไม่ว่าชุดคุณลักษณะนั้นครบถ้วน และถ้าไม่ครบ ควรขยายอย่างไร
ฐานข้อมูลเวกเตอร์ถูกออกแบบมาเพื่อ การค้นหาและการดึงผลลัพธ์การค้นหา
โดยทั่วไปวิธีสร้างเวกเตอร์คือปรับแต่งโมเดลที่ผ่านการ pretrain ขนาดใหญ่ แล้วดึง representation ภายในออกมา
ในชุดข้อมูลมีคิวรีที่สำเร็จและผลลัพธ์ที่ดึงกลับมาอยู่แล้ว ดังนั้นก็เพียงใช้ input ดิบเพื่อปรับ loss function ให้เหมาะกับวัตถุประสงค์ด้านความคล้ายคลึงที่ฐานข้อมูลเวกเตอร์รองรับ
สำหรับ modality ทั่วไปอย่างตาราง ข้อความ รูปภาพ และเสียง การเลือกคุณลักษณะแทบไม่ต้องอาศัยการตัดสินของมนุษย์ แค่ใช้ attention ก็พอ
อนึ่ง โมเดล text-to-vector รุ่นใหม่อย่าง E5-Mistral ไม่จำเป็นต้องมีแม้แต่การคัดสรรข้อมูลโดยมนุษย์ในชุดข้อมูล
ชี้ประเด็นเรื่อง “ไม่รู้ว่าตัวเองไม่รู้อะไร” ได้ดี
ดีใจที่ได้เห็นคนชอบ Steve Reich อีกคน และผมก็สงสัยว่าจะแนะนำเพลงที่คล้ายกับ Music for 18 Musicians ซึ่งเป็นเพลงโปรดของผมได้อย่างไร
เป็นภาพรวมที่ยอดเยี่ยม แต่ส่วนสุดท้ายไม่ได้แตะคำถามเดิม ๆ ว่าควรใช้อะไรระหว่าง vector store อย่าง Postgres+pgvector กับ vector database อย่าง Pinecone
อยากเห็นงานนำเสนอที่พูดถึง trade-off หลายด้าน เช่น ความเร็วในการคิวรี ความเร็วในการ insert และสร้าง index ความง่ายในการใช้งาน เพื่อช่วยเลือกให้เหมาะกับแต่ละแอปพลิเคชันมากขึ้น
ยินดีรับ PR เสมอ
ฐานข้อมูลก็คือ storage ที่มีฟีเจอร์โน่นนี่เพิ่มเข้ามา
digitaloceanspaces.com เป็นผู้ให้บริการโฮสติ้งสไตล์ S3 ดังนั้นคงดีถ้า Hacker News จัดการเป็นกรณีพิเศษ โดยแสดงโดเมนเป็นทำนอง tge-data-web.nyc3.digitaloceanspaces.com แทนที่จะแสดงแบบย่อว่า digitaloceanspaces.com เฉย ๆ
อย่างไรก็ตาม S3 เองก็ดูเหมือนจะมีปัญหาเดียวกัน: https://news.ycombinator.com/item?id=38876761
มี precedent ในที่อื่นอยู่แล้ว เว็บไซต์ซับโดเมน x.github.io ถูกจัดการเป็นกรณีพิเศษที่นี่: https://news.ycombinator.com/from?site=lfranke.github.io
เอกสารนี้ดู ค่อนข้างอันตราย หากวิศวกรจะใช้เป็นจุดเริ่มต้น
คำอธิบายทำนองว่ามีการจัดกลุ่มตามความหมาย หรือถูกปรับให้เหมาะกับการวิเคราะห์นั้นน่าสงสัย
การจัดกลุ่มขึ้นอยู่กับ embedding ที่คำนวณได้ ถ้าคุณเชื่อว่า embedding นั้นประมาณความหมายของข้อมูลได้ดี ก็อาจคิดแบบนั้นได้
แต่เราสามารถจินตนาการ embedding ที่ทำลายสมมติฐานนี้ได้ง่าย ๆ เช่น ถ้าเอาไฟล์เสียงและไฟล์ข้อความที่มีความหมายเดียวกันเข้าไปในกระบวนการ embedding เดียวกัน หากไม่ใช่ multimodal ก็น่าจะอยู่ห่างกันใน vector space
ต่อไปผมคิดว่าจะต้องมี embedding ที่จัดวางให้สิ่งต่าง ๆ อยู่ใกล้กันใน vector space ตาม รูปแบบการใช้งาน มากกว่าตามความคล้ายคลึงเชิงความหมายอย่างแน่นอน
ถ้ากำลังทำระบบแนะนำสินค้า คุณคงไม่อยากจัดการซื้อแบบครั้งเดียวหลาย ๆ รูปแบบให้อยู่ใกล้กัน
ตัวอย่างเช่น เที่ยวบินที่คล้ายกันที่สุดในเชิงความหมายอาจเป็นเที่ยวบินเวลาอื่นไปยังปลายทางเดียวกัน หรือเที่ยวบินไปสนามบินใกล้เคียง แต่ในความเป็นจริงคุณอาจต้องการจับคู่โรงแรมที่ผู้ซื้อเที่ยวบินนั้นมักซื้อร่วมกัน
ฐานข้อมูลเวกเตอร์ยังสามารถใส่มิติเพิ่มเติมอย่างการรับรู้เวลาเข้าไปในข้อมูลได้ด้วย ไม่จำเป็นต้องใช้เวกเตอร์ที่ encode ความหมายเสมอไป
ดังนั้นฐานข้อมูลเวกเตอร์จึงถูกปรับให้เหมาะกับการ lookup หรือค้นหาจากเวกเตอร์อินพุต ไม่ได้คล้ายกับ OLAP query
มันใกล้เคียงกับ Elasticsearch มากกว่า Snowflake ถ้าคุณใช้ฐานข้อมูลเวกเตอร์โดยคาดหวัง reporting หรือการวิเคราะห์ขนาดใหญ่บน vector space เท่าที่ผมรู้ตอนนี้ยังไม่มีผลิตภัณฑ์ที่ใช้งานได้จริงในลักษณะนั้น
ผมเข้าใจการไปจากภาพแอปเปิลเป็นเวกเตอร์ที่แทน “ความเป็นแอปเปิล” แล้วนำเวกเตอร์นั้นไปเปรียบเทียบกับเวกเตอร์อื่นด้วยคณิตศาสตร์ทั่วไป
สิ่งที่ไม่เข้าใจคือใคร/อะไรเป็นผู้รับภาพเป็นอินพุตแล้วส่งเวกเตอร์ออกมา
เอกสารก็เหมือนกัน ถ้าต้องการเพิ่มมิติด้วยการใส่ตัวเลขเพิ่มอีกหนึ่งตัวในอาร์เรย์ ต้องแก้ส่วนไหนของฐานข้อมูลเวกเตอร์เพื่อให้มิตินั้นถูกรวมในการคำนวณเวกเตอร์
หรือว่ากระบวนการแปลงเอกสาร รูปภาพ หรืออะไรก็ตามให้เป็นตัวแทนแบบเวกเตอร์นั้นทำด้วยวิธีอื่นนอกฐานข้อมูล
แก้ไข: การคำนวณ embedding ดูเหมือนเป็นงานของอัลกอริทึมแมชชีนเลิร์นนิง แต่ถ้าอย่างนั้นอัลกอริทึมนั้นก็ต้องถูกฝึกก่อนอยู่ดี สุดท้ายก็วนไปสู่การฝึกไม่รู้จบ
ไม่เข้าใจว่าทำไม PQ ถึงถูกระบุเป็น “กลยุทธ์การทำ index”
PQ เป็นเทคนิคบีบอัดและ quantization เวกเตอร์ ไม่ใช่วิธีแบ่งพื้นที่ค้นหา
สามารถ encode เวกเตอร์ด้วย PQ ใน exhaustive search/flat index, IVF index, HNSW ได้ และใน Faiss ก็มีเป็น IndexPQ, IndexIVFPQ, IndexHNSWPQ ตามลำดับ
ถ้าต้องการก็ใช้กับ k-D tree หรือ ANNOY ได้ด้วย
คำพูดที่ว่า “ถ้าความเร็วคิวรีสำคัญกว่าความแม่นยำ สำหรับชุดข้อมูลขนาดใหญ่มากให้ใช้ HNSW หรือ Annoy” ก็มีปัญหาเช่นกัน
เทคนิคแบบกราฟมี overhead ด้านหน่วยความจำและต้นทุนการสร้างสูง และไม่ practical สำหรับ ชุดข้อมูลระดับพันล้านรายการ
โดยทั่วไปมันแม่นยำกว่าและเร็วกว่าเทคนิค IVF ก็จริง แต่เป็นเพราะ IVF ต้องเยี่ยมชมหลาย cell เพื่อให้ได้ความแม่นยำใกล้เคียงกัน
ในทางกลับกัน IVF แตกต่างจากเทคนิคอื่นตรงที่สามารถ scale ไปถึง ฐานข้อมูลระดับล้านล้านรายการ ได้โดยไม่มี overhead มาก และยังให้ trade-off ระหว่างความเร็วกับความแม่นยำที่สมเหตุสมผล
ผมจะบอกว่า “ให้ใช้กับชุดข้อมูลขนาดกลางที่ความเร็วคิวรีสำคัญ แต่ก็ต้องการความแม่นยำสูง และ flat/exhaustive index ไม่ practical” มากกว่า
ทำ PQ ก่อน แล้วค่อยทำ KNN กับเวกเตอร์ไม่ต่อเนื่องชุดใหม่
วิธีนี้ทำให้บีบอัดพื้นที่คำศัพท์ให้มีขนาดคงที่ได้
ในตารางของสไลด์ที่ 15 ช่อง Indexing & Search Efficiency ของ Traditional Databases กับ Vector Databases ดูเหมือนจะสลับกัน
มีคำแนะนำสำหรับ ฐานข้อมูล embedding แบบฝังตัว คล้าย SQLite ไหม?
สำหรับปัญหาขนาดเล็ก แต่ถ้าสะดวกกว่า LMDB + FAISS ก็คงดี
สามารถรันภายใน Python process ได้ เก็บเนื้อหาไว้ใน SQLite และรองรับการเก็บ embedding vector ในรูปแบบดัชนีเวกเตอร์แบบ local (Faiss, HNSW, Annoy)
อนึ่ง ผมเป็นผู้เขียนหลักของ txtai
https://github.com/patricktrainer/hackernews-comment-search
llmของ Simon Willison ใช้แค่ SQLite กับ UDF ไม่กี่ตัวความเรียบง่ายแบบนั้นน่าสนใจ แต่ยังไม่ค่อยเข้าใจว่าเมื่อไหร่และเพราะอะไรถึงจะไม่เพียงพอ
ส่วนสำหรับ Go เมื่อไม่นานมานี้ผมเริ่มทำ chromem-go โดยได้แรงบันดาลใจจากอินเทอร์เฟซของ Chroma: https://github.com/philippgille/chromem-go
ยังไม่ใช่สำหรับฟีเจอร์ขั้นสูงหรือการใช้งานขนาดใหญ่ แต่เดโม RAG ทำงานได้แล้ว
[1] https://github.com/chroma-core/chroma