گام به گام: اجرای Retrieval Augmented Generation در n8n

در دنیای امروز که هوش مصنوعی و مدل‌های زبانی بزرگ (LLMs) با سرعتی بی‌سابقه در حال تحول هستند، کسب‌وکارها و توسعه‌دهندگان به دنبال راه‌هایی برای بهره‌برداری حداکثری از این فناوری‌ها هستند. با این حال، LLMs به‌تنهایی دارای محدودیت‌هایی همچون “توهم‌زایی” (hallucination)، عدم دسترسی به داده‌های لحظه‌ای یا اختصاصی سازمان، و وابستگی به داده‌های آموزشی ثابت هستند. اینجاست که تکنیک Retrieval Augmented Generation (RAG) به عنوان یک راه‌حل قدرتمند وارد میدان می‌شود. RAG به LLM اجازه می‌دهد تا پیش از تولید پاسخ، به یک پایگاه دانش خارجی و قابل اعتماد دسترسی پیدا کرده و اطلاعات مرتبط را بازیابی کند، بدین ترتیب دقت، اعتبار و به‌روز بودن پاسخ‌ها را به شکل چشمگیری افزایش می‌دهد.

اما چگونه می‌توان یک سیستم RAG پیچیده را بدون نیاز به کدهای سنگین و زمان‌بر پیاده‌سازی کرد؟ n8n، به عنوان یک ابزار اتوماسیون قدرتمند و Low-Code/No-Code، پاسخی جامع به این چالش ارائه می‌دهد. n8n با قابلیت‌های گسترده خود در اتصال به سرویس‌های مختلف، دستکاری داده‌ها و اجرای منطق‌های پیچیده، بستری ایده‌آل برای ارکستراسیون یک سیستم RAG فراهم می‌کند. این پلتفرم به شما امکان می‌دهد تا تمام اجزای یک Pipeline RAG، از جمع‌آوری و آماده‌سازی داده‌ها گرفته تا جستجوی معنایی و فراخوانی LLM، را به صورت بصری و کارآمد مدیریت کنید.

هدف این پست، ارائه یک راهنمای جامع و گام به گام برای پیاده‌سازی Retrieval Augmented Generation در n8n است. ما از مفاهیم اولیه RAG شروع کرده، به معرفی n8n خواهیم پرداخت، اجزای کلیدی یک سیستم RAG را تشریح می‌کنیم و سپس به صورت عملی، نحوه ساخت دو Pipeline اصلی (ورود داده و بازیابی/تولید) را در n8n بررسی خواهیم کرد. در ادامه، به نکات بهینه‌سازی و پیشرفته خواهیم پرداخت و با یک مطالعه موردی، کاربرد عملی این تکنولوژی را به نمایش می‌گذاریم. این راهنما برای توسعه‌دهندگان، مهندسین داده، متخصصین اتوماسیون و هر کسی که علاقه‌مند به ساخت سیستم‌های هوشمند مبتنی بر LLM با کارایی بالا است، طراحی شده است.

Retrieval Augmented Generation (RAG) چیست و چرا اهمیت دارد؟

برای درک عمیق‌تر RAG، ابتدا باید نگاهی به نحوه کارکرد LLMs در حالت سنتی بیندازیم. مدل‌های زبانی بزرگ (Large Language Models) مانند GPT-4 یا Llama 2، بر روی حجم عظیمی از داده‌های متنی آموزش دیده‌اند و توانایی درک، خلاصه‌سازی، ترجمه و تولید متن را دارند. دانش این مدل‌ها محدود به داده‌هایی است که در زمان آموزش به آن‌ها داده شده و پس از آن، به روزرسانی دانش آن‌ها نیازمند فرآیند پرهزینه و زمان‌بر بازآموزی (retraining) است. این موضوع به دو چالش اصلی منجر می‌شود:

• توهم‌زایی (Hallucination): LLMs ممکن است اطلاعاتی را تولید کنند که از لحاظ منطقی صحیح به نظر می‌رسند اما مبنای واقعی ندارند یا غلط هستند. این اتفاق زمانی می‌افتد که مدل برای پاسخ به یک سوال، به داده‌های کافی در مجموعه آموزشی خود دسترسی ندارد و سعی می‌کند با استفاده از الگوهای زبانی، پاسخی را “حدس بزند”.
• عدم دسترسی به اطلاعات لحظه‌ای و اختصاصی: دانش LLMs پس از آموزش ثابت می‌ماند. این بدان معناست که آن‌ها نمی‌توانند به اطلاعات جدید، مانند آخرین اخبار، تغییرات در محصولات یک شرکت، یا داده‌های داخلی و محرمانه یک سازمان دسترسی داشته باشند.

Retrieval Augmented Generation (RAG) راهکاری برای رفع این محدودیت‌ها است. RAG رویکردی است که توانایی‌های تولید متن LLMs را با قدرت بازیابی اطلاعات از یک منبع داده خارجی و معتبر ترکیب می‌کند. به عبارت ساده، یک سیستم RAG قبل از اینکه LLM پاسخی را تولید کند، ابتدا به یک پایگاه دانش سفارشی‌شده نگاه می‌کند، قطعات مرتبط اطلاعات را پیدا می‌کند و سپس این اطلاعات را به عنوان “بافت” (context) به LLM ارائه می‌دهد. LLM سپس از این بافت ارائه شده برای تولید پاسخی دقیق‌تر، مرتبط‌تر و قابل اتکاتر استفاده می‌کند.

مراحل اصلی در یک سیستم RAG:

1. بازیابی (Retrieval): در این مرحله، سیستم با استفاده از یک موتور جستجوی معنایی، به دنبال اطلاعات مرتبط با query کاربر در پایگاه دانش خارجی می‌گردد. این پایگاه دانش معمولاً شامل اسناد، مقالات، صفحات وب، یا هر نوع داده متنی دیگری است که از قبل پردازش و به صورت بردارهای عددی (embeddings) ذخیره شده‌اند.
2. افزایش بافت (Augmentation): قطعات اطلاعات بازیابی شده (که اغلب به آن‌ها “chunks” گفته می‌شود) سپس به همراه query اصلی کاربر، به عنوان یک پرامپت تقویت‌شده (augmented prompt) به LLM ارسال می‌شوند.
3. تولید (Generation): LLM از این پرامپت تقویت‌شده برای تولید پاسخ نهایی استفاده می‌کند. با داشتن بافت مرتبط، LLM می‌تواند پاسخی دقیق‌تر و مبتنی بر واقعیت ارائه دهد و از توهم‌زایی جلوگیری کند.

اهمیت RAG:

• کاهش توهم‌زایی و افزایش دقت: با ارائه اطلاعات واقعی و مرتبط، LLM کمتر به “حدس زدن” متوسل می‌شود و پاسخ‌های دقیق‌تری ارائه می‌دهد.
• دسترسی به اطلاعات لحظه‌ای و اختصاصی: سازمان‌ها می‌توانند پایگاه دانش RAG خود را با داده‌های داخلی، مستندات محصولات، گزارش‌های مالی یا هر منبع اطلاعاتی دیگری که برای LLM در زمان آموزش در دسترس نبوده، تغذیه کنند. این امر به LLM امکان می‌دهد تا به اطلاعات کاملاً به‌روز و مختص یک سازمان دسترسی داشته باشد.
• قابلیت توجیه و شفافیت (Explainability): از آنجایی که پاسخ LLM بر اساس اطلاعات بازیابی شده تولید می‌شود، می‌توان منابعی را که LLM از آن‌ها استفاده کرده است، ردیابی و به کاربر نشان داد. این شفافیت، اعتمادپذیری سیستم را افزایش می‌دهد.
• کاهش هزینه‌ها و زمان: به جای نیاز به بازآموزی مداوم LLM برای به‌روزرسانی دانش آن (که بسیار گران و زمان‌بر است)، می‌توان به سادگی پایگاه دانش RAG را به‌روز کرد.
• انعطاف‌پذیری: RAG به شما اجازه می‌دهد تا با استفاده از LLMs عمومی، سیستم‌هایی بسازید که به صورت تخصصی برای دامنه کاری شما عمل کنند.

