Vector Database คืออะไร? เบื้องหลังความฉลาดของ AI

ทำไมยุคนี้ใคร ๆ ก็พูดถึง Vector Database

ถ้าคุณเริ่มใช้งาน AI ในงานจริง ไม่ว่าจะเป็นระบบค้นหาเอกสาร, แชตบอตตอบคำถามจากข้อมูลในบริษัท หรือระบบแนะนำสินค้า มีโอกาสสูงมากที่คุณจะได้ยินคำว่า “vector database” โผล่มาด้วยเสมอ

คำถามคือ

• ทำไมอยู่ดี ๆ ฐานข้อมูลแบบเดิม (Relational / SQL) ถึงดูเหมือน “ไม่พอ” สำหรับงาน AI ยุคใหม่?
• vector database มันต่างจากฐานข้อมูลทั่วไปยังไง?
• แล้วองค์กรหรือทีมของเราจำเป็นต้องใช้มันจริง ๆ ไหม?

บทความนี้จะพยายามตอบทุกคำถามในระดับเข้าใจได้ ไม่ต้องเป็น Data Scientist ก็อ่านรู้เรื่อง แต่ลึกพอให้คนทำงานสาย IT, PM, SA หรือแม้แต่ผู้บริหาร นำไปใช้ประกอบการตัดสินใจเชิงกลยุทธ์ได้

Vector Database คืออะไร?

vector คืออะไรในมุมของ AI

ในทางคณิตศาสตร์ “เวกเตอร์ (vector)” คือชุดตัวเลขเรียงต่อกัน เช่น [0.12, -0.87, 0.33, …] ในโลก AI เราใช้เวกเตอร์เพื่อ แทนความหมายของข้อมูล บางอย่าง เช่น

• ประโยคหนึ่งประโยค
• รูปภาพหนึ่งรูป
• ไฟล์เอกสารหนึ่งไฟล์
• แม้กระทั่งผู้ใช้ (user) คนหนึ่งในระบบ

ขั้นตอนนี้เรียกว่า “embedding” — แปลงข้อมูลดิบให้กลายเป็นชุดตัวเลข (เวกเตอร์) ที่เก็บ “ลักษณะสำคัญ” ของข้อมูลนั้นไว้ เช่น โทนเนื้อหา, ความหมาย, บริบท

ตัวอย่างง่าย ๆ

• คำว่า “รถยนต์” กับ “รถกระบะ” จะได้เวกเตอร์ที่อยู่ใกล้กัน
• แต่คำว่า “รถยนต์” กับ “ก๋วยเตี๋ยว” เวกเตอร์จะห่างกันมากเพราะความหมายคนละเรื่อง

ตรงนี้สำคัญ เพราะทำให้เรา ค้นหาตามความหมาย (semantic search) ได้ ไม่ใช่แค่หาแบบตรงตัวตามคำในข้อความอีกต่อไป

แล้ว vector database คืออะไร?

vector database ก็คือฐานข้อมูลที่ออกแบบมาเพื่อ:

• เก็บเวกเตอร์จำนวนมาก (เช่น หลักล้าน–หลักพันล้านเวกเตอร์)
• ค้นหา “เวกเตอร์ที่ใกล้เคียงที่สุด” ได้เร็วมาก
• รองรับการทำงานในระดับ production (index, scale, security ฯลฯ)

นี่คือเหตุผลที่ vector database กลายเป็นหัวใจของระบบ AI เชิงความหมาย (semantic AI) เกือบทุกประเภทในปัจจุบัน

ทำไมฐานข้อมูลแบบเดิมถึงไม่พอสำหรับงาน AI บางประเภท

ฐานข้อมูลแบบ Relational หรือ NoSQL ยังสำคัญและจำเป็นมาก แต่พอเราเริ่มทำงานกับ AI + ข้อมูลที่มีความหมายซับซ้อน เช่น ภาษา รูปภาพ เสียง จะเริ่มเจอปัญหาประมาณนี้:

1. การค้นหาแบบคำตรง ๆ จำกัดเกินไป

ตัวอย่างเช่น คนพิมพ์คำถามว่า “วิธีจัดการพนักงานขาดงานบ่อย” แต่ในเอกสารใช้คำว่า “การบริหารกรณีการมาทำงานไม่ครบชั่วโมง” การค้นหาแบบ keyword ปกติอาจหาไม่เจอ ทั้ง ๆ ที่จริงเป็นเรื่องเดียวกัน

2. ข้อมูลไม่ได้อยู่ในรูปแบบตารางอย่างเดียว

ข้อมูลจำนวนมากในยุคนี้เป็น unstructured data เช่น เนื้อหาใน PDF, อีเมล, transcript จากการประชุม ซึ่งไม่เหมาะจะเก็บและค้นหาด้วยรูปแบบแถว–คอลัมน์อย่างเดียว

