پیش‌گفتار:
دوستی دارم که رشته‌ی هنر خونده و علاوه بر دانش عکاسی، تجربه‌ی زیادی هم در این زمینه داره. یک بار برام تعریف می‌کرد که با گروهی که چندتاشون اون رو نمی‌شناختند جایی بودند و ازش خواستند که ازشون عکس بگیره. می‌گفت بعد از این که عکس گرفتم به رسم معمول، عکس‌ها رو نشون همه دادم که ببینند توی عکس خوب افتادند یا نه. بعد از این که از کیفیت عکس و … تعریف کردند یکی از افرادی که با هم آشنایی نداشتیم برگشت گفت «مدل گوشی‌تون چیه؟»

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

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

این تغییرات سریع و بنیادی ابزارهای هوشمند به قدری «غیرعادی‌ها» را به «عادی» تبدیل کرده که تا چند وقت دیگه اگه یه نفر بیاد و یک کد تر و تمیز رو به شما نشون بده احتمالن ازش می‌پرسید که «مدل دست‌یار هوشمندتون چی هست؟». بدون این که ازش بپرسید که شما علاوه بر دست‌یار، چه چیزهایی خوندید یا تجربه کردید.

گزیده:
شما عکس نمی‌گیرید، شما اون رو خلق می‌کنید. انسل آدامز

پیش‌گفتار

چند باری با یکی از دوستان عزیزم («می مهدی») در مورد تاثیر هوش مصنوعی بر آینده‌ی توسعه‌ی نرم‌افزار صحبت کردیم. این گفتگو بهانه‌ای شد تا کمی بیشتر به آن بپردازم. هفته‌ی گذشته یک سخنرانی بسیار ارزشمند رو به صورت اتفاقی دیدم و بر آن شدم تا خلاصه‌ای از آن را به فارسی برگردانم. امیدوارم برای شما عزیزان مفید باشد.
اصل سخنرانی را می‌تونید در آدرس زیر پیدا کنید.
https://www.youtube.com/watch?v=tbDDYKRFjhk

اهمیت سخنرانی

دستیارهای کدنویسی هوش مصنوعی (AI Coding Assistants)‌ به‌سرعت وارد مهندسی نرم‌افزار شده‌اند، اما تأثیر واقعی آن‌ها همچنان نامشخص است. آیا استفاده از آنها واقعن تحویل نرم‌افزار را سریع‌تر می‌کند یا صرفن باعث می‌شوند کد بیشتری تولید شود که توسعه‌دهندگان مجبور می‌شوند بعدن آن را اصلاح کنند؟ این سوال برای مدیران ارشد فناوری و مدیران مهندسی که مسئول ارزیابی پذیرش هوش مصنوعی هستند، حیاتی است.

یگور دنیسوف-بلانچ (Yegor Denisov-Blanch) در سخنرانی خود در استنفورد، یافته‌هایی از یکی از بزرگ‌ترین مطالعات تجربی درباره بهره‌وری توسعه‌دهندگان ارائه می‌دهد که بر پایه‌ی داده‌های بیش از ۱۰۰,۰۰۰ توسعه‌دهنده است.

دنیسوف-بلانچ، پژوهشگر استنفورد در حوزه مهندسی نرم‌افزار داده‌محور (data-driven software engineering)، مطالعه‌ای چندساله را ارائه کرد که بیش از ۶۰۰ شرکت و میلیاردها خط کد را شامل می‌شود که ۸۰٪ آنها کدهای شرکت‌ها هستند (اهمیت استفاده از کدهای خصوصی (private repositories) به جای کدهای در دسترس عموم ( public repositories) در ارایه توضیح داده شده است).

پژوهش او به این سؤال پاسخ می‌دهد: هوش مصنوعی تا چه اندازه و تحت چه شرایطی بهره‌وری توسعه‌دهندگان را بهبود می‌بخشد؟

استدلال‌های اصلی

۱. چرا مطالعات سنتی شکست می‌خورند