به طور خلاصه، RAG یک پل ارتباطی حیاتی بین قدرت زبانی LLMs و واقعیت داده‌های شما ایجاد می‌کند و این امکان را می‌دهد تا از هوش مصنوعی مولد به شکلی مسئولانه، دقیق و کاربردی در محیط‌های حرفه‌ای بهره‌برداری شود.

مقدمه‌ای بر n8n: ابزاری قدرتمند برای اتوماسیون هوشمند

در پیچیدگی‌های جهان فناوری امروز، نیاز به ابزارهایی که بتوانند فرآیندهای کسب‌وکار را ساده‌سازی و خودکار کنند، بیش از پیش احساس می‌شود. n8n (تلفظ “ان ایت ان”) یکی از پیشروترین پلتفرم‌ها در این زمینه است که به عنوان یک ابزار اتوماسیون Low-Code/No-Code شناخته می‌شود. این بدان معناست که کاربران می‌توانند، بدون نیاز به نوشتن مقادیر زیادی کد یا حتی بدون هیچ کدی، جریان‌های کاری (workflows) پیچیده‌ای را برای اتصال برنامه‌ها و سرویس‌های مختلف، دستکاری داده‌ها و خودکارسازی وظایف ایجاد کنند.

n8n چیست؟

n8n یک موتور اتوماسیون منبع باز است که به شما امکان می‌دهد فرآیندها و وظایف را بین بیش از 400 برنامه و سرویس مختلف، از جمله ابزارهای بهره‌وری، پایگاه‌های داده، سیستم‌های CRM، ابزارهای بازاریابی، APIهای مختلف و حتی مدل‌های هوش مصنوعی، خودکار کنید. ویژگی اصلی n8n، رویکرد مبتنی بر گره (node-based) و بصری آن است. هر “گره” (node) یک عملکرد خاص را انجام می‌دهد، مانند ارسال یک درخواست HTTP، خواندن از یک پایگاه داده، تبدیل داده‌ها یا فراخوانی یک مدل LLM. با اتصال این گره‌ها به یکدیگر، می‌توان منطق‌های پیچیده‌ای را به سادگی و به صورت گرافیکی ساخت.

ویژگی‌های کلیدی n8n مرتبط با RAG:

چندین ویژگی n8n آن را به گزینه‌ای ایده‌آل برای ارکستراسیون یک سیستم RAG تبدیل می‌کند:

• اتصال‌پذیری گسترده (Extensive Integrations): n8n دارای گره‌های داخلی برای اتصال به بسیاری از سرویس‌های ابری محبوب، پایگاه‌های داده، ابزارهای ذخیره‌سازی فایل و APIهای سفارشی است. این امکان را فراهم می‌کند تا داده‌ها را از منابع مختلف (مانند Google Drive, Dropbox, پایگاه داده‌های SQL, APIهای RESTful) جمع‌آوری کرده و همچنین با سرویس‌های LLM (مانند OpenAI) و پایگاه‌های داده برداری (Vector Databases) ارتباط برقرار کنید.
• گره HTTP Request: این گره یکی از قدرتمندترین ابزارهای n8n است که به شما امکان می‌دهد با هر API خارجی، از جمله APIهای Embedding، Vector Database و LLM، ارتباط برقرار کنید. این انعطاف‌پذیری برای یکپارچه‌سازی با اجزای RAG حیاتی است.
• گره Code: برای سناریوهایی که نیاز به منطق سفارشی یا پردازش پیچیده داده‌ها دارید، گره Code به شما اجازه می‌دهد تا کد جاوااسکریپت بنویسید. این قابلیت برای عملیاتی مانند chunking پیشرفته، پاکسازی داده‌ها یا فرمت‌بندی پرامپت‌ها بسیار مفید است.
• گره Data Manipulation: گره‌هایی مانند `Set`, `Merge`, `Split In Batches`, `Item Lists` و `Map` به شما امکان می‌دهند تا داده‌ها را در طول Workflow به طور موثر تبدیل، فیلتر و ساختاردهی کنید.
• قابلیت اجرا در محیط‌های مختلف: n8n می‌تواند به صورت محلی، در یک کانتینر Docker، یا بر روی سرورهای ابری مستقر شود، که انعطاف‌پذیری زیادی در انتخاب محیط عملیاتی فراهم می‌کند.
• مدیریت خطا و تلاش مجدد (Error Handling & Retries): n8n ابزارهایی برای مدیریت خطاها و تنظیم منطق تلاش مجدد در Workflowها فراهم می‌کند که برای ساخت سیستم‌های RAG پایدار حیاتی است.

چرا n8n برای RAG ایده‌آل است؟

n8n به عنوان یک ارکستراتور (orchestrator) عالی برای RAG عمل می‌کند زیرا:

• بصری‌سازی فرآیند: پیچیدگی‌های RAG (جمع‌آوری داده، chunking، embedding، ذخیره‌سازی، بازیابی، پرامپت‌نویسی) را می‌توان به صورت بصری و گام به گام در یک Workflow n8n نمایش داد و مدیریت کرد.
• کاهش زمان توسعه: با استفاده از گره‌های موجود و منطق Low-Code، می‌توان یک سیستم RAG را به مراتب سریع‌تر از توسعه آن از صفر با کدنویسی سنتی، راه‌اندازی کرد.
• انعطاف‌پذیری و ماژولار بودن: هر جزء از سیستم RAG می‌تواند به عنوان یک گره یا مجموعه‌ای از گره‌ها در n8n پیاده‌سازی شود، که امکان تغییر و بهینه‌سازی آسان هر بخش را فراهم می‌کند.
• مقیاس‌پذیری: Workflowهای n8n را می‌توان برای مدیریت حجم‌های مختلف داده و درخواست‌ها طراحی کرد.

در ادامه این راهنما، خواهیم دید که چگونه می‌توانیم از قابلیت‌های متنوع n8n برای ساخت هر یک از اجزای یک سیستم RAG پیشرفته استفاده کنیم.

اجزای کلیدی یک سیستم RAG در n8n

یک سیستم Retrieval Augmented Generation (RAG)، صرف نظر از پلتفرم پیاده‌سازی، از چندین جزء کلیدی تشکیل شده است که هر یک نقش مهمی در فرآیند بازیابی و تولید اطلاعات ایفا می‌کنند. در n8n، هر یک از این اجزا معمولاً توسط یک یا چند گره n8n یا از طریق فراخوانی APIهای خارجی مدیریت می‌شوند.

۱. منبع داده (Data Source)

اولین گام در هر سیستم RAG، تعریف و دسترسی به منبع دانش است. این منبع می‌تواند هر جایی باشد که اطلاعات معتبر شما در آن ذخیره شده است.

مثال‌ها:

• اسناد: فایل‌های PDF، DOCX، TXT، Markdown، صفحات HTML.
• پایگاه‌های داده: SQL databases (PostgreSQL, MySQL), NoSQL databases (MongoDB, Cassandra).
• APIها: سیستم‌های مدیریت دانش، CMSها، سیستم‌های پشتیبانی مشتری.
• ذخیره‌سازی ابری: Google Drive, Dropbox, Amazon S3.

در n8n، می‌توانید از گره‌هایی مانند `Read Binary File`، `Google Drive`، گره‌های پایگاه داده مانند `Postgres`, `MySQL`, `MongoDB`، یا `HTTP Request` برای فراخوانی APIهای سفارشی استفاده کنید تا داده‌ها را از این منابع بازیابی کنید.

۲. تقسیم‌بندی و تبدیل به بردارهای عددی (Chunking & Embedding)

این مرحله حیاتی، داده‌های خام را برای جستجوی معنایی آماده می‌کند.

