سقوط دقت بازیابی در pgvector؛ مرز ۱۰ هزار بردار برای سامانه‌های RAG

۱۰ هزار بردار؛ این دقیقاً نقطه‌ای بود که سامانه پشتیبانی مشتریان AIdeazz با سقوط کیفیت بازیابی مواجه شد. این تجربه ثابت می‌کند که دقت در یک سامانه تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — می‌تواند مدت‌ها پیش از رسیدن به مقیاس میلیونی، فرو بپاشد. این یک هشدار جدی برای کسانی است که تصور می‌کنند مقیاس‌پذیری تنها در اعداد میلیونی معنا پیدا می‌کند.

این اتفاق یک محدودیت تئوریک نبود، بلکه یک واقعیت عملیاتی در Oracle Autonomous Database با افزونه pgvector بود که نشان داد تنظیمات پیش‌فرض ایندکس می‌توانند در استقرار واقعی، یک «دیواره عملکرد» (Performance Cliff) ایجاد کنند. در واقع، سیستمی که در ابتدا عالی به نظر می‌رسید، به محض رسیدن به یک حجم داده‌ی خاص، ناگهان دچار افت شدید کیفیت شد.

بسیاری از توسعه‌دهندگان با پایگاه‌داده‌های برداری مثل جعبه‌های سیاهی برخورد می‌کنند که به‌صورت خطی مقیاس می‌پذیرند. اما در عمل، انتخاب الگوریتم ایندکس تعیین می‌کند که هوش مصنوعی شما پاسخ‌های دقیق بدهد یا شروع به توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — و ارائه اسناد بی‌ربط کند. این موضوع به‌ویژه برای سامانه‌های چندعاملی که درخواست‌ها را از تلگرام و واتس‌اپ به عامل‌های تخصصی مجهز به Groq هدایت می‌کنند، حیاتی است؛ چراکه در این معماری، یک تکه متن اشتباه (Context Chunk) می‌تواند کل مسیر استدلال عامل را منحرف کرده و گفتگو را به کلی خراب کند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی حافظه در مدل‌های زبانی اشاره کردیم، مدیریت دقیق بستر متن برای جلوگیری از خطاهای استنتاج ضروری است.

جزئیات پیاده‌سازی اولیه

طبق گزارش فنی AIdeazz، تیم توسعه در ابتدا از pgvector به عنوان یک افزونه روی نسخه ۱۴.۸ پست‌گرس‌اس‌کی‌ال در محیط Oracle Autonomous Database استفاده می‌کرد. آن‌ها از زیرساخت‌های اشتراکی با تعداد OCPUهای متغیر استفاده کردند که بر اساس نیاز، به‌صورت خودکار مقیاس می‌شدند. برای ایجاد بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — از مدل text-embedding-ada-002 با ابعاد ۱۵۳۶ استفاده کردند.

پایگاه دانش آن‌ها شامل دفترچه‌های راهنمای محصول، سوالات متداول داخلی (FAQs) و تاریخچه تعاملات مشتریان بود که به تکه‌هایی با اندازه تقریبی ۲۵۰ توکن تقسیم شده بود. خط لوله ورود داده‌ها (Ingestion Pipeline) یک توالی سخت‌گیرانه داشت: ابتدا تکه‌های متن استخراج می‌شد، سپس از طریق API شرکت OpenAI به بردار تبدیل می‌شد و در نهایت در جدولی با ساختار زیر درج می‌گشت:
CREATE TABLE knowledge_base (id UUID PRIMARY KEY, content TEXT, embedding VECTOR(1536));

برای بازیابی اطلاعات، آن‌ها از دستور ORDER BY embedding <-> query_embedding LIMIT 5 استفاده می‌کردند تا ۵ مورد از نزدیک‌ترین بردارها را پیدا کنند.

شکست ایندکس IVFFlat

مشکل اصلی از ایندکس IVFFlat شروع شد. تیم با تنظیم lists = 100 تصور می‌کرد این مقدار برای حجم داده‌های پیش‌بینی شده (ده‌ها هزار بردار) کافی است. در ۵ هزار بردار اول، سامانه عملکرد خوبی داشت و دقت (Precision@5) روی ۰.۸۵ بود. اما به محض رسیدن به ۱۰ هزار بردار، این عدد به شدت سقوط کرد و به ۰.۵۵ رسید.

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

