نوشته های محمدرضا مصباحی

اصول مهندسی پرامپت (Prompt Engineering) - بخش 1#

محمدرضا مصباحی — Sat, 10 Jun 2023 00:21:32 +0330

این روزها همه در مورد LLM ها،ChatGPT ، Midjourney و هوش مصنوعی های دیگر صحبت می کنند. Prompt Engineering مفهومی جدید است که به سرعت دوره های آموزشی آن در حال انتشار است. اما LLM و Prompt Engineering چیست؟ چطور کار می کنند؟ موارد استفاده چیست؟ من محمدرضا مصباحی در این مجموعه مقالات آموزشی سعی خواهم کرد به همه این سوالات پاسخ دهم و همراه با شما بهترین الگوهای استفاده از ChatGPT را در حوزه های مختلف مرور کنیم.مفهوم LLM ها چیست؟در واقع LLM مخفف عبارت “Large Language Model” و به معنای "مدل زبان بزرگ" است. این مدل های زبانی در حقیقت سیستم‌های هوش مصنوعی پیشرفته‌ای هستند که برای درک و تولید متن‌های شبیه به زبان انسان‌ ها (human-like) بر اساس ورودی‌هایی که دریافت می‌کنند، طراحی شده‌اند. این مدل‌ها بر روی حجم وسیعی از داده‌های متنی آموزش داده شده اند و می‌توانند طیف گسترده‌ای از وظایف مرتبط با زبان، مانند پاسخ به سؤالات، انجام مکالمات، خلاصه‌نویسی متن، ترجمه زبان‌ها و موارد دیگری در این حوزه را انجام دهند.در چند سال گذشته مرکز تحقیقات OpenAI با مدل‌ها و تحقیقات خود، سهم عمده‌ای در توسعه این فضا داشته است. با این حال، بازیگران دیگری نیز در بازار وجود دارند، به عنوان مثال، شرکت متا با مدل‌های OPT، OPT-IML و LLaMA خود، گوگل FLAN-T5 و BERT، StableLM توسط Stability AI، Alpaca در استانفورد و بسیاری از مدل‌های متن‌باز دیگر را منتشر کرد.انواع LLM هادر یک طبقه بندی سطح بالا، LLM ها را می توان به دو نوع دسته بندی کرد، یعنی LLM های پایه (Base LLMs) و LLM های تنظیم شده با دستورالعمل (Instruction Tuned LLMs).نوع اول: LLM های پایه (Base LLMs)این نوع پایه در واقع LLM هایی هستند که برای پیش بینی کلمه یا عبارت بعدی بر اساس داده های آموزش داده شده طراحی شده اند. این مدل زبان برای پاسخ به سؤالات، انجام مکالمات یا کمک به حل مشکلات طراحی مانند مدل 3-GPT طراحی نشده اند. به عنوان مثال، اگر به یک LLM پایه جمله “In this book about LLMs, we will discuss” را بدهید، ممکن است این جمله را کامل کند و به شما بگوید: “In this book about LLMs, we will discuss what LLMs are, how they work, and how you can leverage them in your applications.” یا اگر به آن بگویید “What are some famous social networks?”به جای پاسخ دادن، ممکن است پاسخ دهد:“Why do people use social networks?” همانطور که می بینید، عبارتی سوالی و مرتبط با سوال قبلی را به ما می دهد اما به سوال پاسخی نمی دهد. اینجاست که LLM های تنظیم شده با دستورالعمل وارد بازی میشوند.نوع دوم: LLM های تنظیم شده با دستورالعمل (Instruction Tuned LLMs)این نوع از مدل های زبان، به جای تلاش برای تکمیل خودکار متن شما، سعی می کنند تا از دستورالعمل های خواسته شده با استفاده از داده هایی که بر روی آنها آموزش دیده شده اند تبعیت کنند و دستورالعملی را برای شما انجام دهند. به عنوان مثال، اگر جمله“What are LLMs?”را وارد کنید. از داده هایی که بر روی آن آموزش دیده شده است و در اصطلاح بر روی آن داده ها Train شده است، استفاده می کند و سعی می کند به سوال شما پاسخ دهد. به طور مشابه، اگر سوال:“What are some famous social networks?”را مطرح کنید، این مدل های زبان سعی خواهند کرد تا به جای اینکه به شما یک پاسخ تصادفی بدهد برای سوال شما یک پاسخ دقیق براساس داده ای یادگرفته شده تولید کنند. این نوع مدل های زبانی یعنی Instruction Tuned LLM ها بر روی Base LLM ساخته شده اند. در حقیقت می توان اینطور بیان کرد که:Instruction Tuned LLMs = Base LLMs + Further Tuning + RLHFبرای ساختن یک دستورالعمل تنظیم‌شده LLM، یک Base LLM به عنوان مبناب کار در نظر گرفته می‌شود و با استفاده از یک مجموعه داده بزرگ که نمونه های «دستورالعمل‌ها» را پوشش می‌دهد و اینکه چگونه مدل باید در نتیجه آن دستورالعمل‌ها عمل کند، آموزش داده می‌شود. سپس این مدل با استفاده از تکنیکی به نام «یادگیری تقویتی با بازخورد انسانی» (RLHF - Reinforcement Learning with Human Feedback) تنظیم می‌شود که به مدل اجازه می‌دهد از بازخورد انسان بیاموزد و عملکرد خود را در طول زمان بهبود بخشد.جمع بندیبه طور خلاصه میتوان گفت که LLM ها ابزار قدرتمندی هستند که می توانند برای حل طیف وسیعی از وظایف مرتبط با زبان مورد استفاده قرار گیرند. آنها در صنایع مختلف مانند مراقبت های بهداشتی، مالی، آموزش و غیره برای خودکارسازی فرآیندها و بهبود کارایی استفاده می شوند. LLM ها این پتانسیل را دارند که شیوه تعامل ما با سیستم های کامپیوتری را متحول کنند و زندگی ما را آسان تر کنند.با شناختی که از این مدل های زبان در این مقاله بدست آوردید در مقاله بعدی سعی خواهیم کرد تا مقدمات Prompt Engineering را با هم بررسی کنیم.

