Cum funcționează?

Acest capitol conține evoluția sistemelor de recomandare, obiectivele măsurabile AI și arhitectura soluțiilor de top. Apoi compară abordarea Build (dezvoltare custom) cu cea Managed (soluție nativă cloud) și prezintă diagrama unei implementări hibride "privacy-first" din proiectele noastre. La final discutăm provocările implementării AI pentru recomandări.

Ca introducere tehnologică, aceasta este diagrama arhitecturii funnel (pâlnie) pentru un sistem de recomandări:

Imagine Diagramă

  CATALOG COMPLET DE PRODUSE (ex: 1 milion)
               │
               ▼
PASUL 1: RETRIEVAL/GENERARE (Viteză mare, acoperire largă)
    "Găsește 500 de produse asemănătoare"
    (Căutare vectorială + filtre lexicale)
               │
               ▼
      CANDIDAȚI (ex: 500 produse)
               │
               ▼
PASUL 2.1: SCORING / ORDONARE (Viteză medie)
    "Primele după probabilitatea de cumpărare (pCVR)"
      (Rețea neuronală Deep Learning)
               │
               ▼
PASUL 2.2: RE-RANKING ȘI REGULI (Rapid)
    "Elimină stoc 0 și marjă mică"
      (Post-procesare prin guardrails)
               │
               ▼
    REZULTAT FINAL (ex: 3 produse recomandate)

                

Pentru cursivitatea lecturii, vom ilustra conceptele tehnice cu ecosistemul Google Cloud. Dar arhitectura prezentată este universală: ea poate fi replicată în alte cloud-uri, ca Microsoft Azure sau Amazon Web Services sau cu diferite soluții SaaS.

Ghid: Cum alegi un partener Google Cloud de implementare

Istoricul generațiilor de recomandări explică cum am ajuns în momentul prezent. Vom vedea o evoluție de la intuiție umană la inginerie matematică, care devine accesibilă la scară largă prin AI.

În multe echipe de vânzări, recomandările se bazează pe expertiza agenților seniori și know-how-ul companiei. Compania știe că "X preferă marca Y" sau că "Acestui tip de pompă i se potrivește doar acest racord".

Limitarea majoră este scalabilitatea și riscul de personal. După un nivel, compania:

• Crește know-how-ul propriu doar prin programe riguroase de training
• Poate aplica politica comercială doar cu documentație internă detaliată și proceduri stricte

Când un agent senior părăsește compania, se pierd conexiunile logice. Agenții noi vând produse de bază, ratând oportunitățile de upsell timp de 6-12 luni (en. ramp-up). De altfel, indicatorii citați în Cap. 1 arată impact maxim al AI în cazul agenților de vânzări juniori.

Odată cu apariția e-commerce și a platformelor ERP, companiile au început să instituționalizeze know-how-ul și regulile proprii.

Limitarea majoră este mentenanța:

• Într-un catalog cu 50.000 de repere, este imposibil să menții manual legăturile.
• Companiile de succes definesc riguros taxonomia ierarhică care le permite o gestiune eficientă per categorii.
• Regulile se pot perima: accesoriile nu mai sunt în stoc sau ies din oferta producătorului.

O altă limitare este rigiditatea. Sistemul nu ține cont de clientul concret, ceea ce forțează companiile B2B să opereze o ierarhie de aprobare manuală a discounturilor sau un sistem de fidelizare.

Bine cunoscută pentru zonele "Cine a cumpărat asta, a mai cumpărat și...", tehnologia clasică Amazon-style, folosită de giganții mondiali și locali de e-commerce. De aceea, multe pluginuri populare (ex: Woocommerce) încă vând ca AI această logică.

Standardul de astăzi în AI predictiv (en. Predictive AI) a fost accelerat de marile platforme ca YouTube, Google Shopping, Netflix. Este folosit în ultimii ani de marii jucători, inclusiv din România, iar progresul AI le democratizează pentru segmentul mid-market, vezi abordarea Managed în Cap. 2.4.

Pe aceeași tehnică se bazează căutarea hibridă, care combină căutarea lexicală (ex. SKU, dimensiuni apropiate) cu cea semantică (ex: holșurub = șurub autofiletant). Ea aduce cele mai mari beneficii în software-uri B2B, vezi aplicații în Ghid #4.

Ce face în plus Gen 3:

1. Înțelege secvența de vânzare