• تقسیم‌بندی (Chunking): اسناد کامل، برای جستجوی موثرتر، به قطعات کوچک‌تر و مدیریت‌پذیر (chunks) تقسیم می‌شوند. اندازه و همپوشانی (overlap) این chunks اهمیت زیادی دارد. chunks نباید آنقدر کوچک باشند که بافت معنایی خود را از دست بدهند و نه آنقدر بزرگ که چندین موضوع نامرتبط را پوشش دهند.

  تکنیک‌ها: تقسیم بر اساس پاراگراف، جملات، کاراکترهای ثابت، یا تقسیم‌بندی بازگشتی (recursive splitting) که بافت را حفظ می‌کند.

• تبدیل به بردارهای عددی (Embedding): هر chunk متنی به یک بردار عددی (embedding) تبدیل می‌شود. این بردارها، نمایشی عددی از معنای chunk هستند. جملات یا عباراتی که معنای مشابهی دارند، بردارهای مشابهی در فضای برداری خواهند داشت (نزدیک‌تر به هم قرار می‌گیرند).

  مدل‌های Embedding: مدل‌های تخصصی هوش مصنوعی مانند OpenAI Embeddings (text-embedding-ada-002), Cohere Embed, یا مدل‌های متن‌باز از Hugging Face.

در n8n، می‌توانید از گره `Code` برای اجرای منطق chunking (در صورت نیاز به پیچیدگی بالا یا استفاده از کتابخانه‌های خاص) و از گره `HTTP Request` برای فراخوانی APIهای مدل‌های Embedding استفاده کنید.

۳. پایگاه داده برداری (Vector Database)

پس از تولید embeddingها، آن‌ها باید به گونه‌ای ذخیره و ایندکس شوند که امکان جستجوی سریع و کارآمد بر اساس شباهت معنایی فراهم شود. پایگاه داده برداری برای این منظور طراحی شده است.

کاربرد: ذخیره‌سازی embeddings همراه با متادیتای مرتبط و امکان انجام جستجوی “نزدیکترین همسایه” (Nearest Neighbor Search) برای یافتن chunks مشابه با query کاربر.

مثال‌ها: Pinecone, Weaviate, Qdrant, Milvus, ChromaDB, FAISS (برای استقرار محلی).

در n8n، تعامل با پایگاه داده برداری عمدتاً از طریق گره `HTTP Request` (برای فراخوانی APIهای RESTful پایگاه داده) انجام می‌شود. برای برخی از پایگاه‌های داده محبوب، ممکن است گره‌های اختصاصی n8n نیز وجود داشته باشد.

۴. مکانیسم بازیابی (Retrieval Mechanism)

این جزء مسئول دریافت query کاربر، تبدیل آن به embedding و سپس جستجو در پایگاه داده برداری برای یافتن مرتبط‌ترین chunks است.

فرآیند:

1. کاربر سوالی را مطرح می‌کند (query).
2. query کاربر توسط همان مدل embedding که برای chunking استفاده شد، به یک بردار عددی تبدیل می‌شود.
3. این بردار query برای جستجو در پایگاه داده برداری استفاده می‌شود تا k نزدیک‌ترین chunks (از نظر معنایی) به آن یافت شود.

در n8n، این شامل یک گره `HTTP Request` برای embedding query و سپس یک گره `HTTP Request` دیگر برای فراخوانی API جستجوی پایگاه داده برداری است.

۵. مدل زبانی بزرگ (Large Language Model – LLM)

هسته تولید پاسخ در سیستم RAG است.

کاربرد: دریافت query اصلی کاربر و chunks بازیابی شده به عنوان بافت، و سپس تولید یک پاسخ منسجم و اطلاعاتی بر اساس این داده‌ها.

مثال‌ها: OpenAI GPT-3.5/GPT-4, Anthropic Claude, Google Gemini, Llama 2, Mistral.

در n8n، می‌توان از گره `OpenAI` (اگر موجود باشد) یا گره `HTTP Request` برای فراخوانی APIهای چت یا تکمیل این مدل‌ها استفاده کرد.

۶. منطق ارکستراسیون (Orchestration Logic – n8n)

این مهمترین جزء در بستر n8n است که تمام اجزای فوق را به هم متصل می‌کند و جریان داده‌ها و کنترل را بین آن‌ها مدیریت می‌کند.

کاربرد:

• هماهنگی Pipeline ورود داده (ingestion): از استخراج داده تا ذخیره‌سازی در پایگاه داده برداری.
• هماهنگی Pipeline بازیابی و تولید: از دریافت query کاربر تا ارائه پاسخ نهایی.
• مدیریت خطا، لاگ‌برداری و تنظیم پارامترها.

n8n با رابط بصری و گره‌های متعدد خود، این امکان را فراهم می‌کند که این منطق پیچیده را به صورت شهودی طراحی و پیاده‌سازی کنید. هر مرحله از Workflow شما در n8n یک بخش از این منطق ارکستراسیون است.

با درک این اجزا، می‌توانیم به پیاده‌سازی گام به گام آن‌ها در n8n بپردازیم و یک سیستم RAG کاملاً کاربردی را توسعه دهیم.

گام اول: آماده‌سازی پایگاه دانش (Data Ingestion Pipeline در n8n)

اولین و شاید حیاتی‌ترین گام در ساخت یک سیستم RAG، آماده‌سازی پایگاه دانش است. این فرآیند شامل جمع‌آوری داده‌ها، پردازش آن‌ها، تبدیلشان به بردارهای عددی (embeddings) و ذخیره این embeddings در یک پایگاه داده برداری (Vector Database) است. در n8n، ما یک Workflow برای خودکارسازی این Pipeline ورود داده (Data Ingestion Pipeline) خواهیم ساخت.

مراحل Pipeline ورود داده:

1. جمع‌آوری داده (Data Acquisition): از کجا داده‌ها را دریافت می‌کنیم؟
2. استخراج و پاکسازی متن (Text Extraction & Cleaning): تبدیل داده‌های خام به متن قابل استفاده.
3. تقسیم‌بندی (Chunking): شکستن متن به قطعات کوچک‌تر.
4. تولید Embedding: تبدیل هر chunk به یک بردار عددی.
5. ذخیره در پایگاه داده برداری (Storing in Vector Database): ایندکس کردن chunks و embeddings.

پیاده‌سازی در n8n:

بیایید یک Workflow گام به گام برای این فرآیند در n8n ایجاد کنیم. فرض می‌کنیم می‌خواهیم اسناد PDF را از یک پوشه محلی یا فضای ابری خود خوانده و آن‌ها را به پایگاه دانش RAG خود اضافه کنیم.

۱. راه‌اندازی Workflow و جمع‌آوری داده (Trigger & Data Acquisition)

• گره Start:

  یک گره `Start` را به Workflow خود اضافه کنید. این گره می‌تواند یک `Manual Trigger` (برای اجرای دستی) یا یک `Schedule Trigger` (برای اجرای دوره‌ای) باشد، بسته به اینکه چگونه می‌خواهید داده‌ها را به‌روزرسانی کنید.

• گره Read Binary File (برای فایل‌های محلی) یا Google Drive (برای فایل‌های ابری):

  اگر داده‌های شما فایل‌های PDF محلی هستند، از گره `Read Binary File` استفاده کنید. مسیر پوشه حاوی PDFها را مشخص کنید. این گره فایل‌های باینری را به n8n وارد می‌کند.

  اگر فایل‌های PDF شما در Google Drive هستند، از گره `Google Drive` استفاده کنید. اکانت Google Drive خود را متصل کنید و گزینه “Download a file” یا “List files in folder” را انتخاب کنید. سپس فایل‌های مورد نظر را بر اساس نام یا ID انتخاب کرده و محتوای باینری آن‌ها را دریافت کنید.

  نکته: برای سادگی، در این مثال بر روی خواندن از یک منبع متمرکز می‌شویم، اما شما می‌توانید چندین گره جمع‌آوری داده را ترکیب کنید.

۲. استخراج و پاکسازی متن (Text Extraction & Cleaning)