بیشتر مطالعات بهره‌وری که توسط فروشندگان (vendor) انجام یا هدایت می‌شوند، بر مبنای معیارهای ناقصی مانند تعداد کامیت‌ها (commit)، تعداد پی‌آر (PR) یا نظرسنجی‌ها انجام می‌شوند. اما این معیارها با نادیده گرفتن تفاوت‌های اندازه و بزرگی کارها (task size) یا چرخه‌ی رفع اشکال (bug-fix churn)، بهره‌وری را بیش از حد نشان می‌دهند. به گفته دنیسوف-بلانچ: «ارائه کامیت‌های بیشتر لزومن به معنای بهره‌وری بیشتر نیست.». از سوی دیگر، نظرسنجی‌هایی که با مشارکت توسعه‌دهندگان انجام می‌شوند نیز عملکرد بهتری ندارند و آمار نشان می‌دهد که «توسعه‌دهندگان بهره‌وری خود را به‌طور متوسط ۳۰ درصد اشتباه تخمین می‌زنند».

پیامد عملی این واقعیت‌ها این است که رهبران و مدیران باید نسبت به ادعاهای بازاریابی هشیار و محتاط باشند و چارچوب‌های اندازه‌گیری قوی و درستی را اتخاذ کنند.

۲. اندازه‌گیری آنچه اهمیت دارد

تیم استنفورد مدلی طراحی کرده که کارکردهای تحویلی (functionality delivered) را کمی‌سازی می‌کند که در آن، نتایج توسط گروهی از مهندسان متخصص بررسی و اعتبارسنجی می‌شود. این مدل، «خروجی‌ به‌درد بخور و مفید» (useful output) را به جای معیارهایی مانند تعداد خطوط اندازه‌گیری می‌کند. در کل، دستیارهای کدنویسی در ظاهر بهره‌وری را ۳۰-۴۰٪ را افزایش می‌دهند (بهره‌وری ظاهری)، اما بخش زیادی از این بهره‌وری به دلیل «دوباره‌کاری» (rework) و رفع اشتباهات هوش مصنوعی خنثی شده و کاهش پیدا می‌کند. در نتیجه بهره‌وری به صورت خالص و پایدار حدود ۱۵-۲۰٪ افزایش می‌یابد.

پیامد عملی: پذیرش هوش مصنوعی با در نظر گرفتن رفع خطاها، بهره‌وری را افزایش می‌دهد و میزان افزایش، «متوسط» است.

۳. بهره‌وری بر اساس پیچیدگی وظایف متفاوت است

نتایج از ۱۳۶ تیم در ۲۷ شرکت نشان‌دهنده‌ی تفاوت آشکاری در نتایج است:

• کارها با پیچیدگی کم در پروژه‌ها جدید (greenfield): افزایش ۳۰-۴۰٪
• کارها با پیچیدگی زیاد در پروژه‌های جدید (greenfield): افزایش ۱۰-۱۵٪
• کارها با پیچیدگی کم در پروژه‌های موجود (brownfield): افزایش ۱۵-۲۰٪
• کارها با پیچیدگی زیاد در پروژه‌های موجود (brownfield): افزایش ۰-۱۰٪

یادآوری: گرین‌فیلد به پروژه‌ای گفته می‌شود که از صفر شروع می‌شود و براون‌فیلد به پروژه‌ یا کد موجود گفته می‌شود.

این نشان می‌دهد که نه فقط انتخاب ابزار بلکه که نوع کار نیز در نتایج بهره‌وری بسیار تاثیرگذار است.

پیامد عملی: هوش مصنوعی باید برای ایجاد ساختار ابتدایی کد (Scaffolding) (مانند ایجاد فولدرها، فایل‌ها، پیکربندی و کد ابتدایی پروژه)، کدهای تکراری و استاندارد (Boilerplate) (مانند نوشتن مدلهای پایگاه داده یا کدهای CRUD) یا افزودن ویژگی‌های ساده به‌ویژه برای پروژه‌های جدید، هدف‌مند و بهینه شود.

