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

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

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