Sistemul înțelege ciclicitatea consumabilelor. Dacă o clinică a cumpărat un ecograf azi, nu va cumpăra altul mâine. Dar va avea nevoie de obicei de gel conductiv. Algoritmul prezice probabilitatea de cumpărare și se poate genera un widget "Cumpără-l din nou".

Cu un model AI de prognoză temporală (en. time-series modeling) adăugat, poate prezice și data epuizării stocului clientului, activând livrabilul Predicție de re-aprovizionare din Cap. 3.

2. Înțelege conținut (en. Content-Based) inclusiv multimodal

Când apare un produs nou fără istoric, AI predictiv analizează atributele (complete și descriptive). Îl "înțelege" și îl recomandă clienților relevanți, rezolvând problema lipsei de istoric (Cold Start) din Gen 2.

Vezi extracția de atribute din imagini și PDF-uri în Ghidul #3: Input Multimodal

3. Prelucrează contextul

Ia în calcul nu doar cine ești, ci și ce faci acum. De exemplu: clientul este pe mobil, este grăbit, este în timpul programului de lucru sau în weekend.

Deja în 2026, agenții AI bazați pe LLM-uri sunt peste tot în presă, de exemplu după lansarea UCP pentru negociere automată între agenți. Modelele LLM sunt excelente ca interfață conversațională și ca orchestrator: pot explica recomandările făcute, rezuma contextul comercial și pot propune rapid reguli de business, deși nu le pot aplica în condiții de siguranță (în urma riscului de halucinații) și rapid.

Pentru un sistem de recomandări scalabil, cu latență strictă și cost predictibil, sistemul rămâne de regulă Gen 3. Aplicațiile LLM intervin punctual, de exemplu prin chatbots care explică și justifică recomandările. Vezi livrabilul Copilot în Cap. 3.3.1.

Pe scurt:

Puteți organiza motorul de vânzări cu AI în jurul unor noțiuni fundamentale, care se pot transforma în indicatori măsurabili ai companiei. Vezi și livrabilele din Cap. 3 .

1. Optimizarea experienței clientului

Motorul performanței de vânzări. AI este folosit să lege datele companiei de experiența clientului (frontend prin e-commerce, dar și în vânzări directe sau multi-channel) prin personalizare și inteligență contextuală.

2. Automatizarea proceselor interne

Utilizarea AI pentru a ajuta agentul intern să vândă (pe post de copilot), scopul fiind ca oamenii să se poată concentra pe activități cu valoare înaltă, fără sarcini repetitive.

3. Modele și tuning (personalizare)

Adaptarea AI la specificul datelor, produselor și clienților companiei aduce alfabetizarea digitală a companiei și adoptarea tehnologiilor de top. Se pot folosi modele pre-antrenate sau să personalizați (tune) modelele fundaționale (ex: Google Gemini)

4. Curățenia și relevanța datelor

Recomandările bazate pe contextul exact al clientului depind de date de calitate, din toate sistemele companiei. Curățarea și controlul asupra datelor proprii sunt cheia succesului.

5. Guardrails (reguli de siguranță)

Reguli care protejează compania și imaginea sa, evită recomandările absurde, pierderile (ex: vânzarea sub marjă). Pot fi deterministice ca sistemele expert, conform ideii de arhitectură hibridă. Google Cloud include și controale de siguranță în produsele sale AI.

6. AI explicabil (xAI)

Capacitatea de a explica de ce s-a făcut o recomandare, pentru a câștiga încrederea agentului, a managementului și în final a clientului.

7. Interacțiunea om-AI

O temere nespusă în vânzări B2B este: "Dacă clientul cumpără produsul recomandat de AI, eu îmi iau comisionul?" Pentru a preveni rezistența la noua tehnologie, agentul poate folosi recomandările AI ca fișă de produs instantanee, pentru a câștiga mai mulți clienți.

Pe scurt:

Modelul consacrat astăzi folosește Deep Learning pentru a obține recomandări, upsell, cross-sell și înțelegerea secvenței de cumpărare, a conținutului produselor și a contextului clientului.

Această arhitectură este implementată de la zero de giganți e-commerce, inclusiv în România, fie inclusă în soluțiile gestionate, ca Vertex AI Search for commerce de la Google Cloud.

Studiu de caz: Timp de ofertare -68%, +14% valoare medie comandă pentru distribuție

1. Arhitectura standard

