اگر امروز درگیر «تله نمونه اولیه» هستید و اسکریپت‌های محلی شما در مقیاس واقعی شکست می‌خورند یا به یک کابوس نگهداری تبدیل شده‌اند، باید بدانید که فاصله بین یک دموی ساده و یک محصول تجاری در مدیریت زیرساخت است. تصور کنید مجبور باشید برای داده‌های رابطه‌ای و جاسازی‌های برداری (Vector Embeddings) دو پایگاه داده مجزا را مدیریت کنید؛ این اصطکاک معمولاً سرعت انتقال از یک دمو به یک محصول واقعی را کاهش می‌دهد. یک سامانه تولیدی تولید بازیابی‌افزا (RAG) — شبیه کتابخانه‌داری که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — به ادغام دقیق حافظه، مسیریابی و زیرساخت استقرار نیاز دارد. برای درک بهتر این انتخاب در استراتژی‌های مختلف، می‌توان به راهنمای جامع انتخاب میان پرامپت، RAG و تنظیم دقیق برای استقرار هوش مصنوعی در سال ۲۰۲۶ رجوع کرد.
طبق گزارش منتشرشده در ۲۷ ژوئن ۲۰۲۶ در وب‌سایت dev.to، یک سری فنی و مفصل از مسیر معماری دقیق برای دستیابی به این هدف با استفاده از pgvector و پروتکل زمینهٔ مدل (MCP) ترسیم شده است. بسیاری از توسعه‌دهندگان با دشواری مدیریت جداگانه پایگاه‌های داده رابطه‌ای و بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و همسایگی کلمات را مشخص می‌کند — روبرو هستند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، سادگی در لایه داده، کلید پایداری سیستم است. با استفاده از PostgreSQL و افزونه pgvector، توسعه‌دهندگان می‌توانند هر دو نوع داده (SQL و بردارها) را در قالب یک درخواست واحد فراخوانی کنند و پایگاه‌داده را به عنوان تنها منبع حقیقت (Single Source of Truth) به کار گیرند.
توالی ساخت سیستم
بر اساس مستندات این راهنما، سامانه در ۱۳ مرحله تکاملی، در حالی که از یک پروژه پایتون کاملاً خالی شروع شده بود، توسعه یافته است. این پیشروی به صورت متدیک و گام‌به‌گام انجام شد:
- فاز ۱: هسته برداری – تنظیم جداول pgvector (فایل 01_setup_db.py)، ایجاد ایندکس HNSW (فایل 02_create_index.py)، وارد کردن اسناد (فایل 03_ingest.py) و پیاده‌سازی جست‌وجوی شباهت کسینوسی (فایل 04_search.py).
- فاز ۲: RAG و ابزارها – ساخت خط لوله RAG (فایل 05_rag.py) و پیاده‌سازی مکانیسم انتخاب ابزار پایه (فایل 06_tool_basic.py) و مسیریابی چند-ابزاری (فایل 07_tool_multi.py).
- فاز ۳: عامل‌ها – ایجاد یک حلقه عامل‌محور (Agentic) چندمرحله‌ای (فایل 08_tool_agent.py)، پیاده‌سازی الگوی ری‌اکت (ReAct) (فایل 09_agent_basic.py) — شبیه وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — افزودن حافظه پایدار بین جلسات کاربر (فایل 10_agent_memory.py) و ساخت حلقه «برنامه‌ریزی $\rightarrow$ اجرا $\rightarrow$ ارزیابی» (فایل 11_agent_planner.py). این رویکرد دقیقاً با این دیدگاه همسو است که تولید بازیابی‌افزای عامل‌محور را بیشتر یک چالش در زیرساخت‌های توزیع‌شده بدانیم تا یک مسئله مربوط به مهندسی پرامپت.
- فاز ۴: زیرسافت MCP – توسعه سرورها برای stdio/Claude Desktop (فایل server.py)، پروتکل HTTP (فایل server_http.py) و استقرار در Render (فایل server_render.py)، و در نهایت اتصال آن‌ها از طریق عامل‌های محلی (فایل 12_mcp_agent.py) و ابری (فایل 13_mcp_http_agent.py).
این پشته از مدل gemini-embedding-001 استفاده می‌کند. طبق اعلام نویسنده، یک محدودیت فنی خاص وجود دارد: در حالی که این مدل ۳۰۷۲ بُعد خروجی می‌دهد، ایندکس HNSW در pgvector دارای یک محدودیت سخت‌افزاری ۲۰۰۰ بُعدی است. برای حل این مشکل، سیستم از ۷۶۸ بُعد استفاده می‌کند که نویسنده ادعا می‌کند منجر به کاهش ناچیز کیفیت شده است.
مشخصات فنی و طراحی
- ایندکس‌گذاری: سیستم از HNSW (با تنظیمات m=16 و ef_construction=64) به جای IVFFlat استفاده می‌کند؛ زیرا نیازی به داده‌های آموزشی ندارد، در مقیاس بالا بازخوانی (Recall) پایدارتری ارائه می‌دهد و در زمان پرس‌وجو سریع‌تر است. IVFFlat تنها برای مواردی که محدودیت شدید حافظه وجود دارد توصیه می‌شود.
- استراتژی بازیابی: در این سیستم از انواع متضاد (Asymmetric Task Types) استفاده شده است؛ یعنی RETRIEVAL_DOCUMENT هنگام ذخیره‌سازی و RETRIEVAL_QUERY هنگام جست‌وجو. از آنجا که مدل، پرس‌وجوها را به سمت اسناد هدایت می‌کند (و نه به یک نقطه یکسان)، استفاده از انواع یکسان باعث کاهش دقت می‌شود.
- حلقه عامل‌محور: خط لوله، الگوی ReAct را پیاده می‌کند. مدل زبانی بزرگ (LLM) ابزارها را بر اساس «فیلد توضیحات» انتخاب می‌کند؛ توضیحات دقیق، انتخاب درست را تضمین می‌کند، در حالی که توضیحات مبهم باعث رفتار تصادفی مدل می‌شود.
- مکانیزم حافظه: تاریخچه گفتگو به عنوان حافظه عامل عمل می‌کند. هر فراخوانی ابزار و نتیجه آن به محتویات (contents) اضافه شده و LLM در هر گام، کل تاریخچه را برای استدلال چندمرحله‌ای می‌خواند.
- زیرساخت: از Render برای میزبانی سرور MCP و از Supabase برای پایگاه‌داده pgvector استفاده شده است.
یک نکته کلیدی در شبکه، استفاده از Connection Pooler روی پورت ۶۵۴۳ است. به نقل از نویسنده، این کار اجباری است زیرا Render از پروتکل IPv6 که در پورت استاندارد ۵۴۳۲ Supabase استفاده می‌شود، پشتیبانی نمی‌کند.
خلاصه معماری نهایی
سیستم در دو حالت عمل می‌کند. جریان محلی (Local Flow): Claude Desktop $\rightarrow$ سرور mcp_server/server.py (via stdio) $\rightarrow$ psycopg2 $\rightarrow$ pgvector (Docker). جریان ابری (Cloud Flow): یک عامل پایتونی (فایل 13_mcp_http_agent.py) $\rightarrow$ HTTPS Render (فایل server_render.py) $\rightarrow$ PostgreSQL + SSL (پورت ۶۵۴۳) $\rightarrow$ Supabase (pgvector) $\rightarrow$ Gemini Embedding + LLM.
این معماری نقش ابزارها را از توابع سخت‌کد شده پایتونی به زیرساختی مستقل از طریق MCP تغییر می‌دهد. با تبدیل تعاریف ابزار به یک سرور، یک کد واحد می‌تواند هم‌زمان Claude Desktop، عامل‌های Gemini و سایر کلاینت‌ها را بدون تکرار منطق تغذیه کند.
برای توسعه‌دهنده، پیچیدگی از «کدنویسی یک ویژگی» به «مدیریت یک سرویس» منتقل می‌شود. اثر مرتبه دوم این تغییر، یک سیستم جداساز (Decoupled) است که در آن LLM دیگر تنها ارکستراتور نیست، بلکه کلاینت یک سرور ابزار قدرتمند است.
با این حال، این ساختار بیشتر بر عملکرد متمرکز است تا قابلیت اطمینان. رسیدن به سطح تولیدی واقعی نیازمند حل چالش «ارزیابی‌ها» (Evals) — اندازه‌گیری خودکار بازخوانی زمینه (Context Recall)، مرتبط بودن پاسخ (Answer Relevancy) و وفاداری (Faithfulness) — و نظارت با ابزارهایی مثل Langfuse برای ردیابی تأخیر و مسائل کیفی است.
همچنین شکاف‌های امنیتی در برابر تزریق پرامپت (Prompt Injection)، جیل‌بریک‌ها (Jailbreaks) و نشت داده‌های حساس (PII) باید با پیاده‌سازی حفاظ‌ها (Guardrails) پوشانده شوند. علاوه بر این، نیازهای عملیاتی مثل تنظیم دقیق لورا (LoRA)، الگوهای چند-عاملی «ارکستراتور-ورکر» و انطباق با قوانین هوش مصنوعی اتحادیه اروپا (EU AI Act) باید مورد توجه قرار گیرند.
این مباحث پیشرفته در «راهنمای عملیات تولید: جلد دوم» پوشش داده شده‌اند که جزئیات خطوط لوله CI/CD، نسخه‌بندی پرامپت‌ها و ثبت گزارش‌های حسابرسی (Audit Logging) را شرح می‌دهد. برای بررسی کامل پیاده‌سازی جلد اول، می‌توانید به کد منبع در github.com/qameqame/pgvector-tutorial دسترسی داشته باشید.
گام بعدی شما
- بررسی کد منبع در github.com/qameqame/pgvector-tutorial برای پیاده‌سازی گام‌به‌گام.
- جایگزینی توابع محلی با ساختار MCP برای جداسازی منطق ابزار از لایه مدل.
- پیاده‌سازی معیارهای Evals برای سنجش نرخ توهم در پاسخ‌های بازیابی شده.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو