Ügynökfejlesztési életciklus

Ez az útmutató kiindulópontként szolgál az AI-alkalmazások vagy -ügynökök létrehozásának teljes életciklusához. Ebben az útmutatóban az "ügynök" az AI-alapú rendszerek gyűjtőkifejezése, beleértve az egyszerű LLM-hívásokat, az AI-függvényeket és az ügynökalapú implementációkat.

A fejlesztési életciklus áttekintése

  1. Használati eset, hatókör és sikerességi metrikák ismertetése
  2. Kezdeti ügynök létrehozása
  3. Iterátum az ügynök minőségéről
  4. Egyeztesse az érdekelt felekkel a gyártás előtt
  5. Kiadás termelésbe és a minőség folyamatos nyomon követése

1. Használati eset, hatókör és sikerességi metrikák ismertetése

Mielőtt bármit építenénk, tisztázzuk, hogy mit akar tenni az ügynök. Hozza összhangba magát az érdekelt felekkel, beleértve azokat is, akik jóvá fogják hagyni az éles környezetbe történő üzembe helyezést.

  • Milyen típusú bemeneteket fog kezelni az ügynök (a "tartomány" vagy a "hatókör")? Milyen felhasználók küldik el a bemeneteket?
  • Hogyan reagáljon ideálisan az ügynök a gyakori bemenetekre? Milyen információt vagy környezetet használjon?
  • Milyen feltételek határoznak meg jó vagy rossz választ: hang, pontosság, teljesség, válaszhossz, biztonság, idézetek vagy egyéb követelmények?
  • Milyen rendszerkövetelmények és korlátozások vannak az éles környezetben: költség, késés és méretezhetőség?
  • Mik a lehetséges meghibásodási módok, és hogyan kezelje őket az ügynök: rossz felhasználói bemenetek, nem megfelelő válaszinformációk, rossz választ jelző felhasználói visszajelzések vagy mások?

Válassza ki a legegyszerűbb megvalósítható megközelítést. Sok használati eset nem igényel összetett ügynöki vagy többügynök rendszert. Az építés előtt mérje fel, hogy a probléma hol merül fel a komplexitási kontinuumban. Az egyszerű determinisztikus logika vagy a kötegelt AI funkciók elegendőek? Ha dinamikus eszközhívásra, érvelésre vagy koordinációra van szükség, fontolja meg az eszközhívó ügynököket vagy a többügynök-rendszereket. További útmutatásért tekintse meg az ügynökrendszer tervezési mintáit.

Ez az alap lehetővé teszi a következőket:

  1. Az ügynök által igényelt adatforrások és eszközök azonosítása
  2. A kívánt viselkedést tükröző kezdeti utasítások vagy kérések írása
  3. Azonosítsa a tartomány szakértőit vagy tesztelőit, akik reprezentatív példákat és korai visszajelzéseket adhatnak
  4. Automatizált bírák létrehozása, amelyek az értékelési kritériumokat kódolják és felgyorsítják az iterációt

Ebben a szakaszban nincs szükség tökéletes világosságra, és a megértése az iteráláskor javulni fog. Az erősebb korai igazítás, különösen arra, hogyan mérjük a minőséget, és mit jelent az, hogy "gyártásra kész", jelentősen felgyorsítja a későbbi minőségi fejlesztéseket és a végső jóváhagyást.

2. Kezdeti ügynök létrehozása

Miután a felhasználási esete és céljai egyértelműen meghatározottak, készen áll arra, hogy elkészítse az ügynök prototípusát. A Databricks egyaránt biztosít irányított, felhasználói felületalapú útvonalakat és teljesen egyéni, kódalapú útvonalakat az ügynökök létrehozásához.

2.1. Adatok és eszközök előkészítése

Az ügynökök általában adatokkal és eszközökkel biztosítják a kontextust és a képességeket. Az MCP-k és ügynök eszközök áttekintéséért lásd az adatokkal való munkavégzést és az eszközöket a Databricks-en.

Új adatok és eszközök létrehozása előtt keressen rá a meglévő adatokra és eszközökre:

Szükség szerint hozzon létre és kezelje az új eszközöket:

