Un sistem AI local pentru echipă funcționează ca un serviciu intern: angajații îl folosesc din browser sau dintr-o aplicație, iar modelul rulează pe calculatorul ales de firmă. Implementarea trebuie să lege accesul, documentele și capacitatea disponibilă. Cinci conturi create și cinci cereri executate simultan reprezintă cerințe diferite, care se verifică separat înaintea lansării.

Pornește de la activitățile echipei

Inventariază cine va folosi sistemul, pentru ce operațiuni și la ce ore. Un birou comercial poate pregăti răspunsuri scurte în timpul zilei, în timp ce procesarea unui lot de documente rulează după program. O echipă tehnică poate trimite cereri mai lungi, cu fișiere de cod. Aceste profiluri cer resurse diferite chiar dacă numărul angajaților este identic.

Separă conversațiile interactive de sarcinile de lot și notează durata acceptată pentru fiecare. Pentru început, o stație cu 64 GB RAM, GPU de 16 GB și un model instruct de 8B reprezintă un profil de pilot pentru cereri scurte. Numărul de cereri active și contextul sunt parametri ai probei. Ei se stabilesc prin măsurare pe configurația instalată.

Arhitectura serviciului intern

  1. Angajat

    Browser sau aplicație, cu un cont individual.

  2. Acces controlat

    Rețea aprobată, HTTPS și autentificare.

  3. Aplicație

    Permisiuni, documente, coadă și evidența cererii.

  4. Motor local

    Modelul este executat pe stația firmei.

Dispozitivul utilizatorului și calculatorul modelului au roluri distincte.

Construiește traseul de acces în rețeaua firmei

Calculatorul cu modelul poate găzdui motorul și o aplicație web internă. Dispozitivele angajaților afișează interfața și transmit cereri; modelul rămâne pe stația centrală. Astfel, laptopul fiecărui angajat nu trebuie echipat cu aceeași placă video. Stabilitatea rețelei, autentificarea și disponibilitatea stației centrale devin componente ale serviciului.

Când aplicația și motorul rulează pe același calculator, motorul poate rămâne accesibil doar local. Interfața este expusă controlat printr-un reverse proxy, cu HTTPS și acces din rețeaua aprobată. Pentru angajații aflați în afara biroului, accesul poate trece prin VPN. Firewall-ul permite numai conexiunile necesare, iar portul motorului nu devine un serviciu public pentru utilizatori necunoscuți.

Cabluri albastre conectate la un panou de rețea
Brett Sayles

Conturile și rolurile sunt parte din proiect

Fiecare angajat folosește un cont identificabil. Administratorul gestionează aplicația și configurațiile, iar utilizatorii primesc funcțiile și colecțiile necesare muncii lor. O interfață precum Open WebUI poate furniza administrare de utilizatori și permisiuni, în condițiile versiunii instalate. Modelul conversațional rămâne o componentă separată de mecanismul de autentificare.

Testează explicit cu un utilizator obișnuit, nu numai cu administratorul. Un document vizibil administratorului poate fi ascuns altui rol. La plecarea unui angajat se dezactivează contul și se revocă sesiunile sau cheile asociate. Integrarea cu identitatea firmei se configurează astfel încât schimbările de acces să se aplice și aplicației AI.

Documentele au nevoie de permisiuni proprii

Construiește colecții după responsabilitate: proceduri comune, documentație comercială, materiale tehnice sau documente cu acces limitat. Aplicația verifică dreptul de citire înainte de selectarea pasajelor pentru model. Instrucțiunea „nu arăta documentele colegilor” dintr-un prompt nu înlocuiește filtrarea aplicată în cod și în stratul de regăsire.

Un test util folosește două conturi și același document cu acces restricționat. Contul autorizat trebuie să poată găsi informația; celălalt trebuie blocat atât la fișier, cât și la rezultatele indexului. Repetă proba după schimbarea rolurilor și după reindexare. Păstrează drepturile documentului și atunci când el este împărțit în fragmente.

