Silicon Brain | جامعه هوش مصنوعی

برای آموزش LLM بعد از Pretraining تازه وارد بخش جذاب ماجرا می‌شیم جایی که با Post-training یاد می‌گیره واقعاً مثل یک Assistant جواب بده. اول SFT (Supervised Fine-Tuning) انجام می‌شه؛ یعنی مدل با دیتاست‌های instruction/answer آموزش می‌بینه تا به‌جای صرفاً ادامه دادن متن، سؤال رو بفهمه و جواب بده. بعد می‌رسیم به Preference Alignment مثل RLHF. اینجا جواب‌های مختلف رو با هم مقایسه می‌کنیم، ترجیحا از انسان برای اینکار استفاده میشه و باهاشون یک Reward Model می‌سازیم. بر عکس تصور خیلیا، Reward Model خودش RL نیست آموزش اون یک Supervised Learning محسوب می‌شه و فقط یاد می‌گیره به جواب‌ها score بده. بعد از اون، در روش‌هایی مثل RLHF + PPO خود policy با استفاده از rewardها به‌صورت Reinforcement Learning آپدیت می‌شه. مدل جواب تولید می‌کنه، reward می‌گیره و با Policy Gradient سعی می‌کنه احتمال تولید جواب‌های بهتر رو افزایش بده. PPO برای کنترل میزان تغییر policy و جلوگیری از خراب شدن مدل استفاده می‌شه. در کنار این‌ها RLVR (Reinforcement Learning with Verifiable Rewards) قرار داره؛ مخصوصاً برای چیزهایی مثل Math و Code که می‌شه جواب رو به‌صورت خودکار verify کرد. اینجا به‌جای یک Reward Model، خود Verifier/Checker می‌تونه reward بده. @silicon_brain | از هوش مصنوعی عقب نمانید

لایسنس‌های GitHub؛ فقط Public بودن کد کافی نیست یکی از اشتباهات رایج اینه که فکر کنیم وقتی یک پروژه روی GitHub Public هست، پس می‌تونیم کدش رو برداریم، تغییر بدیم و هرجور خواستیم استفاده کنیم. در حالی که چیزی که مشخص می‌کنه دقیقاً چه اجازه‌ای داری، License پروژه‌ست. یکی از معروف‌ترین‌ها MIT License هست: لایسنس MIT تقریباً یکی از آزادترین لایسنس‌هاست و اجازه می‌ده کد رو استفاده، modify distribute و حتی در محصولات تجاری استفاده کنی فقط باید Copyright و متن License رو حفظ کنی. برای همین خیلی از Libraryها و پروژه‌های Open Source از MIT استفاده می‌کنن. لایسنس Apache 2.0 هم از نظر آزادی استفاده شبیه MIT هست: اما جزئیات حقوقی بیشتری داره و یک نکته مهمش بحث Patent هست. به همین دلیل برای پروژه‌هایی که قرار هست در شرکت‌ها و محصولات تجاری استفاده بشن، گزینه محبوبیه. اما GPL داستان متفاوتی داره: لایسنس GPL یک Copyleft License محسوب میشه یعنی اگر کد GPL رو وارد یک پروژه مشتق‌شده کنی و اون پروژه رو منتشر کنی، معمولاً باید کد مربوط به اون تغییرات و مشتقات رو هم تحت GPL منتشر کنی. به زبان ساده، نمی‌تونی خیلی راحت یک پروژه GPL رو برداری، تغییر بدی و بعد کل محصول رو به شکل Closed Source منتشر کنی. در پروژه‌های AI فقط License خود Repository رو بررسی نکن. ممکنه کد پروژه MIT باشه، ولی Model یا Dataset استفاده‌شده License متفاوت و محدودکننده‌ای داشته باشه. پس وقتی می‌خوای یک Open Source project رو وارد Production کنی، باید حداقل License کد، مدل، Dataset و Dependencies رو بررسی کنی. در واقع Open Source یعنی کد، قابل دسترسه؛ نه اینکه بدون هیچ محدودیتی مالک اون کد شدی @silicon_brain | از هوش مصنوعی عقب نمانید

