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

اما اگر تصمیم بگیرید یک Chatbot اختصاصی برای کسب‌وکار یا محصول خود توسعه دهید، معمولاً با پرسش‌های متعددی روبه‌رو خواهید شد:

• معماری یک Chatbot مدرن چگونه است؟
• Backend و Frontend چگونه با یکدیگر ارتباط برقرار می‌کنند؟
• پیام‌های کاربران در کجا ذخیره می‌شوند؟
• چگونه پاسخ‌ها را به‌صورت لحظه‌ای (Streaming) نمایش دهیم؟
• چگونه بین مدل‌های مختلف هوش مصنوعی جابه‌جا شویم؟
• چگونه هزینه‌ها را کنترل کنیم؟
• چگونه Chatbot را برای هزاران کاربر آماده کنیم؟

در این مقاله، یک Chatbot واقعی را از ابتدا طراحی و پیاده‌سازی می‌کنیم. هدف فقط نمایش چند قطعه کد نیست؛ بلکه می‌خواهیم با معماری صحیح، بهترین روش‌های توسعه و نکات مربوط به استقرار در محیط Production آشنا شویم.

برای تولید پاسخ‌های هوش مصنوعی از API درواره استفاده می‌کنیم؛ یک API سازگار با استاندارد OpenAI که امکان دسترسی به طیف گسترده‌ای از مدل‌های هوش مصنوعی را تنها با یک کلید API فراهم می‌کند. این موضوع باعث می‌شود بدون وابستگی به یک ارائه‌دهندۀ خاص، بتوانید مدل مناسب هر پروژه را انتخاب کرده و در آینده نیز به‌سادگی آن را تغییر دهید.

در پایان این آموزش خواهید توانست:

• معماری یک Chatbot مدرن را طراحی کنید.
• Backend و Frontend یک Chatbot را پیاده‌سازی کنید.
• پاسخ‌ها را به‌صورت Streaming نمایش دهید.
• تاریخچۀ گفتگو را مدیریت کنید.
• Chatbot را به API درواره متصل کنید.
• پروژه را برای استفاده در محیط Production آماده کنید.

Chatbot چیست؟

Chatbot یا چت‌بات، نرم‌افزاری است که از طریق رابط گفتگو با کاربران تعامل می‌کند. در نسل‌های قدیمی، Chatbotها بر اساس قوانین ثابت (Rule-Based) عمل می‌کردند و تنها در صورتی پاسخ مناسب ارائه می‌دادند که ورودی کاربر با الگوهای از پیش تعریف‌شده مطابقت داشت.

برای مثال، اگر کاربر می‌نوشت:

ساعت کاری شرکت چیست؟

Chatbot با جستجو در مجموعه‌ای از قوانین، پاسخ مناسب را نمایش می‌داد.

اما اگر کاربر سؤال را به شکل دیگری مطرح می‌کرد، ممکن بود هیچ پاسخی دریافت نکند.

ظهور مدل‌های زبانی بزرگ (LLM) این وضعیت را تغییر داد.

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

به همین دلیل، Chatbotهای مدرن دیگر صرفاً یک «پنجرۀ گفتگو» نیستند؛ بلکه بخشی از منطق اصلی بسیاری از محصولات نرم‌افزاری محسوب می‌شوند.

Chatbot چگونه کار می‌کند؟

در ظاهر، استفاده از یک Chatbot بسیار ساده به نظر می‌رسد. کاربر پیام خود را وارد می‌کند و چند لحظه بعد پاسخ را دریافت می‌کند.

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

فرایند کلی به این صورت است:

۱. کاربر پیام خود را ارسال می‌کند.

۲. Frontend پیام را به Backend منتقل می‌کند.

۳. Backend درخواست را اعتبارسنجی می‌کند.

۴. تاریخچۀ گفتگو بازیابی می‌شود.

۵. درخواست به مدل هوش مصنوعی ارسال می‌شود.

۶. مدل پاسخ را تولید می‌کند.

۷. پاسخ در پایگاه داده ذخیره می‌شود.

۸. پاسخ برای کاربر نمایش داده می‌شود.

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

Chatbot و AI Agent چه تفاوتی دارند؟

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

یک Chatbot معمولاً بر گفتگو تمرکز دارد، در حالی که AI Agent علاوه بر گفتگو، قادر است وظایف مختلفی را به‌صورت خودکار انجام دهد.

اگر هنوز با مفهوم Agent آشنا نیستید، پیشنهاد می‌کنیم مقالۀ «آموزش ساخت AI Agent با OpenAI Agents SDK و API درواره» را نیز مطالعه کنید.

معماری یک Chatbot مدرن

یکی از مهم‌ترین عوامل موفقیت یک Chatbot، معماری صحیح آن است.

برخلاف نمونه‌های ساده که مستقیماً از مرورگر به مدل هوش مصنوعی متصل می‌شوند، در یک معماری استاندارد همیشه یک لایۀ Backend بین کاربر و مدل قرار می‌گیرد.

این Backend مسئول انجام وظایفی مانند احراز هویت، ثبت تاریخچۀ گفتگو، مدیریت هزینه‌ها، اعتبارسنجی درخواست‌ها و ارتباط با مدل هوش مصنوعی است.

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

             کاربر
                │
                ▼
        رابط کاربری (Frontend)
                │
                ▼
         Backend Application
                │
      ┌─────────┴─────────┐
      ▼                   ▼
 پایگاه داده         API درواره
      │                   │
      └─────────┬─────────┘
                ▼
          پاسخ به کاربر

این معماری چند مزیت مهم دارد:

• کلید API هرگز در مرورگر قرار نمی‌گیرد.
• امکان مدیریت کاربران و احراز هویت فراهم می‌شود.
• تاریخچۀ گفتگو قابل ذخیره و بازیابی است.
• می‌توان درخواست‌ها را ثبت و تحلیل کرد.
• در آینده امکان اضافه کردن قابلیت‌هایی مانند RAG یا AI Agent نیز وجود خواهد داشت.

اجزای اصلی یک Chatbot مدرن

اکنون که با معماری کلی Chatbot آشنا شدیم، بهتر است هر یک از اجزای این معماری را با جزئیات بیشتری بررسی کنیم.

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

اگر این بخش‌ها از ابتدا به‌درستی طراحی شوند، توسعه، نگهداری و مقیاس‌پذیری پروژه در آینده بسیار ساده‌تر خواهد بود.

رابط کاربری (Frontend)

Frontend همان بخشی است که کاربر با آن تعامل می‌کند.

وظیفۀ Frontend فقط نمایش پیام‌ها نیست، بلکه باید تجربۀ کاربری مناسبی نیز ایجاد کند.

یک رابط کاربری استاندارد معمولاً قابلیت‌های زیر را دارد:

