English
/ Ghidul 1 / Capitolul 4: Cookbook
Google Cloud Partner HubSpot Solutions Partner ISO 27001 ISO 9001
Data actualizării: 11.03.2026
CAPITOLUL
04
Recomandări inteligente, upsell, bundling și guardrails

Cookbook tehnic

Știai că sistemele AI au fost create (și) de programatori? Cel puțin pe moment, încă este nevoie de programatori pentru a integra AI cu procesele și software-ul existent. Acest capitol este dedicat celor care vor să vadă cu ochii lor mici bucăți dintr-o asemenea integrare. Dacă ești decident, fluxul minim (dar complet) de implementare din 4.1 este pentru tine. Sau poți sări la capitolul următor.

Nu există un câștigător absolut între variantele Build și Managed de implementare Deep Learning, pe care le-am comparat în Cap. 2.4. În practică, în cazuri diferite, multe companii folosesc o abordare hibridă. De exemplu folosesc componente gestionate pentru recomandări de produse, dar implementează custom prognoze temporale sau discounturi inteligente.

Fluxul corect de decizie pleacă de la livrabilele exemplificate în Cap. 3.3., apoi identifică abordarea tehnică potrivită, apoi estimează efortul necesar.

PAS CU PAS
4.1

Un flux minimal complet

Vei trece pas cu pas prin implementarea unui motor de recomandări AI, ca să ai un blueprint pentru varianta Build (implementare custom) sau un checklist pentru varianta Managed (Cloud Native).

În ambele variante, costurile angajate sunt ușor de cuantificat (în special inginerii de date, respectiv consumul Google Cloud), dar ce este invizibil este costul de oportunitate: cât costă o implementare slabă care nu va fi folosită. Scopul este să prezentăm pașii obligatorii pentru succes.

Pasul 0
4.1.1

Minimul necesar pentru a începe

Înainte de implementare, compania trebuie să definească:

  • Obiectivele de business: ce vrei să îmbunătățești (AOV, rata de conversie, marja, vânzarea produselor slow-moving). Vezi Cap. 2.2.
  • KPI măsurabili: indicatorii companiei (lunari sau trimestriali) și tehnologici (ex: latență și fallback).
  • Reguli de business: ce trebuie să respecte AI (fără halucinații de preț, stoc sau compatibilități, marjă minimă, reguli de diversitate brand, excluderi de clienți rău-platnici). Vezi Cap. 2.5.1

Build

Ședințe cu departamentele de vânzări, marketing, financiar, IT pentru a defini:

  • 1-2 scenarii pilot (ex:"upsell în ofertare", "recomandare în pagina de produs").
  • Un set minim de guardrails (marje, stocuri, compatibilități).
  • Colectarea de feedback, mai ales negativ (ex: "nu mă interesează această recomandare", "această recomandare nu a condus la nicio vânzare timp de o lună").

Managed

Aceleași procese ca în varianta Build.

Se adaugă:

  • Cunoașterea obiectivelor definibile în dashboard (ex: maximizează CTR / CVR / Revenue).
  • Pregătirea segmentelor de trafic pentru testele A/B.
  • Definirea regiunii. În acest moment pentru Vertex AI Search se poate selecta EU Multi-region, pentru Vertex AI Search for commerce locația este globală.
  • Definirea regulilor de date și procese. Ex: ISO27001, NIS2, domenii reglementate.
Pasul 1
4.1.2

Inventarierea și conectarea datelor

Sistemul de recomandări are nevoie de cel puțin trei tipuri de date detaliate în Cap. 2.3.2: catalogul de produse, istoricul de interacțiuni cu clientul și evenimente continue (ex: clickstream). Ne concentrăm pe primele două.

Build

Identifici sursele: ERP, WMS, CRM, e-commerce, fișiere Excel esențiale.

Definești schema de date unificată (ID produs unic, mapping între codurile din ERP, CRM și e-commerce, planul de normalizare unități de măsură etc.).

Realizezi curățarea și normalizarea datelor, cum am recomandat în Cap. 2.5.2.

Construiești un pipeline ETL/ELT (ex: în BigQuery sau alt data warehouse) pentru:

  • Import de catalog o dată pe zi (full) + incremental în funcție de nevoie.
  • Filtre de bază pentru pre-procesare (ex: exclude produsele fără stoc 3 luni).
  • Import cvasi-continuu evenimente de comandă / trafic (streaming sau batch).

Managed

Curățarea și normalizarea datelor proprii este obligatorie și în acest caz.

În loc să construiești ETL complet, folosești conectori și feed-uri standard:

  • Feed de catalog (API/CSV/JSON) mapat pe schema strictă a Google. Dacă folosești BigQuery ca data warehouse, poți conecta direct datele.
  • Regulile de business pot fi definite inițial ca feed-uri: liste de produse de promovat, excluse, bundle-uri, apoi legate prin consolă sau configuri.
  • Pregătești feedul de evenimente: server-side events, Google Tag Manager, loguri.
  • Atenție, librăriile de cod și endpoint-urile API folosesc încă terminologia istorică Retail (ex: google.cloud.retail_v2).

Pentru B2B, dacă prețurile diferă per client, Vertex AI Search for commerce poate învăța pe prețul de listă, iar aplicația trebuie să aplice prețul corect. Există și suport pentru prețuri diferite per segment de clienți, dar cere inginerie de date complexă.

Recomandare: chiar și în varianta Managed, păstrează o copie a datelor într-un data warehouse (ex: BigQuery) pentru audit și pentru a avea sursa proprie de adevăr comercial.

Pasul 2
4.1.3

Definirea evenimentelor, livrabilelor și a punctelor de inserție

Nu poți optimiza ceea ce nu măsori. Compania trebuie să standardizeze evenimentele care descriu comportamentul utilizatorilor.

Tipuri de evenimente Vertex AI Search for commerce API. Verifică documentația oficială

Descoperire: search, detail-page-view, category-page-view, home-page-view, shopping-cart-page-view.

Tranzacționale: add-to-cart, remove-from-cart, purchase-complete.

Trebuie apoi decise în ce livrabile software concrete (Vezi Cap. 3.3) vei insera recomandările AI. Acestea îți dau punctele de inserție. De exemplu în UI e-commerce, poți afișa recomandările în: homepage, categorie, pagină de produs, coș, ofertă PDF, e-mail, backend administrativ (pentru echipa de suport).

