⛏ انواع استراتژی‌های تاب‌آوری نرم‌افزار (Resiliency Strategy)

مفهوم Resiliency یا تاب‌آوری، به توانایی یک سیستم برای بازیابی شرایط پایدار در صورت بروز خطا گفته می‌شه. حالا این بازیابی می‌تونی تلاش برای بازیابی باشه، یا انتخاب راه جایگزین. مثل اینکه شما ۲ بار تلاش می‌کنی از API آب‌وهوا مقدار دمای فعلی یک منطقه رو بگیری، هر بار با فاصله زمانی ۵ ثانیه API رو صدا می‌زنی ولی بعد از اینکه پاسخ موفق نمی‌گیری (تا اینجا به این می‌گن استراتژی retry) بعد تصمیم می‌گیری از cache آخرین مقداری که کم‌تر از ۵ ساعت گذشته وجود داشته رو استفاده کنی که فعلا کار راه بیوفته (استراتژی fallback) یا ... به هر کدوم از این رفتارها برای تداوم کار و مقابله با موانع، می‌گن resiliency strategy.

کتابخونه Polly محبوب‌ترین در بین دات‌نتی‌هاست. و تو دل Aspire هم ازش استفاده شده، برای درک بهتر ویدیوی Aspire که به زودی پابلیش می‌شه، خوبه یه مرور روی انواع استراتژی‌ها کنیم...
—————————
دو گروه اصلی داریم:

⚙️گروه استراتژی‌های Reactive (واکنشی)
وقتی به کار می‌رن که یک خطا یا مشکلی رخ داده و سیستم باید به شکلی واکنش نشون بده.

🛡 ۱: استراتژی Retry
فرضیه: خطاها موقتی هستن و ممکنه با کمی تأخیر و تلاش مجدد برطرف بشن.

در این استراتژی، سیستم تلاش می‌کنه که یک عملیات ناموفق رو بعد از یک بازه‌ی زمانی مشخص دوباره امتحان کنه. این بازه زمانی می‌تونه ثابت یا متغیر باشه (مثل Exponential Backoff). مثلاً اگر سرور موقتی قطع شده باشه، با چند بار Retry ممکنه مشکل حل بشه. در Polly، این با “Retry Policy” قابل پیاده‌سازی است. و تعداد دفعات و بازه زمانی بین هر تلاش به تصمیم ما وابسته است.

🛡 ۲: استراتژی Circuit-Breaker
فرضیه: وقتی سیستم به شدت دچار مشکل می‌شه، بهتره سریعاً فرآیندها متوقف بشن به جای اینکه کاربران منتظر بمونن.

چطور کمک می‌کنه؟ مدار رو قطع می‌کنه (اجرای درخواست‌ها رو متوقف می‌کنه) در زمانی که خطاها از حدی مشخص بیشتر می‌شن (مثل وقتی می‌فرسته به صف ولی هِی روی هم انباشت می‌شه و از اون طرف پردازش نمی‌شن)

شبیه به فیوز برق که اگر بیش از حد فشار وارد بشه، مدار رو قطع می‌کنه. این استراتژی به سیستم اجازه می‌ده برای مدتی مشخص درخواست‌ها رو به مقصد ارسال نکنه تا از خرابی‌های بیشتر جلوگیری بشه. مثلاً در Polly می‌تونید مدت‌زمانی که Circuit باز می‌مونه و شرایط بازگشت به حالت نرمال رو تنظیم کنیم.

🛡 ۳: استراتژی Fallback
فرضیه: خطا تداوم خواهد داشت؛ پس برای پلن B برنامه‌ریزی می‌کنیم.

چطوری کمک می‌کنه؟ یک مقدار یا راه حل جایگزین در صورت بروز یا تداوم خطا ارائه می‌ده.

وقتی یک عملیات شکست می‌خوره، به جای نمایش خطا به کاربر، یک نتیجه جایگزین برمی‌گرده. مثلاً به جای اینکه پیام “سرور API در دسترس نیست” نمایش داده بشه، می‌تونید یک مقدار ذخیره شده از کش رو ارائه بدید.

🛡 ۴: استراتژی Hedging
فرضیه: گاهی اوقات برخی مسیرها شاید کند یا حتی ناموفق باشن؛ پس بهتره چندین راه برای رسیدن به هدف در نظر بگیریم، هر کدوم زودتر جواب داد، همون.

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

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

⚙️گروه استراتژی‌های Proactive (کنشگر)
این استراتژی‌ها برای پیشگیری از بروز مشکلات در سیستم طراحی شده‌اند.