راهنمای اصول طراحی پایتون: The Zen of Python (بخش ۲)

محمدرضا مصباحی — Fri, 16 Oct 2020 16:31:01 +0330

Explicit is better than implicitهمانطور که در بخش ۱ از سری مقاله های Zen of Python اشاره شد، در این مجموعه مقالات هدف ما تشریح و درک این اصول 19 گانه و در نهایت رسیدن به الگوی Clean Code نه تنها به عنوان راهنمای اصول طراحی در پایتون، بلکه در همه زبان های برنامه نویسی است. در مقاله قبلی اولین فلسفه یعنی Beautiful is better than ugly را با هم دیدیم و تاکید این اصل که بر خوانایی کد است را با مثال هایی با هم بررسی کردیم.در این مقاله به تفسیر و تحلیل اصل دوم می پردازیم.Explicit is better than implicit.همانطور که خود عبارت “بیان صریح بهتر از ضمنی است.” گویا است، بهتر است که کد نوشته شده شفاف و صریح باشد. با در نظر گرفتن این رویکرد، کد شما قابلیت خوانایی بیشتری خواهد داشت. پنهان کردن عملکرد یک قطعه کد ممکن است عواقب زیادی داشته باشد زیرا سایر برنامه ها ممکن است قادر به درک کد نباشند.یکی از مصادیق اصلی این اصل هنگامی است که شما می خواهید در برنامه از یک Library استفاده کنید. برای این کار، نه تنها در زبان برنامه نویسی پایتون، بلکه در بسیاری از زبان های دیگر هم چون ES6، Typescript، Java و ...، شما از کلمه کلیدی import استفاده می کنید. در بسیاری از مواقع برنامه نویسان برای load بیش از یک Module از * در هنگام import کردن یک library در کد استفاده میکنند که باعث می شود همه ماژول ها دردسترس باشند، اما همانطور که بدیهی است صراحت و شفافیت کد که در واقع به طور دقیق از کدام ماژول ها استفاده خواهد شد کاسته می شود. برای درک بهتر این مفهوم مثال زیر را در نظر بگیرید:مسئله: "مدل های cat، dog و mouse را load کنید تا بتوانیم نمونه هایی از آنها را ویرایش کنیم."برای انجام این عمل هر دو راهکار زیر قابل اعمال است:Solution#1:def load(): from menagerie.cat.models import * from menagerie.dog.models import * from menagerie.mouse.models import *Solution#2:def load(): from menagerie.models import cat as cat_models from menagerie.models import dog as dog_models from menagerie.models import mouse as mouse_modelsهمانطور که مشخص است در Solution#2 به طورصریح و Explicit مدل ها فراخوانی و بنابراین به راهکار دیگر ترجیح داده می شود شده اند.نکته دیگر در این اصل را می‎توان توجه به نامگذاری در فراخوانی Module ها دانست. بهتر است هر بار که یک ماژول را فراخوانی می‎کنید، صریحاً آن را نامگذاری کنید. مثال زیر را در نظر بگیرید:from math import sin def sin(a): return "Not Commenting is a sin" print(sin(1))سوالی که در اینجا مطرح است، این است که کدام sin در اینجا فراخوانی شده است؟اگر برای استفاده از Module ها کد را به صورت زیر Refactor کنیم و هر بار برای فراخوانی یک ماژول صریحاً آن را نامگذاری کنیم خوانایی و شفافیت بیشتری وجود خواهد داشت و مشکل قبلی که ناشی از عدم بیان Explicit در کد است از بین خواهد رفت.import math def sin(a): return "Not Commenting is a sin" print(sin(1)) print(math.sin(1))Explicit is better than implicit در این مقاله سعی کردیم با مثال هایی مفهوم Explicit is better than implicit در PEP 20 را توضیح دهیم. در مقاله بعدی با هم به بحث Simple is better than complex می پردازیم.