Ezen adategységek és eszközök mindegyike a Unity Katalógusban van szabályozva és verziószámozva, így az ügynökök és alkalmazások között felderíthetőek és újrafelhasználhatók.

2.2. Kezdeti ügynök létrehozása

Egyéni ügynök létrehozása előtt mérje fel, hogy egy deklaratív Knowledge Assistant-ügynök , AI-függvény vagy meglévő Databricks-megoldásgyorsító már megfelel-e a használati esetnek. A gyakori minták esetében ezek az irányított megközelítések jelentősen csökkenthetik a beállítást, javíthatják az alapértelmezett minőséget és az éles üzemidőt.

Ha továbbra is szükség van egy egyéni ügynökre, az új építőknek a leggyorsabb kísérletezéssel kell kezdenie. Az AI Playground használatával kódírás nélkül prototípust hozhat létre egy ügynököt . Az AI Playground lehetővé teszi a különböző modellek kipróbálását, a gyors tervezést és a tesztelési eszközöket az adatok minőségének, az ügynökök viselkedésének és a megközelítésben rejlő lehetőségek gyors megértéséhez. Ezután kódként exportálhatja az ügynököt a további testreszabáshoz és iterációhoz.

Ha már rendelkezik ügynökkóddal, a meglévő kódot beviheti a Databricksbe, és databricks-alkalmazásként telepítheti.

Az ügynök/bot felépítése során tervezze meg előre az értékelést és a gyártást:

  • Instrumentálja ügynökét MLflow Tracing használatával az ügynök viselkedésének rögzítésére és elemzésére.
    • Ebben a szakaszban helyezze a hangsúlyt a funkcionális helyességre: győződjön meg arról, hogy az ügynök végponttól végpontig működik, és hozzáfér a szükséges adatokhoz és eszközökhöz.
    • Ellenőrizze a korai problémákat, például a helytelen eszközválasztást, a hiányzó környezetet vagy a hallucinációkat.
    • Később ezeket a nyomkövetéseket használjuk az ügynök minőségének kiértékeléséhez.
  • A megvalósítás során fontolja meg az éles alkalmazás megfelelő hitelesítési módszerét.

3. Iterátum az ügynök minőségéről

Miután létezik egy működő prototípus, a következő fázis a mérés, a megértés és a minőség javítása szoros ciklusa. A Databricks az MLflow Evaluation-et helyezi a hurok középpontjába, amelyet az MLflow Tracing, a kiértékelési adathalmazok és az LLM-bírák támogatnak.

Az automatizált pontozók és az LLM-bírák skálázást és konzisztenciát biztosítanak, de az emberi visszajelzések kritikus fontosságúak a valós hasznosság ellenőrzéséhez és a finom hibák megértéséhez. Az emberi visszajelzések az LLM-bírák fejlesztését és kalibrálását is irányítja. Az emberi visszajelzés általában három szakaszban jelenik meg, ahogy az ügynök fejlődik.

  1. Korai fejlesztői és érdekelt felek ellenőrzése
  2. Szélesebb szakterületi szakértők áttekintése
  3. Végfelhasználói visszajelzés

3.1. Korai viselkedés ellenőrzése

A fejlesztők és az érdekelt felek vagy tartományi szakértők egy kis csoportja gyors, korai visszajelzést nyújthat. A tesztelés és a kiértékelés skálázása előtt győződjön meg arról, hogy az ügynök a legnyilvánvalóbb helyzetekben helyesen jár el.

A prototípus-készítés során a fejlesztők gyakran közvetlen "hangulatfelmérést" hajtanak végre az ügynök manuális lekérdezésével, hogy meggyőződjenek arról, hogy elejétől a végéig fut, és a várt módon viselkedik. Az MLflow Tracing felhasználói felületén a fejlesztők közvetlenül csatolhatnak visszajelzéseket vagy elvárásokat a minőségi problémák megjelöléséhez, a sikeres példák megjelöléséhez, valamint jegyzetek rögzítéséhez a jövőbeli értékeléshez és iterációhoz.