• نمایش تاریخچۀ گفتگو
• ارسال پیام
• نمایش پاسخ به‌صورت Streaming
• نمایش وضعیت در حال تایپ مدل
• مدیریت چند گفتگو
• امکان توقف تولید پاسخ
• کپی کردن پاسخ‌ها
• نمایش کدها با قالب‌بندی مناسب
• پشتیبانی از Markdown

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

Backend

Backend مهم‌ترین بخش یک Chatbot است.

تمام منطق اصلی سیستم در این بخش قرار دارد.

Backend معمولاً مسئول انجام وظایف زیر است:

• احراز هویت کاربران
• اعتبارسنجی درخواست‌ها
• مدیریت تاریخچۀ گفتگو
• ارتباط با API درواره
• ثبت لاگ
• مدیریت هزینه‌ها
• اعمال Rate Limit
• ذخیرۀ پیام‌ها
• مدیریت خطاها

به همین دلیل، هرگز نباید مرورگر مستقیماً با مدل هوش مصنوعی ارتباط برقرار کند.

مدل هوش مصنوعی

مدل زبانی مسئول تولید پاسخ است.

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

امروزه ممکن است برای سناریوهای مختلف از مدل‌های متفاوتی استفاده کنید.

برای مثال:

• پاسخ به پرسش‌های متداول
• تولید کد
• خلاصه‌سازی متن
• تحلیل اسناد
• تولید محتوا
• استدلال چندمرحله‌ای

هرکدام از این سناریوها ممکن است به مدل متفاوتی نیاز داشته باشند.

به همین دلیل بهتر است معماری Chatbot به‌گونه‌ای طراحی شود که تغییر مدل بدون تغییر سایر بخش‌های برنامه امکان‌پذیر باشد.

API درواره

در این آموزش، Backend به‌جای اتصال مستقیم به یک ارائه‌دهندۀ خاص، از API درواره استفاده می‌کند.

این رویکرد چند مزیت مهم دارد:

• یک API برای دسترسی به مدل‌های مختلف
• سازگاری با استاندارد OpenAI
• مدیریت ساده‌تر کلیدهای دسترسی
• امکان تغییر مدل بدون بازنویسی کد
• مناسب برای پروژه‌های آزمایشی و Production

به این ترتیب، اگر در آینده بخواهید مدل دیگری را آزمایش کنید، معمولاً کافی است نام مدل را تغییر دهید و نیازی به تغییر معماری برنامه نخواهید داشت.

پایگاه داده

یکی از تفاوت‌های اصلی بین یک Chatbot آزمایشی و یک محصول واقعی، استفاده از پایگاه داده است.

حداقل اطلاعاتی که معمولاً ذخیره می‌شوند عبارت‌اند از:

• کاربران
• گفتگوها
• پیام‌های کاربر
• پاسخ‌های مدل
• مدل استفاده‌شده
• زمان ارسال پیام
• تعداد توکن‌های مصرف‌شده

این اطلاعات برای بازیابی تاریخچه، تحلیل رفتار کاربران و مدیریت هزینه‌ها ضروری هستند.

Streaming

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

این قابلیت را Streaming می‌نامند.

در این روش، کاربر لازم نیست تا پایان تولید پاسخ منتظر بماند.

به‌محض اینکه مدل اولین بخش از پاسخ را تولید می‌کند، همان قسمت در رابط کاربری نمایش داده می‌شود.

مزایای Streaming عبارت‌اند از:

• کاهش زمان انتظار کاربر
• بهبود تجربۀ کاربری
• طبیعی‌تر شدن مکالمه
• امکان توقف تولید پاسخ توسط کاربر

در بخش‌های بعدی، نحوۀ پیاده‌سازی Streaming را نیز بررسی خواهیم کرد.

انتخاب فناوری مناسب

برای ساخت Chatbot می‌توان از فناوری‌های مختلفی استفاده کرد.

در این مقاله از معماری زیر استفاده می‌کنیم:

البته این تنها یکی از گزینه‌های ممکن است و می‌توانید متناسب با نیاز پروژه، فناوری‌های دیگری نیز انتخاب کنید.

چرا Backend باید از Frontend جدا باشد؟

برخی توسعه‌دهندگان در پروژه‌های کوچک وسوسه می‌شوند که درخواست‌ها را مستقیماً از مرورگر به مدل هوش مصنوعی ارسال کنند.

اگرچه این روش در ظاهر ساده‌تر است، اما مشکلات متعددی ایجاد می‌کند:

• کلید API در مرورگر قرار می‌گیرد.
• امکان سوءاستفاده از API وجود دارد.
• کنترل هزینه‌ها دشوار می‌شود.
• احراز هویت کاربران به‌درستی انجام نمی‌شود.
• امکان ثبت لاگ و مانیتورینگ محدود خواهد بود.

به همین دلیل، در پروژه‌های واقعی همیشه Backend نقش واسط بین Frontend و مدل هوش مصنوعی را بر عهده دارد.

طراحی پایگاه داده

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

در ساده‌ترین حالت، چهار جدول کافی است.

کاربران (Users)

اطلاعات کاربران سیستم.

گفتگوها (Conversations)

هر کاربر می‌تواند چندین گفت‌وگو داشته باشد.

پیام‌ها (Messages)

تمام پیام‌های کاربر و پاسخ‌های مدل در این جدول ذخیره می‌شوند.

آمار مصرف (Usage)

برای ثبت اطلاعاتی مانند:

• تعداد درخواست‌ها
• تعداد توکن‌ها
• مدل استفاده‌شده
• زمان پاسخ

این اطلاعات در آینده برای تحلیل هزینه‌ها و بهینه‌سازی عملکرد بسیار مفید خواهند بود.

جریان کامل یک پیام

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

کاربر پیام را ارسال می‌کند
            │
            ▼
Frontend درخواست را به Backend ارسال می‌کند
            │
            ▼
احراز هویت کاربر انجام می‌شود
            │
            ▼
تاریخچۀ گفتگو از پایگاه داده خوانده می‌شود
            │
            ▼
درخواست به API درواره ارسال می‌شود
            │
            ▼
پاسخ مدل دریافت می‌شود
            │
            ▼
پاسخ در پایگاه داده ذخیره می‌شود
            │
            ▼
پاسخ به‌صورت Streaming برای کاربر نمایش داده می‌شود

این همان معماری‌ای است که در بسیاری از محصولات حرفه‌ای مبتنی بر هوش مصنوعی استفاده می‌شود و پایه‌ای مناسب برای افزودن قابلیت‌هایی مانند RAG، ابزارها (Tools)، Agentها و جستجوی اسناد سازمانی فراهم می‌کند.

ایجاد پروژه و اتصال Chatbot به API درواره

اکنون که معماری سیستم را طراحی کرده‌ایم، زمان پیاده‌سازی اولین نسخۀ Chatbot فرا رسیده است.

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

هدف این مرحله، ساخت کوچک‌ترین نسخۀ قابل اجرا (MVP) است. در ادامه، قابلیت‌هایی مانند Streaming، ذخیرۀ تاریخچۀ گفتگو و احراز هویت را به همین پروژه اضافه خواهیم کرد.

