← Înapoi la blog

Problema predării: ce trebuie să dețină echipa ta înainte ca consultanții să plece

Cele mai multe proiecte AI nu eșuează la lansare, ci șase luni mai târziu, când nimeni din companie nu mai poate schimba sistemul. Iată cum să preveni asta.

Ce înseamnă cu adevărat proprietatea asupra unui sistem AI

Un proiect AI are două finaluri. Primul este lansarea, sărbătorită de toți. Al doilea este mai puțin zgomotos și apare după luni, când un furnizor modifică o formă, o reglementare se schimbă sau o versiune a modelului este eliminată, iar sistemul începe să ofere răspunsuri mai slabe. Atunci întrebarea devine simplă: cine îl repară?

Dacă răspunsul sincer este "ar trebui să apelăm din nou la consultanți", nu ai cumpărat un sistem, ci ai închiriat unul, iar contorul continuă să ruleze.

Ce înseamnă cu adevărat proprietatea

Proprietatea nu este o dosare de documente predată la sfârșitul zilei. Este reprezentată de patru capacități practice în interiorul companiei tale:

  • Poți rula sistemul: cineva știe cum să verifice dacă funcționează astăzi și primește notificări când nu o face.
  • Poți modifica sistemul: cineva poate ajusta o regulă, adăuga o sursă de documente sau actualiza un prompt fără a deschide un bilet de asistență.
  • Poți evalua rezultatele: cineva poate distinge răspunsurile bune de cele rele, pe baza unor dovezi, nu doar impresii.
  • Poți înlocui sistemul: știi ce depinde de sistem, ce costuri implică mutarea lui și cine altcineva ar putea efectua această muncă.

Majoritatea transferurilor asigură doar prima capacitate și omit celelalte trei. De aceea sistemele se deteriorează în timp.

Documentația care contează

Documentația este scrisă pentru a satisface o clauză contractuală, astfel descrie o arhitectură pe care nimeni nu o va atinge niciodată și omite lucrurile de care oamenii au cu adevărat nevoie. Păstrează lista scurtă și insistă asupra următoarelor:

  • Un ghid de intervenție în caz de eșec: cele cinci probleme cele mai probabile să apară, cum ar părea din exterior și primele trei pași pentru fiecare. Scris pentru persoana de serviciu, nu pentru un inginer.
  • Un set de evaluare: 100-200 de cazuri reale cu răspunsul corect pentru fiecare, convenit de persoanele care fac munca. Acest artefact este cel mai valoros al întregului proiect.
  • Un jurnal de modificări cu motive: nu doar ce a fost configurat, ci și de ce există o regulă. Regulile fără motive vor fi șterse de următorul utilizator.
  • Foaie de calcul a dependențelor și costurilor: fiecare model, API și furnizor; costul lunar; datele de reînnoire ale contractelor; ce se întâmplă dacă dispare.
  • O hartă a datelor: unde sunt stocate datele, cine are acces la ele și cât timp sunt păstrate. Echipele juridice și de securitate vor avea nevoie de aceasta fără preaviz.

Totul altceva este opțional. Dacă un document nu ajută pe cineva să ruleze, să modifice, să evalueze sau să înlocuiască sistemul, este doar decor.

Cei trei oameni de care ai nevoie

Nu ești neapărat obligat să angajezi o echipă de învățare automată. Ai nevoie de trei persoane numite, și ar trebui să le numești înainte de începerea proiectului, nu în ultima lună.

  • Un proprietar de afaceri care decide ce ar trebui să facă sistemul și deține bugetul. Ei aprobă modificările și refuză extinderea scopului. Aceasta nu este un rol tehnic.
  • Un custode tehnic care poate citi configurația, face o modificare controlată, testa și implementa în producție. De obicei, un dezvoltator existent sau un inginer IT cu capacitate alocată. Nu trebuie să construiască modele; trebuie să poată modifica și implementa ceea ce există deja.
  • Un proprietar de calitate din departamentul care utilizează sistemul - managerul senior al cererilor de despăgubire, asistentul principal medical, șeful departamentului de suport. Ei mențin setul de evaluare și decid ce înseamnă "bun". Fără acest rol, calitatea devine o chestiune de opinie în câteva săptămâni.

Costul total intern: de obicei, o fracțiune a unui rol cu normă întreagă pentru fiecare, odată ce sistemul este stabil. Modul de eșec nu este costul; este faptul că nimeni nu a fost numit.

Testați transferul în timp util

Nu accepta documentația ca dovadă a transferului. Rulează un test live în ultimele săptămâni ale angajamentului, în timp ce consultanții sunt încă sub contract.

Alege o modificare reală - adăugarea unui nou produs în baza de cunoștințe, întărirea unei reguli privind ceea ce sistemul refuză să răspundă sau înlocuirea unei tabele de prețuri actualizate. Cere-le propriului tău team să o facă, cu consultanții prezenți dar tăcuți. Măsoară timpul. Apoi, lasă proprietarul de calitate să ruleze setul de evaluare și să confirme că nu s-a rupt nimic altceva.

Dacă echipa ta finalizează asta într-o zi, tu deții sistemul. Dacă durează o săptămână și trei întrebări, ai identificat exact lacunele care trebuie închise înainte ca facturile să se încheie. Orice rezultat este mult mai valoros decât un formular de predare semnat.

Scrie acest lucru în contract la început. Milestones-uri de transfer, o echipă primitoare numită și un test de modificare supravegheat sunt toate mai ușor de negociat înainte de începerea lucrărilor decât după aceea.

Așa construim noi la Hercules A, iar acest lucru înseamnă ca angajamentele noastre se încheie. Aceasta este punctul. Măsurătoarea unui proiect AI bun nu este cât de adânc sunt înrădăcinate consultanții un an mai târziu - este încrederea cu care oamenii din propria ta echipă modifică sistemul fără a apela pe cineva.

Articole · Hercules A

Idei pentru a-ți adapta compania la IA.

Contact