۴. زبان اهمیت دارد

هوش مصنوعی در زبان‌های معروف و اصلی مانند پایتون، جاوا، جاوااسکریپت و تایپ‌اسکریپت بسیار مؤثر است و باعث افزایش ۱۰-۲۰٪ بهره‌وری می‌شود. در زبان‌های کم‌محبوب‌ مانند هسکل، اکسیر یا کوبول (Haskell, Elixir, COBOL)، هوش مصنوعی نه‌تنها مزایای زیادی به همراه ندارد، بلکه می‌تواند با تولید کد بی‌کیفیت، بهره‌وری را کاهش دهد.

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

۵. اندازه پایگاه کد و محدودیت‌های زمینه

هر چه پایگاه‌ کد (code base) بزرگ‌تر و قدیمی‌تر، بازده هوش مصنوعی در آن کمتر است. حتی با پنجره‌های زمینه‌ی بزرگ [پنجره زمینه یا context window به تعداد توکن یا کلمه‌ای گفته می‌شود که یک مدل زبانی یا LLM می‌تواند دریافت کند] هم دقت کدهای تولیدشده با افزایش اندازه ورودی کاهش می‌یابد. به عبارت ساده‌تر، دقت کدنویسی مدل‌های زبانی از حدود ۹۰٪ در ۱,۰۰۰ توکن به حدود ۵۰٪ در ۳۲,۰۰۰ توکن افت می‌کند.

پیامد عملی: هوش مصنوعی بهتر است برای زمینه‌های (کانتکست) کوچک‌تر و ماژولار استفاده شود—پروژه‌های با ساختار مونولیت‌ها(monolith)، کیفیت کدهای خروجی آن را به شدت کاهش می‌دهند.

جمع‌بندی نتایج: داده‌ها چه واقعیتی را نشان می‌دهند

جذاب‌ترین بینش (insight) و یافته در این تحقیق این است که شکافی بین بهره‌وری ادراکی و واقعی (perceived and real productivity)‌ وجود دارد:

• افزایش بهره‌وری از جنبه‌ی ادراکی: توسعه‌دهندگان به دلیل تولید سریع‌تر کد احساس سریع‌تر بودن و افزایش بهره‌وری می‌کنند.
• افزایش بهره‌وری از جنبه‌ی واقعی: پس از کسر بهره‌وری به دلیل دوباره‌کاری‌ها، بهره‌وری واقعی به‌طور متوسط ۱۵-۲۰٪ است.

توجه به این نکته بسیار مهم است زیرا هوش مصنوعی نمودارهای بهره‌وری را یک‌دست و متوازن تغییر نمی‌دهد:

• در حوزه‌های عادی (روتین) و با پیچیدگی کم باعث افزایش توان (throughput) می‌شوند.
• در حوزه‌های پیچیده،‌ قدیمی و زبان‌های نامحبوب، نقش چشم‌گیری در افزایش بهره‌وری ندارند و گاه باعث کاهش آن می‌شوند.
• افزایش بهره‌وری سازمانی به میزان هم‌راستایی هوش مصنوعی با نوع کار بستگی دارد.

این تحقیق تأکید می‌کند که هوش مصنوعی شتاب‌دهنده‌ای همه‌گیر و برای همه‌ی شرایط نیست (universal accelerator) بلکه تقویت‌کننده‌ی موقعیتی (situational multiplier) است.

راهنمای پیاده‌سازی

رهبران مهندسی می‌توانند با موارد زیر تأثیر را به حداکثر برسانند:

• تطبیق هوش مصنوعی با نوع کار: برای کارهای با پیچیدگی کم استفاده کنید، نه سیستم‌های حیاتی.
• اندازه‌گیری کارکردها، نه کامیت‌ها: برای بهره‌وری، معیارهای مبتنی بر خروجی و نتایج را اتخاذ کنید.
• اولویت‌بندی زبان‌های محبوب: روی پایتون، جاوا، جاوااسکریپت/تایپ‌اسکریپت قبل از تکنولوژی‌های خاص تمرکز کنید.
• نظارت بر میزان دوباره‌کاری: چرخه‌ی رفع اشکال (باگ‌ها) را کنترل کنید تا اسیر ادعاهای اغراق‌آمیز نشوید.
• استفاده ماژولار: استفاده از هوش مصنوعی را به زیرسیستم‌ها محدود کنید، نه کل پایگاه کد و مونولیت‌ها.
• آموزش توسعه‌دهندگان: انتظارات را هم‌راستا و مبتنی بر واقعیت‌ها کنید—هوش مصنوعی ابزار است، نه جایگزین.
• پذیرش و استفاده‌ی تدریجی و تکراری: معیارهای بهره‌وری را هر سه ماه بازبینی کنید، زیرا مدل‌ها در حال تکامل هستند.

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

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

نتیجه‌گیری

ابزارهای کدنویسی هوش مصنوعی بهره‌وری را افزایش می‌دهند—اما نه همه‌جا و نه به‌طور یکسان برای همه‌ی موارد. افزایش بهره‌وری در کارهای با پیچیدگی کم و پروژه‌های جدید (گرین‌فیلد) در زبان‌های اصلی بالاتر است و به‌طور متوسط ۱۵-۲۰٪ است. مدیران باید رویکردی گزینشی و داده‌محور اتخاذ کنند و هوش مصنوعی را با تکنیک‌های مهندسی همراه کنند. در ۶ تا ۱۲ ماه آینده، پیشرفت در افزایش بزرگی زمینه (کانتسک) در مدل‌های زبانی ممکن است عملکرد آنها را بهبود بخشد، اما پیچیدگی، اندازه پایگاه کد و دوباره‌کاری همچنان محدودیت‌های اساسی خواهند بود.

خلاصه

• ابزارهای کدنویسی هوش مصنوعی پس از کسر دوباره‌کاری‌ها، بهره‌وری را ۱۵-۲۰٪ افزایش می‌دهند.
• بهترین نتایج برابر است با افزایش ۳۰-۴۰٪ در بهره‌وری برای کارهای با پیچیدگی کم و پروژه‌های جدید (گرین‌فیلد) در زبان‌های محبوب.
• ریسک‌های استفاده از آنها عبارتند از بی‌تأثیری یا تاثیر منفی آنها در محیط‌های پیچیده، قدیمی یا با تکنولوژی‌های خاص.

گزیده:
ندارد.

پیش گفتار:

تراویس الفنت (Travis Oliphant) یکی از تاثیرگذارترین برنامه‌نویسان و دانشمندان داده است. او خالق NumPy و هم‌بنیان‌گذار SciPy و Anaconda و NumFOCUS است. این نوشته برگرفته از مصاحبه‌ای است که لکس فریدمن (Lex Fridman) با وی انجام داده است.

گفتار:

لکس فریدمن: می‌خواستم ازت چیزی بپرسم چون تو یکی از تاثیرگذارترین برنامه‌نویسان تاریخی و رهبر (مدیر) برنامه‌نویسان زیادی بودی و هنوز هم هستی. از دیدگاه یه برنامه‌نویس، چه عواملی باعث می‌شه یه برنامه‌نویس، برنامه‌نویس خوبی بشه و یا چی باعث می‌شه یه برنامه نویس،‌ برنامه‌نویسی بشه با کارایی بالا.

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

اولی کنجکاوی‌یه(curiosity)! برنامه‌نویسی که کنجکاو نباشه،‌ یه برنامه‌نویس معمولی می‌شه. خیلی زود هم انگیزه‌‌اش رو از دست می‌ده. همه‌ی تلاش‌اش رو هم نمی‌کنه. کنجکاوی اساسن یه ویژگی شخصی‌یه – یعنی اینکه شما تا چه حد درباره‌ی موضوعات کنجکاو هستید.

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

