Vector Database ทำงานยังไง ทำไม RDBMS ไปไม่รอดในยุค AI Semantic Search

ช่วงไม่กี่ปีที่ผ่านมา เราเห็น Vector Database บูมกันหนักมาก ๆ โดยเฉพาะเมื่อไม่กี่ปีก่อนที่เราเริ่มมีการเอา RAG มาใช้กันกับ AI กันมากขึ้นเรื่อย ๆ หลายคนถามเข้ามาว่า แล้วทำไม เราไม่ใช้ Relational Database ปกติเหมือนเดิม ทำไมเราต้องเปลี่ยนด้วย วันนี้เราจะมาเล่าให้อ่านกันว่า ทำไมถึงเป็นแบบนั้น และมันทำงานอย่างไร แตกต่างจาก Database แบบเดิม ๆ ที่เราใช้งานอย่างไร

เมื่อวิธีการค้นหาเปลี่ยนไป จาก "คำ" สู่ "ความหมาย"

ถ้ามองย้อนกลับไปที่วิธีการค้นหาข้อมูลจาก Relational Database แบบเดิม ๆ มันคือการใช้ SELECT WHERE แล้ว LIKE สักอย่าง การทำงานแบบนี้เราเรียกว่า Lexical Search หรือการค้นหาตามอักษร เบื้องหลังมันคือการใช้ B-Tree Index ซึ่งเก่งมาก ๆ ในการจัดเรียงข้อมูลที่มีทิศทางชัดเจน หรือการทำ Hash Index เพื่อจับคู่คำแบบ Exact Match เป๊ะ ๆ ปัญหาของวิธีนี้คือ มันไม่เข้าใจบริบท

เช่น เราหาคำว่า "สุนัข" ระบบจะไม่ค้นหาคำอื่นที่มีความหมายเดียวกัน เช่น "หมา" หรือ "ลูกหมา" มด ๆ เลย เว้นแต่ เราจะไปเขียน Rules หรือทำ Synonym Dictionary ดักเอาไว้ ซึ่งในข้อมูลสเกลมหาศาล การจะทำแบบนั้นคือ ลายตุย แน่นอน

เมื่อโลกเราก้าวไปสู่ยุคของพวก AI และ LLM เราว่ามันทำให้กระบวนการที่เรามองข้อมูลพวกนี้เปลี่ยนไป Model พวกนี้มันไม่ได้อ่านภาษาไทย หรืออังกฤษตรง ๆ แต่มันอ่านตัวเลข ข้อมูลทุกอย่างที่เป็น Unstructured Data ไม่ว่าจะเป็น ข้อความ, รูปภาพ และเสียง จะต้องผ่าน Embedding Model เพื่อเอาความหมายและบริบทออกมาให้อยู่ในรูปแบบ Vector หรือก็คือ Array ของตัวเลขในมิติที่สูงมาก ๆ เช่น 1,500 มิติ

พอเรา Groupping ดี ๆ โดยการใช้ Vector เรามักจะเห็นความสัมพันธ์ว่า อย่างคำว่า "สุนัข" และ "หมา" อาจจะไม่ได้เขียนเหมือนกันในทางตัวอักษร แต่ใน Vector Space จุดสองจุดนี้ มันอาจจะวางใกล้กันมาก เพราะมันมีความหมายไปในทิศทางเดียวกัน

ถามต่อว่า แล้วทำไมเราไม่เอา Vector Array ที่ว่า ไปยัดใส่พวก JSONB หรือ TEXT ใน RDBMS แล้ว Query ออกมาละ ตอบสั้น ๆ คือ Performance ห่วยกระจาย เพราะเวลาเราหาข้อมูลที่มีความหมายใกล้เคียง เราไม่ได้หาค่าที่เท่ากันเป๊ะ ๆ แต่เราต้องคำนวณหา "ระยะทางที่สั้นที่สุด" ระหว่าง Vector 2 เส้น โดยใช้สมการทางคณิตศาสตร์ เช่น Cosine Similarity

ปัญหามันจะเกิดขึ้นตรงนี้แหละว่า โครงสร้างของ B-Tree ไม่สามารถใช้จัดดเรียงข้อมูลที่มีมิติสูงระดับพัน หรือ หมื่นมิติได้ เรื่องนี้ถ้าใครเคยทำ Traditional Machine Learning มาก่อน น่าจะเคยได้ยินปรากฏการณ์ที่เรียกว่า The Curse of Dimensionality

