pgvector หรือ Qdrant — ฉันควรโฮสต์อันไหน?

หากคุณรัน Postgres อยู่แล้ว (หรืออยากได้ฐานข้อมูลเดียวสำหรับทั้งข้อมูลแอปและ embeddings) pgvector คือทางเลือกที่ใช้แรงน้อยที่สุด — มันแค่ extension หากคุณมี vector หลายล้านหรืออยากได้เอนจินที่สร้างมาเฉพาะพร้อมการกรองเร็ว Qdrant คุ้มค่ากับบริการแยก สำหรับ agent ส่วนใหญ่ที่เริ่มต้น pgvector บน Postgres เพียงพอ

vector database ต้องการ RAM เท่าไร?

มากกว่าที่คุณเดา เพราะการค้นหาที่ดีต้องการดัชนีในหน่วยความจำ กฎคร่าว ๆ: สองสามแสน embedding นั่งสบายใน 2 GB เมื่อคุณถึงหลักล้านต้น ๆ วางแผน 4 GB+ และปรับจูนดัชนี เริ่มที่ 2 GB เฝ้าดูหน่วยความจำ ปรับขนาดเมื่อการค้นหาช้า

ทำไมโฮสต์ vector store เองแทนที่จัดการให้?

สองเหตุผลที่คนทำจริง: embeddings ของคุณมักมีข้อมูลส่วนตัวของคุณ (บันทึก เอกสาร เนื้อหาลูกค้า) และ store ที่โฮสต์เองเก็บนั่นบนเซิร์ฟเวอร์ที่คุณควบคุม และเป็นต้นทุนคงที่ — บริการ vector ที่จัดการให้คิดตาม vector และ query ขณะที่ VPS คือตัวเลขรายเดือนเดียวไม่มี meter ต่อ query

vector DB และ agent ของฉันรันบน VPS เดียวกันได้ไหม?

ได้ สำหรับงานเล็กถึงกลาง — การวาง agent และ instance pgvector/Qdrant บนเครื่องเดียวง่ายและลด latency ใกล้ศูนย์ แยกพวกมันไปเซิร์ฟเวอร์แยกเฉพาะเมื่อตัวหนึ่งเริ่มอด RAM อีกตัว ซึ่งเป็นปัญหาน่ายินดีภายหลัง ไม่ใช่ข้อกังวลวันแรก

embeddings ใช้ดิสก์มากไหม?

embedding เดียวคือไม่กี่กิโลไบต์ ดังนั้นล้านตัวคือไม่กี่กิกะไบต์บวก overhead ดัชนี — มีนัยแต่ไม่ใหญ่ 25–45 GB ของดิสก์ครอบคลุม memory store ที่มีนัยสำหรับ agent ส่วนใหญ่ RAM ไม่ใช่ดิสก์ มักเป็นขีดจำกัดแรกที่คุณชน

โฮสต์ vector database สำหรับหน่วยความจำ AI agent บน VPS

AI agent ที่ไม่มีหน่วยความจำติดอยู่กับการแนะนำตัวเองใหม่ทุกบทสนทนา การแก้คือ vector database — มันเก็บ embeddings ของเอกสาร บันทึก หรือแชทในอดีตของคุณเพื่อให้ agent เรียกคืนส่วนที่เกี่ยวข้องตามต้องการ (นั่นคือ "R" ใน RAG) คุณเช่ามันเป็นบริการที่จัดการให้ หรือรันมันเองบน VPS และเก็บข้อมูลของคุณ — ซึ่งมักเป็นข้อมูลส่วนตัวของคุณ — บนเครื่องที่คุณควบคุม นี่คือวิธี และมันมีต้นทุน RAM จริงเท่าไร

สองตัวเลือกที่ดี

คุณไม่ต้องการอะไรแปลก สองเส้นทางครอบคลุมแทบทุกคน:

pgvector — extension ของ Postgres หากคุณรัน Postgres อยู่แล้ว (หรือยินดี) นี่เพิ่มการค้นหา vector ลงในฐานข้อมูลที่คุณมีอยู่แล้ว บริการเดียว การสำรองเดียว SQL ที่คุณรู้ จุดเริ่มต้นที่ใช้แรงน้อยที่สุดอย่างมาก

