RAG pentru mentenanță și service pe teren: manuale, istoric

Ora șapte dimineața, hala unui client. O linie de ambalare stă. Tehnicianul are o tabletă cu ecran de opt inch, mănuși pe mâini și un semnal de date care apare și dispare. Pe echipament e o plăcuță cu un model care seamănă cu alte patru din catalogul producătorului. În tabletă are un PDF de patru sute de pagini, descărcat acum șase luni.

Întrebarea lui nu e „ce spune manualul despre senzorul de proximitate”. E „ce fac acum, la mașina asta, ca să repornească fără să stric altceva”.

Celelalte cazuri de utilizare din serie presupun un om așezat la un birou. Mentenanța și service-ul pe teren nu. Constrângerea celorlalte e cognitivă: prea mult text, prea puțin timp. Aici constrângerea e fizică. Omul stă în picioare, are mâinile ocupate, se uită la un ecran mic, iar o procedură greșită nu produce un răspuns nesatisfăcător — produce o piesă distrusă, o garanție pierdută sau un accident. Iar dacă garanția e chiar miza, data de la care curge nu stă în manual, ci în procesul-verbal de recepție — momentul în care riscul trece e un corpus în sine, cu regulile lui.

Un sistem RAG pentru mentenanță și service pe teren schimbă arhitectura în trei locuri concrete: cum filtrezi la retrieval, cum tratezi al doilea corpus (istoricul de intervenții) și ce livrezi ca răspuns. Dacă mecanica de bază nu e clară încă, ce este RAG și când îl folosești acoperă fundamentele.

Ce se schimbă la RAG pentru mentenanță și service pe teren

Diagrama arată la fel ca oriunde: întrebare, retrieval, generare, răspuns cu citări. Constrângerile sunt cele care mută arhitectura, iar aici sunt de alt tip.

Trei constrângeri care nu apar la un asistent de birou

Consecința e fizică, nu informațională. La un helpdesk, un răspuns parțial greșit costă cinci minute de reformulare. La un echipament sub tensiune sau sub presiune, costă altceva. Pragul de „suficient de bun” nu se negociază la fel.

Identitatea contează mai mult decât relevanța. Un manual pentru un model vecin poate fi 95% corect și complet nefolositor. Cuplul de strângere diferă. Ordinea de decuplare diferă. Numărul piesei diferă. Un răspuns care sună corect și vine din documentul greșit e cel mai prost rezultat posibil.

Contextul de execuție e ostil. Fără semnal stabil, fără tastatură, adesea cu zgomot și cu o singură mână liberă. Un răspuns de opt paragrafe e inutil chiar dacă e corect.

Delimitarea față de helpdesk-ul intern

Un asistent intern și unul de teren par același produs. Nu sunt.

Diferența nu stă în tehnologie, ci în ce anume definește un răspuns bun. Angajatul de la birou vrea procesul companiei; tehnicianul vrea procedura producătorului pentru exact echipamentul din fața lui. Primul caz are un router de intenție care separă întrebările despre reguli de cele despre starea personală — mecanica e descrisă în RAG pentru helpdesk intern. Al doilea are nevoie de un pas complet diferit: rezolvarea identității echipamentului înainte de orice căutare.

Corpusul e al producătorului — dar, spre deosebire de o licitație, nu expiră

Cel mai apropiat caz din serie ca proprietate a corpusului e RAG pentru licitații și achiziții publice: și acolo documentul e al altcuiva. Diferența e temporală. Documentația de licitație are dată de expirare — după deschiderea ofertelor devine istorie. Manualul de service nu expiră niciodată; el se versionează.

Consecința pentru index: nu construiești un corpus efemer pe care îl arunci, ci unul permanent în care coexistă revizii multiple ale aceluiași document. Iar dacă două revizii ale aceleiași proceduri stau în același index fără să fie distinse, sistemul va alege între ele pe similaritate — adică aleatoriu, din perspectiva ta.

Documentația structurată: ce rezolvă S1000D

Producătorii mari de echipamente nu livrează PDF-uri. Livrează documentație structurată, iar specificația dominantă e S1000D.

Merită înțeleasă pentru că rezolvă, la sursă, exact problema pe care altfel o rezolvi tu prin chunking. Specificația a fost dezvoltată inițial de AeroSpace and Defence Industries Association of Europe pentru aviația militară, iar de la Issue 2 domeniul ei s-a extins la aplicații terestre și navale și la produse civile de orice tip. E menținută în comun de ASD, Aerospace Industries Association și Air Transport Association, iar textul se descarcă gratuit.

Ideea centrală: informația nu se scrie ca document, ci ca data module — unități autonome, în XML, cu metadate proprii, stocate într-o bază de date comună și asamblate în publicații la cerere. Fiecare modul are un cod care spune la ce produs, sistem și subsistem se aplică.

Practic, dacă furnizorul livrează S1000D, ai deja granularitatea și metadatele pe care în orice alt corpus le fabrici singur. Un data module e, de fapt, un chunk cu identitate. Compromisurile din cazul general rămân valabile pentru restul corpusului — strategiile de chunking le detaliază.

Ce se schimbă în ianuarie 2027

Regulamentul (UE) 2023/1230 privind mașinile a fost adoptat pe 14 iunie 2023 și publicat în Jurnalul Oficial pe 29 iunie 2023. Nu se aplică încă: înlocuiește Directiva 2006/42/CE începând cu 20 ianuarie 2027, iar directiva rămâne aplicabilă până pe 19 ianuarie 2027. Confuzia dintre data adoptării și data aplicării e cea mai frecventă eroare în materialele care circulă pe subiect.

Ce aduce, la partea de documentație: instrucțiunile de utilizare pot fi furnizate în format digital. Condițiile din articolul 10 sunt însă specifice — pe echipament trebuie marcat cum se accesează versiunea digitală, formatul trebuie să permită utilizatorului să tipărească, să descarce și să salveze instrucțiunile pe un dispozitiv, iar versiunea digitală trebuie să rămână accesibilă online pe durata de viață așteptată a echipamentului și cel puțin zece ani de la punerea pe piață. La cerere, producătorul furnizează gratuit o versiune pe hârtie, în termen de o lună.

Două consecințe practice pentru un proiect de retrieval:

• Corpusul digital devine obligația explicită a producătorului, nu un serviciu opțional. Un link mort la doi ani după livrare nu mai e o problemă de suport, ci de conformitate.
• Cerința ca utilizatorul să poată salva instrucțiunile local nu e un detaliu de UX. E recunoașterea, în text de lege, că documentația trebuie să fie disponibilă și atunci când echipamentul e oprit și rețeaua lipsește.

Trei straturi de proprietate

Corpusul unui asistent de teren nu e omogen. Tratat ca un bloc, se comportă prost la retrieval.

Documentația producătorului. Manuale, proceduri, scheme, buletine de service. Externă, versionată, autoritară. Nu o modifici.

Documentația proprie. Instrucțiuni de lucru interne, adaptări locale, decizii de tipul „la clientul X, valva se schimbă din doi în doi ani, nu din trei în trei”.

Istoricul de intervenții. Ce s-a făcut efectiv, de cine, cu ce rezultat. Corpusul cel mai valoros și cel mai murdar.

Straturile au autoritate diferită, iar diferența trebuie să fie vizibilă în răspuns. Când instrucțiunea internă contrazice manualul, sistemul nu alege — le arată pe amândouă și spune care de unde vine. Pregătirea generică a surselor e tratată în cum construiești o bază de cunoștințe AI; ce urmează e specific echipamentelor.

Identitatea echipamentului: filtru dur, înainte de similaritate

Aici stă decizia arhitecturală care separă un asistent de teren util de unul periculos.

De ce „aproape identic” e o categorie periculoasă

Într-un sistem obișnuit de retrieval, un document apropiat semantic e un rezultat mai slab. Pierzi puțină precizie, câștigi acoperire, mergi mai departe.

