pgvector یا Pinecone؛ دیتابیس دوم فقط وقتی مقیاس آن را توجیه کند

اگر دادهٔ اصلی سامانهٔ RAG در PostgreSQL است و pgvector با فیلترهای واقعی به هدف دقت و تأخیر می‌رسد، نگه‌داشتن بردارها در همان پایگاه انتخاب ساده‌تری است. Pinecone زمانی ارزش سامانهٔ دوم را دارد که رشد داده یا ترافیک، هزینهٔ حافظه و ادارهٔ نمایه را بالا ببرد و سرویس مدیریت‌شده در بار کاری خودتان مزیتی سنجیدنی نشان دهد.

مرز تصمیم را نمی‌توان با شمار بردارها به‌تنهایی تعیین کرد. اندازه و تغییرات مجموعه، گزینش‌پذیری فیلترها، درخواست‌های هم‌زمان، هدف recall و ظرفیت تیم بر نتیجه اثر می‌گذارند. اگر بازیابی برداری باید در همان تراکنش به ردیف‌های رابطه‌ای متصل باشد، جدا کردن آن به Pinecone محدودیت معماری تازه‌ای نیز ایجاد می‌کند.

PostgreSQL چه زمانی کافی است؟

راهنمای رسمی pgvector جست‌وجوی نزدیک‌ترین همسایه را به‌طور پیش‌فرض دقیق توصیف می‌کند و HNSW و IVFFlat را برای جست‌وجوی تقریبی با مصالحهٔ سرعت و recall در اختیار می‌گذارد. HNSW معمولاً نتیجهٔ بهتری از نظر این موازنه می‌دهد، اما ساخت آن نسبت به IVFFlat زمان و حافظهٔ بیشتری می‌خواهد. برای مجموعه‌ای که جست‌وجوی دقیقش از قبل به سقف تأخیر می‌رسد، افزودن نمایهٔ تقریبی هم ضرورت ندارد.

فیلترهای SQL می‌توانند دلیل مهم‌تری از اندازهٔ مجموعه برای ماندن باشند. وقتی نتیجه باید با وضعیت انتشار، شناسهٔ مشتری یا مجوز دسترسی در ردیف‌های PostgreSQL ترکیب شود، دادهٔ برداری و رابطه‌ای در یک مسیر پرس‌وجو قرار دارند. این ویژگی به‌ویژه وقتی مهم است که تغییر سند و بردار آن باید با هم ثبت شوند؛ سرویس بیرونی نمی‌تواند در همان تراکنش PostgreSQL شرکت کند.

فیلتر در جست‌وجوی تقریبی pgvector ظرافتی دارد: شرط می‌تواند پس از پیمایش نمایه اعمال شود و درخواست، کمتر از تعداد نتیجهٔ خواسته‌شده برگرداند. برای شرط‌های گزینشی، نمایه روی ستون فیلتر و جست‌وجوی دقیق ممکن است مناسب باشد؛ نمایهٔ جزئی، پارتیشن‌بندی و پیمایش تکراری نیز بسته به توزیع داده گزینه‌اند. افزایش دامنهٔ پیمایش می‌تواند recall را بهتر کند، ولی زمان پاسخ و کار پایگاه را هم تغییر می‌دهد. بنابراین رفتار فیلتر باید با همان شرط‌هایی سنجیده شود که کاربران واقعاً ارسال می‌کنند.

ماتریس تصمیم: آستانه را از بار کاری بگیرید

عدد ثابتی مانند «یک میلیون بردار» آستانهٔ عمومی مهاجرت نیست. دو مجموعه با شمار برابر، به‌دلیل ابعاد بردار، فیلترها، نرخ نوشتن و درخواست‌های هم‌زمان می‌توانند به حافظه و زمان پاسخ متفاوتی نیاز داشته باشند. معیار مفید، عبور یا نگذشتن از هدف‌های از پیش تعیین‌شده در بار نمایندهٔ محصول است:

• در pgvector بمانید وقتی جست‌وجوی دقیق یا تقریبی با فیلترهای واقعی به حداقل recall، تعداد نتیجه و سقف تأخیر می‌رسد؛ نمایه در بودجهٔ منابع جا می‌گیرد و رشد آن اداره‌پذیر است. نیاز به اتصال تراکنشی بردار و دادهٔ رابطه‌ای وزن این انتخاب را بیشتر می‌کند.
• ابتدا مسیر PostgreSQL را تنظیم کنید وقتی فقط برخی فیلترها نتیجهٔ کم می‌دهند یا کند می‌شوند. طرح اجرای پرس‌وجو، نمایهٔ ستون فیلتر، پارتیشن‌بندی و تنظیم پیمایش تقریبی را با یک مجموعه‌پرسش ثابت بررسی کنید. بهبود recall را همراه با مصرف حافظه و تأخیر بسنجید.
• Pinecone را در همان بار آزمایش کنید وقتی نمایهٔ رو به رشد برای منابع PostgreSQL با پرس‌وجوهای اصلی رقابت می‌کند، تغییرات پیوستهٔ داده کار نگهداری را سنگین می‌کند، یا هدف تأخیر در بار هم‌زمان پس از تنظیم معقول محقق نمی‌شود. انتخاب سرویس دوم به بهبود بازیابی یا کاهش هزینهٔ کل عملیات وابسته است، نه صرفاً بزرگ بودن مجموعه.

سامانهٔ دوم چه هزینه‌ای به معماری اضافه می‌کند؟

انتقال جست‌وجوی برداری به Pinecone معمولاً PostgreSQL را از نقش منبع اصلی داده کنار نمی‌زند. برنامه شناسهٔ قطعه‌ها را از نمایهٔ برداری می‌گیرد و متن و وضعیت جاری آن‌ها را از پایگاه رابطه‌ای بازیابی می‌کند. برای به‌روزرسانی یا حذف سند نیز باید تغییر در دو سامانه هماهنگ شود. فاصلهٔ زمانی میان ثبت داده و آماده شدن آن برای جست‌وجو، تلاش دوباره پس از خطا و حذف رکوردهای قدیمی بخشی از هزینهٔ این مسیرند.

در RAG چندمستاجری، مجوز دسترسی را نمی‌توان فقط از حضور یک قطعه در نمایهٔ برداری نتیجه گرفت. اگر وضعیت مجوز در PostgreSQL تغییر می‌کند، برنامه باید آن را پیش از فرستادن متن بازیابی‌شده به مدل کنترل کند. این خواندن دوباره به تأخیر انتهابه‌انتها اضافه می‌شود، اما مانع اتکا به فراداده‌ای می‌شود که ممکن است هنوز با منبع اصلی همگام نشده باشد.

در برآورد هزینه، برای pgvector ظرفیت حافظه و پردازنده، نگهداری نمایه و اثر جست‌وجو بر بارهای دیگر PostgreSQL را حساب کنید. برای Pinecone، هزینهٔ ذخیره‌سازی و عملیات را در کنار بارگذاری اولیه، تغییرات مداوم و کار همگام‌سازی قرار دهید. چک‌لیست تولید Pinecone محدودیت نرخ عملیات، سقف‌های وابسته به طرح و لزوم رسیدگی به خطاهای ناشی از محدودیت نرخ را نیز شرح می‌دهد؛ این قیود می‌توانند بر طراحی و هزینهٔ عملیاتی اثر بگذارند.

اعداد بنچمارک را با شرایط آزمون بخوانید

بنچمارک Supabase در اکتبر ۲۰۲۳ یک میلیون embedding با ۱۵۳۶ بُعد را با معیار ضرب داخلی مقایسه کرد: سوی PostgreSQL از HNSW و یک نمونهٔ Supabase استفاده می‌کرد و سوی Pinecone بر pod و نسخه‌های تکراری آن متکی بود. Supabase در این پیکربندی، توان پاسخ‌گویی بالاتری برای pgvector گزارش کرد. این نتیجه به همان نوع نمایه، بودجه، مجموعه‌داده و هدف دقت مربوط است؛ Supabase خود عرضه‌کنندهٔ PostgreSQL مدیریت‌شده است.

