2022 vége, a ChatGPT első kiadása óta gyakorlatilag minden az MI-ről, annak térhódításáról veszélyeiről, vagy éppen társadalmi következményeiről szól. Ezek különböző reakciókat váltanak ki az emberekből: valaki lehetőséget lát benne, valaki a munkaerőpiac változásait próbálja megjósolni, és feltérképezni, hogy milyen szakmák jöhetnek létre, és melyek azok, amelyeket ki fognak váltani a különböző mesterséges intelligencia megoldások, és vannak, akik szimplán megijednek, nehogy az ő munkájuk váljon feleslegessé a jövőben.

Ugyanígy, ez az a téma, ami felmerül az IT megkeresések kapcsán is, legyen szó akár egy meglévő alkalmazás kiegészítéséről MI funkciókkal, akár egy vállalat belső folyamatainak megértéséről és esetleges optimalizálásáról. A közös pont mindkét esetben ugyanaz: a mesterséges intelligencia a repetitív, kevés gondolkodást igénylő feladatok meggyorsításával képes a leghasznosabb lenni minden fél számára:

• felhasználói oldalról ezeknek a feladatoknak a megoldása egyébként sem izgalmas és kifejezetten bosszantó is tud lenni

• a számítógép ezeket hatékonyan, sokkal kisebb, vagy gyakorlatilag nullás hibaszázalékkal tudja megoldani

• vezetői oldalról pedig megvan az az előny, hogy a munkavállalók valóban értéket tudnak teremteni, nem pedig monoton feladatokkal töltik az idejüket. Ez a vállalat működésének hatékonyabbá tételén túl a munkatársak mentális jóllétéhez is hozzájárulhat.

Esettanulmányok – szoftvermodernizálás

A poszt írása időpontjában két ilyen, egymástól teljesen eltérő módon lefolytatott felmérésen vagyunk túl, és alapvetően mindkét esetben a FOMO (Fear of missing out) effektus volt a megkeresés fő mozgatórugója, vagyis tulajdonképpen az, hogy egyik ügyfelünk se szeretett volna lemaradni azért, mert nem akarnak MI „early adopterek” lenni.

Az egyik, és időben korábbi megkeresésünk kapcsán egy általunk fejlesztett alkalmazás funkciókészletét szerette volna ügyfelünk kibővíteni MI funkciókkal. Ebben az volt érdekes, hogy jó eséllyel az alkalmazás felhasználói csak a felolvastatott szöveg meghallgatása után jöhettek rá, hogy az alkalmazás használ ilyen funkciókat, egyébként teljesen rejtve marad számukra. Ehhez az alkalmazáshoz tartoznak adminisztrátori funkciók, viszont itt ahelyett, hogy a mostani munkájukat könnyítenék meg az új fejlesztések, inkább azt lehet mondani, hogy nincsen bennük semmi „újdonság”, viszont alapesetben (vagyis MI nélkül) annyi manuális munkával járnának, hogy a fejlesztésébe bele se kezdene az ügyfél, mert nem látja megtérülni az adminisztrátorok által befektetett energiát.

Vállalati folyamatok feltérképezése

A második esetben egy gyártócég, hasonló indíttatásból keresett meg minket, mivel az ügyintézés, beszerzés, tervezés folyamatában látnak lehetőségeket, hogy hol tudna bekapcsolódni egy MI megoldás. Itt nagyon fontos volt az, hogy a vezetőség biztosította az ezen munkakörben dolgozó kollégákat, hogy ezeket a fejlesztéseket nem az ő lecserélésükre, hanem annak érdekében tervezzük meg, hogy ők hasznosabb feladatokkal tudják kitölteni a munkaidejüket, adott esetben mondjuk a folyamataikban a fejlődési lehetőségeket is számba tudják venni, és megoldást kidolgozni rájuk.

Ez a felmérés személyesen történt, a későbbi végfelhasználókkal való csoportos egyeztetések útján. Látszott rajtuk, hogy készültek, jöttek ötletekkel, és a vezetők részéről a megerősítés miatt nem voltak zárkózottak. Elsőként azt gondoltuk, hogy amikor kimegyünk, akkor nem lesznek kooperatívak a bevezetőben említett, az átlagembereket foglalkoztató félelmek miatt. Ezeken a megbeszéléseken csak mi, mint szoftverfejlesztő cég, és a végfelhasználók vettünk részt, kihagyva ebből a menedzsmentet, mint hallgatóságot.

A fent említett módszer hatékonynak bizonyult, melynek minden eleme fontos szerepet játszott a sikerességben:

• a vezetői hozzáállás transzparens kommunikációja miatt proaktívak voltak a megbeszéléseken

