AI projektmenedzsment: Miért csak egy újabb IT-projekt az AI-ügynökök építése?

Hogyan kezdett el egy üzleti csapat AI-ügynököket építeni

AI-ügynökök építése, még ha nem is vagyunk informatikusok

Az elmúlt két év érdekes fordulata, hogy már nincs szükség fejlesztőcsapatra ahhoz, hogy működő mesterséges intelligenciát szállítsunk. Egy üzletember, aki le tudja írni, hogy mit kellene történnie, és le tud másolni néhány példát a bemenetre, olyan ügynököt tud építeni, amely valódi munkát végez. Nem terveztük, hogy építők leszünk. Folyamatosan olyan aktivitásokba ütköztünk, ahol a válasz nyilvánvalóan az volt, hogy „ezt egy ügynök is el tudja végezni”, ezért elkezdtünk építkezni. Az első egy délutánba telt. A második egy délutánba telt. Aztán kezdődtek a gondok – nem az épülettel, hanem mindennel körülötte.

Az általunk épített ügynökök

A lista gyorsabban nőtt, mint vártuk. Van egy ügynökünk, aki automatikusan kitölti az ügyfél adatait a Standard szerződéseinkbe. Egy ügynök, aki az értékesítési beszélgetés összefoglalója alapján első ajánlattervezetet készít. Egy integrátor, aki az ügyfél Excel projektlistáját egyenesen a FlexiProject környezetébe importálja. Egy asszisztens, aki segít nekünk a weboldalunk egyes részeinek kezelésében. Egy ügynök, aki lehívja a Google Search Console adatait a domainünkre vonatkozóan, és olvasható heti összefoglalót készít belőlük. Egy ügynök, aki az ügyfelekkel folytatott megbeszélések után frissíti a termékhátralékunkat azzal, hogy az egyes vállalatok szerint mi hiányzik, hogy a funkcióötletek ne vesszenek el a hívás és a következő tervezési ülés között. És tucatnyi kisebb, egyfeladatú segédprogram, amelyet valaki saját magának épített, folyamatosan fejlesztett, és végül megosztott a csapattal.

Amikor ugyanazt az ügynököt párhuzamosan bővítették

A súrlódás nem az egyszer megépített és elfelejtett ügynököktől származott. Hanem azokból az ügynökökből, amelyek valóban számítottak. Két ember fogott egy hasznos ügynököt, mindkettőjüknek volt egy-egy ötlete, hogyan lehetne javítani rajta, és egymástól függetlenül elkezdték bővíteni. Egy héttel később már két változatunk volt: különböző felszólítások, különböző eszközök, különböző széleken felmerülő esetek – és nem volt tiszta módja az összevonásuknak. Ez ugyanaz a probléma volt, amit a fejlesztők évtizedekkel ezelőtt a Git-tel oldottak meg: nem lehet, hogy két ember egy közös kiindulópontból kiindulva dolgozzon és azt különböző irányokba javítsa elágazási modell nélkül. Csak mi nem gondoltuk, hogy szükségünk van rá. Az ágensek „egyszerűek” voltak. A mesterséges intelligencia projektvezető kifejezés még nem került be a szótárunkba.

Miért az AI-ügynökfejlesztés alapvetően IT-projektmenedzsment

Az ügynökök építése triviálisan egyszerű

Az első lecke a legkellemetlenebb: ügynököt építeni valóban könnyű. Bárki, aki ezt olvassa, egy órán belül megnyithat egy modellt, és máris működőképes valamit. A demó varázslatosan fog kinézni. Az első három felhasználó imádni fogja. És pontosan ez az a pillanat, amikor a projekt nehézzé válik, mert egy demó szállítása nem olyan eszköz szállítása, amelyre a vállalat támaszkodhat. A „működik az általam kipróbált bemenetekkel” és a „működik az egész vállalat által hozzáadott bemenetekkel” közötti szakadék óriási, és maga a modell semmit sem tesz ennek áthidalására. Ennek áthidalása az AI projektmenedzsment feladata.

Az AI-ügynököket építő üzleti csapatnak meg kell tanulnia az informatikai projektmenedzsmentet.

Amikor egy nem informatikai csapat elkezd szoftvert építeni, és egy ügynök szoftver, akkor minden olyan problémát megörököl, amelynek kezelésére a mérnöki csapatok ötven éven át tanultak. A követelményeket le kell írni. Meg kell tervezni az architektúrát. A kódot, vagy az utasításokat, vagy az eszközdefiníciókat meg kell osztani valahol. Létezniük kell teszteknek. A változtatásokat át kell tekinteni, mielőtt élesbe mennek. Ha ezek bármelyikét kihagyjuk, attól még nem tűnnek el, csak időben előrehozzuk a költségeket. A jó hír az, hogy a játékkönyv már létezik. Az informatikai projektek sikerét biztosító fegyelmek változatlanul érvényesek, amikor egy üzleti csapat ügynököket épít. Az egyetlen új összetevő az értékelés – a tesztelés AI-specifikus változata.

Az AI Agent projekt életciklusa

1. Kezdeti elemzés – milyen problémát oldunk meg valójában?

Minden olyan ügynök, amelyet érdemes felépíteni, egy elemzési fázissal kezdődik, amelynek semmi köze a mesterséges intelligenciához. Ki fogja ezt használni? Mit csinálnak ma, lépésről lépésre? Melyik lépés fáj valójában? Hogy néz ki a „jól csinált” – mérhetően? Mielőtt megépítettük az ajánlat-előkészítő ügynököt, leírtuk a pontos kézi sorrendet, amelyet az értékesítési csapat követett, megjelöltük, mely lépések ismétlődtek, és melyek igényeltek ítélőképességet, és csak ezután döntöttük el, hogy az ügynöknek mit kell és mit nem kell tennie. Az elemzés tovább tartott, mint az építés. Ez az arány normális.

2. Tervezés – hatókör, integrációk, megosztott fióktelep

A tervezés során három dolgot kell eldöntenie: a bemeneteket és kimeneteket, az integrációkat, amelyeket az ügynök érinteni fog, és ami a legfontosabb, hogy hol él a munka. Ha két ember fog közreműködni, akkor szükségük van a „fő” közös meghatározására. Ez lehet egyetlen dokumentum a kanonikus kérésekkel és eszközdefiníciókkal, egy repo, egy készségmappa – a formátum kevésbé számít, mint a megállapodás. Válassza ki az első napon. Döntse el, hogy mit nem fog az ügynök csinálni, írja le, és tartsa magát hozzá; a scope creep a leggyakoribb oka annak, hogy az ügynökök karbantarthatatlanná válnak.

3. Fejlesztés – a megtévesztően könnyű rész

Maga az építés gyors. Ez a csapda. Megírja a kéréseket, csatlakoztatja az eszközöket, lefuttat néhány példát, és úgy érzi, 80%-ban kész. De inkább csak 30%-ban. A maradék 70% mindaz, amit még nem teszteltél: a furcsa beviteli adatok, a hosszú beviteli adatok, a más nyelvű beviteli adatok, az esetek, amikor az egyik eszköz üres eredményt ad vissza, az esetek, amikor a felhasználó a beszélgetés közepén meggondolja magát. Mindezek közül semmi sem látható az építés belsejéből.

4. Tesztelés – majd ismételt tesztelés

Ez az a pont, ahol az ügynökök leginkább különböznek a klasszikus szoftverektől, és ahol a legtöbb csapat spórol. Egy ügynök ma átmegy egy teszten, holnap pedig megbukhat ugyanezen a teszten, mert megváltoztattunk egyetlen sort a promptban, vagy mert a mögöttes modellt frissítettük. A szükséges fegyelem a regressziós kiértékelés: a bemenetek elmentett készlete az elvárt viselkedéssel, amelyet automatikusan vagy legalábbis szisztematikusan futtatunk minden változtatás után. Enélkül csak akkor értesülünk a regressziókról, amikor a felhasználó megbotlik bennük.

5. Szállítás és átadás

Az olyan ügynök, amelyet hivatalosan soha nem adnak át, olyan ügynök, amely már az első napon örökséggé válik. Az átadás azt jelenti, hogy meg kell írni a felhasználónak szóló dokumentációt, meg kell határozni, hogy a siker hogyan néz ki a termelésben, és meg kell határozni, hogy három hónap múlva is használható-e még az ügynök. Mi ezt a lassú úton tanultuk meg – lásd a következő részt.

MVP, Agile és Scrum az AI projektekben

MVP először – kezdje a legkisebb hasznos ágenssel

Minden sikeres ügynök, amelyet építettünk, önmagának legkisebb hasznos változataként indult. Egy feladat. Egy bemenet. Egy kimenet. Addig ellenálltunk a kísértésnek, hogy hozzáadjuk a második felhasználási esetet, amíg nem láttuk, hogy az első túlélte a valódi felhasználókkal való kapcsolatot. Azok az ügynökök, amelyek küszködtek, éppen ellenkezőleg: az első naptól kezdve ambiciózusak voltak, három képességgel, amelyek közül egyik sem működött végig. A „nagy durranás” ügynökök pontosan ugyanazért buknak el, amiért a „nagy durranás” szoftverprojektek is elbuknak: a formátumok nem változtatnak a matematikán. Ha csak egyetlen szabályt veszel ki ebből a cikkből, akkor ezt: egy mesterséges intelligencia-ügynök MVP-je elég kicsi ahhoz, hogy egy ember három mondatban le tudja írni, és egy nap végéig végig tudja futtatni egy valós példán. Minden, ami ezután következik, az iteráció.

