På denna sida
Tänk dig en produktkatalog som ändras på måndagen. Assistentens prompt innehåller ännu fredagens lista. Teamet uppdaterar prompten. En andra kopia av den gamla listan ligger i exempel som modellen tränades med. Nu ger assistenten både ett aktuellt och ett föråldrat svar i samma session.
Det är ett illustrativt fel, men mekanismen är vanlig: samma faktum har fått fler än ett hem.
Ett samtal om promptar, hämtning och modellvikter drar en användbar gräns. En prompt talar om hur assistenten ska bete sig. Hämtning för in aktuell, citerbar kunskap i en viss uppgift. Modellanpassning kan lära ut ett stabilt mönster. Att se de tre som en stege, först prompta, sedan hämta och därefter finjustera när svaret fortfarande är fel, leder till fel diagnos av faktamissar.
En prompt är en dålig katalog
Promptar lockar eftersom de är enkla att ändra. Lägg till ett stycke så följer det med nästa begäran. Bekvämligheten döljer två kostnader. Faktumet skickas med varje anrop även när det saknar betydelse. Och en stor prompt gör det svårare att veta vilken kopia av regeln modellen använde.
En varaktig instruktion som ”fråga innan du skickar en kampanj” hör nära agenten. En lista över den här butikens aktuella anpassade fält gör det inte. Den kan ändras när en kontoadministratör lägger till ett attribut. Den kan skilja sig mellan kundmiljöer. Den kan vara synlig i en arbetsyta och förbjuden i en annan.
Guiden till Brevo-anslutningen visar varför fältdefinitioner är viktiga för kontaktsynkronisering. Om ett attribut inte har deklarerats i målkontot kanske en mappning som såg rimlig ut inte ger det avsedda fältet. Agenten bör granska kontots aktuella kontrakt, inte minnas en generell fältlista från träningen.
Ett användbart hämtningsresultat är litet nog att ifrågasätta. Det bör ange vilket konto eller vilken kundmiljö det gäller, när det lästes och vilken åtgärd eller vilket fält det beskriver. Om två hämtade stycken motsäger varandra ska systemet visa konflikten i stället för att tyst välja det mest välformulerade. Nästa steg kan vara en ny uppslagning eller en granskning, inte att skriva prompten mer bestämt.
Hämta fakta tillsammans med deras räckvidd
En användbar kunskapspost innehåller mer än text. Den behöver källa, version eller hämtningstid, kontogräns och ett tydligt sätt att ta bort eller ersätta den. En fältdefinition i ett handlarkonto får aldrig bli en allmän regel för ett annat.
En fråga om ett kontaktattribut kan då hämta det minsta stycke som besvarar den: fältnamn, typ och konto där fältet finns. Svaret kan länka till källan. Om mappningen misslyckas kan teamet fråga om uppgiften var föråldrad, om resultatet kom från fel konto eller om modellen missförstod rätt text.
Det är olika reparationer. En promptändring lagar inte ett hämtningsfilter som korsar kundgränser. En större modell kan inte ge en attributdefinition som ingen hämtade.
Förklaringen av MCP visar hur en agent kan fråga verktyg. Verktyget ska lämna rätt kontrakt medan applikationen styr vem som får se det. En textinstruktion om att inte visa en annan kunds data ersätter inte en fråga med avgränsad behörighet.
Uppdelningen gör också reparationer snabbare. Om ett målfält byter namn, uppdatera schemakällan och ogiltigförklara den berörda mappningen. Om agenten gång på gång missförstår en stabil instruktion, ändra instruktionen eller testa riktad träning. Om svaret är fel för att hämtaren valde fel konto missar ändrade modellvikter orsaken. Varje felklass har sin egen ägare och rättningsväg.
- Varaktig instruktion
Hur assistenten ska bete sig
- Avgränsad hämtning konto · version · tid
Vad som gäller nu
- Mappningsbeslut
Använd aktuella fakta för uppgiften
- Styrd skrivning
Kod kontrollerar behörighet och räckvidd
Lär bara ut mönster som blivit stabila
En rimlig invändning är: ”Om samma fakta används hela tiden, varför inte träna in dem i en mindre modell?” Upprepning räcker inte. Fakta måste fortsätta stämma mellan modelluppdateringar, och modellen måste kunna skilja sammanhang åt.
Ett stabilt sätt att klassificera kan med tiden vara värt finjustering. En leverantörs aktuella fältlista är en dålig kandidat. Även om den sällan ändras kan ett enda föråldrat svar leda till en felaktig mappning för många poster. Behåll fakta där en person kan granska och uppdatera dem.
Källsamtalet varnar också för att använda hämtning mot alla resonemangsfel. Om modellen inte kan jämföra två relevanta dokument rätt lär den sig inte det av femtio dokument till. Fråga först om rätt stycke kom fram. Fråga sedan om bedömningen av det var sund.
För den som bygger integrationer blir rättningsordningen: identifiera det felaktiga påståendet, granska det hämtade fält- eller API-stycket, verifiera konto och version, rätta källa eller hämtning vid behov och testa beslutet igen. Först därefter bör ett modellbyte övervägas.
Kostnaden är att underhålla ett verkligt kunskapslager med källuppdateringar, åtkomstkontroller och hänvisningar. Vinsten är ett faktum som kan rättas på ett ställe.
Ett föränderligt kontrakt ska aldrig behöva vänta på att modellen glömmer det.
Vanliga Frågor
Vad hör hemma i en agentprompt?
Små, varaktiga instruktioner om beteende och gränser. En föränderlig katalog, en kundspecifik fältlista eller en aktuell leverantörsregel bör hämtas från en godkänd källa när den behövs.
Varför inte finjustera modellen med aktuell dokumentation?
Då kan föränderliga fakta fastna i vikter som är svåra att granska och uppdatera. Kontrollera först att rätt dokument hämtas och anges som källa vid beslutet.
Hur rättar man ett felaktigt faktasvar?
Granska källdokumentet, versionen, hämtningsfiltret och texten som returnerades. Rätta fakta eller hämtningsvägen innan du ändrar modellen.