دیتاهاب

درود خیلی وقت بود دوره جدید ضبط نکرده بودم. تابستون امسال بود. وسط کلی ناامیدی و ترس از اینکه نکنه دوباره جنگ بشه، یهو به این فکر افتادم: این دو سه سال تجربه از پروژه‌های صنعتی و تحقیقاتی رو چرا جمع نکنم تو یه دوره جمع‌وجور و به درد بخور؟ نمی‌دونم چرا، ولی این بار دلم خواست تصویرم هم باشه. 🎥 با پیشنهاد مجموعه آیتک رفتیم استودیو و وسط گرمای تیر شروع کردیم به ضبط. اولین تجربه همکاریم با مکتب‌خونه بود. حالا دوره آماده‌ست.🥰 لینک دوره

نمونه‌کار باید لینک قابل کلیک داشته باشه، نه چیز ثابت خشک و نوشته ای. وقتی کسی رزومه یا پروژه‌ت رو می‌بینه، معمولاً حوصله نداره مخزن رو کلون کنه، وابستگی‌ها رو نصب کنه تا شاید اجرا بشه. بهترین حالت اینه که یک لینک بدی و طرف با یک کلیک نتیجه رو ببینه. چند گزینه رایگان و محبوب برای این کار: گزینه اول: Hugging Face Spaces برای دموی مدل‌های یادگیری ماشین، چت‌بات‌ها و اپلیکیشن‌های ساخته‌شده با Gradio و Streamlit عالیه. گزینه دوم: Render برای سرویس‌های وب، APIها و پروژه‌های بک‌اند گزینه خوبیه. نسخه رایگان داره و برای نمونه‌کار کاملاً کافیه. گزینه سوم: Railway راه‌اندازی ساده‌ای داره و برای استقرار سریع پروژه‌ها خیلی محبوبه. البته مثل خیلی از سرویس‌های رایگان ممکنه مدتی بدون استفاده بمونه و اصطلاحاً خواب سرد داشته باشه. گزینه چهارم: GitHub Pages اگر داشبورد استاتیک، مستندات پروژه یا سایت شخصی داریم، یکی از ساده‌ترین گزینه‌هاست. گزینه پنجم: Vercel انتخاب محبوب توسعه‌دهنده‌های فرانت‌اند، مخصوصاً برای پروژه‌های Next.js، React و سایت‌های مدرن. استقرارش هم معمولاً فقط چند دقیقه زمان می‌بره. گزینه آخر: Streamlit Community Cloud اگر پروژه‌مون تحلیلی، داده‌محور یا مربوط به علم داده و هوش مصنوعیه، احتمالاً سریع‌ترین راه برای آنلاین کردنش همین گزینه است.

مدل‌ها الان کد می‌نویسن و انصافاً خیلی وقت‌ها هم کدهای خوبی می‌نویسن. ولی مسئله اینجاست که «نوشتن کد» فقط یک لایه کوچک از شغل مهندسیه. لایه بزرگ‌تر اینه که بفهمی مشکل واقعاً چیه، اصلاً چه چیزی باید ساخته بشه، چه چیزی نباید ساخته بشه، داده‌ها قابل اعتماد هستن یا نه، و در نهایت مسئولیت نتیجه‌ای که تولید می‌شه رو بپذیری (این خیلی مهمه ها، مسئولیت نهایی با کیه). هوش مصنوعی می‌تونه کد بنویسه، اما هنوز نمی تونه خود مسئله رو از دل یک کسب‌وکار بیرون بکشه. کسی که این مهارت‌ها رو نداره، حتی با بهترین ابزارهای دنیا هم در نهایت خروجی متوسطی می‌گیره. به نظرم خیلی از بحث‌های «هوش مصنوعی برنامه‌نویس‌ها رو جایگزین می‌کنه» از این تصور میاد که شغل مهندس کامپیوتر رو با نوشتن کد یکی می‌دونیم. در حالی که کدنویسی فقط بخشی از کاره؛ بخش سخت‌تر، فهمیدن مسئله و گرفتن تصمیم‌های درسته. البته این ترس جایگزین شدن هم چیز جدیدی نیست. تقریباً هر نسل با ظهور یک فناوری جدید فکر کرده قراره بخشی از مشاغل برای همیشه از بین برن. بعد از انقلاب صنعتی هم همین نگرانی‌ها وجود داشت. ابزارها عوض می‌شن، روش کار عوض می‌شه، بهره‌وری بالا می‌ره؛ اما فعلا نیاز به آدم‌هایی که مسئله رو بفهمن و برایش تصمیم بگیرن، سر جاش می‌مونه. هوش مصنوعی شاید ارزش «تایپ کردن کد» را کمتر کرده باشه، اما ارزش «فهمیدن مسئله» را بیشتر از قبل کرده. ابزارها عوض می‌شن؛ این مهندس ها هستن که می مانن. 😂

