آخرین کد نویس

مدیریت مسیر شغلی ۱. به خودت به چشم یه بیزینس نگاه کن، نه یه کارمند بزرگ‌ترین اشتباه برنامه‌نویس‌ها اینه که فکر می‌کنن کارمند یه شرکت هستن و امنیت شغلی دارن. شغل مال شرکته، اما مسیر شغلی Career مال خودته. به خودت به چشم یه کسب‌وکار یک‌نفره نگاه کن که خدمات تولید نرم‌افزار می‌فروشه و کارفرمای فعلی تو، فقط مشتری اصلی این بیزینسه. وقتی اینطوری فکر کنی، به جای اینکه منتظر بمونی شرکت برات تصمیم بگیره، خودت مدام کیفیت سرویست رو بالا می‌بری، روی یه نیاز خاص تمرکز می‌کنی و یاد می‌گیری چطور خودت رو به بازار پرزنت کنی تا مشتری‌های بهتری جذب کنی. ۲. هدف‌گذاری معکوس از مقصد به امروز بیشتر برنامه‌نویس‌ها مثل یه کشتی بدون مقصد، فقط اولین پیشنهاد شغلی رو قبول می‌کنن و سال‌ها توی همون مسیر می‌مونن. - تعیین هدف بزرگ ۵ تا ۱۰ ساله: دقیقاً مشخص کن کجا می‌خوای برسی مثلاً معمار نرم‌افزار شدن، فریلنسری یا ساخت محصول شخصی. لازم نیست جزئیاتش از الان صددرصد دقیق باشه، فقط باید جهت حرکت رو مشخص کنه. - شکستن به عقب: از اون هدف بزرگ به زمان حال برگرد و اون رو به اهداف سالانه، ماهانه، هفتگی و در نهایت کارهای کوچک روزانه مثل خوندن روزی چند صفحه کتاب تخصصی بشکن. - بازبینی منظم: آخر هر هفته و هر ماه مسیرت رو چک کن تا مطمئن بشی از هدف اصلی منحرف نشدی.

فصل اول، بخش اول

کتاب Soft Skills

دوره CS329A Self-Improving AI Agent استنفورد چرا بعضی ایجنت‌ها هر بار خطای قبلی رو تکرار می‌کنن؟ یک نگاهی به این دوره بندازید. https://youtu.be/6YnLB0XbTnI?is=TaLzWqKlKUALmOxP

و Anthropic با Claude Duet وارد رقابت AI Agent ها شد! شرکت سازنده Claude از ایجنت جدیدی به نام Claude Duet رونمایی کرده که قراره فراتر از یک چت‌بات معمولی عمل کنه. کارها رو در بکگراند انجام بده و حتی قبل از اینکه درخواست کنی، پیشنهادهایی برای بهتر انجام‌دادن کارهات ارائه بده! قابلیت‌ها؟ 🔹 ساخت داشبورد و گزارش‌های روزانه 🔹 اجرای وظایف در بکگراند، بدون نیاز به نظارت مداوم 🔹 اتصال به بیش از ۶۰۰۰ ابزار و افزونه 🔹 انجام خرید اینترنتی با تأیید کاربر برای پرداخت‌های حساس 💡 چرا مهمه؟ رقابت هوش مصنوعی دیگه فقط بر سر این نیست که کدوم مدل بهتر جواب میده؛ شرکت‌ها دارن ایجنت‌هایی می‌سازن که بتونن ابزارهای مختلف رو به هم وصل کنن، وظایف پیچیده رو انجام بدن و نتیجهٔ نهایی رو تحویل بدن. برای برنامه‌نویس‌ها، این یعنی فرصت‌های بیشتر برای ساخت سیستم‌های هوشمند و اتومات کردن کارهای تکراری! #claude #هوش_مصنوعی #AIAgents @GrowVixo🔥 @GrowVixo_Ask منبع: https://techcrunch.com/2026/10/22/claude-duet-app-is-anthropics-bet-on-agents/