Mulți giganți din e-commerce-ul românesc dar și companiile care folosesc o abordare gestionată ca Vertex AI Search for commerce implementează această arhitectură cu două etape principale: generarea primilor candidați (Retrieval) și selecția lor atentă (Ranking)

Dacă vă este frică de detalii tehnice, nu uitați că în 2026 puteți evita implementarea de la zero, vezi abordarea Managed în Cap. 2.4.

2. Etapa 1: Generarea candidaților (Retrieval)

Din milioanele de produse din catalog (eventual pre-procesate cu filtre de bază), un algoritm rapid selectează câteva sute relevante.

3. Etapa 2: Ranking (ordonare / scoring și post-procesare)

Din sutele de produse candidate, modelul trebuie să calculeze un scor numeric de probabilitate de conversie. De exemplu, pCVR: probabilitate de conversie (achiziție, acceptare ofertă, alt eveniment de succes). Acești candidați ajung primii.

Regulile de business (guardrails) care se aplică la final în post-procesare sunt esențiale pentru controlul AI (vezi detalii în Cap. 2.5.1):

• Asigură alinierea cu politica comercială: unele scoruri sunt ajustate, unele rezultate sunt eliminate.
• Exprimă prioritatea regulilor de business deterministice față de non-determinismul AI.

4. Upsell, cross-sell, discounting

Imagine Diagramă

    
APLICAȚIE SAU SITE           MOTOR AI + REGULI (CUSTOM)    APLICAȚIE SAU SITE 
┌───────────────────┐       ┌──────────────────────┐      ┌─────────────────────┐
│ Client: Coș       │       │ 1. Estimează pCVR    │      │ Reîncarcă coșul:    │
│ Produse: [A, B, C]│ ───►  │ (probabilitate       │ ───► │                     │
│ Total: 950 EUR    │       │  conversie)          │      │ - Produs A          │
└───────────────────┘       │ 2. Verifică marja    │      │ - Produs B          │
                            │ (prin guardrails)    │      │ - Produs C          │
                            │ 3. Decide:           │      │ [DISCOUNT: -38 EUR] │
                            │ "Merită -4% pt a     │      │ (disponibil limitat)│
                            │  închide acum"       │      └─────────────────────┘
                            └──────────────────────┘

                

Upsell: upgrade

Se bazează pe caracteristici și atribute de produs. Pentru un laptop de 1.200 EUR, modelul poate împinge în ranking laptopuri cu specificații similare dar marginal mai bune (și cu marjă mai bună), pentru că a învățat: clienții care compară specificațiile tind să facă upgrade.

Cross-sell: accesorii

Se bazează pe reguli de compatibilitate întărite de date comportamentale.

De exemplu, vectorul unui excavator este asociat puternic tranzacțional cu vectorul kit-ului de filtre hidraulice specific (pentru mentenanță). Aceasta este prima fundație pentru livrabilul #8: Motor de compatibilitate tehnică.

Cealaltă fundație este un sistem de compatibilități exacte între produse pentru care aveți nevoie de fișe tehnice detaliate și să precizați în guardrails filtrele (ex: ce câmpuri trebuie să fie identice).

Discounting: optimizare preț

Arhitectura poate trata discountul ca variabilă de optimizare conversie. De fapt, modelele AI vor estima în spate probabilitatea de conversie pentru fiecare scenariu.

Aceasta este fundația pentru livrabilul Optimizare dinamică preț din Cap. 3. În soluțiile Managed, această logică e adesea custom (componentă separată).

Diferența majoră dintre filtrarea colaborativă (Gen 2) și recomandările Deep Learning (Gen 3 - actuală) este capacitatea de a înțelege intenția imediată, nu doar istoricul.

1. Modelarea secvenței sesiunii (en. Sequence Modeling)

Arhitectura actuală nu se uită doar la istoricul global, ci la sesiunea curentă.

                              Vizualizare telefon  Adăugare coș  Căutare huse
                            

2. Contextul de dispozitiv și timp

Datele calde despre client (ora sesiunii, dispozitivul folosit) sunt esențiale pentru a recomanda clientului ce dorește el acum.

În e-commerce-ul foarte specializat, contextul este asigurat și prin guardrails, definite manual pentru optimizarea sesiunii curente de cumpărare.

Calitatea recomandărilor variază direct cu calitatea și viteza datelor de intrare (principiul GIGO: Garbage In, Garbage Out). Pentru ca modelul AI să fie relevant, datele trebuie să fie curate și corelate în prealabil.