ساختار پروژه

برای این آموزش از ساختار زیر استفاده می‌کنیم:

chatbot/
│
├── app/
│   ├── main.py
│   ├── routes.py
│   ├── services.py
│   ├── config.py
│   └── models.py
│
├── .env
├── requirements.txt
└── README.md

تفکیک بخش‌های مختلف پروژه باعث می‌شود با بزرگ‌تر شدن سیستم، نگهداری و توسعۀ آن بسیار ساده‌تر باشد.

مدیریت تنظیمات پروژه

یکی از اشتباهات رایج، قراردادن کلید API داخل کد است.

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

بهتر است اطلاعات حساس در فایل .env یا متغیرهای محیطی ذخیره شوند.

نمونه‌ای از تنظیمات پروژه:

DARVAREH_API_KEY=YOUR_API_KEY
DARVAREH_BASE_URL=https://api.darvareh.ir/v1
MODEL_NAME=gpt-5.5

نکته: مقدار MODEL_NAME فقط یک نمونه است. در پروژه‌های واقعی، نام مدل را بر اساس مدل‌هایی که درواره در اختیار شما قرار می‌دهد انتخاب کنید تا بدون تغییر کد بتوانید بین مدل‌های مختلف جابه‌جا شوید.

چرا از API درواره استفاده می‌کنیم؟

شاید این سؤال برایتان پیش بیاید که چرا Backend مستقیماً به یک ارائه‌دهندۀ خاص متصل نشود.

در پروژه‌های کوچک شاید این موضوع اهمیت زیادی نداشته باشد، اما در محصولات واقعی معمولاً نیازهای زیر به وجود می‌آید:

• آزمایش چند مدل مختلف
• تغییر مدل در آینده
• کنترل هزینه‌ها
• استفاده از مدل مناسب برای هر سناریو
• جلوگیری از وابستگی به یک ارائه‌دهندۀ خاص

استفاده از API درواره این انعطاف را فراهم می‌کند که بدون تغییر معماری Backend، مدل مناسب را انتخاب یا در آینده جایگزین کنید.

طراحی API داخلی Chatbot

رابط کاربری نباید مستقیماً با مدل هوش مصنوعی ارتباط برقرار کند.

در عوض، Backend یک API داخلی در اختیار Frontend قرار می‌دهد.

برای مثال:

POST /api/chat

بدنۀ درخواست می‌تواند شامل اطلاعات زیر باشد:

{
  "conversation_id": "c_12345",
  "message": "سلام، امروز چه کمکی می‌توانی به من بکنی؟"
}

پس از دریافت درخواست، Backend مراحل زیر را انجام می‌دهد:

1. اعتبارسنجی داده‌ها
2. بررسی هویت کاربر
3. بازیابی تاریخچۀ گفتگو
4. ارسال درخواست به API درواره
5. دریافت پاسخ مدل
6. ذخیرۀ پیام و پاسخ
7. ارسال نتیجه به Frontend

این ساختار باعث می‌شود رابط کاربری کاملاً از منطق هوش مصنوعی جدا باشد.

اعتبارسنجی ورودی‌ها

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

حداقل موارد زیر را بررسی کنید:

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

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

ارسال درخواست به مدل

پس از آماده شدن داده‌ها، Backend درخواست را به API درواره ارسال می‌کند.

در این مرحله معمولاً اطلاعات زیر ارسال می‌شوند:

• مدل انتخابی
• پیام‌های مکالمه
• تنظیمات تولید پاسخ
• در صورت نیاز، پارامترهایی مانند دما (Temperature) یا حداکثر تعداد توکن

نکتۀ مهم این است که Backend تنها اطلاعاتی را برای مدل ارسال کند که برای پاسخ به درخواست فعلی لازم هستند.

ارسال کل تاریخچۀ گفتگو یا داده‌های غیرمرتبط، باعث افزایش هزینه و کاهش سرعت خواهد شد.

دریافت پاسخ و ذخیرۀ آن

پس از دریافت پاسخ از مدل، بهتر است قبل از ارسال آن به رابط کاربری، اطلاعات زیر در پایگاه داده ذخیره شوند:

• شناسۀ گفتگو
• پیام کاربر
• پاسخ مدل
• مدل استفاده‌شده
• زمان پاسخ
• تعداد توکن‌های مصرفی (در صورت دسترس بودن)

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

چرا ذخیرۀ تاریخچۀ گفتگو اهمیت دارد؟

فرض کنید کاربر امروز چنین سؤالی بپرسد:

لطفاً مشخصات لپ‌تاپ‌های مناسب برنامه‌نویسی را پیشنهاد بده.

و چند دقیقه بعد بنویسد:

کدام‌یک باتری بهتری دارد؟

اگر تاریخچۀ گفتگو ذخیره نشده باشد، مدل نمی‌تواند تشخیص دهد که منظور کاربر کدام لپ‌تاپ‌ها است.

به همین دلیل، تقریباً تمام Chatbotهای حرفه‌ای تاریخچۀ گفتگو را نگهداری می‌کنند تا پاسخ‌ها پیوسته و طبیعی باشند.

اولین نسخۀ قابل استفاده (MVP)

در پایان این مرحله، Chatbot شما باید بتواند:

• پیام کاربر را دریافت کند.
• آن را به Backend ارسال کند.
• Backend درخواست را به API درواره منتقل کند.
• پاسخ مدل را دریافت کند.
• پاسخ را در پایگاه داده ذخیره کند.
• نتیجه را به رابط کاربری بازگرداند.

اگر این مراحل به‌درستی انجام شوند، اولین نسخۀ Chatbot شما آماده است.

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

پیاده‌سازی Streaming؛ نمایش پاسخ به‌صورت لحظه‌ای

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

به این قابلیت Streaming گفته می‌شود.

در یک Chatbot حرفه‌ای، Streaming فقط یک قابلیت ظاهری نیست؛ بلکه نقش مهمی در بهبود تجربۀ کاربری دارد.

فرض کنید تولید یک پاسخ ۲۰ ثانیه طول بکشد.

بدون Streaming، کاربر ۲۰ ثانیه هیچ خروجی‌ای مشاهده نمی‌کند و ممکن است تصور کند سیستم متوقف شده است.

اما با Streaming، تنها چند لحظه پس از ارسال پیام، اولین بخش از پاسخ نمایش داده می‌شود و کاربر احساس می‌کند سیستم سریع‌تر و روان‌تر عمل می‌کند.

Streaming چگونه کار می‌کند؟

در حالت عادی، روند پردازش به این شکل است:

کاربر
   │
   ▼
Backend
   │
   ▼
API درواره
   │
   ▼
مدل پاسخ کامل را تولید می‌کند
   │
   ▼
Backend
   │
   ▼
Frontend

در این حالت، Frontend تا پایان تولید پاسخ منتظر می‌ماند.

اما در حالت Streaming، روند کمی متفاوت است.

