معماری پشت‌صحنه یک چت‌بات حرفه‌ای چگونه است؟

یک چت‌بات «حرفه‌ای» در عمل فقط یک مدل زبانی نیست. چیزی که کاربران می‌بینند یک UI ساده و یک باکس گفتگو است، اما پشت صحنه معمولاً یک سیستم چندلایه قرار دارد: API Gateway + سرویس مکالمه + لایه داده (SQL/NoSQL/Vector DB) + مدل زبانی + ابزارها/اکشن‌ها + امنیت/مانیتورینگ. هدف این مقاله این است که این لایه‌ها را دقیق، کاربردی و با نگاه مهندسی توضیح دهد.

1) لایه ورودی و API: نقطه شروع همه‌چیز

در معماری استاندارد، «چت» از سمت وب/موبایل/واتساپ/تلگرام وارد API شما می‌شود. این API معمولاً با یک API Gateway یا Reverse Proxy مثل Nginx/Envoy مدیریت می‌شود تا موضوعاتی مثل TLS، Rate limit، WAF، احراز هویت و روتینگ سرویس‌ها استاندارد شوند.

در این مرحله چند کار کلیدی انجام می‌شود:

• Authentication/Authorization: کاربر کیست؟ به چه داده‌هایی دسترسی دارد؟ (JWT، OAuth2، Session)

• Request Normalization: تبدیل کانال‌های مختلف به یک پیام استاندارد (متن، فایل، تصویر، متادیتا)

• Rate Limiting و Quota: کنترل هزینه و جلوگیری از حملات رباتی

• Observability Hook: یک Trace-ID از همینجا تولید می‌شود تا کل زنجیره قابل ردیابی باشد

از اینجا درخواست وارد «سرویس مکالمه» می‌شود که مهم‌ترین بخش بک‌اند چت‌بات است.

2) سرویس مکالمه (Conversation Service): مغز ارکستریشن

این سرویس تصمیم می‌گیرد برای هر پیام چه اتفاقی بیفتد. معمولاً اجزای زیر را دارد:

2.1 مدیریت وضعیت گفتگو (State)

چت‌بات حرفه‌ای باید «کانتکست» را مدیریت کند، اما نه با روش خامِ ذخیره کل تاریخچه و ارسال دوباره آن. چون:

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

• احتمال لو رفتن اطلاعات بیشتر می‌شود

• کیفیت پاسخ افت می‌کند (نویز زیاد)

پس معمولاً این ترکیب را می‌بینیم:

• Short-term memory: چند پیام آخر (مثلاً 10 پیام) برای انسجام مکالمه

• Summarized memory: خلاصه‌ی به‌روزشونده از گفتگو

• Long-term memory: داده‌های قابل بازیابی از دیتابیس/Vector DB (در بخش RAG)

2.2 تصمیم‌گیری مسیر (Routing)

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

• فقط نیاز به پاسخ زبانی دارد؟

• یا باید به ابزارها/اکشن‌ها وصل شود؟ (مثلاً “فاکتور من رو بده”، “وقت جلسه رزرو کن”، “وضعیت سفارش؟”)

• یا باید ابتدا بازیابی دانش انجام شود؟ (RAG)

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

3) لایه مدل زبانی: API مدل و الگوی استفاده

معمولاً شما مدل را از طریق API فراخوانی می‌کنید. در دنیای جدید OpenAI، Responses API به‌عنوان مسیر پیشنهادی برای پروژه‌های جدید مطرح شده و قابلیت‌های agentic/ابزاری را بهتر یک‌جا ارائه می‌دهد.

همچنین Chat Completions هنوز وجود دارد و برای بسیاری از سناریوها استفاده می‌شود.

نکته‌های معماری در این لایه:

• Streaming برای تجربه سریع‌تر (کاربر حس می‌کند سیستم زنده است)

• Structured Outputs یا پاسخ‌های قالب‌مند (برای اتصال امن به UI/Workflow)

• Tool/Function Calling برای وصل کردن مدل به دنیای واقعی (در بخش بعد)

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

4) ابزارها و اکشن‌ها: وقتی چت‌بات باید «کار» انجام دهد

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

• از دیتابیس بخواند

• سفارش/تیکت ثبت کند

• پرداخت را هدایت کند

• گزارش بسازد

• در CRM/ERP عملیات انجام دهد

