På denne side
Forestil dig et produktkatalog, der ændrer sig mandag. En assistents prompt indeholder stadig fredagens liste. Teamet opdaterer prompten. En anden kopi af den gamle liste ligger i eksempler, som blev brugt til at træne modellen. Assistenten giver nu ét aktuelt og ét forældet svar i samme samtale.
Det er et tænkt fejlforløb, men mekanismen er velkendt: Den samme oplysning har fået mere end ét hjem.
Et oplæg om prompts, søgning og modelvægte trækker en nyttig grænse. En prompt fortæller assistenten, hvordan den skal opføre sig. Søgning henter aktuel viden med kilder til en bestemt opgave. Modeltilpasning kan lære et stabilt mønster. Hvis du behandler de tre som en stige, først prompt, så søgning og derefter finjustering, når svaret stadig er forkert, fejldiagnosticerer du faktuelle fejl.
En prompt er et dårligt katalog
Prompts er tiltrækkende, fordi de er lette at redigere. Tilføj et afsnit, og næste forespørgsel har det med. Bekvemmeligheden skjuler to omkostninger. Oplysningen sendes med hvert kald, også når den er irrelevant. Og en stor prompt gør det sværere at vide, hvilken kopi af en regel modellen brugte.
En varig instruktion som »spørg, før du sender en kampagne« hører til tæt på agenten. En liste over denne butiks aktuelle brugerdefinerede felter gør ikke. Den kan ændre sig, når en kontoadministrator tilføjer en attribut. Den kan være forskellig fra kundemiljø til kundemiljø. Den kan være synlig i ét arbejdsområde og forbudt i et andet.
Guiden til Brevo-connectoren viser, hvorfor feltdefinitioner betyder noget for kontaktsynkronisering. Hvis en attribut ikke er defineret på målkontoen, giver en mapping, der så fornuftig ud ud fra navnet, måske ikke det ønskede felt. Agenten bør undersøge kontoens aktuelle kontrakt, ikke huske en generisk feltliste fra træningen.
Et nyttigt søgeresultat er lille nok til, at det kan efterprøves. Det bør fortælle, hvilken konto eller hvilket kundemiljø det gælder, hvornår det blev læst, og hvilken handling eller hvilket felt det beskriver. Hvis to hentede passager er uenige, bør systemet vise konflikten frem for lydløst at vælge den mest velformulerede. Det rigtige næste skridt kan være et nyt opslag eller en gennemgang, ikke endnu et forsøg på at formulere prompten mere bestemt.
Hent oplysningen sammen med dens gyldighedsområde
En nyttig videnspost indeholder mere end tekst. Den kræver en kilde, version eller hentetidspunkt, en kontoafgrænsning og en klar måde at fjerne eller erstatte den på. En feltdefinition fundet på én butikskonto må aldrig blive en universel regel for en anden.
Et spørgsmål om en kontaktattribut kan derefter hente den mindste passage, der besvarer det: feltets navn, type og den konto, hvor det findes. Svaret kan pege tilbage på kilden. Hvis mappingen fejler, kan teamet undersøge, om oplysningen var forældet, om resultatet kom fra den forkerte konto, eller om modellen misforstod en korrekt passage.
Det kræver forskellige rettelser. En justering af prompten kan ikke rette et søgefilter, der krydser grænser mellem kundemiljøer. En større model kan ikke levere en attributdefinition, som ingen hentede.
Introduktionen til MCP beskriver, hvordan en agent kan spørge værktøjer. Værktøjet bør returnere den relevante kontrakt, mens applikationen håndhæver, hvem der må se den. En tekstinstruktion om »ikke at afsløre et andet kundemiljø« kan ikke erstatte en afgrænset forespørgsel.
Opdelingen gør også rettelser hurtigere. Hvis et felt i målsystemet får nyt navn, skal du opdatere skemakilden og markere den berørte mapping som ugyldig. Hvis agenten gentagne gange misforstår en stabil instruktion, skal du ændre instruktionen eller teste målrettet træning. Hvis et svar er forkert, fordi søgningen valgte den forkerte konto, rammer en ændring af modelvægtene ikke årsagen. Hver fejltype har sin egen ansvarlige og sin egen vej til en rettelse.
- Varig instruktion
Hvordan assistenten skal opføre sig
- Afgrænset søgning konto · version · tidspunkt
Hvad der gælder nu
- Mappingbeslutning
Brug den aktuelle oplysning til opgaven
- Håndhævet opdatering
Kode kontrollerer tilladelse og omfang
Lær først mønstrene, når de er stabile
Den rimelige indvending er: »Hvis en oplysning bruges konstant, hvorfor så ikke træne den ind i en mindre model?« Gentagelse alene er ikke nok. Oplysningen skal forblive korrekt mellem modelopdateringer, og modellen skal kunne skelne mellem sammenhænge.
En stabil klassifikationsopgave kan med tiden være værd at finjustere til. En leverandørs aktuelle feltliste er en dårlig kandidat. Selv hvis den sjældent ændrer sig, kan ét forældet svar koste en forkert mapping anvendt på mange poster. Behold oplysningen dér, hvor en person kan undersøge og opdatere den.
Oplægget advarer også mod at bruge søgning til at løse enhver fejl i ræsonnementet. Hvis modellen ikke kan sammenligne to relevante dokumenter korrekt, lærer halvtreds ekstra dokumenter den ikke at ræsonnere. Spørg først, om den rigtige passage kom frem. Spørg derefter, om vurderingen af passagen var holdbar.
For den, der bygger en integration, giver det en rækkefølge for rettelser: Find den forkerte påstand. Undersøg den hentede passage om feltet eller API’et. Kontrollér konto og version. Ret kilden eller søgningen efter behov. Test beslutningen igen. Overvej først derefter at ændre modellen.
Prisen er at vedligeholde et reelt videnslag: kildeopdateringer, adgangskontroller og henvisninger. Gevinsten er en oplysning, der kan rettes ét sted.
En kontrakt, der ændrer sig, bør aldrig skulle vente på, at en model glemmer den.
Ofte Stillede Spørgsmål
Hvad hører hjemme i en agents prompt?
Korte, varige instruktioner om adfærd og grænser. Et skiftende katalog, en kundespecifik feltliste eller en aktuel leverandørregel bør hentes fra en autoriseret kilde efter behov.
Hvorfor ikke finjustere en model med den aktuelle dokumentation?
Finjustering kan indlejre en skiftende oplysning i modelvægte, som er svære at undersøge og opdatere. Sørg først for, at det korrekte dokument bliver hentet og citeret, når beslutningen træffes.
Hvordan retter du et faktuelt forkert svar?
Undersøg kildedokumentet, dets version, søgefilteret og den returnerede passage. Ret oplysningen eller måden, den bliver hentet på, før du ændrer modellen.