นั่นหมายความว่า ถ้ามีข้อมูล 1 ล้าน Rows และต้องการหาข้อมูลที่คล้ายกันมากที่สุด Database เราจะต้องทำ Full Table Scan โดยดึง Vector 1 ล้านชุดขึ้นมาบน RAM แล้วรัน Cosine Similarity เพื่อหาค่าที่ใกล้เคียงที่สุด ผลก็คือ Query เพียงครั้งเดียว เสียวทั้ง CPU พุ่ง 100% และระบบไม่น่าจะรอด หากมี Concurrent เข้ามาพร้อมกันเยอะ ๆ

มันจะกลายออกไปในอารมณ์ว่า เหมือนเราใช้ส้อมไปขุดดิน ทั้ง ๆ ที่มีจอบอยู่ เพราะสถาปัตยกรรมของ RDBMS เขาออกแบบมาเพื่อรับประกันความถูกต้องของข้อมูลเป็นหลักผ่าน ACID Properties และการเขียนลง Disk อย่างปลอดภัย ไม่ได้ออกแบบมาเพื่อรัน Linear Algebra และนี่แหละ คือ รอยรั่วที่ Vector Database เข้ามาแก้ไข

จาก Extension Library สู่ Database ในยุค AI

ก่อนเราจะไปพูดถึไส้ในมัน เราอยากพูดถึง Evolution ของ Vector Database กันก่อน ในช่วงแรกที่เราทำ Machine Learning กัน ก็เริ่มมีการทำ Vector Embeddings ได้ในระดับที่ใช้งานกันจริงได้แล้วแหละ แต่มันยังไม่มี Database ที่รองรับ Data Structure แบบนี้โดยเฉพาะ การแก้ปัญหาตอนนั้นคือ การทำ Library ที่เกิดมาเพื่อรันการคำนวณบน RAM เป็นหลัก ตอนนั้นถ้าที่ดัง ๆ เลยก็ FAISS ของ Meta ที่เปิดมาในช่วงปี 2017 ตอนนั้นก็คือ ฮือฮ่ากันพอสมควรเลย

เหตุที่ตอนนั้นต้องเอามารันบน RAM ทิ้งไว้ เป็นเพราะ มันทำให้ CPU สามารถดึงไปคำนวณต่อได้เร็วมาก ๆ หรือในเวลาต่อมา ก็เริ่มยกการคำนวณพวกนี้ไปยัดใส่ GPU ก็เรียกว่า ทำให้ทำงานได้เร็วขึ้นมาก ๆ เช่นการทำ Nearest Neighbor Search แทนที่จะใช้ CPU ทำทีละ 8-16 Data Point เราให้ GPU ที่มีหลักพัน Core ทำพร้อมกันซะเลย เร็วกว่ากันเยอะมาก แต่ถึงมันจะทำงานได้เร็วขนาดไหน แต่มันก็สอบตกในความเป็น Database ความชิบหายเกิดตอนระบบเกิดล่ม ไม่มีระบบรองรับ Consistency และการ Update ข้อมูลแบบ Real-time ทำได้ดีสุดคือเก็บไว้ก่อน แล้วมารัน Batch ตอนกลางคืน เพื่อ Rebuild Index (เหมือนธนาคารสมัยก่อนนนนนน โน้นนนนน ที่โอนเงินแล้วเข้าพรุ่งนี้เช้าอะ)

ความสนุกมันเกิด เมื่อ AI นางโตเร็วมาก ๆๆ ข้อมูลมันไม่ได้อยู่ในหลักพัน หรือหมื่นแล้ว มันโตไประดับ Billion หรือ พันล้านจุดแล้ว แน่นอนว่า พี่จะหา RAM ใหญ่ขนาดนั้นจากไหนมารันในเครื่องเดียว ไม่มีทางแน่นอน ทำให้มันจะต้องมีการออกแบบใหม่ตั้งแต่ระดับ Storage Layer นี่แหละ คือจุดเริ่มต้นที่ทำให้เกิด Native Vector Database หรือ Vector Database เพียว ๆ ที่เกิดมาเพื่อเป็น Vector Database แต่แรกเลย เช่นพวก Qdrant, Pinecone และ Mulvus ต้ังแต่ช่วงปี 2019 ถึง 2021 (จำได้ว่า ตอนนั้นใช้ Qdrant ครั้งแรกแล้ว ตื่นเต้นมาก ๆ)

ระบบพวกนี้ มันถูกออกแบบมาเพื่อให้ทำงานในสถาปัตยกรรมสมัยใหม่ขึ้นมา บน Distributed System รองรับการทำ Load Balancing และ Sharding ข้าม Multi-Node server มีการจัดการ Data Persistence ที่ซับซ้อน เขียนข้อมูลลง Disk ผ่านการใช้ Memory-Mapped File กับรวมเอา Algorithm อย่าง HNSW (Hiwearchical Navigable Small Word) เข้ามาเป็นแกนหลักในระบบ Indexing ทำให้วิ่งโดดไปมาในข้อมูลมิติสูง ๆ ได้เร็วหลักเสี้ยววินาที โดยไม่ต้อง Full Table Scan อีกต่อไป

ปัญหาใหม่เกิดอีก เมื่อ ข้อมูลมันใหญ่จัด ๆ เราเลยแยกข้อมูลดิบ เก็บไว้ใน Database นึง แล้วเอา Vector เก็บไว้อีกที่นึง นำมาซึ่งต้นทุนในการ MA มหาศาล และการจัดการ Data Synchronisation เพื่อให้ข้อมูลทั้งสองฝั่งตรงกันตลอดเวลา ฝั่ง RDBMS เลยบอกว่า โน ๆๆๆ เราจัดการได้ ตัวอย่างเช่น pgvector บน PostgreSQL

สิ่งที่เขาทำกันคือ เขียน Extension ที่อนุญาติให้เราเก็บข้อมูล Array ของตัวเลขในหลักพันมิติ คู่ไปกับ Relational Data ไว้ใน Row เดียวกัน แต่ความเจ๋งคือ การเปิดให้นักพัฒนาใช้คำสั่ง SQL เดิมนั่นแหละ Query ได้เลย แต่สามารถสร้าง Index ทับลงไปบน Vector Column นั้นได้ทันที นั่นทำให้เกิดระบบที่ผสานความเสถียรของ Transactional Engine เข้ากับความเร็วในการทำ Semantic Search ได้ในตัวเอง

Vector Database vs RDBMS

การจะเข้าใจว่าทำไม Vector Databaes ถึงทำงานกับข้อมูลมิติสูง ๆ ได้เร็วกว่าฐานข้อมูลแบบเดิม ๆ เราจะต้องเข้าใจการออกแบบโครงสร้างพื้นฐานของทั้งสองระบบนี้ เพราะมันจะทำให้เราเห็นเลยว่า ทั้งสองระบบมันถูกคิดมาโดยมีไอเดียคนละแบบโดนสิ้นเชิง

RDBMS อย่าง PostgreSQL หรือ MySQL ถูกออกแบบมาพร้อมกับ Storage ที่เน้นความสมบูรณ์ และ ความถูกต้อง ของข้อมูลเป็นหลัก มักจะเก็บข้อมูลเป็น Raw-Based หรือ Columnar ซึ่งถูกตีกรอบด้วย Schema ที่กำหนดไว้อย่างชัดเจน ซึ่งเราจะเห็นจากการทำตาม ACID Properties เพื่อรับประกันว่า ทุก Transaction จะถูกเขียนลง Disk อย่างปลอดภัย

ในทางตรงกันข้าม Vector Database ถูกปรับแต่งมาเพื่อการทำงานกับ Array ของตัวเลข Storage Engine ของระบบพวกนี้มักจะทอนความเข้มงวดของ ACID Properties บางอย่างลงไป แล้วหันมาพึ่งกลุ่ม Memory-First หรือการใช้ Memory-Mapped File หรือก็คือ การเอาข้อมูล Vector มาพักไว้ใน RAM ให้ได้มากที่สุด เร็วที่สุด เพราะความเร็วในการทำงานของพวก Distancing มันจะแย่มาก ๆ หากเราต้องรอ Disk I/O นาน ๆ

ในฝั่งของการ Search ข้อมูลก็แตกต่างกันโดยสิ้นเชิงอีก RDBMS เป็นแบบ Deterministic หมายความว่า ผลลัพธ์จากการ Query จะต้องถูกต้อง เหมือนเดิมเสมอ คาดการณ์ได้ หากใช้ข้อมูล และเงื่อนไขเดียวกัน แต่ Vector Database บอกว่า ไม่ ๆๆ เราจะใช้ Probabilistic แทน ยอมแลกความแม่นลงไปเล็กน้อย เพื่อให้ได้มาซึ่งความเร็วมหาศาล ระบบจะไม่พยายามคำนวณระยะทางเปรียบเทียบกับทุก Data Point แต่จะใช้การคาดเดา และค้นหาเจาะจงเฉพาะกลุ่มข้อูลที่มีแนวโน้มว่าจะอยู่ใกล้เคียงกับคำค้น (Keyword) มากที่สุดเท่านั้น ถ้าใครเรียนมา น่าจะคุ้น ๆ คำว่า Approximate Nearest Neighbor (ANN) กันไม่มากก็น้อย

และความต่างสุดท้ายได้เล่าไปบ้างแล้วนั่นคือ Indexing ที่ฝั่ง RDBMS เราใช้ B-Tree เป็น Gold Standard ในการทำงาน โดยมี Big-O ที่ O(log N) แน่นอนว่า เร็วโคตร ๆ ตราบใดที่ข้อมูลมีทิศทางการจัดเรียงที่ชัดเจน แต่พอต้องเจอกับ Vector Array มิติสูง ๆ B-Tree ก็คือแตกยับจากการต้องทำ Full Table Scan