🛡 ۱: استراتژی Timeout
فرضیه: بعد از مدت زمانی مشخص، موفقیت بعیده.

چطوری کمک می‌کنه؟ تضمین می‌کنه که درخواست‌ها بیشتر از زمان مشخص منتظر نمی‌مونن.

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

🛡 ۲: استراتژی Rate Limiter
فرضیه: محدود کردن تعداد درخواست‌هایی که سیستم در یک بازه زمانی مشخص می‌پذیره (راهی برای کنترل بار ورودی).

چطوری کمک می‌کنه؟ اجرای درخواست‌ها رو محدود می‌کنه تا از حد مشخصی فراتر نره.

برای جلوگیری از بار زیاد روی سیستم، این استراتژی تعداد درخواست‌ها در یک بازه زمانی مشخص رو محدود می‌کنه. مثلاً اگر کاربران زیادی همزمان به سیستم درخواست بفرستن، Rate Limiter می‌تونه از خرابی جلوگیری کنه.

—————————

ما می‌تونیم از یک یا ترکیبی از چند استراتژی برای افزایش تاب‌آوری سیستم‌هامون استفاده کنیم.

🔗 رفرنس جهت مطالعه عمیق‌تر

💬 نظر؟ تجربه؟ سوال؟

🍉 مطلب ویژه برای شبی که 1️⃣ دقیقه بیشتر برای فکر کردن وقت داریم...

مفهومی داریم به نام Cargo Cult Practices که به رفتارها یا فرآیندهایی اشاره داره که به‌طور «سطحی» شبیه به رفتارهای موفق و موثر هستن، اما «بدون درک عمیقی» از دلیل یا اصول اساسی‌ای که پشت اون رفتارها و انتخاب‌ها وجود داره...

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

اصطلاح "کارگو کالت" در زمینه‌های مختلف برای توصیف تقلید ظاهری از یک عمل، بدون درک عمیق از مکانیزم‌های واقعی او‌ها به کار می‌ره، به‌ویژه در حوزه‌هایی مثل مدیریت و توسعه نرم‌افزار.

استفاده از فلان معماری یا فلان زبون یا فلان ساختار تیمی چون فلان شرکت استفاده کرده، از همین مصادیقه... توی فرهنگ ما ضرب‌المثل «مرغی که انجیر می‌خوره نوکش کجه» مترادف با همینه...

👀 چند پیشنهاد مقدماتی برای ساختن تیم بهتر؛ به جای تمرکز روی تقلید رفتارهای شرکت‌ها و تیم‌های دیگه روی یک چیز تمرکز کنیم:

⚡️ ساختن فرهنگ و فرایند «متناسب» با نیازها و بضاعتمون، و به کارگیری ابزار مناسب براش... ⚡️

و بعدش:

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

✔️ یه فضایی درست کن که برنامه‌نویس‌هات احساس مسئولیت کنن، بتونن مستقل کار کنن و راحت با هم‌تیمی‌هاشون حرف بزنن. نذار حس کنن دارن زیر میکروسکوپ کار می‌کنن.

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

✔️ این افسانه برنامه‌نویس ده برابری (10x programmer) رو باور نکن! معمولاً اونایی که خیلی خوبن، تو یه زمینه خاص تخصص دارن، نه اینکه تو همه چیز استاد باشن.

✔️ موقع استخدام نیروی جدید، از همون اول درست بهشون یاد بده که چطور باید با بقیه ارتباط بگیرن و مسئولیت‌پذیر باشن. نذار عادت‌های بد از همون اول شکل بگیره.

یلدای همگی مبارک و امیدوارم در کنار خانواده و عزیزانتون سلامت و شاد و موفق باشین 😉

👀 ورک‌لود توی دات‌نت چیه؟
ورک‌لود‌های دات‌نت مجموعه‌ای از اجزای اختیاری SDK هستن که برای توسعه انواع خاصی از برنامه‌ها مورد استفاده قرار می‌گیرن. به زبون ساده‌تر، به جای نصب یک SDK بزرگ که همه چیز رو شامل بشه، می‌تونیم فقط اجزای مورد نیاز برای پروژه خودمون را نصب کنیم.

مثال: 🔤aspire 🔤یا macos یا tvos یا maui-tizen


✍️ تاریخچه و دلیل ایجاد ورک‌لود‌ها
توی نسخه‌های قبل از دات‌نت ۵، تمام قابلیت‌ها در قالب یک SDK یکپارچه (مونولیتیک) ارائه می‌شد. این رویکرد مشکلات متعددی داشت:

- حجم زیاد SDK و مشکلات توزیع
- زمان طولانی ساخت محصول
- پیچیدگی توی مدیریت و به‌روزرسانی
- مصرف منابع غیرضروری توی محیط‌ CI/CD