هر روز این دو عبارت، input token و output token، توی پنل مدل‌های زبانی جلوی چشممونه. ولی یکی از مفاهیم پایه‌ای که هر کسی با API مدل‌ها کار می‌کنه باید بدونه، خود «توکن»ـه، چون فاکتور دقیقاً بر همین اساس صادر میشه. اول این رو بگم که مدل جمله رو مثل ما نمی‌خونه. متن رو می‌شکنه به تکه‌های کوچیکی به اسم توکن و بعد همون تکه‌ها رو پردازش می‌کنه. یه کلمه‌ی معمولی ممکنه فقط یه توکن باشه، بعضی کلمه‌ها چند توکن می‌شن، و اسم‌های خارجی یا اصطلاحات تخصصی گاهی حتی بیشتر. نکته‌ی مهم اینه که صورت‌حساب بیشتر APIها بر اساس تعداد توکن حساب میشه. یعنی هم متنی که می‌فرستی پول داره، هم متنی که مدل برمی‌گردونه. یه اشتباه رایج هم اینه که برای هر درخواست، دوباره و دوباره چند پاراگراف توضیح ثابت می‌فرستیم، در حالی که بخش زیادی از اون متن هیچ‌وقت عوض نمیشه. پس پرامپت‌هایی که مدام تکرار میشن رو تا جایی که میشه کوتاه، شفاف و ماژولار نگه دار. بخش ثابت رو از بخش متغیر جدا کن و هرجا شد، جلوی تکرار بی‌دلیل متن رو بگیر. شاید قیمت یک توکن تقریباً صفر باشه، ولی میلیون‌ها توکن نه.

به نظرم ترتیب درست حل مشکل توی پروژه‌های LLM اینه: اول پرامپت خوب، بعد RAG، و آخر سر فاین‌تیون. چیزی که زیاد می‌بینم اینه که هنوز مدل و معماری درست ارزیابی نشده، ولی خیلی زود بحث فاین‌تیون وسط کشیده میشه. در حالی که بخش بزرگی از مشکلاتی که به اسم «نیاز به فاین‌تیون» شناخته میشن، در عمل از دو جا میان: ۱. مدل دقیقاً نمی‌دونه چه رفتاری ازش انتظار داریم. ۲. اطلاعات و دانش زمینه‌ای کافی دستش نیست. اولی معمولاً با یه پرامپت بهتر، چندتا مثال مناسب و چندتا قاعده‌ی شفاف حل میشه. دومی هم توی خیلی از موارد با RAG و اسناد درست و به‌روز درست میشه. فاین‌تیون ولی داستان فرق می‌کنه. فاین‌تیون فقط زدن یه دکمه نیست. باید داده‌ی تمیز داشته باشی، برچسب‌گذاریش کنی، وقت بذاری برای آماده‌سازی دیتاست، هزینه‌ی آموزش مدل رو بدی و حواست باشه اورفیتینگ رخ نده. تازه، هزینه‌ی GPU هم جداست. یه قانون سرانگشتی که بد نیست همیشه گوشه‌ی ذهنمون باشه: تا وقتی «پرامپت + اسناد» جواب تکرارپذیر و قابل‌قبول نمیده، فاین‌تیون جز گزینه هامون نباشه.

