گره QA Chain در n8n استقرار RAG را بدون کدنویسی ممکن کرد

اگر امروز برای مدیریت دانش سازمانی خود از اسناد پراکنده استفاده می‌کنید، احتمالاً می‌دانید که مدل‌های زبانی در مواجهه با داده‌های اختصاصی شرکت‌ها مستعد «خیال‌بافی» یا همان Hallucinations هستند. گره Question and Answer Chain در پلتفرم n8n این مشکل را با مجبور کردن مدل به پاسخ‌گویی صرفاً بر اساس مجموعه‌ای خاص از اسناد آپلودشده حل می‌کند.

به گزارش مستندات n8n، کاربران اکنون می‌توانند با متصل کردن یک مدل چت و یک ذخیره‌ساز برداری، سیستمی در سطح تولید (Production-ready) بسازند که به‌جای تکیه بر داده‌های عمومی آموزش مدل، از منابع تأییدشده و مستند استفاده کند. این رویکرد تضمین می‌کند که پاسخ‌ها بر اساس واقعیات تجاری شرکت باشند، نه احتمالات آماری مدل زبانی.

ساخت یک پایگاه دانش سفارشی پیش از این نیازمند پشته‌های تخصصی پایتون و استفاده از کتابخانه‌های پیچیده‌ای مانند LangChain یا LlamaIndex بود که تخصص عمیق در برنامه‌نویسی می‌طلبید. n8n این فرآیند را با معرفی یک گره داخلی که کل چرخه «بازیابی-تقویت-تولید» (Retrieve-Augment-Generate) را مدیریت می‌کند، به شدت ساده کرد. این تغییر استراتژیک، RAG را از قلمرو مهندسان هوش مصنوعی خارج کرده و به دست متخصصان اتوماسیون و تحلیلگران کسب‌وکار سپرد تا بدون نوشتن کد، سیستم‌های دانش‌بنیان ایجاد کنند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دقیق بر روی داده‌های ورودی، کلید دستیابی به پاسخ‌های قابل اعتماد است.

تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — در گره QA Chain از طریق یک جریان منطقی سه مرحله‌ای اجرا می‌شود:

• بازیابی (Retrieval): در این گام، گره ابتدا پرسش کاربر را به یک بردار معنایی (Embedding) تبدیل می‌کند. بردارها مانند کارت معرفی عددی برای هر واژه هستند که موقعیت معنایی کلمه را نسبت به سایر کلمات مشخص می‌کنند. سپس گره، ذخیره‌ساز برداری را برای یافتن تکه‌های متنی (Chunks) که از نظر معنایی به پرسش کاربر نزدیک‌تر هستند، کوئری می‌زند.
• تقویت (Augment): تکه‌های بازیابی‌شده از دیتابیس، مستقیماً به عنوان «بستر» یا زمینه (Grounding Context) به پرامپت مدل تزریق می‌شوند. این کار باعث می‌شود مدل بداند دقیقاً بر اساس چه متنی باید پاسخ دهد.
• تولید (Generate): در نهایت، این پرامپت تقویت‌شده به یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — ارسال می‌شود تا پاسخی مستند و واقعی تولید کند.

نتیجه این فرآیند، پاسخی است که در اسناد واقعی شما ریشه دارد، نه یک پاسخ تخیلی از سوی LLM. ورودی‌های رایج این سیستم شامل پرسش‌های کاربران است که از طریق یک Webhook، فرم‌های آنلاین یا تریگرهای چت وارد می‌شوند. همچنین یک ذخیره‌ساز برداری پر شده (مانند Pinecone، Qdrant، Weaviate یا نسخه‌های In-memory) به عنوان منبع داده مورد نیاز است. خروجی‌های متداول شامل یک پاسخ متنی مستند و در صورت فعال بودن تنظیمات، متادیتای مربوط به تکه‌های منبع است که مشخص می‌کند پاسخ دقیقاً از کدام سند استخراج شده است.

