Ciclul de viață LLMOps: de la prototip la producție în LLMOps, Evaluare & Securitate AI

Etapele prin care trece o aplicație bazată pe LLM până în producție: prompturi versionate, evaluare automată, guardrails, lansare controlată și observabilitate.

Configurare & comandă
# Etapele unei aplicații LLM, de la prototip la producție
1. Prompturi și prototip       -> prompturi versionate, comparații între modele
2. Evaluare înainte de lansare -> set de date de evaluare, evaluări automate în CI
3. Securitate (guardrails)     -> filtre pe intrare și ieșire, PII, prompt injection
4. Lansare și rutare           -> gateway, fallback, cache, bugete
5. Observabilitate             -> trace-uri, costuri, latență, feedback, drift

LLMOps (Large Language Model Operations) este setul de practici prin care o aplicație bazată pe un model de limbaj ajunge de la un prototip la un serviciu în producție, monitorizat și cu costuri cunoscute. Nu există o listă oficială de etape; împărțirea de mai sus urmează funcțiile acoperite de uneltele din această secțiune.

Înainte de lansare, echipa construiește un set de date de evaluare (întrebări reprezentative cu răspunsuri sau contexte de referință) și rulează evaluări automate la fiecare schimbare de prompt, de model sau de pipeline RAG. Langfuse și LangSmith păstrează seturile de date și rezultatele experimentelor; Ragas, DeepEval și Promptfoo calculează metricile.

În producție, cererile trec prin verificări de securitate (de exemplu detectarea datelor personale sau a tentativelor de prompt injection), eventual printr-un gateway care face rutare și fallback, iar fiecare cerere este înregistrată ca trace: pașii intermediari, tokenii, costul și durata. Feedback-ul utilizatorilor și scorurile automate se atașează trace-urilor, iar exemplele cu probleme ajung în setul de evaluare.

Concepte cheie și caracteristici

Concept / Parametru Descriere practică
Set de date de evaluare Întrebări reprezentative cu răspunsuri sau contexte de referință verificate. Mărimea depinde de aplicație; contează să acopere cazurile reale și pe cele critice.
Evaluare în CI Evaluări rulate automat la fiecare pull request (de exemplu deepeval test run sau promptfoo eval), cu un prag minim pentru metrici.
Trace Înregistrarea unei cereri complete: apelurile la model, căutările, uneltele, tokenii, costul și durata fiecărui pas.
Feedback și scoruri Evaluări de la utilizatori (pozitiv / negativ) sau de la evaluatori automați, atașate trace-urilor.
Guardrails Verificări programatice pe intrare și ieșire: date personale, subiecte interzise, format JSON, prompt injection.

Exemple practice și scenarii reale

Exemplul 1: Evaluări rulate în GitHub Actions

Pasul pică dacă un test DeepEval are o metrică sub prag. Comanda este cea din documentația DeepEval pentru CI.

# .github/workflows/evals.yml (fragment)
- name: Evaluări LLM
  run: deepeval test run test_asistent.py

Exemplul 2: Nume logice de modele într-un gateway

Aplicația cere numele logic, iar LiteLLM Proxy alege modelul concret. Schimbarea modelului nu mai cere modificări în cod.

model_list:
  - model_name: asistent-rapid
    litellm_params:
      model: anthropic/claude-haiku-5-5
  - model_name: asistent-complex
    litellm_params:
      model: anthropic/claude-sonnet-5-5

Exemplul 3: Feedback de la utilizator atașat unui trace

SDK-ul Python Langfuse v5.

from langfuse import get_client

langfuse = get_client()
langfuse.create_score(
    name="feedback_utilizator",
    value=1,
    trace_id=trace_id,
    data_type="NUMERIC",
)

Greșeli frecvente și capcane

  • Lansezi fără un set de date de evaluare. Fără el nu poți spune dacă o schimbare de prompt sau de model a îmbunătățit aplicația sau a stricat-o.
  • Tratezi feedback-ul utilizatorilor ca opțional. Este una dintre puținele surse de exemple reale pentru setul de evaluare.
  • Măsori doar calitatea. Un model mai bun poate fi prea scump sau prea lent pentru volumul tău; urmărește și costul și latența.

Noțiuni și module înrudite