Alegeți modelul pentru programare pe sarcinile proprii

Locul unui model în oferta furnizorului este un motiv slab pentru a vă construi permanent activitatea în jurul lui. Prezentarea Claude 3.5 Sonnet din iunie 2024 a ilustrat problema: Anthropic propunea un model din gama medie care depășea modelul său anterior de vârf în propriile evaluări de programare. Răspunsul durabil este să păstrați posibilitatea schimbării modelului și să comparați variantele permise pe sarcini din depozitul propriu.

Recomandarea cere o evaluare mică, repetabilă, și o limită clară în codul integrării. Nu cere să schimbați furnizorul la fiecare mișcare dintr-un clasament. Schimbarea merită doar dacă avantajul se păstrează în cerințele, verificările și condițiile dumneavoastră de lucru.

Citiți afirmația de la lansare împreună cu metoda

Anunțul Anthropic din iunie, a cărui pagină afișează acum 21 iunie 2024, raporta 64% dintre probleme rezolvate de Sonnet față de 38% de Claude 3 Opus, într-o evaluare internă de programare cu agenți. Descria și un cost mai mic și o viteză mai mare decât Opus. Erau rezultatele furnizorului pentru modelele de atunci, nu clasamentul actual și nici un câștig de productivitate reprodus independent.

Anexa la fișa modelului explică evaluarea: modificări în depozite cu sursă deschisă, teste ascunse modelului și încercări succesive într-un mediu izolat, fără internet. Metoda contează. Un model care răspunde într-o conversație fără instrumente pentru depozit nu lucrează în aceleași condiții.

Ambele documente provin de la Anthropic. Două linkuri nu înseamnă două măsurători independente. Justifică examinarea unui candidat, fără să transforme scorul raportat în rata de succes așteptată pentru activitatea proprie.

Și evoluția ulterioară cere data ei. Anthropic a anunțat o versiune Sonnet îmbunătățită pe 22 octombrie 2024. Rezultatele raportate foloseau alte evaluări și condiții. Nu plasați actualizarea în iunie și nu alăturați procente diferite ca și cum ar forma aceeași măsurătoare continuă. Din noiembrie 2026, concluzia susținută este că un nume familiar poate acoperi schimbări importante în timp.

Alegeți un set mic care poate schimba decizia

Începeți cu aproximativ douăsprezece sarcini reprezentative, dacă ajung să acopere activitatea pe care o atribuiți efectiv. Numărul este un punct practic de plecare, nu dimensiunea unui eșantion justificat statistic. Includeți o modificare obișnuită, o eroare care cere investigație și o sarcină la care modificarea codului fără legătură ar fi un eșec.

Într-o aplicație ilustrativă de comenzi, o sarcină poate cere schimbarea validării cu păstrarea răspunsului existent de eroare. Alta poate cere găsirea cauzei unui total greșit, fără modificarea interfeței publice. Sunt exemple propuse. Pentru acest articol nu au fost rulate modele pe aceste sarcini.

Scrieți criteriile de acceptare înainte să vedeți răspunsurile. Notați comportamentul cerut, scurtăturile interzise și verificările pe care le va face evaluatorul. Testele trecute sunt utile, dar nu stabilesc totul: o rescriere inutil de amplă poate trece testele și poate îngreuna mentenanța. Includeți evaluarea umană a limitelor schimbării și a clarității.

Protejați datele folosite. Alegeți sarcini și cod pe care aveți dreptul să le trimiteți fiecărui candidat. Un model care nu poate primi acele date în condițiile agreate nu este o variantă disponibilă, indiferent de scorul promovat.

Comparați activitatea completă, apoi separați contribuția modelului

Păstrați comparabile versiunea depozitului, instrumentele și timpul alocat. Înregistrați instrucțiunea, identificatorul modelului și setările pe care serviciul le expune. Dacă un candidat primește instrumente de căutare, iar altul doar text copiat, comparați două sisteme. Rezultatul poate ajuta la alegerea produselor, dar trebuie descris ca atare.

Numărați efortul de verificare și reluările alături de rezultatele acceptate. Dacă un candidat propune rapid o modificare plauzibilă, dar schimbă repetat fișiere fără legătură, viteza răspunsului poate contribui puțin la terminarea sarcinii. Comparați munca totală până la o schimbare acceptabilă, nu doar tokenurile.

Repetați sarcinile cu rezultate neclare când este posibil și păstrați eșecurile. Un set mic poate orienta o decizie locală fără să dovedească superioritatea generală. Schimbați o parte din set odată cu proiectul, ca ajustarea instrucțiunilor pentru exemple deja cunoscute să nu devină întregul exercițiu. Păstrați o parte stabilă pentru a observa regresiile.

Limitați codul dependent de furnizor

Instrumentul care cere o modificare propusă nu ar trebui să aibă detalii specifice furnizorului răspândite în toată aplicația. Grupați construirea cererilor, interpretarea răspunsurilor și tratarea erorilor într-o interfață restrânsă. Asociați datele de autentificare și permisiunile asupra datelor cu furnizorul ales. Nu presupuneți că fiecare înlocuitor are aceleași drepturi.

Un format comun al cererii nu garantează comportament identic. Apelarea instrumentelor, limitele contextului și răspunsurile structurate pot diferi. Păstrați vizibile diferențele relevante și verificați-le înainte de schimbare. Adaptorul trebuie să facă diferențele gestionabile, fără să le ascundă până când sarcina eșuează.

Și alternativa în caz de indisponibilitate trebuie aleasă explicit. O întrerupere temporară nu este permisiunea de a trimite cod confidențial altui furnizor. Dacă nu există o alternativă aprobată, opriți sarcina și păstrați-i starea. Disponibilitatea și autorizarea transmiterii datelor sunt decizii separate.

Posibilitatea schimbării are și ea un cost

Obiecția cea mai serioasă este că un strat universal pentru modele poate deveni un produs separat. Suportul pentru furnizori ipotetici și pentru orice funcționalitate posibilă poate consuma mai mult decât ar economisi o schimbare viitoare. O echipă care lucrează bine cu un abonament nu trebuie să cumpere alte servicii doar ca să demonstreze că are variante.

Folosiți abonamentele și permisiunile existente. Izolați puținele operații specifice de care aveți nevoie, documentați presupunerile și reluați setul mic de sarcini când propuneți o schimbare importantă de model sau instrumente. Păstrați alegerea actuală dacă dovezile pentru schimbare sunt slabe.

Într-o integrare cu agenți AI, rezultatul util este o activitate a cărei calitate poate fi verificată și ale cărei dependențe pot fi schimbate deliberat. Un scor de lansare poate aduce un model pe lista scurtă. Decizia depinde de munca pe care echipa o poate accepta, verifica și întreține.