Prompttervezés céges feladathoz: követelmények és példák

Kiinduló helyzet és döntési feladat

Egy munkatárs ügyféllevelekből rövid összefoglalót készít. Ha a leírás csak annyi, hogy legyen profi, a kimenet nehezen mérhető. Konkrét mezők és jó példák mellett könnyebb felismerni a hibát.

Feladat

Nevezd meg a szükséges műveletet és az elvárt felhasználást. A homályos cél változó eredményt hoz.

Írd le, ki használja fel a kimenetet. Az ellenőrzés fő kérdése: Milyen döntéshez kell az összefoglaló?

Adathatár

Jelezd, mely bemeneti információ tekinthető forrásnak és mit nem szabad kitalálni. A modell hiányzó adatot pótolhat feltételezéssel.

Próbálj ki információszegény bemenetet. Az ellenőrzés fő kérdése: Mi történjen, ha nincs válasz a forrásban?

Kimeneti szerkezet

Definiáld a mezőket, sorrendet és megengedett értékeket. A szép formázás nem garantál gépi feldolgozhatóságot.

Ellenőrizd a kimenetet sémával, ahol indokolt. Az ellenőrzés fő kérdése: Minden szükséges adat egyértelmű helyre kerül?

Példák

Adj valóságos, anonimizált jó és hibás mintát magyarázattal. Egyetlen ideális példa nem fedi a kivételeket.

Válassz rövid, hosszú és ellentmondó esetet. Az ellenőrzés fő kérdése: Melyik különbség tanítja a fontos szabályt?

Határhelyzet

Írd le az elutasítás, visszakérdezés és emberi átadás feltételét. A mindenáron válaszadás hibás biztonságérzetet ad.

Adj tiltott vagy értelmezhetetlen feladatot. Az ellenőrzés fő kérdése: Megfelelően áll meg a folyamat?

Verziózás

A leírást, példát és teszteredményt együtt őrizd meg. A változó prompt mellett nem követhető a minőség.

Módosítás után futtasd ugyanazt a tesztkészletet. Az ellenőrzés fő kérdése: Javult a célzott hiba más funkció romlása nélkül?

Részletes megvalósítás és szakmai döntések

A céges promptot követelményként kezeld, ne szerencsésen hangzó mondatgyűjteményként. Egy kolléga számára is akkor világos a feladat, ha tudja a célt, forrást, kimenetet és korlátot. A modellnek adott leírásnál ugyanez hasznos, de az eredményt továbbra is tesztelni kell. A jó megfogalmazás nem garantál hibamentes működést. A munkafolyamatnak kell gondoskodnia arról, hogy a bizonytalan vagy következményes kimenet megfelelő ellenőrzést kapjon, és a hibákból követhető javítás szülessen a későbbi verziókhoz.

Kezdd azzal, ki használja fel a kimenetet. Más összegzés kell az ügyfélkapcsolati munkatársnak, a fejlesztőnek és a vezetőnek. Az előbbi következő kérdést keres, a második konkrét technikai környezetet, a harmadik rövid döntési képet. A legyen profi utasítás nem mondja meg e különbséget. Írd le a felhasználási helyzetet és azt, mely részlet kötelező. Ha a kimenet egy másik rendszer mezőibe kerül, a formátumot és megengedett értéket is meg kell határozni, nem elegendő a kellemes olvashatóságot kérni a feladatleírásban.

A forráshatárt egyértelműen nevezd meg. A modell a megadott levélből dolgozzon, saját dokumentációt is használhat, vagy általános magyarázat készítése a cél? E különbség nélkül a hiányzó adatot könnyen kitöltheti valamilyen valószínűnek tűnő tartalom. Az ügyfélösszefoglaló példájában külön kérd az ismeretlen mező megőrzését. A feltételezés ne jelenjen meg megadott tényként. A tesztbemenetben szándékosan hagyj ki fontos információt, és nézd meg, hogy a rendszer valóban jelzi-e a hiányt. A szabály akkor értékes, ha a nehéz helyzetben is ellenőrizhetően működik.

