Прибуток:
- Можливість зменшити помилку до найменшого відтворюваного екземпляра та перемістити її до ШІ з повним доказом
- Здатність перевіряти засновані на доказах гіпотези з найдешевшим контролем і знаходити першопричину
- Можливість вирішити першопричину та захистити її за допомогою тесту регресії, а не виправляти симптом
Налагодження — це процес з’ясування причини неочікуваної поведінки програмного забезпечення та її усунення. Це робота, на якій розробник витрачає найбільше часу і найбільше втомлюється; Тому що найчастіше помилка не там, де вона з’являється, а ховається за кілька кроків позаду. Штучний інтелект є потужним розумним партнером, який прискорює ці дослідження, але лише якщо ви надасте йому правильні докази. Налагодження без доказів — це сфера, де ШІ створює найбільше галюцинацій.
У цьому підрозділі ми встановлюємо дисциплінований потік від створення помилки до досягнення її першопричини: з’ясування симптому, збір доказів (повідомлення про помилку, трасування стека, журнал, запис), генерування гіпотези, перевірка гіпотези та перевірка виправлення. AI допомагає на кожному кроці; але «виправлене» рішення приймається, коли бачить, що помилка фактично зникла.
Чому докази - це все?
LLM не бачить помилки так, як ви бачите; Він знає лише те, що ти йому скажеш. Речення на кшталт «Програма виходить з ладу» не дає моделі майже жодної інформації, а модель заповнює прогалину передбаченням — тобто галюцинацією. У свою чергу, повне повідомлення про помилку, трасування стека — розбивка того, через які виклики функції сталася помилка, вхідні дані, які викликали помилку, і що очікувалося тощо. Враховуючи спостережувану поведінку, модель може ранжувати справжні ймовірності.
Під час налагодження сприймайте ШІ як помічника детектива: чим більше доказів ви надасте, тим точнішу гіпотезу він генерує. Якщо доказів немає, помічник буде тільки здогадуватися і може навести вас на хибний слід.
Порада: перш ніж переносити помилку на AI, зведіть її до найменшого відтворюваного прикладу. Найменший код і вхідні дані, які викликають помилку, значно полегшують роботу як для вас, так і для моделі; найчастіше під час цього скорочення ви самі знаходите причину.
Крок за кроком: хід аналізу першопричини
- Уточніть симптом. «Що відбувається, чого ви очікували?» Запишіть два одним реченням.
- Зберіть докази. Повне повідомлення про помилку, трасування стека, відповідні рядки журналу, ініціюючий запис, інформація про версію.
- Сформулюйте гіпотезу. Від AI «3 можливі причини, які пояснюють цей симптом, і як перевірити кожну з них?» запитати.
- Спочатку перевірте найдешевшу гіпотезу. Додати журнал, надрукувати значення, запустити тест. Чи підтверджують докази гіпотезу?
- Усуньте першопричину, а не симптом. Замість того, щоб заглушити симптом за допомогою пластиру, усуньте першопричину.
- Перевірте та додайте регресійне тестування. Подивіться, як помилка зникне; Потім напишіть тест, який виловить цю помилку, щоб вона не поверталася.
Три міні-чохли
Випадок 1. Трасування стека привело до правильного файлу. Програма повертала помилку 500 на певні запити. Розробник надав ШІ запит на повну трасування стека та ініціювання; Модель припустила, що помилка була спричинена значенням None у шарі аналізу дати. Розробник додав журнал до цього рядка, перевірив його та вирішив за 15 хвилин; 2 години були витрачені напередодні на безпідставні досліди.
Випадок 2 — Галюцинація ввела на хибний слід. Інший розробник просто написав «з’єднання з базою даних розривається». AI звинуватив налаштування пулу з’єднань без жодних доказів; Розробник 40 хвилин возився з цим налаштуванням. Справжньою причиною був тайм-аут на стороні мережі, і її було виявлено лише під час перегляду журналів. Урок: гіпотеза, висунута без доказів, лише ймовірна, а не надійна.
Випадок 3 — Виявлено нестабільну помилку. Був іспит, який іноді проваджувався. ШІ отримав тестовий код, повідомлення про помилку та інформацію «іноді він проходить, іноді — не вдається»; модель вказала на спільну залежність часу/порядку тестів. Огляд підтвердив, що тест базувався на місцевому часі системи. Після того, як годинник було виправлено (імітовано), тест став стабільним.
Чотири шаблони, які можна копіювати
Формування гіпотез на основі доказів:
Я виправляю помилку. Докази нижче.- Очікувана поведінка: {{expected}}- Спостережувана поведінка: {{observed}}- Повідомлення про помилку / трасування стека: {{trace}}- Ініціюючий вхід: {{input}}- Середовище/версія: {{version}}Перелічіть 3 НАЙЙМОВІРІШІ основні причини, які пояснюють цей симптом. Для кожного: як перевірити (найдешевша перевірка) і як це виправити, якщо це правда. Якщо доказів недостатньо, скажіть, яка додаткова інформація вам потрібна.
Інтерпретація трасування стека:
Прочитайте цей стек. Розрізняйте, з якого рядка МОЖЛИВО починається помилка (корінь), а які рядки є лише продовженням ланцюжка. Запропонуйте 1-2 місця для пошуку в першу чергу. Пов’язаний код:{{code}}Trace:{{trace}}
Мінімальне повторне віднімання:
Наведений нижче код створює помилку. Зменшіть його до НАЙМЕНШОГО екземпляра, який усе ще викликає помилку, але відкидає все непотрібне. Не припускайте, що кожен фрагмент, який ви видаляєте, не впливає на помилку, але додайте примітку «якщо помилка зникає, коли ви видаляєте це, ось чому».{{code}}
Перевірка після виправлення та регресійне тестування:
Припустимо, що основною причиною є {{причина}}, і я виправляю наступне: {{виправляю}}.1) Чи справді це виправлення усуває симптом, чи матиме побічні ефекти?2) Напишіть регресійний тест, який виявить цю помилку в майбутньому.
Слабка підказка / Сильна підказка
Слабкий: «Код не працює, чому?»
Сильно: «Вузол 20 / Express. POST /orders повертає 500, коли items є порожнім рядком у тілі; мав повернути 400. Трасування стека: TypeError: неможливо прочитати властивості undefined (читання «0») — долучено повне трасування та пов’язаний обробник. Укажіть 3 найімовірніші причини, які пояснюють цей симптом, і як перевірити кожну. [trace + code]»
Потужна версія; Він надає середовище, кінцеву точку, тригерний вхід, точний тип помилки та очікувану поведінку. Модель може робити не прогнози, а аналіз.
крок
Внесок ШІ
ваш контроль
збір доказів
Які потрібні докази, нагадує
Реально збирає докази
генерація гіпотез
Перелічіть можливі причини
Пріоритети з контекстом
перевірка гіпотези
Рекомендує метод тестування
Оперує та спостерігає особисто
корекція
патч рекомендує
Чи вирішує це першопричину? Це правда.
регресія
пише контрольну роботу
Перевіряє, чи зламався тест
Вирішуйте першопричину, а не симптом
У більшості випадків ШІ запропонує патч, який швидко заглушить симптом: додайте спробу/злов, поставте нульову перевірку, проковтніть помилку. Іноді це правда, часто небезпечно; тому що початкова причина залишається на місці і виривається знову звідкись. З кожним виправленням запитуйте себе: «Це усуває причину помилки чи робить її невидимою?» Як тільки ви знайдете першопричину, виправлення зазвичай є меншим, надійнішим і постійним.
Застереження: мовчазне ковтання винятку (пустий catch) не вирішує помилку; це лише приховує та робить неможливим майбутній діагноз. Якщо штучний інтелект пропонує таке «рішення», не приймайте його, не ставлячи під сумнів першопричину.
Поширені помилки
- Ставити питання без доказів. Двозначні речення штовхають модель у галюцинації; Надати повну помилку, трасування та введення.
- Замикаючись на першій гіпотезі. Перша пропозиція ШІ може бути не найімовірнішою; Почніть з найдешевшої контрольованої гіпотези.
- Виправляючи симптом і втрачаючи першопричину. Повертається заглушена помилка.
- Закриття виправлення без перевірки. У стані, схожому на виробництво, помилка фактично зникає.
- Не написання регресійних тестів. Якщо не додати жодних тестів, та сама помилка мовчки повернеться в наступних версіях.
Підсумовуючи
Під час налагодження потужність штучного інтелекту прямо пропорційна доказам, які ви йому надаєте: без повного повідомлення про помилку, трасування стека, вхідних даних і очікуваної поведінки модель просто спекулює. Упорядкований потік — уточнення симптомів, збір доказів, створення гіпотез, тестування з найдешевшим контролем, усунення першопричини, перевірка та додавання регресійного тестування — усуває помилку швидко й назавжди. ШІ є генератором гіпотез; Ви вирішуєте, що помилку справді вирішено.
Аплікаційне завдання
Виберіть справжню помилку, з якою ви нещодавно зіткнулися (або відтворіть тестову помилку). Спочатку виконайте крок «мінімальне відтворення»; Видаліть найменший код і введення, які викликають помилку. Потім отримайте 3 можливі причини та методи тестування від штучного інтелекту за допомогою шаблону «вироблення гіпотез на основі доказів». Самостійно перевірте найдешевшу гіпотезу, знайдіть першопричину, виправте її та, нарешті, напишіть регресійний тест, який виявить цю помилку в майбутньому та підтвердить, що тест справді зламаний.
контрольний список
- [ ] Я зменшую помилку до найменшої відтворюваної вибірки перед тим, як перенести її в AI.
- [ ] Я додаю повне повідомлення про помилку, трасування стека, введення та очікувану поведінку до підказки.
- [ ] Я починаю з найдешевшого керованого, не замикаючись на одну гіпотезу.
- [ ] Я підтверджую, що я усунув першопричину, а не виправляв симптом.
- [ ] Я бачу, що виправлення фактично усуває помилку.
- [ ] Я додаю регресійний тест для кожної вирішеної помилки.