📌 اهداف اصلی معرفی ورک‌لود‌ها
مایکروسافت با معرفی ورک‌لود‌ها، چند هدف کلیدی رو دنبال کرد:

- امکان دانلود انتخابی قابلیت‌های مورد نیاز (مثلاً فقط ASP.NET Core یا فقط Xamarin)
- ساده‌سازی پیکربندی برای محیط‌های CI/CD
- ارائه پیام‌های خطای مفید هنگام نبود ورک‌لود مورد نیاز
- قابلیت نصب خودکار ورک‌لود‌ها بر اساس فایل پروژه
- امکان به‌روزرسانی ورک‌لود‌ها بدون نیاز به نصب نسخه جدید SDK (مثلا aspire رو به‌روز کنیم مستقل از سایر SDKها)

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

*️⃣مانیفست: فایلی که ورک‌لود و اجزاش رو توصیف می‌کنه
*️⃣پک‌ها: مجموعه فایل‌های فشرده‌شده شامل ابزارها، کتابخونه‌ها و منابع مورد نیاز

⌛ شروع به کار:
برای دیدن لیست ورک‌لودها و انتخاب از بینشون:

dotnet workload search

یا برای آپدیت کردن ورک‌لودها:

dotnet workload update

یا مثلا وقتی می‌خواین ورک‌لود لازم برای ساختن نرم‌افزار روی تلویزیون سامسونگ مجهز به تایزن رو نصب کنین:

dotnet workload install maui-tizen

🛫 آینده ورک‌لود‌ها
طبق برنامه مایکروسافت، در آینده:

*️⃣تمام قابلیت‌های دات‌نت (از جمله WPF و Windows Forms) به صورت ورک‌لود ارائه خواهند شد
*️⃣امکان نصب و مدیریت از طریق مدیریت‌کننده‌های بسته لینوکس فراهم می‌شه
*️⃣ابزارهای CLI برای مدیریت ورک‌لود‌ها گسترش پیدا می‌کنن

🚀 مدیریت نسخه‌های ورک‌لود با Workload Sets
یکی از ویژگی‌های مهم که از دات‌نت ۸.۰.۴۰۰ معرفی شد، قابلیت Workload Sets بود. این قابلیت به ما امکان می‌ده مجموعه‌ای از ورک‌لود‌ها رو با یک شماره نسخه مشخص مدیریت کنیم.

مزایای استفاده از Workload Sets

- کنترل بهتر روی نسخه‌های نصب شده
- اطمینان از سازگاری ورک‌لود‌ها با همدیگه
- همگام‌سازی آسون‌تر نسخه‌ها توی تیم توسعه
- مدیریت ساده‌تر به‌روزرسانی‌ها

مثال کاربردی:

dotnet workload install aspire --version 9.0.100-preview.7.24414.1


dotnet workload config --update-mode workload-set

حتی می‌تونیم توی global.json هم درجشون کنیم:

{
  "sdk": {
    "workloadVersion": "9.0.200-preview.0"
  }
}

🧮جمع‌بندی
ورک‌لود‌های دات‌نت نشونه‌ی تکامل طبیعی پلتفرم و حرکت به سمت ماژولار شدن هرچه بیشترش هستن. و این رویکرد به ما این امکان رو میده تا محیط توسعه‌مون رو بهینه‌تر و سبک‌تر نگه داریم و فقط ابزارهای مورد نیازمون رو نصب کنیم.

و NET Aspire. اساسا بر پایه‌ی workloadها بنا شد و چابکی خودش رو وامدار workloadها است، و با رهانش (release)های مستقل از دات‌نت خودش رو مرتب بهبود داده تا امروز...


امیدوارم این مطلب به درک بهتر ورک‌لود کمک کرده باشه و بتونه به عنوان خونه‌های پازل کمک کنه تا Aspire رو بهتر درک کنید.

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

💬 اگر سوالی دارید، حتماً طرح کنید!

✨ اندر باب OpenTelemetry

از اونجایی که دورهمی بعدی‌مون در مورد سیستم‌های توزیع‌شده است، مطالب دیروز (workload) و این مطلب (OpenTelemetry) پیش‌درآمدی است برای دوستانی که آشنایی کمتری دارن ولی دوست دارن از دورهمی استفاده بیشتری ببرن.

به زبون ساده و تا حد امکان کوتاه، OpenTelemetry رو توضیح دادم و Log, Metric و Trace مرور کردم. اگر دوست داشتید مطالعه کنید (instant view تلگرام دسکتاپ مشکلاتی با فارسی داره که اگر روی دسکتاپ مطالعه می‌کنید بهتره تا لینک رو باز کنید)