Miért illik az Agile megoldás a mesterséges intelligencia ügynökökhöz

Az ügynökök szokatlanul jól alkalmazkodnak az Agile munkához, mivel szokatlanul kiszámíthatatlanok. Egy ügynököt nem lehet teljes mértékben előre meghatározni, ahogyan egy fizetési formát vagy egy jelentést sem. Elkészítesz egy kis verziót, megfigyeled, hogyan működik a való világban, látod, hol nem működik, és a következő dolgot javítod. Ha a tökéletes ügynököt papíron próbáljuk megtervezni, mielőtt megépítenénk, az a leggyorsabb módja annak, hogy rossz ügynököt építsünk. Az iteráció nem egy projektmenedzsment preferencia a mesterséges intelligencia esetében; ez egy strukturális követelmény – ugyanaz a Plan, Do, Check, Act ritmus, amelyet Deming évtizedekkel ezelőtt leírt bármely folyamatra, amelyet folyamatosan javítani kell, csak olyan ügynökökre alkalmazva, amelyek viselkedését nem lehet teljesen megjósolni.

Ügynöki munka futtatása Scrum sprintekben

Minden egyes jelentős ügynököt egy kis Scrum-stílusú munkafolyamatként kezelünk. Az ügynöknek van egy listája azokról a képességekről, amelyekkel rendelkezhet. Minden sprint kiválaszt ezekből egy kis számot. A sprintdemó maga az ügynök, amelyet az azt használó csapat valós inputjaival futtatunk. Ha a demó nem meggyőző, a munka folytatódik; az ütemezés valódi beszélgetést kényszerít ki az építő és a felhasználók között a hónapokig tartó csendes építkezés helyett.

Hibákat követtünk el

Építés az elemzés előtt

Mivel az építkezés olyan gyors, hatékony érzés, hogy rögtön rá is ugorhatunk. De nem az. Az egyértelmű elemzés nélkül épített ügynökök végül technikailag működtek, miközben rossz problémát oldottak meg; az őket használó csapat egy darabig udvarias volt emiatt, majd csendben visszatért a kézi munka elvégzéséhez. Egy délutáni elemzéssel megspórolhattunk volna egy hétnyi építkezést.

Bízva a modellben, hogy rájön

Ez volt a legkövetkezetesebb hibánk, és ezt a legnehezebb elfelejteni. Azt feltételeztük, hogy ha a modellnek egyszerű nyelven adjuk meg a feladatot, akkor az jó megoldást fog tervezni. Ez gyakran nem így történt – nem azért, mert a modell gyenge volt, hanem mert mi magunk nem végeztük el a tervezési munkát. A modellnek nincs rálátása a vállalat kontextusára, a meglévő adatokra, az íratlan konvenciókra, a feladatot körülvevő rendszerre. Minél többet adsz meg belőle, egy valódi elemzést, egy valódi architektúrát, a struktúrát, amit követni szeretnél, annál jobb lesz az eredmény. A modell kiváló a végrehajtásban. Nem az építészed.

Nagy durranás ahelyett, hogy egy MVP-vel kezdenénk

Minden alkalommal, amikor megpróbáltunk egy teljes funkcionalitású ügynököt indítani az első napon, az eredményt hosszabb ideig tartott megépíteni, nehezebb volt hibakeresés, és gyakrabban hagytuk el, mint a szándékosan fejlesztett kis verziókat. A big-bang gyorsabbnak tűnt. Nem volt az.

Két ember párhuzamosan fejleszti ugyanazt a hatóanyagot

Ez volt a Git pillanata. Két ember, ugyanaz az ügynök, különböző ötletek, különböző ágak a fejükben, nincs közös „fő”. Egy héttel később két verzió, amelyek nem akartak összeilleszkedni. Mostantól minden értelmes ügynököt úgy kezelünk, ahogy a fejlesztők a kódot: egy kanonikus verzió, explicit elágazási modell, ha egynél több ember dolgozik rajta, és egy explicit egyesítési lépés. Vagy, ha az ötletek valóban eltérnek egymástól, akkor egy szándékos döntés, hogy két különálló ágensre váljunk szét ahelyett, hogy úgy tennénk, mintha még mindig egy lennének.