ترجمه فارسی کتاب Apprenticeship Patterns کتاب Apprenticeship Patterns یکی از بهترین منابع برای یادگیری الگوهای رشد شغلی، تقویت ذهنیت مهندسی و تبدیل شدن به یک برنامه‌نویس حرفه‌ای است. ترجمه فارسی این کتاب رو روی گیت‌هاب گذاشتم: https://github.com/hheydarian/apprenticeship-patterns-persian

ترجمه فارسی کتاب # Clean Code in C کتاب # Clean Code in C یکی از بهترین منابع برای یادگیری اصول کدنویسی تمیز، ریفکتورینگ و نوشتن کدهای قابل نگهداری در دات‌نت است. ترجمه فارسی این کتاب رو روی گیت‌هاب گذاشتم: https://github.com/hheydarian/clean-code-in-csharp-persian

دوستان راهکارها و مطالب مفید برای زمانی قطعی اینترنت رو سعی میکنم تو چندتا پارت آماده کنم و هر قسمت معرفی کنم. آپلودرهای رایگان بدون نیاز به ثبت‌نام: https://up.20script.ir/ https://uplod.ir/ https://toolschi.com/tools/upload-center #پارت_اول @shayangeedook

کتاب Prompt Engineering for LLMs کتاب Prompt Engineering for LLMs نوشته جان بریمن و آلبرت زیگلر از معماران اصلی گیت‌هاب کوپایلوت، یکی از کاربردی‌ترین منابع برای ساخت اپلیکیشن‌های واقعی با مدل‌های زبانی است. این کتاب به‌جای ترفندهای سطحی، سراغ معماری مهندسی، مدیریت کانتکست، مهار توهم مدل و طراحی ایجنت‌ها در محیط عملیاتی می‌رود. خلاصه تمام ۱۱ فصل این کتاب:

- فصل ۱ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۲ بخش اول | بخش دوم | بخش سوم | بخش چهارم | بخش پنجم - فصل ۳ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۴ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۵ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۶ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۷ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۸ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۹ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۱۰ بخش اول | بخش دوم | بخش سوم | بخش چهارم - فصل ۱۱ بخش اول | بخش دوم جمع‌بندی

 @lastcoderworld

عصاره کل کتاب در ۲ قانون بنیادین و ۵ فرمان عملیاتی جان بریمن و آلبرت زیگلر، معماران گیت‌هاب کوپایلوت، در صفحات پایانی کتاب می‌گویند اگر قرار باشد از تمام این ۱۱ فصل فقط دو حقیقت را به خاطر بسپارید، آن دو مورد این‌ها هستند: قانون اول: همه چیز در نهایت تکمیل سند یا Document Completion است

چه از APIهای چت استفاده کنید، چه Tool Calling و چه Artifacts، در نهایت مدل زبانی یک ماشین پیش‌بینی توکن است که سعی می‌کند متنی بنویسد که شبیه داده‌های آموزشی‌اش باشد. - نتیجه عملی (اصل شنل‌قرمزی): هیچ ساختار من‌درآوردی اختراع نکنید! پرامپت‌ها و داده‌های خود را دقیقاً با فرمت‌هایی مثل Markdown و ساختارهایی بنویسید که میلیون‌ها بار در اینترنت تکرار شده‌اند تا مدل در مسیر طبیعی خودش حرکت کند.

قانون دوم: با مدل همدلی کنید مدل را مثل یک دوست قدرتمند اما ساده‌لوح ببینید!

مدل زبانی مثل دوستی است که کل اینترنت را حفظ است، اما درک مستقیمی از موقعیت شما ندارد. برای اینکه بهترین خروجی را از او بگیرید، این ۵ فرمان عملیاتی را همیشه رعایت کنید: ۱. حواس مدل به شدت پرت می‌شود: پرامپت را با اطلاعاتی که شاید به درد بخورد پر نکنید. هر کلمه اضافه در پرامپت، تمرکز مکانیزم Attention را از روی اصل مطلب کم می‌کند. ۲. اگر انسان پرامپت را نفهمد، مدل هم نمی‌فهمد: قبل از ارسال، خروجی نهایی پرامپت رندر شده را خودتان بخوانید؛ اگر ابهامی برای یک انسان وجود داشته باشد، مدل هم قطعاً گیج خواهد شد. ۳. مدل نیاز به هدایت صریح دارد: انتظار نداشته باشید مدل خودش هدف را حدس بزند؛ دستورالعمل‌ها را شفاف بنویسید و هر جا فرمت خاصی می‌خواهید، حتماً با مثال‌های Few-shot مسیر را نشان دهید. ۴. مدل علم غیب ندارد: هر اطلاعاتی که برای حل مسئله لازم است را یا مستقیم در کانتکست بگذارید، یا ابزار مناسب برای پیدا کردنش را در اختیارش قرار دهید. ۵. مدل دیالوگ درونی ندارد: مدل نمی‌تواند قبل از حرف زدن در ذهنش فکر کند؛ همیشه به او فضای فکر کردن با صدای بلند یا همان زنجیره فکر بدهید تا قبل از اعلام جواب نهایی، استدلال کند.