دیشب دو ساعت وسط یکی از پروژه‌های RAG گیر کرده بودم و مطمئن بودم مشکل از مدله: جواب‌های بی‌ربط می‌داد و انگار چیزی از سؤال کاربر نمی‌فهمید. لاگ‌ها رو که دقیق‌تر بررسی کردم، معلوم شد متهم اصلی یه جای دیگه‌ست: Chunking قطعه‌ها یا اون‌قدر کوتاه بودن که وسط مفهوم قیچی می‌شدن و معنی از بین می‌رفت، یا اون‌قدر بلند بودن که مرحله‌ی Retrieval نمی‌تونست بخش درست رو پیدا کنه. فقط اندازه‌ی قطعه‌ها رو تنظیم کردم و یه تمیزکاری ساده روی متن انجام دادم: هدرهای تکراری، پاصفحه‌ها و بخش‌های اضافی رو حذف کردم. نتیجه؟ بدون تغییر مدل، بدون تغییر Embedding و بدون دست زدن به Prompt، کیفیت جواب‌ها یه سطح بالاتر رفت. وقتی خروجی RAG ضعیفه، اولین کسی که مقصر می‌دونیم مدل زبانیه، در حالی که مشکل معمولاً یه لایه پایین‌تر خوابیده. این چندتا مورد رو چک کنیم بهتره: - اندازه و استراتژی Chunking - کیفیت متن‌های ورودی - حذف هدر، فوتر و محتوای تکراری - بخش Retrieval و اسنادی که واقعاً بازیابی شدن - بخش Query کاربر و نحوه‌ی بازنویسیش

دیشب دو ساعت وسط یکی از پروژه‌های RAG گیر کرده بودم و مطمئن بودم مشکل از مدله: جواب‌های بی‌ربط می‌داد و انگار چیزی از سؤال کاربر نمی‌فهمید. لاگ‌ها رو که دقیق‌تر بررسی کردم، معلوم شد متهم اصلی یه جای دیگه‌ست: Chunking قطعه‌ها یا اون‌قدر کوتاه بودن که وسط مفهوم قیچی می‌شدن و معنی از بین می‌رفت، یا اون‌قدر بلند بودن که مرحله‌ی Retrieval نمی‌تونست بخش درست رو پیدا کنه. فقط اندازه‌ی قطعه‌ها رو تنظیم کردم و یه تمیزکاری ساده روی متن انجام دادم: هدرهای تکراری، پاصفحه‌ها و بخش‌های اضافی رو حذف کردم. نتیجه؟ بدون تغییر مدل، بدون تغییر Embedding و بدون دست زدن به Prompt، کیفیت جواب‌ها یه سطح بالاتر رفت. وقتی خروجی RAG ضعیفه، اولین کسی که مقصر می‌دونیم مدل زبانیه، در حالی که مشکل معمولاً یه لایه پایین‌تر خوابیده. این چندتا مورد رو چک کنیم بهتره: - اندازه و استراتژی Chunking - کیفیت متن‌های ورودی - حذف هدر، فوتر و محتوای تکراری - بخش Retrieval و اسنادی که واقعاً بازیابی شدن - بخش Query کاربر و نحوه‌ی بازنویسیش

پست آزمایشی سامانهٔ انتشار — این پیام ۱۰ دقیقه پس از زمان‌بندی، خودکار منتشر می‌شود. بعد از دیدنش می‌توانی پاکش کنی؛ هدف فقط سنجش جریٔ لاتجور است.

