اشکال زدایی و تحلیل علت ریشه ای

سود:

• امکان کاهش یک باگ به کوچکترین نمونه قابل تکرار و انتقال آن به هوش مصنوعی با اثبات کامل
• امکان آزمون فرضیه های مبتنی بر شواهد با ارزان ترین کنترل و یافتن علت اصلی
• توانایی رفع علت اصلی و ایمن سازی آن با تست رگرسیون به جای اصلاح علائم

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

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

چرا شواهد همه چیز است؟

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

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

نکته: قبل از انتقال یک اشکال به هوش مصنوعی، آن را به کوچکترین نمونه قابل تکرار کاهش دهید. کوچکترین کد و ورودی که باعث ایجاد خطا می شود کارها را هم برای شما و هم برای مدل بسیار آسان تر می کند. اغلب در طول این کاهش، علت را خودتان پیدا می کنید.

گام به گام: جریان تحلیل علت ریشه ای

1. علامت را روشن کنید. "چه خبر است، انتظار داشتی چه اتفاقی بیفتد؟" این دو را در یک جمله بنویس.
2. شواهد جمع آوری کنید. پیام خطای کامل، ردیابی پشته، خطوط گزارش مربوطه، ورودی راه‌اندازی، اطلاعات نسخه.
3. فرضیه ایجاد شود. از هوش مصنوعی "3 علت احتمالی که این علامت را توضیح می دهد و چگونه برای هر کدام آزمایش کنم؟" بپرسید
4. ابتدا ارزان ترین فرضیه را آزمایش کنید. یک گزارش اضافه کنید، یک مقدار چاپ کنید، یک آزمایش اجرا کنید. آیا شواهد فرضیه را تایید می کند؟
5. علت اصلی را برطرف کنید، نه علامت را. به جای خاموش کردن علائم با یک پچ، به علت اصلی رسیدگی کنید.
6. اعتبارسنجی و اضافه کردن تست رگرسیون. مشاهده خطا ناپدید می شود. سپس تستی بنویسید که آن خطا را بگیرد تا برنگردد.

سه کیف کوچک

مورد 1 - ردیابی پشته به فایل صحیح منتهی شد. یک برنامه در مورد درخواست های خاص خطای 500 را برمی گرداند. توسعه دهنده ردیابی پشته کامل و درخواست راه اندازی را به هوش مصنوعی داده است. مدل فرض می کند که خطا ناشی از مقدار None در لایه تجزیه تاریخ است. توسعه‌دهنده گزارشی را به آن خط اضافه کرد، آن را تأیید کرد و آن را در 15 دقیقه حل کرد. 2 ساعت روز قبل با آزمایش های اثبات نشده تلف شد.

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

مورد 3 - خطای پوسته پوسته کشف شد. آزمایشی وجود داشت که گاهی اوقات شکست می خورد. به هوش مصنوعی کد آزمایش، پیام شکست و اطلاعات "گاهی می گذرد، گاهی اوقات با شکست مواجه می شود" داده شده است. این مدل وابستگی زمان/سفارش مشترک آزمون‌ها را نشان می‌دهد. بررسی تأیید کرد که آزمایش بر اساس زمان محلی سیستم است. هنگامی که ساعت ثابت شد (مسخره)، آزمایش پایدار شد.

چهار قالب قابل کپی

تولید فرضیه مبتنی بر شواهد:

من در حال رفع اشکال هستم. شواهد زیر.- رفتار مورد انتظار: {{منتظره}}- رفتار مشاهده شده: {{مشاهده}}- پیام خطا / ردیابی پشته: {{ردیابی}}- ورودی راه‌اندازی: {{ورودی}}- محیط/نسخه: {{نسخه}}سه علت ریشه‌ای که به احتمال زیاد این علامت را توضیح می‌دهند را فهرست کنید. برای هر کدام: چگونه تست کنم (ارزانترین چک) و اگر درست است چگونه آن را برطرف کنم. اگر شواهد کافی نیست، به من بگویید به چه اطلاعات اضافی نیاز دارید.

تفسیر ردیابی پشته:

این ردیابی پشته را بخوانید. تشخیص دهید که خطا احتمالاً از کدام خط شروع می شود (ریشه) و کدام خطوط فقط ادامه زنجیره هستند. 1-2 مکان را برای نگاه اول پیشنهاد دهید. کد مرتبط:{{code}}Trace:{{trace}}

حداقل تفریق مجدد:

کد زیر یک خطا ایجاد می کند. آن را به کوچکترین نمونه کاهش دهید که همچنان خطا را راه‌اندازی می‌کند اما هر چیز غیرضروری را کنار می‌گذارد. فرض نکنید که هر قطعه ای که حذف می کنید روی خطا تأثیر نمی گذارد، بلکه یک یادداشت اضافه کنید که "اگر هنگام حذف این خطا ناپدید شد، به همین دلیل است".{{code}}

اعتبارسنجی پس از تصحیح و آزمون رگرسیون:

فرض کنید علت اصلی {{علت}} است و من راه حل زیر را انجام می دهم: {{رفع}}.1) آیا این اصلاح واقعاً علائم را برطرف می کند، آیا عوارض جانبی دارد؟ 2) یک تست رگرسیون بنویسید که در آینده این اشکال را پیدا کند.

اعلان ضعیف / اعلان قوی

ضعیف: "کد کار نمی کند، چرا؟"

Strong: "Node 20 / Express. POST /orders 500 را برمی گرداند زمانی که آیتم ها یک رشته خالی در بدنه هستند؛ باید 400 برگردانده می شد. ردیابی پشته: TypeError: نمی توان ویژگی های تعریف نشده را خواند (خواندن '0') - ردیابی کامل و کنترل کننده مرتبط پیوست شده است. 3 کد symp محتمل ترین عامل هر کدام را برای این آزمایش توضیح دهید.

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

گام

سهم هوش مصنوعی

کنترل شما

جمع آوری شواهد

آنچه مدرک مورد نیاز است، یادآوری می کند

واقعا شواهد جمع آوری می کند

ایجاد فرضیه

دلایل احتمالی را فهرست کنید

با زمینه اولویت بندی می کند

آزمون فرضیه

روش تست را توصیه می کند

عمل می کند و شخصاً مشاهده می کند

تصحیح

پچ توصیه می کند

آیا علت اصلی را حل می کند؟ این درست است.

رگرسیون

تست می نویسد

بررسی می کند که تست خراب است

حل علت اصلی، نه علامت

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

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

اشتباهات رایج

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

به طور خلاصه

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

وظیفه کاربردی

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

چک لیست

• [ ] قبل از انتقال آن به هوش مصنوعی خطا را به کوچکترین نمونه قابل تکرار کاهش می دهم.
• [ ] من پیام خطای کامل، ردیابی پشته، ورودی و رفتار مورد انتظار را به دستور اضافه می‌کنم.
• [ ] من با ارزان ترین مورد قابل کنترل شروع می کنم، بدون اینکه در یک فرضیه قفل شده باشم.
• [ ] من تأیید می کنم که به جای رفع علائم، علت اصلی را برطرف کرده ام.
• [ ] مشاهده می کنم که این اصلاح در واقع اشکال را برطرف می کند.
• [ ] من برای هر اشکال حل شده یک تست رگرسیون اضافه می کنم.