- چشم‌انداز آینده: با ارزان و سریع شدن مدل‌ها، به سمت دنیایی می‌رویم که ساخت نرم‌افزار بسیار سریع‌تر می‌شود و حتی شاهد ظهور اپلیکیشن‌های یک‌بارمصرف و کاملاً شخصی‌سازی‌شده خواهیم بود. در این دنیای جدید که همه چیز با سرعت تغییر می‌کند، برنده کسی است که مدام آزمایش کند، ارزیابی را جدی بگیرد و انعطاف‌پذیر بماند.

کتاب Prompt Engineering for LLMs

چرا بنچمارک‌های هوش مصنوعی از کار افتاده‌اند؟ تکنیک‌های Distillation و Quantization مدل‌ها روزبه‌روز باهوش‌تر، سریع‌تر و ارزان‌تر می‌شوند، اما در پشت پرده توسعه مدل‌های جدید سه اتفاق فنی مهم در حال رخ دادن است که هر مهندس هوش مصنوعی باید بداند: ۱. بحران اشباع بنچمارک‌ها و تقلب ناخواسته مدل‌ها

بنچمارک‌های معروفی که برای سنجش هوش مدل‌ها استفاده می‌شدند، یکی پس از دیگری به سقف ۱۰۰ درصد می‌رسند و کارایی خود را از دست می‌دهند. این اتفاق دو دلیل دارد: مدل‌ها واقعاً قوی‌تر شده‌اند. - آلودگی داده‌ها یا تقلب ناخواسته: وقتی یک بنچمارک یکی دو سال در اینترنت باشد، سوالات و جواب‌هایش در مقالات، فروم‌ها و ریپازیتوری‌های گیت‌هاب کپی می‌شود. در نتیجه، مدل‌های جدید هنگام بلعیدن اینترنت، سوالات کنکور را از قبل در داده‌های آموزشی خود دیده‌اند و حفظ کرده‌اند! - راه‌حل جدید ARC-AGI: جامعه هوش مصنوعی به سمت بنچمارک‌های غیرقابل‌حفظ کردن مثل ARC-AGI رفته است؛ تست‌های هوش تصویری و الگومحور که به صورت الگوریتمی و در لحظه تولید می‌شوند و مدل چاره‌ای جز استدلال واقعی برای حل آن‌ها ندارد.

۲. تکنیک Knowledge Distillation: انتقال مغز مدل غول‌پیکر به مدل کوچک

مدل‌های بسیار بزرگ از تمام ظرفیت شبکه خود استفاده نمی‌کنند. در تکنیک تقطیر دانش یا Knowledge Distillation، یک مدل بزرگ و گران‌قیمت نقش معلم را برای یک مدل کوچک و سبک بازی می‌کند. - مکانیزم فنی: در آموزش عادی، به مدل کوچک فقط یاد می‌دهند که کلمه بعدی چیست. اما در Distillation، مدل کوچک آموزش می‌بیند که توزیع کامل احتمالات (Logprobs) مدلِ معلم را برای توکن بعدی تقلید کند! این کار باعث می‌شود ظرافت‌های ذهنی مدل بزرگ با افت دقت بسیار ناچیزی وارد مدل کوچک شود، در حالی که سرعت اجرای مدل جدید چندین برابر بیشتر و هزینه‌اش بسیار کمتر است.