A kimeneti szerkezet a feldolgozást segítse. Például legyen külön mező az igénynek, ismert feltételnek, nyitott kérdésnek és emberi ellenőrzést igénylő állításnak. A mezők jelentése röviden definiált legyen. Az üres, ismeretlen és nem alkalmazható állapotot ne keverd össze, ha a következő rendszer számára számít a különbség. A technikai formátumot alkalmazási ellenőrzés is vizsgálhatja. A szabályos struktúra nem bizonyít tartalmi helyességet, de kiszűrhet olyan hibát, amely egyébként csak később, más rendszerben okozna elakadást vagy félreértelmezett adatot.

A példák a fontos különbséget mutassák meg. Egy jó mintát érdemes hibás vagy határhelyzeti esettel párosítani, rövid indoklással. Ha csak ideális, tisztán megfogalmazott bemenet szerepel, az üzemi levélzaj és hiányosság rejtve marad. A példák legyenek anonimizáltak vagy világosan szemléltetők. Ne másolj be felesleges személyes adatot a promptba csak azért, mert a valós levélben szerepelt. A céges feladat minőségét a szükséges tartalmi jellegzetesség tanítja, nem az ügyfélazonosító vagy teljes kapcsolattörténet megőrzése a tesztanyagban és fejlesztői felületen.

A bizonytalanságkezelést konkrét viselkedéssel írd le. Mikor kérdezzen vissza, mikor hagyjon mezőt ismeretlenül és mikor adja át embernek az ügyet? A ne hibázz felszólítás nem helyettesíti ezt. Ha a bemenet egymásnak ellentmondó határidőt tartalmaz, a rendszer jelölje az ellentmondást, ne válasszon önkényesen. Ha tiltott adatlekérést kér a forrásban szereplő szöveg, az ne váljon jogos utasítássá. A prompt mellett alkalmazási jogosultság és megfelelő adatkezelés is szükséges, mert a leírás nem lehet az egyetlen határ a következményes műveletek előtt.

A tesztkészletet a prompttal együtt gondozd. Minden fontos módosításhoz tartozzon ismert bemenet és értékelés. Ha egy új mondat javítja a rövid levelek összegzését, nézd meg, nem rontja-e a hosszú, több témájú esetet. Az egyszeri kipróbálás kevés, mert a nyelvi kimenet változhat. A kritikus hibáknál külön figyelj a megfelelő megállásra és átadásra. A teszteredményben legyen megkülönböztethető a formai, tartalmi és biztonsági probléma. Ebből a következő javítás célja is pontosabb lesz, mint általános jobb promptot kérni a fejlesztőtől.

A verziózás megmutatja, mi változott. Őrizd meg a leírást, példákat, szükséges beállításokat és a tesztfuttatás eredményét. Ha a modell vagy külső adatforrás módosul, az is befolyásolhatja a működést, ezért ne csak a prompt szövegét nézd. A munkatárs lássa, melyik változat van üzemben és hogyan lehet visszatérni a korábbihoz. A prompt nem személyes jegyzetfüzetben tárolt titkos tudás, hanem a vállalkozás rendszerének karbantartandó része. E szemlélet különösen fontos, amikor több ember fejleszti vagy üzemelteti ugyanazt a munkafolyamatot.

Az átadáskor egy rövid használati útmutató mondja el a támogatott bemenetet, elvárt kimenetet és ismert korlátot. A felhasználó tudja, mire figyeljen az ellenőrzéskor és hova jelezzen hibát. Az új probléma ne csak szóban maradjon, hanem kerüljön a tesztanyagba megfelelő adatkezeléssel. A prompttervezés így folyamatos minőségmunka lesz. Nem egyetlen tökéletes mondat megtalálásáról szól, hanem a feladat egyre pontosabb leírásáról és a valós működésből származó bizonyíték rendszeres visszavezetéséről a következő változatba.

Gyakori kérdések