Pentru B2B recomandăm unificarea datelor din toate sursele și ingestie continuă prin API.

Vezi în Ghidul #2 cum construim sursa unică de adevăr pentru a alimenta corect algoritmii

1. Catalogul de produse (Sursa principală: ERP, Surse secundare: WMS, PIM, e-commerce)

Sunt date fundamentale ale companiei. AI poate avea acces nu doar la numele produsului, ci și metadatele critice pentru business, în special preț și stoc.

Re-antrenarea modelului de recomandări poate avea loc zilnic, procesând cantități mari de date pentru toate produsele.

2. Istoricul de client (Sursa principală: CRM)

Cu generalizarea LLM, este posibilă și ingestia datelor nestructurate: se transcriu permanent apelurile de vânzări și mailurile trimise, apoi se obține o cifră de sentiment sau acțiune recomandată (en. next best action) care poate fi scrisă înapoi în CRM.

Studiu de caz: Analiză financiară de sentiment cu GenAI & Google Cloud

3. Evenimente live și clickstream (Sursa: e-commerce, alte aplicații ale companiei)

Sunt date imediate și cel mai puternic factor de predicție pentru intenția de cumpărare, cel puțin în e-commerce.

Flow de ingestie date live (e-commerce)

Pentru clickstream se folosesc sisteme ca Apache Kafka sau Spark în varianta Build, respectiv API (userEvents) în varianta Managed

La click pe produs, se trimite un eveniment într-un Feature Store, respectiv prin API. Când încarci următoarea pagină, sistemul interoghează Feature Store-ul: "Care sunt ultimele 5 click-uri ale acestui client?" și modelul va lua în considerare contextul actualizat.

Se previn astfel recomandările vechi (en. stale). Aplicația (UX) poate pivota direct către cross-sell. Va recomanda de exemplu extensie de garanție sau accesoriu.

Rețelele neuronale folosite în arhitecturile custom sunt în mare parte black box (cutii negre). Operatorul uman nu știe exact de ce produsul X a fost recomandat clientului A acum.

Se folosesc strategii de reducere a riscurilor.

Pe scurt:

În vânzările business to business, provocarea este gestionarea unui catalog vast, suplimentat deseori cu produse noi fără istoric (problema Cold Start) și respectarea regulilor stricte de business (ex: nu recomanda produse ieftine clienților premium)

Comparăm construcția propriilor modele (data science in-house) cu utilizarea modelor pre-antrenate, cum ar fi în Vertex AI Search for commerce. Cum recomandăm un produs complementar alături de "Centrală termică 24kW" în cele două abordări?

Este abordarea clasică de data science. Veți dezvolta un model de Deep Learning (Gen 3). Pentru simplitate ilustrăm cu Gen 2 un flux simplificat de filtrare colaborativă cu tehnologii open-source:

Fluxul de date:

Imagine Diagramă

1. EVENIMENTE CLIENT 
(Istoric comenzi, Data warehouse)
        │
        ▼
2. APACHE SPARK / PYTHON PANDAS
(Procesare batch, ex: noaptea)
        │
        ▼
3. MODEL ALS / MATRIX FACTORIZATION
(Antrenare algoritm: "Cine a luat X a luat Y")
        │
        ▼
4. REDIS / MEMCACHED
(Stocare perechi pre-calculate.
 Ex: "produs A" -> "recomandă B, C, D")
        │
        ▼
5. API SERVER
        │
        ▼ 
6. AFIȘARE în APLICAȚIE / E-COMMERCE

                

Avantajul este proprietatea asupra codului dezvoltat (de obicei) și posibilitatea implementării oricărui tip de învățare.

Există modele specializate de prognoză temporală (en. time-series modeling) care pot fi folosite în cloud (ex: Vertex AI Forecast), și multe tipuri de modele în Model Garden (open-source ca Llama / Mistral sau comerciale ca Gemini). Acestea pot fi conectate la datele și restul logicii dezvoltate de echipă.

Ca infrastructură, abordarea Build necesită provizionarea și mentenanța serverelor (ex: Kubernetes), fie in-house, fie într-un cloud ca Google Cloud, urmând să plătiți pentru infrastructură (IaaS - Infrastructure as a Service).

Ca limitări, deoarece calculul matricial este intens, se face de obicei o dată pe zi (batch). Dacă un produs devine brusc popular la ora 10:00, este nevoie de o logică specială (care este realizabilă) pentru a actualiza recomandările înainte de următorul batch, altfel algoritmul nu se va ajusta până a doua zi.