Riscuri de date în B2B
  • În B2B cheia de tracking pentru indicatori nu este individuală ca în B2C, ci contractul, clientul (account sau organizație) sau grupul de clienți.
  • În B2B tranzacțiile fiind de dimensiuni mari dar rare, pierderea unui eveniment din tracking poate fi catastrofală. Folosește mecanisme de reîncercare și idempotență.
  • Recomandăm pseudo-anonimizarea (ex: hashing) datelor personale înainte de a le trimite în sistemul de recomandări. Păstrezi consistența cu risc de conformitate redus.
  • Pentru explicabilitate și audit, se recomandă să logați toate interacțiunile de date cu sistemul de recomandări. Așa veți putea reconstrui separat în viitor KPI-uri tehnice ca NDCG@k (relevanța ordonării) și Recall@k (relevanța căutării).

Build

Definești o schemă de evenimente (nume, payload de date, id-uri unice coerente). Implementezi logarea lor din aplicațiile existente ale companiei:

  • Scripturi JS pentru site e-commerce.
  • Hooks în backend e-commerce, ERP, WMS sau CRM.
  • Logare în fișiere sau în topicuri (ex. Pub/Sub, Kafka).

Stabilești cum va primi la final aplicația recomandările:

  • Endpoint API POST /recom Account_id=…&Context=…
  • Widget pe site e-commerce sau în aplicații interne.

Managed

Mapezi evenimentele tale în schema strictă a Google. Dacă ai evenimentele în BigQuery sau Google Tag Manager, le poți conecta direct.

Configurezi ServingConfigs pentru fiecare punct de inserție (en. placement) pe care îl definești în aplicațiile tale (ex: homepage_recs, cart_upsell).

Un ServingConfig include:

  • Modelul selectat din lista Google. Ex: Buy it Again cu obiectivul de maximizat deja selectat.
  • Serving Controls. Filter (excludere - doar în varianta de căutare), Boost (promovare), Bury (retrogradare).
  • Setarea de diversitate: cât de non-repetitive sunt recomandările.
  • Chemi un ServingConfig când apelezi API, deci îl poți folosi pentru mai multe puncte de inserție în aplicațiile companiei dacă au aceleași reguli.
  • Serving Controls pot fi realizate ca fișiere JSON, deci refolosite în ServingConfigs de căutare diferite.

Atenție, în versiuni mai vechi, se defineau obiecte de tip Placement, dar acestea nu sunt recomandate în noul API pentru Vertex AI Search for Commerce (retail_v2).

Beneficiul este că nu vei implementa de la zero. Dar trebuie să decizi ce înseamnă succesul pentru fiecare punct de inserție, plus să inserezi date istorice (minim 3 luni recomandat) pentru ca algoritmul să nu plece de la zero.

Pasul 3
4.1.4

Generarea candidaților (Retrieval)

Primul pas tehnic al sistemului de recomandări va fi să găsească candidații potențiali: zeci sau sute de produse care sunt relevante. Aceasta este faza Retrieval din arhitectura descrisă în Cap. 2.3.1.

Build

Configurezi un motor de căutare lexicală (BM25 / full-text) pe catalog și în paralel un motor de căutare vectorială cu embeddings pentru produse, clienți, secvențe de sesiuni.

Implementezi opțional un modul de pre-procesare bazată pe reguli: tip de client, stoc, evitare produse nerelevante.

Rezultatul obținut de Vector Search este o listă de candidați care merg apoi la Scoring.

Managed

Oferă Retrieval nativ pe baza evenimentelor, pe baza conținutului (content-based / deep attribution: atribute, fișă produs, inclusiv imagine) și pe baza asocierilor.

Pentru upsell și cross-sell, se folosesc de obicei inginerie de date și Collections: la fiecare produs poți trimite oricâte ID-uri de pachete (compatibile, bundle) care îl conțin, iar modelul va transfera relevanța.

În consolă poți defini noi sinonime (ex: poți defini "cut" ca fiind "cutie") și mai ales filtrele (ex: doar produse în stoc, doar acest brand / categorie) sau strategiile de diversitate ("nu recomanda doar ce e ultra-popular").

Nu construiești algoritmi de recomandare, dar trebuie atenție la configurare și inginerie de date.

Vezi Ghidul #4 pentru combinarea căutării lexicale cu cea semantică

Pasul 4
4.1.5

Ranking, reguli și generarea listei finale

Conține pașii cei mai complecși tehnic. Pentru ranking, modelele AI de scoring vor face:

  1. Ordonarea candidaților.
  2. Post-procesare prin reguli de business (guardrails). Pot fi de eliminare (en. hard), de ordonare (en. soft) sau de proces (ex: audit)
  3. Livrarea finală a unei liste scurte de produse către aplicație în milisecunde (în scenarii optimizate).

Build

Antrenezi și apelezi un model de ranking (ex. tip learning to rank) care primește:

  • semnale din catalog: preț, marjă, categorie, compatibilitate.
  • semnale de context: tip client, timp, detalii coș / ofertă.

Aplici regulile de business în post-procesare (ex: Python, rule engines ca Drools):

  • Filtrează produse fără stoc sau sub marja minimă.
  • Promovează anumite produse sau campanii.
  • Asigură deduplicare și diversitate. Ex: "fără 3 produse consecutive de la același brand".

Testezi capacitatea de scalare și optimizezi pentru latență redusă: caching, optimizări de model.

Managed

Alegi inițial obiective și parametri de ranking: "optimizează pentru click pe recomandare" / "optimizează pentru venit per sesiune" / "optimizează pentru conversie". Odată antrenat, un model cu obiectiv de maximizat selectat nu poate fi schimbat, va trebui să-l re-antrenezi dacă dorești să schimbi obiectivul.

Poți configura și intervalul de training al modelului.

Rafinezi regulile de business ca Filters / Boost / Bury (Serving Controls). Pentru a obține efectele dorite, este nevoie de creativitate și inginerie de date solidă:

  • Fiecare control are structura de condiție / efect (ex: în CEL - Common Expression Language). Ceea ce te reîntoarce la definirea schemei.
  • De exemplu, pentru a implementa o regulă de prognoză temporală externă, poți crea în schemă un atribut seasonal_score (ex: 0.0-1.0) și apoi să definești un Boost.
  • Atenție, adesea rămân unele reguli în middleware sau aplicație, de exemplu permisiunile.

Scalarea automată în cloud la vârf de încărcare (ex: Black Friday) este de obicei un avantaj.

Vezi Ghidul #5 - Optimizare continuă, raportare și feedback

Pasul 5
4.1.6

Integrare în UX și fallback

Motorul de recomandări AI trebuie conectat invizibil (en. seamless) cu aplicația software (ex: e-commerce). Trebuie și să permită feedback și să asigure comportament previzibil pentru clienții sau agenții de vânzări care beneficiază.

Build

Un microserviciu dedicat cu API va întoarce lista finală de recomandări.

Construiești o componentă UI care afișează recomandările (ex. site e-commerce).

