Ügynökrendszer tervezési mintái

Az ügynökrendszer létrehozása magában foglalja az LLM-hívások, az adatlekérés és a külső műveletek együttes áramlásának vezénylését. Az ügynökrendszerek tervezési mintái az összetettség és az önállóság kontinuumán alapulnak: determinisztikus láncoktól, együgynökös rendszerekig, amelyek dinamikus döntéseket hozhatnak (és több LLM-hívást is tartalmazhatnak a motorháztető alatt), akár többügynökös architektúrákig, amelyek több specializált ügynököt koordinálnak.

Eszköz meghívása

Mielőtt belemerülnénk a tervezési mintákba, fontos megérteni az eszközhívást, mint alapvető képességet, amely bármely ügynökrendszerben használható, az egyszerűtől az összetettig. Az eszközhívás olyan mechanizmus, amely lehetővé teszi, hogy az ügynökrendszer külső függvényekkel, adatforrásokkal vagy szolgáltatásokkal kommunikáljon. Ez a következőt teheti lehetővé:

• Élő adatkeresések, például SQL-lekérdezések, CRM-lekérések vagy vektorindex-lekérések.
• Műveletek, például e-mail küldése vagy rekord frissítése.
• Tetszőleges logika vagy átalakítások Python-függvényekkel vagy API-kkal.

Az eszközhívás így hatékony mechanizmust biztosít arra, hogy az LLM-ek "tudatában" legyenek a külső adatoknak vagy API-knak, függetlenül attól, hogy melyik tervezési mintát választja.

Az ügynökeszközökkel kapcsolatos további információkért lásd AI-ügynökeszközök.

Az alábbi szakaszok három ügynökrendszer-tervezési mintát mutatnak be, amelyek mindegyike különböző mértékben használhatja az eszközhívást.

Az AI-alkalmazások tervezési mintáinak összehasonlítása

A Gen AI-alkalmazás (ügynök) tervezési mintái összetettségi sorrendben jelennek meg.

Tervezési minta	Mikor érdemes használni?	Előnyök	Hátránya
determinisztikus lánc	Jól definiált feladatok Statikus csővezetékek, például alapszintű RAG Nincs szükség menet közbeni döntésekre	Nagyon egyszerű Könnyen auditálható	Rugalmatlan Kódmódosításokat igényel az alkalmazkodáshoz
Együgynökös rendszer	Közepes vagy összetett lekérdezések ugyanabban a tartományban Néhány dinamikus döntés több specializált ügynök terhelése nélkül.	Hajlékony Egyszerűbb, mint a több ügynökös rendszer Jó "alapértelmezett"	Kevésbé kiszámítható Óvatosan figyelni kell az ismétlődő vagy helytelen eszközhívások ellen
Többügynökös rendszer	Nagy vagy keresztfunkcionális tartományok; több "szakértő" ügynök; különböző logikai vagy beszélgetési környezetek; speciális tükröződési minták.	Rendkívül moduláris Skálázás nagy tartományokra	Nehezen koordinálható Nehezebb nyomon követni és hibakeresést végezni

együgynök rendszer

Az együgynök-rendszer egyetlen összehangolt logikai folyamatot tartalmaz – gyakran több LLM-hívás vezénylésével – a bejövő kérések kezeléséhez. Az ügynök:

1. Fogadja el a kéréseket, például a felhasználói lekérdezéseket és minden releváns környezetet, például a beszélgetési előzményeket.
2. A válasz legjobb módjának indoka, opcionálisan annak eldöntése, hogy külső adatokhoz vagy műveletekhez kell-e eszközöket hívni.
3. Szükség esetén iteráljon, hívjon meg egy LLM-et (és/vagy ugyanazokat az eszközöket) többször, amíg el nem éri a célkitűzést, vagy egy bizonyos feltétel teljesül (például érvényes adatok fogadása vagy hiba megoldása).
4. Eszközkimenetek integrálása a beszélgetésbe.
5. Egy összetartó választ ad vissza kimenetként.

Sok használati esetben elegendő az LLM-érvelés egyetlen köre (gyakran eszközhívással). A fejlettebb ügynökök azonban több lépésben is végighaladhatnak, amíg el nem érik a kívánt eredményt.

Annak ellenére, hogy csak egy ügynök van, továbbra is lehet több LLM- és eszközhívás a felszín alatt (tervezéshez, létrehozáshoz, ellenőrzéshez stb.), mindezt egy egységes folyamat felügyeli.