یکی از چیزهایی که همیشه جواب می‌ده اینه که مساله‌ای که می‌خواهید حل کنید رو کوچک و محدود کنید. اگر عضو تیمی هستید احتمالن یکی دیگه معماری پروژه را آماده می‌کنه و یه بخشی از کار رو به شما می‌ده. اگه جوونید یا عضو تیمی نیستید، برای این که کار رو پیش ببرید خیلی مهمه که مساله رو به بخش‌های کوچک‌تر بشکنید. اگه یه پروژه بزرگ رو بردارید و بخواهید همه چیز را یکجا و یکباره انجام بدید، دور از انتظار نیست که توی اون گم بشید و کار رو به شکل بدی انجام بدید.

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

از کارهای دیگران هم استفاده بکنید. فکر نکنید که باید همه چیز رو خودتون انجام بدید. هیچ‌کس این کار رو نمی‌کنه. روی شانه‌های غول‌ها بایستید (کنایه از اینکه از کارهای بقیه استفاده کنید). اما این جوری نباشه که فقط کپی-پیست بکنید. این موضوع به‌ويژه در دوره‌ی کنونی که کدکس (Codex – ابزار هوش مصنوعی OpenAI برای تولید کد) و کدهای خودکار تولیدشده اهمیت بیشتری داره. …. نکته اینجاست که کپی-پیست کنید ولی نه کپی‌-پیست کورکورانه. خودم بارها و بارها کپی-پیست کرده‌ام تا بفهمم و بعد متوجه شدم که این کد چه معنایی داره و چه کاری انجام می‌ده. تا جایی که می‌تونید باید کد رو بفهمید و درک کنید. توی این شرایط، کنجکاوی خیلی مهمه. اگر فقط کورکورانه کپی-پیست کنید، چیزی یاد نمی‌گیرید.

نکته‌ی بعدی اینه که حواس‌تون به چرخه‌های هیجان (hype cycle) باشه [توضیح پایین رو بخونید]. هر چند وقت یک‌بار، چیزی می‌آد که همه می‌گند «این جواب همه‌ی مشکلات‌مونه!». مثلن توسعه‌ی آزمون‌محور، برنامه‌نویسی شی‌گرا یا چابکی (Agile). مراقب باشید که توی دام این جور چرخه‌های هیجانی نیفتید. حتمن چیزهای ارزشمندی توی اون‌ها وجود داره که می‌تونید از اون‌ها یاد بگیرید، اما تقریبن مطمئن باشید که این‌ جور چیزها پاسخ همه‌ی مشکلات نیستند.

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

گزیده:
ندارد.

پیش‌گفتار: فرضیه‌ی پیچیدگی متناسب تورنگیت
(Thorngate’s postulate of commensurate complexity)

فرضیه‌ی پیچیدگی متناسب، توصیفی از یک پدیده در نظریه‌پردازی علوم اجتماعی است. کارل ای. ویک (Karl E. Weick) ادعا می‌کند که تحقیقات در زمینه روانشناسی اجتماعی همواره می‌تواند فقط دو ویژگی از سه ویژگی متا-نظری ‘عمومیت’ (Generality)، ‘دقت’ (Accuracy) و ‘سادگی’ (Simplicity) را داشته باشد. بنابراین، یکی از این سه ویژگی‌ همیشه باید تابع دو ویژگی دیگر باشد.به عبارت ساده‌تر یک مدل تنها دو ویژگی از سه ویژگی عام بودن، دقیق بودن و ساده بودن را داشته باشد و نه هر سه‌ی آنها را.
این فرضیه به نام روانشناس اجتماعی کانادایی وارن تورنگیت (Warren Thorngate) از دانشگاه آلبرتا نامگذاری شده است. وی در توصیف مساله می‌گوید: «برای افزایش عمومیت دقت نظریه‌ها به ناچار باید پیچیدگی آنها افزایش یابد».