روش تولید واترمارک مخفی توسط LLM برای تشخیص متن های تولید شده با AI ۱. ​ تولید کلید و Hashing همه‌چیز از توکن‌های قبلی شروع میشه. سیستم کلمه (یا توکن) قبلی رو می‌گیره و با یک Secret Key ترکیب می‌کنه تا یک «هش» بسازه. این هش به عنوان Seed (دانه اولیه) به یک مولد اعداد شبه‌تصادفی (PRNG) داده میشه. ۲. ​تقسیم‌بندی دیکشنری (Green/Red Lists) وقتی مدل زبانی می‌خواد کلمه بعدی رو پیش‌بینی کنه، به تمام کلمات دیکشنریش یک احتمال (Logit) میده. اینجا PRNG وارد عمل میشه و کل دیکشنری مدل رو به دو لیست تقسیم می‌کنه: ​لیست سبز (Green List): توکن‌های مجاز ​لیست قرمز (Red List): توکن‌های غیرمجاز ​(این دسته‌بندی استاتیک نیست و برای هر توکنِ جدید، کاملاً عوض میشه!) ​۳. تزریق بایاس (Logit Modification) حالا به جای اینکه مدل کلمه بعدی رو عادی انتخاب کنه، سیستم میاد به امتیازِ کلماتِ لیست سبز، یک مقدار ثابت آماری (به نام delta) اضافه می‌کنه. با این کار، بدون اینکه به گرامر، ساختار منطقی یا خلاقیت متن ضربه بخوره، شانس انتخاب کلمات لیست سبز به شدت بالا میره. ۴. نحوه تشخیص (Detection) حالا اگه بخوایم مچ یک متن رو بگیریم چی؟ کافیه با همون Secret Key متن رو اسکن کنیم. اگه انسان متن رو نوشته باشه، توزیع کلمات سبز و قرمز کاملاً تصادفی (تقریباً ۵۰-۵۰) است. اما تو متنی که LLM تولید کرده، درصد کلمات لیست سبز به شکل غیرطبیعی بالاست! اینجا با یک محاسبه آماری ساده (Z-score)، ثابت میشه که متن قطعا خروجی ماشینه. این روش (به خصوص الگوریتم Kirchenbauer) الان استاندارد طلایی واترمارک متنه و به زودی به عنوان یک لایه امنیتی و اعتبارسنجی استاندارد، پای ثابت تمام فریم‌ورک‌های توسعه LLM میشه. @silicon_brain | از هوش مصنوعی عقب نمانید

تفاوت یک AI Engineer معمولی با یک مهندس با حقوق‌ $200K+ این قسمت: Tool Call یکی از تفاوت‌های مهم، نحوه‌ی ساخت و مدیریت AI workflow هست.یک AI Engineer معمولی ممکنه یک Agent بسازه که برای انجام هر کار، پشت سر هم tool call بزنه، کل چت‌ها و context رو در هر مرحله دوباره وارد prompt کنه و بدون اینکه حواسش به تعداد tokenها، latency و هزینه باشه و بذاره مدل تا هرجا می‌خواد ادامه بده. روی سیستم خودش هم همه‌چیز خوب به نظر میاد چون مهم نیست یک request چند میلیون token مصرف کنه یا ۳۰ ثانیه طول بکشه. اما وقتی وارد production می‌شیم یک مهندس حرفه‌ای به جای اینکه فقط Agent رو سرهم کنه، روی orchestration، state management و execution flow تمرکز می‌کنه. مثلاً با ابزارهایی مثل LangGraph مشخص می‌کنه Agent در هر مرحله چه stateای داره، چه اطلاعاتی باید نگه داشته بشه، چه چیزهایی دیگه لازم نیست داخل context باقی بمونه، چه زمانی باید یک tool اجرا بشه و چه زمانی اصلاً نباید به LLM درخواست جدیدی ارسال بشه. می‌تونه workflow رو طوری طراحی کنه که کارهای ساده با یک small model انجام بشن و فقط taskهای پیچیده به یک frontier model برن. برای بعضی مراحل هم به جای اینکه دوباره LLM رو صدا بزنه، از deterministic logic استفاده می‌کنه. در نتیجهtoken کمتر، latency پایین‌تر، هزینه‌ی inference کمتر و در نهایت یک سیستم قابل پیش‌بینی‌تر خواهد بود. Basic AI Engineer: Prompt → LLM → Tool → LLM → Tool → LLM → ... Production AI Engineer: State → Router → Model/Tool → Validate → Update State → Next Step → ... @silicon_brain | از هوش مصنوعی عقب نمانید