برای کارکرد صحیح، این گره به دو اتصال اجباری در سطح گره‌های زیرمجموعه (Sub-node) نیاز دارد. اول، یک مدل چت (Chat Model) مورد نیاز است؛ یعنی همان LLM که وظیفه تولید نهایی پاسخ را بر عهده دارد (مانند OpenAI GPT، Anthropic Claude، Google Gemini یا مدل‌های محلی Ollama). این قابلیت مدل‌های پیشرفته را در دسترس‌تر می‌کند، درست مانند آنچه در راهنمای ساخت سیستم تولید ایمیل با Claude و n8n مشاهده کردیم که نشان داد چگونه می‌توان از مدل‌های زبانی برای اتوماسیون‌های متنی پیچیده بهره برد.

دوم، یک بازیاب ذخیره‌ساز برداری (Vector Store Retriever) لازم است. این یک گره بازیاب است که یک ذخیره‌ساز برداری پر شده را در بر می‌گیرد. برای اتصال صحیح، شما باید یک گره Vector Store (مثلاً Pinecone Vector Store) اضافه کنید، حالت آن را بر روی «Retrieve Documents (For Agent/Chain)» تنظیم نمایید و سپس آن را به ورودی Vector Store Retriever در گره QA Chain متصل کنید.

در بخش تنظیمات و بهینه‌سازی، تطبیق دقیق «Query field» حیاتی است. این فیلد تعیین می‌کند که گره باید کدام بخش از داده‌های ورودی را به عنوان پرسش شناسایی کند. مقدار پیش‌فرض «query» است. اگر پرسش کاربر در فیلدی به‌جز query (مثلاً در message، text یا question) ارسال شود، گره یک رشته خالی به ذخیره‌ساز برداری می‌فرستد و در نتیجه نتایج تهی بازمی‌گرداند.

سایر تنظیمات کلیدی عبارت‌اند از:

• تعداد اسناد بازیابی‌شده (Top K): این تنظیم تعیین می‌کند که برای هر پرسش، چه تعداد از تکه‌های متنی برتر استخراج شوند. اگرچه مقدار پیش‌فرض ۴ است، اما بازه ۳ تا ۶ توصیه می‌شود. مقادیر بالاتر، زمینه (Context) بیشتری فراهم می‌کنند اما باعث افزایش هزینه‌ی توکن‌ها شده و ممکن است باعث «رقیق شدن» ارتباطات و کاهش دقت مدل شوند.
• بازگرداندن اسناد منبع (Return source documents): فعال کردن این گزینه، متادیتای تکه‌های منبع را در خروجی قرار می‌دهد. این قابلیت برای ایجاد پاسخ‌هایی که دارای ارجاع و استناد هستند ضروری است و ابزاری حیاتی برای عیب‌یابی (Debugging) مسیر بازیابی داده‌هاست.

طبق راهنمای فنی n8n، شش نکته حیاتی (Gotchas) برای جلوگیری از شکست گردشِ کار وجود دارد که کاربران باید به آن‌ها توجه کنند:

• پیش-پُرکردن (Pre-population): گره QA Chain در زمان پرسش فقط در حالت «خواندنی» است. این گره اسناد را ذخیره نمی‌کند، بلکه فقط از یک ذخیره موجود بازیابی می‌کند. بنابراین شما باید یک گردشِ کار (Workflow) مجزای Ingestion بسازید تا ابتدا اسناد را تبدیل به بردار کرده و در دیتابیس ذخیره کنید.
• عدم تطبیق مدل‌ها (Model Mismatch): مدل Embeddings که در زمان پرسش استفاده می‌شود باید دقیقاً همان مدلی باشد (با همان ابعاد برداری) که هنگام ذخیره اولیه داده‌ها به کار رفته است. عدم تطبیق این دو مدل منجر به بازیابی‌های بی‌معنی و امتیازات شباهت کسینوسی (Cosine Similarity) غلط می‌شود.
• اشتباه در نام فیلد: همان‌طور که اشاره شد، اگر تنظیم روی «query» باشد اما داده در «message» باشد، رشته‌ای خالی ارسال می‌شود. در این حالت بازیاب هیچ تکه‌ای بر نمی‌گرداند و LLM یا بر اساس داده‌های آموزشی کلی خود پاسخ می‌دهد یا می‌گوید «نمی‌دانم».
• اندازه تکه‌ها (Chunk Sizing): اگر تکه‌ها بیش از حد کوچک باشند (کمتر از ۱۰۰ توکن)، بستر اطلاعاتی تکه‌تکه شده و مدل نمی‌تواند پاسخ جامع بسازد. اگر بیش از حد بزرگ باشند (بیش از ۱۰۰۰ توکن)، محدودیت پنجره متنی (Context Limit) مدل رد شده و هزینه‌ها افزایش می‌یابد. اندازه ۳۰۰ تا ۵۰۰ توکن با حدود ۵۰ توکن همپوشانی (Overlap) برای حفظ پیوستگی معنایی، ایده‌آل است.
• فقدان حفاظ‌ها (Guardrail Absence): اگرچه RAG مدل را مستند می‌کند، اما اگر تکه‌های بازیابی‌شده کافی نباشند، مدل باز هم ممکن است توهم بزند. راهکار این است که در پرامپت سیستم صراحتاً دستور دهید: «اگر اطلاعات کافی در متن ارائه شده برای پاسخگویی وجود ندارد، دقیقاً بگویید: من اطلاعات کافی برای پاسخ به این سوال را ندارم».
• ماندگاری حافظه (Memory Persistence): ذخیره‌سازهای در-حافظه (in-memory) با هر بار اجرای گردشِ کار ریست می‌شوند. این حالت برای تست یا پردازش‌های دسته‌ای (Batch) مفید است، اما برای سیستم‌های عملیاتی در محیط تولید، حتماً باید از ذخیره‌سازهای پایدار مانند Pinecone، Qdrant یا Weaviate استفاده کرد.

پلتفرم n8n سه الگوی معماری پیشنهادی برای استقرار این گره در دنیای واقعی ارائه می‌دهد:

الگوی اول: ربات دانش داخلی (Internal Knowledge Base Bot)
این سناریو یک ویکی Notion یا فضای Confluence را به یک ربات در Slack یا Teams تبدیل می‌کند.

• جریان ذخیره‌سازی (Ingestion): درخواست HTTP (دریافت اسناد) $
  ightarrow$ گره Code (تکه-بندی به قطعات ۴۰۰ توکنی) $
  ightarrow$ گره Embeddings (مدل OpenAI text-embedding-3-small) $
  ightarrow$ ذخیره‌ساز Pinecone (ذخیره با متادیتای عنوان سند، URL و تاریخ به‌روزرسانی).
• جریان پرسش (Query): تریگر Webhook (از Slack) $
  ightarrow$ گره QA Chain (متصل به GPT-4o یا Claude و بازیاب Pinecone با Top K: 5 و فعال‌سازی اسناد منبع) $
  ightarrow$ گره Code (فرمت کردن لینک‌ها) $
  ightarrow$ درخواست HTTP (ارسال پاسخ به Slack).
• دلیل موفقیت: جریان ذخیره‌سازی باعث به‌روز ماندن دیتابیس می‌شود، در حالی که جریان پرسش، بدون وضعیت (Stateless) و سریع باقی می‌ماند.

الگوی دوم: پرسش‌و‌پاسخ PDF مشتری‌محور (Customer-Facing PDF Q&A)
این الگو به کاربران اجازه می‌دهد بدون خواندن کامل دفترچه‌های راهنما، اسناد تطبیقی یا قراردادهای حقوقی، از آن‌ها سوال بپرسند.