Vector Database รื้อออกหมดไม่เอาแล้ว ไปใช้ HNSW โครงสร้างลักษณะนี้จะเปลี่ยนมุมมองการเรียงข้อมูลตามลำกับ มาเป็นการสร้าง Graph หลาย ๆ Layer ซ้อน ๆ กัน กลไกของ Graph พวกนี้อนุญาติให้เรากระโดดข้ามกลุ่ม Vector ที่อยู่ห่างไกลใน Layer บน ๆ ได้เร็ว ก่อนจะโดดกลับลงไปหา Vector เป้าหมาที่อยู่ล่างสุดที่มีความละเอียดสูง อารมณ์เหมือนบินโฉบขึ้นไปดูภาพรวม แล้วค่อย ๆ ไล่ ๆ ลงไปเรื่อย ๆ นั่นทำให้มัน Navigate บน High-Dimensional Data ได้ในระดับเสี้ยววินาที

The Hybrid Approach

การเอา Vector Database มาใช้งานจริง มันไม่สามารถใช้แค่นั้นได้ สุดท้ายแล้วเราก็ยังต้องการ RDBMS สำหรับเก็บข้อมูลบางส่วนอยู่ แล้วให้ Vector Database ทำงานเป็นเบื้องหลังของ Search Engine ที่ทำงาน Parallel กันไป

หัวใจหลักของการออกแบบระบบแบบ Hybrid อยู่ที่ การกำหนดให้ RDBMS เป็น Single Source of Truth หรือแหล่งข้อมูลหลักที่ถูกต้องเพียงแหล่งเดียว ข้อมูลที่มีความสำคัญระดับ Business Logic เช่น User Data, ราคา และประวัติการทำงาน จะต้องถูกเก็บและปกป้องอย่างแน่นหนาภายใต้ ACID ของ RDBMS ส่วน Vector Database รับหน้าที่เฉพาะ Vector Embedding ซึ่งเป็นเพียง ร่างจำแลงทางคณิตศาสตร์ของชุดข้อมูลเท่านั้น แล้วเชื่อมต่อผ่าน ID อาจจะเป็นตัวเลข หรือ UUID ของ Record ไว้เท่านั้น

ความเจ๋งของการออกแบบลักษณะนี้คือ เมื่อ User ป้อน Keyword ที่ซับซ้อน ระบบจะไม่ได้ส่งคำนั้นไปหาใน RDBMS เท่านั้น แต่จะเอาไปวิ่งผ่าน Embedding Model แล้วแปลงให้เป็น Query Vector จากนั้นค่อยยิงไปหา Vector Database เพื่อทำการหาระยะที่ใกล้เคียงที่สุดผ่าน ANN

เมื่อ Vector Database ทำงานเสร็จ มันจะคืนค่ากลับมาเป็น UUID ที่มีความหมายตรงกับคำค้นหามากที่สุดกลับมา จากนั้นระบบจะเอา UUID ไปสร้างคำสั่งเรียกข้อมูลเต็ม ๆ ออกจาก RDBMS อีกครั้ง กระบวนการสลับไปมาระหว่าง การหาความหมายใน Vector Space และการดึงข้อมูลต้นฉบับจาก Relational Table เกิดขึ้นอยู่เบื้องหลัง โดย User ไม่รู้เรื่องเลย เนียนกริ๊บเลยละ

สรุป

การที่ AI เข้ามามันไม่ได้เข้ามาทำลาย หรือทดแทน การใช้ Database แบบเดิม ๆ ที่เราใช้กันมานานมาก ๆ อย่าง Relational Database เพราะก็ยังตอบเหมือนเดิมว่า มันก็ยังคงเป็นรากฐานที่แข็งแกร่ง ขาดไม่ได้ในการรักษาสถานะของระบบ และการจัดการข้อมูลที่ต้องการความถูกต้องขั้นสุด แต่ในขณะเดียวกัน ด้วยข้อจำกัดของวิธีการทำงานที่ยึดติดกับการทำงานกับข้อมูลมิติเดียว ก็ทำให้ระบบเหล่านี้ไม่สามารถรับมือกับ Unstructured Data ที่มีอยู่เยอะแบบถล่มได้ นี่คือจุดที่ Vector Database เข้ามาเติมเต็มช่องว่างที่หายไป และทำให้มันเข้ามาเป็น Database ที่กำลังได้รับความสนใจมาก ๆ ในโลกที่ AI กำลังเข้ามามีบทบาทในการทำงานมากขึ้น