پیاده‌سازی خط لوله RAG در Node.js با استفاده از pgvector و لایه‌های حفاظتی

اگر امروز در حال ساخت یک سامانه هوش مصنوعی برای محیط عملیاتی هستید، بزرگ‌ترین ریسک شما نه هوش مدل، بلکه قابلیت اطمینان داده‌هاست. توسعه‌دهندگانی که از Node.js استفاده می‌کنند، اکنون می‌توانند خط لوله‌ای حرفه‌ای برای تولید بازیابی‌افزا (RAG) — شبیه به دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — پیاده کنند تا حدس‌های کور AI را با شواهد قابل تأیید جایگزین کنند.

برای بسیاری از برنامه‌نویسان، پایتون انتخاب پیش‌فرض است، اما Node.js در محیط‌هایی با عملیات ورودی/خروجی (I/O) سنگین، برتری مشخصی دارد. از آن‌جا که RAG به فراخوانی‌های مکرر API مدل‌هایی مثل Claude 3.5 Sonnet و پرس‌وجو از پایگاه‌داده‌هایی مانند PostgreSQL وابسته است، ماهیت غیرهمزمان (Asynchronous) جاوااسکریپت آن را به گزینه‌ای ایده‌آل برای استریم‌های بلادرنگ و استقرار سریع در پلتفرم‌هایی مثل Vercel یا Railway تبدیل می‌کند. استفاده از async/await اجازه می‌دهد جریان‌های پیچیده AI بدون به‌هم‌ریختگی مدیریت شوند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی بازیابی داده‌ها اشاره کردیم، زیربنای هر سیستم RAG موفق، مدیریت دقیق داده‌هاست. این معماری بر پایه pgvector بنا شده است؛ افزونه‌ای برای PostgreSQL که اجازه می‌دهد بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که همسایگی معنایی آن را مشخص می‌کند — به صورت برداری ذخیره شود. برای امنیت در سطح سازمانی، جداسازی سخت‌گیرانه مستأجران (Tenant Isolation) الزامی است تا نشت داده‌ها بین شرکت‌های مختلف با استفاده از tenant_id به‌طور کامل متوقف شود.

طبق مستندات فنی این راهنما، سه نوع ایندکس برای عملکرد بهینه حیاتی هستند:

• ایندکس IVFFLAT: برای جست‌وجوی سریع برداری که زمان پاسخ‌دهی را از ۱۰ ثانیه به زیر ۲۰۰ میلی‌ثانیه می‌رساند.
• ایندکس GIN: برای جست‌وجوی متنی دقیق بر اساس کلمات کلیدی.
• ایندکس Tenant: ترکیبی از tenant_id و resume_id برای حفظ سرعت در بررسی‌های امنیتی.

ساختار پایگاه‌داده شامل جداولی برای ذخیره متن‌های خام، قطعات برداری با ۱۵۳۶ بُعد برای مدل Claude، مدیریت هویت شرکت‌ها و یک جدول حیاتی برای ثبت گزارش‌های پرس‌وجو (Query Logs) است که تأخیر، نرخ بازیابی (Recall)، دقت (Precision) و هزینه هر تعامل را ردیابی می‌کند.

برای جلوگیری از شکست در اتصال به دیتابیس، از pg-promise با یک استخر اتصال (Connection Pool) تخصصی استفاده شده است. این تنظیمات شامل سقف ۲۰ اتصال و زمان انتظار ۵۰۰۰ میلی‌ثانیه‌ای است. تابع initializeDatabase در لحظه استارت‌آپ، اتصال را با یک دستور ساده SELECT 1 تأیید می‌کند و در صورت شکست، برای جلوگیری از وضعیت زامبی، کل پروسه را با process.exit(1) متوقف می‌کند.

بر اساس بررسی‌های فنی، بردار معنایی‌ها توسط مدل Claude 3.5 Sonnet تولید می‌شوند. به دلیل محدودیت ۴۰۹۶ توکنی API، یک مرحله پیش‌اعتبارسنجی برای کوتاه کردن متن‌ها تا ۱۶ هزار کاراکتر تعبیه شده است. هزینه هر ۱ میلیون توکن ورودی نیز ۰.۰۰۳ دلار محاسبه و ثبت می‌شود.

برای پردازش اسناد حجیم، استراتژی تکه‌بندی (Chunking) — یعنی برش‌های کوچکی از متن شبیه به تکه‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — به صورت پنجره لغزان اجرا می‌شود:

• اندازه پنجره: ۱۰۰۰ تا ۱۵۰۰ توکن.
• هم‌پوشانی (Overlap): ۲۰۰ توکن برای حفظ بستر معنایی بین تکه‌ها.
• تشخیص مرز: جست‌وجو برای نقطه یا خط جدید تا جملات در وسط قطع نشوند.

هسته سیستم، یک مکانیزم جست‌وجوی ترکیبی (Hybrid Search) است. این سیستم جست‌وجوی برداری (درک معنا) را با جست‌وجوی کلمات کلیدی (یافتن اصطلاحات دقیق) ترکیب می‌کند و وزنی ۶۰ درصدی به فاصله برداری و ۴۰ درصدی به رتبه کلمات می‌دهد. برای افزایش نرخ بازیابی، سیستم از «بازیابی چندپرس‌وجویی» استفاده می‌کند؛ یعنی مدل Claude ابتدا سؤال کاربر را به ۲ یا ۳ عبارت جایگزین تبدیل می‌کند تا اگر کاربر «بلاک‌چین» جست‌وجو کرد اما در متن عبارت «تکنولوژی دفتر کل توزیع‌شده» آمده بود، باز هم تطابق ایجاد شود.

جزئیات فنی موتور بازیابی شامل موارد زیر است:

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

بازیابی اولیه اغلب «مبهم» است، بنابراین یک فرآیند دو مرحله‌ای معرفی شده: بازیابی سریع و سپس بازرتبه‌بندی (Reranking). در این مرحله، ۱۰ نتیجه برتر دوباره به مدل LLM فرستاده می‌شوند تا به‌عنوان یک متخصص مرتبط‌سازی، آن‌ها را با امتیازی بین ۰.۰ تا ۱.۰ مرتب کند. برای جلوگیری از سرریز توکن‌ها، تکه‌ها در این مرحله به ۲۰۰۰ کاراکتر محدود می‌شوند.

برای متوقف کردن توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — پنج لایه حفاظتی در src/services/safety.ts پیاده شده است:

• لایه ۱: مرزهای بازیابی: دستور صریح به مدل برای پاسخ دادن «فقط» بر اساس تکه‌های ارائه‌شده و در غیر این صورت گفتن «نامشخص».
• لایه ۲: خروجی ساختاریافته: اجبار مدل به بازگرداندن شیء JSON شامل پاسخ، امتیاز اعتماد و شاخص تکه‌های شاهد.
• لایه ۳: اعتبارسنجی شواهد: بررسی وجود واقعی شاخص‌های ذکر شده در آرایه داده‌ها.
• لایه ۴: گیت اعتماد: اعمال آستانه ۰.۷؛ اگر اعتماد مدل پایین‌تر باشد، پاسخ isSafe: false علامت می‌خورد.
• لایه ۵: بررسی وفاداری: تطبیق کلمات کلیدی پاسخ با متن شواهد؛ نرخ تطابق زیر ۸۰٪ باعث رد پاسخ می‌شود.

تحلیل هزینه و عملکرد نشان می‌دهد که هر پرس‌وجوی واحد حدود ۰.۰۰۷۵ دلار هزینه دارد. در مقیاس ۱ میلیون پرس‌وجو در ماه، این رقم به ۷۵۰۰ دلار می‌رسد. برای کاهش هزینه‌ها، راهکارهای زیر پیشنهاد شده است:

• کَشینگ (Caching): استفاده از Redis برای سؤالات تکراری (کاهش ۸۰٪ هزینه).
• دسته‌بندی (Batching): تبدیل برداری ۱۰۰ متن به‌صورت یک‌جا (کاهش ۲۰٪ سربار).
• تغییر مدل: استفاده از Claude Haiku برای کارهای ساده (کاهش ۸۰٪ هزینه نسبت به Sonnet).

برخی نقاط شکست حیاتی در این مسیر وجود دارد. نبود بررسی tenant_id منجر به نشت فوری داده‌ها می‌شود و فقدان ایندکس برداری، تأخیرها را از ۱۰۰ میلی‌ثانیه به ۱۰ ثانیه می‌برد. خطاهای رایج دیگر شامل محدودیت‌های نرخ API (خطای ۴۲۹) است که با استراتژی «عقب‌نشینی نمایی» (Exponential Backoff) حل می‌شود.

برای استقرار عملیاتی، استفاده از Docker با تصویر postgres:15-alpine و ساخت سفارشی pgvector توصیه می‌شود. چک‌لیست نهایی شامل مدیریت کلیدها در AWS Secrets Manager، استفاده از helmet برای امنیت Headerها و تست فشار با ۱۰۰۰ درخواست در ثانیه است.

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

گام بعدی شما

• ابتدا پیاده‌سازی بردارها در PostgreSQL را به تنهایی پایدار کنید.
• با افزایش حجم داده‌ها، لایه بازرتبه‌بندی (Reranker) را اضافه کنید.
• در ماه اول، تمرکز خود را روی لایه‌های ایمنی و در ماه سوم روی بهینه‌سازی هزینه بگذارید.

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