Când ar trebui să dispară o soluție provizorie pentru AI?

Trei întrebări adresate modelului stau între un asistent ilustrativ de integrare și harta lui de câmpuri. Prima clasifică cererea. A doua alege un instrument. A treia reformulează aceeași alegere mai pe larg. Secvența a fost construită când modelul confunda adesea două operațiuni. După actualizarea lui, ruta suplimentară poate adăuga întârziere fără să prevină greșeli.

Singura cale de a afla este să rulezi aceleași sarcini pe ambele rute. Familiaritatea nu dovedește valoarea.

O prezentare despre produsele care se schimbă odată cu capacitatea modelului susține că produsul ar trebui să se îmbunătățească atunci când modelul se îmbunătățește. Relatează și dificultatea eliminării unor interfețe familiare. Lecția utilă nu este să elimini orice sprijin. Este să testezi dacă sprijinul își mai merită locul.

Separă ajutorul de autoritate

Un ajutor vechi poate fi un prompt care repetă descrierile instrumentelor, un selector care alege mereu aceeași operațiune sau o interfață fixă pentru o sarcină pe care modelul o poate explica acum mai limpede la cerere. Rolul său este să ajute modelul ori utilizatorul să termine munca. Dacă nu mai face asta, costul întreținerii este doar povară.

Verificarea permisiunii este altceva. Decide dacă o acțiune este permisă. Un model care ajunge excelent la alegerea instrumentelor tot nu își poate acorda acces la datele altui comerciant. Un model care scrie impecabil o actualizare de contact are în continuare nevoie de aprobarea potrivită înaintea unei scrieri reale.

Explicația MCP descrie atât accesul la instrumente, cât și costul de securitate al expunerii lor. Capacitatea modelului poate schimba felul în care asistentul găsește instrumentul potrivit. Nu elimină nevoia de a limita instrumentul și de a-i valida intrările.

Distincția previne o greșeală frecventă la simplificarea produselor. Echipele văd vechiul flux ca pe un singur strat și fie îl păstrează complet, fie îl șterg complet. Desparte-l în întrebări: ce părți ajută modelul să judece, care îl ajută pe utilizator să înțeleagă și care impun o regulă în afara modelului? Doar primele două pot fi eliminate pe baza noilor capacități.

O comparație corectă cere aceleași intrări ale sarcinii și aceleași acțiuni permise. Dacă ruta simplă primește o schemă mai nouă ori permisiuni mai largi, un rezultat bun spune puțin despre stratul eliminat. Include cazurile de eșec pe care vechiul ajutor trebuia să le prindă, apoi verifică dacă ruta nouă le prinde din același motiv. Altfel, câteva exemple obișnuite reușite pot șterge amintirea motivului pentru care ajutorul exista.

Compară sarcini complete

Un test standard al modelului nu ajunge. Întrebarea pentru produs este dacă utilizatorii termină sarcina reală cu mai puține greșeli, în mai puțin timp sau cu dovezi mai clare.

Construiește un set mic de scenarii: o mapare obișnuită de contact, un câmp necunoscut în destinație, un cont fără permisiunile necesare și o cerere care încearcă activarea înaintea previzualizării. Rulează fiecare caz cu stratul ajutător și fără el. Verifică apelurile instrumentelor, explicațiile și deciziile de oprire. Măsoară întârzierea și costul alături de corectitudine.

Dacă ruta simplă este la fel de bună pentru cazurile obișnuite, dar mai slabă la permisiuni, păstrează protecția. Dacă ajutorul nu schimbă nimic și adaugă două secunde, elimină-l. Dacă ajută doar pentru o clasă rară de cereri, restrânge-l la acea clasă.

Obiecția corectă este: „Utilizatorii au învățat interfața veche; ștergerea ei creează muncă nouă.” Așa este. Un control familiar poate ajuta persoana chiar dacă modelul nu mai are nevoie de el. Observă finalizarea și înțelegerea sarcinii la acei utilizatori. Interfața veche poate rămâne din motive umane, dar motivele trebuie numite și testate.

Separă costul soluției provizorii de costul schimbării ei. Un selector poate adăuga puțină întârziere, dar poate fi ieftin de păstrat; un parser fragil scris manual poate cere întreținere ori de câte ori furnizorul adaugă un câmp. O fișă de evaluare poate nota întârzierea, rata erorilor, povara întreținerii și înțelegerea utilizatorilor. Valorile vin din sarcinile proprii ale produsului, nu din afirmația generală că modelul nou este mai inteligent.

Ce mai protejează ajutorul vechi?

1. Impune permisiuni sau domeniul datelor

   Păstrează controlul

   Capacitatea modelului nu oferă autoritate.

2. Ajută doar o clasă de excepții

   Restrânge ajutorul

   Aplică-l unde testele sarcinii arată valoare.

3. Nu schimbă niciun rezultat testat

   Elimină ajutorul

   Elimină întârzierea și întreținerea pe care nu le mai justifică.

Elimină soluția provizorie cu intenție

Eliminarea sigură are un punct de plecare și o cale de întoarcere. Notează rezultatele vechii rute în aceleași scenarii, activează ruta nouă pentru un grup limitat și urmărește eșecurile. Ține vechiul comportament disponibil suficient pentru a diagnostica o regresie. Sunt verificări obișnuite ale produsului, nu promisiunea că progresul modelelor face orice funcție inutilă.

Ghidul Tajo despre reverse ETL arată o graniță utilă: mutarea repetată a datelor aparține unui flux stabil. Un model mai puternic poate îmbunătăți propunerea sau explicarea unei mapări. Nu face dintr-un apel al modelului pentru fiecare înregistrare un mecanism de transport mai bun.

Costul disciplinei este retestarea periodică. Câștigul este un produs care nu cară la nesfârșit soluțiile provizorii de ieri.

Progresul modelului ar trebui să înlăture corvoada, nu regulile.

Păstrează un motiv scurt lângă fiecare strat rămas. „Acest pas previne scrieri neautorizate” rămâne valabil când crește calitatea modelului. „Acest pas compensează confuzia modelului între două instrumente” ar trebui să declanșeze o nouă testare la următoarea schimbare de model. Un astfel de inventar mic transformă simplificarea viitoare într-o decizie repetabilă, nu într-o dezbatere despre cât de familiar pare vechiul proiect.