Nincs kezdeti dokumentáció – a felhasználók nem tudták, mit csinál az ügynök.

A képességeink első belső felhasználói folyamatosan ugyanazokat a kérdéseket tették fel: mit is csinál ez a dolog, mit kell átadnom, hogy néz ki a kimenet, mikor kell használnom az előző verzióhoz képest. Azt gondoltuk, hogy az ügynök magától értetődő. Nem volt az. Most minden ügynökhöz átadáskor írunk egy rövid, felhasználóbarát leírást – mit csinál, mivel kell etetni, mire számíthatunk, mit nem csinál. Ez tíz percbe kerül, és hetekig tartó zavaros használatot előz meg.

Gyakran ismételt kérdések az AI projektvezetésről

A mesterséges intelligencia projektmenedzsment különbözik a hagyományos informatikai projektmenedzsmenttől?

A tudományágak ugyanazok – elemzés, tervezés, építés, tesztelés, szállítás, ismétlés. A különbségek az építési és tesztelési fázisokban vannak: a kimenetek nem determinisztikusak, a viselkedés változhat, ha a modell vagy a kérések megváltoznak, és a „tesztelés” „értékeléssé válik egy mentett esetkészlet alapján”. Minden, ami e fázisok körül történik, úgy néz ki, mint egy átlagos IT-projekt.

Szükségem van-e projektmenedzsment eszközre az AI-ügynökök fejlesztésének irányításához?

Szükséged van egy helyre, ahol minden ügynök projektként él: tervvel, aktuális verzióval, tulajdonossal és szállítási állapottal. Az, hogy ez a hely egy projektmenedzsment rendszer, egy wiki vagy egy mappastruktúra, kevésbé számít, mint az, hogy van-e ilyen. A sok ügynököt párhuzamosan működtető csapatok számára egy valódi PM-rendszer gyorsan megtérül.

Mekkora legyen egy MVP-ügynök?

Elég kicsi ahhoz, hogy egy ember három mondatban leírja, és egy nap végére végigfuttassa egy valós példán. Ha nem tudod, akkor a hatókör túl nagy, és az MVP valami szűkebb benne.

Hogyan lehet megakadályozni, hogy két ember párhuzamosan építse ugyanazt az ügynököt?

Nem akadályozod meg, hogy két ember hozzájáruljon – egyértelművé teszed, hogy hol él a kanonikus verzió, kié az összeolvadás, és mikor kell az eltérő ötleteket szándékosan két különálló ágensre szétválasztani. A szoftverfejlesztésből vett lecke egy az egyben alkalmazható: közös ág, egyeztetett egyesítési folyamattal.

Mikor válik egy ügynök örökséggé?

Abban a pillanatban senki sem felelős annak értékeléséért, hogy segít-e még. Egy ügynök, amelyet senki sem ellenőriz, csendben leépül, a körülötte lévő világ változik, a bemenetek fejlődnek, a mögöttes modellt lecserélik, és egy nap rosszul működik, és senki sem veszi észre. Az örökség nem egy kor, hanem az elhanyagoltság állapota.

Következtetés

Az AI-ügynökök építésének izgalmas része, a modell, az utasítások, a pillanat, amikor egy demó először működik, a munka legkisebb töredéke. A nem izgalmas részek azok, amelyek a demót olyan eszközzé teszik, amelyre az egész vállalat támaszkodhat: világos elemzés, valódi terv, közös ág, regressziós tesztek, dokumentáció és egy olyan iterációs ritmus, amely az ügynököt még jóval az első verzió leszállítása után is hasznosnak tartja. Mindezek egyike sem egzotikus. Ez pontosan az a fegyelem, amely évtizedek óta sikerre viszi az informatikai projekteket, és amelyet egy kicsit újabb típusú szoftverre alkalmaznak. Azok a csapatok, amelyek korán átveszik ezt a fegyelmet, olyan ügynököket kapnak, amelyekben megbíznak. Azok a csapatok, amelyek kihagyják, végül kétszer építik újra ugyanazt az ügynököt. Az AI projektmenedzsment a gyakorlatban azt jelenti, hogy minden egyes ügynököt valódi projektként kezelünk, egy olyan tervvel, amelyet megtervezhetünk, felülvizsgálhatunk és javíthatunk. Mi ezt a FlexiProjectben tesszük, ahol minden ügynök saját projektrekordot kap, egy világosan leírt cselekvési tervvel; bármilyen rendszert is választ, minden ügynököt kezeljen projektként, ne pedig kísérletként.