۳. تکنیک Quantization: کوچک‌سازی در سطح بیت‌ها

وزن‌های شبکه عصبی به صورت پیش‌فرض با اعداد اعشاری ۳۲ بیتی ذخیره می‌شوند. با تکنیک کوانتیزاسیون، این اعداد به مقادیر ۸ بیتی تقریب زده می‌شوند. این کار حجم مدل و مصرف رم گرافیک را به شدت پایین می‌آورد و سرعت تولید توکن را بدون افت محسوس هوش مدل، به شکل چشمگیری افزایش می‌دهد.

فصل یازدهم، بخش دوم

کتاب Prompt Engineering for LLMs

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

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

۲. عبور از چت‌های سنتی با پارادایم Artifacts

در چت‌بات‌های معمولی مثل ChatGPT اولیه، اگر از مدل بخواهید یک تابع کد بنویسد و در پیام بعدی بگویید یک خط آن را عوض کند، مدل کل تابع را از اول تا آخر دوباره در چت تایپ می‌کند! یعنی به جای اینکه یک شیء واحد وجود داشته باشد که وضعیت آن آپدیت شود، ۱۰ نسخه مختلف در تاریخچه چت تولید می‌شود که ارجاع دادن به آن‌ها بسیار سخت است. آنتروپیک با معرفی Artifacts در مدل Claude اولین قدم را برای حل این مشکل برداشت: مکالمه در سمت چپ صفحه پیش می‌رود، اما خروجی کار مثل کد، دیاگرام یا فایل HTML به عنوان یک موجودیت دارای وضعیت یا Stateful Object در پنل سمت راست ثابت می‌ماند و درجا آپدیت می‌شود.

۳. کمبودهای فعلی Artifacts که شما باید در برنامه‌هایتان حل کنید

نویسندگان کتاب اشاره می‌کنند که پیاده‌سازی فعلی Artifacts هنوز بیشتر یک ترفند ظاهری در UI است تا مهندسی پرامپت، و سه ضعف بزرگ دارد که فرصت خوبی برای توسعه‌دهندگان است: بازنویسی کامل از صفر: وقتی تغییر کوچکی می‌خواهید، مدل در پشت صحنه همچنان کل فایل را از اول تولید می‌کند که برای فایل‌های طولانی کند و پرهزینه است. مدیریت هم‌زمان چند فایل: ارجاع دادن هم‌زمان به چند Artifact مختلف در پرامپت و UI هنوز دشوار است و نیاز به سیستم نام‌گذاری کوتاه دارد. نبود قابلیت ویرایش دوطرفه: اگر کاربر خودش دستی یک خط از کد داخل Artifact را ویرایش کند، این تغییر باید در پرامپت بعدی به مدل اطلاع داده شود تا مدل از آخرین وضعیت فایل باخبر بماند.



فصل یازدهم، بخش اول

کتاب Prompt Engineering for LLMs

ترجمه فارسی کتاب The Pragmatic Programmer کتاب The Pragmatic Programmer یکی از بهترین منابع برای درک اصول مهندسی نرم‌افزار و کار تیمی است. ترجمه فارسی این کتاب رو روی گیت‌هاب گذاشتم: https://github.com/hheydarian/the-pragmatic-programmer-persion

ارزیابی آنلاین در دنیای واقعی؛ تست A/B و ۵ متریک طلایی تست‌های آزمایشگاهی عالی هستند چون رایگان و امن‌اند، اما عیار واقعی محصول زمانی مشخص می‌شود که کاربران واقعی با آن کار کنند. استانداردترین روش در این مرحله تست A/B است: کاربران را به دو گروه تصادفی تقسیم می‌کنید، به گروه اول پرامپت قبلی و به گروه دوم پرامپت جدید را می‌دهید تا ببینید کدام بهتر عمل می‌کند. یک تله آماری مهم در آپدیت برنامه‌ها:

اگر برنامه‌تان سمت کلاینت اجرا می‌شود، هرگز کاربرانی که سریع آپدیت کرده‌اند را گروه B و کسانی که هنوز آپدیت نکرده‌اند را گروه A نگذارید! کاربرانی که سریع آپدیت می‌کنند رفتار کاملاً متفاوتی دارند. تست A/B را فقط بین کسانی اجرا کنید که نسخه جدید را نصب کرده‌اند.