بهبود عملکرد اپلیکیشن‎های +Angular 2 با trackBy

محمدرضا مصباحی — Fri, 09 Oct 2020 12:45:56 +0330

َAngular Performance Improvment مساله:خیلی وقت ها هست که شما در وب اپلیکیشن های Angular خودتون نیاز دارید که روی یک Collection پیمایش انجام بدید و برای نمایش اعضای اون احتمالاً از دستور ngFor استفاده می کنید که یک الگو را یک بار در هر مورد از مجموعه ایجاد می کند. مثلا:

{{item.name}}

حالا اگر زمانی پیش بیاد که ما نیاز به تغییر داده های این مجموعه داشته باشیم، به عنوان مثال در نتیجه درخواست یک API، یا تعاملی که کاربر با برنامه خواهد داشت و به طور مثال موردی را حذف کند یا چیزی را اضافه کند، ما با یک مشکل روبرو هستیم! چون Angular نمی تواند موارد موجود در مجموعه را ردیابی کند و هیچ اطلاعی از اینکه کدام موارد حذف یا اضافه شده اند را ندارد.در نتیجه، Angular باید تمام عناصر DOM مربوط به داده ها را حذف کرده و دوباره آن ها را ایجاد کند. این یعنی در بسیاری از دستکاری های DOM خصوصاً در مورد مجموعه بزرگی از داده‎ها، این دستکاری های DOM میتواند خیلی هزینه بر و گران باشد و در حقیقت عملکرد و کارایی برنامه شما را کاهش دهد.نکته: وقتی صحبت از “تغییر داده ها” می کنیم، منظور این است که در Collection اعضای جدیدی را جایگزین کنیم و یعنی دیگه همان Reference قبلی را حفظ نمی کنیم.راهکار:ما می تونیم با ارائه یک تابع trackBy به Angular کمک کنیم تا مواردی را که اضافه یا حذف می شوند را پیگیری کند. تابع trackBy در واقع index و item فعلی را به عنوان آرگومان ورودی می گیرد و باید یک شناسه منحصر به فرد را برای این item برگرداند. برای اینکه بهتر کاربردش را بفهمیم یک مثال با هم ببینیم:حالا با این روش وقتی که مجموعه داده شما تغییر کند، Angular می‎تواند با توجه به شناسه منحصر به فرد، ردیابی کند که کدام موارد اضافه یا حذف شده و فقط موارد تغییر یافته را ایجاد یا حذف کند. بنابراین دیگر همه DOM شما برای همه موارد دوباره ایجاد نخواهد شد که این خود تاثیر به سزایی در بهبود Performance اپلیکیشن شما خواهد داشت.به همین سادگی!

راهنمای اصول طراحی پایتون: The Zen of Python (بخش ۱)

محمدرضا مصباحی — Fri, 09 Oct 2020 12:19:34 +0330