Qdrant — เอนจิน vector ที่สร้างมาเฉพาะ คว้ามันเมื่อคุณมี vector มาก (หลักล้านขึ้นไป) หรืออยากได้การกรอง metadata เร็วและ API เฉพาะ มันเป็นบริการแยกที่จะรัน แต่มันสร้างมาสำหรับงานนี้พอดี

สำหรับ agent ส่วนใหญ่ที่เพิ่งลงตัว pgvector คือคำตอบแรกที่ถูกต้อง ย้ายไป Qdrant เมื่อคุณโตเกินมัน ไม่ใช่ก่อน

ความจริง RAM (นี่คือส่วนที่คนประเมินต่ำ)

การค้นหา vector เร็วเพราะดัชนีอยู่ในหน่วยความจำ — ดังนั้น RAM ไม่ใช่ดิสก์ คือข้อจำกัดจริงของคุณ คู่มือคร่าว ๆ:

สองสามแสน embedding — สบายใน 2 GB
หลักล้านต้น ๆ — วางแผน 4 GB+ และปรับจูนดัชนี
ดิสก์คือส่วนง่าย: ล้าน embedding คือไม่กี่ GB ดังนั้น 25–45 GB ครอบคลุม store จริงจัง

ดังนั้นกำหนดขนาดสำหรับดัชนี ไม่ใช่ไฟล์ (ตรรกะเดียวกับคู่มือกำหนดขนาดทั่วไป — สิ่งหนักไม่ชัดจนกว่าคุณวัด)

เริ่มต้นเร็ว: pgvector

บนเครื่องที่มี Postgres (Docker ง่ายที่สุด — รูปแบบเดียวกับการโฮสต์ n8n เอง):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- ให้ตรงกับมิติของโมเดล embedding ของคุณ
);

-- หลังคุณมีข้อมูล สร้างดัชนีสำหรับการค้นหาเร็ว:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

agent ของคุณ insert content + embedding ของมัน จากนั้น query ด้วย ORDER BY embedding <=> $query_embedding LIMIT 5 เพื่อดึงหน่วยความจำที่ใกล้ที่สุด นั่นคือลูปทั้งหมด

ชอบ Qdrant? มันคือคอนเทนเนอร์ Docker เดียวที่เปิด HTTP/gRPC API คุณสร้าง collection ด้วยขนาด vector ของคุณและ upsert จุด ไอเดียเดียวกัน เอนจินเฉพาะ

มันแชร์เครื่องกับ agent ได้ไหม?

ได้ — สำหรับ memory store เล็กถึงกลาง รัน vector DB บน VPS เดียวกับ agent มันง่ายกว่าและ latency แทบเป็นศูนย์ แยกพวกมันไปเซิร์ฟเวอร์แยกเฉพาะเมื่อตัวหนึ่งเริ่มเบียดอีกตัวออกจาก RAM นั่นคือการตัดสินใจภายหลัง ปัญหาน่ายินดี ไม่ใช่วันแรก

ข้อควรระวังที่ตรงไปตรงมา

RAM คือกำแพง และมันเงียบ การค้นหาเร็วจนกว่าดัชนีไม่พอดีในหน่วยความจำ จากนั้นมันเสื่อม เฝ้าดูหน่วยความจำและปรับขนาดก่อนมันกัด — อย่ารอให้ query ช้าบอกคุณ
embeddings เสียโทเคนในการสร้าง ทุกเอกสารที่คุณ embed คือการเรียก API ไปยังโมเดล embedding store ถูกที่จะโฮสต์ การสร้าง vector คือต้นทุนซ้ำ — เกี่ยวข้องกับสิ่งที่การรัน agent มีต้นทุนจริง
สำรองมัน หน่วยความจำของ agent คือข้อมูลเหมือนอย่างอื่น หากมันสำคัญ สแนปช็อตมัน

ภายในนั้น vector store ที่โฮสต์เองคือวิธีสะอาดในการให้ agent หน่วยความจำถาวรโดยไม่มอบข้อมูลส่วนตัวของคุณให้บุคคลที่สาม เริ่มด้วย pgvector บนเครื่อง 2 GB เฝ้าดู RAM และโตเข้าสู่ Qdrant หรือแพ็กเกจใหญ่กว่าเฉพาะเมื่อตัวเลขบอกคุณ