- ai-implementation
- ai-maintenance
- ai-cost
- production-ai
- software-ownership
Analiză completă
Întrebarea pe care echipa ta o pune când evaluează integrarea AI este de obicei una dintre acestea: Este această IA suficient de bună pentru a face sarcina? Cât va costa să o construim? Vor găsi utilizatorii noștri că este utilă?
Acestea sunt întrebări rezonabile. Sunt și a doua, a treia și a patra întrebare. Prima întrebare — cea pe care aproape nimeni nu o pune înainte de angajament — este aceasta: Cine menține această funcționalitate în luna 18, și avem bugetul și expertiza pentru a-i da ce are nevoie?
Dacă nu ai un răspuns clar, nu ai un plan pentru a adăuga AI. Ai un plan pentru a-ți asuma o nouă categorie de datorie tehnică.
De ce funcționalitățile AI au o structură de costuri diferită
Software-ul tradițional are o proprietate care face ca mentenanța pe termen lung să fie relativ predictibilă: determinismul. Date aceleași inputuri, același cod produce aceleași outputuri. Bug-urile sunt reproductibile. Odată reparate, rămân reparate. Costul operării software-ului tradițional după livrare este în principal infrastructură și muncă pentru funcționalități noi și corecții de bug-uri. Aceste costuri sunt bine înțelese și au decenii de euristici de estimare în spate.
Funcționalitățile bazate pe AI rup această predictibilitate în patru moduri specifice.
Mentenanța prompturilor
Comportamentul modelelor de limbaj este sensibil la formularea exactă a prompturilor. Această sensibilitate nu este statică — se schimbă pe măsură ce modelele sunt actualizate. Un prompt care produce outputuri de înaltă calitate consistente azi poate produce outputuri notabil diferite după următoarea actualizare a modelului, chiar dacă folosești același nume de model. Furnizorul consideră asta normal. Utilizatorii tăi consideră asta problema ta. Aceasta înseamnă că funcționalitățile AI necesită monitorizare activă a calității outputurilor și revizuire periodică a prompturilor ca răspuns la schimbările modelului.
Ciclurile de deprecare ale modelelor
Furnizorii de modele AI deprecă modele în cicluri definite. Când funcționalitatea ta depinde de un model deprecat, te confrunți cu o migrare forțată: testezi noul model, revizuiești prompturile, validezi calitatea outputurilor, redeployezi. Acesta nu este un cost viitor ipotetic — este unul planificat, previzibil din momentul în care te angajezi la o funcționalitate dependentă de AI.
Monitorizarea comportamentului
Software-ul tradițional fie funcționează, fie nu funcționează. Când nu funcționează, eșuează de obicei în mod vizibil. Funcționalitățile bazate pe AI eșuează diferit: outputuri subtil greșite, inconsistent greșite sau greșite în moduri pe care utilizatorii nu le observă și nu le raportează imediat. Nu te poți baza pe erorile raportate de utilizatori pentru a menține calitatea. Ai nevoie de monitorizare proactivă a outputurilor — cineva sau ceva care evaluează regulat un eșantion de outputuri AI față de un standard definit.
Volatilitatea costurilor din scalarea utilizării
Costurile API AI sunt de obicei per token: fiecare input și output este contorizat. O creștere de 10 ori a numărului de interacțiuni AI produce ceva apropiat de o creștere de 10 ori a costurilor de infrastructură AI. Aceasta creează volatilitate bugetară pentru care bugetele de software tradițional nu pregătesc echipele.
Când nu se aplică
Acest argument nu este un caz împotriva utilizării AI. Este un caz împotriva angajamentului față de funcționalități AI fără a ține cont de cerințele lor specifice de mentenanță. Se aplică mai puțin puternic la: fluxuri de lucru unice sau în lot unde un om revizuiește fiecare output înainte de a acționa; instrumente interne unde variabilitatea comportamentului este acceptabilă; și utilizări experimentale cu timp limitat cu criterii de evaluare definite și un punct de decizie integrat.
Întrebarea mai bună de pus prima
Înainte de a evalua dacă AI este suficient de capabilă pentru a face sarcina, răspunde la aceasta cu specificitate: După ce această funcționalitate este lansată, cine verifică că funcționează corect luna viitoare? Și luna următoare? Și când furnizorul modelului lansează o actualizare care îi schimbă comportamentul?
Dacă răspunsul onest este «ne vom ocupa de asta mai târziu»: costul funcționalității în propunerea ta lipsește cel mai mare element de cost. Dacă răspunsul onest este «nimeni, pentru că presupunem că va funcționa pur și simplu»: funcționalitatea va funcționa probabil bine în primele luni — perioada când echipa ta încă acordă atenție și modelul nu a fost actualizat. Luna 18 este o altă conversație.
Întrebarea nu este dacă să folosești AI. Întrebarea este dacă ești pregătit să menții o funcționalitate bazată pe AI la standardul de producție pentru întreaga perioadă în care intenționezi să o folosești. Majoritatea deciziilor de a adăuga AI se iau pe primul angajament ignorând tăcut al doilea.
Numește-l pe cel care menține înainte de a numi modelul. Dacă nu poți numi cel care menține, mai ai planificat de făcut.
Care este «întrebarea lunii 18» pentru funcționalitățile AI?
Înainte de a se angaja să construiască o funcționalitate bazată pe AI, întreabă: cine menține această funcționalitate în luna 18 și organizația are bugetul și expertiza pentru a-l susține? Această întrebare există deoarece funcționalitățile AI au cerințe de mentenanță continue — revizuiri de prompturi când comportamentul modelului se schimbă, migrări forțate când modelele sunt deprecate, monitorizare proactivă a calității — pe care software-ul tradițional nu le are. Majoritatea echipelor evaluează funcționalitățile AI pe capacitate și cost de construire, tratând mentenanța ca ceva secundar. Întrebarea lunii 18 scoate la suprafață angajamentul care este de fapt asumat.
De ce funcționalitățile AI necesită mentenanță continuă când software-ul tradițional nu o necesită?
Software-ul tradițional este determinist: aceleași inputuri produc întotdeauna aceleași outputuri. Funcționalitățile bazate pe AI nu sunt. Comportamentul modelelor de limbaj este sensibil la formularea prompturilor și se schimbă pe măsură ce modelele sunt actualizate — deci prompturile care funcționau azi pot produce outputuri diferite după o actualizare a modelului, chiar când numele modelului rămâne același. Modelele sunt, de asemenea, deprecate în cicluri definite, necesitând migrări forțate. Și eșecurile AI sunt adesea subtile mai degrabă decât vizibile, necesitând monitorizare proactivă a calității pe care software-ul tradițional nu o necesită.
Există cazuri de utilizare AI unde sarcina de mentenanță este mai mică?
Da. Sarcina de mentenanță este mai mică pentru: fluxuri de lucru unice sau în lot unde un om revizuiește fiecare output înainte de a acționa (deriva prompturilor este prinsă de editor, nu de un sistem de monitorizare); instrumente interne unde variabilitatea comportamentului este acceptabilă (o căutare AI care uneori afișează rezultate mai puțin relevante este enervantă, nu un risc de producție); și utilizări experimentale cu timp limitat cu criterii de evaluare definite și un punct de decizie integrat. Argumentul de mentenanță se aplică cel mai puternic funcționalităților AI persistente, orientate spre clienți, care rulează în producție fără revizuire umană a outputurilor individuale.