Vector คือ JSON ใหม่ของ PostgreSQL

xguru · 2023-06-28T11:05:01+09:00

เวกเตอร์เป็นโครงสร้างทางคณิตศาสตร์ที่มีการศึกษามาอย่างดี ส่วน JSON เป็นรูปแบบสำหรับแลกเปลี่ยนข้อมูล แต่ในโลกของการจัดเก็บและค้นคืนข้อมูล วิธีแทนข้อมูลทั้งสองแบบได้กลายเป็นภาษากลาง และกำลังจะเป็นองค์ประกอบสำคัญของการพัฒนาแอปพลิเคชันสมัยใหม่ในไม่ช้า หากแนวโน้มปัจจุบันยังคงดำเนินต่อไป เวกเตอร์ก็จะมีความสำคัญต่อการสร้างแอปพลิเคชันไม่ต่างจาก JSON PostgreSQL กลายเป็นตัวเลือกตามธรรมชาติสำหรับการจัดเก็บและคิวรีผลลัพธ์จาก Generative AI แต่นี่ไม่ใช่รูปแบบข้อมูลใหม่เสียทีเดียว เวกเตอร์ในฐานะแนวคิดทางคณิตศาสตร์มีมานานหลายร้อยปีแล้ว อาร์เรย์ซึ่งเป็นโครงสร้างข้อมูลพื้นฐานของเวกเตอร์ ถูกสอนในหลักสูตรวิทยาการคอมพิวเตอร์เบื้องต้นส่วนใหญ่ และ PostgreSQL ก็รองรับการทำงานกับเวกเตอร์มานานกว่า 20 ปีแล้ว แล้วอะไรคือสิ่งใหม่? มันคือ "การเข้าถึงได้ง่าย" ของอัลกอริทึม AI/ML เหล่านี้ และความง่ายในการแทนโครงสร้างบางอย่างของ "โลกจริง" (ข้อความ, รูปภาพ, วิดีโอ) เป็นเวกเตอร์เพื่อนำไปใช้ในแอปพลิเคชันภายหลัง อีกทั้งแม้การเก็บเอาต์พุตของระบบเหล่านี้ ("embedding") ลงในที่จัดเก็บข้อมูลจะไม่ใช่เรื่องใหม่ แต่รูปแบบใหม่คือ "การเข้าถึงได้ง่าย" ในการคิวรีและส่งคืนข้อมูลเหล่านี้จากทุกแอปพลิเคชันได้แทบจะเรียลไทม์ แล้วเรื่องนี้เกี่ยวอะไรกับ PostgreSQL? รูปแบบร่วมสำหรับการจัดเก็บและค้นคืนชนิดข้อมูลอย่างมีประสิทธิภาพช่วยให้การพัฒนาแอปง่ายขึ้นมาก และทำให้ผู้คนสามารถเก็บข้อมูลไว้ในที่เดียวกันและทำงานด้วยเครื่องมือเดิมได้ เราเคยเห็นสิ่งนี้กับ JSON เมื่อ 10 ปีก่อน และตอนนี้กำลังเห็นรูปแบบเดียวกันกับข้อมูลเวกเตอร์ ประวัติย่อของ JSON ใน PostgreSQL (โปรดดูต้นฉบับ) การเติบโตของเวกเตอร์ "JSON ประเภทใหม่" ช่วงนี้ได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว กรณีใช้งานทั่วไปคือสร้างโมเดลจากข้อมูลที่จัดเก็บไว้ แปลงให้เป็นรูปแบบเวกเตอร์ แล้วนำไปใช้กับ "semantic search" ในกรณีนี้ อินพุตใหม่ที่เข้ามาสำหรับการค้นหาจะถูกแปลงเป็นรูปแบบเวกเตอร์ก่อน แล้วจึงค้นหาสิ่งที่คล้ายกันที่สุดในฐานข้อมูล ความคล้ายกันวัดด้วยฟังก์ชันระยะทาง เช่น Euclidean/Cosine distance และผลลัพธ์มักจำกัดไว้ที่ k-NN (Nearest Neighbors) หรือออบเจ็กต์ที่คล้ายที่สุดจำนวน k รายการ เนื่องจากการเข้ารหัสชุดข้อมูลฝึกให้เป็นเวกเตอร์อาจใช้เวลามาก จึงควรแคชไว้ในที่อย่างฐานข้อมูลและรันคิวรี k-NN จากที่นั่น การมีชุดเวกเตอร์ที่พร้อมให้คิวรีสำหรับ semantic search มักให้ประสบการณ์ที่ดีกว่ากับผู้ใช้ จึงเกิดความต้องการ "vector database" การจัดเก็บเวกเตอร์ไม่ใช่เรื่องใหม่สำหรับ PostgreSQL ที่จริงแล้วชื่อนี้อาจไม่แม่นนัก เพราะ PostgreSQL สามารถจัดเก็บข้อมูลหลายมิติได้อยู่แล้ว (เช่น matrix) โดยพื้นฐานแล้ว อาร์เรย์ของ PostgreSQL มีความสามารถสำหรับเวกเตอร์อยู่บ้างอย่างจำกัด เช่น การคำนวณ "ระยะทาง" ระหว่างอาร์เรย์สองชุด สามารถเขียน stored procedure ได้ แต่ต้องอาศัยงานเพิ่มจากนักพัฒนาเล็กน้อย โชคดีที่ชนิดข้อมูล cube ช่วยแก้ข้อจำกัดเหล่านี้ได้ cube ถูกใช้งานมานานกว่า 20 ปี และออกแบบมาเพื่อรองรับการทำงานกับเวกเตอร์มิติสูง cube มีฟังก์ชันระยะทางที่ใช้ทั่วไปในการค้นหาความคล้ายของเวกเตอร์เกือบทั้งหมด รวมถึง Euclidean distance ยังสามารถทำคิวรี K-NN อย่างมีประสิทธิภาพได้โดยใช้ดัชนี GiST แต่ cube จัดเก็บเวกเตอร์ได้เพียงถึง 100 มิติ ขณะที่ระบบ AI/ML สมัยใหม่ต้องการมิติมากกว่านั้น pgvector: ส่วนขยายโอเพนซอร์สสำหรับจัดเก็บและค้นหาเวกเตอร์ใน PostgreSQL ใช้ pgvector เพื่อจัดเก็บเวกเตอร์และทำคิวรี k-NN ด้วยเมตริกระยะทางหลายแบบได้ (Euclidean, cosine, inner product เป็นต้น) ปัจจุบัน pgvector มาพร้อมดัชนี ivfflat หนึ่งแบบที่ใช้งานวิธี IVR FLAT สำหรับการทำดัชนีเวกเตอร์ การคิวรีข้อมูลเวกเตอร์ที่ถูกทำดัชนีอาจแตกต่างจากการคิวรีข้อมูลทั่วไป เนื่องจากต้นทุนของการค้นหา nearest neighbor ในเวกเตอร์มิติสูงสูงมาก วิธีทำดัชนีเวกเตอร์จำนวนมากจึงมองหาคำตอบแบบ "ใกล้เคียงพอ" หรือ "ประมาณได้" สิ่งนี้นำไปสู่สาขาการค้นหาแบบ "ANN (Approximate Nearest Neighbor)" สองมิติที่ผู้คนมักพิจารณาในคิวรี ANN คือสมดุลระหว่างประสิทธิภาพกับ "recall" (เปอร์เซ็นต์ของผลลัพธ์ที่เกี่ยวข้องซึ่งถูกส่งกลับ) ยกตัวอย่าง ivfflat เมื่อสร้างดัชนี ivfflat จะต้องตัดสินใจว่าจะมี list กี่ชุด แต่ละ list แทน "ศูนย์กลาง" หนึ่งจุด ซึ่งคำนวณด้วยอัลกอริทึม k-means เมื่อกำหนด center ทั้งหมดแล้ว ivfflat จะระบุว่าเวกเตอร์แต่ละตัวใกล้กับ center ใดที่สุด แล้วเพิ่มเข้าไปในดัชนีนั้น เมื่อต้องคิวรีข้อมูลเวกเตอร์ ivfflat จะตัดสินใจว่าควรตรวจสอบ center กี่จุดตามตัวแปร ivfflat.probes ตรงนี้เองที่เห็น trade-off ระหว่างประสิทธิภาพกับ recall ของ ANN ยิ่งเข้าถึง center มาก ผลลัพธ์ก็ยิ่งแม่นยำขึ้น แต่ประสิทธิภาพจะลดลง ขั้นต่อไปเพื่อรองรับเวกเตอร์ใน PostgreSQL ให้ดียิ่งขึ้น เช่นเดียวกับช่วงแรกของ PostgreSQL 9.2 ที่เริ่มรองรับชนิดข้อมูล JSON อย่างเป็นทางการ ตอนนี้เรากำลังอยู่ในระยะเริ่มต้นของวิธีจัดเก็บข้อมูลเวกเตอร์ใน PostgreSQL PostgreSQL และ pgvector ดีอยู่แล้ว แต่จะดีขึ้นได้อีกมาก pgvector สามารถรองรับกรณีใช้งานข้อมูล AI/ML ทั่วไปได้แล้ว และมีผู้ใช้จำนวนมากนำไปใช้งานจริง ขั้นต่อไปคือช่วยกันปรับปรุงและขยายความสามารถ ซึ่งส่วนใหญ่ก็กำลังดำเนินอยู่แล้ว เพิ่มการประมวลผลแบบขนานให้มากขึ้น รองรับเวกเตอร์ที่มีมิติมากกว่า 2,000 มิติ ใช้ hardware acceleration เพื่อเพิ่มความเร็วในการคำนวณ มีความคาดหวังอย่างมากต่อการใช้ PostgreSQL เป็น "vector database" ดังที่เห็นจากประวัติของ JSON ชุมชน PostgreSQL จะหาวิธีรองรับสิ่งนี้อย่างขยายต่อได้และปลอดภัย