Accesul se aplică înaintea răspunsului

  1. Identificăm

    Contul și rolul utilizatorului.

  2. Filtrăm

    Documentele și fragmentele pe care le poate citi.

  3. Generăm

    Modelul primește numai contextul autorizat.

  4. Verificăm

    Rezultatul păstrează sursele și regulile aplicației.

Un prompt nu înlocuiește autorizarea aplicată tehnic.

Dimensionează cererile active și contextul

Mai multe conversații pot folosi același model încărcat, în condițiile motorului ales, dar cererile active au nevoie de resurse pentru context și execuție. Un număr mare de tokeni pe cerere poate reduce spațiul disponibil pentru paralelism. În fișa serviciului notează modelul, cuantizarea, contextul maxim acceptat și limita cererilor active.

Rulează aceeași probă întâi cu o cerere, apoi cu două cereri simultane și, dacă resursele permit, cu un nivel suplimentar. Măsoară durata totală și timpul de așteptare pentru fiecare utilizator. Capacitatea acceptată este nivelul care respectă criteriile firmei în acea probă. Numărul conturilor rămâne o măsură administrativă, nu o declarație despre debitul sistemului.

Folosește o coadă pentru sarcinile care pot aștepta

La nivelul aplicației, o coadă poate reține cererile până când sunt disponibile resurse. Sarcinile primesc identificator, stare și rezultat, iar utilizatorul vede dacă operațiunea este în așteptare, activă sau încheiată. Pentru loturi se stabilește o limită de dimensiune și o politică de reluare care previne executarea dublă a aceleiași operațiuni.

Procesele interactive și cele de lot pot primi ferestre sau priorități distincte în aplicația integrată. De exemplu, indexarea unei arhive se poate programa după program, iar conversațiile scurte rămân disponibile ziua. Această organizare se implementează și se testează; nu se presupune că orice interfață de chat oferă automat toate regulile de planificare necesare firmei.

Capacitatea are trei numere diferite

  1. Conturi

    Cine are dreptul să folosească aplicația.

  2. Cereri în așteptare

    Ce sarcini sunt păstrate în coadă.

  3. Cereri active

    Ce execută motorul în același timp.

Numerele se stabilesc prin administrare și testare, nu printr-o echivalare automată.

Administrează serviciul ca pe o aplicație de business

Stabilește cine verifică spațiul liber, procesele, backupurile și erorile. O actualizare se testează pe o copie înainte de activare, iar configurația anterioară se păstrează pentru revenire. Evidența operațională poate include modelul, durata, starea și identificatorul cererii. Conținutul conversațiilor se păstrează numai conform scopului și politicii definite pentru sistem.

WebHat folosește un sistem AI local personalizat și oferă consultanță pentru accesul echipei, dimensionare și integrare. Un proiect de aplicație custom cu AI poate include cozi și roluri specifice, iar protecția datelor în aplicații AI se proiectează împreună cu permisiunile. Recepția verifică funcționarea din conturi diferite, cererile simultane, restartul și restaurarea.

Întrebări despre folosirea în echipă

Fiecare angajat are nevoie de GPU?

În arhitectura cu serviciu central, GPU-ul aparține stației care execută modelul. Dispozitivele angajaților au nevoie de acces la interfața și rețeaua aprobate.

Cum aleg numărul de utilizatori simultani?

Prin probe cu modelul, contextul și sarcinile reale. Limita cererilor active se stabilește după memorie, timp de răspuns și regulile de lucru ale echipei.

Pot utiliza sistemul colegii care lucrează de acasă?

Da, printr-un traseu de acces configurat pentru firmă, de exemplu VPN, cu autentificare și permisiuni individuale. Conectarea se testează din dispozitivele folosite efectiv.

Ce se întâmplă când stația centrală este oprită?

Serviciul AI devine indisponibil. Aplicația trebuie să afișeze starea corectă, să păstreze sarcinile conform politicii și să ofere traseul de lucru stabilit pentru această situație.