مقایسهٔ Pinecone نیز برای مجموعهٔ کوچک و نسبتاً ثابت که نمایه‌اش در حافظهٔ موجود جا می‌گیرد، pgvector را گزینه‌ای مناسب می‌داند. Pinecone برای آزمون خود روی چهار مجموعه‌داده در آوریل ۲۰۲۴، هزینهٔ ماهانهٔ مداوم Serverless را ۱٫۵ تا ۲٫۹ برابر کمتر از پیکربندی PostgreSQL مورد آزمون گزارش می‌کند؛ مدل آن بارگذاری کامل، میانگین ۱۰ پرس‌وجو در دقیقه، تغییر ماهانهٔ ۱۰ درصد داده و هدف تأخیر صدک ۹۵ زیر ۱۰۰ میلی‌ثانیه را فرض می‌کرد. آزمون پیش از قابلیت پیمایش تکراری pgvector انجام شده بود. از سوی دیگر، آزمون Supabase نسل pod محور Pinecone را می‌سنجید. این دو عدد به محصول، دوره و روش یکسان تعلق ندارند و پیش‌بینی هزینهٔ پروژهٔ شما نیستند.

آزمون محلی برای recall، تأخیر و هزینه

برای انتخاب میان دو مسیر، پرس‌وجوهای نمایندهٔ RAG را از بار واقعی بردارید: فیلترهای مشتری و مجوز، پرسش‌های دشوار، اسناد تازه و حذف‌شده و ساعت‌های شلوغ باید در نمونه حضور داشته باشند. پیش از اجرا، مقدار k، حداقل recall قابل‌قبول، تعداد نتیجهٔ لازم و سقف تأخیر صدک ۹۵ را تعیین کنید. به این ترتیب، هر دو گزینه با یک معیار سنجیده می‌شوند.

1. برای هر پرس‌وجو، نزدیک‌ترین نتایج دقیق را در PostgreSQL با همان معیار فاصله و همان فیلترها مبنا قرار دهید. سپس سهم شناسه‌های مشترک در نتایج هر گزینه را به‌صورت recall@k حساب کنید. این سنجه کیفیت بازیابی را نشان می‌دهد، نه کیفیت نهایی پاسخ مدل.
2. pgvector را با جست‌وجوی دقیق و تنظیمات مناسب نمایهٔ تقریبی اجرا کنید. تعداد نتایج پس از فیلتر، تأخیر صدک ۹۵، مصرف منابع و اثر ورود دادهٔ تازه را ثبت کنید. در آزمون Pinecone، بردارها، معیار فاصله، فیلترها و k را یکسان نگه دارید و رفت‌وبرگشت شبکه و بازیابی متن از PostgreSQL را در زمان انتهابه‌انتها بیاورید.
3. آزمون را زیر بار هم‌زمان و پس از به‌روزرسانی و حذف داده تکرار کنید. اگر هر دو مسیر به هدف‌ها می‌رسند، هزینهٔ کل و کار ادارهٔ دو سامانه تعیین‌کننده است. اگر PostgreSQL پس از تنظیم معقول به هدف نمی‌رسد و Pinecone با احتساب مسیر کامل بازیابی می‌رسد، سرویس دوم توجیه عملی پیدا می‌کند.

بیشتر بخوانید:

• GraphRAG یا Vector RAG؛ گراف فقط در پرسش‌های چندمرحله‌ای جلو می‌افتد
• RAG را درست ارزیابی کنید؛ یک امتیاز خوب می‌تواند خطای بازیابی را پنهان کند
• تأیید انسانی برای عامل‌ها بسازید؛ توقف را فقط پیش از کار پرخطر بگذارید