#مطلب
HBase Deprecation at Pinterest
در سال‌های اخیر HBase نقش کلیدی و جدی توی زیرساخت Pinterest داشته و بسیاری از سرویس‌های پینترست بر مبنای HBase بنا شده بوده. برای مثال پینترست بر روی Hbase دیتابیس Zen رو ساخته بوده که داده‌های گرافی رو نگه میداره، از OpenTSDB که باز یه دیتابیس رو HBase هست برای نگهداری داده‌های TimeSeries استفاده می‌کرده و ...
اما اخیرا یه پستی توی بلاگ فنیشون گذاشتن که قراره HBase رو بازنشسته کنن و به جاش مهاجرت کنن به دیتابیس‌های جدیدتر. قرارشده داده‌های OLAP رو به Druid/Starrocks و داده‌های KeyValue رو به KVStore و داده‌های گرافی رو به Goku منتقل کنن(دوتای آخری دیتابیس‌های درونی خود پینترست هست).
و برای باقی نیازمندی‌هاشون قراره داده‌های Hbase رو مهاجرت بدن به یه NewSQL به اسم TiDB.
دلیلی که دارن HBase رو بازنشسته میکنن هزینه‌ی زیاد نگهداری، کمبود امکانات لازم ( مثل Secondary Index و distributed transactions) و کوچیک‌شدن کامیونیتی و پیدانشدن نیروهای expert هست(qoute پایین از مقاله در همین مورد جالبه).
لینک مقالات:
Part1: HBase Deprecation at Pinterest
Part2: TiDB Adoption at Pinterest
Part3: Structured DataStore (SDS): Multi-model Data Management With a Unified Serving Stack
Online Data Migration from HBase to TiDB with Zero Downtime
✴️ @software_inside - مهندسی‌نرم‌افزار
HBase Deprecation at Pinterest
در سال‌های اخیر HBase نقش کلیدی و جدی توی زیرساخت Pinterest داشته و بسیاری از سرویس‌های پینترست بر مبنای HBase بنا شده بوده. برای مثال پینترست بر روی Hbase دیتابیس Zen رو ساخته بوده که داده‌های گرافی رو نگه میداره، از OpenTSDB که باز یه دیتابیس رو HBase هست برای نگهداری داده‌های TimeSeries استفاده می‌کرده و ...
اما اخیرا یه پستی توی بلاگ فنیشون گذاشتن که قراره HBase رو بازنشسته کنن و به جاش مهاجرت کنن به دیتابیس‌های جدیدتر. قرارشده داده‌های OLAP رو به Druid/Starrocks و داده‌های KeyValue رو به KVStore و داده‌های گرافی رو به Goku منتقل کنن(دوتای آخری دیتابیس‌های درونی خود پینترست هست).
و برای باقی نیازمندی‌هاشون قراره داده‌های Hbase رو مهاجرت بدن به یه NewSQL به اسم TiDB.
دلیلی که دارن HBase رو بازنشسته میکنن هزینه‌ی زیاد نگهداری، کمبود امکانات لازم ( مثل Secondary Index و distributed transactions) و کوچیک‌شدن کامیونیتی و پیدانشدن نیروهای expert هست(qoute پایین از مقاله در همین مورد جالبه).
For the past few years, we have seen a seemingly steady decline in HBase usage and community activity in the industry, as many peer companies were looking for better alternatives to replace HBase in their production environments. This in turn has led to a shrinking talent pool, higher barrier to entry, and lower incentive for new engineers to become a subject matter expert of HBase.
لینک مقالات:
Part1: HBase Deprecation at Pinterest
Part2: TiDB Adoption at Pinterest
Part3: Structured DataStore (SDS): Multi-model Data Management With a Unified Serving Stack
Online Data Migration from HBase to TiDB with Zero Downtime
✴️ @software_inside - مهندسی‌نرم‌افزار
Medium
HBase Deprecation at Pinterest
Alberto Ordonez Pereira | Senior Staff Software Engineer; Lianghong Xu | Senior Manager, Engineering;
👍2
#بازی
https://www.sqlnoir.com/
یه بازی باحال که شما در نقش کارآگاه هستید و با زدن SQL query و گشتن توی جدول‌های دیتابیس باید معماها رو حل کنید.
برای تقویت raw sql زدن خوبه.
https://www.sqlnoir.com/
یه بازی باحال که شما در نقش کارآگاه هستید و با زدن SQL query و گشتن توی جدول‌های دیتابیس باید معماها رو حل کنید.
برای تقویت raw sql زدن خوبه.
Sqlnoir
SQL Noir - Interactive SQL Game | Learn SQL by Solving Crimes
Master SQL with SQL Noir - the interactive SQL game where you solve crimes using database queries. Perfect SQL game for beginners and experts alike.
🔥5
#ابزار
برای اینکه متوجه بشیم یه کوئری روی دیتابیس چطوری داره اجرا میشه یا چرا کنده معمولا از اون کوئری explain می‌گیریم و سعی می‌کنیم از روی خروجی explain این چیزا رو متوجه بشیم.
متاسفانه خوندن خروجی خام این دستور مخصوصا وقتی پارامترهایی مثل analyze یا buffer و ... رو استفاده کردیم خیلی کار ساده‌ای نیست و خروجیش ممکنه خیلی بزرگ بشه. برای مثال یه نمونه از خروجی خام رو توی عکس‌ها می‌بینید.
https://explain.dalibo.com
https://explain.depesz.com/
دوتا سایت بالا با گرفتن خروجی explain، گزارش‌های خوبی تولید میکنه و باعث میشه راحت‌تر متوجه بشیم چه اتفاقی داره میافته. مخصوصا سایت اولی که به صورت گرافیکی نمودار می‌کشه و interactive هم هست.
برای اینکه متوجه بشیم یه کوئری روی دیتابیس چطوری داره اجرا میشه یا چرا کنده معمولا از اون کوئری explain می‌گیریم و سعی می‌کنیم از روی خروجی explain این چیزا رو متوجه بشیم.
متاسفانه خوندن خروجی خام این دستور مخصوصا وقتی پارامترهایی مثل analyze یا buffer و ... رو استفاده کردیم خیلی کار ساده‌ای نیست و خروجیش ممکنه خیلی بزرگ بشه. برای مثال یه نمونه از خروجی خام رو توی عکس‌ها می‌بینید.
https://explain.dalibo.com
https://explain.depesz.com/
دوتا سایت بالا با گرفتن خروجی explain، گزارش‌های خوبی تولید میکنه و باعث میشه راحت‌تر متوجه بشیم چه اتفاقی داره میافته. مخصوصا سایت اولی که به صورت گرافیکی نمودار می‌کشه و interactive هم هست.
👌3
مهندسی نرم‌افزار - Software Inside
#ابزار برای اینکه متوجه بشیم یه کوئری روی دیتابیس چطوری داره اجرا میشه یا چرا کنده معمولا از اون کوئری explain می‌گیریم و سعی می‌کنیم از روی خروجی explain این چیزا رو متوجه بشیم. متاسفانه خوندن خروجی خام این دستور مخصوصا وقتی پارامترهایی مثل analyze یا buffer…
#مقاله #بلاگ #postgres
Explaining the unexplainable
اون فردی که ابزار دومی توی پست بالا رو ساخته، یه وبلاگ فنی خیلی خوب هم داره که به صورت تخصصی در مورد Postgres می‌نویسه و کلی مطلب خفن داره. یکی از مطالبش که به نظرم خیلی خوب بود مجموعه پست‌هایی تحت عنوان «Explaining the unexplainable» هست که میاد از ابتدا شروع میکنه و توضیح میده که دستور EXPLAIN توی پستگرس چیه و چطوری کار میکنه و تا سطح پیشرفته پیش میره.
برای کسایی که میخوان tune کردن کوئری‌ها و اپتیمایز کردن رو یاد بگیرن خیلی مفید میتونه باشه. کلا 6 بخش ازش منتشر شده که از طریق صفحه‌ی پایین می‌تونید پیداشون کنید:
https://www.depesz.com/tag/unexplainable/
✴️ @software_inside - مهندسی‌نرم‌افزار
Explaining the unexplainable
اون فردی که ابزار دومی توی پست بالا رو ساخته، یه وبلاگ فنی خیلی خوب هم داره که به صورت تخصصی در مورد Postgres می‌نویسه و کلی مطلب خفن داره. یکی از مطالبش که به نظرم خیلی خوب بود مجموعه پست‌هایی تحت عنوان «Explaining the unexplainable» هست که میاد از ابتدا شروع میکنه و توضیح میده که دستور EXPLAIN توی پستگرس چیه و چطوری کار میکنه و تا سطح پیشرفته پیش میره.
برای کسایی که میخوان tune کردن کوئری‌ها و اپتیمایز کردن رو یاد بگیرن خیلی مفید میتونه باشه. کلا 6 بخش ازش منتشر شده که از طریق صفحه‌ی پایین می‌تونید پیداشون کنید:
https://www.depesz.com/tag/unexplainable/
✴️ @software_inside - مهندسی‌نرم‌افزار
🤯3
#معرفی #serialization
MsgPack: It's like JSON but fast and small.
یه فرمت کمتر شناخته شده‌ای وجود داره به اسم MsgPack که بعضا توی طراحی سیستم‌ها به کار میاد.
این فرمت شبیه به JSON هست و بدون Schema کار میکنه. دوتا مزیت داره: یکی اینکه حجمش کمتره و compact تر هست و مزیت بزرگ دومش اینه که به صورت binary هست و برخلاف JSON لازم نیست حتما داده‌ها UTF8 باشن و decode شده باشن. همین قضیه باعث میشه که سرعت serialize شدنش بیشتر باشه و داده های خام رو هم می‌تونیم باهاش جابجا کنیم. برای دید بهتر به عکس بالا توجه کنید. بدیش اینه که human-readable نیست.
این فرمت توی تکنولوژی‌هایی مثل redis یا fluentd هم استفاده میشه و جاهایی که انعطاف برامون مهمه و human-readable بودن برامون مهم نیست یا میخوایم داده‌های binary و دیکد نشده جابجا کنیم به کار میاد.
❇️ @software_inside
MsgPack: It's like JSON but fast and small.
یه فرمت کمتر شناخته شده‌ای وجود داره به اسم MsgPack که بعضا توی طراحی سیستم‌ها به کار میاد.
این فرمت شبیه به JSON هست و بدون Schema کار میکنه. دوتا مزیت داره: یکی اینکه حجمش کمتره و compact تر هست و مزیت بزرگ دومش اینه که به صورت binary هست و برخلاف JSON لازم نیست حتما داده‌ها UTF8 باشن و decode شده باشن. همین قضیه باعث میشه که سرعت serialize شدنش بیشتر باشه و داده های خام رو هم می‌تونیم باهاش جابجا کنیم. برای دید بهتر به عکس بالا توجه کنید. بدیش اینه که human-readable نیست.
این فرمت توی تکنولوژی‌هایی مثل redis یا fluentd هم استفاده میشه و جاهایی که انعطاف برامون مهمه و human-readable بودن برامون مهم نیست یا میخوایم داده‌های binary و دیکد نشده جابجا کنیم به کار میاد.
❇️ @software_inside
👍6
#مطلب
What I Wish I Knew About Onboarding Effectively
https://eugeneyan.com/writing/onboarding/
زمانی که شرکتتون رو عوض میکنید و وارد یه شرکت جدید میشید باید یه فرایندی طی بشه تا شما با اون شرکت، کدهاش و فرهنگش آشنا بشید. به این فرایند میگن آنبوردینگ.
مطلب بالا نکات خیلی خوبی در همین مورد بیان میکنه که باعث میشه این فرایند رو بهتر بتونیم طی کنیم و توی شرکت جدید بهتر جا بیافتیم. اگر دارید آنبورد میشید یا قراره یه نفر دیگه رو آنبورد کنید این مطلب به شدت پیشنهاد میشه.
✴️ @software_inside - مهندسی‌نرم‌افزار
What I Wish I Knew About Onboarding Effectively
https://eugeneyan.com/writing/onboarding/
زمانی که شرکتتون رو عوض میکنید و وارد یه شرکت جدید میشید باید یه فرایندی طی بشه تا شما با اون شرکت، کدهاش و فرهنگش آشنا بشید. به این فرایند میگن آنبوردینگ.
مطلب بالا نکات خیلی خوبی در همین مورد بیان میکنه که باعث میشه این فرایند رو بهتر بتونیم طی کنیم و توی شرکت جدید بهتر جا بیافتیم. اگر دارید آنبورد میشید یا قراره یه نفر دیگه رو آنبورد کنید این مطلب به شدت پیشنهاد میشه.
✴️ @software_inside - مهندسی‌نرم‌افزار
eugeneyan.com
What I Wish I Knew About Onboarding Effectively
Mindset, 100-day plan, and balancing learning and taking action to earn trust.
👏2👌2❤1
#مطلب #Redis
Redis 8 is GA
Redis is Open Source Again
دوتا خبر مهم در مورد ردیس منتشر شده:
۱- انتشار نسخه‌ی 8 ردیس:
- قابلیت‌هایی که قبلا تحت عنوان Redis Stack به صورت پولی فروخته می‌شد الان به صورت رایگان به نسخه‌ی OSS اضافه شده. قابلیت ذخیره سازی داده‌های Time Series یا JSON و کلی داده‌ساختار جدید دیگه اضافه شده. همچنین Redis Query Engine هم رایگان شده که اجازه میده Secondary Index بسازیم و حتی روی داده‌ها Full-Text Search هم بزنیم.
- این نسخه سریع‌ترین ردیسی هست که تا به حال داشتیم و خودشون ادعا میکنن بعضی از کامندها تا 80٪ هم سریع‌تر شده همچنین Throughput هم تا دوبرابر میتونه بهتر بشه.
- با ترند شدن AI و فراگیر شدن LLM ها، دیتابیس‌های vector based هم رونق گرفتن و ردیس هم از قافله جا نمونده. یه داده‌ساختار جدید به اسم VectorSet اضافه کرده که به ما اجازه میده embedding ها رو توش ذخیره کنیم و Vector Search انجام بدیم.
۲- ردیس لایسنسش رو دوباره عوض کرد و از لایسنس اوپن سورس استفاده میکنه:
داستان اینه که شرکت‌های بزرگ ابری مثل AWS و Google Cloud میان ابزارهای اوپن‌سورس رو به عنوان خدمت ارائه میدن و ازش پول درمیارن اما پولی به اون توسعه‌دهنگان اصلی که دارن اون نرم‌افزار رو توسعه میدن پرداخت نمی‌کنن. همین قضیه باعث شده که نرم‌افزارهای اوپن سورس به فکر تغییر لایسنس بیافتن. مثلا قبل از ردیس، MongoDB و Elasticsearch هم لایسنسشون رو به SSPL تغییر داده بودن.
لایسنس SSPL میگه که اگر میخوای نرم‌افزار منو به عنوان سرویس ارائه بدی باید سورس کد کل سرویست رو منتشر کنی(از رابط کاربری گرفته تا ابزارهای مدیریتی و همه‌ی چیزای مربوطه). این لایسنس OpenSource محسوب نمیشه و همین باعث شد که کامیونیتی انتقادات زیادی رو متوجه این نرم‌افزارها بکنن و برن سراغ اینکه یه فورک اوپن سورس درست کنن. طبیعتا شرکت‌های بزرگ هم از این فورک‌های اوپن سورس حمایت کردن. مثلا Valkey که فورک ردیسه یا OpenSearchکه فورک Elastic هست سر همین داستانا به وجود اومدن.
حالا ردیس اومده نسخه‌ی 8 رو با لایسنس AGPLv3 ارائه کرده که یک لایسنس اوپن‌سورس محسوب میشه و به نسبت SSPL سخت‌گیری کمتری داره. قبل از ردیس الستیک سرچ هم لایسنسش رو برگردونده بود و اونم اوپن سورس شده بود دوباره.
برای جزئیات بیشتر می‌تونید به لینک مطالبی که در بالای پست قراره گرفته مراجعه کنید.
✴️ @software_inside - مهندسی‌نرم‌افزار
Redis 8 is GA
Redis is Open Source Again
دوتا خبر مهم در مورد ردیس منتشر شده:
۱- انتشار نسخه‌ی 8 ردیس:
- قابلیت‌هایی که قبلا تحت عنوان Redis Stack به صورت پولی فروخته می‌شد الان به صورت رایگان به نسخه‌ی OSS اضافه شده. قابلیت ذخیره سازی داده‌های Time Series یا JSON و کلی داده‌ساختار جدید دیگه اضافه شده. همچنین Redis Query Engine هم رایگان شده که اجازه میده Secondary Index بسازیم و حتی روی داده‌ها Full-Text Search هم بزنیم.
- این نسخه سریع‌ترین ردیسی هست که تا به حال داشتیم و خودشون ادعا میکنن بعضی از کامندها تا 80٪ هم سریع‌تر شده همچنین Throughput هم تا دوبرابر میتونه بهتر بشه.
- با ترند شدن AI و فراگیر شدن LLM ها، دیتابیس‌های vector based هم رونق گرفتن و ردیس هم از قافله جا نمونده. یه داده‌ساختار جدید به اسم VectorSet اضافه کرده که به ما اجازه میده embedding ها رو توش ذخیره کنیم و Vector Search انجام بدیم.
۲- ردیس لایسنسش رو دوباره عوض کرد و از لایسنس اوپن سورس استفاده میکنه:
داستان اینه که شرکت‌های بزرگ ابری مثل AWS و Google Cloud میان ابزارهای اوپن‌سورس رو به عنوان خدمت ارائه میدن و ازش پول درمیارن اما پولی به اون توسعه‌دهنگان اصلی که دارن اون نرم‌افزار رو توسعه میدن پرداخت نمی‌کنن. همین قضیه باعث شده که نرم‌افزارهای اوپن سورس به فکر تغییر لایسنس بیافتن. مثلا قبل از ردیس، MongoDB و Elasticsearch هم لایسنسشون رو به SSPL تغییر داده بودن.
لایسنس SSPL میگه که اگر میخوای نرم‌افزار منو به عنوان سرویس ارائه بدی باید سورس کد کل سرویست رو منتشر کنی(از رابط کاربری گرفته تا ابزارهای مدیریتی و همه‌ی چیزای مربوطه). این لایسنس OpenSource محسوب نمیشه و همین باعث شد که کامیونیتی انتقادات زیادی رو متوجه این نرم‌افزارها بکنن و برن سراغ اینکه یه فورک اوپن سورس درست کنن. طبیعتا شرکت‌های بزرگ هم از این فورک‌های اوپن سورس حمایت کردن. مثلا Valkey که فورک ردیسه یا OpenSearchکه فورک Elastic هست سر همین داستانا به وجود اومدن.
حالا ردیس اومده نسخه‌ی 8 رو با لایسنس AGPLv3 ارائه کرده که یک لایسنس اوپن‌سورس محسوب میشه و به نسبت SSPL سخت‌گیری کمتری داره. قبل از ردیس الستیک سرچ هم لایسنسش رو برگردونده بود و اونم اوپن سورس شده بود دوباره.
برای جزئیات بیشتر می‌تونید به لینک مطالبی که در بالای پست قراره گرفته مراجعه کنید.
✴️ @software_inside - مهندسی‌نرم‌افزار
Redis
Redis 8 is now GA, loaded with new features and more than 30 performance improvements | Redis
Developers love Redis. Unlock the full potential of the Redis database with Redis Enterprise and start building blazing fast apps.
🔥7👍3💯1
#مطلب
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