Insight / AI Systems
Modelul nu este sistemul AI.
Un model poate genera răspunsuri. Un sistem AI trebuie să poată lucra cu context, knowledge, tools, permissions, workflow, evaluare și control.
Diagramă: modelul ocupă inițial tot cadrul. În jurul lui apar componentele unui sistem AI — context, knowledge, retrieval, tools, workflow, permissions, guardrails, human review, evaluation, observability și feedback — iar modelul rămâne una dintre ele. Cadrul complet se numește sistem AI.
Un demo poate funcționa cu un model și un prompt. Production nu.
Aproape orice organizație are deja un prototip care funcționează. De obicei este convingător. Și, de obicei, funcționează din motive care dispar în momentul în care sistemul iese din mâinile celui care l-a construit.
Un prototip funcționează pentru că cineva furnizează manual contextul potrivit, pentru că operatorul știe exact ce să întrebe, pentru că un răspuns greșit este tolerat, pentru că nu există permisiuni reale, pentru că output-ul nu declanșează nicio acțiune în sisteme, pentru că evaluarea este informală și pentru că nici scala, nici observabilitatea nu contează încă.
Un sistem care intră în producție trebuie să răspundă la un set complet diferit de întrebări. Nu despre calitatea modelului, ci despre arhitectura din jurul lui.
- Q—01De unde vine contextul?Cine îl asamblează, din ce surse și în ce moment al execuției.
- Q—02Care surse sunt de încredere?Ce este source of truth și ce este doar o copie a acesteia.
- Q—03Ce poate accesa sistemul?Date, documente, înregistrări — pentru ce identitate și în ce scope.
- Q—04Ce poate să facă?Ce acțiuni sunt permise, cu ce limite și cu ce efecte în alte sisteme.
- Q—05Ce se întâmplă când greșește?Cum este detectat, cum este oprit și cum este corectat efectul.
- Q—06Cine verifică acțiunile cu impact mare?Unde intervine un om și pe baza cărei informații decide.
- Q—07Cum este evaluat comportamentul?Pe ce cazuri, cu ce criterii și cu ce frecvență.
- Q—08Cum este observată execuția?Ce urme lasă un run și cât de ușor poate fi reconstituit traseul lui.
Notă Niciuna dintre aceste întrebări nu se rezolvă schimbând modelul. Toate se rezolvă în arhitectura sistemului care îl înconjoară.
Modelul este motorul de reasoning și generation. Sistemul îi dă limite, context și capacitatea de a acționa.
Distincția nu este semantică. Un model primește o intrare și produce o ieșire. Un sistem AI decide ce intrare merită produsă, ce informație este legitimă în acel moment, ce are voie să facă rezultatul și ce se întâmplă mai departe cu el.
Model
Perimetru Un apel. Fără stare, fără acces, fără consecință.
Sistem AI
Perimetru Un proces. Cu stare, cu permisiuni și cu efecte reale.
FIG. 01 — Același model, două arhitecturi diferite
Capabilitatea modelului nu compensează o arhitectură slabă.
01 / Context
AI-ul nu poate lua o decizie bună din contextul pe care nu îl are.
Cele mai multe răspunsuri slabe nu vin dintr-un model slab. Vin dintr-un context incomplet, învechit sau irelevant pentru sarcina cerută.
Contextul nu este un singur lucru. Într-un sistem operațional el se compune din mai multe straturi care se schimbă în ritmuri diferite și care au surse diferite de autoritate.
Context de utilizator
Cine cere, cu ce rol, în ce limbă și cu ce nivel de acces.
Context de organizație
Reguli interne, terminologie proprie, structură, entități, politici.
Stare de workflow
Unde se află procesul acum și ce pași au fost deja executați.
Context de task
Ce anume trebuie produs, în ce format și pentru ce destinație.
Permisiuni
Ce are voie să vadă și ce are voie să facă identitatea curentă.
Context istoric
Ce s-a întâmplat anterior în același dosar, proces sau relație.
Starea curentă a sistemului
Ce spun acum sursele operaționale, nu ce spuneau la ultima indexare.
Diferența practică dintre un sistem stabil și unul imprevizibil este adesea aceasta: contextul este asamblat deliberat, pe baza unor reguli explicite, sau este lipit nediferențiat într-un prompt, în speranța că modelul va alege singur ce contează.
Context engineering înseamnă să decizi ce trebuie să știe sistemul acum.
Nu tot ce este disponibil este și relevant. Un context bun este o decizie de proiectare: ce intră, în ce ordine, din ce sursă și cu ce prioritate.
Fereastra de context are o limită practică, iar informația irelevantă concurează cu cea utilă. Asta face din selecție o problemă de inginerie, nu de formulare.
- 01RelevanțăInformația are legătură directă cu sarcina curentă, nu doar cu subiectul general.
- 02ProspețimeVersiunea folosită este cea curentă, iar vechimea ei este cunoscută și verificabilă.
- 03ScopeContextul este limitat la entitatea, dosarul sau perioada care contează.
- 04AutoritateCând două surse se contrazic, sistemul știe dinainte care are prioritate.
- 05Constrângeri de contextSpațiul disponibil este tratat ca resursă limitată, alocată explicit între tipurile de informație.
- 06Structurat vs nestructuratDatele care există deja ca înregistrări nu sunt transformate inutil în text liber.
- 07Asamblare deterministăAceleași condiții produc același context — altfel comportamentul nu poate fi reprodus sau depanat.
- 08Metadate contextualeSursa, data, proprietarul și nivelul de acces circulă împreună cu informația.
Precizare Nu există o singură implementare corectă. Ponderea fiecărui criteriu depinde de domeniu, de riscul acțiunii și de calitatea surselor disponibile.
02 / Knowledge
Knowledge-ul organizației trebuie să fie accesibil fără să devină un dump de documente.
Cunoașterea unei organizații nu stă într-un singur loc și nu are aceeași valoare peste tot. O parte este în documente, o parte în înregistrări structurate, iar o parte doar în capul oamenilor care operează procesul.
Înainte de orice decizie de indexare, sistemul are nevoie de un răspuns la o întrebare simplă: care este sursa de adevăr pentru fiecare tip de informație și cine răspunde de ea.
Sisteme sursă
ERP, CRM, aplicații interne — locul unde datele se schimbă efectiv.
Documente
Contracte, proceduri, specificații, corespondență, materiale tehnice.
Înregistrări structurate
Informație care nu trebuie interpretată, ci citită exact.
Metadate
Tip, entitate, perioadă, versiune, stare, apartenență.
Ownership
Cine menține informația și cine decide când este depășită.
Autoritatea sursei
Ierarhia dintre surse, stabilită înainte de conflict, nu după.
Prospețime
Cât de repede trebuie să se reflecte o schimbare în ceea ce vede sistemul.
Permisiuni
Cine are dreptul să vadă fiecare document, la nivel de sursă.
Retrieval-ul bun începe înainte de embeddings.
Structură · metadate · ownership · permisiuniRAG nu este „search + prompt”.
Într-un demo, retrieval-ul poate fi o singură căutare urmată de un prompt. Într-un sistem de producție este un pipeline cu mai mulți pași, fiecare cu propriile moduri de eșec.
Partea interesantă nu este stocarea vectorilor. Sunt deciziile luate înainte și după: cum este structurată informația, ce metadate o însoțesc, cine are voie să o vadă și ce se întâmplă cu rezultatele înainte să ajungă în context.
Observație Trasabilitatea sursei face răspunsul verificabil de către un om. Nu garantează corectitudinea lui.
Uneori modelul nu greșește. Sistemul i-a dat informația greșită.
Când un răspuns este greșit, prima reacție este să fie acuzat modelul. De multe ori însă modelul a procesat corect exact ce a primit — iar problema este într-un pas anterior, care nu se vede în interfață.
Surse învechite
Documentul indexat nu mai este versiunea validă.
Metadate lipsă
Nu se poate filtra după entitate, perioadă sau versiune.
Retrieval slab
Rezultatele sunt apropiate semantic, dar nu răspund întrebării.
Scope greșit
Informația vine din alt dosar, alt client sau altă perioadă.
Conținut duplicat
Aceeași informație în variante diferite, fără ierarhie între ele.
Sursă autoritativă inaccesibilă
Documentul corect există, dar nu ajunge niciodată în context.
Chunk-uri irelevante
Fragmentarea a rupt exact partea care dădea sens informației.
Retrieval necontrolat
Efect Răspunsul pare la fel de sigur ca unul corect. Diferența nu se vede în text.
Retrieval controlat
Efect Răspunsul poate fi verificat față de sursele folosite. Nu devine automat corect.
FIG. 04 — Aceeași generare, două calități de intrare
03 / Tools
Un sistem AI devine operațional când poate lucra cu sisteme reale.
Atâta timp cât produce doar text, un sistem AI rămâne un asistent de redactare. Devine parte din operațiune abia când poate citi o înregistrare, calcula ceva, genera un document sau actualiza o stare.
Aici crește însă și miza: fiecare tool este o poartă către un sistem real, cu efecte reale.
- T—01Scheme expliciteFiecare tool are un contract clar de intrare și ieșire, nu o descriere aproximativă.
- T—02Acces limitatTool-ul primește exact permisiunile necesare, în contextul identității curente.
- T—03ValidareParametrii sunt verificați determinist înainte de execuție, nu doar interpretați.
- T—04AuditFiecare apel rămâne înregistrat: cine, ce, cu ce parametri, cu ce rezultat.
- T—05Tratarea eșeculuiEroarea are un comportament definit — retry, escaladare sau oprire — nu un răspuns improvizat.
Un tool call este un contract software, nu magie.
Modelul nu execută nimic. Propune o intenție structurată. Ce se întâmplă între acea intenție și efectul real în sistem este cod obișnuit — validare, autorizare, execuție, tratare de erori — și se proiectează după aceleași reguli ca orice integrare.
Validarea intrării
Tipuri, limite, entități existente, valori permise. Un parametru plauzibil nu este automat un parametru valid.
Permisiuni la execuție
Autorizarea se face în momentul apelului, pentru identitatea reală — nu la nivelul interfeței.
Comportament la retry
Ce se reîncearcă, de câte ori și în ce condiții, ca reluarea să nu producă efecte duplicate.
Idempotență, unde contează
Pentru acțiunile care modifică stare, aceeași cerere executată de două ori ar trebui să aibă un singur efect.
Eșec sigur
Când ceva nu funcționează, sistemul se oprește într-o stare cunoscută și o raportează explicit.
Rezultat structurat
Ieșirea tool-ului revine în flux ca dată verificabilă, nu ca text de interpretat din nou.
04 / Workflow
Nu orice task trebuie rezolvat într-un singur model call.
Un apel unic care trebuie să clasifice, să caute, să analizeze, să decidă și să acționeze în același timp este greu de evaluat și aproape imposibil de depanat.
Descompunerea în pași nu este birocrație. Este ceea ce face comportamentul observabil, testabil și reparabil pe bucăți.
Ce rămâne determinist
Rutare, calcule, verificări de reguli, validări de format. Acolo unde comportamentul exact contează, codul rămâne cod.
Unde intră AI-ul
În pașii care cer interpretare: clasificare, extragere, sinteză, formulare. Acolo unde ambiguitatea este reală.
Starea, explicită
Fluxul știe în ce pas se află și de ce. Starea nu se deduce din istoricul conversației.
Agentic nu trebuie să însemne autonomie nelimitată.
Un agent este, în esență, o buclă controlată: observă, decide un pas următor, folosește un tool, evaluează rezultatul și continuă sau se oprește.
Bucla devine utilă când limitele ei sunt proiectate: câți pași are voie să facă, ce tool-uri poate atinge, ce înseamnă „gata” și ce se întâmplă când nu ajunge acolo. Fără aceste limite, un agent nu este mai autonom — este doar mai greu de oprit.
Planning
Descompunerea sarcinii în pași, cu posibilitatea de a fi inspectată.
Tool use
Un set închis de acțiuni permise, nu acces general la sisteme.
State
Ce s-a făcut deja, ce a eșuat și ce rezultat a fost obținut.
Stopping conditions
Limite de pași, de timp și de cost, plus o definiție clară a finalizării.
Permissions
Bucla moștenește drepturile identității în numele căreia rulează.
Observation
Fiecare iterație lasă o urmă operațională verificabilă.
Human escalation
Un traseu clar către un om atunci când bucla nu poate încheia sarcina.
Autonomia trebuie proporțională cu costul greșelii.
Impact redus și reversibil → mai multă autonomie · Impact mare sau ireversibil → mai mult control05 / Permissions
AI-ul trebuie să vadă și să poată face doar ceea ce contextul îi permite.
Un sistem AI moștenește drepturile identității în numele căreia rulează. Dacă acele drepturi sunt mai largi decât ale utilizatorului, sistemul devine o cale ocolită de acces la date.
Regula practică: autorizarea se aplică la retrieval și la execuție, nu la afișare. Ascunderea unui element în interfață nu este o formă de autorizare.
- P—01Identitatea utilizatoruluiCererea rulează pentru o persoană concretă, nu pentru un cont tehnic cu drepturi largi.
- P—02RolulCe categorie de operațiuni este permisă în general acelui rol.
- P—03Contextul de organizațieÎn sisteme cu mai multe entități, separarea trebuie garantată la nivelul datelor.
- P—04Scope de dateCe înregistrări și documente intră efectiv în retrieval pentru acea identitate.
- P—05Scope de acțiuniCe tool-uri pot fi apelate și cu ce limite de efect.
06 / Guardrails
Guardrails bune controlează acțiunea, nu doar formularea răspunsului.
Cele mai multe discuții despre guardrails se opresc la ton și la conținutul textului. Într-un sistem operațional, riscul nu este ce spune sistemul, ci ce face.
Un guardrail util este, cel mai des, o verificare deterministă plasată între intenție și efect.
Validarea intrării
Cererea este verificată înainte de a intra în flux: format, entități, drepturi.
Validarea ieșirii
Structura rezultatului este verificată programatic, nu doar citită.
Policy checks
Reguli interne și cerințe de conformitate aplicate ca verificări explicite.
Tool-uri permise
Setul de acțiuni disponibile depinde de context, nu este constant.
Limite de acțiune
Praguri de valoare, volum sau frecvență, dincolo de care execuția se oprește.
Verificări deterministe
Ce poate fi verificat cu cod nu este lăsat în seama interpretării.
Escaladare
Cazurile care nu trec verificările merg către un om, nu către o aproximare.
Operațiuni restricționate
Acțiuni ireversibile scoase complet din perimetrul automat.
Limită Guardrails reduc probabilitatea și amploarea unei greșeli. Nu elimină riscul și nu înlocuiesc evaluarea sau supravegherea umană.
07 / Human
Human-in-the-loop nu este un compromis. Este o componentă de arhitectură.
Revizuirea umană este tratată adesea ca o etapă temporară, care va dispărea când sistemul devine „suficient de bun”. În practică, ea este pur și simplu locul în care arhitectura recunoaște costul unei greșeli.
Întrebarea corectă nu este dacă există revizuire umană, ci unde este plasată și ce informație primește omul ca să poată decide rapid.
Decizii cu impact mare
Efect financiar, contractual sau operațional semnificativ.
Cazuri ambigue
Contextul disponibil nu este suficient pentru o decizie clară.
Comunicare externă
Orice iese din organizație către client, partener sau autoritate.
Acțiuni ireversibile
Ce nu poate fi anulat nu se execută fără confirmare.
Rezultate cu încredere scăzută
Sistemul semnalează singur când nu are baza necesară.
Fluxuri sensibile la conformitate
Acolo unde trasabilitatea deciziei este o cerință, nu o preferință.
08 / Evaluation
Nu poți îmbunătăți un sistem AI dacă nu poți evalua comportamentul lui.
Fără evaluare, orice modificare devine o presupunere. Un prompt schimbat, o sursă nouă, alt model — nimic nu poate fi confirmat ca îmbunătățire, doar resimțit ca atare.
Evaluarea utilă este specifică sarcinii. Nu există o metrică universală care să spună dacă un sistem AI „funcționează bine”; există criterii legate de ce trebuie să producă acel sistem, în acel domeniu.
- E—01Evaluare specifică sarciniiCriteriile vin din domeniu și din decizia pe care sistemul o sprijină.
- E—02Cazuri de test cunoscuteSituații reale, cu rezultat așteptat stabilit împreună cu oamenii care fac azi munca.
- E—03Seturi de regresieCazurile deja rezolvate rămân verificate după fiecare modificare.
- E—04Evaluarea retrieval-uluiSeparat de generare: a fost adus documentul potrivit sau nu?
- E—05Validitatea ieșirii structurateRezultatul respectă schema așteptată și poate fi consumat de sistemele următoare.
- E—06Corectitudinea apelurilor de toolTool-ul potrivit, cu parametrii potriviți, în momentul potrivit.
- E—07Judecată umană, unde este necesarăPentru calitate, nuanță și adecvare, verificarea automată nu este suficientă.
- E—08Feedback din producțieCe a fost corectat, respins sau refăcut de utilizatori devine material de evaluare.
Precizare Un set de evaluare descrie comportamentul pe cazurile incluse în el. Nu garantează comportamentul pe cazuri pe care nu le conține.
Un model bun într-un pipeline slab poate produce un produs slab.
Când rezultatul final este nesatisfăcător, cauza poate fi în oricare dintre straturi. De aceea evaluarea are nevoie de niveluri: altfel, singura concluzie posibilă rămâne „modelul nu este suficient de bun”.
09 / Observability
Sistemul trebuie să poată explica traseul operațional al unei execuții.
Când cineva întreabă „de ce a răspuns așa?”, răspunsul util nu este o speculație despre raționamentul modelului. Este traseul operațional: ce a fost cerut, ce surse au fost aduse, ce tool-uri au fost apelate, ce validări au trecut.
Aceste artefacte sunt aceleași pe care le are orice sistem distribuit serios — doar că aici trebuie corelate într-un singur run.
Metadate de cerere
Identitate, moment, scope, versiunea configurației folosite.
Referințe de surse
Ce documente și înregistrări au fost aduse, în ce versiune.
Apeluri de tool
Ce a fost apelat, cu ce parametri și cu ce rezultat.
Starea workflow-ului
Pașii parcurși și tranzițiile dintre ei.
Latență
Timpul pe fiecare pas, nu doar durata totală.
Erori
Unde s-a oprit execuția și ce comportament de recuperare s-a aplicat.
Rezultate de validare
Ce verificări au trecut, care au eșuat și ce a urmat.
Output vizibil
Ce a primit efectiv utilizatorul și ce a făcut cu acel rezultat.
Limită de proiectare Observabilitatea acoperă execuția, nu raționamentul intern al modelului. Un sistem serios nu pretinde că afișează gândirea modelului și nu construiește interfețe în jurul unei asemenea afirmații — folosește urme operaționale verificabile.
Failure-ul AI nu este un singur tip de failure.
„Sistemul a greșit” nu este un diagnostic. Arhitectura ar trebui să distingă între tipurile de eșec, pentru că fiecare are altă cauză, altă metodă de detectare și altă remediere. Un eșec de retrieval nu se rezolvă schimbând modelul, iar un eșec de permisiuni nu se rezolvă îmbunătățind prompt-ul.
- F—01Retrieval failureInformația corectă există, dar nu a fost adusă. Se remediază în indexare, filtre și rerank.
- F—02Context failureInformația a fost adusă, dar nu a ajuns utilizabilă în context. Se remediază în asamblarea contextului.
- F—03Model failureContextul era corect, interpretarea nu. Se remediază prin instrucțiuni, structură sau alt model.
- F—04Tool failureApel greșit, parametri invalizi sau serviciu indisponibil. Se remediază în schema și tratarea erorilor.
- F—05Permission failureAcces prea larg sau prea îngust. Se remediază în modelul de autorizare, nu în AI.
- F—06Workflow failurePași în ordine greșită sau stare pierdută. Se remediază în orchestrare.
- F—07Stale-data failureTotul a funcționat corect, pe informație depășită. Se remediază în ingest și prospețime.
- F—08Validation failureRezultatul nu respectă structura sau regulile așteptate. Se remediază în verificările deterministe.
Un sistem care nu-și poate clasifica propriile eșecuri nu poate fi îmbunătățit metodic.
Sistemele AI robuste combină logică deterministă cu componente probabilistice.
Cele două nu concurează. Se completează — cu condiția ca granița dintre ele să fie o decizie de arhitectură, nu o consecință a entuziasmului.
Determinist
Criteriu Comportamentul exact contează și trebuie să fie identic de fiecare dată.
Probabilistic
Criteriu Intrarea este ambiguă și interpretarea aduce valoare reală.
Regula de proiectare este simplă de formulat și greu de respectat sub presiune: AI acolo unde ambiguitatea cere interpretare, cod acolo unde comportamentul exact contează.
Memory nu este același lucru cu knowledge.
Knowledge este ce știe organizația. Memory este ce reține sistemul despre o interacțiune, un utilizator sau un proces. Confuzia dintre ele produce sisteme care își amintesc lucruri irelevante și uită exact ce conta.
Fiecare tip de memorie are alt ciclu de viață, altă sursă de adevăr și alte implicații de confidențialitate.
- M—01Stare de sesiuneCe este relevant acum și dispare la final. Durată scurtă, cost mic al ștergerii.
- M—02Stare de conversațieCe s-a spus până acum într-un schimb — util pentru continuitate, nu pentru adevăr.
- M—03Preferințe de utilizatorSetări explicite, asumate de utilizator, nu deduse tăcut din comportament.
- M—04Stare de workflowUnde se află procesul. Aparține sistemului operațional, nu conversației.
- M—05Evenimente istoriceCe s-a întâmplat efectiv, păstrat în sistemele care dețin acele înregistrări.
- M—06Knowledge de organizațieInformația partajată, cu ownership și versiune — nu memorie personală a unui agent.
Atenție Memoria pe termen lung acumulată nediferențiat devine repede o sursă de context greșit: informație veche, dedusă sau specifică unei singure situații, aplicată în contexte în care nu mai este validă.
Agentul trebuie să știe unde este procesul, nu doar ce s-a spus în conversație.
Istoricul conversației descrie un dialog. Starea operațională descrie un proces. Când sistemul deduce starea din conversație, orice reformulare, reluare sau întrerupere devine o sursă de comportament imprevizibil.
Istoric de conversație
Este o secvență de mesaje. Poate fi editat, reluat sau abandonat. Nu are garanții de consistență și nu poate fi interogat de alte sisteme.
Stare operațională
Este o valoare persistată, cu tranziții permise, verificabilă din exterior și folosită de restul sistemului pentru a decide ce urmează.
AI-ul devine produs când dispare dintr-un tab separat și intră în workflow.
Un asistent într-o fereastră separată cere utilizatorului să iasă din munca lui, să reformuleze contextul și să aducă rezultatul înapoi manual. Costul acestei plimbări anulează, de multe ori, câștigul.
Când AI-ul stă în punctul de decizie — în ecranul unde omul oricum lucrează — contextul este deja acolo, iar rezultatul intră direct în flux.
Recomandare în punctul de decizie
Sugestia apare unde se ia decizia, nu într-un raport separat.
Redactare contextuală
Documentul pornește din datele dosarului, nu de la o pagină goală.
Validare
Verificarea completitudinii și a coerenței înainte de trimitere.
Extragere
Informația din documente devine câmpuri structurate, utilizabile mai departe.
Sinteză
Un rezumat operațional al unui dosar, nu un rezumat generic al unui text.
Search
Căutare care înțelege întrebarea și respectă drepturile de acces.
Sugestia pasului următor
Ce urmează în proces, pe baza stării reale a fluxului.
Detectarea anomaliilor
Semnalarea cazurilor care ies din tipar, pentru verificare umană.
Un exemplu de principiu: AI-ul are mai multă valoare când cunoaște contextul companiei și al oportunității.
Ilustrăm arhitectural, nu prin rezultate. Într-un domeniu ca gestiunea oportunităților și a licitațiilor, aceeași întrebare are răspunsuri complet diferite în funcție de contextul disponibil.
Un model care primește doar textul unei oportunități poate rezuma cerințele. Un sistem care cunoaște și profilul companiei, capacitatea ei, documentele ei și istoricul deciziilor anterioare poate sprijini o discuție de Go / No-Go — pentru că are elementele pe baza cărora oamenii iau efectiv acea decizie.
Oportunitate
Obiectul, termenele, condițiile și structura cererii.
Cerințe
Criterii de eligibilitate și de calificare, extrase și structurate.
Context de companie
Ce poate face organizația, cu ce resurse și cu ce constrângeri.
Sprijin pentru Go / No-Go
Material pregătit pentru decizia oamenilor, nu decizia în locul lor.
Documente
Sursele care susțin fiecare afirmație, rămase trasabile.
Rezultate istorice
Ce s-a întâmplat în situații comparabile, ca element de context.
Arhitectură
Ce înseamnă, complet, un sistem AI operațional.
Toate secțiunile de până acum descriu straturi ale aceleiași arhitecturi. Puse împreună, ele arată de ce modelul ocupă un singur nivel dintr-un sistem cu opt.
FIG. 14 — Arhitectura completă · modelul este stratul 04 din opt
AI maturity este mai degrabă o problemă de integrare decât de model size.
Organizațiile care obțin rezultate durabile nu sunt neapărat cele care folosesc cel mai mare model. Sunt cele care au rezolvat contextul, accesul, controlul și evaluarea.
Traseul de mai jos este o progresie conceptuală, nu un model de scoring. Etapele se suprapun și rareori sunt parcurse în ordine perfectă.
FIG. 15 — Progresie conceptuală · fără scoruri, fără procente de maturitate
Nu orice problemă are nevoie de AI.
Este una dintre cele mai utile decizii tehnice pe care le poate lua o echipă: să recunoască momentul în care software-ul obișnuit rezolvă problema mai bine, mai ieftin și mai sigur.
AI-ul adaugă complexitate reală — context de întreținut, evaluare de construit, moduri noi de eșec, cost variabil. Complexitatea aceasta merită asumată doar când problema chiar cere interpretare.
- 01Regulile sunt exacteDacă poate fi scris ca regulă, ar trebui scris ca regulă.
- 02Rezultatul trebuie să fie complet predictibilAceeași intrare, exact același rezultat, de fiecare dată.
- 03Logica este simplăUn flux clar cu câteva condiții nu are nevoie de interpretare.
- 04Datele sunt deja structurateInformația există ca înregistrare — nu trebuie extrasă din text.
- 05Automatizarea rezolvă mai sigurUn flux determinist este mai ușor de testat, de auditat și de menținut.
Cea mai bună implementare AI dintr-un proiect este uneori partea în care nu a fost folosit AI.
Întrebarea nu este „putem folosi AI?”. Întrebarea este „unde reduce AI suficientă fricțiune încât să justifice complexitatea?”.
Dimensiunile de mai jos se citesc împreună, ca un cadru de discuție. Nu se adună într-un scor: în majoritatea cazurilor reale, una singură dintre ele decide răspunsul.
Ambiguitate
Cât de mult din problemă cere interpretare, nu aplicarea unei reguli.
Valoare
Ce se schimbă concret în munca oamenilor dacă pasul acesta funcționează.
Risc
Ce se întâmplă când rezultatul este greșit și cine suportă efectul.
Disponibilitatea contextului
Există informația necesară și poate fi accesată legitim?
Calitatea datelor
Sursele sunt suficient de curate și de actuale pentru a fi de încredere.
Impactul acțiunii
Rezultatul declanșează ceva reversibil sau ireversibil.
Fezabilitatea evaluării
Putem stabili dacă răspunsul a fost bun — și cât de repede aflăm?
Costul revizuirii umane
Dacă verificarea durează cât munca inițială, câștigul dispare.
Înainte de production, sistemul trebuie să răspundă la câteva întrebări.
Nu sunt întrebări de conformitate. Sunt întrebările la care un sistem AI trebuie să aibă un răspuns explicit ca să poată fi operat, depanat și îmbunătățit.
- 01
De unde vine contextul?
- 02
Care este source of truth?
- 03
Ce poate accesa modelul?
- 04
Ce tools poate folosi?
- 05
Ce acțiuni sunt permise?
- 06
Ce trebuie validat determinist?
- 07
Când intervine un om?
- 08
Cum evaluăm rezultatul?
- 09
Cum observăm execuția?
- 10
Cum tratăm failure-ul?
- 11
Cum actualizăm knowledge-ul?
Test practic Dacă o întrebare nu are un răspuns pe care echipa îl poate formula în două propoziții, acela este următorul lucru de proiectat.
Diferența dintre demo și production este arhitectura din jurul modelului.
Demo
Production system
FIG. 16 — Același model, alt sistem · trei pași devin zece, iar zece pot fi operați
Takeaway
Modelul este o componentă. Sistemul este produsul.
Când AI intră în production, valoarea vine din modul în care modelul este conectat la context, knowledge, tools, workflow și control.
Capabilitățile din jurul sistemului AI.
Fiecare strat din arhitectura de mai sus corespunde unei capabilități tehnice. Într-un sistem AI operațional, rareori lucrează una singură.
Continuă cu alte întrebări de sistem.
Componentele unui sistem AI operațional
Operational AI system
MODEL ≠ SYSTEM
Contact
Ai un AI demo și trebuie să-l transformi într-un sistem operațional?
Putem proiecta contextul, knowledge layer-ul, tool use, workflow-ul, evaluarea și infrastructura necesare pentru ca AI-ul să funcționeze controlat în produs și în production.