Definești varianta elegantă (en. graceful) de fallback. Ce se vede când API-ul nu răspunde / nu are recomandări - de exemplu se poate rula o interogare SQL pentru cele mai noi produse.

Implementezi un mecanism de feedback explicit (Thumbs up/down sau Ascunde). La re-antrenare acest semnal trebuie să fie mult mai puternic decât simpla ignorare a recomandării.

Managed

Trimiți outputul în aplicație programatic (via API/SDK) sau encapsulezi (en. embed) unele mini-aplicații disponibile în Vertex AI Search for commerce (ex: widget-uri frontend, via JS).

În primul caz, construiești componenta UI ca în varianta Build.

Prevezi fallback ca în varianta Build, pentru a nu avea interfață goală niciodată (necesar dacă folosești varianta API). Dacă folosești widget-urile Google, acestea au deja mecanisme de fallback integrate și în varianta API există un parametru strictFiltering care poate fi setat ca fals pentru a returna recomandări când filtrele ar elimina rezultatele.

Prevezi mecanismele de feedback explicit. De obicei, Vertex AI Search for commerce colectează feedback implicit (clickuri, conversii). Feedbackul negativ trebuie implementat de la caz la caz. Poți folosi Filter / Bury sau chiar un eveniment de îndepărtare din coș. În aplicație poți folosi inginerie de date pentru a filtra produsele trimise către AI sau cele returnate de AI.

Pasul 6
4.1.7

Testare, analiză și feedback continuu

Un sistem de recomandări robust depinde de testare A/B și de mentenanță continuă după livrare. Monitorizezi KPI-urile, anomaliile (ex: raport al calității) și feedback-ul clienților sau companiei.

Shadow mode (rularea recomandărilor AI pentru publicul intern înainte de a lansa pentru clienți) permite validarea algoritmului pe date reale fără a risca veniturile sau imaginea. Similar, o procedură de backtesting rulează algoritmul pe date istorice, eventual completate din urmă (en. backfill), înainte de orice rulare live.

Build

Configurezi A/B testing (in-house sau printr-o platformă SaaS, de exemplu split.io):

  • Grup A = situația precedentă.
  • Grup B = aplicare algoritmi noi.

Compari KPI (de obicei de business): AOV, rată de acceptare recomandări, timp de ofertare.

După validare și lansare, implementezi dashboarduri de analiză (ex. Grafana / Looker Studio) pentru un raport al calității:

  • Evoluția KPI-urilor de business (vezi mai sus).
  • Distribuția statistică a recomandărilor: procent bestsellers, diversitate per brand / preț / categorie.
  • Intervențiile regulilor de business (guardrails) și al mecanismelor de fallback

La modificări de algoritm, rulezi backtesting (testare pe date vechi) și shadow mode (testare internă în paralel cu sistemul existent).

Managed

Pentru A/B folosești experimentele Vertex AI Search for commerce:

  • Schimbi obiectivele și strategiile fără a modifica codul programat.
  • Analizezi rezultatele în dashboarduri vizuale.
  • Ajustezi în funcție de KPI (de obicei de business).

Pentru analiză, există rapoarte și metrici vizuale în platformă: CTR, conversion rate, revenue per session. Se pot configura dashboarduri custom ca în varianta Build, de ex. în Looker Studio.

Poți rula experimente de tip shadow mode pe un nou model care nu este în producție, pentru a vedea intern rezultatele.

Poți experimenta inclusiv înlocuirea treptată a regulilor configurate de Boost / Bury / Filter cu cele auto-calculate de modelul AI (pe măsura efectelor pozitive).

 

Dacă ai trecut cu succes prin acești pași minimali, ai schițat un sistem de recomandări complet. Ai aflat că recomandările AI nu sunt un black box magic, ci o structură din sistemul de vânzări al companiei, în care datele, regulile și oamenii sunt esențiali.

Pe scurt:

  • Deep Learning nu este un singur proces, ci o succesiune de pași: definirea obiectivelor, curățarea și conectarea datelor, definirea evenimentelor, generarea candidaților, ranking și post-procesare, integrare în UX, feedback explicit, monitorizare.
  • Build (custom) oferă control maxim, dar cere echipă tehnică dedicată și disciplinată, în plus față de efortul întregii companii.
  • Managed (Cloud Native) externalizează o parte din complexitate, dar necesită decizii la nivelul companiei și configurare tehnică atentă.
  • Ambele variante depind de curățarea datelor și A/B testing pentru a obține rezultate.
EXEMPLE DE COD
4.2

Provocări și soluții în varianta Build (custom)

Prezentăm fragmente de cod pentru o implementare de tip Build (custom) de Deep Learning. Cele patru scenarii corespund provocărilor de business din Cap. 2.5: guardrails și contract de date, dar și provocărilor tehnice din Cap. 2.6: modele pe funcții de business și bundling.

Note

  • Exemplele sunt în pseudocod, pentru a arăta în practică câteva bucăți cheie de logică recomandări AI.
  • Pentru volume mari de date (Big Data) logica tinde să se mute din Python în Spark sau SQL pentru a evita iterări pe milioane de produse. Vezi exemple la Cap 4.2.4.
  • Exemplele de cod sunt simplificate pentru claritate și necesită adaptare la mediul de producție specific, plus autentificare/IAM, protecție pentru concurență, excepții, reîncercări etc.

Guardrails: Siguranța brandului și reguli de excludere

AI a produs un scor brut pentru fiecare candidat, iar guardrails trebuie să asigure că nu vindem produse sub marja minimă sau fără stoc și nu lăsăm UI-ul gol dacă API-urile nu funcționează.

Exemplu B1: Filtrare în pipeline-ul de recomandare (Python)

Snippet: pipeline care primește candidați cu scor și aplică guardrails înainte de a trimite către UI

from dataclasses import dataclass

@dataclass
class Candidate:
    sku: str
    score_ai: float
    stock: int
    margin_pct: float
    forbidden: bool = False

def apply_guardrails(
    candidates: list[Candidate],
    min_margin_pct: float,
    min_score_ai: float,
    max_items: int = 10,
) -> list[Candidate]:
    # 1. filtram produsele interzise, fara stoc sau sub marja minima
    filtered = [
        c for c in candidates
        if not c.forbidden
        and c.stock > 0
        and c.margin_pct >= min_margin_pct
        and c.score_ai >= min_score_ai
    ]

    # 2. daca dupa filtrare lista este prea scurta, completam cu fallback intern (get_top_selling_products)
    if len(filtered) < max_items:
        missing = max_items - len(filtered)
        exclude_skus = {c.sku for c in filtered}
        filtered.extend(get_top_selling_products(exclude_skus=exclude_skus, limit=missing))
    # 3. sortam dupa scorul AI și limitam
    filtered.sort(key=lambda c: c.score_ai, reverse=True)
    return filtered[:max_items]
    
    
