
Ce este un «ham» și de ce contează
Când angajezi o persoană foarte deșteaptă, nu îi dai doar un calculator. Îi dai un post, un șef, niște reguli, un buget și pe cineva care verifică ce este important. La fel se întâmplă și cu inteligența artificială.
Hamul este tot ceea ce înconjoară modelul de IA: ce model folosește fiecare specialist, cum se împart cererile, ce se reîncearcă, ce se decide și când se oprește. Modelul pune inteligența; hamul pune criteriul și siguranța.
ADRI, echipa de specialiști a BionicAdri, funcționează astfel. Aici îți explicăm cum, fără termeni tehnici.
Cine lucrează la fiecare sarcină: șeful de echipă
Fiecare specialist ADRI cere lucru unui grup de modele, pe care îl numim «pool», printr-un gateway propriu. Gândește-te la gateway ca la un șef de echipă care împarte sarcinile între angajații disponibili.
De la 19 septembrie, ADRI nu mai alege modelul manual. O face gateway-ul, cu trei reguli simple:
- După prioritate. Se apelează mai întâi la modelele preferate.
- La prioritate egală, la cel mai puțin ocupat. Ca la o casă de supermarket: te pun unde e coadă mai mică.
- Sare la cele pline sau căzute înainte de a începe să răspundă, pentru ca nimeni să nu aștepte un model care nu va răspunde.
În plus, factura merge doar la modelul care a răspuns. Dacă unul era căzut și a fost sărit, nu costă nimic.
Ca model principal folosim Qwen, open source.
Mai puține niveluri, mai multă claritate
Înainte erau trei niveluri de calitate: scăzut, normal și ridicat. Pe 7 septembrie le-am retras pentru că, la măsurare, două dintre ele mergeau la același model: era complexitate fără beneficiu. Astăzi există un grup pentru fiecare specialist. Vocea în direct are al său, iar acolo ce contează este rapiditatea răspunsului.
Ce se întâmplă dacă un model eșuează
Modelele uneori greșesc în moduri foarte concrete: răspunsul se întrerupe la mijlocul propoziției, sau modelul rămâne să repete același lucru în buclă.
În acest caz, ADRI nu se predă și nu îți livrează un răspuns pe jumătate. Cere lucrarea altui model din grup, ca un șef care, dacă un angajat rămâne blocat, dă sarcina unui coleg. Există o limită: maximum două salturi pe cerere, pentru ca o problemă să nu se transforme într-un lanț fără sfârșit.
Deciziile mici: arbitrul
Un sistem cu mulți specialiști ia sute de mici decizii: către cine merge această cerere?, ce metodă folosesc pentru a căuta aceste date? Înainte se rezolvau cu reguli rigide de cuvinte-cheie: «dacă mesajul conține cutare cuvânt, merge într-un anumit loc». Funcționează până când cineva se exprimă altfel.
Pentru asta, ADRI are un decident, un model mic (aproximativ 9 miliarde de parametri) care nu scrie texte. Este ca un arbitru: răspunde doar la întrebări de da sau nu, sau alege între opțiuni, și spune cu ce probabilitate crede asta. Înlocuiește regulile de cuvinte-cheie în vreo 36 de decizii ale sistemului.
Cum a fost introdus, pas cu pas
- În umbră. Decidentul doar notează ce ar fi decis și dacă se potrivește cu regula veche. Nu trimite nimic.
- Zile de trafic real. Se lasă să observe muncă reală înainte de a-i da putere.
- Decizie cu decizie. Se activează una câte una, nu toate deodată.
În materie de securitate, de altfel, are mâinile legate: poate doar să înăsprească, niciodată să dea permisiunea. Dacă are îndoieli, vetoul său poate doar să retragă un «da», niciodată să îl adauge.
Ce măsurăm
Pe un set de 526 de cazuri reale:
| Decident | Precizie |
|---|---|
| Cel anterior | 89 % |
| Cel actual | 92-93 % |
Și o face rapid: în medie, aproximativ 63 de milisecunde pe decizie. Când are îndoieli (încredere scăzută) poate consulta un model mai mare. Dar am măsurat și asta: cu judecători orbi, pe 9 octombrie am renunțat să mai escaladăm textul, pentru că cel mic nimerea mai des (10 față de 6 în cazurile în care diferau). Uneori cel mare nu îl îmbunătățește pe cel mic.
Un exemplu real
Pe 9 octombrie am schimbat ceva la supervisor: nu mai trimite „la programare” ceea ce nu știe unde se încadrează. În 14 zile am văzut că 22 din 73 de sarcini către programare erau pur și simplu „citește acest fișier”. Acum rezolvă cine trebuie, iar programarea se ocupă de programare.
Fără plafoane fixe: un control de progres
Pe 4 octombrie am eliminat plafoanele fixe de lucru. Înainte, o sarcină era întreruptă după X apeluri, indiferent dacă avea sens sau nu. Era ca și cum i-ai spune unui angajat: „la ora 3 după-amiaza lași ce faci”.
Acum un control de progres evaluează dacă merită să continui, să schimbi abordarea sau să te oprești și să predai ce ai adunat. Se menține un plafon de cheltuieli pe sarcină în gateway ca o siguranță: dacă ceva scapă de sub control, costul are o limită.
Cum mai multe modele verifică lucrul
Pentru cod, securitate și părți delicate, ADRI poate lansa mai multe modele din familii diferite în paralel, fiecare cu propriul său focus, și să adune ce găsesc. Este ca și cum ai cere părerea mai multor recenzori independenți care nu s-au consultat anterior.
De ce familii diferite? Pentru că fiecare greșește în mod diferit. Ce îi scapă uneia, vede alta.
O singură opinie nu este de ajuns; coincidența da.
Într-o măsurătoare internă pe 1.112 constatări:
- Un avertisment izolat de la un singur model nimerește în 16-25 % din cazuri.
- Când 3 sau 4 familii coincid, rata de succes este în jur de 90 %.
De aceea, ceea ce contează este coincidența, nu avertismentul unuia singur. Și ceea ce este important verifică întotdeauna o persoană.
O lecție din iulieUn benchmark din 11 iulie ne-a învățat ceva util: să aduni patru modele „ridică podeaua” (filtrează erorile) dar nu „tavanul” (nu le face mai deștepte). Ajută să greșești mai puțin, nu să fii un geniu.
Ce înseamnă asta pentru compania ta
- Mai puține sperieturi. Dacă un model eșuează, altul continuă lucrul.
- Decizii măsurate. Fiecare schimbare a fost testată înainte de a fi activată, cu cifre.
- Securitate prin design. În cazurile delicate, sistemul poate doar să închidă uși.
- Controlul cheltuielilor. Un plafon pe sarcină evită costurile neașteptate.
- O persoană la final. AI propune și filtrează; ceea ce este important validează cineva.
Concluzie
Inteligența unui asistent nu stă doar în model. Stă în modul în care se împarte munca, cum se reacționează la erori, cine decide în caz de dubii și cine verifică. Aceasta este partea pe care o construim la BionicAdri.
Dacă vrei să vezi ADRI lucrând cu datele companiei tale, cere o demonstrație sau scrie-ne la [email protected].
- Agenți AI
- Gateway de modele
- Decident
- Revizuire multimodel
Dacă vrei să vezi cum funcționează în interior modelele care supraveghează fiecare pas, citește modele de decizie oglindă: cum ADRI decide, supraveghează și se corectează.