📎 لینک مطلب

💬 نظر، سوال، گپ‌ و گفت؟ 😉

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

لذا طیف وسیعی از ابزارهای اتوماسیون برای کارهای مختلف وجود داره، یکی از مهم‌ترین‌هاش هم ابزارهای خودکارسازی بیلد و دپلوی است. ابزارهای Build Automation از فایل‌های XML که برای استفاده از MS Build سال‌ها پیش می‌ساختیم تا فایل‌های Yaml که برای GitHub یا GitLab می‌سازیم؛ وقتی مراحل بیلد، پیچیده و متعدد می‌شدن؛ نوشتن، ایرادیابی و مدیریت فایل Yaml سخت‌تر می‌شه.
حتی توی پروژه‌ها و تیم‌های کوچیک هم شاید یادگیریش برای دولوپر تازه‌کار دشوار باشه.

درسته که افزونه‌هایی بروی سهولت نوشتنشون در دسترس هست؛ ولی بیاین فکر کنیم اگر توی فایل #C با متدها و کلاس‌هایی که AutoComplete و... خیلی خوبی هم دارن، بهتر نیست؟ خوندن داینامیک مقادیر و تصمیم‌گیری راحت‌تر نیست؟ دیباگ کردن راحت‌تر نیست؟

پروژه Nuke.Build و Cake همینه! یه پروژه رایگان کدباز با لایسنس MIT که با همه CI/CDهای رایج GitHub GitLab CI, Azure Pipelines, Actions و... هم سازگاره.

🧐 حالا یه سوال جدی؟ آیا «امروزه، عصر، عصر مهاجرت به Nuke است و با مهاجرت به آن موفقیت را در دستان خود بگیریم و به پوست شفاف‌تر، زندگی شاداب‌تر و گوارش بهتر دست یابیم!» است؟

خیر! nuke با ۳۱۰۰ ستاره در گیت‌هاب و cake با ۳۹۰۰ ستاره، پروژه‌های بدی نیستن، برای پروژه‌های کوچک، و یا جایی که دانش یا نیروی کافی برای DevOps نداریم، و یا نیازهای خاصی داریم که با Yamlنویسی نگهداری و توسعه‌اش سخت می‌شه (پایپ‌لاین‌های خیلی پویا)، باز هم خوبن. ولی اینکه از فردا روش‌های native رو بگذاریم کنار و بدون دلیل منطقی و حساب‌شده بیوفتیم دنبال اینا هم کار ابلهانه‌ای است 😁 خودکارسازی خوبه، آشنایی با ابزارها خوبه، انتخاب با آگاهی و بجا از جفتش بهتره 😉

💬 تجربه شما چیه؟ با چه روش یا ابزاری build automation می‌کنین؟

🧠 مروری بر Semantic Kernel، نرم‌افزار، ولی باهوش!

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

مایکروسافت هم که به لطف سرمایه‌گذاری‌های هوشمندانه‌ای که روی استارتاپ‌ها و شرکت‌های مستعد داشته، اوضاع خیلی خوبی داره. یادمون نره همون‌طور که برنامه‌نویسی وب یا معماری سرویس‌گرا، ۲۵ سال پیش چیزهای مدرنی بودن ولی الان بدیهی و پیش‌پا افتاده به شمار میان؛ استفاده از AI توی نرم‌افزارها هم تا چند وقت دیگه (خیلی خیلی کمتر از ۲۵ سال، حتی کمتر از ۵ سال دیگه) یه موضوع بدیهی خواهد بود.

🎅 دو تا خاطره توی کامنت این مطلب می‌گذارم (خاطره است و اگر نخونید چیزی از مطلب رو از دست ندادید)

البته منظورم چپوندن زورکی و شوآف نیست، بلکه چیزی برای تسهیل نیازهای کاربر نهایی و ارتقاء عملکرد خود سیستمه.

کتابخونه‌ Semantic Kernel که فقط هم برای دات‌نتی‌ها نیست و پایتون و جاوا رو هم پشتیبانی می‌کنه؛ یک کتابخونه‌ی متن‌بازه که به عنوان میان‌افزار (middleware) عمل می‌کند.

❓یعنی چی؟ یعنی این کتابخونه به توسعه‌دهنده کمک می‌کنه تا به سادگی مدل‌های هوش مصنوعی مختلف رو با کدهای موجودش ترکیب کنه و عامل‌های هوشمند (AI agents) بسازه، (بدون داشتن درک عمیق از دل و روده‌ی AI یا LLM)