• جریان ذخیره‌سازی (Sourcing): درخواست HTTP (دانلود PDF) $
  ightarrow$ گره Extract From File $
  ightarrow$ گره Code (تکه-بندی ۴۰۰ توکنی و برچسب‌گذاری با doc_id) $
  ightarrow$ مدل OpenAI Embeddings $
  ightarrow$ ذخیره‌ساز Qdrant (ذخیره با استفاده از Namespace بر اساس doc_id).
• جریان پرسش (Query): تریگر Webhook (دریافت { doc_id, question }) $
  ightarrow$ گره QA Chain (متصل به مدل چت و بازیاب Qdrant که فقط در Namespace مربوط به همان doc_id فیلتر می‌کند، Top K: 4) $
  ightarrow$ پاسخ HTTP.
• دلیل موفقیت: استفاده از Namespace بر اساس doc_id اجازه می‌دهد هزاران سند در یک ذخیره‌ساز قرار بگیرند اما هر پرسش فقط محدود به فایل مربوط به همان کاربر یا محصول شود.

الگوی سوم: پاسخ‌دهنده خودکار تیکت‌های پشتیبانی (Support Ticket Auto-Responder)
این الگو از تاریخچه تیکت‌های حل‌شده برای پیش‌نویس پاسخ به تیکت‌های جدید استفاده می‌کند.

• جریان ذخیره‌سازی: درخواست HTTP (APIهای Zendesk یا Linear) $
  ightarrow$ گره Filter (انتخاب فقط تیکت‌های «حل‌شده» با امتیاز Agent > 4) $
  ightarrow$ گره Code (فرمت‌بندی به شکل «مشکل: ... راه حل: ...») $
  ightarrow$ Embeddings $
  ightarrow$ ذخیره‌ساز Pinecone (ذخیره با متادیتای ticket_id و Category).
• جریان پرسش: تریگر Webhook $
  ightarrow$ گره QA Chain (با پرامپت سیستم: «یک پاسخ پشتیبانی را صرفاً بر اساس متن ارائه شده پیش‌نویس کن» و بازیاب Pinecone با Top K: 3 و فیلتر بر اساس Category) $
  ightarrow$ درخواست HTTP (ارسال پیش‌نویس به یادداشتهای داخلی Zendesk) $
  ightarrow$ اعلان Slack برای بازبینی انسانی.
• دلیل موفقیت: مدل بر اساس راهکارهای اثبات‌شده پیش‌نویس می‌زند. فیلتر بر اساس دسته‌بندی، دقت را بالا می‌برد و گام «انسان در حلقه» (Human-in-the-loop) کیفیت نهایی را تضمین می‌کند.

در مقایسه با سایر گره‌های هوش مصنوعی، تفاوت‌های کلیدی را در جدول زیر مشاهده می‌کنید:

قاعده کلی این است: هرگاه پاسخ‌ها باید در اسناد شما ریشه داشته باشند، از QA Chain استفاده کنید؛ اما اگر دانش عمومی مدل کافی است، Basic LLM Chain گزینه بهتری است.

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

هر سه الگوی ذکر شده در بسته‌های گردشِ کار n8n (Workflow Packs) در Gumroad موجود هستند. شما می‌توانید فایل JSON آن‌ها را دانلود کرده و مستقیماً در نمونه n8n خود وارد کنید تا استقرار سیستم را سریع‌تر آغاز نمایید.

گام بعدی شما

• اگر از n8n استفاده می‌کنید، ابتدا یک جریان مجزای Ingestion برای تبدیل اسناد به بردار بسازید.
• برای کاهش نرخ توهم، اندازه تکه‌ها را روی ۴۰۰ توکن با ۵۰ توکن همپوشانی تنظیم کنید.
• حتماً خروجی Source Documents را فعال کنید تا بتوانید صحت پاسخ‌ها را با منبع تطبیق دهید.

اما تأثیر این ساده‌سازی بر معماری عامل‌های هوش مصنوعی پیچیده‌تر است؛ در تحلیل ما درباره‌ی پروتکل MCP و آینده اتصال مدل‌ها به داده‌ها بیشتر بخوانید.