Opservabilnost i evaluacija AI sustava u produkciji: Vodič za LLM monitoring u 2026.

Uvod

Zamislite ovaj scenarij: vaš tim je mjesecima radio na sofisticiranom AI sustavu — RAG cjevovod koji pretražuje tisuće dokumenata, višeagentni radni tijek koji koordinira specijalizirane LLM-ove, ili chatbot koji korisnicima pruža podršku 24/7. Sustav je implementiran u produkciju, korisnici pristižu, i... kako zapravo znate da sve funkcionira kako treba?

Kako znate da vaš model ne halucinira? Da troškovi ne izmiču kontroli? Da se kvaliteta odgovora nije tiho degradirala nakon zadnjeg ažuriranja?

Ako nemate odgovor na ta pitanja — niste sami. Prema istraživanjima iz 2026., kvaliteta izlaza ostaje primarna prepreka u produkciji za 32% organizacija koje koriste AI agente, dok istodobno 89% organizacija tvrdi da je implementiralo neki oblik opservabilnosti. Ta razlika između brojki govori jasnu priču: većina timova zna da im treba praćenje, ali mnogi se i dalje muče s učinkovitom implementacijom.

U prethodnim člancima istražili smo kako izgraditi višeagentne sustave, produkcijske RAG cjevovode, kako primijeniti napredne tehnike inženjeringa promptova i kako fino podesiti velike jezične modele. Svi ti sustavi dijele jednu zajedničku potrebu: nakon što ih pustite u produkciju, morate ih moći pratiti, evaluirati i kontinuirano poboljšavati.

Upravo o tome govorimo danas. Istražit ćemo tri ključne dimenzije upravljanja AI sustavima u produkciji — monitoring, opservabilnost i evaluaciju — te ćemo kroz praktične primjere koda i pregled vodećih alata pokazati kako ih implementirati u vlastitim projektima. Bez obzira gradite li jednostavan LLM chatbot ili kompleksni višeagentni sustav, ovdje ćete pronaći konkretne korake za uspostavu pouzdane produkcijske infrastrukture.

Monitoring, opservabilnost i evaluacija: ključne razlike

Prije nego zaronimo u alate i implementaciju, vrijedi razjasniti tri pojma koji se često koriste naizmjenično, ali zapravo pokrivaju vrlo različite aspekte upravljanja AI sustavima.

Monitoring — zdravstvena provjera u stvarnom vremenu

Monitoring prati metrike sustava u stvarnom vremenu: latenciju, potrošnju tokena, troškove, stope pogrešaka i dostupnost. Zamislite ga kao nadzornu ploču u kontrolnoj sobi — vidite crvena i zelena svjetla, ali ne znate nužno zašto je nešto crveno. Monitoring odgovara na jedno pitanje: „Radi li sustav?"

Tipične metrike monitoringa uključuju:

• Latenciju — prosječno i percentilno (P95, P99) vrijeme odgovora
• Throughput — broj obrađenih zahtjeva po sekundi
• Potrošnju tokena — ukupan broj ulaznih i izlaznih tokena
• Troškove — rashode po modelu, korisniku ili značajki
• Stope pogrešaka — postotak neuspješnih zahtjeva

Opservabilnost — razumijevanje "zašto"

Opservabilnost ide korak dalje. Pruža potpuno praćenje zahtjeva (tracing) koje pokazuje zašto je nešto pošlo po krivu. Kada monitoring signalizira problem, opservabilnost pomaže u dijagnostici rekonstrukcijom cijelog lanca događaja — od korisničkog unosa, kroz razmišljanje modela, pozive alata, dohvat konteksta, sve do konačnog izlaza.

Opservabilnost odgovara na pitanje: „Zašto sustav ne radi ispravno?"

I evo zašto je to za AI sustave posebno bitno: LLM-ovi su nedeterministički. Isti ulaz može proizvesti različite izlaze, agenti donose autonomne odluke o pozivanju alata, a lanci razmišljanja mogu se protezati kroz desetke koraka. Bez duboke opservabilnosti, dijagnostika problema svodi se na — iskreno — nagađanje.

Evaluacija — kontrola kvalitete

Evaluacija mjeri kvalitetu izlaza kroz testove točnosti, detekciju halucinacija, procjenu relevantnosti i usklađenost s poslovnim zahtjevima. To je vaša kontrola kvalitete — provjera prije i nakon implementacije. Odgovara na pitanje: „Je li izlaz sustava dovoljno dobar?"

Najučinkovitiji pristup kombinira sve tri dimenzije u ciklus:

1. Evaluacija prije implementacije — automatski testovi u CI/CD cjevovodu hvataju regresije prije nego dođu do korisnika
2. Monitoring u produkciji — nadzorne ploče u stvarnom vremenu prate zdravlje sustava
3. Opservabilnost za dijagnostiku — kada monitoring otkrije problem, opservabilnost pomaže pronaći uzrok
4. Evaluacija u produkciji — kontinuirana procjena kvalitete na stvarnim korisničkim podacima

Zašto je opservabilnost AI sustava neophodna u 2026.

Ako ste ikada vodili LLM aplikaciju u produkciji, sigurno ste doživjeli barem jednu od sljedećih situacija: model je počeo davati čudne odgovore nakon ažuriranja, troškovi su naglo skočili bez jasnog razloga, ili su korisnici prijavili probleme koje niste mogli reproducirati. Zvuči poznato? U svim tim slučajevima, dobra opservabilnost uštedjela bi vam sate (ili dane) dijagnostike.

Eksplozija složenosti AI sustava

U 2026. AI sustavi više nisu jednostavni LLM pozivi s jednim promptom. Moderni sustavi uključuju višestruke modele, RAG cjevovode s vektorskim bazama, pozive alata putem MCP protokola, višeagentnu orkestraciju i kompleksne lance razmišljanja. Svaki od tih slojeva dodaje točku potencijalnog kvara koju treba pratiti.

Razmjeri su impresivni — prema podacima iz industrije, neljudski identiteti u poduzećima nadmašuju ljudske u omjeru 50:1, s projekcijama rasta na 80:1 u sljedećim godinama. Svaki AI agent, svaki automatski radni tijek i svaki LLM poziv predstavlja identitet koji treba nadzirati. Pokretanje LLM sustava bez opservabilnosti u 2026. smatra se, blago rečeno, operativno neodgovornim.

Ključni izazovi u produkciji

Tri su dimenzije evaluacijskih izazova s kojima se timovi suočavaju:

• Mjerenje kvalitete izlaza — kako sustavno procijeniti jesu li odgovori točni, relevantni i korisni u različitim scenarijima?
• Kontrola troškova — u višekoračnim radnim tijekovima, jedan neučinkovit agent može dramatično povećati ukupne troškove, a da to nije odmah vidljivo
• Usklađenost s regulativom — EU AI Act i drugi regulatorni okviri zahtijevaju revizijske tragove i transparentnost u donošenju odluka AI sustava

Model drift i degradacija kvalitete

Ovo je možda najzanimljiviji (i najfrustrantiji) aspekt. Za razliku od tradicionalnog softvera koji se ponaša konzistentno dok ga netko ne promijeni, LLM sustavi mogu degradirati bez ikakvog koda koji se promijenio. Pružatelj modela može tiho ažurirati model, distribucija korisničkih upita može se promijeniti, ili se kvaliteta dohvaćenih dokumenata u RAG sustavu može pogoršati. Kontinuirana opservabilnost jedini je način da se takve promjene pravodobno otkriju.

Pregled vodećih alata za opservabilnost i evaluaciju

Tržište alata za opservabilnost AI sustava brzo raste, ali nekoliko platformi jasno se ističe u 2026. Pogledajmo svaku od njih.

Langfuse — otvoreni kod za potpunu opservabilnost

Langfuse je trenutno najkorišteniji open-source alat za opservabilnost LLM aplikacija. Pruža sveobuhvatno praćenje (tracing), evaluacije, upravljanje promptovima i metrike za dijagnostiku i poboljšanje LLM aplikacija. Agnostičan je u pogledu modela i okvira, nudi mogućnosti self-hostinga i odlično se integrira s OpenTelemetry, LangChain i OpenAI SDK-om.

Najnovije verzije Langfuse SDK-ova (Python SDK v3+ i JS SDK v4+) izgrađene su na OpenTelemetry standardu. Kada inicijalizirate Langfuse, automatski se registrira procesor raspona (span processor) koji hvata podatke o praćenju i šalje ih na platformu.

Ključne značajke:

• Potpuno praćenje zahtjeva s detaljnim informacijama o svakom koraku
• Upravljanje promptovima s verzioniranjem
• Evaluacijske funkcionalnosti s LLM-as-judge pristupom
• Analitika troškova i latencije
• Self-hosting opcija za potpunu kontrolu nad podacima

Arize Phoenix — otvoreni kod temeljen na OpenTelemetry

Arize Phoenix je potpuno open-source alat koji se može pokrenuti jednom Docker naredbom i koji je neograničen za korištenje na vlastitoj infrastrukturi ili u oblaku. Phoenix koristi OpenInference — OTel-kompatibilni sloj za automatsku instrumentaciju koji hvata svaki prompt, poziv alata i korak agenta s sub-sekundnom latencijom.

Ono što ga posebno čini korisnim su anotacijski redovi koji omogućuju recenzentima označavanje bilo kojeg praćenja ili skupa podataka, uz automatsko ponovno izračunavanje metrika. Nedavno je dodana i opsežna podrška za evaluaciju agenata — uključujući evaluacije putanja, konvergencije i sesija.

Braintrust — evaluacija i monitoring u jednom

Braintrust je end-to-end platforma dizajnirana za praćenje, evaluaciju i poboljšanje LLM aplikacija u produkciji. Za razliku od općenitih alata za praćenje, kombinira monitoring, evaluaciju kvalitete i eksperimentiranje u jednoj integriranoj platformi.

Posebno se ističe automatizacijom evaluacija u CI/CD cjevovodima — može automatski pokrenuti evaluatore (scorers), analizirati statističku značajnost i blokirati merge kada kvaliteta padne ispod definiranog praga. Podržava 13+ okvira, uključujući LangChain, LlamaIndex, OpenAI Agents SDK, CrewAI, AutoGen i druge.

Datadog LLM Observability — enterprise rješenje

Datadog LLM Observability pruža end-to-end praćenje AI agenata s vidljivošću u ulaze, izlaze, latenciju, potrošnju tokena i pogreške na svakom koraku. Posebno je koristan za enterprise infrastrukturne slučajeve uporabe gdje se Datadog već koristi za praćenje ostatka infrastrukture — sve je na jednom mjestu.

DeepEval — open-source okvir za evaluaciju

DeepEval, razvijen od strane Confident AI, je open-source okvir za evaluaciju LLM sustava koji funkcionira slično Pytestu, ali je specijaliziran za jedinično testiranje LLM izlaza. S više od 50 evaluacijskih metrika utemeljenih na istraživanjima, pokriva sve — od detekcije halucinacija i procjene vjernosti (faithfulness) do relevantnosti odgovora i toksičnosti.

Promptfoo — deklarativno testiranje promptova

Promptfoo je lagan, fleksibilan i open-source okvir fokusiran na deklarativnu YAML konfiguraciju za testiranje promptova. Podržava tipove provjera od podudaranja stringova do LLM-as-judge rubrika. Zanimljiv detalj: Anthropic ga interno koristi za mnoge svoje produkcijske evaluacije.

Koji alat odabrati?

Izbor pravog alata ovisi o specifičnim potrebama vašeg tima i projekta. Evo smjernica koje bi vam mogle pomoći:

• Za timove koji tek počinju: Langfuse je vjerojatno najpristupačniji izbor — open-source je, jednostavan za postavljanje i pruža solidnu ravnotežu između opservabilnosti i evaluacije. Self-hosting opcija znači potpunu kontrolu nad osjetljivim podacima.
• Za timove s postojećom ML infrastrukturom: Arize Phoenix se odlično uklapa jer proširuje postojeće ML opservabilnosti na LLM domenu. Ako već koristite OpenTelemetry, integracija je gotovo automatska.
• Za timove s brzim release ciklusima: Braintrust sa svojom mogućnošću blokiranja merge-ova na temelju evaluacijskih rezultata idealan je za timove koji isporučuju promjene svakodnevno i ne mogu si priuštiti regresije kvalitete.
• Za enterprise organizacije: Datadog LLM Observability najsmisleniji je ako vaša organizacija već koristi Datadog — sve na jednom mjestu, s postojećim pristupnim kontrolama i integracijama.
• Za evaluaciju kao prioritet: DeepEval je pravi izbor kada vam je primarni fokus rigorozno testiranje kvalitete izlaza, pogotovo za RAG sustave gdje su metrike poput vjernosti i halucinacija kritične.

Mnogi timovi u praksi koriste kombinaciju alata — primjerice, Langfuse za opservabilnost u produkciji i DeepEval za evaluacije u CI/CD cjevovodu. Ovi alati nisu međusobno isključivi, a open-source priroda većine njih znači da možete eksperimentirati bez financijskog rizika.

Praktični primjer: postavljanje praćenja s Langfuse i OpenTelemetry

Dosta teorije — ajmo vidjeti kako u praksi postaviti opservabilnost za LLM aplikaciju. Koristit ćemo Langfuse jer je open-source, temeljen na OpenTelemetry standardu i (što je za mnoge presudno) jednostavan za integraciju.

Korak 1: Instalacija paketa

Prvo instaliramo potrebne Python pakete:

pip install langfuse openai openlit

Korak 2: Konfiguracija okruženja i autentifikacija

Postavimo vjerodajnice za Langfuse i OpenTelemetry endpoint:

import os
import base64

# Langfuse vjerodajnice
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-lf-vas-kljuc"
os.environ["LANGFUSE_SECRET_KEY"] = "sk-lf-vas-tajni-kljuc"
os.environ["LANGFUSE_BASE_URL"] = "https://cloud.langfuse.com"

