DevTwitter | توییت برنامه نویسی
#کوته_نیوز مدیرعامل آنتروپیک(Claude): هوش مصنوعی تا یکسال آینده درِ برنامهنویسها میذاره و میفرستتشون باغبونی. @DevTwitter
کنتور که نمیندازه، منم به نظرم تا یه سال دیگه ربات ها قیام میکنن، نسل بشریت کارش تموم میشه!
🤣6🔥2👾1
Forwarded from Delpak Log
ورنه خاموش است و خاموشی...
تیمی را میتوان بهرهمند از امنیت روانی (Psychological Safety) دانست که اعضایش احساس کنند میتوانند آزادانه نظراتشان را بیان کنند، سؤال بپرسند، اشتباهات خود را بپذیرند و ایدههای جدید مطرح کنند، بدون ترس از سرزنش، تمسخر یا تنبیه.
این مفهوم ابتدا توسط پروفسور دانشکده کسبوکار هاروارد، اِمی ادموندسون (Amy C. Edmondson) در دهه نود میلادی مطرح شد، اما تحقیقات اخیر نشان دادهاند که در عصر پرشتاب تحولات دیجیتال، اهمیت آن بیش از پیش افزایش یافته است.
در مطالعهای که در سال ۲۰۲۳ انجام شد پژوهشگران (کلارک و گروس)، از طریق بررسی دادههای جمعآوریشده از ۴۸ تیم نرمافزاری در شرکتهای فعال در حوزه فناوری دریافتند که تیمهایی با سطح بالای ایمنی روانی، تا ۳۵ درصد بهرهوری بیشتری در حل مسائل پیچیده و نوآورانه از خود نشان میدهند.
از دیدگاه دیگر، این بدان معناست که تیمهایی که فاقد این مولفه حیاتی باشند، بخشی از پتانسیل خود را بلااستفاده میگذارند و این مترادف با هدررفت سرمایههای انسانی و سازمانی است. این موضوع بهویژه در شرایطی که تیمها با ابهامات فنی یا فشار زمانی مواجهاند، نمود بیشتری پیدا میکند. مطالعه مذکور همچنین نشان داد که ایمنی روانی با کاهش خاموشی تیمی (Team Silence) – یعنی حالتی که اعضا از بیان نگرانیها یا ایدههای خودداری میکنند – ارتباط مستقیم دارد.
چرا ایمنی روانی برای تیمهای توسعه نرمافزار حیاتی است؟
فرآیند توسعه نرمافزار ماهیتاً پیچیده، تعاملی و وابسته به خلاقیت و حل مسئله مستمر است. در چنین محیطهایی:
۱. اشتباهات اجتنابناپذیرند
از خطاهای کدنویسی تا تصمیمات معماری، اشتباهات بخشی طبیعی از فرآیند توسعه هستند. اگر اعضای تیم نگران باشند که به خاطر گزارش یک خطا یا بیان یک نگرانی سرزنش شوند، مشکلات پنهان باقی میمانند و در نهایت، کیفیت محصول کاهش مییابد. فرهنگ سرزنش، باعث اختفای مشکلات میشود، درحالیکه محیطی امن، شفافیت را تقویت میکند.
۲. نوآوری حیاتی است
نوآوری از دل ایدههای جدید و جسورانه زاده میشود؛ مانند استفاده از ابزارهای نوین، اتخاذ رویکردهای خلاقانه در تست نرمافزار یا یافتن راهکارهای بهینه برای مقیاسپذیری. اما اگر اعضای تیم به دلیل ترس از طرد شدن، ایدههای خود را مطرح نکنند، خلاقیت سرکوب میشود. نسبت ترس و ایده، مانند نسبت کویر و سرسبزی است؛ هرچه ترس بیشتر باشد، چشمانداز نوآوری خشکتر خواهد شد.
۳. فشار زمانی بالاست
در پروژههای نرمافزاری، مهلتهای فشرده و فشار برای تحویل سریع محصول امری رایج است. در چنین شرایطی، اگر اعضای تیم به دلیل ترس از پیامدهای منفی، از بیان نگرانیهای خود خودداری کنند، مشکلات پنهان میمانند، ریسکها افزایش مییابند و دستیابی به ضربالاجلهای تعیینشده دشوارتر میشود.
چه باید کرد؟
پاسخ به این پرسش ساده نیست. ایجاد ایمنی روانی، فراتر از ایجاد محیطی صرفاً مهربانانه است؛ بلکه نیازمند صداقت، شفافیت و پذیرش است. همانطور که امی ادموندسون میگوید:
با این حال، میتوان با اتخاذ برخی اقدامات، مسیر را هموارتر کرد:
✅ وجود رهبری حمایتگر: مدیر یا تیملید باید نشان دهد که اشتباهات، فرصتی برای یادگیری هستند نه دلیلی برای سرزنش. واکنش رهبران به اشتباهات، فرهنگ تیم را میسازد؛ اگر اعضا ببینند که اشتباهات مجازات میشوند، از پذیرش و بیان آنها خودداری خواهند کرد.
✅ بازخورد منظم و ایمن: نشستهای بازاندیشی (Retrospective) باید فضایی فراهم کنند که اعضای تیم بتوانند آزادانه، بدون نگرانی از پیامدهای منفی، چالشها، نگرانیها و ایدههای خود را بیان کنند. این جلسات زمانی موفق خواهند بود که از فضای داوری و سرزنش فاصله داشته باشند و بر تحلیل، یادگیری و بهبود مستمر متمرکز شوند.
✅ تشویق پرسشگری و چالشگری: رهبران و اعضای تیم باید بهطور فعال پرسیدن سوال و ابراز شک را به عنوان یک ارزش تلقی کنند. ایجاد سازوکارهای عملی برای بیان پرسشها – از جمله جلسات اختصاصی برای طرح سوالات، ابزارهای ناشناس برای ارسال بازخورد، و قدردانی از پرسشگران – میتواند به این هدف کمک کند.
در نهایت، ایمنی روانی نه یک مزیت لوکس، بلکه یک ضرورت برای عملکرد بهینه تیمها در دنیای امروز است. تیمهایی که این فضا را ایجاد میکنند، نهتنها از پتانسیل کامل اعضای خود بهرهمند میشوند، بلکه پایدارتر، نوآورتر و مقاومتر در برابر چالشها خواهند بود.
پینوشت:
- روحالله دلپاک
@DelpakLog
تیمی را میتوان بهرهمند از امنیت روانی (Psychological Safety) دانست که اعضایش احساس کنند میتوانند آزادانه نظراتشان را بیان کنند، سؤال بپرسند، اشتباهات خود را بپذیرند و ایدههای جدید مطرح کنند، بدون ترس از سرزنش، تمسخر یا تنبیه.
این مفهوم ابتدا توسط پروفسور دانشکده کسبوکار هاروارد، اِمی ادموندسون (Amy C. Edmondson) در دهه نود میلادی مطرح شد، اما تحقیقات اخیر نشان دادهاند که در عصر پرشتاب تحولات دیجیتال، اهمیت آن بیش از پیش افزایش یافته است.
در مطالعهای که در سال ۲۰۲۳ انجام شد پژوهشگران (کلارک و گروس)، از طریق بررسی دادههای جمعآوریشده از ۴۸ تیم نرمافزاری در شرکتهای فعال در حوزه فناوری دریافتند که تیمهایی با سطح بالای ایمنی روانی، تا ۳۵ درصد بهرهوری بیشتری در حل مسائل پیچیده و نوآورانه از خود نشان میدهند.
از دیدگاه دیگر، این بدان معناست که تیمهایی که فاقد این مولفه حیاتی باشند، بخشی از پتانسیل خود را بلااستفاده میگذارند و این مترادف با هدررفت سرمایههای انسانی و سازمانی است. این موضوع بهویژه در شرایطی که تیمها با ابهامات فنی یا فشار زمانی مواجهاند، نمود بیشتری پیدا میکند. مطالعه مذکور همچنین نشان داد که ایمنی روانی با کاهش خاموشی تیمی (Team Silence) – یعنی حالتی که اعضا از بیان نگرانیها یا ایدههای خودداری میکنند – ارتباط مستقیم دارد.
چرا ایمنی روانی برای تیمهای توسعه نرمافزار حیاتی است؟
فرآیند توسعه نرمافزار ماهیتاً پیچیده، تعاملی و وابسته به خلاقیت و حل مسئله مستمر است. در چنین محیطهایی:
۱. اشتباهات اجتنابناپذیرند
از خطاهای کدنویسی تا تصمیمات معماری، اشتباهات بخشی طبیعی از فرآیند توسعه هستند. اگر اعضای تیم نگران باشند که به خاطر گزارش یک خطا یا بیان یک نگرانی سرزنش شوند، مشکلات پنهان باقی میمانند و در نهایت، کیفیت محصول کاهش مییابد. فرهنگ سرزنش، باعث اختفای مشکلات میشود، درحالیکه محیطی امن، شفافیت را تقویت میکند.
۲. نوآوری حیاتی است
نوآوری از دل ایدههای جدید و جسورانه زاده میشود؛ مانند استفاده از ابزارهای نوین، اتخاذ رویکردهای خلاقانه در تست نرمافزار یا یافتن راهکارهای بهینه برای مقیاسپذیری. اما اگر اعضای تیم به دلیل ترس از طرد شدن، ایدههای خود را مطرح نکنند، خلاقیت سرکوب میشود. نسبت ترس و ایده، مانند نسبت کویر و سرسبزی است؛ هرچه ترس بیشتر باشد، چشمانداز نوآوری خشکتر خواهد شد.
۳. فشار زمانی بالاست
در پروژههای نرمافزاری، مهلتهای فشرده و فشار برای تحویل سریع محصول امری رایج است. در چنین شرایطی، اگر اعضای تیم به دلیل ترس از پیامدهای منفی، از بیان نگرانیهای خود خودداری کنند، مشکلات پنهان میمانند، ریسکها افزایش مییابند و دستیابی به ضربالاجلهای تعیینشده دشوارتر میشود.
چه باید کرد؟
پاسخ به این پرسش ساده نیست. ایجاد ایمنی روانی، فراتر از ایجاد محیطی صرفاً مهربانانه است؛ بلکه نیازمند صداقت، شفافیت و پذیرش است. همانطور که امی ادموندسون میگوید:
ایمنی روانی به این معنا نیست که مهربان باشیم؛ بلکه به این معناست که بتوانیم با یکدیگر صادق باشیم.
با این حال، میتوان با اتخاذ برخی اقدامات، مسیر را هموارتر کرد:
✅ وجود رهبری حمایتگر: مدیر یا تیملید باید نشان دهد که اشتباهات، فرصتی برای یادگیری هستند نه دلیلی برای سرزنش. واکنش رهبران به اشتباهات، فرهنگ تیم را میسازد؛ اگر اعضا ببینند که اشتباهات مجازات میشوند، از پذیرش و بیان آنها خودداری خواهند کرد.
✅ بازخورد منظم و ایمن: نشستهای بازاندیشی (Retrospective) باید فضایی فراهم کنند که اعضای تیم بتوانند آزادانه، بدون نگرانی از پیامدهای منفی، چالشها، نگرانیها و ایدههای خود را بیان کنند. این جلسات زمانی موفق خواهند بود که از فضای داوری و سرزنش فاصله داشته باشند و بر تحلیل، یادگیری و بهبود مستمر متمرکز شوند.
✅ تشویق پرسشگری و چالشگری: رهبران و اعضای تیم باید بهطور فعال پرسیدن سوال و ابراز شک را به عنوان یک ارزش تلقی کنند. ایجاد سازوکارهای عملی برای بیان پرسشها – از جمله جلسات اختصاصی برای طرح سوالات، ابزارهای ناشناس برای ارسال بازخورد، و قدردانی از پرسشگران – میتواند به این هدف کمک کند.
در نهایت، ایمنی روانی نه یک مزیت لوکس، بلکه یک ضرورت برای عملکرد بهینه تیمها در دنیای امروز است. تیمهایی که این فضا را ایجاد میکنند، نهتنها از پتانسیل کامل اعضای خود بهرهمند میشوند، بلکه پایدارتر، نوآورتر و مقاومتر در برابر چالشها خواهند بود.
پینوشت:
آری، آری، زندگی زیباست.
زندگی آتشگهی دیرنده پابرجاست.
گر بیفروزیش، رقص شعلهاش در، هر کران پیداست.
ورنه، خاموش است و خاموشی گناه ماست.
—سیاوش کسرایی
- روحالله دلپاک
@DelpakLog
🔥6🎄1
Audio
صوت جلسه 21
جلسه به شدت جذابی بود، البته همه جلسات جذابیت زیادی داره ولی این یکی بدلیل موضوع به شدت چالش برانگیزش، جذاب تر شد.
مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
- دقت به بررسی معنایی خود عبارات Online transaction processing (OLTP) و online analytical processing (OLAP) و ایجاد مدل ذهنی صحیح از این کلمات و دقت به این موضوع که هر دو عبارت تقسیم های حوزه ابزار هستند و در علوم کامپیوتر جایگاهی ندارند همانند دیگر کلمات حوزه ابزار مثل Cloud
- اشاره به تفاوت دو کلمه Analytics و ANALYSIS که اینجا هم بهشون قبلا پرداختیم. هر چند در جلسه من به اشتباه تعریف دو کلمه را جابجا نسبت به قبلا گفتم که همینجا باید بگم دوستان دقت کنند، هر چند در انتها به توافق با بهنیا عزیز هم نرسیدیم که دقیقا این مرز را قائل بشیم یا نه، هر چند در وجود دو نیازمندی #داده_اکتشافی گذشته نگر و آینده نگر قطعا اتفاق نظر داریم.
جلسه به شدت جذابی بود، البته همه جلسات جذابیت زیادی داره ولی این یکی بدلیل موضوع به شدت چالش برانگیزش، جذاب تر شد.
مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
- دقت به بررسی معنایی خود عبارات Online transaction processing (OLTP) و online analytical processing (OLAP) و ایجاد مدل ذهنی صحیح از این کلمات و دقت به این موضوع که هر دو عبارت تقسیم های حوزه ابزار هستند و در علوم کامپیوتر جایگاهی ندارند همانند دیگر کلمات حوزه ابزار مثل Cloud
- اشاره به تفاوت دو کلمه Analytics و ANALYSIS که اینجا هم بهشون قبلا پرداختیم. هر چند در جلسه من به اشتباه تعریف دو کلمه را جابجا نسبت به قبلا گفتم که همینجا باید بگم دوستان دقت کنند، هر چند در انتها به توافق با بهنیا عزیز هم نرسیدیم که دقیقا این مرز را قائل بشیم یا نه، هر چند در وجود دو نیازمندی #داده_اکتشافی گذشته نگر و آینده نگر قطعا اتفاق نظر داریم.
💯5🔥2
Forwarded from امین رشیدبیگی | مهندسی نرمافزار
ابزار مدیریت محصول Linear که یکی از استارتآپهای خیلی موفق چند سال گذشته است، به خاطر نگاه متفاوتی که به روند توسعهٔ محصولشون داشتن در کامیونیتیهای پروداکت و UX خیلی ازش صحبت میشه. اونا تونستن که محصول خیلی باکیفیتی ارائه بدن و خیلیها معتقدن از رقیبهای بزرگشون مثل Jira و Clickup تجربهٔ کاربری بهتری ارائه میدن.
یک محصول خوب با پشتیبانی یک تیم مهندسی خوب ساخته میشه. Sabin Roman که Engineer Manager و Hiring Manager این شرکته، اخیراً مصاحبهٔ خیلی خوبی با Gergley Orosz داشته. هر دوی این افراد در گذشته در Uber با هم همکار بودن و به همین دلیل مقایسههای جالبی بین شرکت بزرگی مثل Uber و استارتآپ نسبتاً جدیدی و کوچکی مثل Linear شکل میگیره.
نکاتی در مورد فرهنگ شرکت Linear که برام جالب بود:
- شرکتشون کاملاً ریموته و بر روی این اصل پافشاری میکنن. مصاحبهکننده بر این باوره که remote first بودن مزایای زیادی رو به شرکت اضافه میکنه، حتی با وجود این که سربار بیشتری برای مدیرهای شرکت داره.
- حل یک باگ همواره براشون اولویت بالاتری از توسعهٔ محصول داره و همهٔ اعضای تیم موظفن که در زودترین زمان ممکن باگ رو رفع کنن و برای این مسئله فرآیند مشخصی دارن.
- مهندسهاشون ارتباط مستقیم و بدون واسطهای با مشتریها دارن و حرفهاشون رو میشنون و مشکلات محصول رو میبینن.
ویدیو رو میتونید از این لینک ببینید.
@aminrbg
یک محصول خوب با پشتیبانی یک تیم مهندسی خوب ساخته میشه. Sabin Roman که Engineer Manager و Hiring Manager این شرکته، اخیراً مصاحبهٔ خیلی خوبی با Gergley Orosz داشته. هر دوی این افراد در گذشته در Uber با هم همکار بودن و به همین دلیل مقایسههای جالبی بین شرکت بزرگی مثل Uber و استارتآپ نسبتاً جدیدی و کوچکی مثل Linear شکل میگیره.
نکاتی در مورد فرهنگ شرکت Linear که برام جالب بود:
- شرکتشون کاملاً ریموته و بر روی این اصل پافشاری میکنن. مصاحبهکننده بر این باوره که remote first بودن مزایای زیادی رو به شرکت اضافه میکنه، حتی با وجود این که سربار بیشتری برای مدیرهای شرکت داره.
- حل یک باگ همواره براشون اولویت بالاتری از توسعهٔ محصول داره و همهٔ اعضای تیم موظفن که در زودترین زمان ممکن باگ رو رفع کنن و برای این مسئله فرآیند مشخصی دارن.
- مهندسهاشون ارتباط مستقیم و بدون واسطهای با مشتریها دارن و حرفهاشون رو میشنون و مشکلات محصول رو میبینن.
ویدیو رو میتونید از این لینک ببینید.
@aminrbg
YouTube
Linear: move fast with little process (with first Engineering Manager Sabin Roman)
Linear is a small startup with a big impact: 10,000+ companies use their project and issue-tracking system, including 66% of Forbes Top 50 AI companies. Founded in 2019, the company raised $52M in funding and is profitable, and full-remote. How did they…
🔥3
امین رشیدبیگی | مهندسی نرمافزار
ابزار مدیریت محصول Linear که یکی از استارتآپهای خیلی موفق چند سال گذشته است، به خاطر نگاه متفاوتی که به روند توسعهٔ محصولشون داشتن در کامیونیتیهای پروداکت و UX خیلی ازش صحبت میشه. اونا تونستن که محصول خیلی باکیفیتی ارائه بدن و خیلیها معتقدن از رقیبهای…
به نظرم Linear برای مدیریت روال های توسعه نرم افزار خیلی خارق العادس، به نظرم فیچر های خیلی خوبی داره مثل نگهداری Issue ها به صورت دوطرفه هم داخل گیتهاب و هم داخل Linear.
من توی مایگریشنم از Notion به Linear خیلی خوشحالم.
حالا میخوام یه ترکیب برنده رو بگم برای تیم های ریموت کوچیک.
Linear + Slack + WorkWeave + Github
Linear: Task management
Slack: Team comunication
WorkWeave: Team Performance Measurment
Github: Issue management, Code management.
من توی مایگریشنم از Notion به Linear خیلی خوشحالم.
حالا میخوام یه ترکیب برنده رو بگم برای تیم های ریموت کوچیک.
Linear + Slack + WorkWeave + Github
Linear: Task management
Slack: Team comunication
WorkWeave: Team Performance Measurment
Github: Issue management, Code management.
👍3🔥2
Forwarded from thisisnabi.dev [Farsi]
جدای از 1 لایه و 2 لایه و 15 لایه، یا 6 ضلعی و 20 ضلعی و غیره، یا حتی کثیف و تمیز و تمیزتر،
معماری خوب، معماری هست که به مرور زمان نیاز به معمارش نداشته باشه.
معماری خوب، معماری هست که به مرور زمان نیاز به معمارش نداشته باشه.
👍6🔥3
thisisnabi.dev [Farsi]
جدای از 1 لایه و 2 لایه و 15 لایه، یا 6 ضلعی و 20 ضلعی و غیره، یا حتی کثیف و تمیز و تمیزتر، معماری خوب، معماری هست که به مرور زمان نیاز به معمارش نداشته باشه.
این حرف نبی رو باید با الماس گرفت (طلا کمه)
🔥5
Forwarded from CodeLodge
در این قسمت از سری پادکستهای Code lodge، به بررسی عمیق نقش هوش مصنوعی در دنیای توسعه نرمافزار میپردازیم. در این گفتگو، همراه با دوست صمیمیمان، مسعود عزیز، به نقد جنبههای مختلف استفاده از AI در محیطهای دولوپمنت میپردازیم؛ از جمله مباحث پیرامون نگرانیهای مرتبط با اتوماسیون بیش از حد و جایگزینی نیروی انسانی و دست کم گیری نقش مهم مدل های زبانی در توسعه. هدف ما ارائه بینشی جامع از چالشها و فرصتهایی است که هوش مصنوعی برای توسعهدهندگان به ارمغان میآورد و راهکارهایی برای حفظ کیفیت و خلاقیت در کار ارائه میدهد.
میزبانان شما:
بهنیا آزاد
مسعود بیگی
این ایپزود را می توانید از طریق لینک های زیر هم بشنوید :
- 🔗Spotify
- 🔗Amazon
- 🔗Castbox
-🔗Apple podcast
-🔗 Shenoto
#Codelodge
#Software
#AI
#LLM
#softwareDeveloper
#SoftwareEngineer
@codeLodge
میزبانان شما:
بهنیا آزاد
مسعود بیگی
این ایپزود را می توانید از طریق لینک های زیر هم بشنوید :
- 🔗Spotify
- 🔗Amazon
- 🔗Castbox
-🔗Apple podcast
-🔗 Shenoto
#Codelodge
#Software
#AI
#LLM
#softwareDeveloper
#SoftwareEngineer
@codeLodge
🔥6
Software is becoming systems of software. Our thinking generates the concepts that we rely on when designing our systems. When our concepts work together in harmony, supporting a system’s purpose, they have integrity.
Without conceptual integrity, our software systems are built by “many good but independent and uncoordinated ideas.”
From Learning System Thinking Book
Without conceptual integrity, our software systems are built by “many good but independent and uncoordinated ideas.”
From Learning System Thinking Book
🔥4
خرسِ برنامه نویس
Software is becoming systems of software. Our thinking generates the concepts that we rely on when designing our systems. When our concepts work together in harmony, supporting a system’s purpose, they have integrity. Without conceptual integrity, our software…
از این حرف چی میشه برداشت کرد؟
نظر من:
اینکه ممکنه ما در مولفه های معماری نرم افزارمون هماهنگی بین اجزای نرم افزاری رو جا بندازیم. نکته ای که داره اینه که خیلی وقت ها انقدری درگیر ایزوله کردن ماژول ها میشیم که اصلا یادمون میره که این ماژول ها باید با هم ارتباط بگیرند، هماهنگ باشند و باهم کار کنن! اصلا یک سری رفتار ها از ارتباط و هماهنگی بین دوتا ماژول شکل میگیره. نکته دومی هم وجود داره با استفاده از هزار تا تکنولوژی و ابزار هم این موضوع لزوما درست نمیشه. مثلا اگر شما از ابزار های Event Sourcing داری استفاده میکنی به این معنی نیست که مسئله ارتباط بین ماژول ها رو حل کردی، فقط میشه گفت که زیرساخت این موضوع ممکنه اضافه شده باشه. همچنان باید یک پروتکل ارتباطی وجود داشته باشه که در بستر Event Sourcing بتونه به نیاز های ارتباطی پاسخ بده.
نظر من:
اینکه ممکنه ما در مولفه های معماری نرم افزارمون هماهنگی بین اجزای نرم افزاری رو جا بندازیم. نکته ای که داره اینه که خیلی وقت ها انقدری درگیر ایزوله کردن ماژول ها میشیم که اصلا یادمون میره که این ماژول ها باید با هم ارتباط بگیرند، هماهنگ باشند و باهم کار کنن! اصلا یک سری رفتار ها از ارتباط و هماهنگی بین دوتا ماژول شکل میگیره. نکته دومی هم وجود داره با استفاده از هزار تا تکنولوژی و ابزار هم این موضوع لزوما درست نمیشه. مثلا اگر شما از ابزار های Event Sourcing داری استفاده میکنی به این معنی نیست که مسئله ارتباط بین ماژول ها رو حل کردی، فقط میشه گفت که زیرساخت این موضوع ممکنه اضافه شده باشه. همچنان باید یک پروتکل ارتباطی وجود داشته باشه که در بستر Event Sourcing بتونه به نیاز های ارتباطی پاسخ بده.
🔥3❤1
Forwarded from tech-afternoon (Amin Mesbahi)
💡 یک قدم به سمت کاربرد عینی مدل زبانی با RAG, CAG, KAG یا Fine Tuning
در حالت عادی، یه مدل زبانی از چند میلیارد تا چندصد میلیارد پارامتر آموزش میبینه، بلده به زبونهای مختلف حرف بزنه و جملاتی عاقلانه تا ابلهانه سرهم کنه. بلده دستور پخت سوشی تا قرمهسبزی بده و برای دلدردتون چایینبات تجویز کنه، ولی اینکه بالانس حساب آقای جمالی چقدره یا آییننامههای داخلی شرکتی که ما توش کار میکنیم یعنی کامپیوتراندیشان عصر نوین پاسارگاد با مدیریت آقای موکتپور رو که بلد نیست! پس باید راهی یاد بگیریم که مزخرفاتی که بلده رو با مزخرفات خودمون بیامیزیم و مزخرفات ترکیبی تولید کنیم. پس یه نگاه کلی به RAG، CAG, KAG و Fine Tuning بندازیم تا اگر مشتری داشت ادامهاش بدیم…
✅ مفهوم و کاربرد RAG یا Retrieval-Augmented Generation چیه؟
کار RAG اینه که دادههای مدل رو با دیتای ما تکمیل کنه؛ یعنی موقع جواب دادن به سؤال، میره از یه دیتابیس یا منبع خارجی (که عموما به صورت Vector database ذخیره میکنیم) اطلاعات جدید رو میگیره و بعد جواب میده. اینجوری دیگه همیشه اطلاعات سیستم خودمون رو در کنار قابلیتهای مدل اصلی داریم. این اطلاعات رو میتونیم نهایتا به شکل ساختارمند و مشخص (مثلا یه آبجکت یا یه ساختار JSON مشخص) برگردونیم، یا باهاش جمله بسازیم و مثل یه محاوره انسانی برگردونیمش.
چرا لازمه ازش استفاده کنیم؟
- اطلاعات بهروز و دقیقتر
- کاهش خطا و توهم در جوابهای مدل
- جوابهای دقیق و مبتنی بر داده واقعی
✅ مفهوم و کاربرد KAG یا Knowledge-Augmented Generation چیه؟
کاربرد و مفهموم KAG یه مرحله پیشرفتهتر از RAG هست که از گرافهای دانش ساختاریافته استفاده میکنه. یعنی علاوه بر دادههای معمولی، دادهها رو بهصورت ساختاریافته (مثل گراف دانش) به مدل میده و مدل میتونه از طریق این ساختارها منطق و استدلال چندمرحلهای انجام بده. (توی RAG کوئری داریم ولی اینجا گراف دانش)
چرا لازمه ازش استفاده کنیم؟
- افزایش دقت در حوزههای تخصصی
- استدلال چندمرحلهای و منطقی
- رعایت قوانین و مقررات مشخص (مثل حوزههای پزشکی و حقوقی)
✅ مفهوم و کاربرد CAG یا Cache-Augmented Generation چیه؟
مفهوم CAG یه جورایی نسخه سریعتر و سادهتر از RAG هست. توی CAG، دانش ثابت (مثل دفترچههای راهنما) از قبل تو حافظه (Cache) بارگذاری میشه و موقع جواب دادن لازم نیست هر بار اطلاعات رو از بیرون بگیره.
چرا لازمه ازش استفاده کنیم؟
- جوابهای سریعتر
- ساختار سادهتر و هزینه کمتر
- ثبات و یکپارچگی جوابها
✅ مفهوم و کاربر Fine Tuning (تنظیم دقیق) دیگه؟
یه سری دادههای محدود و مشخص رو به یه مدل زبانی که خیلی چیزا بلده، ولی دقیقاً کاری که میخوای رو درست انجام نمیده. اینجا میای از Fine Tuning استفاده میکنی؛ یعنی یه سری داده خاص خودمون رو میدیم بهش که یاد بگیره دقیقاً طبق اون چیزی که میخوایم جواب بده. از RAG خیلی سادهتر و ابتداییتره.
چرا لازمه ازش استفاده کنیم؟
- بهبود دقت مدل توی یه وظیفه خاص
- سفارشی کردن مدل برای کسبوکار یا حوزه خاص خودمون
- کاهش هزینهها (چون نیازی به آموزش یه مدل عظیم از صفر نداریم)
📎 طی ماههای پیش رو، SQL Server 2025 قابلیتهایی ارائه خواهد کرد که کارهای RAG و CAG و KAG رو بتونیم انجام بدیم. یعنی به جای استفاده از Vector Databaseها که الان ازشون برای RAG کمک میگیریم، میتونیم مستقیم از خود SQL Server کمک بگیریم. البته چون هنوز قابلیت vector اش رونمایی عمومی نشده، نمیشه قضاوت کرد که در مقایسه با نمونههای پرشمار VectorDBها چه جایگاهی داره.
مثل همیشه:💬 ⚙️ 😉
سال ۱۴۰۳ هم تموم شد و مثل ۲ سال قبلترش، روز و ساعتی نبود که هوشمصنوعی خصوصا از نوع مولدش از متن و تیتر اخبار بیوفته 😉 حالا اگر تا به امروز فقط باهاش چت کردین، یا همون چت رو با API انجام دادین، دیگه ۱۴۰۴ سالیه که خوبه از حاشیه به متن بیاریدش و «اگر و اگر ارزش افزودهای به محصولتون اضافه میکنه»، به شکل جدیتری ازش استفاده کنین. حالا این یعنی چی؟ مگه چت کردن چشه؟
در حالت عادی، یه مدل زبانی از چند میلیارد تا چندصد میلیارد پارامتر آموزش میبینه، بلده به زبونهای مختلف حرف بزنه و جملاتی عاقلانه تا ابلهانه سرهم کنه. بلده دستور پخت سوشی تا قرمهسبزی بده و برای دلدردتون چایینبات تجویز کنه، ولی اینکه بالانس حساب آقای جمالی چقدره یا آییننامههای داخلی شرکتی که ما توش کار میکنیم یعنی کامپیوتراندیشان عصر نوین پاسارگاد با مدیریت آقای موکتپور رو که بلد نیست! پس باید راهی یاد بگیریم که مزخرفاتی که بلده رو با مزخرفات خودمون بیامیزیم و مزخرفات ترکیبی تولید کنیم. پس یه نگاه کلی به RAG، CAG, KAG و Fine Tuning بندازیم تا اگر مشتری داشت ادامهاش بدیم…
کار RAG اینه که دادههای مدل رو با دیتای ما تکمیل کنه؛ یعنی موقع جواب دادن به سؤال، میره از یه دیتابیس یا منبع خارجی (که عموما به صورت Vector database ذخیره میکنیم) اطلاعات جدید رو میگیره و بعد جواب میده. اینجوری دیگه همیشه اطلاعات سیستم خودمون رو در کنار قابلیتهای مدل اصلی داریم. این اطلاعات رو میتونیم نهایتا به شکل ساختارمند و مشخص (مثلا یه آبجکت یا یه ساختار JSON مشخص) برگردونیم، یا باهاش جمله بسازیم و مثل یه محاوره انسانی برگردونیمش.
چرا لازمه ازش استفاده کنیم؟
- اطلاعات بهروز و دقیقتر
- کاهش خطا و توهم در جوابهای مدل
- جوابهای دقیق و مبتنی بر داده واقعی
کاربرد و مفهموم KAG یه مرحله پیشرفتهتر از RAG هست که از گرافهای دانش ساختاریافته استفاده میکنه. یعنی علاوه بر دادههای معمولی، دادهها رو بهصورت ساختاریافته (مثل گراف دانش) به مدل میده و مدل میتونه از طریق این ساختارها منطق و استدلال چندمرحلهای انجام بده. (توی RAG کوئری داریم ولی اینجا گراف دانش)
چرا لازمه ازش استفاده کنیم؟
- افزایش دقت در حوزههای تخصصی
- استدلال چندمرحلهای و منطقی
- رعایت قوانین و مقررات مشخص (مثل حوزههای پزشکی و حقوقی)
مفهوم CAG یه جورایی نسخه سریعتر و سادهتر از RAG هست. توی CAG، دانش ثابت (مثل دفترچههای راهنما) از قبل تو حافظه (Cache) بارگذاری میشه و موقع جواب دادن لازم نیست هر بار اطلاعات رو از بیرون بگیره.
چرا لازمه ازش استفاده کنیم؟
- جوابهای سریعتر
- ساختار سادهتر و هزینه کمتر
- ثبات و یکپارچگی جوابها
یه سری دادههای محدود و مشخص رو به یه مدل زبانی که خیلی چیزا بلده، ولی دقیقاً کاری که میخوای رو درست انجام نمیده. اینجا میای از Fine Tuning استفاده میکنی؛ یعنی یه سری داده خاص خودمون رو میدیم بهش که یاد بگیره دقیقاً طبق اون چیزی که میخوایم جواب بده. از RAG خیلی سادهتر و ابتداییتره.
چرا لازمه ازش استفاده کنیم؟
- بهبود دقت مدل توی یه وظیفه خاص
- سفارشی کردن مدل برای کسبوکار یا حوزه خاص خودمون
- کاهش هزینهها (چون نیازی به آموزش یه مدل عظیم از صفر نداریم)
مثل همیشه:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Forwarded from DevTwitter | توییت برنامه نویسی
یه چرخ زدم تو گیتهاب ، ملت کلی api key پوش کردن تو گیتهاب :)))
نتیجه وایب کدینگ با هوش مصنوعی
البته بیشتراش از کار افتاده بخاطر سیستم گیتهاب...
@DevTwitter | <Shojaei/>
نتیجه وایب کدینگ با هوش مصنوعی
البته بیشتراش از کار افتاده بخاطر سیستم گیتهاب...
@DevTwitter | <Shojaei/>
🔥3🤣1
Forwarded from TondTech (مسعود بیگی)
برای یکی از چند تا شرکت بزرگ اکوسیستم، دوستانم در حال تیم سازی هستند. اگر در حوزه دات نت مید (d3 به بالا) تا تک لید هستید و دوست دارید این فرصت رو بررسی کنید، رزومه تون رو برام بفرستین
برای سنجش خودتون نگاهی به این فریم ورک بندازید:
https://github.com/jorgef/engineeringladders
@Merkousha
برای سنجش خودتون نگاهی به این فریم ورک بندازید:
https://github.com/jorgef/engineeringladders
@Merkousha
🔥4