بر اساس مستندات فنی، علت این شکست مکانیزم IVFFlat بود که فضای برداری را به خوشه‌هایی (Lists) تقسیم می‌کند. با ۱۰۰ لیست و ۱۰ هزار بردار، هر لیست به‌طور متوسط ۱۰۰ بردار داشت. چون مقدار n_probe به‌صورت پیش‌فرض روی ۱ بود، سامانه تنها یک خوشه را جست‌وجو می‌کرد. در فضای ابعادی بالا، این مقدار بسیار کم بود و باعث می‌شد نزدیک‌ترین همسایه‌های واقعی در خوشه‌های دیگر باقی بمانند و پیدا نشوند.

افزایش n_probe راهکار مناسبی نبود؛ زیرا هرچه این عدد بیشتر شود، تأخیر (Latency) در پاسخگویی بالا می‌رود. برای تعاملات بلادرنگ در تلگرام و واتس‌اپ، سقف تأخیر ۵۰۰ میلی‌ثانیه بود. اگر n_probe به ۱۰ افزایش می‌یافت، سامانه باید ۱۰٪ از کل داده‌ها (۱۰۰۰ بردار) را جست‌وجو می‌کرد که این امر تأخیر را از حد قابل قبول برای فراخوانی‌های همزمان (Synchronous) عامل‌ها می‌گذراند.

مهاجرت به HNSW

برای حل این بحران و بازگرداندن دقت بازیابی، تیم به ایندکس HNSW (Hierarchical Navigable Small World) مهاجرت کرد. برخلاف IVFFlat که بر پایه لیست است، HNSW یک ساختار گرافی می‌سازد که برای جست‌وجوی تقریبی نزدیک‌ترین همسایه (ANN)، به‌ویژه در ابعاد بالا، بسیار کارآمدتر است.

تغییرات فنی شامل حذف ایندکس قدیمی و اجرای دستور زیر بود:
CREATE INDEX ON knowledge_base USING hnsw (embedding vector_l2_ops) WITH (m = 16, ef_construction = 64);

در این تنظیمات، دو پارامتر کلیدی نقش داشتند:
۱. m = 16: تعداد همسایگانی که هر گره به آن‌ها متصل می‌شود را کنترل می‌کند. مقدار m بالاتر به معنای گراف متراکم‌تر و دقت (Recall) بیشتر است، اما باعث کند شدن ساخت ایندکس و مصرف حافظه بیشتر می‌شود.
۲. ef_construction = 64: محدوده جست‌وجو هنگام ساخت ایندکس را تعیین می‌کند. مقادیر بالاتر منجر به ساخت ایندکسی با کیفیت بیشتر می‌شود اما زمان ساخت را افزایش می‌دهد.

نتیجه این تغییر فوری بود: زمان بازسازی ایندکس برای ۱۰ هزار بردار حدود ۳ دقیقه طول کشید، تأخیر بازیابی از ۴۰۰ به ۱۵۰ میلی‌ثانیه کاهش یافت و دقت (Precision@5) دوباره به ۰.۸۸ رسید.

توازن بین مدل برداری و هزینه

در گام بعد، تیم برای بهینه‌سازی هزینه‌ها آزمایش دومی را با مدل all-MiniLM-L6-v2 انجام داد. این یک مدل متن‌باز کوچک‌تر با ۳۸۴ بعد است. این کار مستلزم باز-برداری (Re-embedding) تمام ۱۰ هزار بردار در یک عملیات دسته‌ای (Batch Job) روی یک ماشین محلی بود که ۲ ساعت زمان برد و ستون جدول را به VECTOR(384) تغییر داد.

اگرچه این تغییر تأخیر را باز هم کاهش داد و به ۸۰ میلی‌ثانیه رساند و هزینه‌های API را حذف کرد، اما دقت به ۰.۷۰ افت کرد. این مدل کوچک، ظرافت‌های معنایی لازم برای پشتیبانی فنی محصولات و جزئیات پیچیده سیاست‌های شرکت را نداشت. عامل‌ها دوباره شروع به ارتکاب خطاهای ظریف کردند و به دلیل بستر متن (Context) غیردقیق، قصد کاربر را اشتباه متوجه می‌شدند.