(jkatz05.com)

26 คะแนน โดย xguru 2023-06-28 | 7 ความคิดเห็น | แชร์ทาง WhatsApp

เวกเตอร์เป็นโครงสร้างทางคณิตศาสตร์ที่มีการศึกษามาอย่างดี ส่วน JSON เป็นรูปแบบสำหรับแลกเปลี่ยนข้อมูล
แต่ในโลกของการจัดเก็บและค้นคืนข้อมูล วิธีแทนข้อมูลทั้งสองแบบได้กลายเป็นภาษากลาง และกำลังจะเป็นองค์ประกอบสำคัญของการพัฒนาแอปพลิเคชันสมัยใหม่ในไม่ช้า
หากแนวโน้มปัจจุบันยังคงดำเนินต่อไป เวกเตอร์ก็จะมีความสำคัญต่อการสร้างแอปพลิเคชันไม่ต่างจาก JSON
PostgreSQL กลายเป็นตัวเลือกตามธรรมชาติสำหรับการจัดเก็บและคิวรีผลลัพธ์จาก Generative AI
แต่นี่ไม่ใช่รูปแบบข้อมูลใหม่เสียทีเดียว เวกเตอร์ในฐานะแนวคิดทางคณิตศาสตร์มีมานานหลายร้อยปีแล้ว
อาร์เรย์ซึ่งเป็นโครงสร้างข้อมูลพื้นฐานของเวกเตอร์ ถูกสอนในหลักสูตรวิทยาการคอมพิวเตอร์เบื้องต้นส่วนใหญ่ และ PostgreSQL ก็รองรับการทำงานกับเวกเตอร์มานานกว่า 20 ปีแล้ว
แล้วอะไรคือสิ่งใหม่? มันคือ "การเข้าถึงได้ง่าย" ของอัลกอริทึม AI/ML เหล่านี้ และความง่ายในการแทนโครงสร้างบางอย่างของ "โลกจริง" (ข้อความ, รูปภาพ, วิดีโอ) เป็นเวกเตอร์เพื่อนำไปใช้ในแอปพลิเคชันภายหลัง
อีกทั้งแม้การเก็บเอาต์พุตของระบบเหล่านี้ ("embedding") ลงในที่จัดเก็บข้อมูลจะไม่ใช่เรื่องใหม่ แต่รูปแบบใหม่คือ "การเข้าถึงได้ง่าย" ในการคิวรีและส่งคืนข้อมูลเหล่านี้จากทุกแอปพลิเคชันได้แทบจะเรียลไทม์
แล้วเรื่องนี้เกี่ยวอะไรกับ PostgreSQL?
- รูปแบบร่วมสำหรับการจัดเก็บและค้นคืนชนิดข้อมูลอย่างมีประสิทธิภาพช่วยให้การพัฒนาแอปง่ายขึ้นมาก และทำให้ผู้คนสามารถเก็บข้อมูลไว้ในที่เดียวกันและทำงานด้วยเครื่องมือเดิมได้
- เราเคยเห็นสิ่งนี้กับ JSON เมื่อ 10 ปีก่อน และตอนนี้กำลังเห็นรูปแบบเดียวกันกับข้อมูลเวกเตอร์

