Tre spørsmål til en modell står mellom en tenkt integrasjonsassistent og feltmappingen den skal lage. Det første klassifiserer forespørselen. Det andre velger et verktøy. Det tredje skriver om samme valg i et lengre format. Rekkefølgen ble laget da modellen ofte blandet sammen to operasjoner. Etter en modelloppgradering kan den ekstra ruten gi forsinkelse uten å forhindre feil.
Den eneste måten å vite det på, er å kjøre de samme oppgavene gjennom begge rutene. At noe er kjent, er ikke bevis for at det er nyttig.
En presentasjon om produkter som endrer seg med modellens evner argumenterer for at produktet bør bli bedre når modellen blir bedre. Den beskriver også hvor vanskelig det kan være å fjerne grensesnitt brukerne kjenner. Lærdommen er ikke å fjerne all støtte. Den er å teste om støtten fortsatt fortjener plassen sin.
Skill hjelp fra myndighet
En gammel hjelper kan være en prompt som gjentar verktøybeskrivelser, en ruter som alltid velger samme operasjon, eller et fast grensesnitt for en oppgave modellen nå kan forklare tydeligere ved behov. Jobben til laget er å hjelpe modellen eller brukeren å fullføre arbeidet. Hvis det ikke lenger gjør det, er vedlikeholdet ren ekstra kostnad.
En tillatelsessjekk er noe annet. Den avgjør om en handling er lov. En modell som blir svært god til å velge verktøy, kan fortsatt ikke gi seg selv tilgang til en annen butikks data. En modell som skriver en feilfri kontaktoppdatering, trenger fortsatt riktig godkjenning før skriving i drift.
Forklaringen av MCP beskriver både tilgang til verktøy og sikkerhetskostnaden ved å åpne den. Modellens evner kan endre hvordan assistenten finner riktig verktøy. De fjerner ikke behovet for å avgrense verktøyet og kontrollere inndataene.
Dette skillet hindrer en vanlig feil i oppryddingsprosjekter. Team ser den gamle flyten som ett lag og beholder alt eller sletter alt. Del den i spørsmål: Hvilke deler hjelper modellen å tenke, hvilke hjelper brukeren å forstå, og hvilke håndhever en regel utenfor modellen? Bare de to første kan være kandidater for fjerning fordi modellen er blitt bedre.
En rettferdig sammenligning krever samme oppgaveinndata og samme tillatte handlinger. Hvis den enklere veien får et nyere skjema eller videre tillatelser, sier et godt resultat lite om laget som ble fjernet. Ta med feiltilfellene den gamle hjelperen ble laget for å fange, og sjekk om den nye veien fanger dem av samme grunn. Ellers kan noen få vellykkede vanlige eksempler viske ut minnet om hvorfor hjelpen fantes.
Sammenlign hele oppgaver
En modelltest er ikke nok. Produktspørsmålet er om brukerne fullfører den virkelige oppgaven med færre feil, mindre tid eller tydeligere dokumentasjon.
Lag et lite sett med scenarier: en vanlig kontaktmapping, et ukjent felt i målsystemet, en konto som mangler tillatelser, og en forespørsel om aktivering før forhåndsvisning. Kjør hvert scenario med og uten hjelpelaget. Sjekk verktøykallene, forklaringene og beslutningene om å stoppe. Mål ventetid og kostnad ved siden av korrekthet.
Hvis den enklere veien er like god på vanlige oppgaver, men dårligere når tillatelse mangler, behold sperren. Hvis hjelperen ikke endrer noe og legger til to sekunder, fjern den. Hvis den bare hjelper i én sjelden klasse av forespørsler, avgrens den til den klassen.
En rimelig innvending er: «Brukerne har lært det gamle grensesnittet. Å slette det gir dem mer arbeid.» Det stemmer. En kjent kontroll kan hjelpe et menneske selv etter at modellen ikke lenger trenger den. Se om disse brukerne faktisk forstår og fullfører oppgaven. Et gammelt grensesnitt kan bli av menneskelige grunner, men grunnene bør være beskrevet og testet.
Skill kostnaden ved omveien fra kostnaden ved å endre den. En ruter kan gi liten forsinkelse, men være billig å beholde. En skjør, håndskrevet parser kan kreve vedlikehold hver gang en leverandør legger til et felt. En oversikt kan registrere ventetid, feilrate, vedlikeholdsarbeid og brukerforståelse. Verdiene må komme fra produktets egne oppgaver, ikke en generell påstand om at en nyere modell er smartere.
Hva beskytter den gamle hjelperen fortsatt?
-
Den håndhever tillatelse eller dataavgrensning
Behold kontrollen
Modellevner gir ikke myndighet.
-
Den hjelper bare én unntaksklasse
Avgrens hjelpen
Bruk den der oppgavetestene viser verdi.
-
Den endrer ingen testede resultater
Avvikle hjelperen
Fjern forsinkelse og vedlikehold den ikke lenger forsvarer.
Fjern omveien med vilje
En trygg avvikling har en grunnlinje og en vei tilbake. Registrer resultatene til den gamle flyten på de samme scenariene, bytt til den nye for en avgrenset gruppe, og følg med på feil. Behold den gamle atferden lenge nok til å undersøke en forverring. Dette er vanlige produktkontroller, ikke et løfte om at modellfremgang gjør alle funksjoner unødvendige.
Tajos guide til reverse ETL gir en nyttig grense: Gjentatt dataflytting hører hjemme i en stabil pipeline. En sterkere modell kan forbedre hvordan en mapping foreslås eller forklares. Den gjør ikke ett modellkall per post til en bedre måte å flytte data på.
Kostnaden ved denne disiplinen er regelmessig ny testing. Gevinsten er et produkt som ikke bærer gårsdagens omveier for alltid.
Bedre modeller bør fjerne rutinearbeid, ikke regler.
Skriv en kort begrunnelse ved hvert lag som blir igjen. «Dette steget hindrer skriving uten tillatelse» er varig selv når modellkvaliteten øker. «Dette steget kompenserer for at modellen forveksler to verktøy» bør utløse en ny test ved neste modellbytte. Den lille oversikten gjør fremtidig opprydding til en beslutning som kan gjentas, i stedet for en debatt om hvorvidt den gamle løsningen føles kjent.
Ofte Stilte Spørsmål
Når bør et hjelpelag for AI fjernes?
Når tester av dagens oppgaver viser at laget ikke forbedrer resultatet nok til å forsvare ventetid, kostnad og vedlikehold. Sammenlign de samme oppgavene med og uten laget.
Hvilke kontroller bør bli værende?
Kontroller som håndhever tillatelser, datagrenser eller handlinger som ikke lett kan reverseres, må bli selv om modellen blir bedre. Evne gir ikke myndighet.
Kan det skade brukere å fjerne et kjent grensesnitt?
Ja. Test om brukerne som er avhengige av det, fortsatt forstår og fullfører oppgaven. En raskere modell beviser ikke at alle klarer seg uten det gamle grensesnittet.