فایل‌های PDF باید به متن ساده تبدیل شوند. این کار معمولاً نیاز به یک ابزار یا API خارجی دارد.

• گره HTTP Request (برای Text Extraction API):

  از یک گره `HTTP Request` برای ارسال فایل باینری PDF به یک سرویس استخراج متن استفاده کنید. سرویس‌هایی مانند Google Document AI، Apache Tika (که می‌توانید آن را به صورت محلی یا به عنوان یک سرویس REST اجرا کنید)، یا سایر APIهای OCR/PDF-to-text مناسب هستند.

  تنظیمات گره HTTP Request:

  • Method: POST
  • URL: آدرس API سرویس استخراج متن شما (مثلاً `http://localhost:9998/tika` برای Tika).
  • Headers: `Content-Type: application/octet-stream` (یا هر نوع دیگری که API شما نیاز دارد).
  • Body:

    <?=>{{ $('Read Binary File').item.binary.data }}

    این کد، خروجی باینری گره قبلی را به عنوان بدنه درخواست ارسال می‌کند.

  • Response: سرویس باید متن استخراج شده را در پاسخ برگرداند. مطمئن شوید که پاسخ را به درستی Parse می‌کنید (معمولاً JSON یا Plain Text).

  گره Set (برای پاکسازی اولیه):

  پس از دریافت متن، ممکن است نیاز به پاکسازی اولیه داشته باشید (حذف کاراکترهای اضافی، فاصله‌های خالی تکراری و غیره). از یک گره `Set` یا `Code` برای این کار استفاده کنید.

  مثال با گره Set:

  • Mode: Merge
  • Value: `{{ $(‘HTTP Request’).item.json.extractedText.replace(/\s+/g, ‘ ‘).trim() }}` (با فرض اینکه متن در `extractedText` از پاسخ HTTP قرار دارد).
  • Property Name: `cleanedText`

۳. تقسیم‌بندی (Chunking)

متن پاکسازی شده را به قطعات کوچک‌تر تقسیم می‌کنیم.

• گره Code (برای Chunking):

  تقسیم‌بندی متن یک فرآیند کلیدی است که بهتر است در یک گره `Code` انجام شود تا انعطاف‌پذیری بیشتری داشته باشیم. می‌توانید از یک کتابخانه JavaScript برای این کار استفاده کنید یا منطق ساده‌ای را پیاده‌سازی کنید.

  مثال کد جاوااسکریپت برای Recursive Character Text Splitter (ساده شده):

  const text = $item.get('json.cleanedText');
  const chunkSize = 1000; // تعداد کاراکتر در هر chunk
  const chunkOverlap = 200; // میزان همپوشانی بین chunks
  
  function splitText(text, chunkSize, chunkOverlap) {
      const chunks = [];
      let currentPosition = 0;
  
      while (currentPosition < text.length) {
          let endPosition = Math.min(currentPosition + chunkSize, text.length);
          let chunk = text.substring(currentPosition, endPosition);
          chunks.push(chunk);
  
          if (endPosition === text.length) {
              break;
          }
  
          currentPosition += (chunkSize - chunkOverlap);
          if (currentPosition >= text.length) { // Ensure no out of bounds
              currentPosition = text.length - 1; // Adjust to prevent infinite loop or errors
          }
      }
      return chunks;
  }
  
  const textChunks = splitText(text, chunkSize, chunkOverlap);
  
  // Output each chunk as a separate item
  return textChunks.map(chunk => ({
      json: {
          text: chunk,
          metadata: {
              source: $item.get('json.sourceFileName') || 'unknown',
              // می توانید متادیتای دیگری اضافه کنید
          }
      }
  }));

  نکته: برای chunking پیشرفته‌تر که بافت معنایی را بهتر حفظ کند (مانند استفاده از RecursiveCharacterTextSplitter از Langchain)، ممکن است نیاز به اجرای یک سرویس API خارجی یا استفاده از یک Runtime خاص برای n8n داشته باشید که از ماژول‌های npm پشتیبانی کند.

۴. تولید Embedding (Embedding Generation)

هر chunk متنی را به یک بردار عددی تبدیل می‌کنیم.

• گره HTTP Request (برای Embedding API – مثلاً OpenAI):

  یک گره `HTTP Request` برای فراخوانی API Embedding اضافه کنید (مثلاً OpenAI Embeddings). این گره باید برای هر chunk جداگانه اجرا شود، پس مطمئن شوید که بعد از گره `Code` (که خروجی چند آیتم می‌دهد) قرار گرفته است.

  تنظیمات گره HTTP Request (OpenAI Embeddings):

  • Method: POST
  • URL: `https://api.openai.com/v1/embeddings`
  • Headers:
    • `Content-Type: application/json`
    • `Authorization: Bearer YOUR_OPENAI_API_KEY` (کلید API خود را با یک Credential n8n مدیریت کنید).
  • Body (JSON):

    {
        "input": "{{ $item.json.text }}",
        "model": "text-embedding-ada-002"
    }

    این، متن chunk جاری را به عنوان ورودی برای تولید embedding ارسال می‌کند.

  • Response: پاسخ را به گونه‌ای تنظیم کنید که embedding تولید شده را در `json.data[0].embedding` ذخیره کند.
• گره Set (برای اضافه کردن Embedding به آیتم):

  یک گره `Set` بعد از گره `HTTP Request` اضافه کنید تا embedding تولید شده را به آیتم chunk فعلی اضافه کنید.

  تنظیمات گره Set:

  • Mode: Merge
  • Value: `{{ $(‘HTTP Request’).item.json.data[0].embedding }}`
  • Property Name: `embedding`

  اکنون هر آیتم شامل `text`, `metadata` و `embedding` آن chunk است.

۵. ذخیره در پایگاه داده برداری (Storing in Vector Database)

embeddings و chunks را در پایگاه داده برداری انتخابی خود ذخیره می‌کنیم. در اینجا، Pinecone را به عنوان مثال در نظر می‌گیریم.

• گره HTTP Request (برای Pinecone Upsert):

  یک گره `HTTP Request` دیگر برای فراخوانی API Pinecone upsert اضافه کنید.

  تنظیمات گره HTTP Request (Pinecone Upsert):

  • Method: POST
  • URL: `https://YOUR_INDEX_NAME-YOUR_PROJECT_ID.svc.YOUR_ENVIRONMENT.pinecone.io/vectors/upsert` (اطلاعات خود را جایگزین کنید).
  • Headers:
    • `Content-Type: application/json`
    • `Api-Key: YOUR_PINECONE_API_KEY` (با Credential مدیریت کنید).
  • Body (JSON):

    {
        "vectors": [
            {
                "id": "{{ $item.json.metadata.source }}-{{ $item.json.text.substring(0, 50) | slugify }}", // یک ID منحصر به فرد برای هر بردار
                "values": "{{ $item.json.embedding }}",
                "metadata": {
                    "text": "{{ $item.json.text }}",
                    "source": "{{ $item.json.metadata.source }}"
                }
            }
        ],
        "namespace": "my-rag-data" // (اختیاری) برای سازماندهی داده‌ها
    }

    نکته: برای تولید `id` منحصر به فرد و مدیریت مقادیر رشته‌ای، می‌توانید از توابع جاوااسکریپت داخلی n8n مانند `slugify` (اگر n8n شما از آن پشتیبانی می‌کند) یا `hash` استفاده کنید. اطمینان حاصل کنید که `id` در Pinecone یکتا است.

  • Response: برای تأیید عملیات `upsert`.

پس از اجرای این Workflow، پایگاه داده برداری شما با chunks و embeddings داده‌های شما پر خواهد شد. این Pipeline را می‌توانید هر زمان که نیاز به به‌روزرسانی یا اضافه کردن اطلاعات جدید به پایگاه دانش خود دارید، اجرا کنید.

این Workflow ورود داده، ستون فقرات سیستم RAG شما است و اطمینان می‌دهد که LLM شما به جدیدترین و مرتبط‌ترین اطلاعات دسترسی دارد.