گزارش جدید Stripe از تأثیر AI روی کسب‌وکارها بخشی از داده‌های جدید Stripe نشون می‌ده که در سال ۲۰۲۵، درآمد شش‌ماهه‌ی median استارتاپ‌های تک‌نفره نسبت به سال قبل ۲۳٪ کاهش داشته؛ در حالی که درآمد top 10% حدود ۱۹٪ رشد کرده. جالب‌تر اینکه چهار سال پیش، یک founder در top 10% حدود ۳۴ برابر یک founder معمولی درآمد داشت؛ اما الان این فاصله به حدود ۶۱ برابر رسیده. یعنی AI ورود به بازار رو خیلی راحت‌تر کرده، ولی لزوماً موفق شدن رو راحت‌تر نکرده. امروز ساختن محصول و حتی نوشتن کد داره ارزون‌تر و سریع‌تر می‌شه. بنابراین مزیت رقابتی بیشتر داره می‌ره سمت چیزهایی مثل: distribution، دسترسی به مشتری، brand، domain knowledge، proprietary data و retention. یک نتیجه‌ی دیگه اینه که شاید در سال‌های آینده، دیگه نتونیم صرفاً از روی افزایش تعداد startupها نتیجه بگیریم که به همون نسبت شعل جدید هم ایجاد شده. ممکنه به‌جای اینکه ۲۰ تا شرکت ۵ نفره داشته باشیم، ۱۰۰ تا شرکت یک‌نفره داشته باشیم. البته تیم همچنان مزیت خودش رو داره. طبق داده‌های Stripe، بعد از دو سال، استارتاپ‌های چندبنیان‌گذار موفق در top 10% حدود ۵۳٪ درآمد بیشتری نسبت به نمونه‌های تک‌نفره دارن. پس فعلاً داستان این نیست که «AI قراره شرکت‌ها رو بدون کارمند کنه». اما اتفاق مهم‌تر اینه که سقفی که یک نفر به‌تنهایی می‌تونه بهش برسه، داره به شکل عجیبی بالاتر می‌ره. @silicon_brain | از هوش مصنوعی عقب نمانید

نمایشی از عملکرد پروژه CoretxKG تو این پست در مورد ویژگی های این پروژه گفتم ولی به صورت خلاصه اگه میخوای بدونی: پروژه CortexKG اجازه میده شما با هر مدل LLM با هر Provider که خواستین صحبت کنین و این وسط گراف دانشی از خودتون، شخصیتتون، کاری که میکنین و یا هر اطلاعات دیگه داشته باشین و تو سیستم های دیگه از این دانش استفاده کنین. پروژه به صورت اوپن سورس در گیتهاب: گیتهاب با استار ⭐️ گیتهاب از این پروژه حمایت کنین ❤️