ประวัติย่อของ JSON ใน PostgreSQL

(โปรดดูต้นฉบับ)

การเติบโตของเวกเตอร์ "JSON ประเภทใหม่"

ช่วงนี้ได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว
กรณีใช้งานทั่วไปคือสร้างโมเดลจากข้อมูลที่จัดเก็บไว้ แปลงให้เป็นรูปแบบเวกเตอร์ แล้วนำไปใช้กับ "semantic search"
- ในกรณีนี้ อินพุตใหม่ที่เข้ามาสำหรับการค้นหาจะถูกแปลงเป็นรูปแบบเวกเตอร์ก่อน แล้วจึงค้นหาสิ่งที่คล้ายกันที่สุดในฐานข้อมูล
- ความคล้ายกันวัดด้วยฟังก์ชันระยะทาง เช่น Euclidean/Cosine distance และผลลัพธ์มักจำกัดไว้ที่ k-NN (Nearest Neighbors) หรือออบเจ็กต์ที่คล้ายที่สุดจำนวน k รายการ
- เนื่องจากการเข้ารหัสชุดข้อมูลฝึกให้เป็นเวกเตอร์อาจใช้เวลามาก จึงควรแคชไว้ในที่อย่างฐานข้อมูลและรันคิวรี k-NN จากที่นั่น
- การมีชุดเวกเตอร์ที่พร้อมให้คิวรีสำหรับ semantic search มักให้ประสบการณ์ที่ดีกว่ากับผู้ใช้ จึงเกิดความต้องการ "vector database"
โฆษณา
การจัดเก็บเวกเตอร์ไม่ใช่เรื่องใหม่สำหรับ PostgreSQL
- ที่จริงแล้วชื่อนี้อาจไม่แม่นนัก เพราะ PostgreSQL สามารถจัดเก็บข้อมูลหลายมิติได้อยู่แล้ว (เช่น matrix)
- โดยพื้นฐานแล้ว อาร์เรย์ของ PostgreSQL มีความสามารถสำหรับเวกเตอร์อยู่บ้างอย่างจำกัด เช่น การคำนวณ "ระยะทาง" ระหว่างอาร์เรย์สองชุด
- สามารถเขียน stored procedure ได้ แต่ต้องอาศัยงานเพิ่มจากนักพัฒนาเล็กน้อย
โชคดีที่ชนิดข้อมูล cube ช่วยแก้ข้อจำกัดเหล่านี้ได้
- cube ถูกใช้งานมานานกว่า 20 ปี และออกแบบมาเพื่อรองรับการทำงานกับเวกเตอร์มิติสูง
- cube มีฟังก์ชันระยะทางที่ใช้ทั่วไปในการค้นหาความคล้ายของเวกเตอร์เกือบทั้งหมด รวมถึง Euclidean distance
- ยังสามารถทำคิวรี K-NN อย่างมีประสิทธิภาพได้โดยใช้ดัชนี GiST
- แต่ cube จัดเก็บเวกเตอร์ได้เพียงถึง 100 มิติ ขณะที่ระบบ AI/ML สมัยใหม่ต้องการมิติมากกว่านั้น