گام دوم: ساخت جریان بازیابی و تولید (Retrieval & Generation Pipeline در n8n)

پس از آماده‌سازی پایگاه دانش در گام اول، اکنون زمان آن رسیده که Pipeline اصلی RAG را بسازیم: یعنی دریافت query از کاربر، بازیابی اطلاعات مرتبط و در نهایت تولید پاسخ توسط LLM. این Workflow، هسته تعامل با سیستم RAG شما خواهد بود.

مراحل Pipeline بازیابی و تولید:

1. ورودی Query کاربر (User Query Input): دریافت سوال از کاربر.
2. Embedding Query: تبدیل سوال کاربر به یک بردار عددی.
3. جستجوی معنایی در پایگاه داده برداری (Semantic Search in Vector Database): یافتن مرتبط‌ترین chunks.
4. مونتاژ بافت (Context Assembly): جمع‌آوری متن chunks بازیابی شده.
5. مهندسی پرامپت (Prompt Engineering): ساخت پرامپت برای LLM.
6. فراخوانی LLM (LLM Invocation): ارسال پرامپت به LLM و دریافت پاسخ.
7. مدیریت و ارائه پاسخ (Response Handling & Output): ارائه پاسخ نهایی به کاربر.

پیاده‌سازی در n8n:

یک Workflow جدید در n8n ایجاد کنید.

۱. ورودی Query کاربر (User Query Input)

• گره Webhook Trigger:

  رایج‌ترین راه برای دریافت ورودی کاربر در یک سیستم RAG، از طریق یک API یا Webhook است. یک گره `Webhook Trigger` را به Workflow خود اضافه کنید.

  تنظیمات Webhook Trigger:

  • HTTP Method: POST
  • Path: `/chat` (یا هر مسیر دلخواه دیگری).
  • Authentication: برای امنیت بیشتر می‌توانید احراز هویت را فعال کنید.

  این گره منتظر می‌ماند تا یک درخواست HTTP حاوی سوال کاربر (معمولاً در بدنه JSON) دریافت کند.

  مثال بدنه درخواست JSON ورودی:

  {
      "query": "آخرین تغییرات در سیاست بازگشت محصول چیست؟"
  }

۲. Embedding Query

query کاربر را به یک بردار عددی تبدیل می‌کنیم. بسیار مهم است که از همان مدل Embedding استفاده کنید که در Pipeline ورود داده استفاده کردید.

• گره HTTP Request (برای Embedding API – مثلاً OpenAI):

  یک گره `HTTP Request` اضافه کنید. این گره دقیقاً مشابه گره تولید Embedding در Pipeline ورود داده است.

  تنظیمات گره HTTP Request (OpenAI Embeddings):

  • Method: POST
  • URL: `https://api.openai.com/v1/embeddings`
  • Headers:
    • `Content-Type: application/json`
    • `Authorization: Bearer YOUR_OPENAI_API_KEY` (با Credential مدیریت شود).
  • Body (JSON):

    {
        "input": "{{ $('Webhook').item.json.query }}",
        "model": "text-embedding-ada-002"
    }

    اینجا، `{{ $(‘Webhook’).item.json.query }}` سوال کاربر را به عنوان ورودی ارسال می‌کند.

  • Response: مطمئن شوید که پاسخ را به درستی Parse می‌کنید تا embedding تولید شده را در `json.data[0].embedding` ذخیره کند.
• گره Set (برای ذخیره Embedding Query):

  یک گره `Set` اضافه کنید تا embedding query را در یک Property قابل دسترسی ذخیره کنید.

  تنظیمات گره Set:

  • Mode: Merge
  • Value: `{{ $(‘HTTP Request’).item.json.data[0].embedding }}`
  • Property Name: `queryEmbedding`

۳. جستجوی معنایی در پایگاه داده برداری (Semantic Search in Vector Database)

اکنون از `queryEmbedding` برای جستجو در پایگاه داده برداری (مثلاً Pinecone) استفاده می‌کنیم.

• گره HTTP Request (برای Pinecone Query):

  یک گره `HTTP Request` برای فراخوانی API Pinecone query اضافه کنید.

  تنظیمات گره HTTP Request (Pinecone Query):

  • Method: POST
  • URL: `https://YOUR_INDEX_NAME-YOUR_PROJECT_ID.svc.YOUR_ENVIRONMENT.pinecone.io/query`
  • Headers:
    • `Content-Type: application/json`
    • `Api-Key: YOUR_PINECONE_API_KEY`
  • Body (JSON):

    {
        "vector": {{ $('Set').item.json.queryEmbedding }},
        "topK": 5, // تعداد مرتبط‌ترین chunks برای بازیابی
        "includeMetadata": true, // برای دریافت متن اصلی chunks
        "namespace": "my-rag-data" // (اختیاری) اگر در Pipeline ورود داده استفاده کردید
    }

    این درخواست، 5 chunk مرتبط را همراه با متادیتای آن‌ها (شامل متن اصلی chunk) بازیابی می‌کند.

۴. مونتاژ بافت (Context Assembly)

متن‌های بازیابی شده از پایگاه داده برداری را برای ارسال به LLM جمع‌آوری می‌کنیم.

• گره Item Lists (برای استخراج chunks):

  گره `Item Lists` را اضافه کنید تا از خروجی Pinecone (که ممکن است یک آرایه از نتایج باشد)، تنها آیتم‌های `matches` را استخراج کنید.

  تنظیمات گره Item Lists:

  • Operation: Get All
  • Field: `json.matches`
• گره Set (برای ساخت رشته بافت):

  از گره `Set` برای ساخت یک رشته واحد حاوی تمام متن‌های بازیابی شده استفاده کنید. این رشته به عنوان بافت برای LLM عمل خواهد کرد.

  تنظیمات گره Set:

  • Mode: Merge
  • Value: `{{ $input.all().map(item => item.json.metadata.text).join(‘\n—\n’) }}`
  • Property Name: `retrievedContext`

  این کد تمام متن‌های `metadata.text` را از هر chunk بازیابی شده جمع‌آوری کرده و با خطوط `—` از هم جدا می‌کند.

۵. مهندسی پرامپت (Prompt Engineering)

پرامپت نهایی را برای LLM ایجاد می‌کنیم که شامل دستورالعمل‌ها، بافت بازیابی شده و سوال اصلی کاربر است.

• گره Set (برای ساخت Prompt):

  از گره `Set` برای ساخت پرامپت به فرمت `messages` (برای Chat Completions API) استفاده کنید.

  تنظیمات گره Set:

  • Mode: Merge
  • Value:

    [
        {
            "role": "system",
            "content": "شما یک دستیار هوش مصنوعی مفید هستید. به سوالات فقط با استفاده از اطلاعات ارائه شده در بافت زیر پاسخ دهید. اگر اطلاعات در بافت موجود نیست، به سادگی بگویید که نمی‌توانید پاسخ دهید. پاسخ‌های شما باید جامع و دقیق باشند."
        },
        {
            "role": "user",
            "content": "بافت اطلاعاتی:\n{{ $('Set1').item.json.retrievedContext }}\n\nسوال کاربر: {{ $('Webhook').item.json.query }}"
        }
    ]

    نکته: `Set1` نام گره `Set` است که `retrievedContext` را ایجاد کرد. حتماً آن را با نام واقعی گره خود جایگزین کنید.

  • Property Name: `llmPromptMessages`

۶. فراخوانی LLM (LLM Invocation)

پرامپت مهندسی شده را به LLM ارسال می‌کنیم (مثلاً OpenAI GPT-4).