کاربر
   │
   ▼
Backend
   │
   ▼
API درواره
   │
   ▼
پاسخ به‌صورت بخش‌به‌بخش تولید می‌شود
   │
   ▼
Backend
   │
   ▼
Frontend
   │
   ▼
نمایش هم‌زمان پاسخ

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

مزایای Streaming

استفاده از Streaming مزایای متعددی دارد.

کاهش زمان انتظار

کاربر تقریباً بلافاصله اولین بخش از پاسخ را مشاهده می‌کند.

تجربۀ کاربری بهتر

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

امکان توقف پاسخ

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

این قابلیت علاوه بر بهبود تجربۀ کاربری، می‌تواند باعث کاهش مصرف توکن نیز شود.

مناسب برای پاسخ‌های طولانی

در تولید مقاله، تحلیل اسناد یا تولید کد، پاسخ ممکن است چند هزار کلمه باشد.

Streaming باعث می‌شود کاربر از همان ابتدا متن را مطالعه کند و لازم نباشد تا پایان تولید صبر کند.

معماری Streaming

در بسیاری از پروژه‌های مدرن، ارتباط بین Backend و Frontend با استفاده از Server-Sent Events (SSE) یا فناوری‌های مشابه انجام می‌شود.

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

مزیت این روش آن است که Frontend نیازی به دانستن جزئیات ارتباط با مدل ندارد و تنها یک جریان پیوسته از متن را دریافت می‌کند.

آیا Streaming فقط برای متن کاربرد دارد؟

خیر.

بسته به مدل و نوع خروجی، Streaming می‌تواند برای انواع مختلف داده‌ها نیز استفاده شود.

برای مثال:

• متن
• کد
• استدلال مرحله‌به‌مرحله (در مدل‌هایی که از این قابلیت پشتیبانی می‌کنند)
• داده‌های ساختاریافته

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

طراحی رابط کاربری برای Streaming

یکی از اشتباهات رایج این است که Frontend هر بخش از پاسخ را به‌عنوان یک پیام جدید نمایش دهد.

در طراحی صحیح، تنها یک پیام ایجاد می‌شود و متن همان پیام به‌تدریج کامل می‌شود.

برای مثال، کاربر ممکن است ابتدا چنین چیزی ببیند:

برای ساخت یک Chatbot حرفه‌ای...

چند لحظه بعد:

برای ساخت یک Chatbot حرفه‌ای، ابتدا باید معماری مناسبی طراحی کنید...

و در نهایت:

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

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

نمایش وضعیت در حال تولید

هنگام استفاده از Streaming بهتر است وضعیت تولید پاسخ نیز به کاربر نمایش داده شود.

برای مثال:

• در حال فکر کردن...
• در حال تولید پاسخ...
• در حال دریافت اطلاعات...
• در حال تکمیل پاسخ...

نمایش این وضعیت‌ها باعث می‌شود کاربر بداند سیستم همچنان در حال پردازش درخواست است.

امکان توقف پاسخ

یکی از قابلیت‌هایی که بسیاری از کاربران انتظار دارند، دکمۀ توقف تولید پاسخ است.

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

این قابلیت به‌ویژه برای پاسخ‌های طولانی یا زمانی که کاربر پاسخ موردنیاز خود را زودتر دریافت کرده است، بسیار مفید خواهد بود.

ذخیرۀ پاسخ در حالت Streaming

یک سؤال مهم این است:

چه زمانی باید پاسخ در پایگاه داده ذخیره شود؟

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

اگر ارتباط در میانه راه قطع شود، می‌توانید بسته به نیاز پروژه یکی از این دو رویکرد را انتخاب کنید:

• ذخیرۀ پاسخ ناقص و علامت‌گذاری آن به‌عنوان «ناتمام»
• حذف پاسخ ناقص و درخواست تولید مجدد

انتخاب مناسب به نوع کاربرد Chatbot بستگی دارد.

مدیریت خطا هنگام Streaming

در پروژه‌های واقعی ممکن است ارتباط در میانه تولید پاسخ قطع شود.

برای مثال:

• اختلال شبکه
• پایان مهلت زمانی درخواست
• خطای سرویس هوش مصنوعی
• قطع ارتباط مرورگر

در چنین شرایطی، بهتر است Chatbot به‌جای نمایش یک پیام مبهم، وضعیت را به‌صورت شفاف به کاربر اعلام کند.

برای مثال:

ارتباط با سرویس هوش مصنوعی قطع شد. لطفاً دوباره تلاش کنید.

یا:

تولید پاسخ کامل نشد. آیا مایل هستید ادامه پاسخ دوباره تولید شود؟

مدیریت مناسب این شرایط تأثیر زیادی بر کیفیت تجربۀ کاربری خواهد داشت.

بهترین شیوه‌ها برای Streaming

اگر قصد دارید Chatbot خود را در محیط Production اجرا کنید، این توصیه‌ها را رعایت کنید:

• از Streaming برای پاسخ‌های متنی استفاده کنید.
• وضعیت تولید پاسخ را نمایش دهید.
• امکان توقف تولید پاسخ را فراهم کنید.
• پاسخ را به‌صورت تدریجی در همان پیام نمایش دهید.
• خطاهای احتمالی را به‌صورت واضح مدیریت کنید.
• پس از پایان موفقیت‌آمیز، متن کامل را ذخیره کنید.
• عملکرد Streaming را برای کاربران با اینترنت ضعیف نیز آزمایش کنید.

مدیریت Conversation History؛ چگونه تاریخچۀ گفتگو را ذخیره کنیم؟

اگر از ChatGPT، Claude یا سایر دستیارهای هوش مصنوعی استفاده کرده باشید، احتمالاً متوجه شده‌اید که هر گفت‌وگو به‌صورت مستقل ذخیره می‌شود و می‌توانید روزها یا حتی هفته‌ها بعد دوباره به همان مکالمه بازگردید.

این قابلیت شاید در ظاهر ساده به نظر برسد، اما یکی از مهم‌ترین بخش‌های معماری یک Chatbot حرفه‌ای است.

بدون مدیریت صحیح تاریخچۀ گفتگو، Chatbot نمی‌تواند مکالمه را ادامه دهد، پاسخ‌های مرتبط ارائه کند یا تجربۀ کاربری مناسبی ایجاد کند.

چرا Conversation History اهمیت دارد؟

فرض کنید کاربر چنین گفت‌وگویی را آغاز می‌کند:

کاربر

یک لپ‌تاپ مناسب برنامه‌نویسی پیشنهاد بده.

Chatbot

اگر بودجۀ شما حدود ۷۰ میلیون تومان است، مدل‌های A و B گزینه‌های مناسبی هستند.

چند دقیقه بعد کاربر می‌پرسد:

کدام‌یک باتری بهتری دارد؟

اگر تاریخچۀ گفتگو وجود نداشته باشد، Chatbot هیچ اطلاعی ندارد که منظور کاربر کدام لپ‌تاپ‌ها است.

