Vector Database คืออะไร? อธิบายพร้อมสเปกเครื่องที่ต้องเตรียมจริง

Vector database คืออะไร

Vector database คือฐานข้อมูลที่ออกแบบมาเก็บ "เวกเตอร์" ซึ่งก็คือชุดตัวเลขยาว ๆ ที่ใช้แทนความหมายของข้อความ รูปภาพ หรือเสียง แล้วค้นหาโดยดูว่าชุดตัวเลขไหนใกล้เคียงกับชุดตัวเลขของสิ่งที่เรากำลังหาที่สุด

ความต่างที่เป็นแก่นคือวิธีค้น ฐานข้อมูลที่คุณคุ้นเคยตอบคำถามแบบ "แถวไหนมีคำว่านี้บ้าง" หรือ "แถวไหนที่ราคามากกว่าหนึ่งพัน" ซึ่งเป็นการเทียบแบบตรงตัว ส่วน vector database ตอบคำถามคนละแบบ คือ "อะไรที่ความหมายใกล้เคียงกับสิ่งนี้ที่สุดสิบอันดับแรก" การค้นแบบนี้เรียกว่า similarity search หรือการค้นหาความคล้าย

ผลที่ตามมาในทางปฏิบัติคือ ถ้าเอกสารของคุณเขียนว่า "วันหยุดพักผ่อนประจำปี" แล้วมีคนถามว่า "ลาพักร้อนได้กี่วัน" การค้นแบบตรงตัวจะหาไม่เจอเพราะไม่มีคำว่าพักร้อนอยู่ในเอกสารเลย แต่การค้นด้วยเวกเตอร์จะเจอ เพราะสองประโยคนี้มีความหมายใกล้กัน แม้จะใช้คำคนละคำก็ตาม

Embedding คืออะไร แบบไม่ต้องมีพื้นคณิตศาสตร์

Embedding คือการเปลี่ยนข้อความหนึ่งท่อนให้กลายเป็นตัวเลขชุดหนึ่ง โดยตัวเลขชุดนั้นสะท้อนความหมายของข้อความ หลักการที่ต้องจำมีข้อเดียวคือ ข้อความที่ความหมายใกล้กันจะได้ตัวเลขที่ใกล้กัน ส่วนข้อความที่ความหมายไกลกันก็จะได้ตัวเลขที่ห่างกัน

ลองนึกถึงแผนที่ประเทศไทย ทุกจังหวัดถูกแทนด้วยตัวเลขสองตัวคือละติจูดกับลองจิจูด เชียงใหม่กับลำพูนมีตัวเลขใกล้กันเพราะอยู่ใกล้กันจริง ส่วนเชียงใหม่กับภูเก็ตมีตัวเลขห่างกันมาก ทีนี้ถ้ามีคนถามว่า "จังหวัดไหนอยู่ใกล้เชียงใหม่ที่สุด" คุณไม่ต้องอ่านชื่อจังหวัดเลย แค่คำนวณระยะห่างของตัวเลขก็ตอบได้

Embedding ทำแบบเดียวกันกับความหมาย ต่างกันตรงที่แทนที่จะใช้ตัวเลขสองตัวบนแผนที่แบน ๆ มันใช้ตัวเลขหลายร้อยถึงหลายพันตัวต่อหนึ่งข้อความ เพื่อให้มีที่ว่างพอจะแยกแยะความหมายที่ละเอียดกว่าตำแหน่งบนแผนที่มาก จำนวนตัวเลขต่อหนึ่งเวกเตอร์นี้เรียกว่ามิติ (dimensions) และเป็นค่าที่กำหนดโดยโมเดล embedding ที่คุณเลือกใช้ ไม่ใช่ค่าที่คุณตั้งเอง

คนที่สร้างตัวเลขชุดนี้ให้เราคือโมเดล embedding ซึ่งเป็นคนละตัวกับโมเดลภาษาที่ใช้ตอบคำถาม หน้าที่ของมันมีอย่างเดียวคือรับข้อความเข้าไปแล้วคืนตัวเลขออกมา คุณจะเรียกผ่าน API ของผู้ให้บริการ หรือจะรันโมเดลโอเพนซอร์สเองบนเครื่องก็ได้

ต่างจากฐานข้อมูลปกติยังไง

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

ใช้ทำอะไรได้บ้าง

งานที่ vector database เข้ามาช่วยมีจุดร่วมเดียวกันหมด คือเป็นงานที่ตัดสินด้วย "ความใกล้เคียง" ไม่ใช่ "ตรงเป๊ะ" กรณีที่พบบ่อยที่สุดในไทยตอนนี้คือเอาไปเป็นฝั่งค้นหาของระบบ RAG แต่ก็ยังมีงานอื่นอีกหลายอย่างที่ใช้กลไกเดียวกัน

