Kérdőív feldolgozó rendszer #2: Programcsomagom & Azure

Programcsomag elképzelése

Az általam választott projekt nem csak egy kérdőív felismerést tartalmaz, hanem egy egész programcsomagot.

A programcsomag tervezett tartalma:

  • Kérdőív-felismerő app (röviden: app)
  • SQL szerver, konfigurációs panellel
  • Kimutatást készítő modul
  • Kézírást felvivő modul

Kérdőív felismerő app:
A fő alkalmazás, elindítható külön is, illetve a programcsomag részeként is. A különbség ezek között, hogy ha az egész csomagot használják, akkor projektekbe szervezhetjük a különböző kérdőívek feldolgozását, az információk (SQL címe, táblák nevei, általános beállítások) mentésre kerülnek, így az app nem kér információkat a feldolgozáshoz, ha elkülönítve van futtatva, akkor nyilván kér.

SQL szerver konfigurációs panellel:
Terveim közt szerepel, hogy az adatbázisokból legalább kétfajtát támogatok (MySQL/PostgreSQL, MSSQL), mert a MSSQL rendszerigénye a többihez viszonyítva kicsit magasnak tűnik, az esély nagy rá, hogy a programcsomag nem egy i7|16GB ram|GTX1080 kategóriájú gépen lesz futtatva, illetve a rendszerigényt szeretném alacsonyan tartani. Egynél több adatbázisrendszert pedig egyszerű támogatni, mivel nem beleégetni szeretném az adatbáziskezeléses parancsokat, hanem egy interface-t létrehozni, majd arra osztályokat. Azure támogatása sincs kizárva, de erről majd egy későbbi bejegyzésben.

Kimutatást készítő modul:
Itt egyszerű dolgokra kell gondolni, diagram, táblázat. Természetesen törekedve arra, hogy lehetőleg vektor-grafikusan lehessen menteni a képeket a kimutatásokról.

Kézírást felvivő modul:
Habár jónéhány OCR elérhető, első körben a „manuális felismerést” szeretném majd implementálni, ami annyit takarna, hogy az app kivágja azokat a részeket, ahol szövegnek kellene lennie és van is. Ennek megvalósítása aránylag egyszerűnek tűnik, a lap szélessége*0,75 hosszú vonalakat keresek, vagy ha sikerült az egész lapot beazonosítanom, akkor kivágom az előre (sablonként) megadott részt. Névfelismerésre szintén ezt használni, további részletek ebből is egy külön bejegyzésben lesznek kifejtve.

 

Azure – „yay or nay?”

Azure használata egy nagyon kellemes döntés lenne, semmilyen új gépet nem kellene beilleszteni a hivatali ökoszisztémába, nem kellene semmit változtatni a benti hálózati topológián. Ugyanakkor két erőteljes kérdés felmerül ezzel kapcsolatban:

1. Megéri-e?
Erre a kérdésre még nem lehet egyértelmű választ adni, hiszen nem ismert az appom sebessége, hogy milyen teljesítményű virtuális gép kellene hozzá, illetve mennyi az egy kérdőívre fordítandó keret. Viszont kényelmesnek nagyon kényelmes lenne, VM felállít, bekonfigurál, képek (kérdőívek) feltöltése, majd egyszer csak jön egy üzenet, hogy készen van, adatbázis kimentés és VM leáll.

2. Szabad-e?
Kérdőívek személyes adatokat is tartalmaznak, melyek alapján tisztán beazonosítható a kitöltő, válaszai alapján akár a politikai hovatartozása is, ezért ezek érzékeny adatnak minősülnek, melyeket elvileg csak szabályozott körülmények között szabad kiadni. Erről meg fogom kérdezni a hivatalt, hogy mi az álláspont, a felhőben való feldolgozás adatkiadásnak minősül-e a jelenleg hatályos jogszabályok alapján. Szerencsére az Azure azzal is hirdeti magát, hogy törvényi előírásoknak megfelelően lehet adatokat tárolni, amennyiben az itthoni jog teret ad ennek és az Azure-ban ez nem jelentkezik többletköltségként, akkor megfontolandó egy Azure kompatibilitást is felvenni a tervezett feature listára.

Birthmarks data #6 – SMOTE training