# Kreiranje Base64 autentifikacijskog tokena
LANGFUSE_AUTH = base64.b64encode(
    f"{os.environ['LANGFUSE_PUBLIC_KEY']}:{os.environ['LANGFUSE_SECRET_KEY']}".encode()
).decode()

# Konfiguracija OpenTelemetry OTLP endpointa
os.environ["OTEL_EXPORTER_OTLP_ENDPOINT"] = (
    os.environ["LANGFUSE_BASE_URL"] + "/api/public/otel"
)
os.environ["OTEL_EXPORTER_OTLP_HEADERS"] = f"Authorization=Basic {LANGFUSE_AUTH}"

# OpenAI API ključ
os.environ["OPENAI_API_KEY"] = "sk-proj-vas-openai-kljuc"

Korak 3: Inicijalizacija klijenta i verifikacija veze

from langfuse import get_client

langfuse = get_client()

# Verifikacija povezanosti
if langfuse.auth_check():
    print("Langfuse klijent je autentificiran i spreman!")
else:
    print("Autentifikacija nije uspjela. Provjerite vjerodajnice.")

Korak 4: Kreiranje raspona i praćenja

Langfuse koristi koncept raspona (spans) i generacija (generations) za strukturiranje praćenja. Raspon predstavlja jedinicu rada, a generacija je specijalizirani raspon za LLM pozive:

from langfuse import get_client

langfuse = get_client()

# Kreiranje raspona pomoću upravitelja konteksta
with langfuse.start_as_current_observation(
    as_type="span", name="obrada-korisnickog-upita"
) as span:
    span.update(input="Korisnik je postavio pitanje o proizvodu")

    # Ugniježđena generacija za LLM poziv
    with langfuse.start_as_current_observation(
        as_type="generation",
        name="llm-odgovor",
        model="gpt-4.1",
        model_parameters={"temperature": 0.7}
    ) as generation:
        # Ovdje bi bio stvarni LLM poziv
        generation.update(
            input=[{"role": "user", "content": "Što je opservabilnost?"}],
            output="Opservabilnost je sposobnost razumijevanja...",
            usage={"input_tokens": 15, "output_tokens": 42}
        )

    span.update(output="Zahtjev uspješno obrađen")

# Ispražnjivanje događaja (važno za kratkotrajne aplikacije)
langfuse.flush()

Korak 5: Automatska instrumentacija s OpenLIT

Za najjednostavniju integraciju, OpenLIT pruža automatsku instrumentaciju koja hvata sve LLM pozive bez ručnog dodavanja koda za praćenje. Ovo je pristup koji osobno preferiram za brze prototipove:

import openlit
from openai import OpenAI

# Inicijalizacija automatske instrumentacije
openlit.init()

# Svi OpenAI pozivi automatski se prate i šalju na Langfuse
client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4.1",
    messages=[
        {"role": "system", "content": "Odgovaraj na hrvatskom jeziku."},
        {"role": "user", "content": "Objasni razliku između monitoringa i opservabilnosti."}
    ]
)
print(response.choices[0].message.content)

S ovom postavkom, svaki poziv OpenAI API-ju automatski će se zabilježiti u Langfuse s potpunim informacijama o ulazu, izlazu, potrošnji tokena, latenciji i troškovima. Bez ikakve dodatne promjene u vašem kodu — i to je ono što čini ovaj pristup tako praktičnim.

Praćenje RAG cjevovoda

Za RAG sustave praćenje je posebno važno jer želite razumjeti ne samo kvalitetu konačnog odgovora, već i kvalitetu dohvaćenih dokumenata. Evo kako to izgleda:

from langfuse import get_client

langfuse = get_client()

with langfuse.start_as_current_observation(
    as_type="span", name="rag-cjevovod"
) as trace:
    # Korak 1: Dohvat dokumenata
    with langfuse.start_as_current_observation(
        as_type="span", name="vektorska-pretraga"
    ) as retrieval:
        # Simulacija dohvata iz vektorske baze
        documents = retrieve_from_vector_db(query="AI opservabilnost")
        retrieval.update(
            input={"query": "AI opservabilnost", "top_k": 5},
            output={"num_results": len(documents), "scores": [0.92, 0.87, 0.81]},
            metadata={"vector_db": "chromadb", "collection": "docs_hr"}
        )

    # Korak 2: Generiranje odgovora
    with langfuse.start_as_current_observation(
        as_type="generation", name="rag-generacija", model="gpt-4.1"
    ) as generation:
        context = "\n".join([doc.content for doc in documents])
        response = generate_answer(query="AI opservabilnost", context=context)
        generation.update(
            input={"query": "AI opservabilnost", "context_length": len(context)},
            output=response,
            usage={"input_tokens": 850, "output_tokens": 200}
        )

    trace.update(output={"answer": response, "sources": len(documents)})

langfuse.flush()

Evaluacija kvalitete LLM izlaza s DeepEval

Praćenje vam pokazuje što se događa u vašem sustavu. Ali to nije dovoljno — trebate znati i koliko dobro sustav funkcionira. Tu na scenu stupa DeepEval, open-source okvir koji evaluaciju čini jednako jednostavnom kao pisanje unit testova.

Instalacija i osnovni koncept

pip install deepeval

DeepEval koristi koncept testnih slučajeva (test cases) i metrika (metrics). Testni slučaj sadrži ulaz, stvarni izlaz i opcionalni kontekst, dok metrika definira kako se izlaz procjenjuje. Funkcionira slično tradicionalnom unit testiranju, ali umjesto usporedbe s točnim očekivanim izlazom, koriste se sofisticirani evaluatori — uključujući LLM-as-judge pristup.

Detekcija halucinacija

HallucinationMetric provjerava sadrži li izlaz modela informacije koje nisu podržane danim kontekstom. Za svaki sustav koji prikazuje informacije korisnicima, ovo je kritična metrika — vjerujte mi na riječ:

from deepeval import evaluate
from deepeval.metrics import HallucinationMetric
from deepeval.test_case import LLMTestCase

# Kontekst koji služi kao izvor istine
context = [
    "Naša tvrtka nudi 30 dana za povrat proizvoda bez dodatnih troškova.",
    "Povrat je moguć samo za nekorištene proizvode u originalnom pakiranju."
]

test_case = LLMTestCase(
    input="Kakva je vaša politika povrata?",
    actual_output=(
        "Nudimo 30-dnevni potpuni povrat novca bez dodatnih troškova. "
        "Proizvod mora biti nekorišten i u originalnom pakiranju. "
        "Također nudimo besplatnu dostavu za zamjenske proizvode."
    ),
    context=context
)

metric = HallucinationMetric(threshold=0.7)
evaluate(test_cases=[test_case], metrics=[metric])

U ovom primjeru, tvrdnja o „besplatnoj dostavi za zamjenske proizvode" nije podržana kontekstom — DeepEval će to prepoznati kao halucinaciju i smanjiti ocjenu. Elegantno, zar ne?

Evaluacija vjernosti (faithfulness) za RAG sustave

FaithfulnessMetric je posebno dizajniran za RAG cjevovode. Mjeri koliko se stvarni izlaz faktički podudara s dohvaćenim kontekstom. Rezultat se računa jednostavno: Faithfulness = Broj istinitih tvrdnji / Ukupan broj tvrdnji.

from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import FaithfulnessMetric

# Kontekst dohvaćen iz vektorske baze
retrieval_context = [
    "Langfuse je open-source platforma za opservabilnost LLM aplikacija.",
    "Langfuse podržava OpenTelemetry standard za praćenje.",
    "Langfuse nudi self-hosting opciju i cloud verziju."
]

metric = FaithfulnessMetric(
    threshold=0.7,
    model="gpt-4.1",
    include_reason=True
)

test_case = LLMTestCase(
    input="Što je Langfuse?",
    actual_output=(
        "Langfuse je open-source platforma za opservabilnost LLM aplikacija "
        "koja podržava OpenTelemetry standard. Dostupna je kao self-hosted "
        "rješenje ili kao cloud servis."
    ),
    retrieval_context=retrieval_context
)

result = evaluate(test_cases=[test_case], metrics=[metric])
# Rezultat: visoka ocjena jer su sve tvrdnje podržane kontekstom

Prilagođene evaluacije s G-Eval

Kada ugrađene metrike nisu dovoljne (a to se u praksi često dogodi), DeepEval omogućuje kreiranje prilagođenih evaluacija s G-Eval — pristupom temeljenim na lancu misli (chain-of-thought). Ovo je posebno korisno za domenu specifične zahtjeve:

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCaseParams

# Prilagođena metrika za tehničku točnost
tehnicka_tocnost = GEval(
    name="Tehnička točnost",
    evaluation_steps=[
        "Identificiraj sve tehničke tvrdnje u izlazu.",
        "Provjeri svaku tehničku tvrdnju prema dohvaćenom kontekstu.",
        "Prepoznaj neobrazložene tehničke tvrdnje ili pogrešne terminologije.",
        "Strožije penaliziraj netočne tehničke tvrdnje nego stilske nedostatke.",
        "Obrazloži ocjenu s konkretnim primjerima iz teksta."
    ],
    evaluation_params=[
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.RETRIEVAL_CONTEXT
    ],
)