❓ یکم بیشتر؟ چشم. مثلا شما می‌خواهید از مدلی که یه بابایی یا یه شرکتی، رایگان یا پولی، روی کامپیوتر خودتون یا روی کلاد، وجود داره و مثلا بهش یه متن می‌دید و می‌گید با صدای فلان خواننده بخونه؛ یا یه متن می‌دید می‌گید یه عکس بر اساسش بسازه؛ یا سوال و جواب عادی؛ یا سوال و جوابی که مبنای پاسخش دیتای توی دیتابیس شماست؛
مثلا شما یه نرم‌افزار سنتی فروشگاه آنلاین لباس داری؛ کاربر می‌گه برام یه ست لباس مهمونی برای فصل پاییز و سقف قیمت فلان، برای یک خانم ۳۰ ساله با سایز M پیشنهاد کن، این یه متنه، ولی Semantic Kernel این امکان رو می‌ده به راحتی از دل دیتای ساختار یافته دیتابیس، فرض کنید جدولی که نام کالا، قیمت، رنگ و سایز رو داره، کوئری مورد نیاز رو بسازه. چجوری؟ با دیتایی که توی مدل زبانی داره می‌فهمه رنگ‌های مناسب با پاییز، یا نوع لباس‌های مورد نیاز برای یک مهمانی (شلوار، پیراهن، پالتو، کفش، شال‌گردن برای پاییز و یک خانم نیازه) اینا رو از دل دیتابیس می‌کشه بیرون و متن هم از نتیج خروجی که احتمالا یه لیست از آبجکت کالا است بسازه که: فلانی‌جون اگر اینو اونو اون‌یکی رو ست کنی برای پاییز خوبه و به بودجه‌ات هم می‌خوره!

🧞‍♂️ این یه روزی جادو بود، یه روز رویا بود، یه روز محال بود؛ الان با وجود امکانات ساختاری وکتورها و کتابخونه‌ها به راحتی شدنیه، حتی با تغییرات کم در کدهای فعلی!

این Semantic Kernel در حقیقت یه پُله بین دنیای برنامه‌نویسی سنتی و مدل‌های زبانی بزرگ (LLM).
فعلا هم با زبون‌های C#، Python و Java قابل استفاده است. یه لایه‌ی میانی که درخواست‌های مدل‌های AI رو به توابع تعریف‌شده توی کد ترجمه می‌کنه و پاسخ‌ها را مدیریت می‌کنه (تبدیل متن به یه کلاس، و ساخت متن با استفاده از دیتای ساختاریافته).

مدل‌های هوش مصنوعی مثل GPT و DALL-E و… تحول بزرگی توی نحوه تعامل ما با نرم‌افزار ایجاد کردن. اما استفاده از این مدل‌ها توی محیط‌های واقعی چالش‌هایی هم داره:
🔤 مدیریت درخواست‌ها: چجوری درخواست‌های پیچیده کاربر رو به توابع کدنویسی ترجمه کنیم؟ (مثلا ورودی‌های متد GetProductsByDescription)

🔤 اتصال به سیستم‌های موجود: چجوری هوش مصنوعی با APIها، دیتابیس‌ها، یا فرآیندهای کسب‌وکاری تعامل داشته باشه؟

🔤 امنیت و مقیاس‌پذیری: چجوری میشه این قابلیت‌ها رو به‌صورت ایمن (جلوگیری از نشت اطلاعات یا دسترسی به داده‌هایی که نباید بهش دسترسی داشته باشع) و توی مقیاس بزرگ ارائه کرد؟

و Semantic Kernel برای پاسخ به این چالش‌ها طراحی شد؛ و هدفش ساده‌سازی یکپارچه‌سازی هوش مصنوعی در پروژه‌های واقعیه.

👀 چی کار می‌شه باهاش کرد حالا؟
- ایجاد ربات‌ها و عامل‌های هوشمند: مثل چت‌بات‌هایی که به‌صورت پویا تصمیم می‌گیرن یا فرآیندها رو خودکار می‌کنن.

- یکپارچه‌سازی آسون با کد موجود: با استفاده از قابلیت Function Calling، می‌شه مدل‌های AI رو به کدهای موجود متصل کرد.

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

- مدیریت آسون هوش مصنوعی: فراهم کردن قابلیت مشاهده و نظارت بر عملکرد مدل‌های مختلف.

- اتصال به مدل‌های مختلف AI (مثل OpenAI، یا مدل‌هایی که روی ماشین خودتون دارید)

- پشتیبانی از Vector Store‌ها


✨ اگر دوست دارید این موضوع ادامه بدم:
ری‌اکشن 🤓