• گره HTTP Request (برای OpenAI Chat Completions):

  یک گره `HTTP Request` برای فراخوانی API OpenAI Chat Completions اضافه کنید.

  تنظیمات گره HTTP Request (OpenAI Chat Completions):

  • Method: POST
  • URL: `https://api.openai.com/v1/chat/completions`
  • Headers:
    • `Content-Type: application/json`
    • `Authorization: Bearer YOUR_OPENAI_API_KEY`
  • Body (JSON):

    {
        "model": "gpt-4", // یا "gpt-3.5-turbo"
        "messages": {{ $('Set2').item.json.llmPromptMessages }}, // نام گره Set مهندسی پرامپت
        "temperature": 0.7 // میزان خلاقیت
    }

    اینجا، `Set2` نام گره `Set` است که `llmPromptMessages` را ایجاد کرد.

  • Response: پاسخ LLM در `json.choices[0].message.content` قرار دارد.

۷. مدیریت و ارائه پاسخ (Response Handling & Output)

پاسخ LLM را استخراج کرده و به کاربر برمی‌گردانیم.

• گره Respond to Webhook:

  یک گره `Respond to Webhook` را اضافه کنید تا پاسخ LLM را به درخواست‌کننده اصلی Webhook برگردانید.

  تنظیمات گره Respond to Webhook:

  • Response Type: JSON
  • Data:

    {
        "answer": "{{ $('HTTP Request1').item.json.choices[0].message.content }}"
    }

    اینجا، `HTTP Request1` نام گره `HTTP Request` است که LLM را فراخوانی کرد.

با تکمیل این Workflow، شما یک سیستم RAG کاملاً کاربردی در n8n ساخته‌اید که می‌تواند به سوالات کاربران با اتکا به پایگاه دانش اختصاصی شما پاسخ دهد. این Pipeline، قدرت LLMs را با واقعیت داده‌های شما ترکیب می‌کند و به شما امکان می‌دهد تا برنامه‌های کاربردی هوشمند و قابل اعتمادی را توسعه دهید.

بهینه‌سازی و نکات پیشرفته در RAG با n8n

ساخت یک Pipeline پایه RAG در n8n یک شروع عالی است، اما برای دستیابی به عملکرد بهینه، دقت بالاتر و مقیاس‌پذیری، باید به جزئیات و تکنیک‌های پیشرفته‌تر نیز توجه کرد. در ادامه به برخی از این نکات بهینه‌سازی و تکنیک‌ها می‌پردازیم:

۱. استراتژی‌های پیشرفته Chunking

نحوه تقسیم‌بندی اسناد به chunks تأثیر زیادی بر کیفیت بازیابی دارد.

• اندازه Chunk و Overlap بهینه:

  تست و اعتبارسنجی برای یافتن بهترین `chunk_size` و `chunk_overlap` برای نوع داده‌های شما ضروری است. chunks کوچک‌تر ممکن است بافت کافی نداشته باشند، در حالی که chunks بزرگ‌تر می‌توانند حاوی اطلاعات نامربوط باشند و نویز را افزایش دهند.

• Chunking معنایی (Semantic Chunking):

  به جای تقسیم‌بندی بر اساس تعداد کاراکتر ثابت، از تکنیک‌هایی استفاده کنید که متن را بر اساس معنای آن تقسیم می‌کنند (مثلاً هر پاراگراف یا هر بخش مرتبط از متن). این کار می‌تواند با استفاده از Sentence Transformers برای یافتن نقاط تغییر معنایی انجام شود.

• Chunking مبتنی بر متا-دیتا (Metadata-aware Chunking):

  اطلاعات مهم مانند عنوان بخش، نام سند، تاریخ و غیره را به عنوان متا-دیتا به هر chunk اضافه کنید. این متا-دیتا را می‌توان در هنگام جستجو برای فیلتر کردن نتایج استفاده کرد.

  پیاده‌سازی در n8n: گره `Code` در Pipeline ورود داده برای پیاده‌سازی منطق پیچیده chunking و افزودن متا-دیتا ایده‌آل است. برای chunking معنایی ممکن است نیاز به فراخوانی یک سرویس جانبی که این قابلیت را ارائه می‌دهد (مثلاً با استفاده از یک مدل Sentence Transformer) از طریق گره `HTTP Request` داشته باشید.

۲. انتخاب و تنظیم مدل Embedding

کیفیت embeddings مستقیماً بر دقت جستجوی معنایی تأثیر می‌گذارد.

• انتخاب مدل مناسب:

  مدل‌های مختلف embedding دارای عملکرد متفاوتی برای زبان‌ها و دامنه‌های مختلف هستند. OpenAI’s `text-embedding-ada-002` یک انتخاب عمومی و قدرتمند است، اما مدل‌های دیگر مانند Cohere Embed یا مدل‌های متن‌باز از Hugging Face (مانند `all-MiniLM-L6-v2` برای زبان انگلیسی) نیز وجود دارند.

• Embedding مدل‌های چندزبانه:

  اگر با چندین زبان سروکار دارید، از مدل‌های embedding چندزبانه استفاده کنید.

• به‌روزرسانی مدل:

  مدل‌های embedding دائماً در حال بهبود هستند. Pipeline ورود داده خود را طوری طراحی کنید که در صورت نیاز به استفاده از مدل‌های جدید، بتوانید به راحتی embeddings موجود را بازسازی کنید.

  پیاده‌سازی در n8n: تغییر URL و بدنه درخواست گره `HTTP Request` برای فراخوانی مدل‌های مختلف embedding بسیار آسان است. برای مدل‌های محلی، می‌توانید یک API کوچک را با استفاده از Hugging Face Text Embeddings Inference راه‌اندازی کرده و n8n را به آن متصل کنید.

۳. بهینه‌سازی پایگاه داده برداری

نحوه تنظیم و استفاده از پایگاه داده برداری می‌تواند بر سرعت و دقت بازیابی تأثیر بگذارد.

• ایندکس‌گذاری (Indexing):

  بررسی کنید که آیا پایگاه داده برداری شما از انواع ایندکس‌گذاری خاصی برای جستجوی سریعتر (مانند HNSW) پشتیبانی می‌کند و آن‌ها را به درستی پیکربندی کنید.

• فیلترینگ متا-دیتا (Metadata Filtering):

  از قابلیت‌های فیلترینگ پایگاه داده برداری خود استفاده کنید. به عنوان مثال، اگر کاربر سوالی در مورد “سیاست بازگشت محصول پس از تاریخ مشخص” می‌پرسد، می‌توانید ابتدا نتایج را بر اساس تاریخ فیلتر کنید و سپس جستجوی معنایی انجام دهید. این کار دقت بازیابی را به شدت افزایش می‌دهد.

  پیاده‌سازی در n8n: در گره `HTTP Request` برای Pinecone query، می‌توانید پارامتر `filter` را در بدنه درخواست JSON اضافه کنید تا بر اساس متا-دیتای chunks فیلتر کنید. این متا-دیتا باید در Pipeline ورود داده به درستی ذخیره شده باشد.

• انتخاب معیار فاصله (Distance Metric):

  برخی پایگاه‌های داده برداری از معیارهای فاصله مختلف (مانند Cosine Similarity، Euclidean Distance) پشتیبانی می‌کنند. مدل embedding شما معمولاً معیار مناسب را پیشنهاد می‌دهد.

۴. Reranking (بازرتبه‌بندی)

پس از بازیابی اولیه چند chunk برتر، می‌توان از یک مدل دیگر (معمولاً کوچکتر و سریعتر) برای “بازرتبه‌بندی” این chunks استفاده کرد تا مرتبط‌ترین آن‌ها را در بالای لیست قرار دهد.

• کاربرد: بهبود دقت بازیابی، به خصوص زمانی که جستجوی اولیه چندین chunk با شباهت معنایی بالا را برمی‌گرداند.
• ابزارها: مدل‌های Cohere Rerank یا مدل‌های متن‌باز اختصاصی برای reranking.

پیاده‌سازی در n8n: پس از دریافت نتایج اولیه از پایگاه داده برداری، از یک گره `HTTP Request` دیگر برای ارسال chunks بازیابی شده به یک API reranking استفاده کنید. سپس با استفاده از گره‌های `Sort` یا `Code`، chunks را بر اساس امتیاز rerank مجدداً مرتب کنید و تنها chunks با بالاترین امتیاز را برای LLM ارسال کنید.

