ทำไม RAG ต้องการ RAM มากนัก?

การค้นหา vector ที่รวดเร็วต้องการดัชนีอยู่ในหน่วยความจำ ทุก chunk เอกสารกลายเป็น embedding — vector ของ float ไม่กี่ร้อยถึงสองสามพัน — และที่ chunk หลายล้านมันสะสม ดันดัชนีไปดิสก์แล้ว latency การค้นหาพุ่ง การเก็บเหตุผลทั้งหมดที่คุณโฮสต์เอง (ความเร็ว + การควบคุม) หมายถึงการเก็บมันใน RAM

RAM เท่าไรสำหรับ corpus หนึ่ง?

ความรู้สึกคร่าว ๆ: สองสามแสน embedding นั่งได้ดีใน 2–4 GB หลักล้านต้น ๆ พร้อมแอปและ OS รอบ ๆ คุณอยู่ที่ 16–32 GB หลักสิบล้านหรือ vector มิติสูงคุณเข้าสู่ 48–80 GB และเกินนั้นคุณแบ่งข้ามเซิร์ฟเวอร์ มิติและชนิดดัชนีแกว่งสิ่งนี้มาก ดังนั้นวัดของคุณเอง

pgvector หรือเอนจินเฉพาะอย่าง Qdrant?

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

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

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

RAG ที่โฮสต์เองในขนาดใหญ่: ดัชนี vector กิน RAM เท่าไรจริง

ทุกบทเรียน RAG รันบนแล็ปท็อปกับเอกสารสองสามร้อยชิ้น และมันรู้สึกไม่ต้องออกแรง จากนั้นคุณชี้มันไปที่ corpus จริง — เอกสารของบริษัท ทิกเก็ตหลายปี ฐานความรู้ — และทันใดหน่วยความจำคือบทสนทนาทั้งหมด

RAG ไม่ปรับขนาดด้วย CPU มันปรับขนาดด้วย RAM

ทำไมดัชนีต้องการหน่วยความจำ

การดึงข้อมูลทำงานโดยเปลี่ยนทุก chunk ของข้อความเป็น embedding — vector ยาวไม่กี่ร้อยถึงสองสามพันตัวเลข การค้นหาหมายถึงการเปรียบเทียบ query vector ของคุณกับทั้งหมดอย่างรวดเร็ว "รวดเร็ว" คือคำสำคัญ: สำหรับ latency ต่ำ ดัชนีต้องอยู่ใน RAM บนดิสก์ก็ทำงานได้ แต่ทุก query จ่ายบทลงโทษ และการดึงข้อมูล latency ต่ำคือจุดประสงค์ของการโฮสต์เองตั้งแต่แรก

ดังนั้นบิลหน่วยความจำปรับตามสองสิ่ง: คุณมี chunk เท่าไร และแต่ละ vector กว้างแค่ไหน

ตัวเลขจริง คร่าว ๆ

วัดของคุณเอง — มิติและชนิดดัชนีขยับสิ่งนี้มาก — แต่เป็นความรู้สึกเริ่มต้น:

สองสามแสน embedding — สบายใน 2–4 GB ฐานความรู้ส่วนตัว เอกสารของผลิตภัณฑ์เดียว
หลักล้านต้น ๆ — พร้อมแอป, client โมเดล และ OS รอบ ๆ วางแผน 16–32 GB นี่คือฐานความรู้บริษัทจริงจังหรือ RAG หลายแหล่ง
หลักสิบล้าน หรือ vector มิติสูง — ตอนนี้คุณอยู่ที่ 48–80 GB และเกินนั้นข้ามหลายเครื่อง ที่ดินเอกสารใหญ่ การดึงข้อมูลหลายผู้เช่า หรือคุณเก็บหลายดัชนีร้อนพร้อมกัน

ระบบหลาย agentที่ถือดัชนีใหญ่ด้วยซ้อนทั้งสองต้นทุนบนเครื่องเดียวกัน — นั่นคือวิธีที่แพ็กเกจ 32 GB กลายเป็น 64 GB อย่างเงียบ ๆ

ทางเลือกเอนจิน โดยย่อ

หากคุณรัน Postgres อยู่แล้ว pgvector คือตัวเลือกที่ใช้แรงน้อยที่สุด — มันเป็น extension ไม่ใช่บริการใหม่ให้เลี้ยงดู เมื่อคุณมี vector หลายล้านและต้องการการค้นหากรองที่รวดเร็ว เอนจินเฉพาะอย่าง Qdrant หรือ Weaviate คุ้มค่ากับโปรเซสแยก อย่า over-engineer ในวันแรก รันสิ่งที่คุณดำเนินการอยู่แล้วและแยกออกเมื่อการค้นหาช้าจริง

ทำไมเสียเวลาโฮสต์เอง

สองเหตุผลที่ผู้คนทำสิ่งนี้จริง และไม่มีอันไหนคือ "เพื่อประหยัดสองสามดอลลาร์":

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

ต้นทุนคงที่ บริการ vector ที่จัดการให้คิดตาม vector ที่เก็บและ query ที่รัน VPS คือตัวเลขรายเดือนเดียวและคุณกระหน่ำมันได้เต็มที่ ในขนาดใหญ่ คาดเดาได้ชนะแบบวัด

นี่หมายถึงอะไรต่อการกำหนดขนาด

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

สำหรับอะไรเกิน vector สองสามล้านที่ถือเป็นส่วนตัว สาย Pro รัน 32 ถึง 80 GB พร้อม dedicated IP และการสำรองรายคืน ซึ่งสำคัญเมื่อดัชนีคือผลิตภัณฑ์และการสูญเสียมันเจ็บ