Példa: Ügyfélszolgálati asszisztens

• Ha a felhasználó egy egyszerű kérdést tesz fel ("Mi a visszatérési szabályzatunk?"), az ügynök közvetlenül az LLM tudomása alapján válaszolhat.
• Ha a felhasználó a rendelés állapotát szeretné, az ügynök meghív egy függvényt lookup_order(customer_id, order_id). Ha az eszköz "érvénytelen rendelésszámmal" válaszol, előfordulhat, hogy az ügynök újrapróbálkozza vagy megkéri a felhasználót a megfelelő azonosító megadására, egészen addig, amíg meg nem adja a végső választ.

Mikor érdemes használni:

• Változatos felhasználói lekérdezéseket vár, de továbbra is egy összetartó tartományon vagy termékterületen belül.
• Bizonyos lekérdezések vagy feltételek szükségessé tehetik az eszközök használatát, például eldönthetik, hogy mikor kell beolvasni az ügyféladatokat.
• Nagyobb rugalmasságot szeretne, mint egy determinisztikus lánc, de nem igényel külön speciális ügynököket a különböző feladatokhoz.

előnyei:

• Az ügynök az új vagy váratlan lekérdezésekhez úgy tud alkalmazkodni, hogy kiválasztja a meghívandó (ha van) eszközöket.
• Az ügynök többszöri LLM-hívásokkal vagy eszközhívásokkal finomíthatja az eredményeket anélkül, hogy teljes mértékben többügynököt kellene beállítania.
• Ez a tervezési minta gyakran ideális a nagyvállalati használati esetekhez – egyszerűbb hibakeresést tesz lehetővé, mint a több ügynökös megoldások, miközben továbbra is lehetővé teszi a dinamikus logikát és a korlátozott önállóságot.

szempontok:

• Fixen kódolt lánchoz képest védenie kell az ismétlődő vagy érvénytelen eszközhívások ellen. (Végtelen ciklusok bármilyen eszközhívási forgatókönyvben előfordulhatnak, ezért állítsa be az iterációs korlátokat vagy az időtúllépéseket.)
• Ha az alkalmazás gyökeresen különböző altartományokra (pénzügy, devops, marketing stb.) terjed ki, előfordulhat, hogy egyetlen ügynök nem megfelelő, vagy túlterheli a funkcionalitás követelményeit.
• Az ügynök koncentrált és releváns maradásához továbbra is gondosan megtervezett kérésekre és korlátozásokra van szüksége.

determinisztikus lánc (szigorúan kódolt lépések)

Ebben a mintában a fejlesztő határozza meg, hogy mely összetevőket hívja meg, milyen sorrendben és milyen paraméterekkel. Nincs dinamikus döntéshozatal arról, mely eszközöket meghívni, vagy milyen sorrendben. A rendszer egy előre definiált munkafolyamatot követ az összes kéréshez, így rendkívül kiszámítható.

A "Láncnak" nevezett folyamat lényegében rögzített lépéslánc, például:

1. Mindig kérje le a felhasználó kérését, és kérjen le egy vektorindexből a releváns környezethez.
2. Kombinálja ezt a környezetet a felhasználó kérésével egy végleges LLM-parancssorba.
3. Hívja meg az LLM-et, és adja vissza a választ.

Példa: Alapszintű RAG-lánc

Egy determinisztikus RAG-lánc talán mindig:

1. Lekérheti a legjobb k találatokat egy vektorindexből egy bejövő felhasználói kérés alapján.
2. A beolvasott adatrészek rendezése egy parancssori sablonba kiegészítés céljából.
3. Adja át ezt a bővített utasítást az LLM-nek (generálás céljából).
4. Adja vissza az LLM által adott választ.

Mikor érdemes használni:

• Előrejelezhető munkafolyamatokkal rendelkező, jól definiált feladatokhoz.
• Amikor a konzisztencia és a naplózás a legfontosabb prioritás.
• Ha szeretné minimalizálni a késést azáltal, hogy elkerüli a vezénylési döntésekhez kapcsolódó több LLM-hívást.

előnyei:

• A legnagyobb kiszámíthatóság és auditálhatóság.
• Általában kisebb a késés (kevesebb LLM-hívás vezénylésre).
• Egyszerűbb tesztelés és ellenőrzés.

