Nyereség:
- Lehetőség a hiba csökkentésére a legkisebb reprodukálható példányra, és teljes bizonyítással áthelyezni az AI-ba
- Képes bizonyítékokon alapuló hipotézisek tesztelésére a legolcsóbb kontrollal és megtalálni a kiváltó okot
- Képes a kiváltó ok feloldására és egy regressziós teszttel történő biztosítására a tünet foltozása helyett
A hibakeresés az a folyamat, amelynek során kiderítjük, miért viselkedik váratlanul egy szoftver, és kijavítjuk azt. Ez az a munka, ahol a fejlesztő a legtöbb időt tölti, és ahol a legtöbbet elfárad; Mert a hiba legtöbbször nem ott van, ahol megjelenik, hanem néhány lépéssel mögötte rejtőzik. Az AI egy erőteljes gondolkodó partner, amely felgyorsítja ezt a kutatást – de csak akkor, ha megfelelő bizonyítékot ad rá. A bizonyítékok nélküli hibakeresés az a terület, ahol a mesterséges intelligencia a legtöbb hallucinációt okozza.
Ebben az egységben fegyelmezett folyamatot alakítunk ki a hiba generálásától a kiváltó okig: a tünet tisztázása, bizonyítékok gyűjtése (hibaüzenet, veremnyom, napló, bejegyzés), hipotézis generálása, hipotézis tesztelése és a javítás érvényesítése. Az AI minden lépésben segít; de a "javított" döntést úgy hozzuk meg, hogy látjuk, hogy a hiba valóban eltűnt.
Miért minden a bizonyíték?
Egy LLM nem látja a hibát úgy, ahogyan te látod; Csak azt tudja, amit mondasz neki. Egy olyan mondat, mint „Az alkalmazás összeomlik”, szinte semmilyen információt nem ad a modellnek, és a modell egy jóslattal – vagyis egy hallucinációval – pótolja a hiányt. Viszont a teljes hibaüzenet, veremkövetés – annak lebontása, hogy melyik függvényen keresztül hívja meg a hibát, a hibát kiváltó bemeneten és a várt adatokon stb. A megfigyelt viselkedés alapján a modell képes rangsorolni a valós valószínűségeket.
A hibakeresés során gondoljon az MI-re a nyomozó asszisztensére: minél több bizonyítékot mutat be, annál pontosabb hipotézist generál. Ha nincs bizonyíték, az asszisztens csak találgat, és rossz nyomra vezethet.
Tipp: Mielőtt egy hibát AI-ra portolna, csökkentse azt a legkisebb reprodukálható példára. A hibát kiváltó legkisebb kód és bemenet radikálisan megkönnyíti mind az Ön, mind a modell munkáját; leggyakrabban e redukció során maga találja meg az okot.
Lépésről lépésre: A kiváltó ok elemzésének folyamata
- Tisztázza a tünetet. – Mi történik, mire számítottál? Írd le a kettőt egy mondatban!
- Gyűjts bizonyítékokat. Teljes hibaüzenet, veremkövetés, releváns naplósorok, kiváltó bejegyzés, verzióinformáció.
- Állítsa elő a hipotézist. Az AI-ból „3 lehetséges ok, amely megmagyarázza ezt a tünetet, és hogyan tesztelhetem mindegyiket?” kérdez.
- Először tesztelje a legolcsóbb hipotézist. Adjon hozzá egy naplót, nyomtasson egy értéket, és futtasson egy tesztet. A bizonyítékok megerősítik a hipotézist?
- A kiváltó okot javítsa, ne a tünetet. Ahelyett, hogy egy tapasz segítségével elhallgattatná a tünetet, kezelje a kiváltó okot.
- Érvényesítse és adja hozzá a regressziós tesztet. Lásd a hiba eltűnését; Ezután írjon egy tesztet, amely észleli a hibát, így nem jön vissza.
Három mini tok
1. eset – A verem nyomkövetése a megfelelő fájlhoz vezetett. Egy alkalmazás 500-as hibát adott vissza bizonyos kérésekre. A fejlesztő megadta a teljes verem nyomkövetését és az aktiválási kérést az AI-nak; A modell azt feltételezte, hogy a hibát egy dátumelemző réteg None értéke okozta. A fejlesztő hozzáadott egy naplót ehhez a sorhoz, ellenőrizte és 15 perc alatt megoldotta; 2 órát vesztegettek előző nap nem igazolt kísérletekkel.
2. eset – A hallucinációk rossz nyomra vezettek. Egy másik fejlesztő egyszerűen azt írta, hogy "az adatbázis kapcsolat megszakad". A mesterséges intelligencia a kapcsolatkészlet beállításával vádolt minden bizonyíték nélkül; A fejlesztő 40 percet töltött ezzel a beállítással. A valódi ok a hálózati oldalon bekövetkezett időtúllépés volt, és csak a naplókból derült ki. Tanulság: a bizonyítékok nélkül felvett hipotézis csak valószínű, nem megbízható.
3. eset – Folyamatos hiba észlelve. Volt egy teszt, ami időnként megbukott. Az AI megkapta a tesztkódot, a hibaüzenetet és a „néha átmegy, néha meghiúsul” információt; a modell a tesztek megosztott idő/rend függőségét jelezte. A felülvizsgálat megerősítette, hogy a teszt a rendszer helyi időjén alapult. Miután az órát rögzítették (gúnyolták), a teszt stabillá vált.
Négy másolható sablon
Bizonyítékokon alapuló hipotézisgenerálás:
Hibakeresést végezek. Az alábbi bizonyítékok.- Várható viselkedés: {{megfigyelt}}- Megfigyelt viselkedés: {{megfigyelt}}- Hibaüzenet / veremkövetés: {{trace}}- Kiváltó bemenet: {{input}}- Környezet/verzió: {{version}} Sorolja fel a 3 VALÓSZÍNŰ okot, amelyek megmagyarázzák ezt a tünetet. Mindegyikhez: hogyan teszteljem (legolcsóbb ellenőrzés), és hogyan javítsam ki, ha igaz. Ha a bizonyíték nem elegendő, mondja meg, milyen további információra van szüksége.
A verem nyomának értelmezése:
Olvassa el ezt a veremnyomot. Tegye különbséget aközött, hogy a hiba VALÓSZÍNŰEN melyik sornál kezdődik (a gyökérnél), és mely sorok csak a lánc folytatásai. Javasoljon 1-2 helyet, amelyet először érdemes megnézni. Kapcsolódó kód:{{code}}Nyomkövetés:{{trace}}
Minimális repro kivonás:
Az alábbi kód hibát produkál. Csökkentse a LEGKISEBB példányra, amely továbbra is kiváltja a hibát, de elvet minden feleslegeset. Ne feltételezze, hogy minden eltávolított darab nem befolyásolja a hibát, hanem adjon hozzá egy megjegyzést, amely szerint "ha a hiba eltűnik az eltávolításkor, akkor ez az oka".{{code}}
Korrekció utáni érvényesítés és regressziós tesztelés:
Tegyük fel, hogy a kiváltó ok {{ok}}, és a következő javítást végzem: {{javítás}}.1) Ez a javítás valóban kijavítja a tünetet, lesz-e mellékhatása?2) Írjon egy regressziós tesztet, amely a jövőben észleli ezt a hibát.
Gyenge felszólítás / Erős felszólítás
Gyenge: "A kód nem működik, miért?"
Erős: "A Node 20 / Express. A POST /orders 500-at ad vissza, ha az elemek üres karakterláncok a törzsben; 400-at kellett volna visszaadnia. Verem nyomkövetés: TypeError: Nem olvasható a undefined tulajdonságai ("0" olvasása) – mellékelve van a teljes nyomkövetés és a hozzá tartozó kezelő. Adja meg a 3 legvalószínűbb okot, amelyek magyarázzák ezt a kódot.
Erőteljes változat; Megadja a környezetet, a végpontot, a trigger bemenetet, a pontos hibatípust és a várható viselkedést. A modell már nem előrejelzéseket, hanem elemzéseket készíthet.
lépést
Az AI hozzájárulása
a te irányításod
bizonyítékok gyűjtése
Milyen bizonyítékokra van szükség, emlékeztet
Valóban bizonyítékokat gyűjt
hipotézisgenerálás
Sorolja fel a lehetséges okokat
A kontextus alapján rangsorol
hipotézis tesztelés
Vizsgálati módszert ajánl
Személyesen működik és figyel
korrekció
patch ajánlja
Megoldja a kiváltó okot? ez igaz.
regresszió
tesztet ír
Ellenőrzi, hogy a teszt hibás-e
A kiváltó ok megoldása, nem a tünet
A legtöbbször az AI olyan javítást javasol, amely gyorsan elnémítja a tünetet: adjon hozzá egy try/catch-et, tegyen egy null checket, nyelje le a hibát. Ez néha igaz, gyakran veszélyes; mert az eredeti ok a helyén marad és újra előtör valahonnan. Minden javításnál tedd fel magadnak a kérdést: „Ez megoldja a hiba okát, vagy láthatatlanná teszi?” Miután megtalálta a kiváltó okot, a javítás általában kisebb, robusztusabb és tartósabb.
Figyelem: Egy kivétel (üres fogás) csendes lenyelése nem oldja meg a hibát; csupán elrejti és lehetetlenné teszi a jövőbeni diagnózist. Ha a mesterséges intelligencia ilyen „megoldást” javasol, ne fogadja el anélkül, hogy megkérdőjelezné a kiváltó okot.
Gyakori hibák
- Kérdések feltevése bizonyítékok nélkül. A kétértelmű mondatok hallucinációba taszítják a modellt; Adja meg a teljes hibát, nyomkövetést és bevitelt.
- Az első hipotézishez való ragaszkodás. Az AI első javaslata talán nem a legvalószínűbb; Kezdje a legolcsóbb ellenőrizhető hipotézissel.
- A tünet befoltozása és a kiváltó ok hiánya. Az elnémított hiba visszatér.
- A javítás bezárása ellenőrzés nélkül. Nézze meg gyártási állapotban, hogy a hiba valóban eltűnik.
- Nem ír regressziós teszteket. Ha nem adnak hozzá teszteket, ugyanaz a hiba csendben visszatér a későbbi verziókban.
Összefoglalva
A hibakeresés során a mesterséges intelligencia ereje egyenesen arányos a bizonyítékokkal: a teljes hibaüzenet, a veremkövetés, a trigger input és a várt viselkedés nélkül a modell csak spekulál. A fegyelmezett folyamat – a tünetek tisztázása, bizonyítékok gyűjtése, hipotézisek generálása, tesztelés a legolcsóbb vezérléssel, a kiváltó ok javítása, ellenőrzés és regressziós tesztelés hozzáadása – gyorsan és véglegesen bezárja a hibát. Az AI egy hipotézisgenerátor; Te vagy az, aki eldönti, hogy a hiba valóban megoldódott.
Pályázati feladat
Válasszon ki egy valódi hibát, amellyel a közelmúltban találkozott (vagy reprodukáljon egy teszthibát). Először végezze el a „minimális reprodukciós” lépést; Távolítsa el a hibát kiváltó legkisebb kódot és bemenetet. Ezután szerezzen be 3 lehetséges okot és tesztelési módszert az MI-től a „bizonyítékon alapuló hipotézisgenerálás” sablonnal. Tesztelje saját maga a legolcsóbb hipotézist, keresse meg a kiváltó okot, javítsa ki, és végül írjon egy regressziós tesztet, amely a jövőben észleli ezt a hibát, és ellenőrzi, hogy a teszt valóban hibás-e.
ellenőrző lista
- [ ] A hibát a legkisebb reprodukálható mintára csökkentem, mielőtt áthelyezném az AI-ba.
- [ ] Hozzáadom a teljes hibaüzenetet, a verem nyomkövetését, a bemenetet és a várt viselkedést a prompthoz.
- [ ] A legolcsóbb szabályozhatóval kezdem, anélkül, hogy egyetlen hipotézisbe lennék bezárva.
- [ ] Ellenőrzöm, hogy a kiváltó okot megszüntettem-e, nem pedig a tünetet.
- [ ] Megfigyelem, hogy a javítás valójában kijavítja a hibát.
- [ ] Minden megoldott hibához hozzáadok egy regressziós tesztet.