Печалби:
- Възможност за намаляване на грешка до най-малкия възпроизводим екземпляр и преместването й в AI с пълно доказателство
- Възможност за тестване на основани на доказателства хипотези с най-евтиния контрол и намиране на първопричината
- Възможност за разрешаване на първопричината и нейното обезопасяване с регресионен тест, вместо да коригира симптома
Отстраняването на грешки е процесът на установяване на причините, поради които софтуерът се държи неочаквано и коригирането му. Това е работата, в която разработчикът прекарва най-много време и се уморява най-много; Защото най-често грешката не е там, където се появява, а е скрита няколко крачки назад. AI е мощен мислещ партньор, който ускорява това изследване – но само ако му дадете правилните доказателства. Отстраняването на грешки без доказателства е областта, в която AI произвежда най-много халюцинации.
В този модул ние установяваме дисциплиниран поток от генериране на грешката до достигане до първопричината: изясняване на симптома, събиране на доказателства (съобщение за грешка, проследяване на стека, регистрационен файл, запис), генериране на хипотеза, тестване на хипотезата и валидиране на корекцията. AI помага на всяка стъпка; но "поправеното" решение се взема, като се види, че грешката всъщност е изчезнала.
Защо доказателствата са всичко?
LLM не вижда грешката по начина, по който вие го правите; Той знае само това, което му казвате. Изречение като „Приложението се срива“ не дава на модела почти никаква информация и моделът запълва празнината с прогноза – тоест халюцинация. На свой ред, пълното съобщение за грешка, проследяване на стека — разбивка на извикванията на функцията, чрез които е възникнала грешката, входът, който е задействал грешката, и какво се очаква и т.н. Като се има предвид наблюдаваното поведение, моделът може да класира истинските вероятности.
При отстраняване на грешки мислете за AI като за помощник на детектив: колкото повече доказателства представяте, толкова по-точна е хипотезата, която генерира. Ако няма доказателства, асистентът само ще предполага и може да ви поведе по грешната следа.
Съвет: Преди да пренесете грешка към AI, намалете я до най-малкия възпроизводим пример. Най-малкият код и вход, който задейства грешката, прави нещата радикално по-лесни както за вас, така и за модела; най-често при тази редукция вие сами намирате причината.
Стъпка по стъпка: Процес на анализ на първопричината
- Изяснете симптома. – Какво става, какво очакваше да се случи? Напишете двете в едно изречение.
- Съберете доказателства. Пълно съобщение за грешка, проследяване на стека, съответни редове в журнала, задействащ запис, информация за версията.
- Генерирайте хипотезата. От AI „3 възможни причини, които обясняват този симптом и как да тествам за всяка от тях?“ попитайте.
- Тествайте първо най-евтината хипотеза. Добавете журнал, отпечатайте стойност, изпълнете тест. Доказателствата потвърждават ли хипотезата?
- Коригирайте първопричината, а не симптома. Вместо да заглушите симптома с лепенка, обърнете се към първопричината.
- Валидирайте и добавете регресионно тестване. Вижте грешката да изчезне; След това напишете тест, който ще хване тази грешка, за да не се появи отново.
Три мини калъфа
Случай 1 — Проследяването на стека доведе до правилния файл. Приложение връщаше грешка 500 при определени заявки. Разработчикът даде пълното проследяване на стека и заявката за задействане на AI; Моделът предположи, че грешката е причинена от стойност None в слой за анализ на дата. Разработчикът добави дневник към този ред, провери го и го реши за 15 минути; 2 часа бяха пропилени предния ден с недоказани опити.
Случай 2 — Халюцинациите доведоха до погрешен път. Друг разработчик просто написа „връзката с базата данни прекъсва“. Изкуственият интелект обвини настройка на пула за връзка без никакви доказателства; Разработчикът прекара 40 минути в бърникане с тази настройка. Истинската причина беше таймаут от страна на мрежата и беше разкрита само при преглед на регистрационните файлове. Урок: хипотеза, взета без доказателства, е само вероятна, а не надеждна.
Случай 3 — Уловена нестабилна грешка. Имаше тест, който понякога се проваляше. На AI беше даден тестовият код, съобщението за грешка и информацията „понякога преминава, понякога се проваля“; моделът посочи споделена зависимост от време/ред на тестовете. Прегледът потвърди, че тестът е базиран на местното време на системата. След като часовникът беше фиксиран (подиграван), тестът стана стабилен.
Четири копируеми шаблона
Генериране на основани на доказателства хипотези:
Отстранявам грешка. Доказателство по-долу.- Очаквано поведение: {{expected}}- Наблюдавано поведение: {{observed}}- Съобщение за грешка/проследяване на стека: {{trace}}- Задействащ вход: {{input}}- Среда/версия: {{version}}Избройте 3-те НАЙ-ВЕРОЯТНИ основни причини, които обясняват този симптом. За всеки: как да тествам (най-евтината проверка) и как да го поправя, ако е вярно. Ако доказателствата са недостатъчни, кажете ми от каква допълнителна информация се нуждаете.
Интерпретиране на проследяването на стека:
Прочетете това проследяване на стека. Разграничете от кой ред ВЕРОЯТНО започва грешката (корена) и кои редове са просто продължение на веригата. Предложете 1-2 места, които първо да разгледате. Свързан код:{{code}}Проследяване:{{trace}}
Минимално репро изваждане:
Кодът по-долу дава грешка. Намалете го до НАЙ-МАЛКОТО копие, което все още задейства грешката, но изхвърля всичко ненужно. Не приемайте, че всяка част, която премахнете, не влияе на грешката, но добавете бележка, казваща „ако грешката изчезне, когато премахнете това, това е причината“.{{code}}
Валидиране след корекция и регресионно тестване:
Да предположим, че основната причина е {{cause}} и правя следната корекция: {{fix}}.1) Тази корекция действително ли коригира симптома, ще има ли странични ефекти?2) Напишете регресионен тест, който ще хване тази грешка в бъдеще.
Слаба подкана / Силна подкана
Слаб: "Кодът не работи, защо?"
Силно: "Възел 20 / Express. POST /orders връща 500, когато елементите са празен низ в тялото; трябваше да върне 400. Проследяване на стека: TypeError: Не може да прочете свойствата на undefined (четене '0') — прикачено е пълното проследяване и свързания манипулатор. Дайте ми 3-те най-вероятни причини, които обясняват този симптом и как да тествам всеки. [trace + code]"
Мощна версия; Той дава средата, крайната точка, въвеждането на тригера, точния тип грешка и очакваното поведение. Моделът вече не може да прави прогнози, а анализи.
стъпка
Приносът на AI
вашият контрол
събиране на доказателства
Какви доказателства са необходими, напомня
Наистина събира доказателства
генериране на хипотези
Избройте възможните причини
Приоритизира с контекста
проверка на хипотези
Препоръчва метод за тестване
Оперира и наблюдава лично
корекция
кръпката препоръчва
Решава ли първопричината? вярно е
регресия
пише тест
Проверява дали тестът е повреден
Разрешаване на първопричината, а не на симптома
През повечето време изкуственият интелект ще предложи корекция, която бързо заглушава симптома: добавете опит/улов, поставете нулева проверка, преглъщайте грешката. Това понякога е вярно, често опасно; защото първоначалната причина остава на мястото си и избухва отново от някъде другаде. При всяка корекция се запитайте: „Това коригира ли причината за грешката или я прави невидима?“ След като откриете първопричината, поправката обикновено е по-малка, по-здрава и постоянна.
Внимание: Тихо поглъщане на изключение (празен улов) не разрешава грешката; то само прикрива и прави бъдеща диагноза невъзможна. Ако изкуственият интелект предлага такова „решение“, не го приемайте, без да поставите под въпрос първопричината.
Често срещани грешки
- Задаване на въпроси без доказателства. Двусмислените изречения тласкат модела към халюцинация; Дайте пълна грешка, проследяване и въвеждане.
- Заключване на първата хипотеза. Първото предложение на AI може да не е най-вероятно; Започнете с най-евтината контролируема хипотеза.
- Поправяне на симптома и липса на първопричината. Заглушената грешка се връща.
- Затваряне на корекцията без проверка. Вижте в състояние, подобно на производствено, че грешката действително изчезва.
- Без писане на регресионни тестове. Ако не се добавят тестове, същата грешка тихо ще се върне в по-късните версии.
В обобщение
При отстраняване на грешки силата на AI е право пропорционална на доказателствата, които му давате: без пълното съобщение за грешка, проследяване на стека, задействащ вход и очаквано поведение, моделът просто спекулира. Дисциплиниран поток - изясняване на симптома, събиране на доказателства, генериране на хипотеза, тестване с най-евтиния контрол, отстраняване на основната причина, проверка и добавяне на регресионно тестване - затваря грешката както бързо, така и за постоянно. AI е генератор на хипотези; Вие сте този, който решава, че грешката наистина е разрешена.
Задача за приложение
Изберете истинска грешка, която сте срещали наскоро (или възпроизведете тестова грешка). Първо направете стъпката "минимално възпроизвеждане"; Премахнете най-малкия код и вход, който задейства грешката. След това вземете 3 възможни причини и метода за тестване от AI с шаблона „генериране на основана на доказателства хипотеза“. Тествайте сами най-евтината хипотеза, намерете основната причина, поправете я и накрая напишете регресионен тест, който ще хване тази грешка в бъдеще и ще потвърди, че тестът действително е повреден.
контролен списък
- [ ] Намалявам грешката до най-малката възпроизводима проба, преди да я преместя в AI.
- [ ] Добавям пълното съобщение за грешка, проследяване на стека, въвеждане и очаквано поведение към подканата.
- [ ] Започвам с най-евтиния контролируем, без да се заключвам в една хипотеза.
- [ ] Потвърждавам, че съм разрешил основната причина, вместо да коригирам симптома.
- [ ] Забелязвам, че корекцията всъщност коригира грешката.
- [] Добавям регресионен тест за всяка разрешена грешка.