۵ متریک کلیدی برای اینکه بفهمیم کدام نسخه برنده شده است:

۱. بازخورد مستقیم کاربر: گذاشتن دکمه لایک و دیس‌لایک کنار پیام‌ها. تجربه نشان داده کاربران به ندرت برای یک جواب خوب لایک می‌زنند، اما وقتی جواب خراب باشد فوراً دیس‌لایک می‌زنند؛ بنابراین دیس‌لایک سیگنال بسیار دقیق‌تری برای کشف مشکلات است. ۲. درستی عملکردی در عمل: آیا خروجی مدل در سیستم کاربر کار کرد؟ مثلاً اگر کد تولید کرد، آیا در ادیتور کاربر بدون خطا کامپایل شد؟ ۳. نرخ پذیرش یا Acceptance Rate مهم‌ترین متریک کوپایلوت: آیا کاربر پیشنهاد هوش مصنوعی را قبول کرد؟ مثلاً روی لینک پیشنهادی کلیک کرد یا کلید Tab را زد تا کد وارد پروژه‌اش شود؟ تیم کوپایلوت کشف کرد که همین نرخ پذیرش اولیه بالاترین همبستگی را با رضایت و بهره‌وری واقعی برنامه‌نویسان دارد. ۴. تاثیر نهایی یا Achieved Impact: چقدر از کار نهایی باقی ماند؟ مثلاً کاربر پیشنهاد کد را قبول کرد، اما ده دقیقه بعد هنگام ذخیره فایل، چند درصد از کد هوش مصنوعی را پاک نکرد و دست‌نخورده نگه داشت؟ یا در سیستم پیشنهاد سفر، آیا در نهایت بلیت آن شهر را خرید؟ ۵. متریک‌های جانبی و گاردریل‌ها: معیارهایی مثل زمان پاسخ‌دهی، نرخ خطا و طول مکالمه. طول مکالمه به تنهایی خوب یا بد نیست؛ مکالمه کوتاه می‌تواند نشانه حل سریع مشکل باشد یا نشانه کلافه شدن و خروج کاربر! این اعداد را باید به عنوان گاردریل زیر نظر بگیرید تا مطمئن شوید پرامپت جدید، سرعت یا پایداری سیستم را خراب نکرده است.

فصل دهم، بخش چهارم

کتاب Prompt Engineering for LLMs

تکنیک LLM-as-a-Judge؛ چطور از خود مدل برای نمره‌دهی بی‌طرفانه استفاده کنیم؟ وقتی خروجی برنامه شما یک متن باز مثل خلاصه مقاله یا ایمیل است، نه می‌شود با کدهای معمولی آن را تست کرد و نه تطابق کلمه به کلمه جواب می‌دهد. اینجا باید از یک مدل زبانی دیگر به عنوان داور استفاده کنید تا به خروجی برنامه شما نمره بدهد.

