Hvornår bør en AI-omvej forsvinde?

Tre spørgsmål til en model står mellem en tænkt integrationsassistent og dens feltmapping. Første spørgsmål klassificerer forespørgslen. Det andet vælger et værktøj. Det tredje omskriver samme valg i et længere format. Rækkefølgen blev bygget, da modellen ofte forvekslede to handlinger. Efter en modelopgradering kan den ekstra vej skabe forsinkelse uden at forhindre fejl.

Den eneste måde at vide det på er at køre de samme opgaver gennem begge forløb. At noget er velkendt, er ikke bevis for værdi.

Et oplæg om produkter, der ændrer sig med modellens evner argumenterer for, at et produkt bør blive bedre, når modellen bliver bedre. Det beskriver også, hvor svært det er at fjerne velkendte grænseflader. Den nyttige lære er ikke at fjerne enhver støtte. Det er at teste, om støtten stadig fortjener sin plads.

Adskil hjælp fra beføjelser

En gammel hjælper kan være en prompt, der gentager værktøjsbeskrivelser, en router, der altid vælger samme handling, eller en fast grænseflade til en opgave, som en model nu kan forklare tydeligere efter behov. Dens opgave er at hjælpe modellen eller brugeren med at afslutte arbejdet. Hvis den ikke længere gør det, er vedligeholdelsen ren ekstraomkostning.

En tilladelseskontrol er noget andet. Den afgør, om en handling er tilladt. En model, der bliver fremragende til at vælge værktøjer, kan stadig ikke give sig selv adgang til en anden butiks data. En model, der skriver en fejlfri kontaktopdatering, har stadig brug for den rette godkendelse før en opdatering i drift.

Introduktionen til MCP beskriver både værktøjsadgang og sikkerhedsomkostningen ved at åbne den. Modellens evner kan ændre, hvordan en assistent finder det rigtige værktøj. De fjerner ikke behovet for at afgrænse værktøjet og kontrollere dets input.

Skellet forebygger en almindelig fejl i oprydningsprojekter. Teams ser det gamle forløb som ét lag og beholder enten det hele eller sletter det hele. Del det op i spørgsmål: Hvilke dele hjælper modellen med at ræsonnere, hvilke hjælper brugeren med at forstå, og hvilke håndhæver en regel uden for modellen? Kun de første to kan fjernes med bedre modelevner som begrundelse.

En rimelig sammenligning kræver samme opgaveinput og samme tilladte handlinger. Hvis den enklere vej får et nyere skema eller bredere tilladelser, siger et godt resultat ikke meget om det fjernede lag. Medtag de fejltilfælde, den gamle hjælper blev bygget til at fange, og kontrollér, om det nye forløb fanger dem af samme grund. Ellers kan nogle få vellykkede almindelige eksempler udviske hukommelsen om, hvorfor hjælperen fandtes.

Sammenlign hele opgaver

En modelmåling er ikke nok. Produktspørgsmålet er, om brugerne afslutter den faktiske opgave med færre fejl, mindre tidsforbrug eller tydeligere dokumentation.

Byg et lille sæt scenarier: en normal kontaktmapping, et ukendt felt i målsystemet, en konto med manglende tilladelser og en forespørgsel, der forsøger at aktivere før forhåndsvisning. Kør hvert scenarie med og uden hjælpelaget. Kontrollér de resulterende værktøjskald, forklaringer og beslutninger om at stoppe. Mål ventetid og omkostninger sammen med korrekthed.

Hvis den enklere vej er lige så god til almindelige opgaver, men dårligere ved manglende tilladelse, så behold kontrollen. Hvis hjælperen intet ændrer og tilføjer to sekunder, så fjern den. Hvis hjælperen kun betyder noget for én sjælden type forespørgsel, så begræns den til den type.

Den rimelige indvending er: »Brugerne har lært den gamle grænseflade. At slette den giver dem nyt arbejde.« Korrekt. En velkendt kontrol kan hjælpe en person, selv når modellen ikke længere behøver den. Observer de brugeres faktiske forståelse og evne til at afslutte opgaven. En gammel grænseflade kan blive af menneskelige grunde, men grundene bør beskrives og testes.

Adskil omkostningen ved omvejen fra omkostningen ved at ændre den. En router kan give en lille forsinkelse, men være billig at beholde. En skrøbelig håndskrevet parser kan kræve vedligeholdelse, hver gang en leverandør tilføjer et felt. En oversigt kan registrere ventetid, fejlrate, vedligeholdelsesbyrde og brugerforståelse. Tallene skal komme fra produktets egne opgaver, ikke fra en generisk påstand om, at en nyere model er klogere.

Hvad beskytter den gamle hjælper stadig?

1. Den håndhæver tilladelse eller dataafgrænsning

   Behold kontrollen

   Modellens evner giver ikke beføjelser.

2. Den hjælper kun én type undtagelse

   Afgræns hjælperen

   Brug den dér, hvor opgavetestene viser værdi.

3. Den ændrer intet testet resultat

   Udfas hjælperen

   Fjern ventetid og vedligeholdelse, den ikke længere retfærdiggør.

Udfas omvejen bevidst

En sikker udfasning har et udgangspunkt og en vej tilbage. Registrer det gamle forløbs resultat i de samme scenarier, skift til det nye forløb for en afgrænset gruppe, og hold øje med fejl. Behold den gamle adfærd længe nok til at kunne undersøge en forværring. Det er almindelige produktkontroller, ikke et løfte om, at bedre modeller gør alle funktioner overflødige.

Tajos guide til reverse ETL giver en nyttig grænse: Gentagen dataflytning hører til i en stabil pipeline. En stærkere model kan forbedre, hvordan en mapping foreslås eller forklares. Den gør ikke ét modelkald pr. post til en bedre transportmekanisme.

Prisen for disciplinen er regelmæssig gentest. Gevinsten er et produkt, der ikke bærer rundt på gårsdagens omveje for evigt.

Bedre modeller bør fjerne rutinearbejde, ikke regler.

Gem en kort begrundelse ved hvert lag, der bliver. »Dette trin forhindrer opdateringer uden tilladelse« holder, selv når modellens kvalitet stiger. »Dette trin kompenserer for, at modellen forveksler to værktøjer« bør udløse en ny test ved næste modelændring. Den lille oversigt gør fremtidig oprydning til en gentagelig beslutning frem for en debat om, hvorvidt det gamle design føles velkendt.