Note
  • Guardrails sunt o funcție distinctă în pipeline.
  • Fallback (pasul 2) e la fel de important ca filtrarea.
  • Asigurați-vă că get_top_selling_products() aplică aceleași guardrails

Exemplu B2: Validare de calitate candidați la nivel de tabel (SQL)

Pe lângă filtrele la runtime, poți face verificări offline care detectează recomandările nedorite (ex: cu marjă negativă).

Snippet: pseudocod de detecție recomandări cu marjă sub prag

SELECT
  r.account_id
  , r.scenario
  , r.sku_recom
  , r.score_ai
  , p.margin_pct
  , r.created_at
FROM recommendations_log r
JOIN products p ON r.sku_recom = p.sku
WHERE 
  p.margin_pct <= 0.15 -- sau prag parametrizabil
  AND r.created_at > (NOW() - INTERVAL '1 DAY')
ORDER BY r.created_at DESC
LIMIT 100;
    
    
Note
  • Acest tip de interogări generează un raport al calității într-un dashboard de analiză.
  • Decizi în ce măsură guardrails-urile sunt suficiente sau mai trebuie definite.

Ingestie de date și consistență

Fără ingestie corectă, recomandările vor fi greșite. Pe lângă problema latenței, este importantă consistența datelor, toate evenimentele trebuie să aibă detaliile minime și să fie identificate unic pentru idempotență.

Exemplu B3: Model de eveniment (Python)

Snippet: structură de eveniment de actualizare stoc, validat înainte de pipeline / Feature Store

from pydantic import BaseModel, Field
from datetime import datetime
from typing import Optional

class InventoryUpdateEvent(BaseModel):
    sku: str
    new_stock: int = Field(ge=0)
    source: Optional[str] = None     # ex: "WMS", "ERP", "Manual"
    updated_at: datetime
    idempotency_key: str = Field(min_length=8)

    #aici se poate adauga logica de Feature (atribut) pentru care apoi se defineste pipeline-ul
    
    
Note
  • Validează datele minime (new_stock nu e negativ) și permite ingestia în orice ordine prin updated_at.
  • În B2B new_stock trebuie calculat de obicei ca stoc real (scriptic - rezervat) sau chiar liber la raft (din WMS).
  • idempotency_key asigură că la retry/trimitere dublată a aceluiași update de stoc, sistemul îl poate procesa o singură dată.

Exemplu B4: Upsert pentru stoc (SQL)

Snippet: pseudocod de Postgres pentru actualizare stoc. În BigQuery folosiți MERGE

INSERT INTO inventory (sku, stock, updated_at)
VALUES (:sku, :stock, :updated_at)
ON CONFLICT (sku)
DO UPDATE SET
  stock = EXCLUDED.stock
  , updated_at = EXCLUDED.updated_at
WHERE 
    inventory.updated_at IS NULL 
    OR inventory.updated_at < EXCLUDED.updated_at;
    
    
Note
  • Idempotența se poate implementa suplimentar cu un tabel de deduplicare sau un câmp (Ex: last_event_id).
  • Poți determina dacă produsul e eligibil pentru recomandări (stock > 0) și îl marchezi.
  • În caz de modificare, declanșezi un task care invalidează cache-ul local pentru el.

Exemplu B5: Verificare a consistenței stocului (SQL)

Snippet: pseudocod pentru detecția diferențelor între stocul oficial și cache-ul local de recomandări

SELECT
  i.sku
  , i.stock AS stock_official
  , c.stock_cache AS stock_recommender
FROM inventory i
JOIN recommender_cache c ON i.sku = c.sku
WHERE i.stock <> c.stock_cache;
    
    
Note
  • Investighezi unde ingestia real-time nu funcționează. Ex: update-uri pierdute, update-uri netrimise.
  • Este recomandat ca sistemul să detecteze problemele înainte ca ele să fie raportate de clienți sau agenți.

Alegerea modelului potrivit pentru funcția de business

Reamintim din Cap. 2.6.1 că nu există un singur model magic de recomandări. În practică, ai un model pentru Similare, un altul pentru Cumpărate împreună, poate altul pentru Cumpără din nou, plus modele speciale.

Exemplu B6: Router simplu de modele (Python)

Snippet: router care decide modelul și sursa de date în funcție de context, cu variantă Feature Store

from enum import Enum

class Scenario(Enum):
    SIMILAR_ITEMS = "similar_items"
    CART_ADDONS = "cart_addons"
    SUBSTITUTES = "substitutes"

# Registry de mapare scenariu -> model
MODEL_REGISTRY = {
    Scenario.SIMILAR_ITEMS:  "models/similar_items_v3",
    Scenario.CART_ADDONS:    "models/cart_addons_v5",
    Scenario.SUBSTITUTES:    "models/substitutes_v2",
}

# Daca folosesti un Feature Store, poti avea un registry separat pentru versiunile serviciilor scenariilor
FS_SERVICE_REGISTRY = {
    Scenario.SIMILAR_ITEMS:  "similar_items_service_v1",
    Scenario.CART_ADDONS:    "cart_addons_service_v2",
    Scenario.SUBSTITUTES:    "substitutes_service_v1",
}

def recommend_for_scenario(
    scenario: Scenario,
    account_id: str,
    context: dict,
) -> list[str]:
    model_path = MODEL_REGISTRY[scenario]
    
    full_context = context.copy()
    # interactiune cu Feature store (conceptual): mai intai obtii detaliile din store, apoi hidratezi contextul
    # fs_service = FS_SERVICE_REGISTRY[scenario]
    # account_features = call_fs_to_get_features(account_id=account_id, service=fs_service)
    # full_context.update(account_features)

    # Apel catre un model local sau un endpoint din cloud (cu toate datele necesare)
    scores = call_model(model_path, account_id=account_id, inputs=full_context)
    

    # scores e lista de (sku, score_ai), ex: [("SKU1", 0.92), ("SKU2", 0.87)...]
    ordered = sorted(scores, key=lambda x: x[1], reverse=True)
    return [sku for sku, _ in ordered]
    
    
Note
  • Organizarea versiunilor de modele și servicii este esențială și e bine să fie decuplată. Dacă nu știi ce versiune rulează într-un scenariu, nu poți explica ce se întâmplă în producție.
  • Prin hidratare afli foarte rapid înainte de inferența modelului ultimele atribute din Feature Store pentru acel account_id.
  • Logica de Feature Store este ascunsă, contractul call_fs_to_get_features include conectarea, caching și deserializarea (pentru latență minimă).

