Modeller, kontekst og forkerte svar

Skeln mellem evner og tilgængelige oplysninger

En sprogmodel bruger indlærte mønstre og de oplysninger, der gives under en opgave. Moderne modeller kan udføre omfattende ræsonnementer og nyttigt softwarearbejde. De kan også give et detaljeret svar, som bygger på en forkert antagelse.

»Frontier-model« beskriver et niveau af evner, som ændrer sig over tid. Begrebet dokumenterer ikke, at modellen har læst dit repository. Det viser ikke, at modellen kender versionerne af dine afhængigheder eller uskrevne forretningsregler. Opgavens miljø skal stille disse fakta til rådighed.

En agent med passende værktøjer kan hente oplysninger. En chat uden adgang kan ikke undersøge repositoryet. Stil to spørgsmål, når et svar virker forkert. Kan modellen løse problemet med de rigtige oplysninger? Modtog modellen de oplysninger?

En anden model kan måske hjælpe med det første problem. En manglende politik eller en kontrol af en afhængighed kan løse det andet.

Definér konteksten for denne opgave

Kontekst er de oplysninger, som er tilgængelige for det aktuelle svar. Den omfatter instruktioner, tilføjede filer, relevant samtale og resultater fra værktøjer. Produkter vælger og bevarer disse oplysninger på forskellige måder. De kan også opsummere tidligere indhold.

Antag ikke, at en model læser hver fil i en uploadet mappe. Antag ikke, at en tidlig instruktion forbliver tilgængelig under en lang session. Bed værktøjet om at angive de filer og instruktioner, det brugte.

Mere kontekst forbedrer ikke altid svaret. En aktuel arkitekturbeslutning kan hjælpe mere end uvedkommende kildefiler. En forældet migreringsvejledning kan give et forkert svar, fordi vejledningen virker autoritativ.

Overvej en fiktiv funktion til kontoindstillinger. Tilføj routen, middleware til rettighedskontrol, den relevante datamodel og en eksisterende test. Tilføj en konkret begrænsning: »Et medlem må ændre sit viste navn. Et medlem må ikke ændre sin rolle i organisationen.« Modellen har nu en udtrykkelig regel, som den skal bevare.

Kontrollér påstandene i en forklaring

Et svar kan hævde, at et endpoint er sikkert, fordi middleware kontrollerer ejerskab. Kontrollér hver del af denne påstand.

1. Kontrollér, at endpointet bruger den angivne middleware.
2. Kontrollér, at middleware verificerer ejerskab, ikke kun autentifikation.
3. Find kilden til brugeridentiteten.
4. Udfør en negativ test som en anden bruger.

En henvisning til repositoryet viser, hvor du skal kigge. Henvisningen dokumenterer ikke, at forklaringen stemmer med koden.

Brug samme metode ved en API-anbefaling. Genereret kode kan kalde en metode, som din installerede pakke ikke eksporterer. Kontrollér pakkeversionen og den officielle dokumentation, før du udskifter afhængigheder. Ellers kan en udokumenteret antagelse føre til en unødvendig migrering.

Omsæt usikkerhed til en kontrol

»Vær præcis« er ikke en verifikationsplan. Beskriv antagelsen, den nødvendige dokumentation og konsekvensen af et forkert resultat.

For eksempel: »Vi har ikke verificeret tenant-isolation for dette endpoint. Undersøg request-handleren. Tilføj en test, hvor en bruger fra en anden tenant anmoder om samme post.« Instruktionen giver agenten en konkret undersøgelse og et observerbart resultat.

Ved spørgsmål om implementering skal du undersøge den faktiske systemversion. Et dokument kan beskrive tilsigtet adfærd. Kodegennemgang og tests hjælper med at fastslå den aktuelle adfærd. Hvis de er uenige, skal du registrere forskellen, indtil en ansvarlig afklarer den. Vælg ikke stiltiende det mest bekvemme svar.

Ledere kan bruge metoden uden at læse hver kodeændring. Spørg, hvilke antagelser teamet har kontrolleret. Find de antagelser, der stadig er åbne, og de ansvarlige for dem. Den viden støtter en releasebeslutning mere direkte end modellens navn.