Az MI gyorsabban áttekinthetővé tehet egy támogatási kérést: összefoglalhatja az igényt, felismerheti a hiányzó adatokat és megfelelő engedélyezett útmutatást készíthet elő. A haszon akkor keletkezik, ha ebből jól ellenőrizhető feldolgozási állapot lesz. A válasz elküldése vagy egy módosítás végrehajtása külön döntés.
Első alkalmazásként korlátozott feladatkör javasolt. Az asszisztens például belső hibajegytervezeteket készít, anélkül hogy maga küldene üzeneteket vagy rendszereket módosítana. Így a minőség és az utómunka a tényleges munkafolyamatban értékelhető.
Mit tartalmazzon egy használható javaslat?
A rövid összefoglaló megnevezi a megfigyelt hibát, az érintett munkaeszközöket és az eddigi eseményeket. A feltételezések és a nyitott kérdések ettől elkülönülnek. Ha hiányzik egy időpont, hibaüzenet vagy az akadályoztatás mértéke, azt láthatóvá kell tenni.
A választervezet magyarázza el, milyen információra van még szükség, vagy melyik engedélyezett lépés tűnik észszerűnek. Egy javasolt megoldáshoz követhető alap kell. Egy hasonló hangzású régi hibajegy nem elegendő bizonyíték, ha a környezet vagy az ok eltér.
Példa: „Lassú az alkalmazás”
Az asszisztens kérdéseket készít elő az időpontról, az érintett felhasználókról, a konkrét funkcióról és a hibaüzenetekről. Egyesítheti a hibajegyben már szereplő adatokat, és hivatkozhat egy megfelelő engedélyezett dokumentációs részre.
Nem állítja, hogy már elvégezte a szerver ellenőrzését vagy megerősített egy okot. Technikai intézkedés csak akkor javasolható, ha azt a rendelkezésre álló megállapítások alátámasztják. Ez lehetséges folyamatpélda, nem ügyfélreferencia.
A hibajegyek és dokumentumok jogosultságai továbbra is meghatározók
A támogatási asszisztensnek nem kell automatikusan minden hibajegyhez és minden dokumentációhoz hozzáférnie. A keresés az adott felhasználóra, a megállapodott feladatkörre és a megfelelő objektumokra korlátozódik. Ez a mellékletekre, belső jegyzetekre és más ügyfelek információira is vonatkozik.
A RAG-alapú tudáskeresésnél ezeket a jogokat már a találatok kiválasztásakor figyelembe kell venni. A tiltott tartalom egy később elvetett modellkontextusba sem kerülhet be. A dokumentumhozzáférések műszaki megvalósítása forrásonként eltér; a Microsoft például különböző dokumentumjogosultsági megközelítéseket ismertet az Azure AI Search esetében (külső hivatkozás). Egy egyszerű szűrő csak akkor hatékony, ha az identitást és a szűrőértékeket megbízhatóan határozzák meg.
Több ügyfélkörnyezet kezelésekor az elkülönítésük és az engedélyezett adatfolyamok az integrációs koncepció részei. A tárolt naplókat és tartalmakat a cél és az üzemeltetési igény alapján határozzák meg. A lehető legnagyobb teljes prompttörténet megőrzése nem öncél.
A bejövő tartalom adat, nem munkautasítás
Egy hibajegy tartalmazhat olyan szöveget, amely tiltott műveletre szólítja fel az asszisztenst. Ugyanez érvényes a dokumentumokra, e-mailekre és mellékletekre. Az ilyen tartalom nem változtathatja meg a rendszerszabályokat, és nem nyithat meg további eszközöket vagy hozzáféréseket.
Az alkalmazás ezért szerveroldalon korlátozza, mely források olvashatók és mely funkciók hívhatók meg. Egy modelljavaslat önmagában nem írja felül ezeket a határokat. Meghatározott funkciók bekötéséhez használhatók ellenőrzött MCP-eszközök és meglévő API-k ; az MCP biztonsági dokumentációja (külső hivatkozás) konkrét támadási és védelmi területeket ír le.
Jóváhagyás és végrehajtás két külön lépésként
Az ügyintéző együtt látja az összefoglalót, a forrásokat és a választervezetet. Javíthatja az adatokat, visszakérdezhet vagy elvetheti a javaslatot. A küldés gombnak egyértelműen meg kell mutatnia, melyik üzenet melyik címzettnek megy. A küldés az erre jogosult alkalmazáson keresztül történik.
Technikai módosításoknál további elkülönítés célszerű: egy diagnosztikai javaslat nem válik adminisztrátori megbízássá pusztán attól, hogy hihetően hangzik. A célt, a célrendszert, az engedélyezett hatókört és a szükséges jóváhagyásokat külön ellenőrzik. A nem egyértelmű vagy kockázatos esetek a felelős szakemberhez kerülnek.
A pilothoz több kell egy jó bemutatónál
- Szokásos esetek: Helyesen rögzítik az igényt és a szükséges visszakérdezéseket?
- Hiányzó alap: Felismeri az asszisztens, hogy még nem adható alátámasztott válasz?
- Hibás vagy régi forrás: Ellenőrzik a verziót és a hibajeggyel való tényleges kapcsolatot?
- Jogosultságváltozás: Eltűnnek a tartalmak a keresésből és a kontextusból a hozzáférés visszavonása után?
- Manipulált bemenetek: Megmaradnak az eszközkorlátok és a jóváhagyások?
- Szolgáltatáskiesés: A hibajegy továbbra is a szokásos módon kezelhető?
Az értékelésnek az olvasásra, javításra és ellenőrzésre fordított időt is mérnie kell. Egy hosszú tervezet többletmunkát okozhat. Egy rövid, jól alátámasztott feldolgozási állapot viszont tehermentesíthet, akkor is, ha a végső döntés továbbra is embernél marad.
Az egyedi tervezettől a karbantartható integrációig
A DAXS a támogatással és az IT-val együtt tisztázza a megfelelő kezdőpontot, beköti az engedélyezett adatforrásokat és korlátozott pilotot valósít meg. A meglévő hibajegykezelő rendszert, az identitásokat és a dokumentációt együtt vizsgálják. A hatókör és a bővítés az igazolt haszonhoz igazodik.
Az MI alkalmazási területeinek áttekintése · Bevezetés és használati szabályok · IT a napi üzemeltetésben