Exemplu B7: Config declarativ pentru scenarii

Snippet: configurație de scenariu într-un fișier declarativ (JSON sau YAML), ușor de modificat de arhitect sau product owner (vezi Cap. 5.2.1)

scenarios:
  similar_items:
    model: "models/similar_items_v3"
    max_items: 10

  cart_addons:
    model: "models/cart_addons_v5"
    max_items: 6

  substitutes:
    model: "models/substitutes_v2"
    max_items: 5
    
    
Note
  • Router-ul din exemplul anterior poate citi această configurație la startup.
  • Poți folosi principii de Convention over Configuration (ex: numele scenariului să corespundă numelui modelului, similar_items să fie și în numele store-ului de audit etc).

Bundling și pachete dinamice

Bundling-ul poate apărea în două locuri:

  • În sistemul de recomandare: ce pachet propun pentru coșul sau oferta curentă.
  • În data warehouse: ce propuneri recomandăm să devină pachete permanente în aplicație.

Într-o situație de producție cu milioane de tranzacții istorice, iterarea simplă (ex: Python) este ineficientă combinatoric (en. combinatorial explosion). Se folosesc clustere de date (ex: Databricks, Spark) pentru a căuta asocierile de forma "cine cumpără A, cumpără și B cu probabilitatea X".

Exemplu B8: Calcul reguli de asociere cu Spark (PySpark)

Snippet: algoritm FPGrowth (Frequent Pattern Growth) pentru a găsi asocieri

from pyspark.ml.fpm import FPGrowth
from pyspark.sql import SparkSession

spark = SparkSession.builder.getOrCreate()

# 1. Datele: fiecare rand este o tranzactie cu un array de SKU
# schema: [order_id: string, items: array<string>]
df_orders = spark.table("sales_history_clean")

# 2. Configuram algoritmul FPGrowth
# minSupport: produsele apar impreuna in X% din tranzactii
# minConfidence: cine ia A, are X% sanse sa ia si B
fp_growth = FPGrowth(itemsCol="items", minSupport=0.001, minConfidence=0.2)

# 3. Antrenam modelul distribuit
model = fp_growth.fit(df_orders)

# 4. Extragem regulile de asociere (antecedent -> consequent)
# schema: [antecedent: [SKU_A], consequent: [SKU_B], confidence: 0.85, lift: 2.4]
association_rules = model.associationRules

# Salvam intr-un tabel temporar pentru procesare ulterioara
association_rules.createOrReplaceTempView("raw_rules")
    
    
Note
  • Acest cod rulează distribuit pe un cluster de Spark (pentru o implementare Enterprise) și procesează istoricul rapid.
  • Rezultatul brut trebuie rafinat cu reguli de business (guardrails) ulterior.
  • În pre-procesare se pot îndepărta produsele prea comune care sunt zgomot statistic (en. noise): ambalaje, consumabile, transportul dacă are SKU în ERP.

Exemplu B9: Rafinare pachete asociate după marjă și stoc (Spark SQL)

După ce există asocierile, logica sistemului de recomandări se aplică prin verificări. Exemplificăm cu SQL peste Spark un caz complex:

  • Există tabelul de asocieri între pachete (antecedent) care pot avea mai multe produse și un singur produs recomandat (consequent).
  • Verificăm că produsele nu au fost șterse, au preț și cele asociate (consequent) au stoc > 10.
  • Calculăm marja totală a asocierii (antecedent + consequent).
  • Avantajăm dintre bundleurile cu marjă totală pozitivă pe cele cu un produs în stoc peste 120 de zile.
Snippet: sortare pachete după marjă și stoc vechi cu verificări de consistență (Hive/Spark)

WITH rule_financials AS (
    SELECT 
        r.antecedent
        , r.consequent
        , r.confidence
        -- COALESCE pentru a evita NULL
        , SUM(COALESCE(p_ant.margin_eur, 0)) as antecedent_total_margin        
        -- Verificam daca am gasit toate produsele din antecedent
        , COUNT(p_ant.sku) as found_ant_products
        , SIZE(r.antecedent) as expected_ant_products
        , MAX(COALESCE(p_cons.margin_eur, 0)) as consequent_margin
        , MAX(p_cons.days_in_inventory) as cons_days_inv
    FROM raw_rules r
    LATERAL VIEW explode(r.antecedent) a AS ant_sku
    -- JOIN pentru antecedent
    JOIN products p_ant ON a.ant_sku = p_ant.sku  
    -- JOIN pentru consequent cu filtrare directa de stoc > 10 
    JOIN products p_cons ON r.consequent[0] = p_cons.sku AND p_cons.stock_quantity > 10
    GROUP BY 
        r.antecedent
        , r.consequent
        , r.confidence
)

SELECT
    antecedent as current_basket
    , consequent[0] as recommended_upsell
    , confidence
    , (antecedent_total_margin + consequent_margin) as total_bundle_margin
    -- Calcul scor
    , (confidence 
        * (antecedent_total_margin + consequent_margin) 
        * (CASE WHEN cons_days_inv > 120 THEN 1.5 ELSE 1.0 END)
        ) as priority_score
FROM rule_financials
WHERE 
    -- la JOIN nu s-au pierdut produse din antecedent 
    found_ant_products = expected_ant_products
    -- eliminam marjele negative sau zero (recomandat)
    AND (antecedent_total_margin + consequent_margin) > 0
ORDER BY 
    priority_score DESC;
    
    
Note

Exemplu B10: Aplicare bundle în momentul ofertării (Python)

Când agentul construiește o ofertă, sistemul poate propune automat pachete pe baza listelor de bundle-uri:

Snippet: pseudocod care atribuie produselor curente bundle-uri precalculate

def suggest_bundles_for_quote(
    current_skus: list[str],
    bundles: dict[tuple[str, str], int],
    max_suggestions: int = 5,
) -> list[tuple[str, str]]:
    suggestions: list[tuple[str, str]] = []
    seen: set[tuple[str, str]] = set()
    current = set(current_skus)

    for sku in current_skus:
        for (a, b), _count in bundles.items():
            pair = None

            if sku == a and b not in current:
                pair = (a, b)
            elif sku == b and a not in current:
                pair = (b, a)

            if pair and pair not in seen:
                seen.add(pair)
                suggestions.append(pair)

                if len(suggestions) >= max_suggestions:
                    break

        if len(suggestions) >= max_suggestions:
            break

    return suggestions
    
    
Note
  • Compania nu mai depinde de memoria agentului (Gen 0) pentru a propune cross-sell, AI identifică tipare și în post-procesare regulile validează și ordonează pachetele conform politicii comerciale.
  • În producție, puteți indexa bundle-urile după SKU (hashmap) pentru a evita loop.
  • În producție, trebuie monitorizate 24/7 pipeline-urile de date și reîncercările (en. retries).