اما اگر فقط از مدل بپرسید: آیا این جواب خوب است؟، نتیجه‌ای به شدت پرنوسان و بی‌ارزش می‌گیرید. برای ساخت یک داور دقیق، باید ۴ قانون به نام چارچوب SOMA را رعایت کنید: ۱. ترفند روانشناختی: سوم‌شخص کردن ارزیابی هرگز نگذارید مدل بفهمد دارد به خروجیِ خودش نمره می‌دهد! مدل‌ها به خاطر داده‌های فروم‌های اینترنتی و آموزش‌های RLHF، وقتی بفهمند خروجی مال خودشان است دچار تعصب یا تواضع کاذب می‌شوند. همیشه در پرامپت داور بنویسید: من خروجی یک دستیار دیگر را به تو می‌دهم تا به عنوان ناظر بیرونی ارزیابی کنی. ۲. پرسیدن سوالات کاملاً مشخص Specific به جای سوال کلی آیا این پاسخ درست است؟، دقیقاً مشخص کنید چه چیزی باید سنجیده شود. مثلاً بپرسید: آیا اقدام دستیار، مشکل سرد بودن اتاق کاربر را حل می‌کند؟ ۳. امتیازدهی درجه‌بندی‌شده به جای بله و خیر (Ordinal Scale) مدل‌ها در جواب‌های صفر و یکی معیار ثابتی ندارند. از مقیاس ۱ تا ۵ استفاده کنید و در پرامپت، معنی دقیق هر عدد را توضیح دهید؛ مثلاً بنویسید: امتیاز ۱ یعنی مشکل را اصلاً حل نمی‌کند یا بدتر می‌کند، امتیاز ۳ یعنی بخش اصلی مشکل را حل می‌کند، و امتیاز ۵ یعنی مشکل را به طور کامل و بی‌نقص برطرف می‌سازد. ۴. تفکیک معیارها به چند بُعد مستقل (Multi-Aspect) یک پاسخ خوب ابعاد مختلفی دارد. همه را در یک سوال مخلوط نکنید؛ برای هر کدام نمره جدا بخواهید: قصد و نیت: آیا مدل درست فهمیده کاربر چه می‌خواهد؟ اجرا: آیا ابزار درست را با سینتکس درست صدا زده است؟ معیار طلایی RTC: در چت‌بات‌ها سه چیز را جداگانه نمره دهید: مرتبط بودن، صحیح بودن علمی، و کامل بودن پاسخ.

دو نکته طلایی در نوشتن پرامپتِ داور: معیارهای امتیازدهی را قبل از نشان دادن متنِ نمونه در پرامپت بنویسید؛ چون مدل متن را از بالا به پایین می‌خواند و باید قبل از دیدن جواب، بداند دنبال چه ایرادهایی بگردد. ازModel بخواهید اول تحلیلش را بنویسد و در آخرین خط نمره را بدهد تا از مزایای زنجیره فکر بهره ببرید.

فصل دهم، بخش دوم

کتاب Prompt Engineering for LLMs

چطور هزاران نمونه برای تست خودکار هوش مصنوعی بسازیم؟ بررسی چشمی با Git Diff برای ۲۰ نمونه عالی است، اما برای اینکه مطمئن شوید محصولتان واقعاً کار می‌کند، به صدها یا هزاران نمونه نیاز دارید. سوال بزرگ اینجاست: وقتی هنوز محصول را نساخته‌ایم، این همه نمونه ورودی و خروجی استاندارد را از کجا بیاوریم؟

روش اول: مهندسی معکوس داده‌های موجود (تکنیک کوپایلوت) هدف کوپایلوت این بود که حدس بزند برنامه‌نویس در لحظه بعد چه کدی می‌خواهد تایپ کند. هیچ دیتاستی در دنیا برای کدهای نیمه‌کاره برنامه‌نویسان وجود نداشت! اما گیت‌هاب پر از کدهای کامل بود. تیم کوپایلوت این ترفند را زد: ۱. یک فایل کد سالم از یک پروژه متن‌باز برداشتند. ۲. بدنه یکی از توابع داخل فایل را پاک کردند و فرض کردند نشانگر موس برنامه‌نویس دقیقاً اول آن تابع است. ۳. از کوپایلوت خواستند ادامه کد را بنویسد و سپس کد تولیدشده را با کد اصلی مقایسه کردند! شما هم در پروژه خودتان بگردید ببینید کجا کارهای کامل‌شده وجود دارد؛ بخشی از آن را حذف کنید تا تبدیل به یک مسئله تست شود. روش دوم: تولید داده‌های مصنوعی با انفجار ترکیبی اگر هیچ داده آماده‌ای ندارید، از خود LLM بخواهید برایتان نمونه بسازد. اما اگر به مدل بگویید: ۱۰ نمونه سوال مشتری بده، نمونه‌هایی بسیار کلیشه‌ای و تکراری تولید می‌کند.

راه‌حل مهندسی:

متغیرهای مسئله را به چند بُعد تقسیم کنید. مثلاً اگر سیستم پشتیبانی می‌سازید: ۵ نوع لحن کاربر (عصبانی، عجول، مودب و غیره) ضربدر ۱۰ نوع مشکل فنی ضربدر ۴ نوع محصول؛ شما فوراً ۲۰۰ سناریوی کاملاً متفاوت دارید که می‌توانید به مدل بدهید تا بر اساس هر ترکیب، یک پیام نمونه بسازد.