در نتیجه مجبور می‌شود دوباره سؤال کند یا حتی پاسخ اشتباه بدهد.

اما با وجود Conversation History، Chatbot می‌داند سؤال دوم ادامه همان مکالمه است و پاسخ مناسبی ارائه می‌دهد.

Conversation با Memory چه تفاوتی دارد؟

گاهی این دو مفهوم با یکدیگر اشتباه گرفته می‌شوند.

Conversation History شامل پیام‌های ردوبدل‌شده در یک گفت‌وگو است.

اما Memory اطلاعاتی است که باید بین گفت‌وگوهای مختلف حفظ شوند.

برای مثال:

Conversation

• پیام اول
• پاسخ اول
• پیام دوم
• پاسخ دوم

Memory

• نام کاربر
• زبان ترجیحی
• تنظیمات شخصی
• شهر محل سکونت
• علایق کاربر

بنابراین Conversation مربوط به همین مکالمه است، اما Memory مربوط به کاربر است.

هر کاربر چند Conversation می‌تواند داشته باشد؟

در یک Chatbot حرفه‌ای، هر کاربر معمولاً می‌تواند چندین گفت‌وگو ایجاد کند.

برای مثال:

امیر

├── برنامه‌نویسی Python
├── سفر دبی
├── تحلیل قرارداد
├── ایده‌های استارتاپ
└── تحقیق دانشگاهی

هر Conversation تاریخچۀ مستقل خود را دارد.

این طراحی باعث می‌شود کاربر بتواند بدون تداخل موضوعات، چندین مکالمه را هم‌زمان مدیریت کند.

ساختار مناسب پایگاه داده

برای مدیریت گفتگوها، معمولاً دو موجودیت اصلی کافی است.

جدول Conversations

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

برای مثال:

• شناسه گفتگو
• شناسه کاربر
• عنوان گفتگو
• زمان ایجاد
• آخرین زمان به‌روزرسانی

جدول Messages

تمام پیام‌های کاربر و پاسخ‌های مدل در این جدول ذخیره می‌شوند.

هر پیام معمولاً شامل اطلاعات زیر است:

• شناسه پیام
• شناسه گفتگو
• فرستنده (کاربر یا مدل)
• متن پیام
• زمان ایجاد

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

عنوان‌گذاری خودکار گفتگو

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

برای مثال، اگر اولین پیام کاربر این باشد:

برای سفر به ژاپن برنامه‌ریزی کن.

عنوان گفتگو می‌تواند به‌صورت خودکار چنین چیزی باشد:

برنامه‌ریزی سفر به ژاپن

یا اگر پیام اول این باشد:

تفاوت FastAPI و Django چیست؟

عنوان گفتگو می‌تواند باشد:

مقایسۀ FastAPI و Django

این کار باعث می‌شود کاربران بعداً راحت‌تر گفت‌وگوهای خود را پیدا کنند.

آیا باید تمام پیام‌ها را برای مدل ارسال کنیم؟

خیر.

این یکی از اشتباهات رایج در طراحی Chatbot است.

فرض کنید یک Conversation شامل ۳۰۰ پیام باشد.

ارسال تمام این پیام‌ها در هر درخواست:

• هزینه را افزایش می‌دهد.
• سرعت پاسخ را کاهش می‌دهد.
• ممکن است از محدودیت Context مدل فراتر برود.

بهترین روش این است که فقط بخش مرتبط از تاریخچۀ گفتگو را برای مدل ارسال کنید.

خلاصه‌سازی گفتگوهای طولانی

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

برای مثال:

به‌جای ارسال ۱۵۰ پیام قبلی، می‌توان خلاصه‌ای مانند زیر را در اختیار مدل قرار داد:

کاربر دربارۀ انتخاب لپ‌تاپ، مقایسۀ پردازنده‌ها و بودجۀ ۷۰ میلیون تومان سؤال کرده است. در پاسخ، مدل دو گزینۀ A و B را پیشنهاد داده است.

این روش باعث می‌شود:

• تعداد توکن‌ها کاهش یابد.
• سرعت افزایش پیدا کند.
• مدل همچنان Context لازم را در اختیار داشته باشد.

حذف Conversation

کاربران معمولاً انتظار دارند بتوانند گفت‌وگوهای خود را حذف کنند.

اما حذف Conversation باید فقط از دید کاربر انجام شود یا از پایگاه داده نیز حذف شود؟

در پروژه‌های سازمانی معمولاً دو رویکرد وجود دارد:

حذف منطقی (Soft Delete)

Conversation از دید کاربر مخفی می‌شود اما در پایگاه داده باقی می‌ماند.

مزایا:

• امکان بازیابی
• حفظ لاگ‌ها
• مناسب برای سازمان‌ها

حذف فیزیکی (Hard Delete)

تمام اطلاعات Conversation حذف می‌شوند.

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

جستجو در گفتگوها

اگر کاربران صدها Conversation داشته باشند، پیدا کردن یک گفت‌وگوی قدیمی دشوار خواهد شد.

به همین دلیل، بسیاری از Chatbotهای حرفه‌ای امکان جستجو در عنوان یا متن گفتگوها را فراهم می‌کنند.

برای مثال، کاربر می‌تواند عبارت زیر را جستجو کند:

قرارداد اجاره

و تمام Conversationهای مرتبط را مشاهده کند.

همگام‌سازی بین چند دستگاه

کاربر ممکن است امروز با لپ‌تاپ خود گفتگو را آغاز کند و فردا از طریق تلفن همراه همان مکالمه را ادامه دهد.

اگر Conversationها در پایگاه داده ذخیره شوند، این انتقال کاملاً شفاف خواهد بود و کاربر بدون از دست دادن تاریخچه، می‌تواند از هر دستگاهی به گفت‌وگوهای خود دسترسی داشته باشد.

بهترین شیوه‌ها برای مدیریت گفتگو

اگر قصد دارید یک Chatbot مقیاس‌پذیر طراحی کنید، این توصیه‌ها را رعایت کنید:

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

گام بعدی

اکنون Chatbot ما می‌تواند:

• چندین گفت‌وگو را برای هر کاربر مدیریت کند.
• تاریخچۀ مکالمات را ذخیره و بازیابی کند.
• Context مناسب را برای مدل ارسال کند.
• پاسخ‌ها را به‌صورت Streaming نمایش دهد.

اما هنوز یک قابلیت بسیار مهم باقی مانده است.

امروزه بسیاری از کاربران انتظار دارند علاوه بر متن، فایل نیز برای Chatbot ارسال کنند؛ مانند:

• PDF
• Word
• Excel
• تصویر
• فایل متنی

افزودن قابلیت بارگذاری فایل؛ فراتر از یک Chatbot متنی

تا اینجا Chatbot ما تنها با پیام‌های متنی کار می‌کند. اما در بسیاری از پروژه‌های واقعی، کاربران انتظار دارند بتوانند فایل نیز ارسال کنند.

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