În plus față de codare, în abordarea Build este esențială infrastructura de servere, pipeline-urile de date și monitorizarea lor.

Studiu de caz: Infrastructură AI-Ready (web, email, vânzări)

În secțiunea următoare, vedem cum Google preia o parte din muncă prin configurarea abordării Managed.

EXEMPLE DE CONFIGURĂRI
4.3

Provocări și soluții în varianta Managed (Cloud Native)

Prezentăm exemple de configurări pentru o implementare Managed. Ele pot fi citite în oglindă cu secțiunea precedentă. Fragmentele ilustrează provocările de business din Cap. 2.5: guardrails și contract de date, dar și provocările tehnice din Cap. 2.6: modele pe funcții de business și bundling.

Elemente cheie:

  1. Evenimente (aproape) real-time: userEvents API.
  2. Reguli de business (guardrails): Serving Controls (Boost / Bury / Filter, Filter fiind folosit doar în modul Search), inclusiv variante site-wide (per toată aplicația).
  3. Strategii comerciale: configurații declarative JSON și obiectivul selectat pentru model (CTR / CVR / Revenue).
  4. Testare: ServingConfigs distincte și A/B testing din dashboard prin Experiments.

În aplicațiile care folosesc și componente generative (ex.: sumarizarea rezultatelor sau asistenți chatbots tip copilot), prompt-urile sunt construite pe baza acelorași câmpuri și reguli. Context engineering (produse, evenimente, clienți, reguli) este prima linie de control.

Definim configurația și lăsăm serviciul să se ocupe de scalare, training și monitorizare.

Notă: Exemplele de cod sunt conceptuale, ele necesită adaptare la mediul de producție specific. Verificați permanent documentația oficială pentru cheile și câmpurile exacte.

Guardrails și selecția ServingConfigs pentru un punct de inserție în aplicație

În varianta Build, am separat ce model chemăm (scenariu / router) de ce reguli aplicăm (guardrails). În varianta Managed, aceeași logică se exprimă prin:

  • ServingConfigs (parametru placement în API): folosit pentru orice punct de inserție (homepage_recs, cart_upsell).
  • filters și params în cererea de predicție.
  • eventual Serving Controls reutilizabile (Boost/Bury/Filter) pentru căutare.

Exemplu M1: Cerere de predicție pentru upsell cu filtre (Python)

Snippet: cod Python care cere pentru produsele din coș produse complementare, doar din gama non-hobby și cu stoc

from google.cloud import retail_v2

project_id = "PROJECT_ID"
catalog_id = "default_catalog"
serving_config_id = "cart_upsell"
# completati
account_id = "HASH_ID_ERP_CLIENT"
user_id = "HASH_ID_ERP_REPREZENTANT_CLIENT"
device_id = "HASH_ID_DEVICE_UNIC"

serving_config = (
    f"projects/{project_id}/locations/global/catalogs/{catalog_id}"
    f"/servingConfigs/{serving_config_id}"
)

client = retail_v2.PredictionServiceClient()

user_event = retail_v2.UserEvent(
    event_type="shopping-cart-page-view",
    visitor_id=device_id,
    user_info=retail_v2.UserInfo(user_id=user_id),
    product_details=[
        # SKU-urile din cos cu cantitatile
        retail_v2.ProductDetail(product=retail_v2.Product(id="SKU-HOLSURUB-36"), quantity=1),
        retail_v2.ProductDetail(product=retail_v2.Product(id="SKU-SURUB-35"), quantity=2)
    ]
)
# Custom attributes sunt esentiale in B2B
user_event.attributes["account_id"] = retail_v2.CustomAttribute(text=[account_id])

request = retail_v2.PredictRequest(
    placement=serving_config,
    user_event=user_event,
    page_size=10, #nr maxim recomandari
    filter='(availability: ANY("IN_STOCK")) AND NOT (categories: ANY("Hobby-DIY"))', #reguli de business
    params={
        "filterSyntaxV2": True, #permite filtre avansate
        "strictFiltering": True, # respecta filtrele scrise, fara fallback
        "diversityLevel": "medium-diversity",
        "returnProduct": True, #returneaza metadatele produselor
        "returnScore": True, #returneaza scorul AI,
        "priceRerankLevel": "low-price-reranking", # prioritizeaza usor produsele cu pret mare (nu profit) 
    },
)

response = client.predict(request=request)
    
    
Note

Guardrails se exprimă prin:

  • Expresii filter. Conform documentației.
  • Setarea diversityLevel pentru a evita monotonie în listă. Atenție, diversityLevel cu anumite filtre poate reduce drastic numărul de rezultate.

Exemplu M2: ServingConfig-uri diferite pentru scenarii diferite

În loc de un router custom de modele, folosim ServingConfig-uri diferite pentru scenarii:

  • projects/.../servingConfigs/homepage_recs
  • projects/.../servingConfigs/cart_upsell
  • projects/.../servingConfigs/product_page_similar
Snippet: cod Python care apelează ServingConfig-ul potrivit și primește ID-urile de produs

from typing import Any, Optional
from google.cloud import retail_v2


def recommended_for_placement(
    user_event: retail_v2.UserEvent,  # vezi Exemplul M1
    serving_config_id: str,  # Ex: "homepage_recs", "cart_upsell"
    project_id: str,
    catalog_id: str,         # Ex: "default_catalog"
    page_size: int = 10,
    filter_expr: Optional[str] = None,
    params: Optional[dict[str, Any]] = None = None,
) -> list[str]:
    client = retail_v2.PredictionServiceClient()

    serving_config = (
        f"projects/{project_id}/locations/global/catalogs/{catalog_id}/"
        f"servingConfigs/{serving_config_id}"
    )
    # construim request-ul de baza
    request = retail_v2.PredictRequest(
        placement=serving_config,
        user_event=user_event,
        page_size=page_size,  # nr maxim recomandari
        params={
            "filterSyntaxV2": True,
            "returnProduct": True,
            "returnScore": True,
        },
    )

    if filter_expr:
        request.filter = filter_expr

    if params:
        request.params.update(params)

    response = client.predict(request=request)
    
    # ID-uri produse recomandate
    return [result.id for result in response.results]
    
    
Note
  • Nu mai folosești "model_X_vY.pkl", scenariile sunt configurate la nivel de punct de inserție (placement), iar codul poate rămâne aproape neschimbat.
  • În spatele placement-ului, aplicația specifică către API Google un ServingConfig.

Cum captăm intenția utilizatorului: evenimentele în timp real

