هزینه تأیید هزینه کدگذاری واقعی هوش مصنوعی است

{“error”:”Error: Upstream error from Nvidia: ResourceExhausted: Worker local total request limit reached (33\/32) Code: 502″}
زمانی که وظایف کدنویسی را در بین مدل ها مسیریابی می کردم، یک سوال ساده می پرسیدم:
کدام مدل برای این کار به اندازه کافی قوی است؟
این سوال هنوز مفید است، اما اولین سوالی نیست که می پرسم.
سوال اول بهتر این است:
چقدر سریع می توانم خروجی را تأیید کنم؟
این روش من را از مدل های ارزان قیمت تغییر داد. من با آنها به عنوان جایگزین های ضعیف تری برای مدل کدنویسی اصلی خود رفتار نمی کنم. من با آنها به عنوان کارگران مفید برای کارهایی که مسیر تأیید کوتاه است رفتار می کنم.
سطح 1: آیا می توانم خروجی را مستقیماً بررسی کنم؟
بررسی برخی از کارها ارزان است زیرا خروجی قابل مشاهده است.
مثال ها:
- پاکسازی README
- نمونه های استفاده
- نظرات
- یادداشت های تغییرات
- اسکریپت های قالب بندی کوچک
- قالب های مسئله
اگر مدل یک پاراگراف README بد بنویسد، می توانم آن را ببینم. اگر عبارت مبهم اضافه کند، می توانم آن را حذف کنم. شکست آزار دهنده است، اما ارزان است.
اینجاست که مدل های کم هزینه مفید هستند.
سطح 2: آیا می توانم یک آزمون اجرا کنم؟
بهترین دسته بعدی کارهای قابل آزمایش است.
اگر بتوانم رفتار مورد انتظار را توصیف کنم و مجموعه آزمایشی را اجرا کنم، مایلم اولین پیش نویس را به یک مدل ارزان تر هدایت کنم.
اما سریع نیاز به مرزها دارد.
به جای:
تست هایی را برای این کمک کننده اضافه کنید.
می نوشتم:
تست هایی را برای ورودی خالی، ورودی تهی، مقادیر تکراری، پیکربندی نامعتبر، پیکربندی پیش فرض و ورودی معمولی اضافه کنید. کد زمان اجرا را تغییر ندهید.
تفاوت کوچک است، اما مدل را مجبور می کند تا در یک چارچوب تأیید کار کند.
سطح 3: آیا می توانم آن را به صورت دستی تأیید کنم؟
برخی از کارها تست خودکار ندارند، اما هنوز یک بررسی دستی واضح دارند.
مثال ها:
- قالب بندی خروجی CLI
- نمونه های پیکربندی
- یادداشت های مهاجرت خشک
- اسکریپت های تبدیل داده های کوچک
برای این موارد، از مدل می خواهم که شامل موارد زیر باشد:
- چگونه آن را اجرا کنیم
- چه ورودی استفاده کنید
- چه خروجی را باید انتظار داشت
- کدام موارد لبه را بررسی کنید
اگر مدل نتواند نحوه تأیید خروجی خود را توضیح دهد، من به پچ اعتماد ندارم.
سطح 4: آیا می تواند رفتار پنهان را تغییر دهد؟
اینجاست که سرعتم را کم می کنم.
ریفکتورهای کوچک اغلب خطرناکتر از آنچه به نظر می رسند هستند.
تفاوت ممکن است کوتاه باشد. ممکن است کد تمیزتر به نظر برسد. اما رفتار ممکن است در یک مسیر بازگشتی، یک مقدار پیشفرض، یک بررسی مجوز یا یک شاخه سازگاری تغییر کند.
من سطح ریسک را هنگامی که یک کار لمس می کند افزایش می دهم:
- بازگشتی ها
- پیش فرض ها
- مسیریابی
- مجوزها
- صورتحساب
- محدودیت های نرخ
- مهاجرت ها
- سازگاری به عقب
این خرابی ها همیشه در بررسی کد آشکار نمی شوند. برای توجه به آنها به زمینه نیاز دارید.
قانون مسیریابی فعلی من
من با هزینه تأیید مسیر می کنم:
- هزینه تأیید کم: مدل کم هزینه می تواند آن را پیش نویس کند.
- هزینه تأیید متوسط: مدل کمهزینه میتواند پیشنویس، ویرایشهای انسانی.
- هزینه تأیید بالا: مدل قوی ممکن است کمک کند، اما آزمایشات و بررسی انسانی مورد نیاز است.
این قانون مفیدتر از “کار کوچک در مقابل کار بزرگ” است.
یک کار کوچک می تواند گران باشد اگر تأیید آن سخت باشد.
نکته
مدل های کدنویسی با هوش مصنوعی کم هزینه بی فایده نیستند.
آنها زمانی مفید هستند که کار به راحتی قابل بازرسی، آزمایش آسان یا به راحتی برگشتن باشد.
بخش گران قیمت کدنویسی هوش مصنوعی همیشه تولید نیست.
اغلب، اعتماد است.