• یک قرارداد را خلاصه کند.
• یک فایل PDF را تحلیل کند.
• یک فایل Excel را بررسی کند.
• یک رزومه را ارزیابی کند.
• یک تصویر را برای مدل ارسال کند.
• از روی یک گزارش مالی سؤال بپرسد.

به همین دلیل، پشتیبانی از فایل یکی از مهم‌ترین قابلیت‌های یک Chatbot مدرن محسوب می‌شود.

معماری تحلیل فایل

اضافه کردن File Upload فقط به معنی قراردادن یک دکمۀ «انتخاب فایل» نیست.

پشت صحنه، چندین مرحله انجام می‌شود.

کاربر
    │
    ▼
بارگذاری فایل
    │
    ▼
Backend
    │
    ├────────► اعتبارسنجی فایل
    │
    ├────────► ذخیرۀ فایل
    │
    ├────────► استخراج محتوا
    │
    └────────► ارسال به API درواره
                     │
                     ▼
              مدل هوش مصنوعی
                     │
                     ▼
               پاسخ به کاربر

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

چه فایل‌هایی را می‌توان پشتیبانی کرد؟

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

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

اعتبارسنجی فایل‌ها

هر فایل بارگذاری‌شده باید پیش از پردازش بررسی شود.

حداقل موارد زیر را کنترل کنید:

• نوع فایل
• حجم فایل
• پسوند
• محتوای واقعی فایل
• تعداد فایل‌های ارسالی

برای مثال، اگر Chatbot فقط از PDF پشتیبانی می‌کند، نباید فایل اجرایی یا فایل ناشناس را بپذیرد.

همچنین بهتر است برای جلوگیری از مصرف بیش از حد منابع، محدودیتی برای اندازۀ فایل‌ها در نظر بگیرید.

استخراج متن از فایل

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

ابتدا باید محتوای فایل استخراج شود.

برای مثال:

• از PDF متن استخراج می‌شود.
• از فایل Word محتوای سند خوانده می‌شود.
• از فایل Excel داده‌های جدول استخراج می‌شوند.

پس از استخراج، متن در اختیار مدل قرار می‌گیرد تا آن را تحلیل کند.

تحلیل PDF

یکی از رایج‌ترین کاربردهای Chatbotهای سازمانی، تحلیل فایل‌های PDF است.

کاربر ممکن است چنین درخواستی داشته باشد:

این قرارداد را خلاصه کن.

یا:

مهم‌ترین تعهدات طرفین این قرارداد چیست؟

یا:

بندهای مربوط به فسخ قرارداد را پیدا کن.

در این سناریو، Chatbot ابتدا متن PDF را استخراج می‌کند و سپس آن را برای مدل ارسال می‌کند تا پاسخ مناسبی تولید شود.

تحلیل فایل‌های Excel

بسیاری از کسب‌وکارها داده‌های خود را در فایل‌های Excel نگهداری می‌کنند.

نمونه درخواست‌های کاربران:

فروش ماه گذشته را تحلیل کن.

بیشترین فروش مربوط به کدام محصول است؟

نمودار روند فروش را توضیح بده.

در این حالت، Backend اطلاعات فایل را استخراج می‌کند و داده‌های ساختاریافته را در اختیار مدل قرار می‌دهد.

تحلیل تصویر

یکی دیگر از قابلیت‌های ارزشمند Chatbotهای مدرن، تحلیل تصویر است.

برای مثال، کاربر می‌تواند:

• تصویر یک نمودار را ارسال کند.
• عکس یک محصول را بارگذاری کند.
• اسکرین‌شات یک خطا را ارسال کند.
• تصویر یک سند را تحلیل کند.

در چنین سناریوهایی، Chatbot متن تصویر را تولید نمی‌کند، بلکه محتوای تصویر را تحلیل کرده و به سؤال کاربر پاسخ می‌دهد.

برای مثال:

این نمودار چه چیزی را نشان می‌دهد؟

یا:

این خطا در برنامه به چه معناست؟

امنیت فایل‌ها

فایل‌های بارگذاری‌شده ممکن است شامل اطلاعات محرمانه باشند.

به همین دلیل رعایت چند اصل ضروری است:

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

در پروژه‌های سازمانی، این موارد اهمیت بسیار زیادی دارند و باید از همان ابتدای طراحی در نظر گرفته شوند.

چه زمانی باید از RAG استفاده کنیم؟

اگر کاربر تنها یک فایل را بارگذاری کند و چند سؤال درباره همان فایل بپرسد، معمولاً استخراج متن و ارسال آن به مدل کافی است.

اما اگر قرار باشد Chatbot روی هزاران فایل، صدها قرارداد، اسناد داخلی شرکت یا پایگاه دانش سازمان جستجو کند، این روش دیگر مناسب نیست.

در چنین شرایطی باید از Retrieval-Augmented Generation (RAG) استفاده کنید.

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

در مقالۀ «ساخت یک سیستم RAG واقعی با LangChain، LlamaIndex و API درواره» نحوۀ پیاده‌سازی این معماری را به‌صورت گام‌به‌گام آموزش داده‌ایم.

اتصال Chatbot به سیستم RAG؛ پاسخ‌گویی بر اساس اسناد و دانش اختصاصی

تا اینجا Chatbot ما می‌تواند:

• پیام‌های کاربران را دریافت کند.
• تاریخچۀ گفتگو را مدیریت کند.
• پاسخ‌ها را به‌صورت Streaming نمایش دهد.
• فایل‌های PDF، Word و تصویر را تحلیل کند.

اما هنوز یک محدودیت اساسی وجود دارد.

تمام پاسخ‌های Chatbot بر اساس اطلاعاتی تولید می‌شوند که یا در پیام کاربر وجود دارد یا مدل زبانی قبلاً آن‌ها را آموخته است.

حال فرض کنید بخواهید Chatbot به سؤال‌هایی مانند موارد زیر پاسخ دهد:

آیین‌نامۀ مرخصی شرکت چیست؟

یا

آخرین قرارداد همکاری با شرکت X چه شرایطی دارد؟

یا

بر اساس مستندات داخلی، نحوۀ استقرار سرویس چگونه است؟

مدل زبانی به این اطلاعات دسترسی ندارد.

اینجاست که Retrieval-Augmented Generation (RAG) وارد عمل می‌شود.

RAG چیست؟

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

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

در عوض:

• اطلاعات مرتبط پیدا می‌شود.
• فقط همان بخش‌ها برای مدل ارسال می‌شوند.
• مدل پاسخ نهایی را بر اساس آن اطلاعات تولید می‌کند.

به همین دلیل، پاسخ‌ها دقیق‌تر، به‌روزتر و قابل اعتمادتر خواهند بود.

معماری Chatbot مبتنی بر RAG

در یک معماری استاندارد، جریان پردازش به شکل زیر است.

کاربر
    │
    ▼
Frontend
    │
    ▼
Backend
    │
    ▼
