Vector Database คืออะไร

Vector database ตอบคำถามเดียว ได้เร็วมาก

ให้ชุดตัวเลขแก่มัน แล้วมันจะคืนชุดตัวเลขที่เก็บไว้ซึ่งใกล้เคียงที่สุด นั่นคืออินเทอร์เฟซทั้งหมด

ชุดตัวเลขเหล่านั้นคือ embeddings โมเดล embedding จะแปลงข้อความหนึ่งย่อหน้า คำอธิบายสินค้า หรือรูปภาพ ให้กลายเป็นตัวเลขตั้งแต่ไม่กี่ร้อยไปจนถึงหลายพันตัว โดยจัดวางให้ความหมายที่คล้ายกันอยู่ใกล้กัน และ embeddings ในความหมายของ AI คืออะไร อธิบายวิธีการนี้ไว้ Vector database คือที่ที่ชุดตัวเลขเหล่านั้นอยู่เมื่อคุณมีมันจำนวนมาก มันเก็บแต่ละชุดพร้อมกับ ID และเมทาดาต้าบางส่วน สร้างดัชนีขึ้นมา และตอบคำถามแบบ nearest neighbour search: "นี่คือ query vector ให้สิบตัวที่ใกล้ที่สุดมาให้ฉัน"

ส่วนที่ยากคือคำว่าเร็ว การเทียบ query กับ vector ที่เก็บไว้หนึ่งล้านตัว แต่ละตัวมี 1,536 ตัวเลข คือการคูณ 1.5 พันล้านครั้ง และการทำแบบนั้นทุกครั้งที่พิมพ์ย่อมขยายขนาดไม่ไหว ดังนั้น vector database จึงใช้ดัชนีแบบ approximate nearest neighbour ที่พบบ่อยที่สุดคือ HNSW ซึ่งเป็นโครงสร้างกราฟจากงานวิจัยปี 2016 โดย Malkov และ Yashunin ที่ไปเยี่ยมผู้สมัครเพียงไม่กี่ร้อยตัวแทนที่จะเป็นทั้งล้านตัว และให้คำตอบที่ถูกต้องเกือบทุกครั้ง คำว่า "เกือบ" นี้คือข้อแลกเปลี่ยน: recall ที่ลดลงเล็กน้อยแลกกับความเร็วที่เพิ่มขึ้นนับพันเท่า

ฐานข้อมูลเดิมของคุณจับคู่คำ ส่วน vector database จับคู่ความหมาย

Relational database ค้นหาแถวที่ค่าตรงกัน: WHERE customer_id = 4127 ดัชนี full-text ค้นหาเอกสารที่มีคำนั้นอยู่: refund AND policy ส่วน vector database ค้นหารายการที่ความหมายใกล้เคียงกัน คำค้น "how do I get my money back" จะได้ย่อหน้าชื่อ "Returns and refunds" แม้ทั้งสองจะไม่มีคำร่วมกันเลยก็ตาม

แถวสุดท้ายแสดงให้เห็นว่าหมวดหมู่นี้เบลอแค่ไหน pgvector เพิ่มคอลัมน์เวกเตอร์และดัชนี HNSW เข้าไปใน Postgres ทั่วไป ส่วน Elasticsearch มีฟิลด์เวกเตอร์มาตั้งแต่เวอร์ชัน 7.0 ในปี 2019 และมี HNSW search ตั้งแต่เวอร์ชัน 8.0 ในปี 2022 "Vector database" มักเป็นความสามารถหนึ่งในฐานข้อมูลที่คุณใช้อยู่แล้ว มากกว่าจะเป็นผลิตภัณฑ์ใหม่ และผลิตภัณฑ์แบบสแตนด์อโลนก็แข่งกันที่สเกลและความเรียบร้อยในการใช้งาน ไม่ใช่ที่การทำสิ่งที่ Postgres ทำไม่ได้

Chat-with-your-documents คือการค้นหาแบบเวกเตอร์ที่ต่อท้ายด้วยโมเดล

Retrieval-augmented generation ซึ่ง RAG คืออะไร อธิบายไว้ มีขั้นตอนค้นหาและขั้นตอนเขียนคำตอบ vector database คือขั้นตอนค้นหา

1. แบ่งแต่ละเอกสารออกเป็นย่อหน้าละไม่กี่ร้อยถึงหนึ่งพันโทเคน
2. ทำ embed ทุกย่อหน้าและเก็บเวกเตอร์ พร้อมข้อความย่อหน้าและแหล่งที่มา ไว้ใน vector database
3. เมื่อคำถามมาถึง ให้ embed คำถามนั้นแล้วขอย่อหน้าที่ใกล้ที่สุดจากฐานข้อมูล
4. ส่งย่อหน้าเหล่านั้นให้โมเดลภาษาพร้อมกับคำถาม แล้วปล่อยให้มันเขียนคำตอบ

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

เมื่อไหร่ที่คุณต้องใช้ และเมื่อไหร่ที่ส่งทั้งไฟล์ดีกว่า