جمله: «ببخشید که از چت‌جی‌پی‌تی پرسیدم و کدش رو کپی کردم» لزوماً جمله بدی نیست؛ اما واقعاً چرا باید بابت استفاده از هوش مصنوعی عذرخواهی کنیم؟ می‌بینم این روزها بعضی‌ها گارد می‌گیرن که چرا با هوش مصنوعی کد می‌نویسی و ازش کمک می‌گیری. تازه وارد فازی هم می‌شن که انگار باید فخر فروخت که ما اصلاً از هوش مصنوعی کمک نمی‌گیریم. شبیه اینه که ماشین اختراع شده باشه، بعد یکی بگه من هنوز می‌خوام الاغ‌سوار بشم. خب سوار شو... آخرش کی ضرر می‌کنه؟ آخه وقتی ابزاری وجود داره که کیفیت کار رو بالاتر می‌بره یا حداقل انجام کارهای قبلی رو ساده‌تر می‌کنه، چرا نباید ازش استفاده کنم؟ حالا اگر برای پروژه یک بیگ‌کمپانی هم استفاده نکنی اشکالی نداره، ولی چرا برای استفاده شخصی ازش استفاده نکنی؟ البته می‌دونم که یک ظرافت‌هایی هم داره؛ مثلاً آدم حرفه‌ای منطق مسئله و کد رو می‌فهمه، اون رو در محیط پروژه تست می‌کنه و شاید گاهی با سبک خودش بازنویسی‌اش کنه؛ ولی آدم کپی‌کار مستقیم Ctrl+C و Ctrl+V می‌زنه. به نظر می‌رسه در دنیای امروز، کمک گرفتن از هوش مصنوعی برای کدنویسی، البته به شرط فهم کلیت و منطق کدهای تولیدشده، خودش یک مهارته؛ اما کپی کردن بدون درک، فقط بدهی فنی ایجاد می‌کنه. این بدهی فنی بالاخره یک روز باید تسویه بشه و ممکنه تاوان سنگینی برامون داشته باشه.

میخام یک عبارت من درآوردی بگم بهتون اونم یادگیری در ملا عام جز ارزون ترین روش های دیده‌شدنه یعنی چی؟ هر هفته یک نوشته کوتاه از کاری که کردی و مشکلی که حل کردی — لینکدین، GitHub یا هر جای دیگه— بزار. 2 تا نتیجه باحال داره: مسیر رشدت مستند می‌شه، و آدم‌های هم‌مسیر پیدا می‌شن. البته مزایای دیگم داره، پروژه سمتت میاد، برندینگ شخصی بهتری خواهی داشت و کلی نکته مفید دیگه البته یک شرط داره، کمال گرایی ممنوع، منتشر کن، حتی به غلط و ناقص. خیلی کم خرجه این روش و پربازده، اگه این روش به مدت 3 ماه مستمر انجام بدی، یک نتایجی برات به ارمغان میاره که حسرت میخوری چرا زودتر شروع نکردی

فوت کوزه گری: وقتی خبر ارائه یک مدل جدید میاد قبلش 3تا سوال بپرس: (۱) به درد مشکل فعلی و ضروری من میخوره؟ (۲) هزینه‌م چه تغییری می‌کنه؟ (۳) می‌شه مشکل خودم را بهش بدم و یک تست اولیه ازش بگیرم؟ اگه جواب هر سه «نمی‌دونم»ه، سمت این نرو که کدها یا پروژه هات تغییر بدی چون اینجوری هر چند وقت نه یک بار باید همه چی به روزرسانی کنی در صورتی که سازنده های خودرو میتونن تا ابد ماشینشون بهینه کنن و بهبود بدن و به بازار ارائش نشدن ولی یک جایی که به حد کافی خوب میرسه رها می کنن و دیگه تغییر و تحولی نمیدن و اون ماشین را می فروشن یعنی چی؟ یعنی همیشه میشه رفت سمت عالی ترین و بهترین و جدیدترین، ولی به اندازه کافی خوب، گزینه منطقی تره چون تماشای مدل‌های جدید رایگانه؛ ولی جاگذاری‌شون گرون. پس این گوشت در باشه اون یکی دروازه، کاهی فقط خبرها بخون و رد شو

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