pgvector: ส่วนขยายโอเพนซอร์สสำหรับจัดเก็บและค้นหาเวกเตอร์ใน PostgreSQL

ใช้ pgvector เพื่อจัดเก็บเวกเตอร์และทำคิวรี k-NN ด้วยเมตริกระยะทางหลายแบบได้ (Euclidean, cosine, inner product เป็นต้น)
ปัจจุบัน pgvector มาพร้อมดัชนี ivfflat หนึ่งแบบที่ใช้งานวิธี IVR FLAT สำหรับการทำดัชนีเวกเตอร์
การคิวรีข้อมูลเวกเตอร์ที่ถูกทำดัชนีอาจแตกต่างจากการคิวรีข้อมูลทั่วไป
เนื่องจากต้นทุนของการค้นหา nearest neighbor ในเวกเตอร์มิติสูงสูงมาก วิธีทำดัชนีเวกเตอร์จำนวนมากจึงมองหาคำตอบแบบ "ใกล้เคียงพอ" หรือ "ประมาณได้"
สิ่งนี้นำไปสู่สาขาการค้นหาแบบ "ANN (Approximate Nearest Neighbor)"
สองมิติที่ผู้คนมักพิจารณาในคิวรี ANN คือสมดุลระหว่างประสิทธิภาพกับ "recall" (เปอร์เซ็นต์ของผลลัพธ์ที่เกี่ยวข้องซึ่งถูกส่งกลับ)
- ยกตัวอย่าง ivfflat เมื่อสร้างดัชนี ivfflat จะต้องตัดสินใจว่าจะมี list กี่ชุด
- แต่ละ list แทน "ศูนย์กลาง" หนึ่งจุด ซึ่งคำนวณด้วยอัลกอริทึม k-means
- เมื่อกำหนด center ทั้งหมดแล้ว ivfflat จะระบุว่าเวกเตอร์แต่ละตัวใกล้กับ center ใดที่สุด แล้วเพิ่มเข้าไปในดัชนีนั้น
- เมื่อต้องคิวรีข้อมูลเวกเตอร์ ivfflat จะตัดสินใจว่าควรตรวจสอบ center กี่จุดตามตัวแปร ivfflat.probes
- ตรงนี้เองที่เห็น trade-off ระหว่างประสิทธิภาพกับ recall ของ ANN ยิ่งเข้าถึง center มาก ผลลัพธ์ก็ยิ่งแม่นยำขึ้น แต่ประสิทธิภาพจะลดลง