Pe echipamente, gradientul acesta nu există. Două variante ale aceluiași utilaj pot diferi prin poziția unui senzor, prin secvența de blocare a energiei sau prin lubrifiantul prescris. Procedura de la varianta vecină nu e „un răspuns cu 90% acuratețe”. E o instrucțiune greșită, livrată cu încredere.

De aceea identitatea nu poate fi o componentă a scorului de similaritate. Trebuie să fie un predicat aplicat înainte: din întregul index, sistemul caută numai în documentele care se aplică acestui echipament, la această revizie. Restul nu intră în competiție.

E același mecanism ca la controlul accesului, unde filtrarea se face la retrieval, nu prin instrucțiuni în prompt — logica e descrisă pe larg în controlul accesului în RAG. Diferența: acolo filtrezi ce ai voie să vezi, aici filtrezi ce se aplică fizic.

Ce metadate pui pe fiecare chunk

Minimul funcțional, pe fiecare fragment indexat:

• Producător și model, în forma din nomenclator, nu cea din vorbire.
• Interval de serie sau variantă, când procedura diferă pe loturi.
• Revizia documentului și data ei, ca să poți exclude versiunile depășite fără să le ștergi.
• Sistemul și subsistemul vizat — hidraulic, electric, pneumatic, control.
• Tipul de conținut: procedură, specificație, schemă, buletin de service, avertisment de siguranță.
• Nivelul de competență cerut pentru execuție.

Metadatele ca filtru sunt un pattern general, nu o invenție locală. Ce e specific aici e că filtrul nu e opțional și nu e o preferință de ranking: e o condiție de corectitudine. Aceeași logică, aplicată unui articol de catalog care poartă cinci coduri diferite în cinci sisteme, e în RAG pentru achiziții și aprovizionare.

Cum afli identitatea fără să întrebi

Un tehnician nu va tasta modelul complet într-o casetă de căutare. Trei căi, în ordinea fiabilității:

1. Scanare. Cod QR, cod de bare sau plăcuță fotografiată. Cea mai sigură, dacă echipamentul e etichetat. La echipamente vechi, adesea nu e.
2. Ordinul de lucru. Dacă tehnicianul a plecat pe teren cu o comandă din sistemul de mentenanță, echipamentul e deja identificat acolo. Contextul vine gratuit, fără niciun pas în plus.
3. Dezambiguizare conversațională. Sistemul întreabă scurt, cu opțiuni: „Ai în față varianta cu răcire pe apă sau pe aer?”. O întrebare, două butoane, nu un formular.

Ce faci când identitatea rămâne incertă

Regula e simplă și trebuie ținută: dacă echipamentul nu poate fi identificat cu certitudine, sistemul nu ghicește.

Comportamentul corect e să spună explicit ce nu știe, să arate ce a găsit ca fiind comun tuturor variantelor candidate și să marcheze diferențele. „Procedura de mai jos e identică la ambele variante până la pasul 4; de la pasul 5 diferă, iar pentru asta am nevoie să știi care variantă e” e un răspuns onest și utilizabil. Un răspuns complet, dar pentru varianta greșită, nu e.

Istoricul de intervenții: al doilea corpus, scris în altă limbă

Manualul spune ce ar trebui să facă echipamentul. Istoricul de intervenții spune ce face în realitate, la clientul ăsta, de trei ani încoace. Al doilea corpus e adesea mai valoros și aproape întotdeauna mai greu de folosit.

Nepotrivirea de vocabular

Manualul scrie „ansamblu de etanșare al arborelui primar, reper 4471-B”. Tehnicianul a scris în raport „am schimbat simeringul de la intrare”. Ambele descriu aceeași piesă. Niciun model de embedding antrenat pe text general nu are cum să știe asta, pentru că legătura nu există nicăieri în date.

