Engineering AI Assistant Evaluation: A Buyer’s Framework

Un ghid pentru cumpărători: cum evaluați un asistent AI pentru echipe de inginerie Siemens NX și Teamcenter

§ 02 — Pentru cine este și cum îl folosiți

Documentul este scris pentru persoana care trebuie să aprobe achiziția: un director de inginerie, un responsabil de metode CAD/PLM sau un arhitect IT întrebat dacă un asistent de inginerie merită o linie de buget. Presupune un mediu Siemens NX sau Teamcenter, dar cadrul se aplică oricărei filiere de unelte profunde, versionate și specifice unui furnizor.

Folosiți-l în această ordine. Citiți secțiunea 4 și decideți de care straturi de ancorare au nevoie întrebările voastre — asta singură elimină cea mai mare parte a pieței. Citiți secțiunea 5 ca să distingeți o arhitectură reală de retrieval de un simplu înveliș. Punctați candidații cu secțiunea 7. Rulați protocolul din secțiunea 8 față de cei doi rămași, cu metoda din secțiunea 9. Verificați secțiunea 10 înainte să discutați prețul și secțiunea 11 în timp ce îl discutați. Secțiunile 12 și 13 acoperă greșelile dinainte și de după semnătură.

Contextul de industrie merită un paragraf și nu mai mult. Adopția nu este problema: în Work Trend Index 2024 al Microsoft și LinkedIn, un sondaj pe 31.000 de persoane din 31 de țări, 75 la sută dintre lucrătorii din domeniul cunoașterii foloseau deja AI generativă la serviciu, iar 78 la sută dintre ei își aduceau propriile unelte. Problema este conversia. Raportul MIT NANDA The GenAI Divide: State of AI in Business 2025 a constatat că 95 la sută dintre proiectele-pilot din companii nu au produs niciun randament măsurabil, iar Enterprise AI Agent Report 2026 al OutSystems a găsit 94 la sută dintre organizații care tratează proliferarea necontrolată a AI ca sursă în creștere de complexitate, datorie tehnică și risc de securitate, în timp ce doar 12 la sută rulează o platformă centrală. Golul dintre „oamenii folosesc AI” și „compania obține valoare” este un gol de evaluare și de ancorare.

§ 03 — De ce eșuează asistenții generali la întrebările de inginerie

Un asistent general eșuează la o întrebare de inginerie într-un mod specific și previzibil: răspunde fluent din text public, iar întrebările de inginerie în cea mai mare parte nu se pot răspunde din text public. Trei moduri de eșec se repetă, iar fiecare are altă rezolvare.

Deriva de versiune. Siemens livrează de aproximativ două ori pe an — NX 2606 și Teamcenter 2606 au apărut amândouă în iunie 2026, ultimul pe 12 iunie. Un asistent antrenat pe un corpus care acoperă un deceniu de versiuni va răspunde cu încredere cu o metodă eliminată acum două versiuni, iar nimic din răspuns nu semnalează cărei versiuni îi aparține. Inginerul află abia la compilare sau, mai rău, la execuție pe o piesă de producție. Deriva de versiune nu este o problemă de calitate a modelului, ci una de retrieval, și se rezolvă legând retrievalul de o ediție, nu cerându-i modelului mai multă grijă.

Suprafață de API inventată. Acest lucru este măsurabil, nu anecdotic. Într-un studiu arXiv din 2026, pe care îl rezumă analiza noastră despre ChatGPT, modelele de vârf inventează 4 până la 6 la sută dintre numele de pachete și de API-uri, iar rata crește pentru API-uri de nișă precum NXOpen, unde materialul public de antrenare este subțire. Un nume de metodă halucinat este mai rău decât niciun răspuns: trece de revizuire pentru că arată exact ca unul real — scriere corectă, spațiu de nume plauzibil, argumente rezonabile — și costă un inginer o oră ca să îl infirme. Înmulțit cu o echipă, asistentul este pe minus.

