Kód belső működésének ellenőrzése automatikusan AI segítségével

Használok anomália detektálást izolációs erdővel felhős infrastruktúra belső analitikájának figyelésére. Ráadásul nyers szöveges részeket is beleteszek. Az automatikus feature engineering megoldásom szétszedi numerikus mátrixra. Majd kiválogatja és szól ha valami furcsa van a múlthoz képest.

Működik, okos, észrevesz különleges időpontokat, például ha furcsa időben érkezett be egy kérés, vagy furcsa lett az eredménye. Nem kell manuálisan felügyelni. Persze vannak egyszerű figyelő eljárások is.

Ezzel infrastruktúra állapot figyelést támogatok gépi tanulással.

Viszont szeretnék kódban futás közben állapotokat vizsgálni. Konkrétan változók és objektumok értékeit. Mindezt tárolni és automatikus jelzést kérni az AI algótól, ha valami furcsát talál. Az izolációs erdő nagy dimenziójú adatnál is villámgyors és lineáris időben skálázódik.

Tehát tesztelést támogatok úgy, hogy a kódom bármely pontjára beinjektálok egy függvényt, melynek átadok változókat és bármilyen objektumot, mely azon a pontján releváns a kódomnak.

A függvény átalakítja az összes objektumot egy tömbbé, majd ezt a tömböt folyamatosan hozzáadom egy globális változóhoz. De minden alkalommal a hozzáadás után ráfuttatom az AI-t és breakpoint-ot csinálok, ha van furcsaság.

Az eredmény, hogy futhat magától a kód és furcsa állapotnál REPL konzolt dob nekem, melyben ott van élőben az állapot és könnyen tudom prototipizálni a javításokat. Ruby-nál a “binding.pry” hívást használom ehhez.

Pseudo kód:

 

anom( var1, obj1, var2, stb )

 

Ennyi a hivás, melynél “anom” a függvényem neve és változó számú paramétert adhatok át. Egy dolog fontos, hogy egy minimum számú bejegyzést gyűjtsünk, hogy az elején ne legyen sok fals riasztás.

Miért hasznos? Mert megérti a furcsa kombinációkat. Mélyen látja az összefüggéseket.

Éjjel nappal futtatok automatikus teszteket a kódomra, melyet véletlen eloszlásból mintavételezett értékekkel szórok meg crash test céljából. Ráadásul kevert modellből (uniform, exponenciális, nulla model stb) és így nagy szórású, extrém állapotokat is elő tudok idézni az input oldalon. String-eknél hibás utf kódokat is küldök be.

Viszont a kód belső eljárásai viselkedhetnek furcsán a bemeneti értékektől függetlenül. És ezt lehet elkapni automatikusan komplex anomália detektálással.

Ilyen beépített megoldásokat kellene hozzáadni a modern nyelvekhez. Erős fejlesztői hiba detektáló támogatást adna. Illetve nem csak ML megoldások, hanem egyszerűbb statisztikai határérték elemzéseknek is lenne értelme, melyek futás időben jelzéseket dobnának debug módban vagy teszt módban. Ezek villámgyorsak lennének, illetve olyan kódrészekhez tenném amúgy is, amelyek nem performancia kritikusak, nem belső ciklus része, és van idő egy rövid elemzéshez.

Hozzászólások

csak az "izolációs erdő" szóért egy külön bugyrot kellene létrehozni a pokolban.

// Happy debugging, suckers
#define true (rand() > 10)

Van bármi, ami ebből open source? Hogy érdemes nekilátni hasonló megoldásnak?

Nincs túl sok false positive?

Igazából annyira egyszerű a koncepció, ahogy leírtam. Az "isolation forest" algo sok nyelven elérhető, ha nem, akkor meg python-ból vagy másból meghívható.

Egyszerűen elkezded bedobálni egy globális változóba az objektumokat (lelapítva egyetlen tömbbé a tömbben) és futtatod közben. Ennyi az egész. Példa adat:

[[1, 1, 6],
 [0, 0, 1],
 [1, 1, 0],
 [0, 0, 3],
 [1, 0, 0],
 [0, 1, 0],
 [2, 0, 23],
 [3, 1, 0],
 [1, 13, 0],
 [3, 1, 1]]

AD eredménye:

[[6, 0.6240602610039736], [8, 0.6056862922420121]]

Vagyis a 6. és 8. sort gondolja anomáliának. Ha 0.7-es a limit, akkor még nem azok.

Persze itt látszik, hogy azokban van nagyobb érték és ez egyszerűnek tűnik. Nem lesz egyszerű azonban, amikor nagy a dimenzió mértéke és rengeteg adat van. Ott kapunk igazán okos döntést.

A fals pozitívok kérdése fontos, ehhez pár ötlet:

Egyrészt az isoforest visszatérési értéke egy 0..1 közötti pontszám, melynél a nagyobb pontszám erősebb anomáliát jelent. Az eredeti 2008-as paper szerint 0.6 felettiek tekintendők annak. Viszont ezt tudod kézzel finomhangolni.

Másrészt érdemes több objektumot elemezni, hogy a tömb dimenziója minél magasabb legyen. Úgy még okosabb szűrést kapunk.

Nem tudom milyen környezetet használsz, Ruby-hoz "isotree"-t javasolnám "gem install isotree"-vel, Python-hoz "from sklearn.ensemble import IsolationForest" javaslom "pip3 install sklearn"-el, de máshoz is lesz nagy valszeggel.

Ha implementálod és kérdésed van, nyugodtan írj.

Latency-hez 1 dimenziós értékekhez adok egy stat eljárást is, mely megmondja, hogy elég extrémek-e az értékek. Ezt sigma értékével tudod meghatározni, hogy feljebb vagy lejjebb legyenek a limitek. 2 és 3 között legyen, alapból 3-at javaslom:

 

