Modele, context și răspunsuri incorecte

Separați capacitatea de informațiile disponibile

Un model lingvistic folosește tipare învățate și informațiile furnizate în timpul unei sarcini. Modelele moderne pot efectua raționamente complexe și lucrări software utile. Pot produce și un răspuns detaliat care depinde de o ipoteză incorectă.

„Model frontier” descrie un nivel de capacitate aflat în schimbare. Termenul nu dovedește că un model a citit depozitul de cod. Nu arată că modelul cunoaște versiunile dependențelor sau regulile de afaceri nescrise. Mediul sarcinii trebuie să furnizeze aceste fapte.

Un agent cu instrumente adecvate poate obține informații. Un chat fără acces nu poate inspecta depozitul de cod. Când un răspuns pare incorect, puneți două întrebări. Poate modelul rezolva această problemă cu informațiile corecte? A primit modelul acele informații?

Un alt model ar putea ajuta la prima problemă. Furnizarea unei politici lipsă sau verificarea unei dependențe poate rezolva a doua problemă.

Definiți contextul acestei sarcini

Contextul este informația disponibilă pentru răspunsul curent. Include instrucțiuni, fișiere furnizate, conversația relevantă și rezultatele instrumentelor. Produsele selectează și păstrează aceste informații în moduri diferite. Pot și rezuma conținutul anterior.

Nu presupuneți că un model citește fiecare fișier dintr-un dosar încărcat. Nu presupuneți că o instrucțiune timpurie rămâne disponibilă pe durata unei sesiuni lungi. Cereți instrumentului să identifice fișierele și instrucțiunile folosite.

Mai mult context nu îmbunătățește întotdeauna răspunsul. O decizie de arhitectură actuală poate ajuta mai mult decât fișiere sursă fără legătură. Un ghid de migrare depășit poate produce un răspuns incorect deoarece pare să aibă autoritate.

Luați în considerare o funcționalitate fictivă pentru setările contului. Furnizați ruta, middleware-ul de autorizare, modelul de date relevant și un test existent. Adăugați o constrângere concretă: „Un membru își poate schimba numele afișat. Un membru nu își poate schimba rolul în organizație.” Modelul are acum o regulă explicită de păstrat.

Verificați afirmațiile din explicație

Un răspuns poate afirma că un endpoint este sigur deoarece middleware-ul verifică apartenența resursei. Verificați fiecare parte a afirmației.

1. Verificați dacă endpointul folosește middleware-ul indicat.
2. Verificați dacă middleware-ul confirmă apartenența resursei, nu doar autentificarea.
3. Identificați sursa identității utilizatorului.
4. Executați un test negativ ca alt utilizator.

O referință la depozitul de cod indică unde să căutați. Referința nu dovedește că explicația corespunde codului.

Folosiți aceeași metodă pentru o recomandare de API. Codul generat poate apela o metodă pe care pachetul instalat nu o exportă. Verificați versiunea pachetului și documentația oficială înainte de a înlocui dependențele. Altfel, o ipoteză fără dovezi poate provoca o migrare inutilă.

Transformați incertitudinea într-o verificare

„Fiți preciși” nu este un plan de verificare. Identificați ipoteza, dovezile necesare și consecința unui rezultat incorect.

De exemplu: „Nu am verificat izolarea între tenant-uri pentru acest endpoint. Inspectați handlerul cererii. Adăugați un test în care un utilizator din alt tenant cere aceeași înregistrare.” Instrucțiunea îi oferă agentului o investigație concretă și un rezultat observabil.

Pentru întrebări despre implementare, examinați versiunea efectivă a sistemului. Un document poate descrie comportamentul intenționat. Inspecția codului și testele ajută la stabilirea comportamentului actual. Dacă acestea se contrazic, consemnați diferența până când un responsabil o rezolvă. Nu alegeți în tăcere răspunsul mai convenabil.

Managerii pot folosi metoda fără a citi fiecare modificare de cod. Întrebați ce ipoteze a verificat echipa. Identificați ipotezele încă neclarificate și responsabilii lor. Aceste informații sprijină decizia de lansare mai direct decât numele modelului.