‏Anthropic داره Auto Mode رو به‌عنوان سیستم پیش‌فرض permission در Claude Code معرفی می‌کنه ایده اینه که به‌جای اینکه برای هر shell command، file write یا tool call از کاربر اجازه گرفته بشه، یک AI classifier قبل از اجرای action بررسی کنه که خطرناک هست یا نه. مشکل سیستم قبلی این بود که کاربرها تقریباً به 97٪ permission promptها اجازه می‌دادن و بعد از چند ده درخواست، دقت انسان در تشخیص commandهای خطرناک به حدود 5٪ می‌رسید اما تو حالت Auto Mode، هر action مهم توسط یک سیستم دو مرحله‌ای بررسی می‌شه. یک لایه سریع درخواست رو فیلتر می‌کنه و موارد مشکوک برای بررسی عمیق‌تر فرستاده می‌شن. نتیجه تو تست Anthropic روی 1,053 کاربر، انسان‌ها فقط حدود 13.6٪ از commandهای خطرناک رو تشخیص دادن، در حالی که Auto Mode حدود 89٪ اون‌ها رو block کرد. این سیستم جلوی کارهایی مثل data exfiltration، حذف گسترده فایل‌ها، تغییر permissionها، دستکاری production، نصب SSH key و عبور از trust boundaryها رو می‌گیره. @silicon_brain | از هوش مصنوعی عقب نمانید

‏پروژه CortexKG حافظه‌ی شخصی و قابل انتقال برای مدل‌های زبانی اخیرا این پروژه کار کردم و به صورت اوپن سوریس تو گیتهاب گذاشتم. در واقع CortexKG مکالمات شما رو به یه Knowledge Graph تبدیل می‌کنه یعنی مفاهیم تاریخچه‌ی چت، موجودیت ها، افراد، پروژه‌ها و ارتباط بین اونارو استخراج میکنه و به‌صورت یک گراف دانش ذخیره میکنه. این دانش ساخته شده قابل انتقال هست و تو سیستم های دیگه با LLM های مختلف لوکال مثل Ollama و انحصاری مثل OpenAI و Gemini از این دانش استفاده کنین فیچرهای اصلی • ساخت خودکار Knowledge Graph از مکالمات • نمایش تعاملی گراف و امکان جستجو و بررسی ارتباطات • حافظه‌ی ماندگار برای LLMها • انتقال دانش و حافظه بین مدل‌های مختلف • خروجی و ورودی JSON برای گراف • پشتیبانی از OpenAI، Gemini، Ollama و انواع Provider های دیگه تو این پروژه نقشه از دانشی که توی گفتگوها و شخصیت کاربر شکل گرفته ساخته می‌شه، دانشی که هم قابل مشاهده باشه و هم قابل انتقال، و هم می‌تونه دوباره به مدل تزریق بشه تا مکالمه‌های بعدی با زمینه‌ی بهتری ادامه پیدا کنن. لینک گیتهاب لطفا با استار ⭐️ گیتهاب از این ریپو حمایت کنین ❤️

به‌تازگی OpenAI نتایج مدل منتشرنشده‌ی خودش به اسم Astra رو منتشر کرده؛ مدلی که تونسته ۱۰ مسئله باز ریاضی رو حل کنه مسائلی که بعضی از اون‌ها بیشتر از ۱۰ سال (و حتی چند دهه) بدون جواب مونده بودن. نکته جالب اینه که Astra فقط جواب نداده بلکه اثبات‌های ریاضی رو هم تولید کرده و بعد اون‌ها رو به زبان Lean 4 تبدیل کرده. Lean یه زبان برای Formal Verification هست که اثبات‌های ریاضی رو به‌صورت ماشینی بررسی می‌کنه و مطمئن میشه هیچ خطای منطقی داخلشون وجود نداره. از مهم‌ترین دستاوردهاش میشه به ساخت اولین نمونه صریح از یک Non-Sofic Group، رد کردن Connes's Rigidity Conjecture، ارائه نتایج جدید درباره Sphere Packing و حل چند مسئله مطرح‌شده توسط Paul Erdős اشاره کرد. جالب‌تر اینکه هزینه کل این محاسبات، طبق قیمت API مدل Sol، حدود ۲ هزار دلار بوده؛ یعنی به‌طور میانگین فقط ۲۰۰ دلار برای حل هر مسئله. OpenAI هم تمام جزئیات کار، از جمله یک مجموعه ۲۴۹ صفحه‌ای، روند استدلال مدل و فایل‌های Lean 4 رو منتشر کرده تا همه بتونن نتایج رو بررسی کنن. لینک @silicon_brain | از هوش مصنوعی عقب نمانید