ขั้นต่อไปเพื่อรองรับเวกเตอร์ใน PostgreSQL ให้ดียิ่งขึ้น

เช่นเดียวกับช่วงแรกของ PostgreSQL 9.2 ที่เริ่มรองรับชนิดข้อมูล JSON อย่างเป็นทางการ ตอนนี้เรากำลังอยู่ในระยะเริ่มต้นของวิธีจัดเก็บข้อมูลเวกเตอร์ใน PostgreSQL
PostgreSQL และ pgvector ดีอยู่แล้ว แต่จะดีขึ้นได้อีกมาก
pgvector สามารถรองรับกรณีใช้งานข้อมูล AI/ML ทั่วไปได้แล้ว และมีผู้ใช้จำนวนมากนำไปใช้งานจริง
ขั้นต่อไปคือช่วยกันปรับปรุงและขยายความสามารถ ซึ่งส่วนใหญ่ก็กำลังดำเนินอยู่แล้ว
- เพิ่มการประมวลผลแบบขนานให้มากขึ้น
- รองรับเวกเตอร์ที่มีมิติมากกว่า 2,000 มิติ
- ใช้ hardware acceleration เพื่อเพิ่มความเร็วในการคำนวณ
มีความคาดหวังอย่างมากต่อการใช้ PostgreSQL เป็น "vector database"
ดังที่เห็นจากประวัติของ JSON ชุมชน PostgreSQL จะหาวิธีรองรับสิ่งนี้อย่างขยายต่อได้และปลอดภัย

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

