Отклањање грешака и анализа пада са вештачком интелигенцијом

Добици:

• Способност да се брзо сузи могући основни узроци давањем записа о паду (трагова стека) вештачкој интелигенцији са релевантним кодом и контекстом сценарија
• Способност трајног отклањања основног узрока, а не валидације дијагнозе АИ као хипотезе у коду и тестирања и утишавања симптома
• Заштита приватности током отклањања грешака маскирањем личних података у записима о рушењу и евиденцијама

Свака апликација даје грешке; Оно што разликује доброг програмера је колико брзо проналази и исправља грешке. Отклањање грешака на мобилном уређају — проналажење и отклањање извора проблема — је посебно тешко јер се грешка јавља на уређају корисника, у окружењу које не можете да видите. Већину времена, све што имате је евиденција пада (дневник пада / праћење стека — технички преглед где је апликација отишла када се срушила). АИ је изузетно моћна у читању ових загонетних записа, набрајању могућих узрока и предлагању решења. У овој јединици ћемо научити како да користимо вештачку интелигенцију као „детектив за грешке“, али вам остављамо одговорност да потврдите коначну дијагнозу и поправите.

Читање дневника пада: Где АИ сија најјаче

Дневник пада је дугачак и застрашујући текст; неискусни програмер неће знати где да тражи. АИ анализира овај текст за неколико секунди: у којој линији се срушио, који изузетак је избачен, који је могући разлог. Уобичајене грешке на мобилном уређају су очигледне и АИ их брзо препознаје: НуллПоинтерЕкцептион (покушава приступити нултој вредности), ИндекОутОфБоундсЕкцептион (приступ непостојећем елементу листе) на Андроиду, ЕКСЦ_БАД_АЦЦЕСС (приступ ослобођеној меморији) на иОС-у, неочекивано пронађена нил (присилна нула).

Најчешћи типови отказивања мобилних уређаја и њихови типични узроци су следећи:

Грешка (изузетак)

Платформа

типичан узрок

НуллПоинтерЕкцептион

Андроид

Приступ нултој вредности

ИндекОутОфБоундсЕкцептион

Андроид

Приступ непостојећем елементу листе

неочекивано пронађена нула

иОС

Присилно одмотавање нула опционо (!)

ЕКСЦ_БАД_АЦЦЕСС

иОС

Приступ ослобођеној меморији

АНР/замрзавање

Андроид

Дуга/тешка обрада на главној нити

Корак по корак ток отклањања грешака:

1. Сакупи запис. Саставите евиденцију о паду, поруку о грешци и кораке да је репродукујете ако је могуће.
2. Дајте АИ контекст. Реци ми не само грешку, већ и релевантни део кода и шта ради.
3. Питајте за могуће узроке. „Реците ми 3 највероватнија узрока и како да проверим сваки од њих.“
4. Верифи. Потврдите предложени разлог у коду и тестирању; Немојте то поправљати погађањем.
5. Поправите и тестирајте поново. Проверите да ли је грешка заиста нестала и да се не генеришу нове грешке.

Савет: Када дате евиденцију о паду АИ, укључите и релевантни исечак кода. Само са праћењем стека АИ прави опште предвиђање; Када видите код, вероватноћа проналажења тачне линије и правог узрока се увелико повећава. Контекст одређује квалитет дијагнозе.

Замка личних података

Евиденције и евиденције пада често садрже корисничке податке: е-пошту, кориснички ИД, локацију, чак и садржај обрасца. Лепљење овог записа у вештачку интелигенцију као што јесте представља цурење личних података трећој страни и представља кршење КВКК / ГДПР. Очистите (маскирајте) личне области пре слања снимка. Такође, пазите да не уписујете личне податке у дневнике ваше апликације од почетка; Добар дневник описује проблем, али не открива идентитет.

Опрез: Исправка коју је предложила АИ може „утишати грешку“, али можда неће решити основни узрок. На пример, умотавање НуллПоинтерЕкцептион са нулл провером зауставиће рушење, али ако не схватите зашто је вредност нула, стварна логичка грешка ће се наставити. Лечите болест, а не симптом.

Анализа узрока

Циљ професионалног отклањања грешака није да утиша грешку, већ да пронађе основни узрок. Питао сам АИ „зашто би ово могло бити нулто, где се могло изгубити у току података?“ питајући: "Како да ућуткам ово?" То је много вредније од тражења. Једном када се пронађе основни узрок, десетине варијација исте грешке се решавају одједном. АИ је добар у овом ланчаном резоновању: пратите податке од улаза до излаза и замолите га да размисли о томе где се квари.

три мини кофера