szempontok:

• Korlátozott rugalmasság a különböző vagy váratlan kérések kezeléséhez.
• A logikai ágak növekedésének következtében összetettsé és nehezen karbantarthatóvá válhat.
• Az új képességekhez jelentős újrabontásra lehet szükség.

többügynök rendszer

A többügynök-rendszer két vagy több speciális ügynököt foglal magában, amelyek üzeneteket cserélnek, és/vagy együttműködnek a feladatokon. Minden ügynök saját tartomány- vagy feladat-szakértelemmel, környezettel és potenciálisan eltérő eszközkészletekkel rendelkezik. Egy külön "koordinátor" – amely lehet egy másik LLM vagy szabályalapú útválasztó – a megfelelő ügynökhöz irányítja a kéréseket, vagy eldönti, hogy mikor adja át a feladatot az egyik ügynöktől a másiknak.

Példa: Vállalati asszisztens speciális ügynökökkel

• ügyfélszolgálati ügynök: KEZELI a CRM-kereséseket, a visszaküldéseket és a szállítást.
• Analytics-ügynök: AZ SQL-lekérdezésekre és az adatok összegzésére összpontosít.
• felügyelő/útválasztó: Kiválasztja, hogy melyik ügynök a legjobb egy adott felhasználói lekérdezéshez, vagy mikor váltson.

Minden alügynök képes eszközhívást végezni a saját tartományán belül (például lookup_customer_account vagy run_sql_query) gyakran egyedi kéréseket vagy beszélgetési előzményeket igényel.

Mikor érdemes használni:

• Önnek vannak egyértelműen meghatározott problématerületei vagy képességcsoportjai, mint például a kódolási készségek vagy a pénzügyi képességek.
• Minden ügynöknek hozzá kell férnie a beszélgetési előzményekhez vagy a tartományspecifikus kérésekhez.
• Annyi eszköze van, hogy mindet egyetlen ügynök sémájába illeszteni nem praktikus; minden ügynök birtokolhat egy részhalmazt belőle.
• Tükrözést, kritikát vagy oda-vissza együttműködést szeretne megvalósítani a specializált ügynökök között.

előnyei:

• Ez a moduláris megközelítés azt jelenti, hogy az egyes ügynököket külön csapatok fejleszthetik vagy tarthatják karban, szűk tartományra specializálódva.
• Képes kezelni azokat a nagy, összetett vállalati munkafolyamatokat, amelyeket egyetlen ügynök nehezen kezelhet összetartó módon.
• Lehetővé teszi a speciális többlépéses vagy többszempontú érvelést – például egy ügynök választ hoz létre, egy másik pedig ellenőrzi azt.

szempontok:

• Stratégiát igényel az ügynökök közötti útválasztáshoz, valamint többletterhelést a naplózás, a nyomkövetés és a hibakeresés több végponton történő végrehajtásához.
• Ha sok alügynökkel és eszközzel rendelkezik, bonyolult lehet eldönteni, hogy melyik ügynök rendelkezik hozzáféréssel az adatokhoz vagy API-khoz.
• Az ügynökök feladatokat adhatnak át egymásnak határozatlan ideig megoldás nélkül, ha nem korlátozzák őket gondosan.
  • Az együgynökös eszközhívásban is fennállnak végtelen hurokkockázatok, de a többügynök-beállítás további hibakeresési összetettségi réteget ad hozzá.

Gyakorlati tanácsok

Függetlenül attól, hogy melyik tervezési mintát választja, fontolja meg a következő ajánlott eljárásokat a stabil, karbantartható ügynökrendszerek fejlesztéséhez.

1. Egyszerű kezdés: Ha csak egy egyszerű láncra van szüksége, a determinisztikus lánc gyorsan felépíthető.
2. Fokozatosan adja hozzá a bonyolultságot: Mivel dinamikusabb lekérdezésekre vagy rugalmas adatforrásra van szüksége, váltson egy együgynökös rendszerre eszközhívással.
3. Vegyünk fel több ügynököt: Csak akkor, ha egyértelműen eltérő feladatkörökkel vagy feladatokkal, több beszélgetési kontextussal rendelkezik, vagy egy olyan eszközkészlet van a birtokában, amely túl nagy egyetlen ügynök kéréséhez.