atempest 2025-05-07

ถึงจะอเนกประสงค์สูง แต่สุดท้ายประเด็นสำคัญก็คงเป็นเรื่องความเร็วหรือเปล่า
เทียบกับ vector DB แบบแท้ ๆ แล้ว น่าจะช้าจนดูไม่จืดเลย....

nicewook 2023-06-28

ผมสงสัยว่าทำไมถึงยังคาดหวังกับ PostgreSQL อยู่ ในเมื่อมีฐานข้อมูลเวกเตอร์อย่าง Pinecone อยู่แล้ว @@

tkwlsrl 2023-06-28

จากประสบการณ์ของผม PostgreSQL เข้าถึงและใช้งานได้ง่ายที่สุด

ตอนที่ใช้พวก Pinecone, ChromaDB หรือ Weaviate มันยังไม่ได้ถูกทำให้เป็นมาตรฐานว่าจะใช้งานฐานข้อมูลแต่ละตัวได้เหมือนกัน

พูดง่าย ๆ คือแต่ละฐานข้อมูลต้องใช้ SDK คนละชุด และวิธีใช้ก็ต่างกัน ทำให้ต้องเขียนโค้ดใหม่แยกตามแต่ละฐานข้อมูล นอกจากนี้ภาษาที่มี official SDK ให้ก็ยังมีไม่มาก จนบางครั้งต้องเปลี่ยนภาษาไปใช้ด้วย

แน่นอนว่าถ้าจะใช้เวกเตอร์ใน PostgreSQL มันก็คล้าย ๆ กันอยู่บ้าง แต่ยังดีที่แค่ต้องเพิ่มความรู้จากไวยากรณ์ SQL เดิมอีกนิดหน่อยก็ใช้งานได้แล้ว เลยเข้าถึงได้ง่าย

ตอนนี้พอลองเทียบความเร็วของฐานข้อมูลเวกเตอร์แล้ว PostgreSQL ถือว่าค่อนข้างช้าพอสมควร หวังว่าจะอัปเกรดให้ดีขึ้นเร็ว ๆ นี้นะครับ 555

xguru 2023-06-28

น่าจะประมาณว่า "ติดตั้ง/ดูแลแค่ DB ตัวเดียวที่รองรับทุกอย่างก็สะดวกดี" + "เชื่อมต่อกับฟังก์ชันอื่นได้ง่าย" ไม่ใช่เหรอครับ
พออินสแตนซ์เพิ่มขึ้นเรื่อย ๆ ก็ยิ่งน่ารำคาญขึ้นน่ะครับ..

nicewook 2023-06-28

อ๋อ เข้าใจแล้วครับ
ที่ Redis ชอบพ่วงโน่นนี่เพิ่มก็คงเป็นเพราะเหตุผลนั้นสินะ อืมๆ

iolothebard 2023-06-28

ไปๆ มาๆ...เทนเซอร์...