På denne siden
Se for deg en produktkatalog som endres på mandag. Assistentens prompt inneholder fortsatt fredagens liste. Teamet oppdaterer prompten. En annen kopi av den gamle listen ligger i eksempler som ble brukt til å trene modellen. Assistenten gir nå ett gjeldende og ett foreldet svar i samme samtale.
Dette er et tenkt feilforløp, men mekanismen er velkjent: Det samme faktumet har fått mer enn ett hjem.
En presentasjon om prompter, kunnskapssøk og modellvekter trekker en nyttig grense. En prompt forteller assistenten hvordan den skal oppføre seg. Søk henter gjeldende, kildebelagt kunnskap inn i en bestemt oppgave. Modelltilpasning kan lære et stabilt mønster. Hvis du behandler de tre som en stige, først prompt, så søk og deretter finjustering hver gang svaret fortsatt er feil, tar du feil av årsaken til faktafeil.
En prompt er en dårlig katalog
Prompter er fristende fordi de er lette å redigere. Legg til et avsnitt, og neste forespørsel tar det med seg. Bekvemmeligheten skjuler to kostnader. Faktumet sendes med hvert kall, også når det ikke er relevant. Og en stor prompt gjør det vanskeligere å vite hvilken kopi av en regel modellen brukte.
En varig instruks som «spør før du sender en kampanje» hører hjemme nær agenten. En liste over denne butikkens gjeldende egendefinerte felt gjør ikke det. Listen kan endres når en kontoadministrator legger til et attributt. Den kan være forskjellig mellom kunder. Den kan være synlig i ett arbeidsområde og forbudt i et annet.
Guiden til Brevo-koblingen viser hvorfor feltdefinisjoner betyr noe for kontaktsynkronisering. Hvis et attributt ikke er definert på målkontoen, kan en mapping som virket fornuftig ut fra navnet, unnlate å opprette riktig felt. Agenten bør undersøke kontoens gjeldende kontrakt, ikke hente en generell feltliste fra modellens hukommelse.
Et nyttig søkeresultat er lite nok til å utfordres. Det bør vise hvilken konto eller kunde det gjelder, når det ble lest, og hvilken operasjon eller hvilket felt det beskriver. Hvis to hentede avsnitt er uenige, bør systemet vise konflikten i stedet for stille å velge det mest velformulerte. Riktig neste steg kan være et nytt oppslag eller en gjennomgang, ikke enda et forsøk på å formulere prompten sterkere.
Hent faktumet sammen med gyldighetsområdet
En nyttig kunnskapsoppføring inneholder mer enn tekst. Den trenger en kilde, en versjon eller et tidspunkt for innhenting, kontoavgrensning og en tydelig måte å fjerne eller erstatte den på. En feltdefinisjon fra én butikkonto må aldri bli en universell regel for en annen.
Et spørsmål om et kontaktattributt kan da hente det minste avsnittet som svarer på det: feltnavn, type og kontoen der feltet finnes. Svaret kan peke tilbake på kilden. Hvis mappingen feiler, kan teamet spørre om informasjonen var gammel, om resultatet kom fra feil konto, eller om modellen misforstod et riktig avsnitt.
Dette er ulike feil med ulike rettelser. En endring i prompten kan ikke rette et søkefilter som krysser kundegrenser. En større modell kan ikke oppgi en attributtdefinisjon ingen hentet.
Forklaringen av MCP viser hvordan en agent kan spørre verktøy. Verktøyet bør returnere den relevante kontrakten, mens applikasjonen håndhever hvem som får se den. En tekstinstruks om «ikke avslør data fra en annen kunde» erstatter ikke en avgrenset forespørsel.
Denne oppdelingen gjør også feilretting raskere. Hvis et felt i målsystemet får nytt navn, oppdater skjemakilden og gjør den berørte mappingen ugyldig. Hvis agenten stadig misforstår en stabil instruks, endre instruksen eller test målrettet trening. Hvis et svar er feil fordi søket valgte feil konto, bommer en endring i modellvektene på årsaken. Hver feiltype har en eier og en egen vei til rettelse.
- Varig instruks
Hvordan assistenten skal oppføre seg
- Avgrenset søk konto · versjon · tidspunkt
Hva som gjelder nå
- Mappingbeslutning
Bruk gjeldende fakta i denne oppgaven
- Kontrollert skriving
Kode sjekker tillatelse og omfang
Lær mønstre først når de har stabilisert seg
En rimelig innvending er: «Hvis et faktum brukes hele tiden, hvorfor ikke trene det inn i en mindre modell?» Gjentakelse er ikke nok. Faktumet må være riktig mellom modelloppdateringer, og modellen må kunne skille mellom kontekster.
Et stabilt klassifikasjonsmønster kan etter hvert være verdt å finjustere for. En leverandørs gjeldende feltliste er en dårlig kandidat. Selv om den endres sjelden, kan ett foreldet svar føre til at feil mapping brukes på mange poster. La faktumet være der en person kan undersøke og oppdatere det.
Kilden advarer også mot å bruke søk som løsning på enhver svikt i resonneringen. Hvis modellen ikke klarer å sammenligne to relevante dokumenter riktig, lærer ikke femti ekstra dokumenter den å resonnere. Spør først om riktig avsnitt ble hentet. Spør deretter om vurderingen av det var god.
For den som bygger integrasjoner, gir dette en rekkefølge for feilretting: Finn den uriktige påstanden. Undersøk det hentede avsnittet om feltet eller API-et. Sjekk konto og versjon. Rett kilden eller søket ved behov. Test beslutningen på nytt. Først da bør du vurdere en modellendring.
Kostnaden er å vedlikeholde et virkelig kunnskapslag: kildeoppdateringer, tilgangskontroller og henvisninger. Gevinsten er et faktum som kan rettes på ett sted.
En kontrakt som endrer seg, bør aldri måtte vente på at en modell glemmer den.
Ofte Stilte Spørsmål
Hva hører hjemme i en agents prompt?
Korte, varige instrukser om atferd og grenser. En katalog som endres, en kundespesifikk feltliste eller en gjeldende leverandørregel bør hentes fra en autorisert kilde når den trengs.
Hvorfor ikke finjustere en modell på dagens dokumentasjon?
Finjustering kan bake et foranderlig faktum inn i modellvekter som er vanskelige å undersøke og oppdatere. Sørg først for at riktig dokument blir hentet og kildebelagt når beslutningen tas.
Hvordan bør et feilaktig faktasvar rettes?
Undersøk kildedokumentet, versjonen, søkefilteret og avsnittet som ble hentet. Rett faktumet eller måten det hentes på, før du endrer modellen.