تله خطرناک در تولید تست با هوش مصنوعی

هرگز با مدلی که نمونه تست‌ها را ساخته، مدل دیگری را مقایسه نکنید! اگر تست‌ها را با GPT-4 بسازید و بخواهید بین GPT-4 و Claude یکی را انتخاب کنید، مدل اول همیشه برنده می‌شود؛ چون ساختار ذهنی خودش را در طراحی سوالات لحاظ کرده است.

چطور درستی جواب‌ها را در مقیاس بالا چک کنیم؟

تطابق جزئی به جای تطابق کامل: در متن‌های طولانی، انتظار نداشته باشید خروجی مدل کلمه به کلمه شبیه جواب استاندارد شما باشد. فقط بخش حیاتی را چک کنید؛ مثلاً اگر ایجنت خانه هوشمند دارید و کاربر می‌گوید: سردم است، چک نکنید که دما حتماً روی ۲۵ درجه تنظیم شود؛ فقط چک کنید که مدل تابعِ set_room_temp را با یک عدد منطقی صدا زده باشد.

تست عملکردی: به جای مقایسه متن کد، کد تولیدشده توسط مدل را واقعاً کامپایل کنید و Unit Testهای پروژه را روی آن اجرا کنید؛ اگر تست‌ها پاس شدند یعنی خروجی درست است.

فصل دهم، بخش دوم

کتاب Prompt Engineering for LLMs

ترجمه فارسی کتاب C# 12 in a Nutshell اگه با سی‌شارپ و دات‌نت کار می‌کنید، احتمالاً کتاب C# 12 in a Nutshell رو می‌شناسید. ترجمه فارسی این کتاب رو به صورت رایگان و متن‌باز توی گیت‌هاب گذاشتم تا مطالعه‌ش راحت‌تر باشه. می‌تونید از طریق لینک زیر به ریپازیتوری سر بزنید: https://github.com/hheydarian/csharp-12-in-a-nutshell-persian

قدیمی‌ترین کد گیت‌هاب کوپایلوت چه بود؟ شروع ارزیابی با Git Diff شاید فکر کنید اولین کدی که تیم گیت‌هاب کوپایلوت نوشت، مربوط به پرامپت‌ها یا افزونه VS Code بود؛ اما نویسندگان کتاب می‌گویند اولین کدی که نوشتیم سیستم ارزیابی بود! چرا؟ چون در مهندسی پرامپت، هر کلمه‌ای که عوض می‌کنید ممکن است یک جا را درست کند و سه جای دیگر را خراب کند. بدون سیستم تست، در تاریکی حرکت می‌کنید.

- سطح اول تست: تکنیک ساده اما قدرتمند Example Suite وقتی تازه اول راه هستید و هنوز کاربر واقعی ندارید، نیازی به سیستم‌های پیچیده ندارید. نویسندگان کتاب این روش ۳ مرحله‌ای را پیشنهاد می‌کنند: ۱. بین ۵ تا ۲۰ نمونه از ورودی‌های واقعی و متنوعی که قرار است به برنامه‌تان داده شود آماده کنید. ۲. یک اسکریپت بنویسید که پرامپت شما را روی این ۲۰ نمونه اجرا کند و خروجی‌های مدل را داخل فایل‌های متنی ذخیره نماید. ۳. این فایل‌ها را در Git کامیت کنید! حالا هر بار که پرامپت را تغییر می‌دهید، دوباره اسکریپت را اجرا کنید و دستور git diff بزنید. با دیدن تفاوت فایل‌ها در گیت، در چند ثانیه با چشم می‌بینید که تغییر یک کلمه در پرامپت، خروجی ۲۰ سناریوی مختلف را چطور بهتر یا بدتر کرده است.

تست‌های واحد در برابر تست‌های کل سیستم

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