Ha a használati eset kicsi – például egy egyszerű RAG-lánc – egy kemény kódolt lánccal kezdődik. A követelmények fejlődésével eszközhívási logikát adhat hozzá a dinamikus döntéshozatalhoz, vagy akár több specializált ügynökbe is szegmentelheti a feladatokat. A gyakorlatban számos valós ügynökrendszer kombinálja a mintákat. Használjon például egy többnyire determinisztikus láncot, de lehetővé teszi, hogy az LLM dinamikusan meghívjon bizonyos API-kat egyetlen lépésben, ha szükséges.

A Mozaik AI-ügynök keretrendszere függetlenül működik a választott mintáktól, így könnyen fejleszthetők a tervezési minták az alkalmazás növekedésével.

Fejlesztési útmutató

• Utasítások
  • Az ellentmondásos utasítások elkerülése, az információk elterelése és a hallucinációk csökkentése érdekében tartsa tisztán és minimálisan a kéréseket.
  • Az ügynökének szükséges eszközöket és kontextust biztosítsa, ahelyett hogy korlátlan számú API-t vagy nagy, irreleváns kontextust kínálna.
• Naplózás & megfigyelhetőség
  • Részletes naplózás implementálása minden felhasználói kéréshez, ügynökcsomaghoz és eszközhíváshoz. Az MLflow Tracing segíthet a strukturált naplók rögzítésében a hibakereséshez.
  • Biztonságosan tárolja a naplókat, és ügyeljen a személyes azonosításra alkalmas adatokra (PII) a beszélgetési adatokban.
• Modellfrissítések & verziórögzítés
  • Az LLM viselkedése változhat, ha a szolgáltatók a színfalak mögött frissítik a modelleket. Használjon verzió-rögzítést és gyakori regressziós teszteket annak érdekében, hogy az ügynöklogika robusztus és stabil maradjon.
  • A MLflow és a Mozaik AI-ügynök kiértékelési kombinálása leegyszerűsíti az ügynökök verziószámozását, és rendszeresen értékeli a minőséget és a teljesítményt.

Tesztelési és iterációs útmutató

• Hibakezelés & tartalék logika
  • Eszköz- vagy LLM-hibákra való felkészülés. Az időtúllépések, a hibásan formázott válaszok vagy az üres eredmények megszakíthatják a munkafolyamatot. A speciális funkciók sikertelensége esetén újrapróbálkozásos stratégiákat, tartalék logikát vagy egyszerűbb tartalékláncot is tartalmazhat.
• Iteratív prompt mérnöki tevékenység
  • Várhatóan idővel pontosítja a parancssorokat és a lánclogikát. Az egyes módosításokat (a Git és az MLflow használatával) verziószámozhatja, így visszaállíthatja vagy összehasonlíthatja a különböző verziók teljesítményét.
  • Fontolja meg az olyan keretrendszereket, mint a DSPy a parancssorok és egyéb összetevők programozott optimalizálásához az ügynökrendszeren belül.

Termelési útmutató

• késés és költségoptimalizálás
  • Minden további LLM- vagy eszközhívás növeli a tokenhasználatot és a válaszidőt. Ha lehet, egyesítse a lépéseket, vagy gyorsítótárazza az ismétlődő lekérdezéseket a teljesítmény és a költségek kezelhető szinten tartása érdekében.
• Biztonsági és tesztkörnyezeti
  • Ha az ügynök képes a rekordok frissítésére vagy a kód futtatására, akkor ezeket a műveleteket tesztkörnyezetbe helyezheti, vagy szükség esetén emberi jóváhagyást kényszeríthet ki. Ez kritikus fontosságú a vállalati vagy szabályozott környezetekben a nem szándékos károk elkerülése érdekében.
  • A Databricks a Unity Catalog eszközeit javasolja a tesztkörnyezetes végrehajtáshoz. Lásd : Az eszköz megközelítésének kiválasztása. A Unity Catalog lehetővé teszi az tetszőleges kódvégrehajtás elkülönítését, és megakadályozza, hogy a rosszindulatú szereplők átvezényelik az ügynököt olyan kód létrehozására és futtatására, amely zavarja vagy lehallgatja a többi kérést.

Az irányelvek követésével enyhítheti a leggyakoribb meghibásodási módokat, például az eszközhibákat, az LLM-teljesítmény eltolódását vagy a váratlan költségnövekedéseket, és megbízhatóbb, méretezhető ügynökrendszereket hozhat létre.