# Prilagođena metrika za kvalitetu odgovora korisničke podrške
kvaliteta_podrske = GEval(
    name="Kvaliteta korisničke podrške",
    evaluation_steps=[
        "Provjeri je li odgovor ljubazan i profesionalan.",
        "Provjeri nudi li odgovor konkretan sljedeći korak korisniku.",
        "Provjeri je li odgovor potpun i pokriva li sve aspekte upita.",
        "Provjeri koristi li odgovor jasan i razumljiv jezik."
    ],
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT
    ],
)

Integrirano testiranje s Pytest

DeepEval se besprijekorno integrira s Pytestom, što omogućuje pokretanje LLM evaluacija kao dio standardnog testnog paketa. Ako već koristite Pytest (a tko ne koristi?), ovo će vam se svidjeti:

import pytest
from deepeval import assert_test
from deepeval.metrics import HallucinationMetric, AnswerRelevancyMetric
from deepeval.test_case import LLMTestCase
from deepeval.dataset import EvaluationDataset

# Definiranje testnih slučajeva
test_cases = [
    LLMTestCase(
        input="Što je RAG?",
        actual_output="RAG je tehnika koja kombinira dohvat dokumenata s generiranjem.",
        context=["RAG (Retrieval-Augmented Generation) je tehnika..."]
    ),
    LLMTestCase(
        input="Kako radi vektorska pretraga?",
        actual_output="Vektorska pretraga koristi embedding vektore za pronalaženje sličnih dokumenata.",
        context=["Vektorska pretraga pretvara tekst u numeričke vektore..."]
    ),
]

dataset = EvaluationDataset(test_cases=test_cases)

@pytest.mark.parametrize("test_case", dataset)
def test_ai_chatbot(test_case: LLMTestCase):
    halucinacija = HallucinationMetric(threshold=0.7)
    relevantnost = AnswerRelevancyMetric(threshold=0.7)
    assert_test(test_case, [halucinacija, relevantnost])

S ovom postavkom, možete pokrenuti evaluacije jednostavnom naredbom pytest test_llm.py ili integriranijom deepeval test run test_llm.py — koja pruža dodatne analitičke mogućnosti.

Anthropicov pristup evaluaciji AI agenata

U siječnju 2026. Anthropic je objavio utjecajan članak „Demystifying Evals for AI Agents" koji je brzo postao referentni vodič za evaluaciju agenata u industriji. Ključne lekcije iz tog članka vrijedi detaljno razmotriti jer pružaju praktičan okvir primjenjiv za svaki tim koji gradi AI agente.

Eval-driven development

Anthropic preporučuje pristup koji nazivaju eval-driven development (razvoj vođen evaluacijama): definirajte evaluacije za planirane sposobnosti prije nego što ih agent može ispuniti, a zatim iterativno poboljšavajte agenta dok ne postigne zadovoljavajuće rezultate. Ako vam ovo zvuči poznato — da, to je u biti TDD (test-driven development) primijenjen na AI sustave.

Počnite maleno, s stvarnim greškama

Ne trebate stotine testnih slučajeva da biste počeli. Anthropic preporučuje 20 do 50 jednostavnih zadataka izvedenih iz stvarnih neuspjeha. Rane promjene imaju velike efekte, pa su mali uzorci sasvim dovoljni za početak. Kako sustav sazrijeva, postupno proširujte skup evaluacija.

Ovo je savjet koji bih posebno naglasio — previše timova se paralizira pokušavajući odmah napraviti "savršen" evaluacijski sustav.

Ocjenjujte ishode, ne samo putanje

Agenti mogu doći do ispravnog rješenja na neočekivane načine. Umjesto da strogo ocjenjujete svaki korak, fokusirajte se na konačni ishod. Kombinacija determinističkih testova (kod-bazirani, brzi i jeftini) i LLM-baziranih rubrika (za subjektivne kriterije poput tona ili kreativnosti) daje najbolje rezultate.

Slojeviti pristup ocjenjivanju

Anthropicova preporuka je jasna hijerarhija:

1. Deterministički (kod-bazirani) ocjenjivači — koristite ih svugdje gdje je moguće. Brzi su, jeftini i potpuno ponovljivi.
2. LLM-bazirani ocjenjivači — koristite ih kada deterministički pristup nije dovoljan, primjerice za procjenu kvalitete teksta ili relevantnosti odgovora.
3. Ljudski ocjenjivači — koristite ih primarno za kalibraciju LLM ocjenjivača ili za evaluaciju subjektivnih izlaza gdje je ljudski konsenzus referentni standard.

Agenti su stohastički