چرا حتی با temperature=0 هم LLM همیشه جواب ثابت نمیده؟ اگه نمیدونی temperature چیه اینجا گفتم خیلی‌ها فکر می‌کنن با temperature=0 خروجی مدل کاملاً deterministic میشه، ولی همیشه این‌طور نیست. یکی از دلیل‌های اصلی، Floating Point Rounding هست. توی ترنسفورمرها میلیاردها عملیات Matrix Multiplication و Attention انجام میشه و به خاطر محدودیت دقت اعداد اعشاری، ترتیب اجرای محاسبات می‌تونه اختلاف‌های خیلی کوچیکی ایجاد کنه. این اختلاف‌ها شاید در حد چند رقم اعشار باشن اما وقتی امتیاز (Logit) دو Token خیلی به هم نزدیک باشه، همین اختلاف جزئی می‌تونه باعث بشه مدل Token متفاوتی انتخاب کنه. از اونجا که تولید متن مرحله‌به‌مرحله انجام میشه، همین تغییر کوچک ممکنه در نهایت خروجی کاملاً متفاوتی بسازه. مواردی مثل CUDA Kernel، Dynamic Batching، Attention یا حتی نسخه مدل هم روی خروجی تأثیر داره. به همین خاطر، توی Production به‌جای انتظار برای خروجی کاملاً یکسان، از Semantic Evaluation، Regression Testing و Model Versioning استفاده می‌کنن تا مطمئن بشن تغییرات مدل واقعاً مشکل‌ساز نیست. @silicon_brain | از هوش مصنوعی عقب نمانید

یکی یه پست گذاشته بود، با تمسخر و خنده می‌گفت: «فاز اون برنامه‌نویسایی که میگن کدهای AI باید Review بشن رو نمی‌فهمم، نیازی به برنامه نویسی و مهندسی کامپیوتر نیست و الکی به اینا پول ندین😅» به نظرم ظهور AI با اینکه کلی فرصت فوق‌العاده ایجاد کرده، یه مشکل جدی هم به وجود آورده؛ اینکه الان بعضی‌ها تو هر حوزه‌ای خودشون رو متخصص می‌دونن. بدون اینکه از مهندسی، معماری، محدودیت‌ها یا حتی اصول اون حوزه شناختی داشته باشن، با اطمینان کامل نسخه می‌پیچن اینکه کسی که برنامه‌نویس نیست از AI استفاده کنه و ایده‌ش رو تبدیل به یه محصول یا Prototype کنه، اتفاقاً خیلی هم خوبه. این دقیقاً یکی از بهترین قابلیت‌های AI هست. مشکل از جایی شروع می‌شه که همون فرد نتیجه می‌گیره: «پس دیگه برنامه‌نویس و مهندس نرم‌افزار لازم نیست» یا « مهندسی و معماری سرویس‌ها بی‌معنیه.» کد فقط این نیست که امروز اجرا بشه. باید قابل نگهداری (Maintainable)، امن (Secure)، مقیاس‌پذیر (Scalable)، قابل تست (Testable) و قابل توسعه هم باشه. خیلی از ایرادها هم اصلاً با یک اجرای موفق مشخص نمی‌شن و ممکنه چند ماه بعد، زیر بار واقعی یا با یک تغییر کوچک خودشون رو نشون بدن. همه ما میدونیم قوی‌ترین AI ها ممکنه کدهای فاجعه بار بزنن. منطقی هم هست چون میخواد به هر شکلی شده نیاز تورو برطرف کنه. این تویی که استاندار‌های فنی رو براش تعریف میکنی و ازش کار میکشی @silicon_brain | از هوش مصنوعی عقب نمانید