Problema e cunoscută în regăsirea informației ca nepotrivire de vocabular, iar aici apare în forma ei cea mai dură: două corpusuri despre același obiect fizic, scrise de două populații care nu folosesc aceleași cuvinte. Notele de teren sunt telegrafice, pline de prescurtări personale, scrise pe genunchi la finalul intervenției, uneori dictate.

Cum construiești puntea

Trei mecanisme, aplicate împreună: Numărul de reper ca ancoră. E singurul identificator pe care ambele părți îl folosesc identic. Extrage-l din notele de teren și indexează-l ca metadată, nu doar ca text. O intervenție cu reper 4471-B se leagă de secțiunea din manual despre 4471-B fără niciun model între ele.

Un dicționar de echivalențe construit din date reale. Nu îl scrii la birou. Îl extragi din perechile care apar deja în istoric: notele care conțin și forma colocvială, și reperul. Câteva sute de perechi acoperă de obicei majoritatea traficului.

Căutare hibridă. Componenta lexicală prinde reperul și codul de eroare exact; componenta semantică prinde reformularea. Un sistem pur semantic ratează sistematic codurile alfanumerice — motiv pentru care hybrid search și reranking nu e o optimizare opțională aici, ci o cerință.

Ce filtrezi înainte să indexezi

Istoricul de intervenții are aceleași trei defecte ca orice arhivă de tichete, plus unul propriu.

• Intervenții nefinalizate sau eșuate. O notă care descrie o încercare care nu a funcționat, indexată fără marcaj, devine o recomandare.
• Date personale. Nume de operatori, uneori date de contact ale clientului. Se curăță înainte de indexare, cu aceeași disciplină descrisă în RAG și GDPR.
• Soluții expirate. „Se ocolește releul K3” a fost valid până la retrofit-ul de anul trecut.
• Note fără context suficient. „Reglat, funcționează” nu e o informație regăsibilă. Nu o exclude — dar nu o lăsa să concureze cu proceduri complete.

Practic: indexează intervențiile închise cu rezultat confirmat, legate de identitatea echipamentului, marcate în metadate ca sursă de tip istoric — ca răspunsul să poată spune clar că sugestia vine din ce s-a făcut, nu din ce prescrie producătorul.

Documentația vizuală: ce ratează retrievalul pe text

O parte semnificativă din ce caută un tehnician nu e text. E o schemă de cablaj, un desen explodat cu poziții numerotate, o diagramă hidraulică. Un pipeline care extrage text și indexează text trece pe lângă exact informația căutată.

Trei tipuri de vizual, trei tratamente

Scanuri de documente vechi. Manuale tipărite, scanate cândva ca imagine. Aici tratamentul e OCR, cu toate limitele lui pe desene tehnice și pe adnotări scrise de mână — aceeași problemă apare la arhivele de documente semnate, tratată în RAG pe contracte și documente juridice.

Desene native, cu text vectorial. Textul e extractibil, dar contextul spațial se pierde. „Poziția 14” nu înseamnă nimic fără desenul care arată unde e poziția 14.

Diagrame în care relația e informația. Scheme de cablaj, diagrame de proces. Aici nu există reprezentare textuală echivalentă care să păstreze sensul.

Retrieval direct pe imaginea paginii

Pentru al treilea tip a apărut o abordare care ocolește complet extragerea de text: indexezi imaginea paginii, nu textul ei.

Lucrarea ColPali, publicată de Faysse și colegii pe arXiv în 2024, propune exact asta — embeddings multi-vectoriale produse direct din imaginile paginilor de document, cu un mecanism de potrivire de tip late interaction preluat din ColBERT. Aceeași lucrare introduce ViDoRe, un benchmark de regăsire la nivel de pagină pe documente bogate vizual, pe care metoda depășește pipeline-urile clasice bazate pe OCR, analiză de layout și embedding de text.

Două precizări de onestitate. Benchmark-ul e propus de autorii metodei, ceea ce e obișnuit în domeniu, dar înseamnă că cifrele de acolo nu sunt o evaluare independentă. Și, mai important pentru tine: rezultatul e la nivel de pagină. Sistemul îți aduce pagina corectă cu schema, nu componenta din schemă.

