بازگشت به کتابخانهکتابخانه16.2سیستم‌های ML و جستجوی برداری
طراحی سیستم نرم‌افزاری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.2فصل ۱۶طراحی سیستم در عصر AI

سیستم‌های ML و جستجوی برداری

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

فراتر از LLM: هر محصولی که «تصمیم با داده» می‌گیرد — پیشنهادگر، تشخیص تقلب، جستجو — یک سیستم ML است با چرخه عمر: داده → ویژگی → آموزش → سرو → بازخورد. این درس همان چرخه را به زبان سیستم‌دیزاین می‌گوید.

Feature Store: قرارداد بین آموزش و سرو

  • مسئله: ویژگی «میانگین خرید ۳۰ روز اخیر کاربر» باید در آموزش (آفلاین، روی تاریخچه) و در سرو (آنلاین، در میلی‌ثانیه) یکسان محاسبه شود؛ وگرنه training-serving skew مدل را خراب می‌کند.
  • راه‌حل: Feature Store با دو سطح — آفلاین (lake/warehouse برای آموزش دسته‌ای) و آنلاین (KV کم‌تأخیر مثل Redis/Dynamo برای سرو هم‌زمان) — با تعریف ویژگی یک‌بار و یکسان برای هر دو.
  • Point-in-time correctness: هنگام ساخت دیتاست آموزش، ویژگی‌ها باید «تا لحظه رویداد» محاسبه شوند، نه با داده امروز — وگرنه نشتی از آینده (leakage) مدل را دروغین خوب نشان می‌دهد.

دیتابیس برداری و ANN

Embedding
نگاشت متن/تصویر/کاربر به برداری در فضای چندصدهُبُعدی؛ «نزدیکی» = شباهت معنایی. مدل embed باید بین ایندکس و کوئری یکی باشد وگرنه فضاها قابل مقایسه نیستند.
ANN — HNSW
گراف چندلایه که با پرش‌های محلی همسایه نزدیک را پیدا می‌کند: رایج‌ترین ایندکس؛ تطبیق حافظه/سرعت/دقت با پارامترها. جایگزین‌ها: IVF (خوشه‌بندی)، quantization (فشرده‌سازی بردارها برای حافظه).
فیلتر متادیتا
در عمل جستجو همیشه با قید است (tenant ،زبان، موجودی): یا pre-filter یا post-filter — انتخابش روی recall اثر دارد؛ موتورهای مدرن (pgvector ،Qdrant ،Milvus ،Elasticsearch kNN) هر دو را بهینه کرده‌اند.

سرو و بازخورد

  • دو مسیر پیش‌بینی: آنلاین (real-time ،p99 میلی‌ثانیه‌ای، کش ویژگی و حتی کش نتیجه) در برابر دسته‌ای (امتیازدهی شبانه به همه کاربران، ذخیره در KV برای سرو سریع — پیشنهادگرهای چرخه‌آرام همین‌طور‌اند).
  • کنیبالیزه نشدن: نسخه جدید مدل با shadow traffic (فصل ۱۴، تست) یا A/B واقعی سنجیده می‌شود؛ متریک محصول (کلیک/خرید) حرف آخر است نه فقط متریک مدل (accuracy).
  • حلقه بازخورد: رفتار کاربر (کلیک، نادیده‌گرفتن) داده آموزشی بعدی است — یعنی pipeline ایونت (Kafka فصل ۴) → پردازش → دیتاست. همین حلقه، سیستم را زنده نگه می‌دارد — و drift را معنی می‌دهد: وقتی توزیع داده زنده از داده آموزش دور شود، کیفیت بی‌صدا می‌میرد؛ پس مانیتورینگ drift (فصل ۱۵) جزئی از سرویس است.
DIAGRAMچرخه ML در production
ایونت‌ها — Kafka
پردازش + Feature Store
آموزش — آفلاین
Registry — نسخه مدل
سرو — آنلاین + کش
نتیجه محصول — بازخورد

به زبان ساده

سیستم ML یعنی چرخه دائمی: داده → ویژگی → آموزش → سرو → بازخورد؛ و Feature Store تضمین می‌کند «میانگین خرید ۳۰ روز» در آموزش و سرو یکی محاسبه شود.

مثال واقعی

مثل آشپزی با دستور ثابت: اگر مواد در تمرین (آموزش) با ترازوی گرم و در رستوران (سرو) با ترازوی اونس وزن شود، طعم غذا فرق می‌کند — همان training-serving skew.

دانش‌سنجی

آزمون درس

۴ Q
01
training-serving skew از کجا می‌آید؟
02
data leakage هنگام ساخت دیتاست یعنی؟
03
برای سرو پیش‌بینی میلی‌ثانیه‌ای به ۵۰ میلیون کاربر، کدام ترکیب معقول است؟
04
drift چیست و چطور مهار می‌شود؟