فراموش می‌شوی گویی که هرگز نبوده‌ای @silicon_brain | از هوش مصنوعی عقب نمانید

یکی از مهم‌ترین بخش‌های هر شبکه عصبی، Activation Function هست. اگه بین لایه‌ها فقط عملیات خطی (Linear) انجام بشه، حتی اگه هزار تا لایه هم باشه، کل شبکه معادل یه لایه ساده میشه و چیزی یاد نمی‌گیره. اینجاست که Activation Functionهایی مثل ReLU، Sigmoid و Tanh وارد میشن. با اضافه کردن Non-linearity باعث میشن مدل بتونه الگوهای پیچیده، مرزهای غیرخطی و روابط بین داده‌ها رو یاد بگیره مثلاً توی پردازش زبان، کلمه‌ای مثل "flies" بسته به Context می‌تونه فعل یا اسم باشه. به کمک چندین لایه و Activation Function، مدل کم‌کم معناهای مختلف رو از هم جدا می‌کنه و درک عمیق‌تری از جمله به دست میاره. از نظر تئوری هم Activation Function غیرخطی که استفاده میشه، اگه به اندازه کافی بزرگ باشه، می‌تونه تقریباً هر تابع پیوسته‌ای رو یاد بگیره. البته این قضیه فقط ثابت می‌کنه چنین مدلی وجود داره نه اینکه آموزش دادنش راحت باشه در واقع، Activation Function همون چیزی هست که یه شبکه عصبی رو از یه ماشین حساب خطی به مدلی تبدیل می‌کنه که می‌تونه تصاویر، متن، صدا و الگوهای بسیار پیچیده رو یاد بگیره. @silicon_brain | از هوش مصنوعی عقب نمانید

خوندن کل این کتاب حدود ۳ ساعت وقت می‌گیره @silicon_brain | از هوش مصنوعی عقب نمانید

خیلیا فکر می‌کنن ساختن AI Agent فقط به Prompt Engineering مربوطه، ولی در عمل چهار لایه مهم وجود داره: Prompt Engineering: نوشتن Prompt مناسب، تعیین Role، دادن Example و مشخص کردن Format خروجی مثل JSON. Context Engineering: مدیریت اطلاعاتی که به مدل می‌رسه؛ مثل RAG، Memory، تاریخچه چت و خروجی Toolها. چون Context Window محدوده، باید فقط اطلاعات مهم وارد مدل بشه. Harness Engineering: کدی که دور مدل نوشته میشه؛ مدیریت Tool Calling، Retry، Validation، تقسیم کار بین Sub-Agentها و بررسی صحت خروجی. Loop Engineering: مهم‌ترین بخش Agentها. به جای اینکه کاربر هر مرحله Prompt جدید بده، Agent خودش داخل یک while loop کار می‌کنه، Tool صدا می‌زنه، نتیجه رو بررسی می‌کنه و تا رسیدن به هدف ادامه میده. برای جلوگیری از گیر کردن هم از Token Limit، Max Iteration و Completion Check استفاده میشه. به طور خلاصه، یه AI Agent فقط یه Prompt خوب نیست؛ ترکیب Prompt Engineering + Context Engineering + Harness Engineering + Loop Engineering هست که باعث میشه بتونه به‌صورت خودکار، پایدار و قابل اعتماد کارهای پیچیده رو انجام بده. @silicon_brain | از هوش مصنوعی عقب نمانید

دنياى توسعه نرم‌افزار وارد فازى شده كه ساختن يك محصول اوليه (MVP) به لطف وایب کدینگ و ابزارها، مولد كد، به جای چند هفته، فقط چند ساعت زمان ممکنه ببره خیلیا خوشحالن از این موضوع بنيانگذاران، مديران محصول و سرمايه‌گذارها اما زير اين پوسته براق و سريع، يك واقعيت تلخ در حال شكل‌گيرى هست: انبوهى از محصولات سريع اما بی‌كيفيت، ناامن و ناپايدار تو سطح پروداکت که هزینه زیادی برای رسیدن به حالت نرمال و پایدار لازم دارن نظر شما چیه؟ @silicon_brain | از هوش مصنوعی عقب نمانید