• Echipă: Dezvoltator, inginer de date/ML, inginer DevOps, analist de business
• Dezvoltare model: 2-3 luni (cu iterări necesare pentru acuratețe).
• Infrastructură (evenimente, modele, API): 1-2 luni.
• Total până la lansare: de la 4-6 luni.

Este o abordare în care modelul AI este complet gestionat extern. Folosim un serviciu ca Vertex AI Search for commerce, care include modele de Deep Learning cunoscute în piață a fi similare cu Google Shopping sau YouTube.

Fluxul de date:

Imagine Diagramă

1. EVENIMENTE CLIENT        2. CATALOG ERP / E-COMMERCE
(Click, adăugare coș,      (Metadate: categorie, preț,
 afișare, real-time)        atribute, descriere)
        │                         │
        └──────────────┬──────────┘
                       ▼
        3. VERTEX AI SEARCH FOR COMMERCE
           (Motor gestionat de Google)
        ┌────────────────────────────────────────┐
        │ • Deep & Cross Network (DCN)           │
        │ • Reguli de business (filtre explicite)│
        │ • Setare optimizare: CTR (click-through│
        │   rate), conversie sau Revenue (venit) │
        └────────────────┬───────────────────────┘
                         │
                         ▼
        4. API SERVER/MINI-APP (WIDGET)
                         │
                         ▼
        5. AFIȘARE ÎN APLICAȚIE / E-COMMERCE
      ("Pentru clientul X, acum, arată produsul Y")

                

Avantajul este rezolvarea la pachet a problemei lipsei de istoric (Cold Start) și a comparației semantice. Dacă apare un produs nou în ERP (ex: "Bormașină model 2026") cu toate specificațiile, algoritmul îi indexează atributele (ex: putere, brand, categorie) și chiar imagini. El îl va recomanda clienților care caută produse similare și, în plus, în piață algoritmii Google sunt cunoscuți ca fiind excelenți pentru clienții noi fără istoric.

Ca limitări, produsul nu include acum unele tipuri de învățare, de exemplu prognoză temporală (en. time-series modeling) pentru cadență sau logică de discounting. Acestea necesită implementare orchestrată în middleware-ul de control. Se pot folosi inclusiv modele din Google Cloud, de exemplu din Model Garden.

În al doilea rând, nu ai acces la codul modelelor Managed, dar poți configura obiectivele lor din lista disponibilă în consolă (ex: maximizare CTR sau Revenue / session).

• Echipă: Dezvoltator, Inginer de date, analist de business
• Sincronizare catalog (dacă datele sunt curate): 2-3 săptămâni.
• Infrastructură (evenimente, API): 1-2 săptămâni.
• Antrenare inițială: 1-2 săptămâni (automată).
• Total până la lansare: de la 2-3 luni.

Construirea unui sistem de recomandări de la zero (varianta Build) este o opțiune pentru companiile cu volum mare de trafic și nevoie de control pe cod.

Construirea cu Vertex AI Search for commerce (varianta Managed) este o opțiune pentru implementare rapidă. Componentele care nu sunt disponibile, de exemplu prognoză temporală, pot fi implementate custom.

Pe scurt:

Pentru companiile cu cerințe stricte de securitate sau cu sisteme ERP on-prem, ilustrăm din proiectele OPTI Software cum arată un middleware centralizat pentru adevăr comercial.

Poate funcționa în cloud sau on-prem și se conectează punctual la funcțiile de AI, fie gestionate de Google, fie custom via Model Garden.

Imagine Diagramă