Fără acces la ce este al vostru. Orice instalare NX cu ceva vechime poartă un strat pe care nu îl cunoaște nimeni din afara companiei: macrouri scrise de cineva care a plecat, automatizări VB.NET de acum trei versiuni de NX, API-uri interne nedocumentate, convenții de atribute și denumire care există doar în mintea oamenilor și regulile de verificare care decid dacă o piesă poate fi eliberată. Nimic din toate acestea nu este public, deci nimic nu se află într-un model de bază. Un asistent nu poate fi ancorat în ele decât dacă i le dă cineva în mod deliberat.

Niciunul dintre acestea nu se rezolvă cu un model mai bun. Toate trei se rezolvă prin ancorare — iar ancorarea este o arhitectură, nu o bifă pe o listă de funcții.

§ 04 — Cele patru straturi de ancorare

Fiecare asistent de pe piață acoperă un subset din patru straturi. Denumirea lor transformă o comparație vagă într-o listă scurtă de verificat — și explică de ce două produse bune pot arăta complet diferit într-o demonstrație.

Straturile sunt independente, iar tocmai asta contează. Un asistent PLM poate fi excelent la stratul 4 și să nu aibă nimic la straturile 2 și 3 — Teamcenter Copilot de la Siemens are exact această formă, prin proiectare și nu din scăpare, pentru că este ancorat în evidențe și documentație Teamcenter. Un asistent orientat pe cod poate fi puternic la 1 și 2 și orb la 4. Greșeala nu este alegerea produsului greșit, ci lipsa observației despre ce straturi cer întrebările voastre.

Un diagnostic care durează douăzeci de minute. Luați ultimele douăzeci de întrebări de inginerie pe care oamenii voștri și le-au pus reciproc în chat sau la birou și marcați fiecare cu stratul care o rezolvă. Distribuția este cerința voastră — scrisă de propria organizație, nu de un furnizor. În echipele NX cu care lucrăm, straturile 2 și 3 domină, iar stratul 3 este cel pe care aproape nimeni nu îl planifică. Dacă distribuția voastră este dominată de stratul 4, cumpărați un asistent PLM și opriți-vă din citit comparații de produse CAD.

§ 05 — Ce stă de fapt în spatele unui asistent ancorat

Această secțiune există pentru că „folosim RAG” a încetat să fie o informație. Toți furnizorii o spun. Ce diferă este arhitectura de dedesubt, iar cinci decizii concrete din ea determină dacă asistentul este demn de încredere pe conținut de inginerie. Întrebați despre fiecare pe nume.

Și formatul răspunsului. Citarea sursei nu este decor. Un inginer care vede din ce document și din ce ediție provine un răspuns îl verifică în secunde; cine nu vede trebuie să verifice de la zero, iar atunci asistentul nu a economisit nimic. Tratați citarea ca pe o cerință funcțională.

§ 06 — Granița deterministă

Aceasta este o doctrină, nu un criteriu, și o respectăm în fiecare proiect: un asistent poate ajuta un om să decidă și nu trebuie niciodată să decidă el însuși ceva ce trebuie să poată fi apărat.

De ce modelul de actualizare cântărește mai mult decât limbajul am descris în NXOpen față de Knowledge Fusion; pentru AI se aplică aceeași logică. Ce trebuie să facă asistentul este tot ce înconjoară această graniță: să explice de ce a picat o verificare, să schițeze codul care implementează o regulă, să găsească ghidul aplicabil, să rezume treizeci de pagini de specificație, să îi explice unui inginer nou ce este o named reference. Este o suprafață mare și valoroasă și nimic din ea nu cere să încredințezi asistentului un verdict.

Întrebați fiecare furnizor unde trasează această graniță. Un furnizor care își vrea modelul într-o decizie de eliberare fie nu s-a gândit la auditabilitate, fie speră că voi nu v-ați gândit.

§ 07 — Douăsprezece criterii punctate

Punctați fiecare candidat cu 0, 1 sau 2 per criteriu. Sub 16 din 24 nu este un candidat serios pentru un mediu de inginerie; un 0 la orice criteriu marcat critic este descalificant indiferent de total.

§ 08 — Protocolul de test: zece întrebări, o după-amiază

Rulați-le față de fiecare candidat, cu formulare identică, și notați răspunsurile. Nu lăsați furnizorul să conducă sesiunea. Întrebările 2 și 8 sunt cele la care cad majoritatea produselor și cele mai des absente dintr-o demonstrație.