Ce înseamnă practic: abordarea merită încercată când corpusul e dominat de scheme și desene, ca strat paralel peste retrievalul pe text — nu ca înlocuitor. Când desenul nu mai e anexă la manual, ci documentul-sursă — cota cu toleranță, revizia care guvernează lotul, modelul BIM interogat structurat — arhitectura se schimbă mai mult decât atât: RAG pe desene tehnice și BIM tratează cazul separat. Iar când o găsești, pagina se livrează ca imagine, cu zona relevantă marcată, nu ca descriere în cuvinte a unei scheme de cablaj.

Offline, ecran mic, mâini ocupate

Constrângerile de produs decid dacă sistemul e folosit sau abandonat după două săptămâni. Ele nu sunt o etapă de UX de la final; se proiectează de la început, pentru că schimbă arhitectura.

Ce cachezi local și ce nu

Nu poți sincroniza tot corpusul pe o tabletă. Nici nu trebuie.

Ce merită local: documentația pentru echipamentele din ordinele de lucru ale zilei, plus procedurile de siguranță relevante. Selecția e derivabilă automat din planificare, cu o zi înainte, cât timp dispozitivul e în rețea.

Ce rămâne în cloud: restul corpusului, istoricul complet, generarea. Un model mic care rulează pe dispozitiv poate acoperi căutarea în cache-ul local, dar sinteza de calitate rămâne, în practică, o operație de rețea.

Comportamentul în degradare trebuie proiectat explicit: fără semnal, sistemul spune că e offline, arată ce are în cache și marchează vizibil ce nu poate verifica. Un răspuns din cache prezentat ca și cum ar fi actual e mai rău decât un mesaj de indisponibilitate.

Formatul răspunsului pentru un om în picioare

Regulile generale de sinteză și format sunt în cum arată un răspuns bun de RAG. Aici se strâng suplimentar:

• Pași numerotați, unul pe rând, nu proză. Tehnicianul citește un pas, execută, revine.
• Avertismentele de siguranță înaintea pasului, nu la finalul răspunsului.
• Citarea ca sursă verificabilă: document, revizie, secțiune. Un tehnician experimentat verifică sursa înainte să atingă echipamentul.
• Răspuns scurt sau întrebare scurtă. Dacă informația lipsește, o întrebare de clarificare bate un paragraf de aproximări.

Sincronizarea, când revine semnalul

Notele scrise offline se sincronizează la revenirea în rețea și devin corpus pentru intervențiile următoare — bucla care face sistemul să se îmbunătățească din utilizare. Merită tratată ca funcționalitate de produs, nu ca detaliu tehnic: dacă introducerea unei note cere zece atingeri de ecran cu mănuși, nu se va întâmpla, iar al doilea corpus rămâne gol.

Granița cu CMMS-ul

Întrebarea apare la fiecare discuție: dacă avem deja un sistem de management al mentenanței, ce mai adaugă un strat de retrieval?

Ce rămâne în CMMS

Tot ce e stare și proces. Ordinele de lucru, planificarea preventivă, stocul de piese, contoarele de ore de funcționare, raportarea de disponibilitate. Sunt date structurate, tranzacționale, cu o sursă unică de adevăr. Un sistem de retrieval nu are ce căuta acolo — la fel cum nu răspunde la „câte zile de concediu mai am”.

Când tehnicianul întreabă „am piesa 4471-B pe stoc în depozitul din Cluj?”, răspunsul nu vine din documente. Vine dintr-un apel către CMMS sau ERP, cu identitatea lui, și se formulează în limbaj natural.

Ce câștigă stratul de retrieval

Regăsirea procedurii corecte pentru echipamentul exact și legarea ei de ce s-a întâmplat deja acolo. Un CMMS stochează istoricul, dar îl expune ca listă filtrabilă, nu ca răspuns; iar manualul producătorului e, în majoritatea instalărilor, un fișier atașat — căutabil ca fișier, nu ca procedură. Valoarea nu e că înlocuiește CMMS-ul, ci că răspunde la o interogare pe care acesta nu o acceptă: „ce s-a mai încercat la eroarea E-217 pe modelul ăsta și ce a funcționat”.