การตัดสินใจอยู่ที่ขนาด โมเดลพิจารณาได้แค่ context window ของมันในคราวเดียว และทุกโทเคนในนั้นต้องจ่ายเงินทุกครั้งที่คุยกัน vector database มีไว้เพื่อวางเฉพาะส่วนที่เกี่ยวข้องไว้ตรงหน้าโมเดล สำหรับเอกสารชิ้นเดียวที่ใส่พอดี การค้นหาเป็นขั้นตอนที่คุณข้ามได้ แต่สำหรับคอลเลกชันที่ใส่ไม่พอ มันคือทางเลือกเดียว

ลองคิดราคาการออกแบบทั้งสองแบบบนรายงาน 300,000 โทเคน หลายร้อยหน้า ถามสิบคำถาม ดึงย่อหน้าที่มี 1,000 โทเคนมาห้าย่อหน้าต่อคำถาม การส่งทั้งไฟล์ทุกครั้งคือ 3 ล้านอินพุตโทเคน การดึงห้าย่อหน้าที่มี 1,000 โทเคนต่อคำถามคือ 50,000 โทเคน ที่อัตราราคาลิสต์อินพุตใน ดัชนีต้นทุนโมเดล AI ซึ่งดึงมาจาก OpenRouter เมื่อวันที่ 2026-08-20 ส่วนต่างคือ 60 เท่าในทุกโมเดล การทำ prompt caching ในที่ที่ผู้ให้บริการมีให้ จะคิดราคาการอ่านไฟล์เดิมซ้ำที่หนึ่งในสิบถึงครึ่งหนึ่งของราคาลิสต์ ซึ่งทำให้ส่วนต่างแคบลงเหลือประมาณ 6 ถึง 30 เท่า การดึงข้อมูลยังคงชนะ แต่ชนะน้อยลง

การออกแบบแบบส่งทั้งไฟล์คุ้มเงินตรงที่เมื่อไฟล์พอดีกับงบประมาณ สัญญา 60 หน้า ราวๆ 40,000 โทเคน ทำให้โมเดลตอบคำถามที่ต้องใช้เอกสารทั้งฉบับพร้อมกันได้ เช่น "มีอะไรในนี้ที่ขัดแย้งกับข้อ 14 หรือไม่" ซึ่งการดึงข้อมูลถามไม่ได้ เพราะมันไม่เคยเห็นข้อ 14 กับข้อขัดแย้งอยู่ในชุดเดียวกัน กฎที่ได้จากตรงนี้คือ เอกสารเดียวหรือไม่กี่ฉบับ ให้ใส่ทั้งฉบับ ส่วนคลังเอกสารขนาดใหญ่ให้ผ่าน vector database ระหว่างสองแบบนี้ ให้แบ่งการอัปโหลดตามหัวข้อ เพื่อให้โมเดลได้ส่วนที่มันต้องการ

Whizi ส่งข้อความจริงตรงๆ ได้สูงสุด 40,000 โทเคนต่อรอบ

Whizi ไม่ได้รัน vector database สำหรับแชตของคุณ เมื่อคุณแนบไฟล์ ระบบ อัปโหลดเอกสาร จะดึงข้อความออกมาแล้วส่งให้โมเดลเป็นข้อความในพรอมต์ สูงสุด 40,000 โทเคนต่อรอบแบบตายตัว ถ้าอัปโหลดยาวเกินจะถูกตัด พร้อม toast และเครื่องหมายในข้อความบอกไว้ ไฟล์โปรเจกต์ก็ทำงานแบบเดียวกัน ฟีเจอร์ โปรเจกต์ ปักหมุดได้สูงสุด 10 ไฟล์ และสร้างข้อความของไฟล์เหล่านั้นขึ้นใหม่ในพรอมต์ทุกข้อความ จำกัดที่ 32,000 ตัวอักษรต่อไฟล์ และ 120,000 ตัวอักษรสำหรับทั้งบล็อกโปรเจกต์

ขีดจำกัดคือขอบเขตของการออกแบบนี้ ไฟล์ที่ปักหมุดเกิน 32,000 ตัวอักษรจะถูกตัดทอน ไฟล์แนบที่เกินงบ 40,000 โทเคนต่อรอบจะถูกตัด และโปรเจกต์คือโฟลเดอร์ ไม่ใช่คลังที่ค้นหาได้ นี่คือการแลกเปลี่ยนที่ตั้งใจ สำหรับสัญญาหรือเปเปอร์ที่พอดีกับงบต่อรอบ การมีข้อความอยู่ตรงหน้าดีกว่าการถูกค้นหา และการตรวจสอบที่สำคัญ คือการขอให้โมเดลยกข้อความที่มันใช้มาอ้างอิง ได้ผลเพราะย่อหน้านั้นอยู่ตรงนั้นจริง สำหรับเอกสารเป็นพันฉบับ vector database คือเครื่องมือที่ถูกต้อง และแชตแอปคือเครื่องมือที่ผิด

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