Notați pass, parțial sau fail în cuvinte, cu câte o propoziție de dovadă. Nu punctați doar cu culori — peste trei săptămâni notițele sunt cele cu care argumentați, iar un verdict trebuie să fie lizibil ca un cuvânt.

§ 09 — Cum vă construiți propriul set de întrebări

Protocolul de mai sus este jumătatea independentă de furnizor. Cealaltă jumătate sunt douăzeci de întrebări pe care doar organizația voastră le poate scrie — iar felul în care le scrieți decide dacă evaluarea înseamnă ceva.

Luați-le din realitate, nu din imaginație. Extrageți ultimele douăzeci de întrebări de inginerie din istoricul de chat, din coada de helpdesk sau din inboxul unui responsabil de metode. Întrebările pe care oamenii chiar le-au pus au distribuția corectă de dificultate; cele inventate pentru o evaluare sunt sistematic prea ușoare sau prea exotice.

Marcați fiecare cu stratul ei de ancorare. Acesta este diagnosticul din secțiunea 4 — și totodată documentul vostru de cerințe.

Scrieți răspunsul etalon înainte să rulați ceva. Pentru fiecare întrebare, scrieți ce trebuie să conțină un răspuns corect — faptele-cheie, nu formularea. Fără un răspuns etalon scris dinainte, punctarea devine o dezbatere despre ton, iar cea mai zgomotoasă persoană din încăpere câștigă.

Decideți cine punctează și câți. Doi evaluatori independenți pe aceleași răspunsuri, dezacordurile discutate, nu mediate. Dacă vreți să verificați dacă punctarea voastră este măcar fiabilă, convenția din cercetare este un kappa ponderat peste aproximativ 0,6 între doi evaluatori sau alfa Krippendorff la cel puțin 0,8 cu mai mult de doi.

Despre punctarea cu un LLM. Funcționează mai bine decât se așteaptă majoritatea — evaluările publicate pun judecătorii LLM la 80-90 la sută acord cu judecata umană, la o fracțiune din cost — și este unealta potrivită pentru o suită mare de regresie, mai târziu. Pentru decizia de cumpărare este unealta greșită, pentru că un judecător moștenește punctele oarbe ale lucrului pe care îl judecă. Consensul literaturii 2025-2026: judecătorii completează revizuirea umană, nu o înlocuiesc, iar oamenii se uită la cazurile marcate. Pentru douăzeci de întrebări și doi candidați, punctați voi.

Păstrați setul. Devine suita voastră de regresie. Fiecare versiune a asistentului și fiecare upgrade de NX este un motiv să îl rulați din nou — și exact așa observați când un produs se înrăutățește în tăcere.

§ 10 — Implementare, securitate și reglementare

Rezolvați aceste puncte înainte de preț, pentru că fiecare poate încheia discuția. Două puncte din listă s-au schimbat în 2026 și merită citite chiar dacă ați evaluat un produs anul trecut.

Dacă trebuie să ruleze între zidurile voastre. On-premise nu mai este exotic, iar aritmetica de dimensionare este publică: bugetați aproximativ 0,5 GB VRAM per miliard de parametri la cuantizare pe 4 biți sau 2 GB la 16 biți, apoi rezervați încă 20-40 la sută pentru cache-ul cheie-valoare și activări și validați la concurența voastră reală, nu pe un benchmark cu un singur utilizator. Stivele de servire — vLLM, NVIDIA NIM, SGLang, TensorRT-LLM — sunt pregătite pentru producție, nu experimentale. Un aranjament cu adevărat air-gapped înseamnă că greutățile modelului, modelul de încorporare, baza de date vectorială și orchestrarea stau toate pe hardware local, fără cale spre exterior — și este realizabil. Constrângerea onestă este că majoritatea companiilor nu au capacitatea GPU în casă, motiv pentru care un tipar hibrid — infrastructura voastră, serverele voastre de calcul atinse printr-un API controlat — este calea de mijloc obișnuită.

§ 11 — Cât costă asta pe trei ani

Nu vom tipări un preț, pentru că orice cifră inventată de noi ar fi greșită pentru situația voastră. Ce vă putem da este structura — ca business case-ul vostru să aibă liniile potrivite, nu doar pe cea vizibilă.

