بازگشت به کتابخانهکتابخانه16.1سرویس LLM در production و RAG
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 16.1فصل ۱۶طراحی سیستم در عصر AI

سرویس LLM در production و RAG

  • ~۱۵ دقیقه
  • ۴ پرسش
  • متن را انتخاب کن تا هایلایت شود

محصول AI یعنی تمام درس‌های ۱۵ فصل قبل به‌علاوه سه متغیر جدید: مدل گران و کند، خروجی غیرقطعی، و context محدود. معماری AI محصولِ جدیدی نیست؛ سیستم‌دیزاین است با محدودیت‌های تازه.

چالش‌های یکتای LLM در production

  • تأخیر و هزینه متغیر: هر توکن پول است؛ پاسخ ۱۰۰۰ توکنی = ثانیه‌ها استریم. راهکارها: استریم SSE (درس ۴۰ — UX را زنده نگه می‌دارد)، model routing (سؤال ساده به مدل کوچک/ارزان، پیچیده به بزرگ)، و کش معنایی.
  • Semantic Cache: کش فصل ۴ بر تطبیق دقیق کلید بود؛ اینجا کلید بردار embedding سؤال است و hit یعنی شباهت بالای آستانه — سؤال «قیمتش چنده؟» و «چقدر می‌شه؟» هر دو از یک پاسخ کش سرو می‌شوند. خطر: پاسخ شخصی/حساس را نباید کش معنایی کنی.
  • Token Budget: context محدود است؛ باید بودجه‌بندی کنی: system prompt + تاریخچه خلاصه‌شده + اسناد بازیابی‌شده + پاسخ. خلاصه‌سازی تاریخچه (به‌جای ارسال کل چت) هم هزینه را کم می‌کند هم کیفیت را.
  • قطعیت نیست: همان ورودی، خروجی متفاوت. پس نیاز به: ارزیابی مداوم (eval) روی مجموعه‌ای از پرامپت‌های مرجع، گاردریل خروجی (ولیدیشن ساختاری/موضوعی)، و fallback وقتی اعتماد پایین است («نمی‌دانم، با پشتیبانی صحبت کنید»).

RAG: سه‌شماره‌دار بازیابی

DIAGRAMجریان RAG
سؤال کاربر
Embedding سؤال
جستجوی ANN در Vector DB
بازترتيب و انتخاب K سند
تزریق به context مدل
پاسخ + ارجاع
  • گام ۱ — ایندکس: اسناد را chunk کن (نه خیلی ریز که معنا بشکند، نه خیلی درشت که نویز بیاید؛ معمولاً چند صد توکن با هم‌پوشانی)، هر قطعه را embed کن و در دیتابیس برداری بگذار.
  • گام ۲ — بازیابی: ANN (فصل ۳، درس بعدی همین فصل) نزدیک‌ترین K بردار را می‌آورد؛ معمولاً با فیلتر متادیتا (tenant_id ،زبان، تاریخ) ترکیب می‌شود.
  • گام ۳ — تولید: اسناد منتخب به‌عنوان context به مدل داده می‌شوند؛ مدل موظف به پاسخ بر اساس همان‌ها + ارجاع. سیاست «اگر در اسناد نبود، بگو نمی‌دانم»، توهم (hallucination) را مهار می‌کند.
  • Freshness: سند تازه/اصلاح‌شده باید دوباره embed و ایندکس شود — این pipeline (CDC فصل ۱۲ → embed → upsert در Vector DB) قلبِ به‌روز بودن RAG است.

معماری مرجع یک چت‌بات سازمانی

DIAGRAMسرویس گفتگو بر پایه RAG
کلاینت — SSE
API — احراز + rate limit
Router — مدل کوچک/بزرگ
Semantic Cache
Vector DB + فیلتر tenant
LLM — استریم پاسخ
Eval/گاردریل + لاگ

هر اجزا را می‌شناسی: احراز (فصل ۶)، rate limit per-tenant (فصل ۴ + ۱۵)، صف برای کار سنگین embed (فصل ۴)، observability با trace که span های retrieval و generation را جدا نشان می‌دهد (فصل ۱۵)، و SLO برای «زمان اولین توکن» نه فقط پاسخ کامل. AI مسئولیت‌های قدیمی را حذف نمی‌کند؛ به آن‌ها مدل، eval و هزینه توکن را اضافه می‌کند.

به زبان ساده

سرویس LLM یعنی همان سیستم‌دیزاین همیشگی + سه متغیر تازه: هر توکن پول است، خروجی قطعی نیست و context محدود؛ RAG دانش سازمان را هنگام پرسش به مدل تزریق می‌کند.

مثال واقعی

مثل کارمند تازه‌ای که حافظه کوتاهی دارد اما دسترسی به بایگانی: قبل از هر پاسخ، چند سند مرتبط از بایگانی (Vector DB) جلویش می‌گذاری تا از حفظیاتش نگوید.

دانش‌سنجی

آزمون درس

۴ Q
01
Semantic Cache چه چیزی را حل می‌کند که کش معمولی نمی‌تواند؟
02
در RAG ،اندازه chunk بیش از حد درشت چه آسیبی دارد؟
03
مدل گاهی با اطمینان چیز غلط می‌گوید. سه مکانیزم معماری برای مهار؟
04
برای به‌روز نگه‌داشتن پایگاه دانش RAG چه pipeline ای لازم است؟