AI pentru helpdesk de inginerie: versiunea scurtă
AI pentru helpdesk de inginerie este un asistent care regăsește tichetele NX, Teamcenter și NXOpen rezolvate, propune pentru fiecare tichet nou un răspuns de primă linie cu surse și redactează schița de răspuns pentru administratorul CAD. Este retrieval (regăsire de informații) peste un istoric de tichete pseudonimizat, nu un model cu fine-tuning. inteliScience, specialiști Siemens NX și Teamcenter care livrează nearshore din România, îl construiește on-premise sau într-un cloud din UE.
Problema: aceleași erori NX și Teamcenter sunt rezolvate în fiecare trimestru
“Poate fi AI-ul antrenat pe datele din sistemul nostru de tichete pentru a obține o tratare a erorilor bazată pe AI?” Întrebarea a venit de la utilizatorii unui client NX, colectată de administrația CAD a unui constructor de mașini din DACH. Este cea mai practică întrebare de pe lista lor, pentru că cunoștințele pe care le doresc există deja. Stau în tichete închise pe care nu le citește nimeni.
O coadă de helpdesk CAD/PLM are un tipar. O stație de lucru este reinstalată (reimaged) și NX nu își mai găsește serverul de licențe. O autentificare Teamcenter eșuează după o schimbare de parolă. Un instrument NXOpen care a funcționat ani de zile se oprește după upgrade-ul la Designcenter NX 2606, lansat în iunie 2026 [6]. Fiecare problemă a fost rezolvată înainte, de aceiași doi administratori, iar rezolvarea a ajuns într-un tichet care a fost închis, arhivat și niciodată redeschis. În trimestrul următor, tichetul revine cu un alt solicitant.
Deflecția tichetelor (evitarea tichetelor) este cea mai puțin spectaculoasă și cea mai măsurabilă utilizare a unui asistent de cunoștințe de inginerie, și de aici am începe. Dacă 40 la sută din coadă sunt repetiții, un asistent care răspunde la repetiții din istoric returnează acele ore administratorilor care asigură și Suport Teamcenter și servicii gestionate prin rotație. Ce urmează este modul de a-l construi fără cele două greșeli pe care le vedem cel mai des: fine-tuning-ul unui model pe tichete brute și indexarea tichetelor cu numele încă în ele.
Ce conține un tichet și ce lipsește de obicei
Un tichet închis este un simptom, un mediu și o rezolvare, scrise sub presiunea timpului de două persoane diferite. Retrieval-ul lucrează pe simptom; răspunsul vine din rezolvare; mediul decide dacă răspunsul mai este valabil. Înainte ca cineva să construiască ceva, exportați 200 de tichete închise și auditați-le după acest tabel.
| Câmp | De obicei prezent | De obicei lipsă | De ce contează pentru retrieval |
|---|---|---|---|
| Simptom (subiect, descriere, text de eroare lipit) | Da, în cuvintele solicitantului | Textul exact al dialogului; adesea o captură de ecran în loc de text | Un tichet nou înseamnă cuvintele altui solicitant pentru același simptom; aceasta este ceea ce se potrivește |
| Mediu (versiune NX sau Teamcenter, sistem de operare, rol, locație, tip de licență) | Parțial, îngropat în text liber | Versiunea ca un câmp structurat | Un răspuns valabil pentru NX 2312 poate să nu mai fie valabil pentru Designcenter NX 2606 |
| Cauza principală | Rareori notată | Singura linie care transformă o remediere în cunoștințe | Fără ea, două tichete cu aceeași remediere par fără legătură |
| Rezolvare | În tichetele închise, dacă administratorul a scris-o | “Rezolvat prin telefon”, “reparat”, “vezi mailul” | Asistentul poate propune doar ceea ce a fost înregistrat |
| Link către articol KB sau înregistrare de eroare cunoscută | Rareori | Referința care face răspunsul ușor de întreținut | Permite asistentului să citeze articolul în locul unui tichet |
| Date personale | Întotdeauna: numele solicitantului, e-mail, hostname, nume de utilizator, uneori o captură de ecran cu un nume pe ea | Nu lipsește nimic aici, ceea ce este chiar problema | Trebuie eliminate sau pseudonimizate înainte de indexare |
Două constatări din acest audit decid proiectul. Dacă mai puțin de jumătate din tichetele închise conțin o rezolvare utilizabilă, primul livrabil este un șablon de închidere cu un câmp de rezolvare obligatoriu, nu un asistent. Dacă cea mai mare parte a textului de eroare se află în capturi de ecran, pipeline-ul are nevoie mai întâi de OCR pe atașamente. Ambele sunt mai ieftin de aflat acum decât în săptămâna a cincea a unui pilot.
“Antrenat pe tichete” înseamnă retrieval, nu fine-tuning
Utilizatorii spun “antrenați AI-ul pe tichetele noastre”. Ceea ce le trebuie este un asistent care, pornind de la un tichet nou, găsește tichetele rezolvate care descriu același simptom și își construiește răspunsul din ele, cu tichetul-sursă citat. Aceasta este generarea augmentată prin regăsire (retrieval-augmented generation, RAG), iar noi am sfătui împotriva fine-tuning-ului unui model pe text de tichete pentru această sarcină.
Fine-tuning-ul schimbă modul în care scrie un model; nu îi oferă o memorie fiabilă despre ce tichet a spus ce anume și nu poate cita un ID de tichet. Retrieval-ul păstrează cunoștințele în afara modelului, într-un index pe care îl puteți inspecta, corecta și din care puteți șterge. Propriul material explicativ al AWS o formulează la fel: RAG “extinde capacitățile deja puternice ale LLM-urilor către domenii specifice sau către baza de cunoștințe internă a unei organizații, toate fără a fi nevoie de reantrenarea modelului”, iar “rezultatul poate include citări sau referințe la surse” [1]. Studiul de sinteză larg citat al lui Gao et al. enumeră exact modurile de eșec pe care le declanșează datele din tichete, halucinații, cunoștințe învechite și raționament netrasabil, și descrie RAG ca abordarea care permite “actualizări continue ale cunoștințelor și integrarea informațiilor specifice domeniului” [2]. Tichetele se actualizează zilnic. Un model cu fine-tuning este un instantaneu.
Există și un al doilea motiv, și ține de protecția datelor. Un model cu fine-tuning pe tichete brute a absorbit nume, iar pentru un nume aflat în ponderile modelului nu există nicio operațiune de ștergere. Un index are una.
Modelul în sine este decizia cea mai puțin interesantă. Modelele Claude actuale, precum claude-opus-5-5, lansat pe 22 septembrie 2026 [3], sau un model open-weight pe propriile GPU-uri vor scrie ambele un răspuns bun de primă linie din trei tichete bine alese. Ceea ce desparte un asistent util de o demonstrație este stratul de retrieval și evaluarea din jurul lui, motiv pentru care cadrul nostru de evaluare a asistenților AI pentru inginerie dedică mai multe pagini straturilor de fundamentare (grounding) decât modelelor.
Pipeline-ul: de la exportul tichetelor la un asistent conectat
Construirea corpusului înseamnă șapte pași, iar pașii doi până la patru iau cea mai mare parte a timpului. Fiecare pas rulează acolo unde se află datele tichetelor.
- Exportare. Extrageți tichetele închise cu rezolvare, istoricul stărilor și atașamentele din instrumentul de tichete (Jira Service Management, ServiceNow, OTRS sau un export din portalul furnizorului), inclusiv câmpurile produs și versiune chiar și acolo unde sunt goale.
- Curățare. Eliminați tichetele fără rezolvare, îndepărtați semnăturile, firele de e-mail citate și răspunsurile automate și extrageți textul erorilor din capturile de ecran cu OCR.
- Pseudonimizare. Înlocuiți numele, adresele de e-mail, numele de utilizator și hostname-urile cu substituenți înainte ca textul să părăsească baza de date a tichetelor; păstrați maparea în sistemul de tichete, nu în index.
- Segmentare per tichet. Un tichet este o unitate de retrieval, cu simptomul și rezolvarea păstrate împreună. Segmentele de dimensiune fixă separă întrebarea de răspunsul ei, singurul lucru care nu trebuie să se întâmple.
- Legarea rezolvărilor. Grupați tichetele care s-au încheiat cu aceeași remediere, atașați articolul KB sau înregistrarea de eroare cunoscută acolo unde există și marcați un tichet canonic per grup.
- Indexare. Generați embedding-uri pentru textul simptomului, stocați produsul, versiunea, data și grupul de rezolvare ca metadate și filtrați după ele la momentul interogării, astfel încât un răspuns pentru NX 2312 să nu fie oferit pentru un mediu 2606.
- Conectarea la instrumentul de tichete. Un webhook la crearea tichetului trimite noul tichet către asistent, care își scrie propunerea înapoi ca un comentariu intern. Niciun răspuns automat către solicitant.
Pașii doi și trei pot începe ca un script. Acesta citește un CSV de tichete, elimină adresele de e-mail și ID-urile de login cu expresii regulate, păstrează doar tichetele închise cu o rezolvare scrisă și le grupează după rezolvare. Doar biblioteca standard; adaptați modelul de login la convenția dumneavoastră de denumire.
import csv
import re
from collections import defaultdict
EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+")
LOGIN = re.compile(r"\b[a-z]{2}\d{4,6}\b") # adapt to your login pattern, e.g. ab12345
def clean(text):
text = EMAIL.sub("<email>", text or "")
text = LOGIN.sub("<user>", text)
return re.sub(r"\s+", " ", text).strip()
resolved = []
with open("tickets_export.csv", newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
if row["status"] != "closed" or not row["resolution"].strip():
continue # open tickets and closed-without-resolution teach nothing
resolved.append({
"id": row["id"],
"product": row["product"], # NX, Teamcenter, NXOpen tool, licence, install
"version": row["version"],
"symptom": clean(row["subject"] + " " + row["description"]),
"resolution": clean(row["resolution"]),
})
# Group tickets that ended in the same resolution: one knowledge unit, many symptoms
by_resolution = defaultdict(list)
for t in resolved:
by_resolution[t["resolution"].lower()].append(t)
with open("knowledge_units.csv", "w", newline="", encoding="utf-8") as f:
w = csv.writer(f)
w.writerow(["resolution", "tickets", "ticket_ids", "products", "versions", "sample_symptoms"])
for res, group in sorted(by_resolution.items(), key=lambda kv: -len(kv[1])):
w.writerow([
res,
len(group),
";".join(t["id"] for t in group),
";".join(sorted({t["product"] for t in group})),
";".join(sorted({t["version"] for t in group})),
" | ".join(t["symptom"][:160] for t in group[:3]),
])Gruparea prin potrivire exactă este în mod deliberat rudimentară; în pipeline-ul real, rezolvările aproape duplicate sunt fuzionate cu embedding-uri, iar un om confirmă fuziunea. Chiar și așa, rezultatul sortat după numărul de tichete este cel mai util document pe care îl produce o administrație CAD într-un an întreg: remedierile care se repetă, cu dovezi atașate. În proiectul de asistent AI privat pentru cunoștințe din studiul nostru de caz, acest audit al corpusului a modelat arhitectura mai mult decât a făcut-o alegerea modelului.
Ce face asistentul la un tichet nou
La fiecare tichet nou, asistentul face patru lucruri și se oprește înaintea celui de-al cincilea: regăsește tichete rezolvate similare, propune un răspuns de primă linie cu surse, redactează schița de răspuns în vocea administratorului și marchează tichetul ca necunoscut atunci când nimic din istoric nu se potrivește. Nu trimite niciodată. AI-ul propune, un om validează.
Iată forma lui, scrisă generic. ID-urile de tichet sunt ilustrative; textul erorii este mesajul pe care NX îl afișează atunci când clientul de licențiere nu poate ajunge la serverul său, așa cum este documentat în firele de discuție din Siemens Community [4] (versiunile mai vechi numesc variabila UGS_LICENSE_SERVER).
NEW TICKET T-2318 (requester: <user>, site: Plant 2)
"NX won't start on my new workstation. Dialog says: License Error:
Cannot connect to license server system. The server (lmgrd) has not
been started yet, or SPLM_LICENSE_SERVER is set to the wrong port@host."
SIMILAR RESOLVED TICKETS (3 of 3 above threshold)
T-1907 reimaged workstation, SPLM_LICENSE_SERVER still pointed at the
old server name -> resolved, KB-041 linked
T-2044 licence service stopped after server patching, restarted
Siemens PLM License Server service -> resolved
T-1622 VPN profile blocked the licence port -> resolved, KB-058 linked
PROPOSED FIRST-LINE ANSWER (sources: T-1907, KB-041)
New workstation + this exact message = most often the environment
variable. Check SPLM_LICENSE_SERVER on the client, expected format
port@host, against the current licence server name in KB-041.
If the value is right, check the licence service (T-2044) and the
VPN profile (T-1622).
DRAFT REPLY FOR ADMIN (edit, then send)
Hi, this message usually means the workstation is looking for the
licence server under an old name. Could you open System Properties >
Environment Variables and send me the value of SPLM_LICENSE_SERVER?
It should read port@host with our current server (see KB-041) ...
UNKNOWN-ERROR FLAG: noTrei detalii contează. Cauzele sunt ordonate după cât de des au rezolvat acest simptom în istoricul acestei companii, nu după ce spune un forum public. Fiecare linie indică un tichet sau un articol KB pe care administratorul îl poate deschide cu un singur clic. Iar schița cere singura informație care decide între cele trei cauze, în loc să le enumere pe toate trei.
Când retrieval-ul nu găsește nimic peste prag, asistentul spune acest lucru și setează marcajul. Acel marcaj este al doilea produs al sistemului: lista erorilor pe care istoricul dumneavoastră nu le-a rezolvat niciodată, care este intrarea pentru lista de erori cunoscute. Lăsați asistentul să răspundă oricum și va produce o presupunere încrezătoare dintr-un forum public. În practică, asta se termină rareori bine.
Acesta rulează ca un POC. Ce lipsește pentru producție: pseudonimizare care rezistă unui audit, SSO și oglindirea permisiunilor, integrarea cu instrumentul de tichete, o buclă de feedback care reindexează zilnic, monitorizare și operare. Închidem decalajul de la “rulează pe mașina mea” la “rulează în enterprise”, cu un chatbot read-only, cu citarea surselor pe primul loc, pe infrastructura dumneavoastră. Începeți cu pilotul NX Knowledge Chatbot.
Metrici și designul pilotului
Un AI pentru helpdesk de inginerie se măsoară cu cifrele pe care helpdesk-ul le are deja, plus două pe care le adaugă asistentul. Fiecare metrică are nevoie de o linie de referință din trimestrul dinaintea pilotului, altfel pilotul nu dovedește nimic. Nu cităm cifre de benchmark pentru că nu există niciuna pentru coada dumneavoastră; tabelul arată ce să măsurați și cum.
| Metric | Definiție | Sursa liniei de referință | Ce compară pilotul |
|---|---|---|---|
| Timp până la primul răspuns | Timpul de la crearea tichetului până la primul răspuns de substanță | Marcaje temporale din instrumentul de tichete, trimestrul trecut | Mediana pentru tichetele cu propunere vs. fără |
| Rezolvare la primul contact | Ponderea tichetelor închise după primul răspuns, fără a fi nevoie de urmărire | Istoricul stărilor | La fel, pentru tichetele la care administratorul a folosit schița |
| Deflecție (evitarea tichetelor) | Ponderea potențialelor tichete la care răspunde chatbot-ul self-service înainte de deschiderea unui tichet | Nemăsurabilă înainte de pilot; numărați sesiunile de chatbot care se încheie fără un tichet | Sesiuni fără tichet vs. total sesiuni |
| Rata de escaladare | Ponderea tichetelor transmise de la prima linie către specialistul NX sau Teamcenter | Istoricul alocărilor | Înainte vs. în timpul pilotului |
| Acceptarea schițelor | Ponderea răspunsurilor redactate trimise nemodificate sau cu editări minore | Nouă; înregistrată de asistent | Tendința pe parcursul săptămânilor de pilot |
| Rata răspunsurilor fundamentate pe surse | Ponderea propunerilor ale căror tichete citate conțin într-adevăr rezolvarea dată | Nouă; eșantionată și evaluată săptămânal de un administrator | Țintă convenită înainte de pilot |
| Rata erorilor necunoscute | Ponderea tichetelor marcate ca inexistente în istoric | Nouă; înregistrată de asistent | Ar trebui să scadă pe măsură ce crește lista de erori cunoscute |
Designul pilotului într-un singur paragraf: o coadă (prima linie NX și Teamcenter), tichetele închise din ultimii doi-trei ani, un administrator care evaluează douăzeci de propuneri pe săptămână față de rezultatul real al tichetului, patru până la șase săptămâni și o decizie go/no-go bazată pe acceptarea schițelor și pe rata răspunsurilor fundamentate pe surse, nu pe cum s-a simțit demo-ul. Recomandarea noastră clară: evaluați rata răspunsurilor fundamentate pe tichete pe care asistentul nu le-a văzut niciodată, inclusiv câteva cu text de eroare deliberat deformat, pentru că “știe când nu știe” decide dacă administratorii îl mai folosesc în săptămâna a treia.
Guvernanță: GDPR, găzduire și pista de audit
Tichetele sunt date personale. Fiecare tichet numește un solicitant și un administrator, majoritatea conțin o adresă de e-mail, multe un hostname care identifică un birou, unele o captură de ecran cu numele unui coleg în bara de titlu. Corpusul este o activitate de prelucrare conform GDPR încă înainte ca primul embedding să fie calculat, iar trei articole modelează designul.
Articolul 4 alineatul (5) definește pseudonimizarea ca prelucrarea datelor cu caracter personal astfel încât acestea “să nu mai poată fi atribuite unei anume persoane vizate fără a se utiliza informații suplimentare” păstrate separat [5]. Aceasta este separarea din pasul trei: substituenți în index, maparea în sistemul de tichete sub controlul de acces existent. Articolul 5 alineatul (1) litera (c), reducerea la minimum a datelor, este motivul pentru care indexul conține simptom, mediu și rezolvare și nimic altceva. Articolul 28 se aplică din momentul în care un furnizor găzduiește orice parte a sistemului: un acord de prelucrare care precizează ce se stochează, unde, pentru cât timp și cine poate citi jurnalele.
În privința găzduirii, poziția noastră este aceeași ca pentru fiecare asistent de inginerie pe care îl construim: on-premise sau într-un cloud din UE aflat sub controlul dumneavoastră, cu permisiunile oglindite din instrumentul de tichete. Un model frontier găzduit, accesat printr-o regiune UE a unui hyperscaler, este acceptabil pentru mulți producători din DACH; un model open-weight pe propriile GPU-uri este răspunsul acolo unde tichetele ating programe supuse controlului exporturilor. Arhitectura de referință se află în articolul nostru despre AI agentic suveran pentru industria producătoare europeană, iar modelul operațional care menține o astfel de platformă în viață după pilot este subiectul studiului nostru de caz privind platforma GenAI enterprise.
Pista de audit transformă un chatbot într-un instrument de helpdesk. Fiecare propunere stochează din ce tichete și articole KB a fost construită, ce versiune de model a scris schița și dacă administratorul a acceptat-o, a editat-o sau a respins-o. Stratul self-service dezvăluie că este un sistem AI, așa cum obligațiile de transparență din articolul 50 al Regulamentului UE privind IA (AI Act) o cer începând cu 2 august 2026. Iar când un tichet este șters în baza unei reguli de retenție sau a unei cereri de ștergere, intrarea din index dispare în același job. Retrieval-ul face din asta o singură linie. Fine-tuning-ul ar fi făcut-o imposibilă.
Întrebări frecvente
Poate fi un AI antrenat cu adevărat pe sistemul nostru de tichete pentru a trata erorile NX și Teamcenter?
Da, dacă “antrenat” înseamnă indexat pentru retrieval. Asistentul regăsește tichetele închise al căror simptom se potrivește cu un tichet nou, propune un răspuns construit din rezolvările lor și le citează. Erorile recurente sunt tratate; erorile noi sunt marcate, nu ghicite. Plafonul este stabilit de câte tichete închise conțin o rezolvare scrisă.
RAG vs. fine-tuning: care este potrivit pentru datele din tichete?
RAG, din trei motive: tichetele se schimbă zilnic și un index se actualizează în câteva minute, în timp ce un model cu fine-tuning este un instantaneu; RAG poate cita tichetul pe care l-a folosit, fine-tuning-ul nu poate; iar datele personale dintr-un index pot fi șterse, în timp ce un nume absorbit în ponderile modelului nu poate fi. Fine-tuning-ul are un rol doar pentru ton, niciodată pentru cunoștințe.
De ce date are nevoie un AI pentru helpdesk de inginerie din tichetele noastre?
Simptom, mediu și rezolvare per tichet, cu datele personale înlocuite prin substituenți (placeholders); produs și versiune ca metadate; un link către un articol KB sau o înregistrare de eroare cunoscută, acolo unde există. Atașamentele contează atunci când textul erorii se află în capturi de ecran, ceea ce în helpdesk-urile CAD se întâmplă des. Tichetele deschise și tichetele închise fără rezolvare sunt lăsate deoparte.
Cât costă configurarea unui AI pentru helpdesk de inginerie?
Pilotul cu preț fix de pe pagina noastră NX Knowledge Chatbot este punctul de referință: corpusul de bază indexat, chatbot cu citarea surselor pe primul loc, live pentru un grup pilot pe infrastructura dumneavoastră, un raport privind calitatea răspunsurilor la întrebări reale, patru până la șase săptămâni, deductibil din costul rollout-ului. Costul mai mare și mai puțin vizibil este de partea dumneavoastră: curățarea exportului de tichete, convenirea regulilor de pseudonimizare cu responsabilul cu protecția datelor și conectarea instrumentului de tichete. Bugetați acele zile înaintea licenței.
Va răspunde asistentul direct solicitanților și va închide tichete?
Nu în designul nostru. Răspunde în chatbot-ul self-service înainte ca un tichet să existe; pe un tichet deschis scrie o propunere internă și o schiță de răspuns pe care administratorul o trimite sau o respinge. Închiderea automată a tichetelor pe baza unui răspuns AI elimină verificarea umană care menține onestă rata răspunsurilor fundamentate pe surse.
Pasul următor
Discutați cu inginerii noștri despre un asistent pe istoricul dumneavoastră de tichete
Subiecte conexe
- NX Knowledge Chatbot: răspunsuri cu surse citate, read-only prin design
- Asistenți și chatboți NX AI: prezentarea generală a familiei
- Ce acoperă Teamcenter Copilot de la Siemens și unde se oprește
Referințe
- Amazon Web Services, “What is RAG (Retrieval-Augmented Generation)?”, https://aws.amazon.com/what-is/retrieval-augmented-generation/, accesat la 24 septembrie 2026.
- Yunfan Gao et al., “Retrieval-Augmented Generation for Large Language Models: A Survey,” arXiv:2312.10997, v5, 27 martie 2024, https://arxiv.org/abs/2312.10997, accesat la 24 septembrie 2026.
- Anthropic, “Introducing Claude Opus 5.5,” 22 septembrie 2026, https://www.anthropic.com/news/claude-opus-5-5, accesat la 24 septembrie 2026.
- Siemens Digital Industries Software Community, “NX License Error: Cannot connect to license server system. The server (lmgrd) has not been started yet, or UGS_LICENSE_SERVER is set to the wrong port@host,” https://community.sw.siemens.com/s/question/0D54O000061wpw6SAA/nx-license-error-cannot-connect-to-license-server-system-the-serverimgrd-has-not-been-started-yet-or-ugslicenseserver-is-set-to-the-wrong-port-host-15, accesat la 24 septembrie 2026.
- European Union, “Regulation (EU) 2016/679 (General Data Protection Regulation),” articolele 4(5), 5(1)(c) și 28, https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng, accesat la 24 septembrie 2026.
- Siemens, “Designcenter is for everyone: June 2026 release,” blogul Designcenter, 23 iunie 2026, https://blogs.sw.siemens.com/designcenter/designcenter-is-for-everyone-june-2026-release/, accesat la 24 septembrie 2026.