Isti agent s istim ulazom može proizvesti različite rezultate u različitim pokretanjima. Anthropic naglašava da za svaki zadatak trebate pokrenuti više pokusa (trials) i pratiti varijance, ne samo prolaz/pad. Ova stohastička priroda čini evaluaciju agenata fundamentalno drugačijom od testiranja tradicionalnog softvera — i to je nešto na što se mnogi timovi moraju navikavati.

Vrijednost evaluacija se kumulira

Timovi koji rano ulože u evaluacije otkrivaju da se razvoj ubrzava: neuspjesi postaju testni slučajevi, testni slučajevi sprječavaju regresije, a metrike zamjenjuju nagađanje. Timovi s dobrim evaluacijama mogu nadograditi modele u danima, dok se oni bez evaluacija suočavaju s tjednima ručnog testiranja.

Praktična primjena Anthropicovog pristupa

Kako biste primijenili ove preporuke u vlastitom projektu, evo konkretnog plana u pet koraka:

1. Prikupite 20-50 stvarnih neuspjeha — pregledajte logove korisničke podrške, pritužbe korisnika ili ručno testirajte scenarije za koje znate da su problematični. Ti primjeri postaju vaš prvi evaluacijski skup podataka.
2. Napišite determinističke testove za očigledne slučajeve — ako vaš agent treba uvijek koristiti specifičan alat za određenu vrstu upita, to je deterministički test. Brz i jeftin za pokretanje.
3. Dodajte LLM-bazirane evaluatore za subjektivne kriterije — kvaliteta teksta, prikladnost tona i sveobuhvatnost odgovora zahtijevaju sofisticiraniji pristup.
4. Pokrenite više pokusa po zadatku — umjesto jednog pokretanja, izvršite svaki test 3-5 puta i pratite varijance. Ovo daje pouzdaniju sliku stvarne kvalitete agenta.
5. Automatizirajte u CI/CD — integrirajte evaluacije u razvojni cjevovod tako da se pokreću na svakom pull requestu koji mijenja promptove, konfiguraciju agenata ili logiku dohvata.

Integracija evaluacija u CI/CD cjevovod

Evaluacije imaju najveću vrijednost kada su automatizirane i integrirane u razvojni proces. Evo kako to konkretno izgleda.

GitHub Actions primjer

Sljedeći GitHub Actions workflow automatski pokreće LLM evaluacije na svakom pull requestu:

name: LLM Evaluacije
on:
  pull_request:
    paths:
      - 'src/prompts/**'
      - 'src/agents/**'
      - 'src/rag/**'

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Postavljanje Python okruženja
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Instalacija zavisnosti
        run: pip install deepeval openai langfuse

      - name: Pokretanje LLM evaluacija
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          LANGFUSE_PUBLIC_KEY: ${{ secrets.LANGFUSE_PUBLIC_KEY }}
          LANGFUSE_SECRET_KEY: ${{ secrets.LANGFUSE_SECRET_KEY }}
        run: deepeval test run tests/eval/ --verbose

      - name: Provjera praga kvalitete
        if: failure()
        run: |
          echo "LLM evaluacije nisu zadovoljile minimalne pragove kvalitete."
          echo "Pregledajte rezultate evaluacija prije spajanja."
          exit 1

Offline i online evaluacijska petlja

Najučinkovitiji pristup kombinira offline i online evaluacije u kontinuirani ciklus poboljšanja. Evo kako to izgleda u praksi:

1. Evaluirajte offline — pokrenite testove na fiksnom skupu podataka prije implementacije
2. Implementirajte u produkciju — s povjerenjem da su osnovni pragovi kvalitete zadovoljeni
3. Pratite online — kontinuirano evaluirajte na stvarnim korisničkim podacima
4. Prikupite nove slučajeve neuspjeha — iz produkcijskog praćenja
5. Dodajte u offline skup podataka — obogatite testni skup stvarnim problemima
6. Poboljšajte agenta — iterirajte na temelju novih saznanja
7. Ponovite — ciklus se nastavlja

Ovaj ciklus osigurava da se vaš evaluacijski skup podataka stalno poboljšava s primjerima iz stvarnog svijeta, dok istodobno automatizirani testovi sprječavaju regresije.

Atribucija troškova

Osim kvalitete, CI/CD integracija omogućuje praćenje atribucije troškova — raščlanjivanje rashoda po korisniku, značajki, modelu ili eksperimentu. Ovo čini jasnim gdje će optimizacijski napori imati najveći utjecaj. Primjerice, možete otkriti da jedan specifičan agent u vašem višeagentnom sustavu troši 60% ukupnog budžeta za tokene — i odjednom znate što treba optimizirati prvo.

Najbolje prakse za produkcijsku opservabilnost AI sustava

Na temelju svega što smo pokrili, evo sažetog pregleda najboljih praksi. Držite se ovih smjernica i nećete pogriješiti.

1. Koristite OpenTelemetry kao temelj

