Ezen az oldalon
Képzelj el egy termékkatalógust, amely hétfőn megváltozik. Az asszisztens promptjában még a pénteki lista szerepel. A csapat frissíti a promptot. A régi lista másik példánya azonban a modell tanításához használt példákban marad. Az asszisztens egyetlen beszélgetésben ad aktuális és elavult választ.
Ez képzeletbeli hiba, de az oka gyakori: ugyanannak a ténynek több otthona lett.
Egy előadás a promptokról, lekérésről és modellsúlyokról hasznos határvonalat húz. A prompt azt mondja meg, hogyan viselkedjen az asszisztens. A lekérés aktuális, hivatkozható tudást ad egy adott feladathoz. A modell módosítása stabil mintát taníthat. Ha ezt a hármat lépcsőnek tekintjük, ahol a prompt után lekérés, majd minden további hibánál finomhangolás következik, félrediagnosztizáljuk a tényhibákat.
A prompt rossz katalógus
A prompt vonzó, mert könnyen szerkeszthető. Hozzáadsz egy bekezdést, és a következő kérés már tartalmazza. Ez a kényelem két költséget rejt. A tény minden hívással elküldődik, akkor is, ha nem fontos. Nagy promptnál pedig nehezebb megállapítani, hogy a modell egy szabály melyik példányát használta.
Egy tartós utasítás, például „kampány küldése előtt kérj jóváhagyást”, közel maradhat az ügynökhöz. Az áruház jelenlegi egyedi mezőinek listája nem. Megváltozhat, amikor a fiók rendszergazdája attribútumot ad hozzá. Fiókonként eltérhet. Az egyik munkaterület láthatja, a másik nem.
A Brevo-csatlakozóról szóló útmutató megmutatja, miért számítanak a meződefiníciók a kapcsolatok szinkronizálásánál. Ha egy attribútum nincs deklarálva a célfiókban, a neve alapján ésszerűnek tűnő leképezés nem feltétlenül hozza létre a kívánt mezőt. Az ügynök az adott fiók aktuális szerződését nézze meg, ne egy tanításból megmaradt általános mezőlistát idézzen fel.
A hasznos lekért eredmény elég kicsi ahhoz, hogy vitatható legyen. Jelezze, melyik fiókra érvényes, mikor olvasták, és melyik műveletet vagy mezőt írja le. Ha két lekért részlet ellentmond egymásnak, a rendszer mutassa meg az ellentmondást, ne csendben a gördülékenyebbet válassza. A következő helyes lépés lehet friss lekérés vagy felülvizsgálat, nem feltétlenül a prompt erélyesebb megfogalmazása.
A tényt a hatókörével együtt kérd le
A hasznos tudásrekord több mint szöveg. Kell hozzá forrás, verzió vagy lekérési idő, fiókhatár és egyértelmű csere vagy eltávolítási mód. Az egyik kereskedői fiókban megtalált meződefiníció soha nem válhat másik fiók általános szabályává.
Egy kapcsolatattribútumra vonatkozó kérdés így a legkisebb válaszoló részletet kérheti le: a mező nevét, típusát és azt a fiókot, ahol létezik. A válasz visszamutathat a forrásra. Ha a leképezés elbukik, a csapat megkérdezheti, hogy a tény elavult volt-e, rossz fiók eredménye érkezett-e, vagy a modell értett félre egy helyes részletet.
Ezek különböző javítások. A prompt átírása nem javítja a fiókok közötti lekérési szűrőt. A nagyobb modell nem ismerheti azt az attribútumdefiníciót, amelyet senki sem kért le.
Az MCP-ről szóló magyarázat leírja, hogyan kérdezhet eszközöket egy ügynök. Az eszköz a fontos szerződést adja vissza, míg az alkalmazás érvényesíti, ki láthatja. A „ne fedd fel másik fiók adatait” szöveges utasítás nem helyettesíti a fiókra korlátozott lekérdezést.
Ez a felosztás gyorsítja a javítást. Ha egy célmezőt átneveznek, frissítsd a sémaforrást, és érvénytelenítsd az érintett leképezést. Ha az ügynök ismételten félreért egy stabil utasítást, változtasd meg az utasítást, vagy tesztelj célzott tanítást. Ha a válasz azért rossz, mert a lekérő a rossz fiókot választotta, a modell súlyainak javítása nem kezeli az okot. Minden hibaosztályhoz más felelős és javítási út tartozik.
- Tartós utasítás
Hogyan viselkedjen az asszisztens
- Korlátozott lekérés fiók · verzió · idő
Mi igaz most
- Leképezési döntés
Az aktuális tény használata ehhez a feladathoz
- Érvényesített írás
A kód ellenőrzi a jogosultságot és a hatókört
Mintát csak akkor taníts, ha már stabil
Jogos ellenvetés: „Ha egy tényt állandóan használunk, miért ne tanítsuk bele egy kisebb modellbe?” Az ismétlődés önmagában kevés. A ténynek helyesnek kell maradnia két modellfrissítés között, és a modellnek meg kell tudnia különböztetni a kontextusokat.
Egy stabil osztályozási stílus később lehet érdemes a finomhangolásra. A szolgáltató aktuális mezőlistája rossz jelölt. Még ha ritkán változik is, egyetlen elavult válasz ára lehet sok rekordra alkalmazott hibás leképezés. A tény maradjon ott, ahol ember ellenőrizheti és frissítheti.
A forráselőadás arra is figyelmeztet, hogy nem minden gondolkodási hibára a lekérés a megoldás. Ha a modell két fontos dokumentumot sem tud helyesen összevetni, további ötven dokumentum nem tanítja meg erre. Előbb kérdezd meg, megérkezett-e a helyes részlet. Aztán nézd meg, helyes volt-e a fölötte hozott ítélet.
Integrációépítőként így javíthatsz: azonosítsd a téves állítást; vizsgáld meg a lekért mező- vagy API-részletet; ellenőrizd a fiókot és a verziót; szükség esetén javítsd a forrást vagy a lekérést; teszteld újra a döntést. Csak ezután fontolj meg modellcserét.
Ennek ára egy valódi tudásréteg fenntartása: forrásfrissítések, hozzáférés-ellenőrzés és hivatkozások. A nyereség az egy helyen javítható tény.
Egy változó szerződésnek soha nem szabad arra várnia, hogy a modell elfelejtse.
Gyakran Ismételt Kérdések
Mi kerüljön az ügynök promptjába?
Kicsi, tartós utasítások a viselkedésről és a határokról. A változó katalógust, fiókspecifikus mezőlistát vagy aktuális szolgáltatói szabályt szükség esetén engedélyezett forrásból kell lekérni.
Miért ne tanítsuk tovább a modellt a jelenlegi dokumentáción?
A finomhangolás a változó tényt nehezen vizsgálható és frissíthető súlyokba építheti. Először biztosítsd, hogy a döntés pillanatában a helyes dokumentumot kérjük le és hivatkozzuk.
Hogyan javítsunk egy hibás tényszerű választ?
Vizsgáld meg a forrásdokumentumot, annak verzióját, a lekérési szűrőt és a visszaadott részletet. A modell módosítása előtt javítsd a tényt vagy a lekérés útját.