جستجو در پایگاه دانش
    │
    ▼
بخش‌های مرتبط اسناد
    │
    ▼
API درواره
    │
    ▼
مدل هوش مصنوعی
    │
    ▼
پاسخ نهایی

تفاوت اصلی این معماری با Chatbot معمولی در مرحلۀ بازیابی اطلاعات است.

چرا نباید کل اسناد را برای مدل ارسال کنیم؟

فرض کنید شرکت شما ۸ هزار فایل PDF دارد.

آیا می‌توان تمام این فایل‌ها را در هر درخواست برای مدل ارسال کرد؟

خیر.

چند دلیل مهم:

• هزینه بسیار زیاد خواهد شد.
• سرعت پاسخ به‌شدت کاهش پیدا می‌کند.
• محدودیت Context مدل اجازه چنین کاری را نمی‌دهد.
• بیشتر اطلاعات به درخواست کاربر ارتباطی ندارند.

به همین دلیل، ابتدا باید فقط اسناد مرتبط پیدا شوند.

RAG چگونه اسناد مرتبط را پیدا می‌کند؟

به‌طور خلاصه، فرایند به این شکل است:

۱. اسناد به بخش‌های کوچک‌تر تقسیم می‌شوند.

۲. از هر بخش یک بردار معنایی (Embedding) تولید می‌شود.

۳. این بردارها در یک پایگاه دادۀ برداری ذخیره می‌شوند.

۴. هنگام طرح سؤال، از سؤال نیز Embedding ساخته می‌شود.

۵. نزدیک‌ترین بخش‌های اسناد پیدا می‌شوند.

۶. فقط همان بخش‌ها برای مدل ارسال می‌شوند.

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

یک مثال واقعی

فرض کنید کاربر سؤال زیر را مطرح می‌کند:

مدت گارانتی لپ‌تاپ‌های شرکت چند ماه است؟

پایگاه دانش ممکن است شامل صدها فایل باشد.

اما سیستم RAG فقط بخشی از سند گارانتی را پیدا می‌کند.

برای مثال:

تمام محصولات سری Professional دارای ۲۴ ماه گارانتی هستند.

همین بخش به مدل ارسال می‌شود و پاسخ نهایی تولید خواهد شد.

چه زمانی به RAG نیاز داریم؟

اگر Chatbot فقط به سؤال‌های عمومی پاسخ می‌دهد، معمولاً نیازی به RAG نیست.

اما در شرایط زیر استفاده از RAG توصیه می‌شود:

• مستندات شرکت
• قراردادها
• آیین‌نامه‌ها
• راهنماهای فنی
• ویکی داخلی
• گزارش‌های سازمانی
• مقالات علمی
• مستندات محصول

در چنین پروژه‌هایی، RAG تقریباً ضروری است.

تفاوت تحلیل فایل و RAG

یکی از رایج‌ترین ابهام‌ها این است که کاربران تصور می‌کنند تحلیل PDF همان RAG است.

در حالی که این دو کاربرد متفاوتی دارند.

به همین دلیل، اگر کاربر تنها یک قرارداد را بارگذاری کند، نیازی به RAG نیست.

اما اگر قرار باشد Chatbot در کل آرشیو شرکت جستجو کند، RAG بهترین انتخاب است.

API درواره و RAG

یکی از مزیت‌های استفاده از API درواره این است که پس از بازیابی اطلاعات، می‌توانید آن‌ها را برای مدل مناسب ارسال کنید.

برای مثال:

• پاسخ‌های سریع با یک مدل اقتصادی
• تحلیل قراردادها با مدلی دارای توانایی استدلال بالا
• تحلیل مستندات فنی با مدلی مناسب برنامه‌نویسی

بدون اینکه معماری Chatbot تغییر کند.

بهترین شیوه‌های طراحی Chatbot مبتنی بر RAG

اگر قصد دارید یک دستیار سازمانی ایجاد کنید، این نکات را رعایت کنید:

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

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

RAG پایان کار نیست

بسیاری از تیم‌ها تصور می‌کنند پس از پیاده‌سازی RAG، Chatbot آن‌ها کامل شده است.

در عمل، RAG تنها یکی از اجزای یک دستیار هوشمند است.

یک Chatbot حرفه‌ای معمولاً این قابلیت‌ها را نیز دارد:

• احراز هویت کاربران
• مدیریت سطح دسترسی
• Streaming
• ذخیرۀ تاریخچۀ گفتگو
• تحلیل فایل
• استفاده از Toolها
• قابلیت جستجو
• مانیتورینگ
• ثبت لاگ
• مدیریت هزینه‌ها

ترکیب این قابلیت‌ها است که یک محصول قابل استفاده در محیط Production ایجاد می‌کند.

آماده‌سازی Chatbot برای محیط Production

اگر تا اینجا مراحل مقاله را دنبال کرده باشید، اکنون یک Chatbot دارید که می‌تواند:

• پیام‌های کاربران را دریافت کند.
• با API درواره ارتباط برقرار کند.
• پاسخ‌ها را به‌صورت Streaming نمایش دهد.
• تاریخچۀ گفتگو را مدیریت کند.
• فایل‌های کاربران را تحلیل کند.
• به پایگاه دانش مبتنی بر RAG متصل شود.

اما هنوز یک تفاوت مهم بین این پروژه و یک محصول واقعی وجود دارد.

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

در ادامه مهم‌ترین توصیه‌ها برای استقرار یک Chatbot حرفه‌ای را بررسی می‌کنیم.

احراز هویت کاربران

اگر Chatbot بخشی از محصول یا سامانه شما است، باید هویت کاربران پیش از ارسال درخواست به مدل بررسی شود.

این کار چند مزیت مهم دارد:

• جلوگیری از استفاده غیرمجاز
• محدود کردن دسترسی به داده‌های هر کاربر
• امکان اعمال سهمیه (Quota)
• ثبت فعالیت کاربران

هرگز کلید API را در اختیار مرورگر قرار ندهید. تمام درخواست‌ها باید ابتدا به Backend ارسال شوند و Backend پس از بررسی مجوزها، با API درواره ارتباط برقرار کند.

مدیریت هزینه‌ها

در پروژه‌های آزمایشی شاید مصرف توکن اهمیت زیادی نداشته باشد، اما در محیط Production مدیریت هزینه ضروری است.

چند راهکار عملی:

• فقط تاریخچۀ مرتبط را برای مدل ارسال کنید.
• مکالمات طولانی را خلاصه کنید.
• از Streaming استفاده کنید تا کاربران پاسخ را زودتر ببینند.
• برای هر نوع درخواست، مدل مناسب را انتخاب کنید.
• درخواست‌های تکراری را در صورت امکان Cache کنید.

اگر Chatbot روزانه هزاران درخواست دریافت می‌کند، همین بهینه‌سازی‌ها می‌توانند هزینه‌ها را به شکل محسوسی کاهش دهند.

ثبت لاگ و مانیتورینگ