۵. مهندسی پرامپت پیشرفته

کیفیت پرامپت ارسالی به LLM حیاتی است.

• دستورالعمل‌های واضح (Clear Instructions):

  مطمئن شوید که دستورالعمل‌های شما برای LLM در پرامپت سیستم (system prompt) بسیار واضح هستند: “فقط از بافت ارائه شده استفاده کن”، “اگر نمی‌دانی بگو نمی‌دانم”، “پاسخ را مختصر و مفید نگه دار” و غیره.

• مثال‌های چند شاتی (Few-Shot Examples):

  در پرامپت خود، چند مثال از سوال و پاسخ ایده‌آل (شامل بافت و پاسخ مطلوب) ارائه دهید تا LLM نحوه پاسخگویی را بهتر یاد بگیرد. این کار به LLM کمک می‌کند تا سبک، لحن و فرمت پاسخگویی مورد نظر شما را درک کند.

• تگ‌گذاری (Tagging):

  برای مشخص کردن بافت و سوال کاربر از تگ‌های XML یا Markdown استفاده کنید (مثلاً `<context> … </context>`). این کار به LLM کمک می‌کند تا بخش‌های مختلف پرامپت را بهتر از هم تفکیک کند.

  پیاده‌سازی در n8n: گره `Set` و `Code` در Pipeline بازیابی و تولید، ابزارهای اصلی برای ساخت و فرمت‌بندی پرامپت‌های پیچیده هستند.

۶. کش‌گذاری (Caching)

برای بهبود عملکرد و کاهش هزینه‌ها، عملیات‌های تکراری را کش کنید.

• کش کردن Embeddings:

  اگر چندین بار یک متن را embedding می‌کنید (مثلاً در سناریوهای به‌روزرسانی داده‌ها)، نتایج embedding را کش کنید تا از فراخوانی مکرر API جلوگیری شود.

• کش کردن پاسخ‌های LLM:

  برای queryهای پرتکرار، می‌توانید پاسخ LLM را کش کنید. اگر query یکسان است و بافت بازیابی شده نیز تغییر نکرده، می‌توان پاسخ کش شده را برگرداند.

  پیاده‌سازی در n8n: می‌توانید از یک پایگاه داده (مانند Redis یا یک پایگاه داده SQL) یا حتی یک فایل JSON ساده (برای موارد ساده) که از طریق گره `HTTP Request` یا گره‌های پایگاه داده n8n قابل دسترسی است، به عنوان یک لایه کش استفاده کنید. منطق کش را با گره `IF` و `Code` مدیریت کنید.

۷. مدیریت خطا و پایداری

سیستم‌های RAG می‌توانند پیچیده باشند و مستعد خطا. باید برای آن آماده باشید.

• مدیریت خطا (Error Handling):

  از قابلیت‌های مدیریت خطای n8n (مسیرهای Error Handling) برای گرفتن استثناها در فراخوانی APIها (مانند خطاهای شبکه، Rate Limitها) و ارائه پاسخ‌های دوستانه به کاربر یا اجرای منطق بازیابی (retry logic) استفاده کنید.

• تلاش مجدد (Retries):

  برای فراخوانی‌های API به سرویس‌های خارجی (LLM، Embedding، Vector DB) که ممکن است به دلیل مشکلات موقت شبکه یا Rate Limitها با شکست مواجه شوند، منطق تلاش مجدد را با تأخیر تصاعدی (exponential backoff) پیاده‌سازی کنید.

  پیاده‌سازی در n8n: n8n گره‌های داخلی برای `Error Trigger` و `Retry` در گره‌های `HTTP Request` دارد که می‌توانید از آن‌ها استفاده کنید.

۸. قابلیت مشاهده و مانیتورینگ (Observability & Monitoring)

برای درک عملکرد سیستم و عیب‌یابی مشکلات، نیاز به مانیتورینگ دارید.

• لاگ‌برداری (Logging):

  مراحل کلیدی Workflow (مانند دریافت query، chunks بازیابی شده، پرامپت نهایی، پاسخ LLM) را ثبت کنید. این کار به شما کمک می‌کند تا در صورت بروز مشکل، مسیر را ردیابی کنید.

• مانیتورینگ عملکرد:

  زمان پاسخگویی کل سیستم، زمان هر مرحله (Embedding، Search، LLM) و تعداد درخواست‌های موفق/ناموفق را مانیتور کنید.

  پیاده‌سازی در n8n: می‌توانید از گره `Log` n8n یا گره `HTTP Request` برای ارسال لاگ‌ها به یک سیستم لاگ‌برداری متمرکز (مانند ELK Stack, Splunk, DataDog) استفاده کنید.

۹. جستجوی هیبریدی (Hybrid Search)

ترکیب جستجوی معنایی (با embeddings) با جستجوی مبتنی بر کلمات کلیدی (مانند BM25) می‌تواند نتایج بازیابی را به میزان قابل توجهی بهبود بخشد، به خصوص برای queryهایی که هم شامل کلمات کلیدی خاص هستند و هم نیاز به درک معنایی دارند.

• پیاده‌سازی: ابتدا جستجوی کلمات کلیدی را در پایگاه داده‌ای مانند Elasticsearch یا با استفاده از قابلیت‌های جستجوی متنی پایگاه داده برداری (اگر پشتیبانی می‌کند) انجام دهید. سپس نتایج را با نتایج جستجوی معنایی ترکیب کنید و قبل از ارسال به LLM، یک reranking انجام دهید.

پیاده‌سازی در n8n: می‌توانید یک گره `HTTP Request` اضافی برای فراخوانی API جستجوی کلمات کلیدی (مثلاً Elasticsearch) اضافه کنید. سپس نتایج هر دو جستجو را با `Merge` یا `Code` ترکیب کرده و برای reranking یا ساخت بافت استفاده کنید.

با به‌کارگیری این نکات پیشرفته، می‌توانید سیستم RAG خود را در n8n از یک نمونه اولیه کارآمد به یک راه‌حل پایدار، دقیق و مقیاس‌پذیر ارتقا دهید.

مطالعه موردی: ساخت یک ربات پشتیبانی مشتری دانش‌بنیان با n8n و RAG

برای درک بهتر کاربرد عملی Retrieval Augmented Generation در n8n، بیایید یک مطالعه موردی رایج را بررسی کنیم: ساخت یک ربات پشتیبانی مشتری (Customer Support Bot) که قادر است به سوالات کاربران بر اساس مستندات محصول و پایگاه داده دانش شرکت پاسخ دهد.

سناریو:

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

چالش‌ها بدون RAG:

• پاسخ‌های نادرست: LLMs سنتی ممکن است به دلیل عدم دسترسی به مستندات اختصاصی، پاسخ‌های نادرست یا توهم‌گونه ارائه دهند.
• اطلاعات منسوخ: تغییرات در محصولات یا سیاست‌ها به سرعت رخ می‌دهند و LLM بدون بازآموزی نمی‌تواند به اطلاعات به‌روز دسترسی داشته باشد.
• عدم قابلیت توجیه: نمی‌توان منبع پاسخ LLM را به کاربر نشان داد، که اعتماد را کاهش می‌دهد.

راه حل با n8n و RAG:

ما یک سیستم RAG خواهیم ساخت که مستندات شرکت را به عنوان پایگاه دانش استفاده می‌کند. این سیستم شامل دو Workflow اصلی در n8n خواهد بود:

1. Workflow ورود داده (Ingestion Workflow): برای پردازش و ذخیره مستندات.
2. Workflow بازیابی و تولید (Query & Generation Workflow): برای پاسخگویی به سوالات کاربران.

۱. Workflow ورود داده (Ingestion Workflow) در n8n

هدف: جمع‌آوری مستندات محصول (مثلاً فایل‌های PDF و DOCX)، تبدیل آن‌ها به chunks، تولید embeddings و ذخیره در Pinecone.