همانطور که همه برنامه نویسان پایتون آشنا هستند برای استفاده از Libraryها و Packageهای مختلف در Python از کلمه کلیدی import به همراه نام library در مقابل آن استفاده می کنیم. اما آیا تا به حال this را import کردید؟import thisخروجی دستور import this در پایتون: The Zen of Pythonبله این ها در حقیقت جملات قصاری هستند که به Zen of Python مشهور هستند. (PEP 20)در حقیقت Zen of Python مجموعه ای از 19 "اصل راهنما" برای نوشتن برنامه های کامپیوتری است که بر طراحی زبان برنامه نویسی Python تأثیر می گذارد. مهندس نرم افزاری با نام Tim Petersاین مجموعه اصول را در سال 1999 نوشت و در لیست پستی پایتون قرار داد. لیست Peters اصل 20ام را با عنوان "for Guido to fill in" خالی گذاشت تا گویدو ون روسوم، نویسنده اصلی زبان پایتون، اصل 20ام را ارائه کند. اما جای خالی اصل 20ام هنوز پر نشده است.در سری مقاله های Zen of Python با هم با این اصول 19 گانه طراحی برنامه که به نوعی Best Practice هایی در جهت نوشتن کد Readable هستند و تفسیر معانی آن ها خواهیم پرداخت. در ادامه این مقاله به توضیح فلسفه اول خواهیم پرداخت.1. Beautiful is better than ugly.Beautiful is better than uglyبرنامه نویس بودن، تنها به نوشتن یکسری کد و اجرای آن ها نیست. Python زبانی است که به خاطر ویژگی های خوانایی (Readability) و سادگی (Simplicity) کدنویسی آن شناخته شده است. اگر شما یک Data Science هستید ممکن است غالبا کدی را بنویسید که به سادگی جواب دهد و شاید شما بیشتر به کارایی زمانی و میزان مصرف منابع اهمیت دهید، اما به ندرت خوانایی کد مورد توجه شما باشد. اما نوشتن کد تمیز و خوانا هنری است که باعث تحسین شما از طرف سایر برنامه نویسان شده و به آن ها این امکان را می دهد که بتوانند ذره ذره کد شما را درک کنند.هر چند در بسیاری از زبان های برنامه نویسی، "زیبا" بودن کد اجباری نیست، اما Python به عنوان یک زبان برنامه نویسی برای حفظ consistency، readability و simplicity طراحی شده است. به طور مثال تفاوت Syntax ای همچون استفاده از and، or در پایتون در مقابل || و && در بسیاری از زبان هایی همچون C، C++ و ... یکی از این حفظ زیبایی و خوانایی ها است.if ( condition_1 && var1 == 0 || flag == 'yes') { // Code here... }در مقایسه با کد Python زیر:if condition_1 and var1 == 0 or flag == 'yes': # Code here...نکته دیگر در فلسفه طراحی Python، استفاده قابل توجه از Whitespace و تاکید بر خوانایی کد و درحقیقت توجه به Indentation style در آن است. در Python برخلاف بسیاری از زبانهای دیگر که از Bracket {} برای نشان دادن بلوک کد استفاده می‎شود، از فضای سفید برای نشان دادن آن ها استفاده می شود که باعث پیاده سازی Indentation style ودر نتیجه افزایش قابلیت خوانایی کد می شود و شما را به عنوان برنامه نویس مجبور به نوشتن کد خوانا می کند. اما بسیاری موراد دیگر وجود دارد که برنامه نویس باید به آن ها توجه کند و سعی در نوشتن کد خوانا داشته باشد. به طور مثال کد زیر را در نظر بگیرید:def isEven(num): if num %2 == 0: return True else: return Falseدر کد بالا نیازی به افزودن "else" نیست. در اینجا وجود "else" غیر ضروری است. بنابراین، برای بهتر و تمیزتر کردن آن می توان کد را به این صورت Refactor‌ کرد:def isEven(num): if num %2 == 0: return True return Falseبه عنوان آخرین مثال از بحث Beautiful is better than ugly مساله زیر را در نظر بگیرید:"پیاده سازی تابعی که لیستی از اعداد را دریافت کرده و لیستی از مجذور اعداد زوج آن را برمی گرداند."دو راهکار زیر را در نظر بگیرید:Solution #1:squareEvens = lambda nums: map(lambda i:i**2, filter(lambda i: not i%2, nums))Solution #2:def squareEvens(nums): return [i**2 for i in nums if not i % 2]هر دو راهکار بالا جواب مساله شما را خواهند داد، اما همانطور که از ظاهر کد مشخص است راهکار Solution #2 قابلیت خوانایی بالاتر و سادگی بیشتری را دارد و بنابراین از نقطه نظر Code Readability مناسب تر است.در این مقاله سعی کردیم با مثال هایی مفهوم Beautiful is better than ugly در PEP 20 را توضیح دهیم. در مقاله بعدی با هم به بحث Explicit is better than implicit می پردازیم.