همانطور که برای کاربردهای واقعی، دستورالعملهایی را طراحی میکنید، یک بدهبستان کلیدی پدیدار میشود: ایجاد تعادل بین اختصار و اثربخشی. وقتی همه عوامل برابر باشند، یک دستورالعمل مختصر، سریعتر، ارزانتر و نگهداری آن آسانتر از یک دستورالعمل طولانیتر است. این امر به ویژه در محیطهای وب که تأخیر و محدودیتهای توکن اهمیت دارند، اهمیت دارد. با این حال، اگر دستورالعمل شما بیش از حد مختصر باشد، مدل ممکن است فاقد زمینه، دستورالعملها یا مثالهایی برای تولید نتایج با کیفیت بالا باشد.
توسعه مبتنی بر ارزیابی (EDD) به شما امکان میدهد تا به طور سیستماتیک این بده بستان را رصد و بهینه کنید. این روش، یک فرآیند تکرارپذیر و قابل آزمایش برای بهبود خروجیها در گامهای کوچک و مطمئن، شناسایی رگرسیونها و همسوسازی رفتار مدل با انتظارات کاربر و محصول در طول زمان ارائه میدهد.
آن را به عنوان توسعه مبتنی بر آزمون (TDD) در نظر بگیرید که برای عدم قطعیت هوش مصنوعی تطبیق داده شده است. برخلاف آزمونهای واحد قطعی، ارزیابیهای هوش مصنوعی را نمیتوان به صورت کدنویسیشده ارائه داد زیرا خروجیها، چه خروجیهای خوشفرم و چه خروجیهای ناموفق، میتوانند شکلهای پیشبینینشدهای به خود بگیرند.
EDD همچنین از تلاشهای اکتشافی شما پشتیبانی میکند. درست همانطور که نوشتن تستها به شفافسازی رفتار یک ویژگی کمک میکند، تعریف معیارهای ارزیابی و بررسی خروجیهای مدل شما را مجبور میکند تا با عدم شفافیت روبرو شوید و به تدریج جزئیات و ساختار بیشتری را به وظایف نامشخص یا ناآشنا اضافه کنید.
مشکل را تعریف کنید
شما میتوانید مسئله خود را مانند یک قرارداد API، شامل نوع ورودی، فرمت خروجی و هرگونه محدودیت اضافی، قالببندی کنید. برای مثال:
- نوع ورودی: پیشنویس پست وبلاگ
- قالب خروجی: آرایه JSON با ۳ عنوان پست
- محدودیتها: کمتر از ۱۲۸ کاراکتر، با لحنی دوستانه
سپس، ورودیهای نمونه را جمعآوری کنید. برای اطمینان از تنوع دادهها، هم نمونههای ایدهآل و هم ورودیهای واقعی و نامرتب را در نظر بگیرید. به تغییرات و موارد حاشیهای، مانند پستهایی با ایموجی، ساختار تو در تو و تعداد زیادی قطعه کد فکر کنید.
مقداردهی اولیه یک خط پایه
اولین سوال خود را بنویسید. میتوانید با zero-shot شروع کنید و موارد زیر را در آن بگنجانید:
- دستورالعملهای واضح
- فرمت خروجی
- جایگذاری متغیر ورودی
شما پیچیدگی را افزایش میدهید و هنگام ارزیابی و بهینهسازی با سایر مؤلفهها و تکنیکهای پیشرفتهی راهنمایی کار میکنید. ابتدا باید یک سیستم ارزیابی راهاندازی کنیم تا تلاش بهینهسازی را در مسیر درست هدایت کند.
سیستم ارزیابی خود را ایجاد کنید
در TDD، شما زمانی که نیازمندیها را میدانید، شروع به نوشتن تست میکنید. با هوش مصنوعی مولد، هیچ خروجی قطعی برای تست وجود ندارد، بنابراین باید تلاش بیشتری برای ایجاد حلقه ارزیابی خود صرف کنید.
برای ارزیابی مؤثر، احتمالاً به ابزارهای اندازهگیری متعددی نیاز دارید.
معیارهای ارزیابی خود را تعریف کنید
معیارهای ارزیابی میتوانند قطعی باشند. برای مثال، ممکن است بررسی کنید که آیا مدل JSON معتبری را برمیگرداند یا تعداد صحیحی از موارد را خروجی میدهد.
با این حال، بخش عمدهای از وقت شما باید به شناسایی و اصلاح معیارهای ذهنی یا کیفی، مانند وضوح، سودمندی، لحن یا خلاقیت اختصاص یابد. ممکن است با اهداف کلی شروع کنید، اما به سرعت با مسائل جزئیتری روبرو شوید.
برای مثال، فرض کنید تولیدکننده عنوان شما بیش از حد از عبارات یا الگوهای خاصی استفاده میکند که منجر به نتایج تکراری و رباتیک میشود. در این صورت، شما معیارهای جدیدی را برای تشویق به تنوع و جلوگیری از استفاده بیش از حد از ساختارها یا کلمات کلیدی تعریف میکنید. با گذشت زمان، معیارهای اصلی شما تثبیت میشوند و میتوانید پیشرفتها را پیگیری کنید.
این فرآیند میتواند از متخصصانی که میدانند در حوزه برنامه شما چه چیزی خوب به نظر میرسد و میتوانند حالتهای ظریف شکست را تشخیص دهند، بهرهمند شود. به عنوان مثال، اگر در حال توسعه یک دستیار نویسندگی هستید، با یک تولیدکننده محتوا یا ویراستار همکاری کنید تا مطمئن شوید ارزیابی شما با جهانبینی آنها همسو است.
داوران خود را انتخاب کنید
معیارهای ارزیابی مختلف، ارزیابهای متفاوتی را میطلبند:
- بررسیهای مبتنی بر کد برای خروجیهای قطعی یا مبتنی بر قانون به خوبی کار میکنند. برای مثال، ممکن است عناوین را برای کلماتی که میخواهید از آنها اجتناب کنید، اسکن کنید، تعداد کاراکترها را بررسی کنید یا ساختار JSON را اعتبارسنجی کنید. این روشها سریع، قابل تکرار و برای عناصر رابط کاربری با خروجی ثابت، مانند دکمهها یا فیلدهای فرم، عالی هستند.
- بازخورد انسانی برای ارزیابی ویژگیهای ذهنیتر، از جمله لحن، وضوح یا مفید بودن، ضروری است. به خصوص در اوایل کار، بررسی خروجیهای مدل توسط خودتان (یا با متخصصان حوزه) امکان تکرار سریع را فراهم میکند. با این حال، این رویکرد به خوبی مقیاسپذیر نیست. پس از راهاندازی برنامه، میتوانید سیگنالهای درون برنامهای مانند امتیاز ستارهای را نیز جمعآوری کنید، اما این سیگنالها معمولاً نویز دارند و فاقد ظرافت لازم برای بهینهسازی دقیق هستند.
- LLM به عنوان قاضی، با استفاده از یک مدل هوش مصنوعی دیگر برای امتیازدهی یا نقد خروجیها، روشی مقیاسپذیر برای ارزیابی معیارهای ذهنی ارائه میدهد. این روش سریعتر از بررسی توسط انسان است، اما بدون نقص هم نیست: در یک پیادهسازی ساده، میتواند سوگیریها و شکافهای دانش مدل را تداوم بخشیده و حتی تقویت کند.
کیفیت را بر کمیت اولویت دهید. در یادگیری ماشین کلاسیک و هوش مصنوعی پیشبینیکننده، حاشیهنویسی دادهها از طریق جمعسپاری یک روش رایج است. برای هوش مصنوعی مولد، حاشیهنویسهای جمعسپاریشده اغلب فاقد زمینه دامنه هستند. ارزیابی با کیفیت بالا و غنی از زمینه، بیش از مقیاس اهمیت دارد.
ارزیابی و بهینهسازی
هر چه سریعتر بتوانید درخواستهای خود را آزمایش و اصلاح کنید، زودتر به چیزی میرسید که با انتظارات کاربر همسو باشد. شما باید به بهینهسازی مداوم عادت کنید. یک بهبود را امتحان کنید، ارزیابی کنید و چیز دیگری را امتحان کنید.
پس از تولید، به مشاهده و ارزیابی رفتار کاربران و سیستم هوش مصنوعی خود ادامه دهید. سپس، این دادهها را تجزیه و تحلیل کرده و به مراحل بهینهسازی تبدیل کنید.
خودکارسازی فرآیند ارزیابی شما
برای کاهش اصطکاک در تلاشهای بهینهسازی خود، به زیرساخت عملیاتی نیاز دارید که ارزیابی را خودکار کند، تغییرات را ردیابی کند و توسعه را به تولید متصل کند. این معمولاً به عنوان LLMOps شناخته میشود. در حالی که پلتفرمهایی وجود دارند که میتوانند به اتوماسیون کمک کنند، شما باید قبل از تعهد به یک راهحل شخص ثالث، گردش کار ایدهآل خود را طراحی کنید.
در اینجا چند مؤلفه کلیدی که باید در نظر گرفته شوند عبارتند از:
- نسخهبندی : اعلانها، معیارهای ارزیابی و ورودیهای آزمایشی را در کنترل نسخه ذخیره کنید. برای اطمینان از تکرارپذیری و پاک کردن تاریخچه تغییرات، با آنها به عنوان کد رفتار کنید.
- ارزیابیهای دستهای خودکار : از گردشهای کاری (مانند GitHub Actions) برای اجرای ارزیابیها در هر بهروزرسانی سریع و ایجاد گزارشهای مقایسهای استفاده کنید.
- CI/CD برای اعلانها : استقرار دروازه با بررسیهای خودکار، مانند آزمونهای قطعی، نمرات LLM به عنوان داور یا گاردریلها، و ادغام بلوکها در هنگام افت کیفیت.
- ثبت وقایع تولید و مشاهدهپذیری : ورودیها، خروجیها، خطاها، تأخیر و میزان استفاده از توکن را ثبت کنید. بر انحراف، الگوهای غیرمنتظره یا افزایش ناگهانی خطاها نظارت کنید.
- دریافت بازخورد : سیگنالهای کاربر (نظرات مثبت، بازنویسیها، رها کردن) را جمعآوری کنید و مشکلات تکراری را به موارد آزمایشی جدید تبدیل کنید.
- ردیابی آزمایش : نسخههای آزمایشی، پیکربندیهای مدل و نتایج ارزیابی را ردیابی کنید.
با تغییرات کوچک و هدفمند تکرار کنید
اصلاح درخواست معمولاً با بهبود زبان درخواست شما آغاز میشود. این میتواند به معنای خاصتر کردن دستورالعملها، روشن کردن منظور یا رفع ابهامات باشد.
مراقب باشید که بیش از حد برازش ندهید. یک اشتباه رایج، اضافه کردن قوانین بیش از حد محدود به مسائل مدل اصلاحی است. برای مثال، اگر تولیدکننده عنوان شما به تولید عناوینی که با راهنمای قطعی شروع میشوند ادامه میدهد، ممکن است وسوسه شوید که صریحاً این عبارت را ممنوع کنید. در عوض، مسئله را خلاصه کنید و دستورالعمل سطح بالاتر را تنظیم کنید. این میتواند به این معنی باشد که شما بر اصالت، تنوع یا یک سبک ویرایشی خاص تأکید میکنید، بنابراین مدل ترجیح اساسی را به جای یک استثنای واحد یاد میگیرد.
مسیر دیگر، آزمایش تکنیکهای انگیزشی بیشتر و ترکیب این تلاشها است. وقتی تکنیکی را انتخاب میکنید، از خود بپرسید: آیا این وظیفه از طریق قیاس (چند مرحلهای)، استدلال گام به گام (زنجیره فکری) یا پالایش تکراری (خوداندیشی) بهتر حل میشود؟
وقتی سیستم شما به مرحله تولید میرسد، چرخ لنگر EDD شما نباید کند شود. در صورت وقوع هرگونه اتفاق، باید سرعت بگیرد. اگر سیستم شما ورودی کاربر را پردازش و ثبت میکند، این ورودیها باید به ارزشمندترین منبع بینش شما تبدیل شوند. الگوهای تکرارشونده را به مجموعه ارزیابی خود اضافه کنید و به طور مداوم بهترین مراحل بهینهسازی بعدی را شناسایی و پیادهسازی کنید.
نکات مهم شما
توسعه سریع مبتنی بر ارزیابی، روشی ساختارمند برای پیمایش عدم قطعیت هوش مصنوعی در اختیار شما قرار میدهد. با تعریف واضح مشکل، ایجاد یک سیستم ارزیابی متناسب و تکرار از طریق بهبودهای کوچک و هدفمند، یک حلقه بازخورد ایجاد میکنید که به طور پیوسته خروجیهای مدل را بهبود میبخشد.
منابع
اگر میخواهید LLM را به عنوان قاضی اجرا کنید، در اینجا چند کتاب پیشنهادی برای مطالعه ارائه شده است:
- قابلیت LLM را با خلاصهسازی مقایسه کنید .
- راهنمای هامل حسین برای استفاده از مدرک کارشناسی ارشد حقوق به عنوان قاضی را بخوانید.
- مقاله را بخوانید: بررسی در مورد LLM به عنوان قاضی .
اگر به بهبود بیشتر اعلانهای خود علاقهمند هستید، درباره توسعه مبتنی بر زمینه بیشتر بخوانید. این کار بهتر است توسط یک مهندس یادگیری ماشین انجام شود.
درک خود را بررسی کنید
هدف اصلی توسعه مبتنی بر ارزیابی چیست؟
چرا از مدلهای بزرگتر برای ارزیابی یک سیستم سمت کلاینت استفاده کنیم؟
یک مشکل بالقوه در استفاده از LLM به عنوان قاضی برای ارزیابی چیست؟
کدام مؤلفه بخشی از یک خط لوله ارزیابی خودکار پیشنهادی است؟
هنگام انتخاب داوران برای سیستم ارزیابی خود، محدودیت اصلی استفاده از بازخورد انسانی چیست؟