Miután üzembe helyez egy belső prototípust, a Review App Chat felhasználói felülete egyszerű felhasználói felületet biztosít a visszajelzések gyűjtéséhez. Ossza meg a prototípus csevegőfelületét fejlesztők vagy tartományi szakértők egy kis csoportjával, akik ésszerű és problémás lekérdezéseket is kérhetnek.

Az MLflow Tracing rögzíti az interakciókat és a visszajelzéseket az eredmények kezdeti adatkészletének létrehozásához. Elemezze a nyomkövetéseket az MLflow felhasználói felületével vagy kódjával az ügynök teljesítményének és viselkedésének megértéséhez. Ha az eredmények rosszak vagy váratlanok, a nyomkövetésekkel hibakeresést végezhet:

  • Elemezze az ügynökkel kapcsolatos minőségi problémákat, például az eszközök helytelen használatát, a hallucinációkat vagy a hiányzó kontextust. Alkalmazza a javításokat, például a gyorshangolást, az eszközhasználatot vagy az adatokat. Lásd : 3.4. Javítsa ki a problémákat, és ellenőrizze újra a fejlesztéseket.
  • Az iterálás során a nyomkövetési adatkészletet használhatja reprezentatív felhasználói bemenetként az új prototípus nyomkövetési adatainak létrehozásához.
  • Ismételje meg ezt a ciklust: futtassa, vizsgálja meg, javítsa ki és futtassa újra, amíg az ügynök a várt módon nem kezeli az összes vagy a legtöbb reprezentatív bemenetet.
  • A későbbi iterációkban további problémák merülhetnek fel és kezelhetők. A minőség javítása iteratív, és nem korlátozódik erre a korai fázisra.

A lépés után biztos lehet abban, hogy a prototípus érzékelhetően viselkedik a gyakori esetekben, és ésszerű minőségi szintet ér el, mielőtt részletesebb tesztelésbe fektet.

3.2. Tesztelés és visszajelzés bővítése

Miután a prototípus egyszerű esetekben működik, skálázza fel a minőségértékelést a bétatesztelők szélesítésével és a testre szabott visszajelzések gyűjtésével. Ez a fázis olyan vakfoltokat mutat be, mint a váratlan témakörök, a félreértett lekérdezések, az eszközök és a lekérési rések, vagy az újonnan megjelenő használati minták. Emellett kibővíti a kiértékelési adatkészleteket is.

3.3. Minőség értékelése és hibakeresés szisztematikusan

Ahogy a kiértékelési adathalmazok egyre nagyobbak és változatosabbak lesznek, strukturáltabb és automatizáltabb módszerekre lesz szüksége a problémák észleléséhez, a legfontosabb hibák felszínre hozásához és a kiváltó okok megértéséhez.

A gyakorlatban valószínűleg kétféle kiértékelési adatkészletre oszthatja az adatokat:

  • Regressziós tesztelés: A jó minőségű AI-válaszokkal rendelkező adatok segítenek meghatározni a várt viselkedést. Ezekkel az adatkészletekkel ellenőrizheti, hogy az ügynök új verziói továbbra is jól teljesítenek-e a várt forgatókönyvek széles és változatos halmazában.
  • Problémaközpontú hibakeresés: Az alacsony minőségű AI-válaszokat tartalmazó adatok számos nemkívánatos viselkedést tartalmazhatnak. Elkülönítheti azokat a nyomkövetési csoportokat, amelyek ugyanolyan típusú alacsony minőségű viselkedést mutatnak, így megértheti a kiváltó okokat, és iterálhatja a célzott javításokat.

Az alábbi eszközök segítenek a kiértékelési adathalmazok mindkét típusának összeállításában és elemzésében.

Regressziós tesztek futtatása

  • Regressziós teszteket készíthet olyan adatok reprezentatív részhalmazainak kiválasztásával, amelyekre kiváló minőségű AI-válaszokkal vagy emberi elvárásokkal rendelkezik.
  • Értékelési kritériumok meghatározása beépített vagy egyéni LLM-bírák és pontozók használatával. Az automatizált kiértékelés önállóan használhatja az LLM-eket a válaszminőség értékeléséhez, vagy összehasonlíthatják a válaszokat az alapigaz válaszokkal vagy az elvárásokkal.
  • Végezze el az értékelést az ügynök új verzióin, hogy a frissítések ne ronthassák a korábban jó működést.