• ระบบ RAG ให้ AI ตอบจากเอกสารของเรา — เก็บเอกสารที่ตัดเป็นท่อนไว้เป็นเวกเตอร์ พอมีคำถามก็ดึงท่อนที่เกี่ยวข้องที่สุดส่งให้โมเดลภาษาอ่านแล้วเรียบเรียงตอบ
• ค้นหาเชิงความหมายในเว็บหรือระบบภายใน — ผู้ใช้พิมพ์คนละคำกับที่เขียนไว้ในหน้าเว็บก็ยังหาเจอ ซึ่งช่วยมากกับภาษาไทยที่เขียนคำเดียวกันได้หลายแบบ
• แนะนำสินค้าหรือเนื้อหาที่คล้ายกัน — เอาคำอธิบายสินค้าแปลงเป็นเวกเตอร์ แล้วหาสินค้าที่ใกล้เคียงกับตัวที่ลูกค้ากำลังดูอยู่ โดยไม่ต้องมานั่งติดแท็กเองทุกชิ้น
• ตรวจของซ้ำและเนื้อหาใกล้เคียง — หาโพสต์ซ้ำ ลูกค้าซ้ำที่สะกดชื่อไม่เหมือนกัน หรือคำถามที่เคยมีคนถามไปแล้วในระบบซัพพอร์ต
• จัดกลุ่มคำถามและรีวิวอัตโนมัติ — รวมข้อความที่พูดเรื่องเดียวกันเข้ากลุ่มเดียวกัน เพื่อดูว่าลูกค้าบ่นเรื่องอะไรมากที่สุดโดยไม่ต้องอ่านทีละอัน
• ค้นรูปภาพหรือเสียงด้วยความคล้าย — หลักการเดียวกันทุกประการ เปลี่ยนแค่โมเดลที่ใช้แปลงเป็นเวกเตอร์ให้ตรงกับชนิดของข้อมูล

ตัวเลือกที่คนนิยมและรันเองได้

ตัวเลือกในตลาดมีเยอะมากจนเลือกไม่ถูก แต่ถ้าแบ่งเป็นประเภทตามวิธีติดตั้ง จะเหลือแค่ไม่กี่แบบและตัดสินใจง่ายขึ้นเยอะ ทุกแบบด้านล่างนี้ยกเว้นแบบสุดท้ายรันเองบนเครื่องของคุณได้ และส่วนใหญ่มีคู่มือติดตั้งแบบ Docker ให้ทำตามอยู่แล้ว

• ส่วนขยายของฐานข้อมูลที่มีอยู่แล้ว เช่น pgvector บน PostgreSQL — เหมาะที่สุดถ้าทีมคุ้นกับ SQL อยู่แล้วและไม่อยากเพิ่มบริการใหม่ให้ต้องดูแล ใช้การ backup และการจัดการสิทธิ์ชุดเดิมได้เลย
• ฐานข้อมูลเวกเตอร์เฉพาะทางที่รันเองได้ เช่น Qdrant, Weaviate, Milvus — ออกแบบมาเพื่องานนี้โดยตรง มีฟีเจอร์การกรองและการปรับดัชนีละเอียดกว่า เหมาะเมื่อข้อมูลเริ่มเยอะจนต้องปรับจูนจริงจัง
• ไลบรารีหรือฐานข้อมูลแบบฝังในแอป เช่น Chroma หรือไลบรารีค้นความคล้ายที่เก็บดัชนีเป็นไฟล์ — เริ่มง่ายที่สุด ไม่ต้องรันบริการแยก เหมาะกับการทำต้นแบบและงานที่ข้อมูลไม่เยอะ
• บริการคลาวด์แบบ managed — ไม่ต้องดูแลเซิร์ฟเวอร์เอง แลกกับการที่ข้อมูลออกไปอยู่นอกองค์กรและค่าใช้จ่ายผูกกับปริมาณการใช้งาน

แรมคือคอขวด: สเปกที่ควรเผื่อ

จุดที่คนพลาดมากที่สุดคือเลือกเครื่องตามจำนวน CPU แต่ตัวที่ตัดสินว่าระบบจะไหวหรือไม่คือแรม เหตุผลคือดัชนีค้นความคล้ายแบบที่นิยมใช้กันอย่าง HNSW ถูกออกแบบให้ทำงานในหน่วยความจำเป็นหลัก ถ้าดัชนีใหญ่เกินแรม ระบบจะเริ่มสลับข้อมูลลงดิสก์แล้วช้าลงอย่างชัดเจน หรือแย่กว่านั้นคือถูกระบบปิดกระบวนการทิ้งเพราะแรมหมด

ปริมาณแรมที่ต้องใช้คำนวณคร่าว ๆ ได้จากสามตัวคูณกัน คือจำนวนเวกเตอร์ที่เก็บ คูณด้วยขนาดเวกเตอร์ (จำนวนช่องตัวเลข) คูณด้วยขนาดของตัวเลขหนึ่งช่อง ซึ่งโดยทั่วไปเก็บเป็น float32 ที่กินช่องละ 4 ไบต์ จากนั้นต้องบวกโครงสร้างของดัชนีเข้าไปอีกส่วนหนึ่ง บวกแรมที่ระบบปฏิบัติการและบริการอื่นบนเครื่องใช้อยู่

ตัวเลขในตารางด้านล่างคำนวณจากสมมติฐานว่าเวกเตอร์มี 768 ช่อง เก็บเป็น float32 ซึ่งเป็นขนาดที่พบบ่อย ใช้เป็นตัวตั้งต้นเพื่อให้เห็นภาพลำดับความใหญ่เท่านั้น ของจริงจะต่างไปตามโมเดล embedding ที่คุณเลือกและชนิดดัชนีที่ใช้ ดังนั้นควรวัดจากข้อมูลจริงของคุณเองก่อนตัดสินใจซื้อระยะยาว

ข้อควรระวังก่อนขึ้นใช้งานจริง

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

เรื่องที่ต้องเน้นที่สุดคืออย่าเปิดพอร์ตของ vector database ออกสู่อินเทอร์เน็ตโดยไม่มีการยืนยันตัวตน หลายตัวติดตั้งมาแบบเปิดให้เข้าถึงได้ทันทีเพื่อความสะดวกในการทดลอง ถ้าคุณผูกพอร์ตนั้นกับ IP สาธารณะ เท่ากับเปิดให้ใครก็ได้อ่านและลบข้อมูลทั้งชุด และเนื้อหาที่อยู่ในนั้นคือเอกสารภายในของคุณทั้งหมด

• ปิดการเข้าถึงจากภายนอกเป็นค่าเริ่มต้น — ให้บริการฟังเฉพาะภายในเครื่องหรือเครือข่ายภายใน แล้วเข้าผ่านช่องทางที่ยืนยันตัวตนแล้วเท่านั้น เปิดใช้ API key และตั้งไฟร์วอลล์เสมอ
• แบ็กอัปดัชนีและข้อมูลกำกับให้ครบ — การสร้างดัชนีใหม่จากศูนย์เมื่อข้อมูลเยอะเป็นงานที่กินเวลาและกินค่าเรียก API ดังนั้นอย่าคิดว่าสร้างใหม่ได้เสมอเลยไม่ต้องแบ็กอัป
• เก็บข้อความต้นฉบับไว้ด้วยเสมอ — เวกเตอร์แปลงกลับเป็นข้อความเดิมไม่ได้ ถ้าเก็บแต่ตัวเลขแล้วต้นฉบับหาย คุณจะเหลือแค่ตัวเลขที่ใช้ประโยชน์ต่อไม่ได้
• เปลี่ยนโมเดล embedding เมื่อไหร่ ต้องสร้างดัชนีใหม่ทั้งหมด — เวกเตอร์จากคนละโมเดลเทียบกันไม่ได้ แม้จะมีจำนวนช่องเท่ากันก็ตาม การเผลอเปลี่ยนโมเดลกลางทางทำให้ผลค้นหาเพี้ยนแบบหาสาเหตุยาก
• บันทึกไว้ว่าใช้โมเดลอะไร เวอร์ชันไหน ตัดท่อนแบบไหน — ข้อมูลพวกนี้จำเป็นตอนต้องสร้างดัชนีใหม่หรือย้ายเครื่อง และมักไม่มีใครจำได้หลังผ่านไปหลายเดือน
• กรองสิทธิ์ตั้งแต่ตอนค้น — ถ้าเอกสารบางชุดบางคนไม่ควรเห็น ต้องใส่เงื่อนไขกรองในขั้นตอนค้นหา ไม่ใช่ไปหวังให้โมเดลภาษาเลี่ยงไม่พูดถึงทีหลัง

สรุป

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

สิ่งที่ควรจำไปตัดสินใจมีสองข้อ ข้อแรกคือแรมเป็นคอขวด ไม่ใช่ CPU ให้ประเมินจำนวนเวกเตอร์ที่จะมีจริงแล้วเผื่อแรมไว้ตั้งแต่ต้น ข้อสองคือความปลอดภัยต้องตั้งตั้งแต่วันแรก เพราะข้อมูลในนั้นคือเอกสารภายในของคุณ

ถ้าคุณกำลังจะเอาไปทำระบบตอบคำถามจากเอกสาร อ่าน RAG คืออะไร ต่อเพื่อเห็นภาพรวมทั้งระบบว่า vector database ไปวางอยู่ตรงไหน และถ้าอยากให้ข้อมูลไม่ออกนอกองค์กรเลย ลองดู Ollama ประกอบว่าการรันโมเดลเองบนเครื่องที่ไม่มี GPU ทำได้แค่ไหน ส่วนใครที่ยังไม่เคยเช่าเซิร์ฟเวอร์มาก่อน แนะนำเริ่มที่ VPS คืออะไร ก่อน เพราะการติดตั้งพวกนี้ต้องใช้สิทธิ์ root ซึ่งโฮสติ้งแบบแชร์ทั่วไปไม่ให้