سیستم RAG در n8n
مقدمه
در عصر توسعه سریع ابزارهای مبتنی بر هوش مصنوعی، دسترسی به اطلاعات دقیق، بهروز و درونسازمانی یکی از چالشهای اصلی کسبوکارها است. مدلهای زبانی بزرگ مانند GPT-4 هرچند بسیار هوشمند هستند، اما از دانش خصوصی سازمان شما، مستندات داخلی یا پایگاههای دانش پویا آگاهی ندارند. برای حل این مشکل، معماری سیستم RAG در n8n (تولید هدایتشده با بازیابی اطلاعات یا Retrieval-Augmented Generation) به عنوان یک راهکار انقلابی مطرح شده است. این معماری به هوش مصنوعی اجازه میدهد قبل از پاسخگویی به سوالات، اطلاعات مرتبط را از پایگاههای داده اختصاصی شما فراخوانی کرده و پاسخی دقیق و بدون خطا ارائه دهد.
در این مقاله جامع، نحوه ساخت یک سیستم RAG در n8n را بهصورت کاملاً کاربردی بررسی خواهیم کرد. در این سناریو، مستندات موجود در پایگاه دانش Notion بهصورت خودکار و زمانبندیشده خوانده میشوند، پس از پردازش و تبدیل به بردار (Embedding)، در پایگاه داده برداری Supabase ذخیره میگردند و در نهایت یک چتبات هوشمند تعاملی از این دادهها برای پاسخگویی دقیق به سوالات کاربران استفاده میکند.
سیستم RAG در n8n برای چه کسب و کارهایی مناسب است:
اگر سازمان شما کوچک می باشد و هم اکنون بسیاری از کار های خود را با نرم افزار هایی همچون اکسل انجام می دهید، N8N برای کسب و کار شما ایده آل است و در صورتی که کسب و کاری متوسط یا بزرگ دارید می توانید بخش های بسیاری از فرایند های غیر کلیدی خود را با این ابزار هوشمند کنید.
و اگر به پیادهسازی اختصاصی، اتصال n8n به نرمافزارهای سازمانی یا سفارشیسازی Workflowها متناسب با کسبوکارتان نیاز دارید، Danix با بررسی نیازهای کسبوکار تان، میتواند این فرایند را از طراحی تا استقرار برای شما انجام دهیم.
برای کسب و کارهای کوچک به این لینک مراجعه کنید.
همچنین اگر ترجیح میدهید شخصاً نصب و راهاندازی را انجام دهید، میتوانید از اطلاعات موجود در مقالات، دسته N8N استفاده کنید .همچنین می توانید template موجود در این workflow را به صورت رایگان از این قسمت دانلود کنید.
رمز فایل: danixai.com
قبل از شروع
اگر هنوز n8n را نصب نکردهاید، پیشنهاد میکنیم ابتدا مقاله «آموزش n8n» را مطالعه کنید. در آن مقاله، مراحل نصب با Node.js و Docker، راهاندازی اولیه و ساخت اولین Workflow بهصورت کامل آموزش داده شده است. پس از نصب و راهاندازی، به این مقاله بازگردید و مراحل پیادهسازی این Workflow را دنبال کنید.
این Workflow برای سیستم RAG در n8n چه کاری انجام میدهد؟
این Workflow یک زنجیره کامل از فرآیند RAG روی دادههای پویا (Living Data) است که از دو بخش اصلی تشکیل شده است:
بخش اول، فرآیند همگامسازی و تولید بردارها (Data Ingestion Pipeline) است. سیستم بهصورت زمانبندیشده (مثلاً هر یک دقیقه یکبار) صفحات بهروزرسانیشده در دیتابیس Notion را شناسایی میکند. پس از استخراج مستندات جدید، تکههای قبلی مرتبط با آن صفحه را از پایگاه داده برداری Supabase پاکسازی میکند تا دادههای تکراری یا قدیمی باقی نمانند. سپس محتوای جدید را دریافت، یکپارچه و به بخشهای کوچکتر (Chunk) تقسیم میکند. در ادامه، با استفاده از مدل OpenAI Embeddings، این کلمات به بردارهای عددی تبدیل شده و در Supabase ذخیره میشوند.
بخش دوم، چتبات پاسخگویی به سوالات (Retrieval QA Chain) است. زمانی که کاربر از طریق رابط چت دستیار هوشمند سوالی میپرسد، سیستم سوال کاربر را به بردار تبدیل کرده و در پایگاه داده Supabase به دنبال شبیهترین و مرتبطترین بخشهای متن میگردد. سپس این دادههای بازیابیشده به همراه سوال کاربر به مدل GPT-4o ارسال میشوند تا پاسخی بسیار دقیق و کاملاً مبتنی بر اسناد رسمی سازمان تولید شود.
کاربردهای این Workflow
-
پشتیبانی هوشمند از مشتریان: اتصال مستندات راهنمای محصولات در Notion به چتبات سایت جهت پاسخگویی ۲۴ ساعته و دقیق به سوالات فنی کاربران.
-
دستیار آنبوردینگ پرسنل جدید: پاسخگویی خودکار به سوالات آییننامهای، منابع انسانی و فرآیندهای داخلی سازمان برای نیروهای تازه استخدامشده.
-
مدیریت پایگاه دانش درونسازمانی: جستجوی هوشمند در میان صدها صفحه صورتجلسات، مستندات پروژهها و قوانین شرکت بدون نیاز به مطالعه دستی.
-
دستیار تخصصی تیمهای پشتیبانی و فروش: دسترسی سریع کارشناسان به آخرین قیمتها، شرایط گارانتی و مشخصات فنی کالاها در حین مکالمه با مشتری.
-
تحلیل و خلاصهسازی گزارشهای پویا: بازیابی بخشهای مرتبط از گزارشهای طولانی موجود در Notion و ارائه خلاصه مدیریتی.
-
کاهش توهم (Hallucination) مدلهای هوش مصنوعی: محدود کردن پاسخهای مدل زبانی صرفاً به اطلاعات تاییدشده و موجود در دیتابیس اختصاصی.
پیشنیازها در مورد سیستم RAG در n8n
برای پیادهسازی و اجرای این سناریو، به پیشنیازهای زیر نیاز خواهید داشت:
-
نصب و راهاندازی n8n: دسترسی به نسخه لوکال یا سرور n8n.
-
کلید API حساب OpenAI: جهت دسترسی به مدلهای Embeddings و GPT-4o.
-
حساب کاربری Notion و ساخت Integration: جهت دریافت API Key و اتصال پایگاه دانش (Knowledge Base) به n8n.
-
حساب کاربری Supabase و پروژه فعال: جهت استفاده از افزونه Pgvector برای ذخیرهسازی و جستجوی بردارهای عددی.
-
ساخت جدول Documents در Supabase: ایجاد جدول استاندارد ذخیره بردارها (شامل ستونهای id، content، metadata و embedding).
دانلود Template
فایل JSON این Workflow را از این قسمت دانلود کنید.
آموزش Import کردن Workflow
وارد داشبورد n8n شوید. روی Import from File کلیک کنید. فایل JSON را انتخاب کنید. Workflow ایجاد خواهد شد. Credentialهای موردنیاز را تنظیم کنید.
ساختار Workflow جهت استفاده از سیستم RAG در n8n
اجرای این Workflow شامل دو مسیر مجزا اما وابسته به یکدیگر است:
مسیر همگامسازی دادهها (Ingestion): Schedule Trigger / Notion Trigger ↓ Get updated pages (Notion) ↓ Input Reference ↓ Loop Over Items ↓ Delete old embeddings if exist (Supabase) ↓ Get page blocks (Notion) ↓ Concatenate to single string (Summarize) ↓ Supabase Vector Store (Insert) ← [Embeddings OpenAI & Default Data Loader & Token Splitter]
مسیر چتبات و بازیابی (Retrieval): When chat message received ↓ Question and Answer Chain ← [OpenAI Chat Model] ↓ Vector Store Retriever ← [Supabase Vector Store & Embeddings OpenAI]
آموزش کامل تمام Nodeها برای سیستم RAG در n8n
1. Schedule Trigger
-
وظیفه: شروع زمانبندیشده فرآیند بررسی تغییرات در پایگاه دانش.
-
ورودی: تنظیمات زمانبندی سیستم.
-
خروجی: یک سیگنال اجرا در فواصل زمانی مشخص.
-
تنظیمات مهم: تنظیم interval روی فواصل دلخواه (مثلاً هر ۱ دقیقه).
-
نکات قابل تغییر: میتوانید زمان بررسی را متناسب با حجم تغییرات مستندات تغییر دهید.
-
دلیل استفاده: پایش مداوم Notion برای استخراج آخرین تغییرات صفحات.
2. Notion Trigger (غیرفعال به صورت پیشفرض)
-
وظیفه: جایگزین هوشمندتر برای Schedule Trigger بر اساس وقوع رویداد (Event-based).
-
ورودی: تغییرات لحظهای در دیتابیس مشخصشده در Notion.
-
خروجی: اطلاعات صفحهای که بهروزرسانی شده است.
-
تنظیمات مهم: رویداد
pageUpdatedInDatabaseو شناسه دیتابیس مربوطه. -
دلیل استفاده: کاهش تعداد اجراها (Executions) در برنامههای ابری.
3. Get updated pages (Notion Node)
-
وظیفه: فراخوانی لیست صفحاتی که در یک دقیقه گذشته تغییر کردهاند.
-
ورودی: سیگنال دریافتی از Schedule Trigger.
-
خروجی: لیست آرایهای از صفحات ویرایششده به همراه متادیتاها.
-
تنظیمات مهم: استفاده از فیلتر
Last edited timeبرابر با$now.minus(1, 'minutes').toISO(). -
دلیل استفاده: جلوگیری از پردازش مجدد صفحاتی که تغییری نداشتهاند.
4. Input Reference (NoOp Node)
-
وظیفه: عمل به عنوان یک نقطه مرجع و واسط ساختاری (Placeholder).
-
ورودی: دادههای خروجی از نود Notion.
-
خروجی: همان دادههای ورودی بدون تغییر.
-
دلیل استفاده: آسانسازی جایگزینی منبع داده (مثلا تغییر Notion به Google Docs) بدون بهم ریختن ارجاعات در نودهای بعدی.
5. Loop Over Items (Split in Batches Node)
-
وظیفه: پردازش تکتک صفحات تغییریافته بهصورت جداگانه.
-
ورودی: لیست تمام صفحات تغییریافته.
-
خروجی: ارسال تکتک آیتمها به داخل حلقه.
-
تنظیمات مهم: اندازه دستهها (Batch Size) بهصورت پیشفرض روی ۱ قرار دارد.
-
دلیل استفاده: ایزولهسازی فرآیند حذف و اضافه بردارها برای هر سند.
6. Delete old embeddings if exist (Supabase Node)
-
وظیفه: حذف بردارهای قدیمی سند جاری از دیتابیس Supabase.
-
ورودی: شناسه سند (
id) از نود Input Reference. -
خروجی: تاییدیه حذف دادههای قبلی.
-
تنظیمات مهم: فیلتر حذف بر اساس شرط
metadata->>id=eq.{{ $('Input Reference').item.json.id }}. -
دلیل استفاده: جلوگیری از ذخیره بردارهای تکراری و متناقض هنگام ویرایش یک صفحه در Notion.
7. Limit & Limit1 (Limit Nodes)
-
وظیفه: کنترل جریان داده و محدود کردن تعداد جریانهای فعال به ۱ آیتم.
-
ورودی: خروجی مراحل قبلی.
-
خروجی: یک جریان یکتای کنترلشده.
-
دلیل استفاده: جلوگیری از پردازش موازی تکراری در شاخههای بعدی ورکفلو.
8. Get page blocks (Notion Node)
-
وظیفه: استخراج تمام بلوکهای متنی و محتوایی داخل یک صفحه مشخص.
-
ورودی: شناسه صفحه Notion.
-
خروجی: لیست کامل بلوکهای متنی (پاراگرافها، تیترها، لیستها و…).
-
تنظیمات مهم: فعال بودن گزینه
fetchNestedBlocksبرای دریافت بلوکهای درونشهری و فرزند. -
دلیل استفاده: دسترسی به متن کامل داخل صفحات Notion.
9. Concatenate to single string (Summarize Node)
-
وظیفه: ادغام تمام بلوکهای متنی مجزای صفحه در یک رشته متنی یکپارچه.
-
ورودی: آرایه بلوکهای متنی صفحه.
-
خروجی: یک متن طولانی یکپارچه با جداسازی خط جدید (
\n). -
دلیل استفاده: آمادهسازی متن کامل برای فرآیند Chunking و تبدیل به بردار.
10. Token Splitter (Text Splitter Node)
-
وظیفه: قطعهقطعه کردن متنهای طولانی به بخشهای کوچکتر بر اساس تعداد توکن.
-
ورودی: متون ادغامشده.
-
خروجی: تکههای متنی بهینهسازیشده.
-
تنظیمات مهم:
chunkSizeروی ۵۰۰ توکن تنظیم شده است. -
دلیل استفاده: رعایت محدودیت ورودی مدلهای بردارساز و افزایش دقت در بازیابی اطلاعات.
11. Default Data Loader
-
وظیفه: ساخت شیء سند استاندارد (Document Object) به همراه متادیتاهای سفارشی.
-
ورودی: تکههای متنی خروجی از Splitter.
-
خروجی: ساختار متنی قابل فهم برای Vector Store.
-
تنظیمات مهم: تزریق متادیتای
idوnameمربوط به صفحه Notion در هر تکه متن. -
دلیل استفاده: حفظ ارتباط بین تکههای متن با سند اصلی در Notion برای ارجاعات بعدی.
12. Embeddings OpenAI
-
وظیفه: تبدیل متنها و سوالات کاربر به ریاضیات برداری (Vector Embeddings).
-
ورودی: متون خروجی از Data Loader یا سوال کاربر در چت.
-
خروجی: آرایهای از اعداد اعشاری (بردارها).
-
تنظیمات مهم: استفاده از مدل استانداردی مثل
text-embedding-ada-002یاtext-embedding-3-small. -
دلیل استفاده: امکانپذیر ساختن جستجوی معنایی (Semantic Search) در پایگاه داده.
13. Supabase Vector Store (Insert Mode)
-
وظیفه: ذخیرهسازی بردارهای تولیدشده به همراه متن و متادیتا در جدول
documentsدر Supabase. -
ورودی: دادههای برداری از OpenAI و ساختار سند از Data Loader.
-
خروجی: ذخیره موفق در دیتابیس و ادامه حلقه به آیتم بعدی.
-
تنظیمات مهم: تنظیم حالت روی
insertو انتخاب جدولdocuments. -
دلیل استفاده: پایگاه داده اصلی ذخیرهسازی دانش سازمان.
14. When chat message received (Chat Trigger)
-
وظیفه: نقطه شروع تعامل کاربر با چتبات RAG.
-
ورودی: پیام یا سوال ارسالشده از طرف کاربر در رابط چت.
-
خروجی: متن سوال کاربر.
-
دلیل استفاده: رابط کاربری دریافت سوالات.
15. OpenAI Chat Model
-
وظیفه: تحلیل دادههای بازیابیشده و تولید پاسخ نهایی به زبان طبیعی.
-
ورودی: پرامپت و دادههای زمینه (Context) ارسالشده از زنجیره QA.
-
خروجی: پاسخ متنی هوشمند.
-
تنظیمات مهم: انتخاب مدل
gpt-4o. -
دلیل استفاده: قدرت بالای استدلال و درک زبانی در ترکیب دادهها.
16. Supabase Vector Store1 & Vector Store Retriever
-
وظیفه: جستجو در پایگاه داده Supabase و یافتن نزدیکترین تکههای متنی به سوال کاربر.
-
ورودی: سوال کاربر به صورت بردار.
-
خروجی: چند قطعه متن بسیار مرتبط از اسناد Notion.
-
دلیل استفاده: تامین زمینه (Context) دقیق برای پاسخگویی مدل زبانی.
17. Question and Answer Chain (Retrieval QA Chain)
-
وظیفه: مدیریت کامل فرآیند RAG؛ ترکیب سوال کاربر با دادههای بازیابیشده و ارسال به GPT-4o.
-
ورودی: سوال کاربر، مدل زبانی OpenAI و بازیاب Vector Store Retriever.
-
خروجی: پاسخ نهایی و دقیق به کاربر.
-
دلیل استفاده: هسته مرکزی پردازش RAG که تمام اجزا را به یکدیگر متصل میکند.
نحوه شخصیسازی Workflow
این Workflow بهگونهای طراحی شده که انعطافپذیری بسیار بالایی برای تغییرات دارد:
-
تغییر منبع داده: با تغییر نود Notion در بخش Get updated pages و Get page blocks، میتوانید منابع دیگری مانند Google Drive، Confluence، فایلهای PDF یا دیتابیسهای SQL را جایگزین کنید.
-
تغییر مدل AI و Embeddings: به راحتی میتوانید نود OpenAI Embeddings را با Cohere، HuggingFace یا مدلهای محلی مثل Ollama تعویض کنید تا هزینهها کاهش یابد.
-
تنظیمات Chunking: میزان
chunkSizeو افزودنchunkOverlapدر نود Token Splitter قابل تغییر است. برای متنهای تخصصی، افزایش overlap باعث حفظ بهتر پیوستگی مفاهیم میشود. -
تغییر Vector Database: میتوان پایگاه داده Supabase را با Qdrant، Pinecone یا Chroma جایگزین نمود.
-
تغییر مدل چت: به جای GPT-4o میتوانید از مدلهای متناسب دیگر یا حتی مدلهای Claude از شرکت Anthropic استفاده کنید.
مزایای استفاده از این Workflow و سیستم RAG در n8n
-
پاسخگویی کاملاً بهروز (Living Data): بهروزرسانی خودکار دیتابیس برداری همزمان با تغییر اسناد در Notion.
-
حذف دادههای تکراری و قدیمی: پاکسازی هوشمند بردارهای قبلی سند پیش از درج نسخه جدید.
-
کاهش چشمگیر هزینههای API: پردازش تفکیکی و استفاده از فیلتر زمانی ۱ دقیقه برای جلوگیری از پردازش کل صفحات.
-
دقت بسیار بالا در پاسخگویی: ارجاع چتبات به دقیقترین تکههای متن با استفاده از معماری RAG.
-
پشتیبانی از متادیتاهای سفارشی: حفظ عنوان و شناسه سند اصلی جهت امکان ارجاع دقیق به منبع.
-
ساختار ماژولار: امکان تعویض ساده اجزای هوش مصنوعی، دیتابیس برداری یا منبع مستندات بدون تخریب کل سیستم.
نکات مهم
-
جدول
documentsدر Supabase باید دارای افزونهpgvectorباشد و ابعاد بردارها (Dimensions) دقیقاً با مدل Embedding انتخابی (مثلا ۱۵۳۶ برای ada-002) مطابقت داشته باشد. -
دقت کنید که Integration ساخته شده در Notion حتماً به دیتابیس Knowledge Base دسترسی (Access) داشته باشد.
-
مقدار
chunkSizeبه همراه overlap نباید از حد مجاز مدل بردارساز (مثلا ۸۱۹۱ توکن) تجاوز کند. -
نود Delete old embeddings بر اساس متادیتای
idعمل میکند؛ از تغییر ساختار متادیتا در Data Loader خودداری کنید. -
در صورت استفاده از خطه ابری n8n، پیشنهاد میشود به جای Schedule Trigger از Notion Trigger استفاده کنید تا تعداد Executions مصرفی کاهش یابد.
-
توصیه میشود متغیرهای حساس مانند API Keyها را حتما در بخش Credentials نرمافزار n8n ذخیره کنید.
-
برای بهبود پاسخهای چتبات، میتوانید System Prompt سفارشی به زنجیره QA اضافه کنید تا لحن پاسخگویی مشخص شود.
-
همواره میزان شارژ حساب OpenAI و ترافیک دیتابیس Supabase را پایش کنید.
خطاهای رایج در سیستم RAG در n8n
(Troubleshooting)
۱. خطای Dimension Mismatch در Supabase
-
علت: عدم خوانی ابعاد بردار تولیدشده توسط مدل OpenAI با ابعاد ستون vector در جدول Supabase.
-
راهحل: ستون embedding در جدول Supabase را طوری تنظیم کنید که ابعاد آن دقیقاً مطابق با خروجی مدل (مثلاً ۱۵۳۶) باشد.
۲. عدم بازیابی اطلاعات جدید ویرایششده در Notion
-
علت: عدم تطابق فیلتر زمان آخرین ویرایش (
last_edited_time) با زمان اجرای Schedule Trigger. -
راهحل: بازه زمانی در نود Get updated pages را با بازه تکرار Schedule Trigger یکسانسازی کنید.
۳. عدم پیدا کردن صفحات توسط Notion Node
-
علت: عدم اشتراکگذاری (Share) دیتابیس Notion با Integration ساخته شده.
-
راهحل: در صفحه دیتابیس Notion، از منوی سه نقطه بالا سمت راست، گزینه Add connections را بزنید و ربات خود را اضافه کنید.
۴. خطای Rate Limit از سمت OpenAI
-
علت: ارسال حجم زیادی از تکههای متنی به API بردارساز در یک زمان کوتاه.
-
راهحل: حجم اسناد ورودی را با استفاده از Loop کنترل کرده یا نرخ اجرا را کاهش دهید.
۵. پاسخهای نامرتبط چتبات (Empty Context)
-
علت: کوچک بودن بیش از حد
chunkSizeیا عدم وجود تشابه معنایی میان سوال کاربر و بردارهای ذخیرهشده. -
راهحل: مقدار
chunkSizeرا افزایش دهید و از درست ذخیره شدن متنها در جدول Supabase اطمینان حاصل کنید.
جمعبندی
طراحی و پیادهسازی سیستم RAG در n8n با استفاده از Notion و Supabase، یکی از حرفهایترین روشها برای هوشمندسازی جریانهای کاری و ساخت دستیارهای متنی مبتنی بر دانش واقعی سازمان است. این سناریو چالش متداول دادههای ایستا (Static Data) را حل کرده و به شما اجازه میدهد پایگاه دانشی پویا داشته باشید که با هر تغییر در اسناد Notion، بهروزرسانی میشود. با بهکارگیری این معماری، علاوه بر افزایش چشمگیر سرعت دسترسی به اطلاعات، پاسخهای هوش مصنوعی را کاملاً قابل اعتماد، دقیق و عاری از اطلاعات نادرست خواهید ساخت.
سوالات متداول
آیا ساخت این سیستم RAG نیازمند دانش کدنویسی پیشرفته است؟
خیر، تمامی مراحل در محیط بصری n8n و با استفاده از نودهای پیشفرض و استاندارد مدیریت میشوند.
آیا میتوان از دیتابیس برداری دیگری به جای Supabase استفاده کرد؟
بله، n8n از دیتابیسهای برداری متنوعی مانند Pinecone، Qdrant، Zep و Chroma پشتیبانی میکند و میتوانید نود مربوطه را به راحتی جایگزین کنید.
هزینه استفاده از این سیستم چقدر خواهد بود؟
اگر از نسخه Self-hosted n8n و طرح رایگان Supabase استفاده کنید، تنها هزینه پرداختی مربوط به مصرف API مدلهای OpenAI (Embeddings و GPT-4o) خواهد بود که بسیار اقتصادی است.
چگونه میتوان امنیت دادههای محرمانه Notion را حفظ کرد؟
تمام ارتباطات بین n8n، Notion و Supabase از طریق کلیدهای API امن و پروتکل HTTPS انجام میشود. همچنین با میزبانی شخصی n8n دادههای شما از کنترل خارج نخواهند شد.
اگر یک صفحه در Notion حذف شود، آیا بردارهای آن هم از Supabase پاک میشوند؟
در سناریوی فعلی، پاکسازی هنگام «ویرایش» انجام میشود. برای پاکسازی هنگام «حذف»، میتوانید یک شاخه شرطی اضافه کنید تا در صورت یافت نشدن صفحه، دستور حذف بردارهای آن ID به Supabase ارسال شود.