A gyenge minőségű válaszok típusainak azonosítása

Az automatikus észlelés pontosságának javítása

Bár a kiértékelési adatkészleteket többnyire emberi visszajelzések használatával kezdheti el létrehozni, a kiértékelést automatizált észleléssel skálázhatja. Az iteráció során az alkalmazáshoz és a tartományhoz szabott LLM-bírákba vagy kódalapú pontszámkezelőkbe fektethet be.

  • Kezdje a beépített bírókkal, és szükség szerint vegyen fel egyéni bírákat és kódalapú pontszámokat . Ha egy beépített bíró által nem rögzített hibamódot észlel, automatizálhatja a jövőbeli észlelést egy egyéni bíróval vagy pontozóval, amely az adott hibatípus észlelésére lett kialakítva.
  • Emberi visszajelzések használatával igazíthatja az egyéni bírákat a szakértői ismeretekhez. A bíráknak a hamis pozitív és negatív értékek csökkentésére való hangolása növeli az automatizált értékelés és osztályozás iránti bizalmat.
  • Az új bírák és pontozók egyaránt használhatók az automatikus értékeléshez és monitorozáshoz, valamint a nyomkövetések szűréséhez, hogy adathalmazokat építsenek ki a hibakereséshez.

Hatékonyan kezelje a kiváltó okok problémáit

A hiba azonosítása után meg kell határoznia, hogy miért történt.

  • Az MLflow Tracing használatával manuálisan vizsgálhatja meg az ügynök érvelésének minden lépését:
    • Mely eszközök lettek kiválasztva
    • Eszközbemenetek és -kimenetek használata
    • Azt jelzi, hogy a lekérés releváns környezetet adott-e vissza
    • Hogyan befolyásolták a modellválaszok az alsóbb rétegbeli döntéseket?
  • Az MLflow AI-elemzések vagy az ügynök mint bíró segítségével elemezheti a nyomkövetéseket, és olyan valószínű okokra mutathat, mint például a gyenge alapozás, a rossz utasításszerkezet vagy a helytelen parancsérvek.
  • Hasonlítsa össze az MLflow kiértékelési felhasználói felületén található verziókat, és ellenőrizze, hogy a problémák regressziós vagy az iterációk között megmaradnak-e.

Ennek a lépésnek az ideális eredménye az, hogy strukturált ismereteket szerzünk arról, hogy mi a sikertelen, miért hiúsul meg, és hogyan javítható ki. Az automatizálás és az alkalmazás-specifikus értékelők lehetővé teszik, hogy magabiztosan iteráljon, miközben az ügynöke egyre képesebbé válik, és a tesztkészlet egyre bonyolultabb lesz.

3.4. Problémák elhárítása és a fejlesztések ismételt ellenőrzése

Ahogyan a problémák alkalmazásspecifikusak, a javításokat az alkalmazáshoz kell igazítani. Gyakori javítások például a következők:

  • Gyors optimalizálás: Pontosítsa manuálisan az ügynök utasításait, vagy használjon adatvezérelt gyorsoptimalizálást. Az ügynökök szélesebb körű optimalizálásához, például a többlépéses érvelés vagy az eszközhasználat finomhangolásához használja a DSPy finomhangolását.
  • Eszközök és adatok: Az eszközök és a lekérési folyamatok javítása, ha a nyomkövetések hiányzó tényeket vagy rossz földelést mutatnak.
  • Útválasztás: Ha a nyomkövetések rossz eszközöket vagy alügynököket mutatnak, javítsa az eszköz vagy ügynök metaadatait, a kéréseket vagy az útválasztási modellt.
  • Védőkorlátok: Ha a válaszok megsértik a biztonsági szabályokat vagy a szivárgási információkat, használjon AI Gateway-védőkorlátokat vagy testre szabott védőkorlátokat az ügynökében.
  • Tartalékok: A szélsőséges esetek, hiányzó adatok vagy API-híváshibák kezelése kecsesen, tartalék mechanizmusok, például alternatív API-végpontok vagy tartalék válaszok használatával.

A javítások iterálása során a Parancssori beállításjegyzék használatával rögzítheti a verziókat az egyszerűbb összehasonlításokhoz és a regressziós teszteléshez.