3. การจัดอันดับผลลัพธ์แบบ “ใกล้เคียงที่สุด” ทำได้ยาก

แม้จะใช้เทคนิค full-text search ก็ยังไม่เข้าใจ “ความหมายลึก ๆ” เท่า embedding + vector search

ตรงนี้แหละที่ vector database เข้ามาช่วยเติมเต็ม ไม่ได้มาแทนที่ database เดิมทั้งหมด แต่เข้ามาเป็น “ขาใหม่” ของ architecture ข้อมูลในยุค AI

ภาพรวมการทำงานของ vector database

ลองมองภาพการทำงานเป็น 4 ขั้นตอนหลัก ๆ ดังนี้:

1. แปลงข้อมูลเป็นเวกเตอร์ (Embedding)

นำข้อมูลดิบ เช่น ข้อความ, ย่อหน้า, เอกสาร, metadata ส่งเข้าโมเดล AI (embedding model) แล้วได้ผลลัพธ์เป็นเวกเตอร์ เช่น 768 หรือ 1,536 มิติ แล้วแต่โมเดล

ตัวอย่าง: ประโยค “นโยบายการลาหยุดประจำปีของบริษัท” ถูกแปลงเป็นเวกเตอร์ลิสต์ยาว ๆ เช่น [0.02, -0.13, …, 0.89]

2. เก็บเวกเตอร์ลงใน vector database

เวลาเก็บข้อมูล เราไม่ได้เก็บแค่ค่าเวกเตอร์ แต่เก็บพร้อมกับ:

• ข้อมูลอ้างอิง เช่น ID, ชื่อเอกสาร, path ไฟล์ เป็นต้น
• metadata เช่น แผนก, ปี, ประเภทเอกสาร เพื่อใช้ filter เพิ่มเติม

3. ตอนค้นหา: แปลงคำถามเป็นเวกเตอร์ แล้วหา “เพื่อนบ้านที่ใกล้ที่สุด”

เมื่อผู้ใช้พิมพ์คำถาม เช่น “พนักงานลาพักร้อนสูงสุดได้กี่วัน”:

1. แปลงคำถามเป็นเวกเตอร์ด้วย embedding model เดียวกัน
2. ส่งเวกเตอร์นี้เข้า vector database
3. ฐานข้อมูลใช้ algorithm เช่น Approximate Nearest Neighbor (ANN) เพื่อหาเวกเตอร์ที่ใกล้ที่สุดตาม metric เช่น cosine similarity
4. ส่งรายการเอกสาร/ข้อมูลที่ใกล้เคียงที่สุดกลับมา พร้อมคะแนนความใกล้เคียง

4. นำผลลัพธ์ไปใช้งานต่อ

ผลลัพธ์จาก vector database มักถูกใช้ร่วมกับ:

• LLM / ChatGPT เพื่ออ่านเนื้อหาแล้วสรุปหรือตอบเป็นภาษาคน
• ระบบ recommendation เพื่อจัดอันดับสิ่งที่ควรแนะนำ
• ระบบ search ที่เน้น “ความเข้าใจ” มากกว่า “คำตรงตัว”

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

1. ระบบค้นหาแบบ Semantic Search

จากเดิม: เสิร์ชคำว่า “ลางาน” แต่อาจไม่เจอเอกสารชื่อ “การบริหารกรณีการมาทำงานไม่ครบ” เพราะคำใช้ไม่เหมือนกัน

เมื่อใช้ vector database ระบบมองที่ ความหมาย ไม่ใช่แค่ตัวอักษร ทำให้ค้นหา policy, เอกสารภายใน, คู่มือ, FAQ ที่มีความหมายใกล้คำถามได้แม่นยำ

นี่คือพื้นฐานของแนวทาง RAG (Retrieval-Augmented Generation) ที่ใช้ในแชตบอตตอบคำถามจากข้อมูลองค์กร

2. แชตบอตองค์กรที่ตอบจากข้อมูลจริง

หลายบริษัทอยากได้ “ChatGPT เวอร์ชันองค์กร” ที่ตอบจากข้อมูลตัวเอง:

• พนักงานถามว่า “สิทธิประโยชน์ของพนักงานระดับ Senior มีอะไรบ้าง”
• ระบบต้องตอบจาก policy จริงของบริษัท ไม่ใช่ข้อมูลทั่วไปในอินเทอร์เน็ต

สถาปัตยกรรมที่พบได้บ่อยคือ:

1. แปลงทุกเอกสารของบริษัท → embedding → เก็บใน vector database
2. ตอนพนักงานถาม → แปลงคำถามเป็น embedding → ค้นหาเอกสารที่ใกล้เคียง
3. ส่งเอกสารที่เกี่ยวข้องไปให้ LLM อ่านและสรุปเป็นคำตอบ