ZONA DATE INTERNE                        ZONA MIDDLEWARE                        ZONA AI 
┌─────────────────────────────────┐      ┌───────────────────────────────┐      ┌───────────────────────────┐
│ 1. SURSE DE DATE                │      │ 2. DATA HUB & SYNC            │      │ 3. Vertex AI (Search +    │
│                                 │      │                               │      │  Search for commerce,     │
│                                 │      │                               │      │  Model Garden)            │
│ ┌────────────┐   ┌────────────┐ │      │  ┌─────────────────────────┐  │      │ ┌───────────────────────┐ │
│ │ ERP        │   │ FILE SERVER│ │      │  │ Bază de date rapidă     │  │      │ │ Vectori               │ │
│ │ (Master)   │   │ (PDF/Docs) │ │      │  │ (Cache)                 │  │      │ │ Index                 │ │
│ └──────┬─────┘   └─────┬──────┘ │      │  └────────────┬────────────┘  │      │ └───────────▲───────────┘ │
│        │               │        │      │               │               │      │             │             │
│        ▼               ▼        │      │               ▼               │      │             │             │
│  [Sync unidirecțional securizat]├─────►│  [Filtrare și sanitizare]     ├─────►│ [Ingestie (doar public)]  │
└─────────────────────────────────┘      │               │               │      │                           │
                                         │               │               │      │ ┌───────────────────────┐ │
                                         │  ┌────────────▼────────────┐  │      │ │ Model / LLM           │ │
                                         │  │ API Gateway             │◄─┼──────┤ │ (RAG & Procesare)     │ │
                                         │  │ (Combina interne cu AI) │  │      │ └───────────────────────┘ │
                                         │  └────────────▲────────────┘  │      └───────────────────────────┘
                                         └───────────────┼───────────────┘                                   
                                                         │                                                   
                                                         ▼                                                   
                                            ┌─────────────────────────┐                                      
                                            │ 4. Aplicatii            │                                      
                                            │ (Ofertare / Chatbot)    │                                      
                                            └─────────────────────────┘                                      

                

Arhitectură comparată: Soft de ofertare Vânzări cu AI de la OPTI

În Vertex AI Search for commerce, integrarea API-ului în aplicație și construcția livrabilelor necesită programatori, dar strategia de vânzare se poate defini parțial din interfață (low-code).

Fluxul de control low-code/no-code:

Imagine Diagramă

ANALIST DE BUSINESS          DASHBOARD VERTEX AI (UI)       E-COMMERCE (live)
┌──────────────────────┐    ┌──────────────────────┐      ┌─────────────────────┐
│ Strategie:           │    │ 1. ServingConfig     │      │ Widget "Recomandăm" │
│ "Vreau să împing     │ ──►│    [ Add Rule ]      │ ───► │                     │
│ camioanele MAN       │    │ 2. Condition:        │      │ 1. MAN TGX 480      │
│ în față."            │    │    Brand == "MAN"    │      │    (promovat)       │
└──────────────────────┘    │ 3. Action:           │      │ 2. Alte produse     │
                            │    Boost score 0.5   │      │    (standard)       │
                            └──────────────────────┘      └─────────────────────┘

                

Pentru un departament comercial cu un analist tehnic, regulile de afișare pot fi controlate din dashboarduri, folosind controale vizuale. Trainingul și comunicarea cu echipa tehnică sunt esențiale pentru evitarea configurărilor greșite, riscurile fiind considerabile.

Nu vrem să vindem sub marja minimă, să recomandăm produse imposibile / incompatibile sau să lăsăm clientul sau agentul de vânzări fără sugestie când integrarea AI nu funcționează.

Abordarea hibridă nu înseamnă doar date proprii plus AI în cloud, ci și AI predictiv sau agentic (Gen 3-4) controlat de reguli explicite ca în Gen 1. Scopul folosirii datelor companiei este de a controla rezultatul AI. Regulile sunt plasa de siguranță a afacerii.

1. Protecția afacerii

Regulile sunt invizibile pentru client, dar critice pentru departamentul financiar sau marketing:

În special pentru upsell în B2B, regulile sunt esențiale pentru a nu încălca contractul, care poate prevedea, de exemplu, doar anumiți producători agreați.

Modelele AI pot învăța corelații greșite, ducând la recomandări repetitive sau absurde. Unui client de volum care a cumpărat o flotă de laptopuri Apple nu trebuie să i se recomande genți și accesorii Asus.

Soluția sunt regulile de excludere bazate pe metadate, care encodează expertiza umană.

2. Fallback: Continuitatea experienței

Ce se întâmplă dacă API-ul are o latență, dacă clientul este nou (fără istoric) sau dacă pentru un produs obscur nu există recomandare de încredere (ex: scor > 0.5 derivat în abordarea Build)?

3. Sisteme expert: Oamenii pot ști mai bine

Deși AI este puternic, el poate ști prea puțin (en. underfitting) despre contextul comercial complet. Managerul poate trece peste (en. override) recomandările AI.

Forțarea campaniilor:

Pentru campaniile noi unde nu există date contextuale relevante, se pot defini perioade de promovare (ex: Boost) cu forțarea priorității.