• گره Start (Manual Trigger): برای اجرای دستی این Workflow هر زمان که مستندات جدیدی اضافه یا به‌روزرسانی می‌شوند.
• گره Read Binary File / Google Drive Node:

  برای خواندن فایل‌های PDF و DOCX از یک پوشه مشخص در سرور n8n یا از Google Drive شرکت.

• گره HTTP Request (به Text Extraction API / Apache Tika):

  ارسال فایل‌های باینری به یک سرویس خارجی (مانند یک سرور Dockerized Apache Tika) برای استخراج متن از PDF/DOCX.

• گره Code (Chunking):

  دریافت متن استخراج شده و تقسیم آن به chunks با اندازه مثلاً 500 کاراکتر و همپوشانی 100 کاراکتر. اضافه کردن متادیتای مهم مانند `file_name`، `section_title` (در صورت امکان استخراج) و `source_url` (اگر از وبسایت استخراج شده باشد).

  مثال:

  const text = $item.get('json.extractedText');
  const fileName = $item.get('json.fileName'); // از گره قبلی
  // ... منطق chunking ...
  return textChunks.map(chunk => ({
      json: {
          text: chunk,
          embedding: [], // Placeholder
          metadata: {
              source: fileName,
              doc_type: 'product_manual',
              timestamp: new Date().toISOString()
          }
      }
  }));

• گره HTTP Request (به OpenAI Embeddings API):

  ارسال هر chunk متنی به OpenAI برای دریافت بردار embedding آن. (استفاده از مدل `text-embedding-ada-002`).

• گره HTTP Request (به Pinecone Upsert API):

  ذخیره هر chunk، embedding آن، و متادیتای مربوطه در ایندکس Pinecone. استفاده از `id` منحصر به فرد (مثلاً ترکیبی از نام فایل و هش chunk) و تنظیم `namespace` برای سازماندهی بهتر (مثلاً `product_docs`).

این Workflow تضمین می‌کند که پایگاه دانش ربات همیشه به‌روز و جامع است.

۲. Workflow بازیابی و تولید (Query & Generation Workflow) در n8n

هدف: دریافت سوال از مشتری، بازیابی اطلاعات مرتبط از پایگاه دانش Pinecone و تولید پاسخ با LLM.

• گره Webhook Trigger:

  به عنوان نقطه ورودی برای سوالات مشتریان، که از طریق یک رابط کاربری چت (مانند وب‌چت، Slack یا Microsoft Teams) فراخوانی می‌شود. این گره JSON حاوی `user_query` را دریافت می‌کند.

• گره HTTP Request (به OpenAI Embeddings API):

  تبدیل `user_query` به یک بردار embedding با استفاده از همان مدل (`text-embedding-ada-002`) که برای ورود داده استفاده شد.

• گره HTTP Request (به Pinecone Query API):

  استفاده از embedding query برای جستجو در ایندکس Pinecone و بازیابی 3 تا 5 chunk برتر (با `topK=5`) که بیشترین شباهت معنایی را به سوال کاربر دارند. اطمینان از `includeMetadata=true` برای دریافت متن اصلی chunks.

  بهینه‌سازی: در این مرحله، می‌توان فیلترهای متا-دیتا را نیز اعمال کرد. به عنوان مثال، اگر کاربر در مورد محصول X سوال می‌پرسد، می‌توان نتایج را به chunks مربوط به `product_X` فیلتر کرد تا دقت افزایش یابد.

• گره Set (Context Assembly):

  استخراج متن `metadata.text` از chunks بازیابی شده و ترکیب آن‌ها در یک رشته واحد با جداکننده.

• گره Set (Prompt Engineering):

  ساخت یک پرامپت دقیق برای LLM:

  System: "شما یک دستیار هوش مصنوعی برای پشتیبانی مشتریان شرکت هستید. با استفاده از اطلاعات ارائه شده در بافت، به سوال کاربر پاسخ دهید. همیشه منابع (نام فایل یا URL) را در انتهای پاسخ خود ذکر کنید. اگر اطلاعات کافی در بافت نیست، به طور محترمانه بگویید که نمی‌توانید پاسخ دهید."
  
  User: "بافت اطلاعات:\n{{ retrievedContext }}\n\nسوال: {{ user_query }}"

• گره HTTP Request (به OpenAI Chat Completions API):

  ارسال پرامپت به GPT-4 برای تولید پاسخ. تنظیم `temperature` به یک مقدار پایین (مثلاً 0.2) برای اطمینان از پاسخ‌های کمتر خلاقانه و مبتنی بر واقعیت.

• گره Respond to Webhook:

  استخراج پاسخ LLM و ارسال آن به همراه منابع (از متا-دیتای chunks) به کاربر از طریق Webhook.

  مثال پاسخ:

  {
      "answer": "برای بازگرداندن محصول، باید ظرف 30 روز از تاریخ خرید اقدام کنید. محصول باید در بسته‌بندی اصلی و بدون آسیب‌دیدگی باشد. لطفا برای جزئیات بیشتر به بخش 4.2 'سیاست بازگشت کالا' در 'راهنمای کاربری محصول X.pdf' مراجعه کنید.",
      "sources": ["راهنمای کاربری محصول X.pdf", "سیاست‌های شرکت 2023.docx"]
  }

نتایج و مزایا:

• پاسخ‌های دقیق و مرتبط: ربات به جای “حدس زدن”، از مستندات واقعی شرکت برای پاسخگویی استفاده می‌کند.
• دسترسی به اطلاعات به‌روز: با به‌روزرسانی آسان Workflow ورود داده، دانش ربات همیشه به‌روز می‌ماند.
• افزایش اعتماد مشتری: با ارائه منابع برای هر پاسخ، مشتریان می‌توانند پاسخ‌ها را تأیید کنند و اعتماد بیشتری به ربات پیدا می‌کنند.
• کاهش بار کاری تیم پشتیبانی: ربات به سوالات متداول پاسخ می‌دهد و به تیم پشتیبانی اجازه می‌دهد تا بر روی مسائل پیچیده‌تر تمرکز کنند.
• کاهش هزینه‌ها: نیاز به توسعه و نگهداری یک LLM سفارشی‌سازی شده از بین می‌رود.

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

نتیجه‌گیری

در این راهنمای جامع، ما به تفصیل فرآیند پیاده‌سازی Retrieval Augmented Generation (RAG) در n8n را بررسی کردیم. از آشنایی با مفهوم RAG و اهمیت آن در رفع محدودیت‌های مدل‌های زبانی بزرگ، تا ساخت گام به گام دو Workflow حیاتی در n8n (Pipeline ورود داده و Pipeline بازیابی و تولید)، نشان دادیم که چگونه می‌توان یک سیستم هوشمند و دانش‌محور را با استفاده از این ابزار Low-Code ارکستراسیون کرد.

دریافتیم که n8n با قابلیت‌های گسترده خود در اتصال به سرویس‌های مختلف (مانند OpenAI، Pinecone و سرویس‌های استخراج متن)، امکان دستکاری داده‌ها با گره‌های `Set` و `Code`، و رابط کاربری بصری، بستری بی‌نظیر برای طراحی و اجرای Workflowهای پیچیده RAG فراهم می‌کند. این رویکرد نه تنها زمان توسعه را به شدت کاهش می‌دهد، بلکه انعطاف‌پذیری و مقیاس‌پذیری بالایی را نیز ارائه می‌دهد.

همچنین، با بررسی نکات بهینه‌سازی و تکنیک‌های پیشرفته، مانند استراتژی‌های پیشرفته chunking، انتخاب مدل embedding، بهینه‌سازی پایگاه داده برداری، reranking و مهندسی پرامپت، بر اهمیت تنظیم دقیق هر جزء برای دستیابی به حداکثر دقت و کارایی تأکید کردیم. مطالعه موردی ساخت ربات پشتیبانی مشتری نیز به وضوح نشان داد که چگونه RAG با n8n می‌تواند به طور عملی مشکلات کسب‌وکارها را حل کرده و ارزش‌آفرینی کند.

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