این دقیقاً با Tool Calling / Function Calling انجام می‌شود: شما ابزارها را با یک Schema تعریف می‌کنید و مدل بر اساس نیاز، آن‌ها را صدا می‌زند.

نکته معماری: ابزارها را مثل “API داخلی امن” طراحی کنید:

• ورودی‌ها validate شوند

• سطح دسترسی کنترل شود

• خروجی‌ها sanitize شوند

• زمان اجرا و هزینه محدود باشد

5) دیتابیس و دانش: SQL/NoSQL و لایه Vector برای RAG

5.1 دیتابیس عملیاتی (Operational DB)

این بخش همان SQL/NoSQL کلاسیک است:

• کاربران، نقش‌ها، سشن‌ها

• سفارش‌ها، تیکت‌ها، فاکتورها

• تنظیمات و کانفیگ‌های سازمانی

• لاگ رویدادها

5.2 چرا Vector DB؟

چون بسیاری از نیازهای چت‌بات «بازیابی دانش متنی» است:

• مستندات داخلی

• FAQ

• قراردادها و آیین‌نامه‌ها

• کاتالوگ محصول

• ایمیل‌ها/دانش سازمان

اینجاست که RAG وارد می‌شود: به جای اینکه مدل “حدس بزند”، اول جستجو می‌کنید و بعد از مدل می‌خواهید با استناد به نتایج، پاسخ دهد. مفهوم کلی RAG و مرحله Retrieval با embedding و جستجوی برداری به‌طور گسترده در منابع فنی توضیح داده شده است.

5.3 انتخاب تکنولوژی Vector Store

دو مسیر رایج:

الف) PostgreSQL + pgvector

اگر می‌خواهید استک ساده باشد و تیم‌تان SQL محور است، pgvector بسیار کاربردی است: ذخیره embedding و similarity search در خود Postgres.

ب) سرویس‌های تخصصی Vector DB

مثل Pinecone و… که در مقیاس بالا، ابزارهای خوبی برای hybrid search / rerank و مدیریت ایندکس دارند.

6) امنیت: چت‌بات حرفه‌ای یعنی «ایمن» قبل از «باهوش»

در چت‌بات‌های سازمانی، تهدید اصلی فقط SQL Injection نیست؛ Prompt Injection و سوءاستفاده از رفتار مدل یکی از ریسک‌های کلیدی است و حتی در OWASP LLM Top 10 به‌عنوان ریسک شماره 1 آمده است.

چک‌لیست امنیتی معماری:

• تفکیک داده و دستور: هرگز متن کاربر را “دستور سیستم” نکنید

• Least Privilege برای ابزارها: ابزارها فقط به حداقل داده لازم دسترسی داشته باشند

• Content Filtering/Policy: برای داده حساس (PII)، خروجی کنترل شود

• Audit Trail: هر Tool Call باید لاگ قابل بررسی داشته باشد

• Rate limit و Model DoS: جلوگیری از پیام‌های طولانی/حمله هزینه‌ای (OWASP به Model DoS هم اشاره می‌کند)

7) مانیتورینگ و بهبود کیفیت: بدون Observability چت‌بات “Black Box” است

یک چت‌بات حرفه‌ای باید قابل اندازه‌گیری باشد:

• نرخ حل مسئله (Resolution Rate)

• زمان پاسخ

• نرخ ارجاع به انسان

• هزینه به ازای هر مکالمه

• کیفیت RAG (آیا سند درست بازیابی شد؟)

• خطاهای Tool Calling

در عمل تیم‌ها معمولاً:

• لاگ‌های ساختاریافته (JSON logs)

• Tracing (OpenTelemetry)

• داشبورد متریک‌ها (Prometheus/Grafana یا سرویس‌های APM)

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

8) نقشه معماری پیشنهادی (جمع‌بندی عملی)

اگر بخواهیم یک معماری مرجعِ «قابل پیاده‌سازی» بدهیم، این زنجیره استاندارد است:

1. Client/UI (Web/Mobile/Channels)

2. API Gateway (Auth, Rate limit, WAF)

3. Conversation Service

o State manager (short/summarized memory)

o Router (RAG vs Tool vs Direct answer)

4. Knowledge Layer

o SQL/NoSQL Operational DB

o Vector Store (pgvector یا سرویس تخصصی)

5. LLM API (Responses/Chat Completions)

6. Tools/Actions (Function calling به سرویس‌های داخلی)

7. Observability + Security (Logs/Tracing/Policies/Red-team)

منبع : منظومه نگاران