#مطلب
Here’s how I use LLMs to help me write code
https://simonwillison.net/2025/Mar/11/using-llms-for-code/
با اومدن LLM ها و ابزارهایی مثل Cursor و Windsurf نحوه‌ی کد زدن خیلی از مهندسان نرم‌افزار هم عوض شده و استفاده از این ابزارها به بخشی از کارهای روزمره تبدیل شده. از طرفی استفاده‌ی درست از LLM ها به گونه‌ای که بتونیم بهترین بهره‌وری رو داشته باشیم کار ساده‌ای نیست و نیاز به آزمون و خطا و تجربه کردن داره. مقاله‌ی بالا به همین موضوع می‌پردازه و سعی میکنه به ما کمک کنه که چطوری بهتر از LLM ها توی کد زدن استفاده کنیم.
چندتا نکته‌ی کوتاه که جالب بود رو اینجا آوردم ولی پیشنهاد میکنم حتما مقاله‌ی اصلی رو بخونید:
- هوش مصنوعی یه دستیار خوب و سریعه ولی با اعتماد به نفس بیش از اندازه:
با اینکه خیلی از چیزا رو درست میگه اما یکسری از چیزها رو هم با اعتماد به نفس کامل اشتباه میگه و ممکنه شما رو کلا گمراه کنه. اگر یک انسان اینکار رو انجام بده احتمالا شما اعتمادتون رو بهش از دست میدید و دیگه چیزی رو ازش نمی‌پرسید اما با هوش مصنوعی نباید مثل یه انسان برخورد کرد! در عوض بهتره نقاط قوت و ضعف مدل‌های مختلف رو بشناسیم و یادبگیریم که چیا رو میتونن انجام بدن و توی چه چیزهایی خوب نیستن
- تاریخ cuttoff رو حتما مد نظر قرار بدید
تاریخ cutoff نشون میده اطلاعاتی که مدل روش آموزش دیده چقدر بروز بوده. برای مثال اگر cutoff یه مدلی 2023 باشه احتمالا تغییراتی که توی 2025 اتفاق افتاده رو نمی‌دونه یا بد عمل میکنه. البته با اومدن قابلیت tools و سرچ کردن این مشکل بهتر شده اما همچنان اگر مدل روی داده‌های جدیدتر آموزش دیده باشه بهتر میتونه جواب بده. خوبه زمان cutoff مدلی که استفاده میکنید رو بدونید. برای همین هرچقدر از کتابخونه‌های معروف‌تر که توی اینترنت درموردشون دیتای بیشتری هست استفاده کنید احتمالا LLM ها بیشتر میتونن بهتون کمک کنن.
- کانتکست خیلی مهمه!
جواب مدل‌ها خیلی خیلی وابسته به این هست که چه چیزی رو توی پیام‌های قبلی براشون فرستادید. تمامی پیام هایی که بین شما و مدل رد و بدل میشه توی کانتکست مدل هست و اونا رو میدونه. برای همین خیلی مهمه که کانتکست خوبی بهش بدید. مثلا اگر میخواید یه کار بزرگی بهش بدید خوبه اول یه iteration کوچیک باهاش برید و بهش بگید کم کم پیچیدش کنه و قسمت‌های مختلفش رو بزنه. اینطوری چون تمامی کدها و کانتکست قبلی رو داره میتونه بهتر جواب بده
- مدل‌های زبانی برای prototype زدن و تست گرفتن ایده‌های مختلف خیلی خوبن
- هنگام استفاده از مدل‌ها توی کد پروداکشن محافظه‌کارتر باشید
توی کدهای پروداکشن بهتره دقیقا به LLM بگید چی‌میخواید و با جزئیات براش توضیح بدید. کدهایی که LLM میزنه به نظر درست میاد، اسم متغیرها درسته اسم توابع به نظر درست میاد اما این نباید شما رو گول بزنه. حتما حتما باید کدهای LLM رو تست کنید و درستی یه کدی رو تا با چشمتون ندیدید باور نکنید. احتمال اینکه باگ‌های ریز توی جاهای مختلف باشه زیاده که به چشم نمیان. همچنین اگر تست‌ها رو میدید که خود LLM بزنه خوبه خیلی دقیق کدهای تست رو بررسی کنید که چه چیزی رو دارن تست میکنن.
- آماده‌ی مداخله‌ی انسانی باشید!
مدل‌های زبانی قرار نیست جای تجربه و شهود شما رو بگیرن. بزرگ‌ترین مزیت این مدل‌ها سرعت زیادشون هست اما خیلی جاها باید آماده باشید که مداخله کنید و یه تغییراتی رو خودتون اعمال کنید. قرار نیست سر تا ته یه پروژه رو بدید LLM بزنه.
داخل مقاله کلی مثال و prompt و نکته‌ی باحال دیگه هم هست که من اینحا نیاوردم و پیشنهاد میکنم حتما مقاله‌ی اصلی رو بخونید.
✴️ @software_inside - مهندسی‌نرم‌افزار
Here’s how I use LLMs to help me write code
https://simonwillison.net/2025/Mar/11/using-llms-for-code/
با اومدن LLM ها و ابزارهایی مثل Cursor و Windsurf نحوه‌ی کد زدن خیلی از مهندسان نرم‌افزار هم عوض شده و استفاده از این ابزارها به بخشی از کارهای روزمره تبدیل شده. از طرفی استفاده‌ی درست از LLM ها به گونه‌ای که بتونیم بهترین بهره‌وری رو داشته باشیم کار ساده‌ای نیست و نیاز به آزمون و خطا و تجربه کردن داره. مقاله‌ی بالا به همین موضوع می‌پردازه و سعی میکنه به ما کمک کنه که چطوری بهتر از LLM ها توی کد زدن استفاده کنیم.
چندتا نکته‌ی کوتاه که جالب بود رو اینجا آوردم ولی پیشنهاد میکنم حتما مقاله‌ی اصلی رو بخونید:
- هوش مصنوعی یه دستیار خوب و سریعه ولی با اعتماد به نفس بیش از اندازه:
با اینکه خیلی از چیزا رو درست میگه اما یکسری از چیزها رو هم با اعتماد به نفس کامل اشتباه میگه و ممکنه شما رو کلا گمراه کنه. اگر یک انسان اینکار رو انجام بده احتمالا شما اعتمادتون رو بهش از دست میدید و دیگه چیزی رو ازش نمی‌پرسید اما با هوش مصنوعی نباید مثل یه انسان برخورد کرد! در عوض بهتره نقاط قوت و ضعف مدل‌های مختلف رو بشناسیم و یادبگیریم که چیا رو میتونن انجام بدن و توی چه چیزهایی خوب نیستن
- تاریخ cuttoff رو حتما مد نظر قرار بدید
تاریخ cutoff نشون میده اطلاعاتی که مدل روش آموزش دیده چقدر بروز بوده. برای مثال اگر cutoff یه مدلی 2023 باشه احتمالا تغییراتی که توی 2025 اتفاق افتاده رو نمی‌دونه یا بد عمل میکنه. البته با اومدن قابلیت tools و سرچ کردن این مشکل بهتر شده اما همچنان اگر مدل روی داده‌های جدیدتر آموزش دیده باشه بهتر میتونه جواب بده. خوبه زمان cutoff مدلی که استفاده میکنید رو بدونید. برای همین هرچقدر از کتابخونه‌های معروف‌تر که توی اینترنت درموردشون دیتای بیشتری هست استفاده کنید احتمالا LLM ها بیشتر میتونن بهتون کمک کنن.
- کانتکست خیلی مهمه!
جواب مدل‌ها خیلی خیلی وابسته به این هست که چه چیزی رو توی پیام‌های قبلی براشون فرستادید. تمامی پیام هایی که بین شما و مدل رد و بدل میشه توی کانتکست مدل هست و اونا رو میدونه. برای همین خیلی مهمه که کانتکست خوبی بهش بدید. مثلا اگر میخواید یه کار بزرگی بهش بدید خوبه اول یه iteration کوچیک باهاش برید و بهش بگید کم کم پیچیدش کنه و قسمت‌های مختلفش رو بزنه. اینطوری چون تمامی کدها و کانتکست قبلی رو داره میتونه بهتر جواب بده
- مدل‌های زبانی برای prototype زدن و تست گرفتن ایده‌های مختلف خیلی خوبن
- هنگام استفاده از مدل‌ها توی کد پروداکشن محافظه‌کارتر باشید
توی کدهای پروداکشن بهتره دقیقا به LLM بگید چی‌میخواید و با جزئیات براش توضیح بدید. کدهایی که LLM میزنه به نظر درست میاد، اسم متغیرها درسته اسم توابع به نظر درست میاد اما این نباید شما رو گول بزنه. حتما حتما باید کدهای LLM رو تست کنید و درستی یه کدی رو تا با چشمتون ندیدید باور نکنید. احتمال اینکه باگ‌های ریز توی جاهای مختلف باشه زیاده که به چشم نمیان. همچنین اگر تست‌ها رو میدید که خود LLM بزنه خوبه خیلی دقیق کدهای تست رو بررسی کنید که چه چیزی رو دارن تست میکنن.
- آماده‌ی مداخله‌ی انسانی باشید!
مدل‌های زبانی قرار نیست جای تجربه و شهود شما رو بگیرن. بزرگ‌ترین مزیت این مدل‌ها سرعت زیادشون هست اما خیلی جاها باید آماده باشید که مداخله کنید و یه تغییراتی رو خودتون اعمال کنید. قرار نیست سر تا ته یه پروژه رو بدید LLM بزنه.
داخل مقاله کلی مثال و prompt و نکته‌ی باحال دیگه هم هست که من اینحا نیاوردم و پیشنهاد میکنم حتما مقاله‌ی اصلی رو بخونید.
✴️ @software_inside - مهندسی‌نرم‌افزار
Simon Willison’s Weblog
Here’s how I use LLMs to help me write code
Online discussions about using Large Language Models to help write code inevitably produce comments from developers who’s experiences have been disappointing. They often ask what they’re doing wrong—how come some …
❤11👍3🙏1💯1
Forwarded from نوشته‌های ترمینالی
پاسخ به یک سوال معروف مصاحبه ها:
وقتی گوگل رو در مرورگر باز می‌کنیم چه اتفاقی میوفته؟
این مطلب یه جواب خیلی کامل و مفصل به این سوال ارائه داده ولی قاعدتا تو مصاحبه با این عمق فرصت نمیشه بگیم :))
https://github.com/alex/what-happens-when
وقتی گوگل رو در مرورگر باز می‌کنیم چه اتفاقی میوفته؟
این مطلب یه جواب خیلی کامل و مفصل به این سوال ارائه داده ولی قاعدتا تو مصاحبه با این عمق فرصت نمیشه بگیم :))
https://github.com/alex/what-happens-when
GitHub
GitHub - alex/what-happens-when: An attempt to answer the age old interview question "What happens when you type google.com into…
An attempt to answer the age old interview question "What happens when you type google.com into your browser and press enter?" - alex/what-happens-when
👍4❤1👌1
#مطلب
The Part of PostgreSQL We Hate the Most
https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html
قسمت‌هایی از پستگرس که ازشون متنفریم! این روزا پستگرس تبدیل شده به یکی از محبوب‌ترین دیتابیس‌های رابطه‌ای و روز به روز هم داره به محبوبیتش اضافه میشه اما این بدین معنی نیست که پستگرس مشکلی نداره :)
داخل پستگرس یه مفهومی داریم به اسم MVCC که کمک میکنه تراکنش‌های مختلف به صورت همزمان داخل پایگاه داده اجرا بشن بدون اینکه روی داده‌های هم‌دیگه اثر بذارن و isolation رو نقض کنن.
این مطلب به صورت عمیق به توضیح MVCC توی دیتابیس‌ها علی‌الخصوص پستگرس می‌پردازه و مشکلات روشی که پسترگس رفته رو بیان میکنه. اینکه توی پسترگس نیاز به VACCUM دوره‌ای داریم یا مشکل Table bloatیا اینکه آپدیت کردن یک ستون از یه ردیف باعث میشه کل داده‌های ردیف کپی بشن به همین مفهوم مربوطه.
این مطلب دید خیلی خوبی به internals پستگرس میده و به کسایی که دوست دارن توی پستگرس و دیتابیس‌ها عمیق بشن توصیه میشه
✴️ @software_inside - مهندسی‌نرم‌افزار
The Part of PostgreSQL We Hate the Most
https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html
قسمت‌هایی از پستگرس که ازشون متنفریم! این روزا پستگرس تبدیل شده به یکی از محبوب‌ترین دیتابیس‌های رابطه‌ای و روز به روز هم داره به محبوبیتش اضافه میشه اما این بدین معنی نیست که پستگرس مشکلی نداره :)
داخل پستگرس یه مفهومی داریم به اسم MVCC که کمک میکنه تراکنش‌های مختلف به صورت همزمان داخل پایگاه داده اجرا بشن بدون اینکه روی داده‌های هم‌دیگه اثر بذارن و isolation رو نقض کنن.
این مطلب به صورت عمیق به توضیح MVCC توی دیتابیس‌ها علی‌الخصوص پستگرس می‌پردازه و مشکلات روشی که پسترگس رفته رو بیان میکنه. اینکه توی پسترگس نیاز به VACCUM دوره‌ای داریم یا مشکل Table bloatیا اینکه آپدیت کردن یک ستون از یه ردیف باعث میشه کل داده‌های ردیف کپی بشن به همین مفهوم مربوطه.
این مطلب دید خیلی خوبی به internals پستگرس میده و به کسایی که دوست دارن توی پستگرس و دیتابیس‌ها عمیق بشن توصیه میشه
✴️ @software_inside - مهندسی‌نرم‌افزار
Andy Pavlo - Carnegie Mellon University
The Part of PostgreSQL We Hate the Most
As much as Andy loves PostgreSQL, there is one part that is terrible and causes many headaches for people. Learn what it is and why it sucks.
#مطلب
Time to upgrade your monitor
https://tonsky.me/blog/monitors/
🖥 برای برنامه‌نویسی چه مانیتوری داشته باشیم خوبه؟! مطلب بالا مفصل به این قضیه می‌پردازه و یه سری پیشنهاد در این زمینه میکنه که پایین همین پست خلاصش رو نوشتم.
یکی از چیزایی که مهمه Text Clarity و کیفیت نمایش متن‌هاست. خیلیا فک میکنن resolution تنها ملاک کیفیته و اگر مثلا صفحه‌ای FullHD باشه کیفیتش خوبه. اما این همه‌ی ماجرا نیست!
1. برای اینکه کیفیت نمایش بالا بره باید چگالی پیکسل‌های صفحه یا Pixels Per Inch بیشتر باشه. مثلا یه مانیتور 24 اینچ FullHD دارای 92 پیکس در هر اینچه در صورتی که مانیتور 27 اینچ دارای 82 پیکسل در هر اینچه و کیفیتش از 24 اینچ کمتره. هرچه PPI بیشتر باشه، جزئیات بهتر نمایش داده میشه و کیفیتش بالاتر میره.
2. دومین موردی که مهمه فاصله‌ی چشم ما تا ماینتوره، هرچقدر ما صفحه رو نزدیک‌تر به چشممون بذاریم پیکسل‌هاش بیشتر توی چشم میزنه و کیفیت پایین‌تر جلوه میکنه. برای همینه که چگالی پیکسل توی گوشی‌های موبایل معمولا از مانیتورها خیلی بیشتره. چون آدما صفحه‌ی موبایل رو خیلی نزدیک به چشم میگیرن و اگر PPI پایین باشه به راحتی پیکسل‌های تصویر مشخص میشه و توی ذوق میزنه. اگر فاصلتون از صفحه به حدی باشه که چشمتون نتونه پیکسل‌ها رو از هم تشخیص بده، اصطلاحا میگن شما در فاصله Retina هستید. این کلمه توسط اپل معرفی شده. برای اینکه یه صفحه‌ی 24 اینچ FullHD به صورت رتینا به نظر برسه شما باید از فاصله 94 سانتی متری بهش نگاه کنید!
3. سومین موردی که مهمه میزان refresh rate مانیتور هست که با واحد Frame per second سنجیده میشه. هرچقدر FPS بالاتر باشه تغییرات رو نرمتر و روونتر می‌بینید. این قضیه مخصوصا برای زمانی که دارید متن‌ها رو اسکرول میکنید به چشم میاد.
حالا مطلب بالا به صورت کامل نکات مهم رو توضیح میده و درنهایت توصیه‌های زیر رو میکنه:
- مانیتور حداقل 4K باشه
- حداقل FPS برابر با 120hz باشه
- از Integer Scaling استفاده کنید(توضیح کاملش توی متن هست. من برای بزرگ نشدن پست اینجا توضیحش نمی‌دم)
پیشنهاد خودم اینه که ماینتور 27 اینچ باشه. چون نه خیلی کوچیکه نه خیلی بزرگ. همچنین برای اینکه صفحه رتینا به نظر بیاد باید فاصله 53 سانتی از مانیتور داشته باشید که فاصله نرمالیه برای یه مانیتور. توی سایت زیر توضیحات کاملی در مورد PPI و فاصله retina وجود داره. عکس جدول فواصل رو توی پست گذاشتم.
لینک
تجربه‌ی شما توی این زمینه چیه؟ چقدر موافقید با این مطلب؟
✴️ @software_inside - مهندسی‌نرم‌افزار
Time to upgrade your monitor
https://tonsky.me/blog/monitors/
یکی از چیزایی که مهمه Text Clarity و کیفیت نمایش متن‌هاست. خیلیا فک میکنن resolution تنها ملاک کیفیته و اگر مثلا صفحه‌ای FullHD باشه کیفیتش خوبه. اما این همه‌ی ماجرا نیست!
1. برای اینکه کیفیت نمایش بالا بره باید چگالی پیکسل‌های صفحه یا Pixels Per Inch بیشتر باشه. مثلا یه مانیتور 24 اینچ FullHD دارای 92 پیکس در هر اینچه در صورتی که مانیتور 27 اینچ دارای 82 پیکسل در هر اینچه و کیفیتش از 24 اینچ کمتره. هرچه PPI بیشتر باشه، جزئیات بهتر نمایش داده میشه و کیفیتش بالاتر میره.
2. دومین موردی که مهمه فاصله‌ی چشم ما تا ماینتوره، هرچقدر ما صفحه رو نزدیک‌تر به چشممون بذاریم پیکسل‌هاش بیشتر توی چشم میزنه و کیفیت پایین‌تر جلوه میکنه. برای همینه که چگالی پیکسل توی گوشی‌های موبایل معمولا از مانیتورها خیلی بیشتره. چون آدما صفحه‌ی موبایل رو خیلی نزدیک به چشم میگیرن و اگر PPI پایین باشه به راحتی پیکسل‌های تصویر مشخص میشه و توی ذوق میزنه. اگر فاصلتون از صفحه به حدی باشه که چشمتون نتونه پیکسل‌ها رو از هم تشخیص بده، اصطلاحا میگن شما در فاصله Retina هستید. این کلمه توسط اپل معرفی شده. برای اینکه یه صفحه‌ی 24 اینچ FullHD به صورت رتینا به نظر برسه شما باید از فاصله 94 سانتی متری بهش نگاه کنید!
3. سومین موردی که مهمه میزان refresh rate مانیتور هست که با واحد Frame per second سنجیده میشه. هرچقدر FPS بالاتر باشه تغییرات رو نرمتر و روونتر می‌بینید. این قضیه مخصوصا برای زمانی که دارید متن‌ها رو اسکرول میکنید به چشم میاد.
حالا مطلب بالا به صورت کامل نکات مهم رو توضیح میده و درنهایت توصیه‌های زیر رو میکنه:
- مانیتور حداقل 4K باشه
- حداقل FPS برابر با 120hz باشه
- از Integer Scaling استفاده کنید(توضیح کاملش توی متن هست. من برای بزرگ نشدن پست اینجا توضیحش نمی‌دم)
پیشنهاد خودم اینه که ماینتور 27 اینچ باشه. چون نه خیلی کوچیکه نه خیلی بزرگ. همچنین برای اینکه صفحه رتینا به نظر بیاد باید فاصله 53 سانتی از مانیتور داشته باشید که فاصله نرمالیه برای یه مانیتور. توی سایت زیر توضیحات کاملی در مورد PPI و فاصله retina وجود داره. عکس جدول فواصل رو توی پست گذاشتم.
لینک
تجربه‌ی شما توی این زمینه چیه؟ چقدر موافقید با این مطلب؟
✴️ @software_inside - مهندسی‌نرم‌افزار
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👌2
Forwarded from LLM Engineers
یه بحثی که همیشه داغه، این همه عنوان شغلی تو حوزه AI از کجا میاد و فرقشون چیه. خیلی از این عناوین یا توسط HRها ساخته شدن یا صرفاً برای هایپ و جذب نیرو هستن. واقعیت اینه که مرز بین این نقش‌ها خیلی باریکه و تو شرکت‌های مختلف، شرح وظایف یه AI Engineer میتونه زمین تا آسمون فرق کنه. اینجا سعی میکنم یه دسته‌بندی منطقی و به دور از هایپ از این نقش‌ها بدم.
هسته‌ی فنی و مهندسی (The Core Engineers)
اینجا با نقش‌هایی طرفیم که بیس کار AI رو تشکیل میدن و بیشترین هم‌پوشانی رو دارن.
ML Engineer:
میشه گفت این اصلی‌ترین و جاافتاده‌ترین عنوانه. کارش ساخت، آموزش و دیپلوی مدل‌های machine learning هست. از ساخت data pipeline گرفته تا training و مانیتورینگ مدل تو پروداکشن، همه با این شخصه. ابزارهاش هم Python، فریمورک‌هایی مثل PyTorch و TensorFlow و ابزارهای MLOps هست.
AI Engineer:
این عنوان یه کم کلی‌تر از ML Engineer هست. یه AI Engineer ممکنه روی سیستم‌های AI که لزوماً learning-based نیستن هم کار کنه (مثلاً سیستم‌های rule-based یا optimization). اما در عمل، ۹۰ درصد مواقع شرکت‌ها از این عنوان به جای ML Engineer استفاده میکنن و فرق خاصی بینشون نیست.
Deep Learning Engineer:
این یه تخصص از ML Engineer به حساب میاد. تمرکزش فقط روی شبکه‌های عصبی عمیق و معماری‌های پیچیده‌ست. این افراد معمولاً روی مسائل Computer Vision یا NLP کار میکنن که مدل‌های ساده جواب نمیدن. باید درک عمیقی از GPU، بهینه‌سازی و ریاضیات پشت این مدل‌ها داشته باشه.
بچه‌های پروداکت و نرم‌افزار (The Application Layer)
این گروه کارشون اینه که AI رو از فاز تئوری و مدل، بیارن تو دل یه محصول واقعی.
Applied AI Engineer:
این عنوان یعنی «بیا این مدل رو بردار و یه مشکل واقعی تو بیزینس رو باهاش حل کن». تفاوتش با ML Engineer اینه که تمرکزش روی کاربرد و بیزینسه، نه لزوماً ساخت بهترین مدل. باید دانش دامنه (مثلاً مالی یا پزشکی) داشته باشه و بتونه سریع prototype بسازه.
AI Software Engineer:
این یه مهندس نرم‌افزاره که AI هم بلده. کار اصلیش software engineering هست ولی میتونه مدل‌های آماده رو تو یه اپلیکیشن بزرگ‌تر ادغام کنه. کدنویسی تمیز، معماری نرم‌افزار و کار با APIها براش مهم‌تر از خودِ الگوریتم‌هاست.
موج جدید: متخصص‌های GenAI و LLM
اینا نقش‌هایی هستن که با ظهور Generative AI و LLMها به وجود اومدن و هنوز خیلی‌هاشون به بلوغ نرسیدن.
LLM Engineer:
کار این شخص تماماً حول Large Language Models می‌گرده. از fine-tuning کردن مدل‌ها با تکنیک‌های PEFT مثل LoRA گرفته تا بهینه‌سازی inference و کار با ابزارهای مرتبط. این نقش الان خیلی رو بورسه.
AI Agent Developer:
این نقش روی ساخت ایجنت‌های هوشمند و خودمختار تمرکز داره که میتونن با استفاده از LLM و ابزارهای دیگه، وظایف چندمرحله‌ای رو انجام بدن. کار با فریمورک‌هایی مثل LangChain یا ساخت سیستم‌های planning و reasoning جزو کارشونه.
زیرساخت و عملیات (The Infrastructure & Ops)
اینا کسایی هستن که چرخ‌دنده‌های سیستم‌های AI رو روغن‌کاری میکنن تا همه چیز روان کار کنه.
MLOps Engineer:
این شخص مسئول اتوماسیون و مدیریت چرخه حیات مدل‌های ML هست. کارش ساخت CI/CD pipeline برای مدل‌ها، مانیتورینگ، ورژن‌بندی و تضمین scalability اونهاست. با ابزارهایی مثل Kubernetes، Kubeflow و Prometheus سر و کار داره. مدل نمیسازه، ولی کمک میکنه مدل‌ها به درستی دیپلوی بشن و زنده بمونن.
LLMOps Engineer:
این همون MLOps هست ولی برای دنیای LLMها. چالش‌های LLMها مثل هزینه‌های سرسام‌آور inference، مدیریت پرامپت‌ها و مانیتورینگ hallucination باعث شده این تخصص جدید به وجود بیاد.
استراتژیست‌ها و محقق‌ها (The Big Picture & Research)
این گروه یا در لبه‌ی دانش حرکت میکنن یا تصویر بزرگ سیستم رو طراحی میکنن.
AI Researcher / Research Scientist:
کارش تحقیق و توسعه‌ی الگوریتم‌ها و روش‌های جدیده. این افراد معمولاً درگیر انتشار مقاله و کارهای آکادمیک هستن و کمتر با پروداکشن درگیرن. معمولاً مدرک دکترا دارن و ریاضیشون خیلی قویه.
Data Scientist:
این نقش بیشتر به تحلیل داده و کشف insight مرتبطه تا مهندسی. از ML استفاده میکنه تا الگوها رو پیدا کنه و به سوالات بیزینس جواب بده. خروجیش معمولاً گزارش، داشبورد و مدل‌های پیش‌بینی‌کننده‌ست، نه یه سیستم نرم‌افزاری production-grade.
در نهایت، این عناوین فقط برچسب هستن. مهم اینه که شما روی مهارت‌های اصلی مثل برنامه‌نویسی، درک عمیق الگوریتم‌ها و مهندسی نرم‌افزار تمرکز کنید. این مهارت‌ها همیشه ارزشمندن، حتی اگه فردا عنوان شغلی جدیدی مد بشه.
🛠 Join @LLMEngineers Community
هسته‌ی فنی و مهندسی (The Core Engineers)
اینجا با نقش‌هایی طرفیم که بیس کار AI رو تشکیل میدن و بیشترین هم‌پوشانی رو دارن.
ML Engineer:
میشه گفت این اصلی‌ترین و جاافتاده‌ترین عنوانه. کارش ساخت، آموزش و دیپلوی مدل‌های machine learning هست. از ساخت data pipeline گرفته تا training و مانیتورینگ مدل تو پروداکشن، همه با این شخصه. ابزارهاش هم Python، فریمورک‌هایی مثل PyTorch و TensorFlow و ابزارهای MLOps هست.
AI Engineer:
این عنوان یه کم کلی‌تر از ML Engineer هست. یه AI Engineer ممکنه روی سیستم‌های AI که لزوماً learning-based نیستن هم کار کنه (مثلاً سیستم‌های rule-based یا optimization). اما در عمل، ۹۰ درصد مواقع شرکت‌ها از این عنوان به جای ML Engineer استفاده میکنن و فرق خاصی بینشون نیست.
Deep Learning Engineer:
این یه تخصص از ML Engineer به حساب میاد. تمرکزش فقط روی شبکه‌های عصبی عمیق و معماری‌های پیچیده‌ست. این افراد معمولاً روی مسائل Computer Vision یا NLP کار میکنن که مدل‌های ساده جواب نمیدن. باید درک عمیقی از GPU، بهینه‌سازی و ریاضیات پشت این مدل‌ها داشته باشه.
بچه‌های پروداکت و نرم‌افزار (The Application Layer)
این گروه کارشون اینه که AI رو از فاز تئوری و مدل، بیارن تو دل یه محصول واقعی.
Applied AI Engineer:
این عنوان یعنی «بیا این مدل رو بردار و یه مشکل واقعی تو بیزینس رو باهاش حل کن». تفاوتش با ML Engineer اینه که تمرکزش روی کاربرد و بیزینسه، نه لزوماً ساخت بهترین مدل. باید دانش دامنه (مثلاً مالی یا پزشکی) داشته باشه و بتونه سریع prototype بسازه.
AI Software Engineer:
این یه مهندس نرم‌افزاره که AI هم بلده. کار اصلیش software engineering هست ولی میتونه مدل‌های آماده رو تو یه اپلیکیشن بزرگ‌تر ادغام کنه. کدنویسی تمیز، معماری نرم‌افزار و کار با APIها براش مهم‌تر از خودِ الگوریتم‌هاست.
موج جدید: متخصص‌های GenAI و LLM
اینا نقش‌هایی هستن که با ظهور Generative AI و LLMها به وجود اومدن و هنوز خیلی‌هاشون به بلوغ نرسیدن.
LLM Engineer:
کار این شخص تماماً حول Large Language Models می‌گرده. از fine-tuning کردن مدل‌ها با تکنیک‌های PEFT مثل LoRA گرفته تا بهینه‌سازی inference و کار با ابزارهای مرتبط. این نقش الان خیلی رو بورسه.
AI Agent Developer:
این نقش روی ساخت ایجنت‌های هوشمند و خودمختار تمرکز داره که میتونن با استفاده از LLM و ابزارهای دیگه، وظایف چندمرحله‌ای رو انجام بدن. کار با فریمورک‌هایی مثل LangChain یا ساخت سیستم‌های planning و reasoning جزو کارشونه.
زیرساخت و عملیات (The Infrastructure & Ops)
اینا کسایی هستن که چرخ‌دنده‌های سیستم‌های AI رو روغن‌کاری میکنن تا همه چیز روان کار کنه.
MLOps Engineer:
این شخص مسئول اتوماسیون و مدیریت چرخه حیات مدل‌های ML هست. کارش ساخت CI/CD pipeline برای مدل‌ها، مانیتورینگ، ورژن‌بندی و تضمین scalability اونهاست. با ابزارهایی مثل Kubernetes، Kubeflow و Prometheus سر و کار داره. مدل نمیسازه، ولی کمک میکنه مدل‌ها به درستی دیپلوی بشن و زنده بمونن.
LLMOps Engineer:
این همون MLOps هست ولی برای دنیای LLMها. چالش‌های LLMها مثل هزینه‌های سرسام‌آور inference، مدیریت پرامپت‌ها و مانیتورینگ hallucination باعث شده این تخصص جدید به وجود بیاد.
استراتژیست‌ها و محقق‌ها (The Big Picture & Research)
این گروه یا در لبه‌ی دانش حرکت میکنن یا تصویر بزرگ سیستم رو طراحی میکنن.
AI Researcher / Research Scientist:
کارش تحقیق و توسعه‌ی الگوریتم‌ها و روش‌های جدیده. این افراد معمولاً درگیر انتشار مقاله و کارهای آکادمیک هستن و کمتر با پروداکشن درگیرن. معمولاً مدرک دکترا دارن و ریاضیشون خیلی قویه.
Data Scientist:
این نقش بیشتر به تحلیل داده و کشف insight مرتبطه تا مهندسی. از ML استفاده میکنه تا الگوها رو پیدا کنه و به سوالات بیزینس جواب بده. خروجیش معمولاً گزارش، داشبورد و مدل‌های پیش‌بینی‌کننده‌ست، نه یه سیستم نرم‌افزاری production-grade.
در نهایت، این عناوین فقط برچسب هستن. مهم اینه که شما روی مهارت‌های اصلی مثل برنامه‌نویسی، درک عمیق الگوریتم‌ها و مهندسی نرم‌افزار تمرکز کنید. این مهارت‌ها همیشه ارزشمندن، حتی اگه فردا عنوان شغلی جدیدی مد بشه.
🛠 Join @LLMEngineers Community
👌1