Primul pas de implementare este același ca în varianta Build: catalogul se încarcă prin feed-uri batch. Dar diferența critică este captarea evenimentelor în timp real prin API. Folosim Vertex AI Search for commerce ca punct central pentru userEvents cu o nuanță specifică B2B.

Exemplu M3: Eveniment detail-page-view (JavaScript)

Când un utilizator B2B intenționează să cumpere un produs, creăm un payload de tip "vizualizare pagină produs" care poate fi trimis prin GTM/pixel sau backend.

Trebuie decisă agregarea comportamentului unității de tracking (ex: companie, account, contract):
  • Documentația Google recomandă unicitatea visitorId per device și unicitatea userId per utilizator (ex: reprezentant al clientului).
  • Există atribute (en. features) care se pot trimite în UserEvent.attributes care vor ajuta trainingul modelului. Exemplul M1 folosește această metodă pentru a trimite account_id.
  • Puteți experimenta cu tratarea accountului client ca utilizator unic (userId = account_id). În acest caz, istoricul diferiților reprezentanți ai clientului se vor uni sub același userId. Exemplificăm mai jos.
  • În orice caz, câmpul attributionToken este folosit când s-a primit o căutare/recomandare anterioară, altfel modelul nu învață corelarea conversiei cu predicția.
Snippet: payload pentru detail-page-view

let account_id = "HASH_ID_ERP_CLIENT";
let device_id = "HASH_ID_DEVICE_UNIC";
                            
const userEvent = {
  eventType: "detail-page-view",
  visitorId: device_id,
  userInfo: { userId: account_id },
  productDetails: [{ product: { id: "SKU-SURUB-35" }, quantity: 1 }],
  eventTime: new Date().toISOString(),
};

// pentru evenimente downstream dupa un predict/search anterior
userEvent.attributionToken = attributionTokenFromPredict;
    
    

Exemplu M4: Scrierea evenimentului cu clientul Python

Snippet: Server-side (sau un worker dedicat) se trimite evenimentul prin API

from typing import Any
from google.cloud import retail_v2
from google.protobuf.json_format import ParseDict

def write_event_from_json(
    user_event_json: dict[str, Any], # Vezi Exemplul M3
    project_id: str,
    catalog_id: str, # Ex: "default_catalog"    
) -> retail_v2.UserEvent:
    
    client = retail_v2.UserEventServiceClient()

    parent = f"projects/{project_id}/locations/global/catalogs/{catalog_id}"

    # ParseDict preia chei camelCase si le mapează pe campuri proto
    user_event = ParseDict(user_event_json, retail_v2.UserEvent())

    request = retail_v2.WriteUserEventRequest(
        parent=parent,
        user_event=user_event,
    )

    return client.write_user_event(request=request)
    
    
Note
  • Nu trebuie să construiești infrastructura de machine learning. Trebuie să ai un mecanism robust de livrare a evenimentelor prin API.
  • Pe datele trimise de tine, serviciul gestionat de Google învață în funcție de configurare.

Ingestie date, consistență și experimentare

O parte din munca de lucru cu datele este preluată de serviciu prin feed-uri de catalog (și stoc), userEvents pentru comportament, configurări ServingConfig și A/B testing din dashboard.

Exemplu M5: Payload de actualizare stoc (verificați documentația actuală)

Snippet: produsul revine în stoc, pregătim un update de catalog

{
  "id": "SKU-HOLSURUB-36",
  "title": "Holsurub RTE 6x60 mm",
  "availability": "IN_STOCK", 
  "priceInfo": {
    "price": 45.90,
    "currencyCode": "EUR"
  },
  "fulfillmentInfo": [
    {
      "type": "pickup-in-store",
      "placeIds": ["store_cluj_1"]
    }
  ]
}

    
    

După trimitere, serviciul se va ocupa de propagarea stocului în index (actualizarea availability este aproape real-time)

Exemplu M6: A/B testing la nivel de ServingConfig

Vertex AI Search for commerce oferă suport în dashboard pentru experimente.

Separare tehnică configurări:

servingConfigs/homepage_recs_v1 (baza A cu controale sau obiective),

servingConfigs/homepage_recs_v2 (baza B cu controale sau obiective diferite).

În loc să construim logica de testare sau raportare, ne concentrăm pe:

  • definirea corectă a feed-urilor (catalog, utilizator, evenimente),
  • configurarea ServingConfig (model cu obiectiv, controale, diversitate),
  • configurarea Serving Controls . Boost / Bury pentru căutare și recomandări, Filter doar pentru căutare.
  • Menținerea attributionToken în evenimente pentru corelarea conversiilor cu predicțiile și adăugarea la UserEvent-urile trimise server-side a unor câmpuri speciale (ex: experimentIds, verifică documentația actuală) .
Vezi Ghidul #5 Optimizare continuă și raportare

Strategii comerciale și bundling

În varianta Build, logica de bundling, lichidare stoc și prioritizare a marjei se scria în cod. În varianta Cloud Native, multe decizii se exprimă declarativ: printr-un obiect ServingConfig și prin Serving Controls (Boost/Bury/Filter) atașate.

Exemplu M7: Config de ServingConfig pentru căutare (verificați documentația actuală)

Snippet: configurare ServingConfig pentru căutări pe homepage, poate folosi controale reutilizabile

{
  "displayName": "Produse Home",
  "solutionTypes": ["SOLUTION_TYPE_SEARCH"], // va fi folosit pentru cautare
  "boostControlIds": [
    "margin_boost" // vezi controlul de la Exemplul M9
  ]
}
    
    

Exemplu M8: Config de ServingConfig pentru recomandări (verificați documentația actuală)

Snippet: configurare ServingConfig pentru recomandări, nu folosește controale reutilizabile, poate folosi strategie de preț

{
  "displayName": "Recomandari upsell",
  "modelId": "upsell_model_v1", // numele modelului antrenat (cu obiectul selectat)
  "solutionTypes": ["SOLUTION_TYPE_RECOMMENDATION"], // va fi folosit pentru recomandari
  "priceRerankingLevel": "low-price-reranking", // prioritizeaza usor produsele cu pret mare (nu profit) 
  "diversityLevel": "high-diversity" // recomandat aici, nu la apelare in Python
}
    
    

Exemplu M9: Control global de căutare Boost pentru marjă (verificați documentația actuală)

Snippet: control care urcă mai sus în căutare produsele cu marjă bună

{
  "displayName": "Margin boost",
  "solutionTypes": ["SOLUTION_TYPE_SEARCH"],
  "rule": {
    "condition": { }, // se aplică tuturor cautarilor
    "boostAction": {
      "boost": 0.3, // valoare intre -1 si 1, sub 0 este Bury (retrogradare)
      "productsFilter": "attributes.margin_pct: IN(0.2i, *)" // marja mai mare sau egala cu 20%, atribut setat ca indexabil, i inseamna incluziv
    }
  }
}
    