در نهایت، آن‌ها روی مدل text-embedding-3-small متوقف شدند. این مدل کیفیت ۱۵۳۶ بعدی مدل‌های قبلی را حفظ کرد اما هزینه را در مقایسه با ada-002 تا ۵ برابر کاهش داد؛ یعنی قیمت از ۰.۰۰۰۱ دلار به ۰.۰۰۰۰۲ دلار به‌ازای هر ۱ هزار توکن رسید.

پشته فنی نهایی و چشم‌انداز

پشته فنی نهایی و پایدار AIdeazz اکنون شامل موارد زیر است:

• پایگاه‌داده: pgvector روی Oracle Autonomous Database (PostgreSQL 14.8)
• ایندکس: HNSW (m=16, ef_construction=64)
• مدل: text-embedding-3-small (1536 dimensions)
• عملکرد: دقت ۰.۸۵ با تأخیر حدود ۱۲۰ میلی‌ثانیه

به نقل از گزارش AIdeazz، این ساختار در حال حاضر ۱۵ هزار بردار را مدیریت می‌کند و نرخ رشد آن ۵۰۰ بردار در روز است. آن‌ها پیش‌بینی می‌کنند این معماری تا ۱۰۰ هزار بردار پاسخگو باشد و پس از آن نیاز به تنظیم مجدد ef_search یا شاردینگ (Sharding) باشد. برای مقیاس‌های عظیم (میلیون‌ها بردار)، نقشه راه آن‌ها شامل بررسی پایگاه‌داده‌های تخصصی مثل Qdrant یا Pinecone، و یا استفاده از pgvector توزیع شده با ذخیره‌سازی ستونی TimescaleDB است.

زمینه عملیاتی و نظارت

تیم AIdeazz دلیل انتخاب Oracle Autonomous Database را این دانست که عملیات وصله‌گذاری (Patching)، پشتیبان‌گیری و مقیاس‌پذیری را به‌صورت خودکار انجام می‌دهد. برای تیمی که هیچ بودجه‌ای از سرمایه‌گذاران (VC) ندارد و بودجه‌ای برای تیم عملیات (Ops) اختصاص نداده است، این سرویس مدیریت‌شده هزینه‌های اداری را حذف می‌کند.

برای حفظ کیفیت، آن‌ها از یک فرآیند اعتبارسنجی انسانی (Human-in-the-loop) استفاده می‌کنند. هر هفته، بازبین‌های انسانی ۵ سند برتر بازیابی شده برای نمونه‌ای از ۱۰۰ تعامل عامل را بررسی می‌کنند. مقدار Precision@5 به عنوان میانگین تعداد اسناد مرتبط در آن ۵ نتیجه اول محاسبه می‌شود.

این مورد ثابت می‌کند که تنظیمات پیش‌فرض pgvector برای مجموعه‌داده‌های کوچک تا متوسط «امن» نیستند. گذار از چند هزار به ۱۰ هزار بردار، آستانه بحرانی است که در آن انتخاب ایندکس، تعیین‌کننده اصلی قابلیت اطمینان RAG می‌شود.

درس برای توسعه‌دهندگان روشن است: هرگز هزینه را به قیمت ایجاد توهم بهینه نکنید. کاهش هزینه ماهانه از حدود ۱۵۰ دلار به ۳۰ دلار هیچ ارزشی ندارد اگر دقت بازیابی به زیر حد کاربردی سقوط کند و کاربر پاسخ‌های غلط دریافت کند.

اگر در حال مقیاس‌بندی یک ذخیره‌ساز برداری هستید، معیارهای Precision@k خود را به‌صورت هفتگی رصد کنید. ممکن است متوجه شوید که ایندکس فعلی شما با رشد پایگاه دانش، به‌صورت خاموش در حال شکست خوردن است.

گام بعدی شما

• اگر از pgvector استفاده می‌کنید، فوراً معیار Precision@k خود را در مقیاس‌های مختلف (۱ هزار، ۵ هزار و ۱۰ هزار بردار) تست کنید.
• در صورت مشاهده افت دقت، از IVFFlat به HNSW مهاجرت کنید و پارامترهای m و ef را بر اساس حافظه در دسترس تنظیم کنید.
• برای تعادل بین هزینه و دقت، مدل‌های جدیدتر اما بهینه‌تر مثل text-embedding-3-small را جایگزین مدل‌های قدیمی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.