OpenTelemetry je postao de facto standard za opservabilnost, i to se proširilo na AI sustave. Alati poput Langfuse, Arize Phoenix i OpenLLMetry izgrađeni su na njemu, što znači da se vaši podaci o praćenju mogu slati na više odredišta istodobno — primjerice Langfuse za LLM opservabilnost i Datadog za infrastrukturu. Izbjegavajte zaključavanje u vlasničke SDK-ove kada god je to moguće.

2. Pratite ono što je važno

Nemojte pratiti sve — fokusirajte se na metrike koje su zaista relevantne za vaš sustav:

• Zdravlje sustava: dostupnost, latencija (P50, P95, P99), stope pogrešaka
• Ponašanje agenta: točnost odabira alata, točnost parametara alata, koherentnost višekoračnih poziva
• Kvaliteta izlaza: relevantnost, vjernost, stopa halucinacija
• Troškovi: potrošnja tokena po zahtjevu, dnevni i mjesečni rashodi po modelu

3. Implementirajte upozorenja temeljena na kvaliteti

Tradicionalni sustavi upozorenja reagiraju na latenciju i pogreške. Za AI sustave trebate nešto više — upozorenja temeljena na kvaliteti koja se aktiviraju kada padne ocjena vjernosti, relevantnosti, sigurnosti ili kada se detektira porast halucinacija. Ovo je fundamentalna razlika u pristupu opservabilnosti AI sustava u usporedbi s klasičnim softverom.

4. Uspostavite revizijski trag

S regulativnim okvirima poput EU AI Acta, revizijski trag postaje zakonska obveza za mnoge primjene AI sustava. Praćenje bi trebalo bilježiti potpunu povijest svakog zahtjeva — ulaz, lanac razmišljanja, pozive alata, dohvaćene dokumente i konačni izlaz. Langfuse i slični alati ovo omogućuju iz kutije, pa nema razloga to ne implementirati od samog početka.

5. Koristite model švicarskog sira za evaluaciju

Nijedan evaluacijski sloj ne hvata svaki problem. Kombinirajte više metoda — automatizirane evaluacije u CI/CD-u, monitoring u produkciji, A/B testiranje, povratne informacije korisnika i ručni pregled transkripata — kako bi problemi koji promaknu jednom sloju bili uhvaćeni drugim. To je model švicarskog sira primijenjen na sigurnost AI sustava, i u praksi se pokazuje iznimno učinkovitim.

6. Započnite jednostavno, razvijajte postupno

Nemojte pokušavati implementirati savršenu opservabilnost od prvog dana. Preporučeni redoslijed je:

1. Faza 1: Osnovno praćenje — latencija, troškovi, stope pogrešaka
2. Faza 2: Duboko praćenje — potpuni tragovi zahtjeva s kontekstom
3. Faza 3: Offline evaluacije — automatski testovi u CI/CD-u
4. Faza 4: Online evaluacije — kontinuirana procjena kvalitete u produkciji
5. Faza 5: Napredna analitika — A/B testiranje, korelacija kvalitete s troškovima, optimizacija

Zaključak

Izgradnja AI sustava je samo pola posla. Održavanje njihove kvalitete, pouzdanosti i učinkovitosti u produkciji jednako je važno — ako ne i važnije. U 2026. godini, ekosustav alata za opservabilnost i evaluaciju dosegao je razinu zrelosti koja omogućuje svakom timu, od startupa do enterprise organizacija, da uspostavi pouzdanu produkcijsku infrastrukturu.

Ključne poruke su jasne: monitoring vam govori radi li sustav, opservabilnost vam pomaže razumjeti zašto nešto ne radi, a evaluacija osigurava da je kvaliteta izlaza na razini koju vaši korisnici očekuju. Sva tri elementa su neophodna za potpunu sliku.

Alati poput Langfuse i Arize Phoenix demokratizirali su opservabilnost čineći je dostupnom kroz open-source rješenja temeljena na OpenTelemetry standardu. DeepEval je evaluaciju učinio jednako jednostavnom kao pisanje unit testova. A Anthropicov pristup eval-driven developmentu pruža praktičan okvir za kontinuirano poboljšanje.

Nemojte čekati produkcijske incidente da biste počeli ulagati u opservabilnost. Počnite s osnovnim praćenjem, dodajte nekoliko evaluacijskih testova za najkritičnije scenarije i postupno proširujte pokrivenost. Ulaganje u evaluacije ima kumulativni učinak — svaki neuspjeh postaje testni slučaj, svaki testni slučaj sprječava buduću regresiju, i s vremenom, metrike zamjenjuju nagađanje. U svijetu nedeterminističkih AI sustava, to je prednost koju si ne možete priuštiti ignorirati.