Cele două integrări care contează

Prima: ordinul de lucru ca sursă de context. Deschis un ordin, sistemul știe echipamentul, clientul, istoricul recent și tipul intervenției — fără niciun pas de identificare.

A doua: nota de intervenție ca ieșire. Sinteza a ce s-a făcut, propusă completată, validată de om, scrisă înapoi în CMMS. Aici stă cel mai vizibil câștig de timp, pentru că documentarea e partea pe care toată lumea o amână.

Ce măsori când o eroare are consecință fizică

Instrumentarul general de evaluare — recall la retrieval, faithfulness la generare, set de referință construit din întrebări reale — e descris în cum evaluezi un sistem RAG. Ce se schimbă aici e ponderea și pragul.

Metricile care se schimbă

Acuratețea identității devine metrica principală. Nu recall-ul general, ci: din cazurile testate, în câte a filtrat sistemul pe echipamentul corect? O eroare aici invalidează tot ce urmează, oricât de bine ar arăta restul.

Rata de abținere corectă. Câte dintre întrebările fără acoperire în corpus au primit un refuz explicit în loc de un răspuns plauzibil. Într-un context cu consecință fizică, abținerea e o funcționalitate, nu un eșec.

Setul de test conține deliberat capcane de identitate. Întrebări formulate pentru modele vecine, pentru revizii vechi, pentru variante care nu există. Dacă setul tău conține doar cazuri curate, nu măsoară riscul real.

Competența autorizată ca al doilea filtru

În România, o parte din intervenții nu sunt libere tehnic, ci reglementate. Legea nr. 64/2008 privind funcționarea în condiții de siguranță a instalațiilor sub presiune, a instalațiilor de ridicat și a aparatelor consumatoare de combustibil prevede că lucrările de montare, reparare, întreținere și revizie la echipamentele din domeniul ISCIR se execută de persoane autorizate, iar deținătorul are obligația să asigure la fiecare loc de muncă instrucțiunile tehnice specifice și documentele cu măsurile pentru cazuri de avarie.

Pe partea de energie, autorizarea e la fel de personală. Regulamentul pentru autorizarea electricienilor, aprobat prin Ordinul ANRE nr. 66/2023, leagă gradele de autorizare de limite concrete de putere instalată și tensiune. Iar cadrul se mișcă: în mai 2026, ANRE a aprobat un regulament nou pentru autorizarea operatorilor economici din domeniul gazelor naturale, care înlocuiește integral ordinul anterior din 2021 și acordă operatorilor autorizați sub vechea reglementare un termen de trei luni pentru a dovedi îndeplinirea noilor cerințe.

Trei consecințe de arhitectură:

1. Competența intră ca metadată de filtrare, alături de identitatea echipamentului. Un tehnician fără autorizarea necesară nu ar trebui să primească procedura ca instrucțiune de execuție, ci ca informație cu marcaj clar de restricție.
2. Documentul cu regimul aplicabil trebuie să fie regăsibil, nu doar procedura tehnică. Întrebarea „am voie eu să fac asta?” e la fel de operațională ca „cum se face”.
3. Corpusul de reglementare se versionează separat de cel tehnic, pentru că se schimbă după alt calendar. Un act abrogat rămas în index produce un răspuns confident și greșit.

Ce nu poți măsura din surse publice

Cifrele de tipul „reducere de downtime cu X%” circulă abundent în materialele furnizorilor de software de mentenanță. Nu sunt reproduse aici, din trei motive verificabile: rareori vine o metodologie cu ele; definițiile diferă între surse — downtime planificat sau neplanificat, timp mediu de reparație sau disponibilitate globală; iar sursa e, de regulă, materialul comercial al celui care vinde soluția.