کارل ویک برای نمایش این مفهوم از تصویر ساعت زیر استفاده کرد. در این ساعت روی ساعت ۱۲، ۴ و ۸ سه عبارت عمومیت، دقت و ساده نوشته شده است. حالا به مفهوم ساعت ۲ و ۶ و ۱۰ دقت کنید
– ساعت ۲: تحقیقات برای همه جا قابل استفاده‌اند و جزئیات زیادی هم دارند، اما پیچیده می‌شوند و سادگی خود را از دست می‌دهند.
– ساعت ۶: تحقیقات برای یک زمینه خاص مفیداند، اما نتایج‌شان به طور کلی قابل اعمال به دیگر زمینه‌ها و تعمیم‌پذیر نیستند.
ساعت ۱۰: تحقیقات برای همه جا قابل استفاده‌‌اند و به آسانی قابل درک‌اند، اما جزئیات کافی و خیلی دقیقی ندارند.

کارل ویک ادعا می‌کند که شما باید یک تصمیم بینابینی (tradeoff) برای انتخاب این سه ویژگی بگیرید زیرا در هر زمان تنها دو تای آنها قابل دست‌یابی هستند.

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

اکنون وقت آن است که چند راه حل قبلی خودتان را مرور کنید و ببینید در دنیای راهکارهای شما ساعت چند است.

منبع:
– ایده‌ی این نوشته از کتاب Mastering DDD نوشته‌ی Annegret Junker آمده است.

بخش گذشته (لینک)

در این بخش می‌خواهیم با هم یاد بگیریم که چگونه یک متن به یک بردار تبدیل می‌شود. تبدیل متن به بردار یکی از پایه‌ای ترین و مهم‌ترین کارها در پردازش زبان طبیعی و یادگیری ماشین است.
با تبدیل متن به بردار می‌توان بخش عمده‌ای از عملیات مورد نیاز برای پردازش زبان طبیعی به عملیات روی بردارها تبدیل می‌شود. برای درک این موضوع اجازه دهید مثالی از درس فیزیک را با هم مرور کنیم.

در مبحث حرکت در درس فیزیک،‌ نقطه‌ای را به عنوان مبدا در نظر می‌گرفتیم. موقعیت متحرک را هم روی محور افقی (محور ایکس) نشان می‌دادیم. مثلن اگر متحرک در سمت راست مبدا مختصات و به فاصله ۵ متری آن بود آن را به صورت بردار مثبت ۵ (+۵) نشان می‌دادیم. اگر متحرک به اندازه ۷ متر به سمت چپ حرکت می‌کرد، میزان جابه‌جایی آن را به صورت بردار منفی ۷ (-۷) نشان می‌دادیم. برای پیدا کردن مقصد متحرک کافی است که دو بردار +۵ و -۷ یعنی مبدای حرکت و میزان جا به جایی متحرک را با هم جمع کنیم تا به مقصد یعنی منفی ۲ (-۲) برسیم. در اینجا اگر سه متحرک الف،‌ ب، پ داشته باشیم که بردار مکان آنها +۴ و +۱۳ و +۱۵ باشد می‌توانیم نتیجه بگیریم که دو متحرک ب و پ که فاصله‌ی بردار آنها ۲ است به هم نزدیک‌ترند تا دو متحرک الف و ب که فاصله‌ی دو بردار آنها ۱۱ است.

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

بردارسازی که به آن دگرنمایی یا جاسازی (embedding) هم گفته می‌شود [به معنای جا دادن کلمات در یک فضای چند بعدی یا نمایش کلمات در یک فضای چند بعدی] کمک می‌کند تا کلمات در یک فضا (مشابه با محورهای مختصات در درس فیزیک) جاسازی شوند. در پایان جاسازی واژگان، هر واژه در نقطه‌ای از این فضا قرار می‌گیرد که شبیه به نمایش مکان متحرک در مثال قبلی است. هر چه دقت این بردارها بیشتر باشد عملیات بعدی دقیق‌تر و درست‌تر خواهد بود.