چطور یک چت‌بات چندمرحله‌ای را تست کنیم؟ تست کردن چت‌بات سخت است چون هر جواب مدل، سوال بعدی کاربر را تغییر می‌دهد. دو راه‌حل عملی برای این کار وجود دارد:

- مکالمات کنسروشده: یک مکالمه کامل از پیش نوشته شده را مرحله‌به‌مرحله به مدل بدهید. در هر مرحله جواب مدل را امتیازدهی کنید، اما برای رفتن به مرحله بعد، جواب مدل را دور بریزید و دیالوگ از پیش نوشته شده خودتان را جایگزین کنید تا مسیر مکالمه منحرف نشود. - کاربر مصنوعی: یک پرامپت بنویسید که نقش کاربر را با یک شخصیت مشخص بازی کند و بگذارید با چت‌بات شما به صورت خودکار گفتگو کند تا کل حلقه مکالمه تست شود.

فصل دهم، بخش اول

کتاب Prompt Engineering for LLMs

معماری‌های پیشرفته؛ چطور دو ایجنت را روبه‌روی هم بگذاریم تا بدون دخالت انسان کار کنند؟ در بخش آخر فصل نهم، کتاب سراغ مرزهای پیشرفته مهندسی پرامپت می‌رود: زمانی که مسئله آن‌قدر باز و پویاست که نمی‌توان از قبل مراحل ثابتی برایش طراحی کرد. در اینجا سه الگوی بسیار جذاب آموزش داده می‌شود:

۱. الگوی UserProxy: جایگزین کردن انسان با یک ایجنت ناظر! گفتیم که ایجنت‌های مکالمه‌محور به تنهایی کار را ول می‌کنند و نیاز دارند یک انسان بالای سرشان باشد تا به آن‌ها بازخورد بدهد و مسیرشان را اصلاح کند. فریم‌ورک‌هایی مثل AutoGen ایده درخشانی را مطرح کردند: بیایید نقش انسان را هم به یک ایجنت دیگر بدهیم! این معماری چطور کار می‌کند؟ - ایجنت اول Assistant: برنامه‌نویس است؛ ابزار نوشتن فایل و اجرای کد دارد، اما هدف کلی پروژه را نمی‌داند. - ایجنت دوم UserProxy: هیچ ابزاری ندارد، اما هدف نهایی پروژه در System Message او نوشته شده است. این دو ایجنت را به هم وصل می‌کنید. ایجنت UserProxy دقیقاً مثل یک کارفرما به Assistant دستور می‌دهد، کدهایش را می‌بیند، ایرادهایش را می‌گیرد و مجبورش می‌کند کد را اصلاح کند تا زمانی که پروژه کامل شود! ۲. ایجنت‌های مقیم فایل Stateful Task Agents در سیستم‌های عادی، ایجنت کارش را انجام می‌دهد و همه چیز را فراموش می‌کند. اما در معماری Stateful، هر ایجنت صاحب و نگهبان دائمی یک بخش از پروژه می‌شود. مثلاً در ساخت یک وب‌سایت، یک ایجنت مسئول فایل فرانت‌اند است و یک ایجنت مسئول فایل بک‌اند. وقتی شما به ایجنت فرانت‌اند می‌گویید یک دکمه جدید اضافه کند، این ایجنت بعد از تغییر فایل خودش، یک پیام به ایجنت بک‌اند می‌فرستد و می‌گوید: من این فرم را تغییر دادم، تو هم API خودت را متناسب با این آپدیت کن. ۳. نصیحت پایانی معماران گیت‌هاب کوپایلوت هر چقدر سیستم را خودمختارتر کنید، کنترل و دیباگ کردن آن سخت‌تر می‌شود. بنابراین: هر کاری را که می‌شود با چند خط کد معمولی پایتون یا جاوااسکریپت انجام داد، هرگز به LLM نسپارید.

برای کارهای ساده از مدل‌های کوچک و ارزان استفاده کنید و مدل‌های گران را فقط برای گلوگاه‌های فکری نگه دارید. قبل از رفتن سراغ فریم‌ورک‌های پیچیده چندایجنتی، ابتدا با یک Workflow ساده و شفاف شروع کنید.

فصل نهم، بخش سوم

کتاب Prompt Engineering for LLMs