Două observații din proiectele pe care le-am rulat. Întâi, licența este rareori costul decisiv, iar optimizarea ei ignorând liniile de preluare și operare este drumul pe care un produs ieftin devine un program scump. Al doilea: dacă luați în calcul on-premise, pragul de rentabilitate este real, dar depinde de sarcină — ghidurile publicate pun hardware-ul de intrare pentru servire privată în jur de zece mii de dolari americani, cu paritate față de cheltuiala pe API-uri cloud în câteva luni la volume mari de întrebări și niciodată la volume mici. Calculați-vă propriul volum înainte să luați o poziție.

Linia pe care am apăra-o cel mai tare într-o revizuire de buget este evaluarea. Un set de întrebări rerulat la fiecare versiune costă foarte puțin și este singurul mecanism care vă spune dacă lucrul cumpărat mai este lucrul pe care îl aveți.

§ 12 — Cinci greșeli de achiziție

Evaluarea pe întrebările furnizorului. O demonstrație este un caz optim curatoriat. Aduceți propriile douăzeci de întrebări din secțiunea 9, altfel punctați un scenariu de vânzare, nu un produs.

Cumpărarea capabilității fără condiții contractuale. Rezidența datelor, retenția, despăgubirea, documentația conform Regulamentului european privind IA și ieșirea aparțin aceleiași decizii ca și calitatea răspunsurilor — nu unei revizuiri juridice ulterioare care descoperă un blocaj după ce bugetul este angajat, iar promotorul și-a pus credibilitatea la bătaie.

Fără referință inițială. Dacă nu puteți spune cât costă o întrebare astăzi — minute până la un răspuns, escaladări pe săptămână, cât de des întrerupe un junior un senior —, nu veți putea arăta ce s-a schimbat. Discuția de reînnoire devine atunci o chestiune de opinie, iar opiniile pierd în fața tabelelor.

Omiterea testului de refuz. Un asistent care nu spune niciodată „nu știu” nu este încrezător, ci neancorat. Vedeți întrebarea 2 din protocol — și tratați un răspuns fluent la o metodă inventată ca pe un motiv de descalificare, nu ca pe o curiozitate.

Nebugetarea stratului 3. Aducerea propriilor macrouri, standarde și convenții în asistent este de obicei cea mai mare linie de cost și cea omisă din business case. Tot acolo stă și cea mai mare parte a valorii, ceea ce face omiterea de două ori mai scumpă: proiectul pare ieftin, livrează prea puțin și vina cade pe tehnologie.

§ 13 — După ce cumpărați: partea care decide dacă funcționează

Achiziția se termină la semnătură; valoarea începe mai târziu. Trei lucruri separă o implementare care prinde de una care încetează în tăcere să fie folosită.

Puneți-l acolo unde se lucrează. Un asistent într-un tab de browser separat concurează cu termenul limită al inginerului și pierde. În sesiunea CAD sau PLM devine un reflex. De aceea integrarea în sesiune ține de criteriile de flux de lucru, nu de o listă de comodități.

Faceți din onboarding o cale, nu un proiect. Dacă adăugarea unui caz de utilizare nou sau a unui set nou de documente cere de fiecare dată echipa de platformă, echipa de platformă devine strangularea — iar o strangulare nu se distinge de o politică ce spune nu. Întrebați, înainte de semnătură, ce trebuie să facă un departament ca să adauge material propriu.

Numiți un responsabil și un ritm de revizuire. Cineva deține baza de cunoștințe, cineva aprobă surse noi, cineva rerulează setul de întrebări la fiecare versiune. Fără aceste trei nume, asistentul se degradează: corpusul se învechește, răspunsurile derivează și nimeni nu observă până când un inginer încetează să aibă încredere în el. Este aceeași lecție pe care am tras-o din construirea unei platforme GenAI la nivel de companie pentru un producător mare — arhitectura nu a fost niciodată partea grea; modelul de operare a fost.

§ 14 — Dezvăluire: unde se situează Vision4NX

Lectură conexă: recenzia noastră despre de ce ChatGPT greșește la Siemens NX descrie măsurătoarea din spatele stratului 2.