Случај 1 — 2 сата рада за 10 минута. Програмер је провео 2 сата тражећи грешку која се срушила само на одређеном Самсунг моделу. Дао дневник пада (чишћење личних области) АИ; ИЗ је рекао да грешка указује на преливање меморије које се јавља са другачијом резолуцијом камере тог уређаја. Уз траг, разлог је пронађен за 10 минута. АИ је убрзао потрагу, човек је потврдио решење.

Случај 2 — Утишана грешка се вратила. Један тим је утишао понављајући пад користећи предлог вештачке интелигенције да покуша да га ухвати. Рушење је престало, али су корисници почели да се жале да се „подаци не чувају“; јер је прави проблем (веза са базом података) још увек постојао, управо је постао невидљив. Када је пронађен основни узрок, отклоњени су и пад и губитак података. Поука: ћутање није решење.

Случај 3 — Подаци су процурили у дневник. Ревизија је открила да су пуна имена и бројеви телефона корисника уписани у евиденцију пада апликације. Програмери су рутински лепили ове евиденције у АИ и исправљали грешке; Дакле, лични подаци излазе месецима. Дневници су маскирани и процес је исправљен. Поука: поверљивост важи чак и када се отклањају грешке.

Слаби промпт / Јаки промпт

Лош упит: „Зашто се јавља ова грешка? [праћење стека]“

Снажан упит: „Ово рушење се дешава у мојој Андроид апликацији. Контекст:- Док ради: корисник додаје у корпу из детаља о производу- Само на неким уређајима, модели са мало РАМ-а- Повезани код: [ВиевМодел и део спремишта]- Евиденција отказивања (лични подаци обрисани): [праћење стека]Наведите 3 највероватније основна узрока. прећуткивање). Изнесите своју претпоставку где нисте сигурни“.

Шаблони који се могу копирати

Шаблон анализе отказивања: „Анализирајте следећи пад. Контекст: [шта радите, који уређај/верзија]. Релевантни код: [код]. Евиденција отказивања (лични подаци обрисани): [траг]. Наведите 3 највероватније основна узрока и верификацију + трајно решење за сваки. Такође означите заобилазна решења која утишају симптом.“

Шаблон основног узрока: "Ова вредност долази [нулл/фалсе] неочекивано. Пратите ток података од улаза до ове тачке: где би могао бити изгубљен или оштећен? Реците ми где да проверим у свакој фази. [шифра]"

Шаблон за читање дневника: „Протумачите овај излаз дневника: који су се догађаји дешавали редом, где је абнормалност, који је био последњи здрави корак пре грешке? [лог — лични подаци обрисани]“

Шаблон репродукције: „Које кораке, стања уређаја и податке треба да покушам да поуздано репродукујем ову грешку? Наведите услове који би могли да изазову грешку по редоследу вероватноће. [опис]“

Уобичајене грешке

• Давање праћења стека без контекста. Без релевантног кода и сценарија, АИ прави општа предвиђања.
• Лепљење личних података у АИ заједно са евиденцијама. Кршење поверљивости; прво маска.
• Утишајте симптом. Сакривање пада помоћу три-цатцх оставља основни проблем и ствара нове проблеме.
• Примена првог предлога без његове провере. Дијагноза АИ је хипотеза; Потврдите у коду.
• Покушавам да га репродукујем у емулатору. Неке грешке се појављују само на стварном уређају/стању.
• Не понавља се након корекције. Поправка је можда покварила нешто друго; Проверите регресију.

Укратко

Једна од области у којој се АИ истиче је читање дневника пада и разврставање могућих узрока; Квалитет дијагнозе се значајно побољшава када се да контекст. Али коначна дијагноза и корекција припадају човеку: сугестија вештачке интелигенције је хипотеза, верификована у коду и тестирању. Циљ није да се утиша симптом, већ да се реши основни узрок; Утишана грешка се обично враћа у другом облику. Дневници пада могу садржати личне податке; Замаскирајте га пре него што га дате АИ и не пишите личне податке у своје дневнике од почетка.

Задатак апликације

Узмите евиденцију пада коју имате (или узорак који генеришете из АИ), маскирајте све личне/различите податке у њему и дајте га АИ помоћу „шаблона анализе пада“. Разликујте који од основних узрока АИ листе су стварне поправке, а које само ућуткају. Примените трајну исправку коју сте изабрали и проверите да ли је грешка нестала и да се не појављују нови проблеми.

контролна листа

• [ ] Дао сам дневник пада са релевантним кодом и контекстом сценарија
• [ ] Прикрио сам личне/различите податке у евиденцији
• [ ] Тражио сам од вештачке интелигенције основни узрок и трајно решење, а не утишавање
• [ ] Проверио сам дијагнозу у коду и тестирању, нисам је применио слепо
• [ ] Након поправке, тестирао сам да је грешка нестала и да нема регресије
• [ ] Проверио сам да моја апликација не уписује личне податке у своје евиденције