حالا با در نظر گرفتن آموخته‌های درس فیزیک بیایید مثالی از بردارهای کلمات را با هم مرور کنیم. برای سادگی فرض می‌کنیم که دستگاه مختصات یک بعدی است و فقط محور ایکس وجود دارد. در نظر بگیرید که در پایان بردارسازی کلمات، کلمه‌ی «برادر» در نقطه‌ی ۱۱ و کلمه‌ی «مرد» در نقطه‌ی ۶ و کلمه‌ی «زن» در نقطه‌ی +۷ قرار گرفته باشند. حدس بزنید اگر بردارهای «مرد»، «زن» و «برادر» را به شکل زیر جمع و تفریق کنیم نتیجه‌ چه خواهد شد؟

برادر – مرد + زن = ؟

احتمالن درست حدس زدید! نتیجه‌ی این عملیات ریاضی که بردار +۱۲ خواهد بود باید محل قرار گرفتن کلمه‌ی «خواهر» در دستگاه مختصات باشد.
حالا به این پرسش پاسخ دهید:
گیلان – رشت + کردستان = ؟
بله! پاسخ باید برابر با سنندج باشد اگر مکانیزم بردارسازی ما به اندازه کافی دقیق و درست باشد.

با این مقدمه نگاهی بندازیم به ویدیوهای زیر که تلاش دارد نشان دهد چگونه می‌توان کلمات را در نقاط مختلف یک فضا جاسازی کرد.
ویدیوی یک: از ابتدا تا دقیقه ۶
لینک
A Complete Overview of Word Embeddings by AssemblyAI

ویدیوی دو: از دقیقه ۶:۳۰ تا دقیقه ۱۰:۳۰
لینک
What Are Word Embeddings? by Under The Hood

پیش گفتار:
در این نوشته‌ها می‌خواهم منابعی برای آشنایی کاربردی با هوش مصنوعی را معرفی کنم. مخاطبان اصلی این نوشته‌ها،‌ توسعه‌دهندگان نرم‌افزار هستند و تمرکز بر هوش مصنوعی مولد (Gen AI) خواهد بود. تلاش می‌کنم مفاهیم و مباحث فنی‌تر این حوزه تا جایی که به کاربرد بهتر کمک کند در منابع گنجانده شود. اولویت در انتخاب منابع بر منابع ویدیویی خواهد بود.

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

درس ۱: پرامپت‌نویسی
منبع:‌ Master the Perfect ChatGPT Prompt Formula
آدرس: لینک

گزیده:
قبلن استک‌اورفلو (stackoverflow) همیشه جلوی من باز بود و ازش برای برنامه‌نویسی استفاده می‌کردم. الان به جاش چت GenAI جلوم بازه ولی اصلن احساس نمی‌کنم یک برنامه‌نویس‌ام. احساس می‌کنم شدم یک مدیر میانی‌ که باید مودبانه و با خواهش از کارآموز نابغه و غیرقابل پیش‌بینی‌ام بخوام که «لطفن رنگ اون دکمه (button) توی فرم رو آبی‌ش کن» 😄
به نقل از خود GenAI 😄

همان طور که قبلن نوشتم، در یک گروه کوچک و دوستانه کتاب‌هایی را به شیوه‌ی «آهسته و پیوسته» می‌خوانیم و با هم در مورد آنها گفتگو می‌کنیم. این بار نوبت به کتاب «چگونه تصمیم بگیریم: ابزارهای ساده برای انتخاب‌های بهتر» (How to Decide: Simple Tools for Making Better Choices) اثر آنی دوک (Annie Duke) رسید.

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

گزیده:
کیفیت نتایج یک تصمیم مانعی است در برابر توانایی درک ما از کیفیت آن تصمیم‌. آنی دوک

The quality of the outcome casts a shadow over our ability to see the quality of the decision.

توضیح: این جمله بدین معناست که معمولاً قضاوت ما از کیفیت (درستی/نادرستی) تصمیم‌ها بر اساس نتایج آنهاست. اگر نتیجه‌‌ی تصمیم خوب باشد، فکر می‌کنیم تصمیم خوبی گرفته‌ایم و اگر نتیجه بد باشد، تصور می‌کنیم تصمیم بدی گرفته‌ایم. در حالی که چنین رویکردی همیشه درست نیست.