Consecința practică: măsoară-ți propriul punct de plecare înainte de orice implementare. Timpul mediu de la sosirea la echipament până la începerea intervenției efective, procentul de intervenții care necesită o a doua deplasare, procentul de note de intervenție completate în aceeași zi. Trei cifre, culese două-trei săptămâni, valorează mai mult decât orice procent citat din altă parte.

Pragul sub care nu ai nevoie de asta

Dacă ai un singur model de echipament, un manual de o sută de pagini și cinci tehnicieni care îl știu pe de rost, un PDF căutabil rezolvă problema. Investiția are sens de la un anumit prag de eterogenitate: multe modele, revizii care se suprapun, rotație de personal, documentație în mai multe limbi — aceleași variabile decid și cât costă un asistent AI intern. Delimitarea generală e făcută în când NU folosești RAG.

Întrebări frecvente

Cum tratez echipamentele fără documentație digitală?

Le tratezi ca proiect separat de digitalizare, nu ca parte din proiectul de retrieval. Scanarea și OCR-ul unui fond de manuale vechi e o etapă cu cost și durată proprii, iar rezultatul pe desene tehnice rămâne inegal. Pornește de la echipamentele cu documentație deja structurată sau nativ digitală și extinde după ce sistemul e folosit — ordinea inversă blochează proiectul în faza de pregătire a datelor.

Ce fac dacă producătorul nu îmi dă documentația în format prelucrabil?

Verifică întâi contractul de service și condițiile de livrare, apoi termenele de conformitate. Regulamentul (UE) 2023/1230 se aplică de la 20 ianuarie 2027 și clarifică regimul instrucțiunilor digitale, inclusiv obligația ca acestea să poată fi descărcate și salvate. Până atunci, negocierea contractuală rămâne singura cale sigură; extragerea din PDF-uri livrate rămâne posibilă tehnic, dar te lasă cu întreținerea versiunilor în cârcă.

Pot folosi același sistem pentru tehnicieni interni și pentru service extern la clienți?

Componentele se reutilizează, dar corpusurile nu. Un tehnician al furnizorului vede documentația tuturor clienților deserviți; unul al clientului vede doar propriile echipamente. Segmentarea se face la retrieval, pe apartenența echipamentului, iar identitatea utilizatorului trebuie să vină din sursa autoritară, nu dintr-un câmp editabil.

Cât de mult istoric merită indexat?

Cât acoperă cel puțin un ciclu complet de mentenanță preventivă pentru echipamentele din parc, plus intervențiile corective din aceeași perioadă. Mai vechi de un retrofit sau de o schimbare majoră de revizie, istoricul devine mai degrabă sursă de confuzie decât de informație — dacă îl păstrezi, marchează-l explicit ca fiind anterior modificării.

Cum împiedic sistemul să dea o procedură de la un model apropiat?

Prin filtrare dură pe identitate înainte de căutarea semantică, nu prin instrucțiuni în prompt. Dacă documentul a intrat în context, modelul îl va folosi. Verificarea se face la retrieval, ca predicat pe metadate, iar cazurile de identitate ambiguă se testează explicit în setul de evaluare.

Merită un model care rulează local pe dispozitiv?

Pentru căutarea în cache-ul offline, da, dacă intervențiile au loc frecvent în zone fără acoperire. Pentru sinteză, calitatea rămâne de partea unui model rulat în rețea. Configurația pragmatică e hibridă, cu diferența comunicată vizibil utilizatorului.

Un asistent de teren care funcționează nu e un proiect de model. E un proiect de identitate a echipamentului, de punte între două vocabulare și de comportament la conectivitate slabă — în ordinea asta. Restul cazurilor din serie stau în cazuri de utilizare enterprise, iar imaginea completă a unui sistem livrat cap-coadă e în hub-ul de soluții AI și RAG. Dacă pornești mâine, începe cu inventarul: câte modele, câte revizii, cât istoric — sunt cifrele care decid dacă ai o problemă de retrieval sau doar un PDF prost organizat.