یکی از اولین قابلیت‌هایی که باید به Chatbot اضافه کنید، ثبت لاگ است.

برای هر درخواست، اطلاعاتی مانند موارد زیر را ذخیره کنید:

• شناسه کاربر
• شناسه گفتگو
• مدل استفاده‌شده
• زمان شروع و پایان پردازش
• مدت زمان پاسخ
• وضعیت درخواست (موفق یا ناموفق)
• اطلاعات مصرف توکن (در صورت دسترس بودن)

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

محدود کردن نرخ درخواست‌ها (Rate Limiting)

اگر هیچ محدودیتی وجود نداشته باشد، ممکن است یک کاربر یا یک اسکریپت مخرب هزاران درخواست در مدت کوتاهی ارسال کند.

برای جلوگیری از این موضوع، بهتر است محدودیت‌هایی مانند موارد زیر اعمال شوند:

• تعداد درخواست در دقیقه
• تعداد درخواست در روز
• حداکثر تعداد پیام در هر گفتگو
• محدودیت بر اساس نقش کاربر

این محدودیت‌ها علاوه بر افزایش امنیت، از مصرف غیرضروری منابع نیز جلوگیری می‌کنند.

مدیریت خطاها

هیچ سرویسی همیشه در دسترس نیست.

ممکن است:

• ارتباط اینترنت قطع شود.
• مدل هوش مصنوعی موقتاً در دسترس نباشد.
• پایگاه داده پاسخ ندهد.
• زمان انتظار درخواست به پایان برسد.

در چنین شرایطی، به‌جای نمایش پیام‌های فنی یا نامفهوم، خطا را به زبان ساده به کاربر توضیح دهید.

برای مثال:

در حال حاضر امکان دریافت پاسخ وجود ندارد. لطفاً چند دقیقه دیگر دوباره تلاش کنید.

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

همه درخواست‌ها به یک مدل یکسان نیاز ندارند.

برای مثال:

از آنجا که API درواره از مدل‌های متنوعی پشتیبانی می‌کند، می‌توانید بدون تغییر معماری پروژه، مدل مناسب هر سناریو را انتخاب کنید.

۱۰ اشتباه رایج هنگام ساخت Chatbot

حتی توسعه‌دهندگان باتجربه نیز گاهی با چالش‌هایی روبه‌رو می‌شوند که باعث کاهش کیفیت Chatbot می‌شود.

در ادامه، رایج‌ترین اشتباهات را مرور می‌کنیم.

۱. قراردادن کلید API در Frontend

کلید API باید فقط در Backend نگهداری شود.

۲. ارسال کل تاریخچۀ گفتگو در هر درخواست

این کار هزینه را افزایش داده و سرعت پاسخ را کاهش می‌دهد.

۳. نداشتن مدیریت خطا

کاربران باید در صورت بروز خطا، پیام واضح و قابل فهم دریافت کنند.

۴. طراحی نامناسب پایگاه داده

پیام‌ها، گفتگوها و کاربران را از یکدیگر جدا نگه دارید.

۵. استفاده نکردن از Streaming

برای پاسخ‌های طولانی، Streaming تجربۀ کاربری بسیار بهتری ایجاد می‌کند.

۶. نادیده گرفتن امنیت

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

۷. استفاده از یک مدل برای تمام سناریوها

انتخاب مدل مناسب برای هر وظیفه باعث کاهش هزینه و افزایش کیفیت پاسخ‌ها می‌شود.

۸. طراحی بدون قابلیت توسعه

از همان ابتدا معماری را به‌گونه‌ای طراحی کنید که بعداً بتوانید قابلیت‌هایی مانند RAG یا AI Agent را به آن اضافه کنید.

۹. نداشتن مانیتورینگ

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

۱۰. انتظار بیش از حد از مدل زبانی

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

پرسش‌های متداول

آیا می‌توان Chatbot را بدون Backend ساخت؟

از نظر فنی ممکن است، اما برای پروژه‌های واقعی توصیه نمی‌شود؛ زیرا امنیت، کنترل هزینه و مدیریت کاربران به‌شدت محدود خواهد شد.

آیا API درواره فقط برای Chatbot مناسب است؟

خیر. علاوه بر Chatbot، می‌توانید از آن برای ساخت AI Agent، سیستم‌های RAG، ابزارهای تولید محتوا، دستیارهای برنامه‌نویسی، تحلیل اسناد و بسیاری از کاربردهای دیگر استفاده کنید.

آیا می‌توان مدل را بدون تغییر کد جایگزین کرد؟

اگر معماری پروژه بر اساس API سازگار با OpenAI طراحی شده باشد، معمولاً تنها با تغییر تنظیمات مربوط به مدل می‌توان از مدل دیگری استفاده کرد.

آیا Chatbot می‌تواند فایل PDF را تحلیل کند؟

بله. با استخراج متن فایل و ارسال آن به مدل، می‌توانید قابلیت‌هایی مانند خلاصه‌سازی، پاسخ به سؤال و تحلیل قرارداد را پیاده‌سازی کنید.

چه زمانی باید از RAG استفاده کنیم؟

اگر Chatbot باید به هزاران سند یا پایگاه دانش سازمان دسترسی داشته باشد، استفاده از RAG بهترین گزینه است.

Chatbot یا AI Agent؛ کدام را انتخاب کنیم؟

اگر هدف شما پاسخ‌گویی و مکالمه با کاربران است، Chatbot معمولاً انتخاب مناسبی است.

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

جمع‌بندی

ساخت یک Chatbot حرفه‌ای فقط به اتصال یک مدل هوش مصنوعی محدود نمی‌شود.

یک Chatbot مدرن باید بتواند کاربران را مدیریت کند، تاریخچۀ گفتگو را ذخیره کند، پاسخ‌ها را به‌صورت Streaming نمایش دهد، فایل‌ها را تحلیل کند، به پایگاه دانش متصل شود و در عین حال امنیت، مقیاس‌پذیری و هزینه‌های سیستم را نیز کنترل کند.

در این مقاله، معماری یک Chatbot حرفه‌ای را از طراحی اولیه تا استقرار در محیط Production بررسی کردیم و دیدیم چگونه می‌توان با استفاده از API درواره، بدون وابستگی به یک ارائه‌دهندۀ خاص، یک چت‌بات توسعه‌پذیر و آماده برای پروژه‌های واقعی ایجاد کرد.

اگر قصد دارید قابلیت‌های بیشتری به Chatbot خود اضافه کنید، پیشنهاد می‌کنیم مقالات زیر را نیز مطالعه کنید:

• آموزش ساخت AI Agent با OpenAI Agents SDK و API درواره
• LangChain چیست؟ آموزش کامل ساخت Agentهای هوش مصنوعی
• LlamaIndex چیست؟ آموزش ساخت سیستم RAG و اتصال داده‌ها به هوش مصنوعی
• ساخت یک سیستم RAG واقعی با LangChain، LlamaIndex و API درواره

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