• a csoportos megbeszéléseknek hála a különböző felhasználók egymást triggerelték a gondolataikkal, úgyhogy hatékony, brainstormolós meetingek jöttek létre

• a vezetők távolmaradása miatt teljesen őszinte tudott lenni a kommunikációjuk. A felmérést megelőzően egy rizikót láttunk volna abban, hogyha a menedzsment is a része lesz a megbeszéléseknek, mert nem mernek bevallani kevésbé hatékonyan működő folyamatokat, szégyellve, hogy valamivel sok idő telik el.

Tapasztalatunk szerint a feladatok, amelyek során az AI hatékonyan bevethető, a következőek:

• strukturálatlan adatok feldolgozása: főleg PDF, ebből kinyerni adatokat legtöbb esetben manuálisan lehet, főleg, hogyha az egy szkennelt fájl

• szabadszöveges emailek feldolgozása: ha az MI fel van vértezve vállalati adatokat tartalmazó kontextussal, akkor még azokban az esetekben is tudunk korrekt megrendelést készíteni, hogyha az mondjuk az embernek csak hosszas keresgélés után lenne egyértelmű

• rugalmas interfész a felhasználók felé: a legtöbb szoftver listákkal, mezőkkel operál, amikor felhasználói felületről beszélünk, az MI-vel viszont chaten keresztül tudunk beszélni, és a válaszokat jóval gyorsabban megkapni. Például, lehet, hogy egy vállalati szoftverben 4-5 szint mélyen találunk meg valamire választ, míg az MI ezt jóval gyorsabban elő tudja keresni, és a kérdéseinket szabadszövegesen tudjuk megfogalmazni felé.

Mivel az általunk használt szolgáltatások (lásd következő bekezdés) működésébe csak bizonyos szintig látunk bele, ezért a pilot projekt során az egyik alapfeltételezésünk az volt, hogy bár a forrásrendszerekhez csatlakozik a megoldás, de az eredményeket a felhasználónak csak megjelenítjük, nem küldünk emailt, nem írunk a forrásrendszerekbe stb. Ennek oka, hogy ezek már gyors manuális lépések, és a lényegi információ már jóval gyorsabban rendelkezésre áll, viszont nagyobb problémát okozunk, ha ezek automatikusan mentésre kerülnek, és később ezeket korrigálni kell (akár módosításokkal, akár elnézést kérő / pontosító emailekkel).

No-code megoldások vs. Azure Services

A technikai megvalósítás tervezése során felmerült a kérdés, hogy használjuk-e a Microsoft no-code megoldását, a Copilot Studiot, vagy egy szinttel „alacsonyabban”, saját magunk által létrehozott és konfigurált Azure megoldással menjünk-e tovább.  

Rövid kutatás után a második mellett döntöttünk, hiszen a kiinduló állapot továbbra is egy vállalati szoftver, saját adatbázissal, illetve on-premise hálózaton tárolt, fájlmegosztásban lévő fájlok halmaza, amikből az MI-nek a kontextust kell felépítenünk. Előbbit semmiképp sem szeretnénk kinyitni a külvilág felé, utóbbinak SharePointra migrálása pedig nem a scope része, mivel több szereplővel is egyeztetnünk kellett volna a megvalósításról. Ezen felül szükségünk van bizonyos pontokon up-to-date adatokra is, ilyenkor pedig az Azure OpenAI funkciója, a function calling nagy hasznunkra válik.  

A fentiek mind bonyodalmasan oldhatóak meg a Copilot Studioval, ezért választásunk a saját magunk által üzemeltetett Azure szolgáltatások használatára esett. Ezt a választásunkat is megerősíti, hogy a Copilot Studio gyakorlatilag fekete dobozként működne a számunkra: nem fejlesztőknek találták ki, így a konfigurációs lehetőségeink arra korlátozódnak, amiket a felhasználói felületen elérhetünk. Az Azure szolgáltatások (ideértve az Azure AI Search-öt, vagy Document Intelligence-t is) használatával jóval nagyobb kontrollunk van afelett, hogy hogyan működjön a rendszer, de egyébként jó tanulság volt a Copilot Studio megvizsgálása is. Kevésbé komplex esetekben az is felhasználható, és az üzemeltetési költségei is kedvezőbbek a saját magunk által tervezett megoldásnál.

Konklúzió

Összességében elmondható, hogy az MI jelenlegi állása szerint teljesen nem tud kiváltani embereket és munkaköröket. Ennek oka az, hogy továbbra is rutinfeladatokat tud megoldani – ahol már speciális eset van, vagy kreativitás kell, akkor már érdemes felülvizsgálni az eredményt, mert könnyen elképzelhető, hogy az hibás lesz. Hogy ez valóban ne járjon leépítésekkel, abban viszont a vezetőknek is felelősségük van.

‍