‏Moonshot AI بالاخره وزن های مدل Kimi K3 رو منتشر کرد یک مدل Mixture-of-Experts (MoE) با 2.8 تریلیون پارامتر که به گفته این شرکت، اولین مدل Open-Weight در کلاس 3T دنیاس. این مدل از تصویر به‌صورت Native پشتیبانی می‌کنه، 1M Token Context Window داره و از…

یک سوال مهم مصاحبه مهندسی نرم افزار و AI: اگر بار روی Database خیلی زیاد بشه، چه راه‌حل‌هایی پیشنهاد می‌دی؟ پاسخ این سؤال فقط Redis نیست. معمولاً چندین راهکار وجود داره که بسته به نوع مشکل ازشون استفاده می‌کنیم: استفاده از Redis (Caching) اولین راهکار، اضافه کردن یک Cache Layer مثل Redis هست. اگر یک Query بارها تکرار می‌شه (مثلاً اطلاعات محصولات یا پروفایل کاربران)، به جای اینکه هر بار از Database خونده بشه، داخل Redis ذخیره می‌شه. این کار می‌تونه تعداد زیادی از درخواست‌های Read رو از روی Database برداره. استفاده از Read Replica اگر تعداد درخواست‌های Read خیلی زیاد باشه، می‌شه از Read Replica استفاده کرد. در این حالت یک Primary Database داریم که عملیات Write روی اون انجام می‌شه و چندین Replica که فقط درخواست‌های Read رو پاسخ می‌دن. این روش باعث می‌شه بار خواندن بین چند سرور تقسیم بشه. روش Database Sharding اگر حجم داده‌ها خیلی بزرگ بشه، یک Database به تنهایی جوابگو نیست. در Sharding داده‌ها بین چند Database تقسیم می‌شن؛ مثلاً کاربران بر اساس User ID یا منطقه جغرافیایی روی سرورهای مختلف ذخیره می‌شن. این روش مقیاس‌پذیری بالایی داره، ولی مدیریت و پیاده‌سازی اون پیچیده‌تره. روش Queue و پردازش Asynchronous همه درخواست‌ها لازم نیست همون لحظه داخل Database ثبت بشن. کارهایی مثل ارسال ایمیل، ثبت لاگ یا پردازش گزارش‌ها رو می‌شه داخل Message Queueهایی مثل RabbitMQ یا Kafka قرار داد تا به‌صورت Asynchronous انجام بشن و فشار لحظه‌ای روی Database کم بشه. روش Connection Pooling اگر هر درخواست یک اتصال جدید به دیتابیس ایجاد کنه، خود این اتصال‌ها تبدیل به گلوگاه می‌شن. استفاده از Connection Pool باعث می‌شه اتصال‌ها دوباره استفاده بشن و هزینه ایجاد Connection جدید از بین بره. راه حل آخر Scale Up یا Scale Out اگر همه راهکارهای بالا کافی نباشن، می‌شه منابع سرور رو افزایش داد (Vertical Scaling) یا چندین Database و سرور جدید اضافه کرد (Horizontal Scaling). در عمل، سیستم‌های بزرگ مثل Instagram، Netflix یا Amazon معمولاً از ترکیب چند راهکار استفاده می‌کنن؛ مثلاً Redis برای Caching، Read Replica برای توزیع بار Read، Sharding برای مدیریت حجم زیاد داده و Message Queue برای پردازش‌های غیرهمزمان. این ترکیب باعث می‌شه سیستم هم سریع‌تر باشه و هم در برابر افزایش تعداد کاربران مقیاس‌پذیر باقی بمونه. @silicon_brain | از هوش مصنوعی عقب نمانید