sigma = 3

mean = average of values

sd = standard deviation of values

limit_normal = mean + sd * sigma
limit_exp = -ln( 1 – erf( sigma / 2^0.5 )) * mean
if skewness < 1
    limit = limit_normal
else if skewness > 2
    limit = limit_exp
else
    limit = limit_normal^( 1 - ( skewness – 1 )) * limit_exp^( skewness -1 )

 

A két limit között geometrikus módon választok, annak függvényében, hogy mekkora a skewness. Ez egy baromi okos és adaptív megoldás részemről, szakterületen nem találod meg. Ez még jó lehet 1D-s értékekhez.

Ha 1D-s, akkor ahhoz ne az isoforest-et használd, mert annak magasabb dimenzióban van az ereje. Akkor csak a stat függvényemet javaslom.

mean-t, sd-t meg skewness-t találsz a python stat csomagban, rengeteg modulban le van implementálva. Ne is implementáld magad szerintem. Scipy stats csomagban lesz minden.

# Importing library

from scipy.stats import skew

# Creating a dataset

dataset = [88, 85, 82, 97, 67, 77, 74, 86, 81, 95, 77, 88, 85, 76, 81]

# Calculate the skewness

print(skew(dataset, bias=False))

Kiegészítés: ha több 1D-s értéked van, azt nyugodtan bedobhatod az isoforest-be. Arra értettem a fentit hogy ne használd, ha csak 1 db 1D-s értéked van.

Az AI mellett meg nyugodtan vizsgálhatod az extrémitását a stat eljárással is egyenként mindegyiknek. Ha a limit-nél magasabb valamelyik érték, akkor valamilyen extrém hatás van jelen erős valószínűséggel.

A "részemről" szótól tekintsetek el, rosszul fogalmaztam meg mert siettem és nem úgy hangzik ahogy le akartam írni. Nem arra akartam utalni hogy "én" milyen okos megoldást adok, hanem arra, hogy az adaptivitása okos, mert sok változó függvénye és ehhez képest pedig relatíve egyszerű.

Maga az otlet nem rossz. De mint az esetek tobbsegeben itt is a tanulo adatok minosege a kerdeses. Peldaul, hogy allitot be a "contamination" hyperparametert?  

Kösz. Jó a kérdésed. A paraméter miatt valóban marad egyetlen szabad gyök.

Ezzel kapcsolatban írtam feljebb. Hangolni kell. A hibajelzés ellenőrzése alapján feljebb kellhet állítani, valóban. De ez hamar kiderül és gyakorlati tapasztalatom, hogy könnyen és gyorsan hangolható. A 0.6-os érték nagyon jó kiinduló, ettől 0.7 még lehet jó beállítás.

Sőt, mivel az algo minden egyes elemhez vissza adja az értéket, így a fenti stat függvényemmel is lehet extrém limitet vizsgálni és az alapján beállítani. Például 2 sigma megbízhatósággal. Tehát több lehetőség van. Ez így valóban nem 100% adaptivitás, de itt nem is kell.

A tanuló adatok minősége pedig itt nem kérdés, ugyanis valós adatokról van szó, melyekben anomáliát keresünk. Ezek a valós adatok. Semmi teendő nincs. Az AD detektáló mechanizmusnak kell jónak lenni, nem az adatoknak.

Részemről sokat használom a gyakorlatban valós adatokon és az isoforest algot eleve elég adaptívnak és nagyon erősnek találom. Jó összefüggéseket talál és nem kell játszanom a paraméterekkel.

Szerintem itt valamit félreértettél. Szóval van egy felügyelet nélküli eljárásának, ami a épít egy rakás fát, és megjelöli kiugró értéknek azt amihez mindig gyorsan el lehet jutni a fa gyökeréből. A gond az,  hogy nem tudod igazából az anomália vagy csak egy normális megfigyelés ami a PDF farkában van. Vagyis nem tudod, hogy mennyire szennyezett az adatsorod, mennyi igazi anomália van benne.  És teljesen mindegy, hogy az valós vagy nem valós adatsor, innentől fogva ez vakrepülés. Például van 105 megfigyelés, 100 normális amiből 5 van az 5% farok tartományban, és 5 abnormális, ami szinten ott van.  Ez azt jelenti, hogy optimális esetben is minden második “abnormális” megfigyelés hamis pozitív lesz. A gond, hogy igazából nincs erről az egészről fogalmad, addig amíg nem fogsz minden egyes hibát ellenőrizni. 

Ez nem jelenti azt, hogy az iskolation forest rossz, de megvannak a korlátai. Mi is több helyen használjuk, de amikor 100 000+ megfigyelésed van negyedóránként ( mint nálunk ) akkor az 1% anomália is olyan sok hamis riasztást jelent amit nem lehet megnézni.  Ez nem igazából az isolation forest hibája, hanem annak, hogy “felügyelet nélküli “ tanulásról van szó (egyszerűen a faroktartomany feláldozásán kívül sok mindent ilyen esetben nem lehet tenni). Viszont az isolation forest csak annyiban jobb mint mondjuk pl. a GMM, hogy független az adatok eloszlásáról.

Szerintem nem így kell tekinteni. Nincs olyan hogy jó meg rossz adat meg túl sok anomália.

Egyszerűen csak a top X db anomáliát kell tekinteni. Ha kell, akkor a top 3-at. Az eljárás a furcsaság mértékét mutatja. És a legfurcsábbakkal kell kezdeni az ellenőrzést. Ilyen egyszerű.

Ez nélkül nem tudjuk sorba rendezni az adatot furcsaság alapján. Nekünk szívességet tesz eleve, hogy rámutat ranking-el.