Sezonalitatea:

Calendarul uman diferă de statistica pură, de exemplu:

• Ianuarie (start bugete): Prioritizează echipamentele cu valoare mare, considerate investiții.
• Octombrie (final de sezon în construcții): Prioritizează lichidarea stocurilor de materiale sezoniere sau perisabile.

În B2B tehnic, compatibilitatea este binară: merge sau nu. Se folosesc sisteme expert, definite pe detaliile din fișa de specificații.

Din punct de vedere tehnic, guardrails sunt clasificate în hard (filtre și eliminări), soft (promovări și retrogradări în ordinea listei) și de proces (necesare pentru control și audit. Ex: "cere permisiune pentru discount prea mare" / "Notează aplicarea regulii în log").

Principiul "Garbage In, Garbage Out" spune că fără date proaspete corecte, și recomandările AI vor da rezultate greșite. Orice schimbare în sursa fundamentală de adevăr a companiei (ex: actualizare ERP, schimbare TVA sau modificarea unei categorii cruciale) poate distruge integrările.

Soluția este definirea unui Contract de date între echipa care gestionează sursa de adevăr (ERP, WMS, CRM, e-commerce) și echipa care gestionează integrarea AI.

1. Pregătirea datelor: de la haos la claritate

Aceste proceduri cresc la maxim claritatea operațională a companiei și reduc la minim datoria tehnică acumulată în trecut.

Vezi metodologia OPTI Software în Cap. 5.3.2

2. Schema de date: structura

Pentru ca integrarea să se "înțeleagă" cu sursa datelor, se definesc trei nivele. Entitățile care se vor sincroniza, cum trebuie să arate câmpurile lor de date și care sunt consecințele pentru integrare când contractul este încălcat.

3. Semantica datelor: înțelesul

Dezvoltatorii aplicației de AI trebuie să înțeleagă ce înseamnă datele din sistemele sursă, pentru a menține identic comportamentul întregului sistem, în special față de clientul final.

Atenție la orice ține de următoarele:

Înțelesul fiecărui câmp contează pentru varianta Build, pentru a nu antrena un model pe corelații irelevante. Contează și în varianta Managed, ca la orice integrare SaaS.

4. SLA de date: latență și race conditions

Se definesc condiții de forma "Modificările de stoc trebuie să ajungă în AI în maxim 5 minute", "Când ERP nu funcționează, se folosesc ultimele date, dar nu se mai dau discounturi" pentru a asigura consistența și previzibilitatea sistemului.

Studiu de caz: Construcția unei platforme de microplăți pentru Playwing

5. Checklist: Date necesare pentru o implementare AI în vânzări

Contractul de date stabilește schema, semantica, pregătirea datelor și SLA pentru datele companiei care sunt afectate de implementarea AI.

Pe scurt:

Vezi exemple de cod și configurare pentru guardrails și ingestie de date în Cap. 4, pentru Build și Managed.

Iată două provocări tehnice de finețe, întâlnite în implementările reale de AI pentru vânzări.

Cele mai populare modele funcționează diferit și trebuie adaptate la momentul din secvența de cumpărare (en. customer journey):

În abordarea Build (custom), aceste modele se definesc și antrenează separat, cu refolosirea unor componente comune.

În abordarea Managed (Cloud Native), se pornește prin configurarea modelelor predefinite de Google pentru cazurile populare de mai sus. Obții livrare mai rapidă și posibilitatea de a alege obiectivul de business maximizat, fără a putea să modifici modelul de bază.

Pentru a implementa pachete, avem nevoie de inginerie de date sau de o abordare hibridă.

1. Discount inteligent la cumpărare (standard)

2. Pachete direct în catalog

Prima implementare implică modificarea coșului de cumpărături și a modulului de comenzi. A doua implementare implică integrarea în adâncime cu fluxurile comerciale automatizate.

Pe lângă aceste provocări, există și altele legate de scalabilitate, latență, securitate și monitorizare, în funcție de complexitatea fluxurilor companiei. Dar tehnologia AI pentru vânzări B2B există, cum am arătat în acest capitol.

×

Nu ești sigur ce arhitectură ți se potrivește? OPTI Software oferă un audit tehnic gratuit

Cere formatul PDF complet

Manualul este disponibil și în variantă PDF completă. OPTI Software trimite o dată pe lună noutăți Tech & Biz exclusive.

Preview PDF

Vezi aici o previzualizare a ghidului