جمله: «ببخشید که از چت‌جی‌پی‌تی پرسیدم و کدش رو کپی کردم» لزوماً جمله بدی نیست؛ اما واقعاً چرا باید بابت استفاده از هوش مصنوعی عذرخواهی کنیم؟ می‌بینم این روزها بعضی‌ها گارد می‌گیرن که چرا با هوش مصنوعی کد می‌نویسی و ازش کمک می‌گیری. تازه وارد فازی هم می‌شن که انگار باید فخر فروخت که ما اصلاً از هوش مصنوعی کمک نمی‌گیریم. شبیه اینه که ماشین اختراع شده باشه، بعد یکی بگه من هنوز می‌خوام الاغ‌سوار بشم. خب سوار شو... آخرش کی ضرر می‌کنه؟ آخه وقتی ابزاری وجود داره که کیفیت کار رو بالاتر می‌بره یا حداقل انجام کارهای قبلی رو ساده‌تر می‌کنه، چرا نباید ازش استفاده کنم؟ حالا اگر برای پروژه یک بیگ‌کمپانی هم استفاده نکنی اشکالی نداره، ولی چرا برای استفاده شخصی ازش استفاده نکنی؟ البته می‌دونم که یک ظرافت‌هایی هم داره؛ مثلاً آدم حرفه‌ای منطق مسئله و کد رو می‌فهمه، اون رو در محیط پروژه تست می‌کنه و شاید گاهی با سبک خودش بازنویسی‌اش کنه؛ ولی آدم کپی‌کار مستقیم Ctrl+C و Ctrl+V می‌زنه. به نظر می‌رسه در دنیای امروز، کمک گرفتن از هوش مصنوعی برای کدنویسی، البته به شرط فهم کلیت و منطق کدهای تولیدشده، خودش یک مهارته؛ اما کپی کردن بدون درک، فقط بدهی فنی ایجاد می‌کنه. این بدهی فنی بالاخره یک روز باید تسویه بشه و ممکنه تاوان سنگینی برامون داشته باشه.

پست آزمایشی — سنجش اتصال انتشار (دقایقی بعد حذف می‌شود)

پیشگویی در حد المپیک😎😎😎

دوستان عدد پرداختی برای این کار خوب هست

برای انجام یک پروژه در زمینه مدل های زبانی (تشخیص متون انسانی از متون غیر انسانی)، دوستانی که در حوزه NLP سنیور هستند لطفا پیام بدن تا در مورد زمان و هزینه صحبت بشه @data_hub

شانسو ببین Open code هک شد 😂 کاش من حرف نزنم

مدل Beam دیونم کرده، امروز واسه اولین بار باهاش کار کردم، توی کدنویسی بسیار سریعه، و دقت بسیار بالایی داره و رایگانه پ.ن: توی open code ازش استفاده می کنم

دنیای جالبی شده. آنتراپیک اومده و به یک سازمان دیگه گفته بیان تا ارزیابی مستقلی از ریسکها داشته باشند. اصلاً از این کارهای آنتراپیک خیلی خوشم میآید که همیشه فقط دغدغهٔ مالی نیست و به جنبه‌های فرهنگی و اخلاقی هم فکر میکند. نظارت مستقل، اونهم توسط سازمانی مثل METR؛ کار جالبیه. فک کن دسترسی مشابه با کارمندهاش به ۶ نفر از نیروهای METR داده که برند و ببینند کجاها مدل زبانی شیطانی میکند. کاش شرکتهای بزرگ دیگری هم چنین پنجرهای برای همیشه باز داشته باشند… https://the-decoder.com/anthropic-gives-metr-inside-access-to-audit-its-ai-models-and-safety-practices