Exemplu M10: Sugerare bundle-uri în coș (Python)

Snippet: funcție care obține bundle-urile active (adăugate deja în catalog) ale unui produs din coș.

from google.cloud import retail_v2
from collections.abc import Iterable

def recommend_bundles_for_cart_item(
    item_sku: str,
    cart_skus: Iterable[str],
    device_id: str, #HASH_ID_DEVICE_UNIC
    account_id: str, #HASH_ID_ERP_CLIENT (compania ca user)
    project_id: str = "PROJECT_ID",
    catalog_id: str = "default_catalog",
    serving_config_id: str = "bundle_recs",
    page_size: int = 6 
) -> list[str]:
   
    
    # 1. Creare user-event, folosim varianta de account ca user
    user_event = retail_v2.UserEvent(
        event_type="shopping-cart-page-view",
        visitor_id=device_id,
        user_info=retail_v2.UserInfo(user_id=account_id),
        product_details=[
            retail_v2.ProductDetail(product=retail_v2.Product(id=str(sku)), quantity=1)
            for sku in cart_skus
        ],
    )

    # 2. ANY("...") pentru exact match, atributele sunt de tip text si setate ca filtrabile
    filter_expr = (
        f'(availability: ANY("IN_STOCK")) AND '
        f'(attributes.is_bundle: ANY("true")) AND '
        f'(attributes.bundle_component_skus: ANY("{item_sku}"))'
    )
    
    # 3. Vezi Exemplul M2
    ids = recommended_for_placement(
        user_event=user_event,    
        serving_config_id=serving_config_id,
        project_id=project_id,
        catalog_id=catalog_id,
        page_size=page_size,
        filter_expr=filter_expr
    )

    return ids
Note
  • Se folosește solutionTypes (plural) în definiția Serving Controls reutilizabile.
  • Similar cu Exemplul M9, puteți trimite la sfârșitul căutării produsele fără stoc cu un Bury (boost negativ).
  • Exemplul M10 arată ingineria de date necesară pentru a sugera bundle-uri în coș. Acestea au fost create în aplicație, trimise către Vertex AI Search for commerce cu atribute custom is_bundle și bundle_component_skus, AI urmând să le recomande în funcție de obiectiv pentru coșul curent.
  • În modelul "privacy-first" din Cap. 2.4.4., nu toate datele vor fi trimise către cloud, deci o parte din logică trebuie mutată din ServingConfigs în middleware (aplicație).

Studiu de caz: Integrare ERP Entersoft-Vertex AI Search pentru distribuție

Esențialul:

Un sistem de recomandări se poate implementa fie în varianta Build (custom), fie în varianta Managed (Cloud Native), cu un compromis între control low-level și viteză de implementare și mentenanță:

  • În Build, regulile sunt cod (ex: Python, Java, Go).
  • În Managed, regulile se mută în general din cod în configurații declarative și inginerie de date.
  • În Managed, modelul este gestionat de Google, iar programatorii se concentrează pe sincronizarea datelor, definirea guardrails și eventuale extinderi (ex: prognoze temporale discutate la Cap. 2.1.4).

Dacă evaluați posibilitatea de a implementa in-house una dintre cele două variante, puteți urma pașii de proiect recomandați mai sus. Varianta Build este recomandată dacă aveți o echipă de dezvoltare ML și date proprii. Varianta Managed este recomandată pentru livrare mai rapidă.

Vezi matricea de costuri și metodologia noastră în Cap. 5

Ai nevoie de o validare tehnică înainte de implementare? OPTI Software poate oferi un audit gratuit.

Continuă în ghid

Capitolul 1
De ce AI?
Analiza problemei: "ERP-ul nu este un motor de vânzări". Contextul național (România) și cultura discount-ului.
Citește Business Case
Capitolul 2
Cum funcționează?
Generații de recomandări și Deep Learning. Obiective și KPI. Build vs. Managed. Guardrails și contractul de date.
Vezi tehnologia
Capitolul 3
Ce se poate construi?
Livrabile construite pentru vânzări B2B.
Copilot agenți
Smart Bundles
Substitutes
Re-order
Vezi toate livrabilele
Capitolul 5
Când și cu ce resurse?
Structura echipei, resursele necesare, buget și garanțiile Google Cloud. Plus: metodologia noastră.
Vezi structura de cost
Noutăți AI
Viitor: AI agentic
Lansarea UCP în ian. 2026, tehnologii AI noi care se maturizează și cum se pot adapta companiile.
Vezi noutățile AI
Resurse
Resurse și glosar
Glosar (AI, business, software) + bibliografie, whitepaper-uri și linkuri utile din ghid.
Vezi resursele
Galerie
Navighează tematic
Explorează resurse pe roluri (CEO, Business etc.) într-o galerie tematică
Alege rolul și tema

Întrebări rapide

Ce înseamnă o implementare Build în practică?

Înseamnă control total asupra pipeline-urilor de date, regulilor și logicii de decizie, folosind tehnologii precum SQL, Spark și cod custom pentru ranking și guardrails.

De ce este importantă idempotency în evenimente?

Pentru că update-urile de stoc și preț pot fi trimise de mai multe ori. Fără idempotency, sistemele ajung rapid în stări inconsistente.

Ce păstrezi într-un sistem Managed?

Retrieval-ul, modelele pre-antrenate și infrastructura scalabilă. Logica comercială critică rămâne de obicei în middleware.

Cum eviți lock-in-ul tehnic?

Separând clar datele, regulile și modelele, și păstrând exportabilitatea logicii critice.

Care este concluzia (TLDR)?

Acest capitol arată cum se construiește efectiv sistemul: ce evenimente trimiți, cum eviți duplicatele, cum ții stocul coerent și cum aplici guardrails, astfel încât recomandările să fie utile și auditabile.

Care sunt tehnologiile și metodologiile implicate?

Tehnologii: Python, SQL, JavaScript, Postgres, MySQL, BigQuery, Spark, Databricks, Vertex AI Search, Vertex AI Search for commerce, Retail API, Cloud Logging, Cloud Monitoring, Pub/Sub, Dataflow, Cloud Run
Metodologii: event-driven architecture, idempotency keys, deduplicare, UPSERT/MERGE, validare JIT (stoc/preț/permisiuni), market basket analysis (FP-Growth), offline scoring (NDCG/Recall), A/B testing, shadow testing, observability și reason codes

Cere formatul PDF complet

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

Interesat?

Ești interesat?

programează o întâlnire

Cere consultanță gratuită

Noutăți și ghiduri

Mai multe noutăți