Mivel a jelenlegi adathalmaz elég kicsinek mondható, így nem olyan egyszerű olyan kísérletet összeállítani ami hozza az elvárt precizitást, megbízható eredményt szolgáltat (fontos néhány alkalmazás tekintetében, hogy a felhasználó mit kap vissza válaszként), ugyanakkor nagy mértékben csökkenti a magolás bekövetkezését. Ezért megnézzük a tanulás eredményét abban az esetben, ha az adatokat egy kicsit felturbózzuk (mármint példányszámban).

Continue reading

Klaszterezés a Studioban

Az előző posztomban foglalkoztam a klaszterezéssel általában, most nézzük meg, hogy konkrétan milyen lehetőségünk van erre a Studioban.

Jelenleg mindössze egyetlen egy megoldás áll rendelkezésünkre, méghozzá egy centroid alapú, a k-means (k-közép) algoritmus. Ez ugye központi vektorokkal választja el egymástól a klasztereket. n megfigyelést k klaszterbe partícionál az átlaguk alapján, ezáltal Voronoj-cellákat hoz létre. Iteratív algoritmus, optimalizálást hajt végre. Ez egy NP-nehéz probléma, amit jelenlegi tudásunk (és technológiánk) szerint nem tudunk megoldani belátható idő alatt, még szuperszámítógépekkel sem. Azonban léteznek heurisztikus algoritmusok, amik elég hamar konvergálnak a lokális optimumhoz. Ezek használatával gyorsan elérhetjük a kívánt eredményt.

Continue reading

Klaszteranalízis

Ahogy már korábban is írtam, létezik felügyelt, és felügyelet nélküli tanulás is. Most a másodikkal fogok foglalkozni.

A klaszterezés lényege, hogy az egyes egyedeket csoportokba osztja.
Fontos különbség az osztályozással szemben, hogy itt az adat belső struktúrájának a felfedése a lényeg, és nem pedig az egyes elemek pozíciója.

Continue reading

Birthmarks data #5 – training

Az anyajegyek adatait tartalmazó adathalmazunk első körben készen áll arra, hogy felhasználjuk tanulásra. Elkészítettem pár osztályozó algoritmus modelljét, amiket majd összehasonlítási alapként fogok használni a további finomhangolás és egyebek után. A folyamat végén majd valamikor végül a legjobban működő modellt fogjuk kiválasztani, amiből elkészül a web service.

Continue reading

Birthmarks data #4 – normalization

Az előző bejegyzésben eljutottam addig, hogy megvan a tisztán csak feature selection modul által javasolt feature listám. Ez rendben is van. Ebben a bejegyzésben viszont egy kis kitérőt fogok tenni, amiben csak annyit szeretnék elvégezni, hogy a rendelkezésre álló adatokat normalizáljuk (elsősorban azért, mert mint említettem egy kis utána olvasás után és nálam komolyabban a témához értő emberek iránymutatása azt az eredményt adta nekem, hogy a leginkább célravezető feature selection method ilyen esetben az a mutual information, amihez – és egyébként is – jobb a normalizált adathalmaz).

Continue reading

Birthmarks data #3 – feature selection

Miután az adatainkat rendeztük, szétvágtuk, alakítottuk, kezdhetjük a megfelelő Feature halmaz meghatározását. Mint már tudjuk, ehhez maga az Azure is számos megoldást kínál, de csinálhatjuk ezt manuálisan is (ha tudunk valami olyat amit a gép nem 😀 ). Tehát az anyajegyek adathalmazunkban jelenleg mik lesznek a meghatározó feature elemek, amelyeket az osztályozáshoz fogunk használni?

Continue reading

Birthmarks data #2 – separation

Az előző postban eljutottam addig, hogy az adatokat kicsit módosítottam és a több osztályos tanulásból kétosztályos tanulást csináltam. Most ismét a későbbi könnyebb munka és egy kicsit az eredmények javítása céljából tovább bontottam az adathalmazt. Azaz teljesen különálló adathalmazt hoztam létre a tanuló és a teszt adatoknak. Ez azt jelenti, hogy mind a BENING és a MALIGNANT halmazból véletlenszerűen kiválasztottam 5 db sort tesztadatnak.

Continue reading