Az ügynök utasításait, adatlekérdezéseit, eszközeit, adatait vagy egyéb részeit érintő javításokat ugyanazzal a módszerrel kell ellenőrizni, amellyel azokat felfedezték. Futtassa újra az új ügynökverziót ugyanazon a kiértékelési adatkészleten, hogy meggyőződjön arról, hogy a probléma ki lett javítva, és nem vezettek be regressziókat.

4. Egyeztetni az érdekelt felekkel a gyártás előtt

Mielőtt egy ügynök valós környezetbe kerül, a csapatoknak közösen kell megismernie az aktuális képességeit, korlátait és mért minőségét. Ehhez a ponthoz általában több iteráció és minőségjavítás szükséges a 3. lépésben. Ebben a szakaszban a technikai jeleket (például kiértékelési metrikákat, rendszermetrikákat és példákat) lefordíthatja az üzleti környezetbe, amely végső soron meghatározza, hogy az ügynök valóban "készen áll-e".

  • A kiértékelési eredményeket fordítsa le világos üzleti jelzésekké: Foglalja össze a pontosságot, a stabilitást, a biztonságot, valamint az ismert korlátokat a szereplők számára, akik ezekre tudnak reagálni.
  • Ellenőrizze, hogy teljesülnek-e a szabványosított minőségi ellenőrzések: Győződjön meg arról, hogy a szükséges értékelési metrikák, regressziós ellenőrzések és adatkészlet-lefedettségi küszöbértékek teljesülnek a jelölt verzióhoz.
  • A működési készültség ellenőrzése és a jóváhagyás megszerzése: Tekintse át a figyelési beállításokat, a védőkorlátokat és a bevezetési tervet. Dokumentálja a kockázatokat és az elfogadási kritériumokat a gyártás előtt.

5. Élesítés és a minőség folyamatos figyelése

A termelés elérése jelentős mérföldkő! Ez azt jelenti, hogy az ügynök készen áll a valós felhasználókra és a tényleges hatásra. Ugyanakkor a termelés is egy új ciklus kezdete. Az ügynök élő állapotba kerülése után folyamatos figyelést és fejlesztést kap, mivel a valós használat új viselkedéseket, peremes eseteket és problémákat fog felszínre hozni.

  • Visszajelzések gyűjtése végfelhasználóktól a termelési környezetben. Felhasználói visszajelzések összekapcsolása adott nyomkövetésekkel, hogy a modell viselkedése mellett elemezhető legyen. Ezt úgy teheti meg, hogy az eredeti nyomkövetéshez csatolt értékelésekként rögzíti a visszajelzést.
  • Használja ki az AI-átjárót a védőkorlátokhoz, az útválasztáshoz és a konzisztens naplózáshoz. Győződjön meg arról, hogy minden új ügynökverzió valós forgalommal értékelhető működési súrlódás nélkül.
  • Az élő forgalom minőségének figyelése mintavételezett gyártási nyomkövetéseken végzett értékelés futtatásával. Győződjön meg arról, hogy az új verzió legalább a korábbi verziókhoz hasonlóan működik, és keressen új problémákat, amikor a felhasználók új típusú lekérdezéseket küldenek. A folyamatos monitorozás az ügynököt folyamatosan megbízhatóan, biztonságosan és az üzleti igényeknek megfelelően tartja, ahogy fejlődik. Az MLflow monitorozási irányítópultot biztosít, de mivel a nyomkövetések a Unity Katalógusban tárolhatók, testre szabhatja az irányítópultokat és a riasztásokat:
  • Hajts végre intézkedéseket a termelési betekintések alapján:
    • Magas kockázatú használati esetek esetén kapcsolja össze a monitorozást az automatizált vagy feltételes visszaállítási mechanizmusokkal a kritikus problémák megoldásának érdekében.
    • Használja fel gyártási ismereteit a következő iteráció során. Alakítsa át a valós hibákat új kiértékelési adatokká, és térjen vissza a kiértékelési és hibakeresési ciklushoz az ügynök következő, jobb verziójának létrehozásához.

További erőforrások

  • Last updated on