3. ระบบแนะนำสินค้า / คอนเทนต์ (Recommendation)

ตัวอย่างการใช้ vector database ในงานแนะนำ (recommendation):

• เก็บ embedding ของสินค้าแต่ละชิ้น จากคำอธิบาย, รูปภาพ, หมวดหมู่ ฯลฯ
• เก็บ embedding ของผู้ใช้แต่ละคนจากพฤติกรรมการดู, คลิก, ซื้อ
• ใช้ vector database เพื่อหาสินค้าที่ “ใกล้ความสนใจ” ของผู้ใช้นั้นที่สุด

ผลลัพธ์คือระบบแนะนำจะเข้าใจ “สไตล์” หรือ “ความชอบ” มากกว่าการใช้กฎแบบเดิมอย่าง “คนที่ซื้อ A มักซื้อ B”

4. การจัดกลุ่มและวิเคราะห์ข้อมูลที่ซับซ้อน

เมื่อเรามีเวกเตอร์จำนวนมาก เราสามารถนำไปใช้ทำงานวิเคราะห์ต่อได้ เช่น:

• จัดกลุ่มเนื้อหาคล้ายกัน (clustering)
• วิเคราะห์ความใกล้เคียงของเนื้อหาข้ามแหล่งข้อมูล
• ตรวจจับเนื้อหาที่ผิดปกติหรือเป็น outlier

แม้ขั้นตอนวิเคราะห์อาจทำในระบบอื่น แต่การมี vector database ทำให้การดึงและจัดการเวกเตอร์ในระดับ production เป็นเรื่องง่ายขึ้นมาก

ตัวอย่างประเภทของระบบที่เกี่ยวข้องกับ vector database

แยกตามประเภทภาพรวม :

แนวคิดเบื้องหลังเหมือนกันคือ เก็บเวกเตอร์ + ค้นหาใกล้เคียงได้เร็ว ส่วนจะเลือกใช้แบบไหน ขึ้นกับ requirement, ecosystem และข้อจำกัดของแต่ละองค์กร

vector database ไม่ได้มีแต่ข้อดี: สิ่งที่ควรรู้ก่อนใช้

1. ต้องเข้าใจ embedding ให้ดี

vector database เก่งเรื่อง “เก็บ” และ “ค้นหา” เวกเตอร์ แต่ถ้า embedding ที่ใช้ไม่ดี เช่น โมเดลไม่เหมาะกับภาษาไทย หรือโดเมนต่างกันมาก ผลลัพธ์การค้นหาก็จะ “ไม่ฉลาด” เท่าที่ควรทันที

แนวทางที่ควรทำ:

• เลือก embedding model ให้เหมาะกับภาษา/โดเมนขององค์กร
• ทดสอบคุณภาพการค้นหากับ use-case จริง
• ปรับปรุง pipeline embedding เป็นระยะตามข้อมูลที่เปลี่ยนไป

2. ขนาดข้อมูลและค่าใช้จ่าย

เวกเตอร์หนึ่งตัวอาจมีหลายร้อยถึงหลายพันมิติ เมื่อเก็บในระดับหลักล้านเวกเตอร์ขึ้นไป:

• ขนาดฐานข้อมูลจะเติบโตเร็ว
• การสร้าง index และอัปเดตอาจใช้ทรัพยากรสูง
• ต้องวางแผน storage, scaling และต้นทุนให้ดี

3. Latency และประสบการณ์ผู้ใช้ (UX)

งานอย่างแชตบอตหรือระบบค้นหาที่รองรับผู้ใช้จำนวนมาก ต้องการเวลาในการตอบสนองที่รวดเร็ว:

• ถ้าออกแบบ index หรือ hardware ไม่ดี query ที่ซับซ้อนอาจทำให้ระบบช้า
• การผสม filter metadata หนัก ๆ กับการค้นหาคล้ายคลึงกันอาจเพิ่ม latency ได้

4. ต้องวางสถาปัตยกรรมร่วมกับระบบเดิม

vector database ไม่ได้มาแทน:

• Relational DB ที่เก็บธุรกรรม
• Data warehouse สำหรับงาน BI และรายงาน

แต่จะอยู่ร่วมกันใน architecture แบบใหม่ เช่น:

• ระบบหลักยังเก็บข้อมูลธุรกรรมในฐานข้อมูลเดิม
• ข้อมูลเนื้อหา/เอกสาร/text/log → ทำ embedding → เก็บใน vector database
• มี service ชั้นกลาง (API / microservice) เชื่อมข้อมูลระหว่างสองฝั่ง