LLM-sovellusten havainnoitavuus: jäljitys, kustannukset, viive ja laadun ajautuminen

LLM-sovellukset rikkoutuvat eri tavoin kuin perinteiset ohjelmistot. Tavallinen ohjelmistovirhe tuottaa pinojäljen. LLM:n ”virhe” on laadun ajautuminen, jonka huomaat vasta käyttäjien valittaessa. Tavallinen viiveongelma on hidas päätepiste. LLM:n viiveongelma on 30 sekunnin päättelyjäljitys, jonka ajan käyttäjä tuijottaa latausilmaisinta.

Perinteinen havainnoitavuus, kuten Datadog, New Relic ja Sentry, kertoo API-kutsun onnistuneen 8.4 sekunnissa ja käyttäneen 12,847 syötetokenia. Se ei kerro, oliko vastaus hyvä, hallusinoiko malli, kutsuttiinko väärää työkalua tai onko laatu ajautunut viime viikosta.

Tuotannon LLM-järjestelmät tarvitsevat erilaisen havainnoitavuuspinon tai vähintään lisäkerroksia perinteisten päälle. Tämä artikkeli käsittelee erityispiirteitä, instrumentoitavia asioita ja toimivia malleja.

Miten LLM-havainnoitavuus eroaa

Perinteinen havainnoitavuus ei käsittele seuraavia LLM-järjestelmien ominaispiirteitä:

Epädeterministisyys yksikkötasolla. Sama syöte tuottaa eri kutsuilla erilaisia tuotoksia. Kysymykseen ”toimiko tämä oikein?” ei voi vastata tilakoodin perusteella.

Laatu ensisijaisena mittarina. Viiveellä ja kustannuksella on merkitystä, mutta laatu on tärkein ja vaikeimmin mitattava asia.

Monivaiheiset jäljitykset. Käyttäjän kysely voi käynnistää 5-50 LLM-kutsua, kuten agenttisilmukoita, RAG-hakuja, rakenteista poimintaa ja arviointia. Jokainen kutsu kuuluu suurempaan jäljitykseen.

Tokenitason kustannusvaihtelu. Yksittäisen kutsun kustannus voi olla €0.001 ja €1.00 välillä kehotteen koosta, tuotoksen pituudesta ja mallista riippuen. Kokonaiskustannukset pitää kohdistaa kutsukohtaisesti.

Ajautuminen ajan mittaan. Mallit päivittyvät, kehotteet kehittyvät ja syötteiden jakaumat muuttuvat. Laatu liikkuu, ja liike pitää nähdä.

Arkaluonteiset hyötykuormat. Syötteet ja tuotokset ovat usein arvokkainta diagnostiikkatietoa mutta myös arkaluonteisinta. Lokitus vaatii kuria.

Pitkät asynkroniset työnkulut. Minuutteja kestävät agenttiajot, taustalla ajettavat erätyöt ja suoratoistetut vastaukset eivät sovi perinteiseen pyyntö-vastaus-havainnoitavuuteen.

Nämä eivät ole teoreettisia huolia. Jokainen LLM-järjestelmiä tuotannossa käyttävä tiimi kohtaa ne.

Havainnoitavuuspino

Täydellisessä LLM-havainnoitavuuspinossa ovat seuraavat kerrokset:

1. Kutsutason instrumentointi. Jokaisesta LLM-kutsusta kirjataan syöte, tuotos, viive, kustannus, malli ja tila.

2. Jäljitystason instrumentointi. Usean kutsun työnkulut yhdistetään jäljityksiksi, jolloin käyttäjäpyynnön koko kutsuketju näkyy.

3. Sovellustason mittarit. Ominaisuus-, käyttäjä- ja asiakaskohtaiset yhdistelmät.

4. Laadunvalvonta. Otokseen perustuva tai kattava automaattinen laadunarviointi.

5. Käyttäjäpalautteen keruu. Suorat signaalit, kuten peukku ylös tai alas, sekä epäsuorat signaalit, kuten uudelleengenerointi ja keskeyttäminen.

6. Hälytykset. Reaaliaikaiset hälytykset kustannuspiikeistä, viiveen heikkenemisestä, laadun laskusta ja virheprosentin kasvusta.

7. Virheenselvitystyökalut. Kun jokin rikkoutuu, löydät jäljityksen, näet syötteet ja tuotokset sekä ymmärrät tapahtumat.

Käymme seuraavaksi läpi kaikki kerrokset.

Kutsutason instrumentointi

Jokaisen LLM-kutsun pitäisi tuottaa seuraavat tiedot sisältävä lokitietue:

{
  "call_id": "uuid",
  "timestamp": "2026-05-15T14:23:45Z",
  "trace_id": "uuid",  // for grouping into traces
  "span_id": "uuid",   // for parent-child relations
  "feature": "summarize_document",
  "prompt_version": "v3.2",
  "model": "claude-4-sonnet",
  "provider": "anthropic",
  "input_messages": [...],
  "output_message": "...",
  "input_tokens": 1842,
  "output_tokens": 384,
  "total_tokens": 2226,
  "cost_usd": 0.0084,
  "latency_ms": 2340,
  "first_token_ms": 1240,  // streaming
  "status": "success",
  "error": null,
  "user_id": "user_123",
  "tenant_id": "tenant_45",
  "metadata": {
    "session_id": "...",
    "experiment_arm": "v3_test"
  }
}

Tämä on vähimmäistaso. Tallenna kaikki.

Keskeiset toteutusvalinnat:

Lokituspaikka. Vaihtoehdot:

• Erillinen havainnoitavuustyökalu, kuten Helicone, LangSmith, Phoenix, Braintrust tai Arize.
• LLM-laajennuksilla varustettu yleinen havainnoitavuusalusta, kuten Datadog LLM Observability tai Sentry.
• Omat lokit tai tietokanta.

Useimmille tiimeille kannattaa valita erillinen työkalu. Niissä on LLM-kutsujen tarkasteluun suunnitellut käyttöliittymät, ja oppimiskynnys on oman ratkaisun rakentamiseen verrattuna pieni.

Suuremmille tiimeille sopii yhdistelmä. Käytä LLM-kohtaiseen käyttöliittymään erillistä työkalua mutta vie tiedot myös keskitetylle havainnoitavuusalustalle järjestelmien välistä korrelaatiota varten.

Instrumentointitapa. Vaihtoehdot:

• Sovelluksen ja LLM-palveluntarjoajan välissä toimiva välityspalvelin, kuten Heliconen malli.
• Sovelluskoodiin liitettävä SDK.
• Rajapintaluokka, jota kutsutaan käsin jokaisen LLM-kutsun yhteydessä.

Välityspalvelimet ovat helpoimpia mutta lisäävät viivettä. SDK:t ovat siistejä mutta edellyttävät integrointia. Manuaalinen rajapinta on joustavin mutta helpoin unohtaa.

Käytännöllinen ratkaisu on SDK-rajapinta kohdassa, jossa sovellus kutsuu LLM:ää. Instrumentointi tehdään yhdessä paikassa ja kaikki muu kulkee sen läpi.

Lokitettavat tiedot. Käytännön huomioita:

• Katkaise erittäin pitkät syötteet ja tuotokset mutta kirjaa katkaisu.
• Korvaa henkilötiedot tiivisteellä tai peitä ne, ja anna tarvittaessa mahdollisuus hakea alkuperäinen tieto turvallisella erillishaulla.
• Älä lokita tunnistetietoja edes virhepoluissa.
• Kirjaa suoratoistossa sekä viive ensimmäiseen tokeniin että kokonaisviive.

Jäljitystason instrumentointi

Yksi käyttäjän toiminto sisältää usein monta LLM-kutsua. Ilman jäljitystason instrumentointia käytössä on tuhat kutsulokia mutta ei keinoa tietää, mitkä kutsut kuuluivat samaan käyttäjän toimintoon.

Toteutus:

Jäljitystunnisteen luominen. Luo yksilöllinen jäljitystunniste käyttäjäpyynnön alussa ja välitä se kaikkiin myöhempiin kutsuihin.

Ylä- ja alisuhteiset spanit. Jokaisella jäljityksen kutsulla on span-tunniste ja valinnaisesti ylätason span-tunniste. Näin syntyy kutsuhierarkian näyttävä puu.

Toimintojen nimeäminen. Jokainen span nimetään, esimerkiksi ”summarize_document”, ”extract_entities” tai ”tool_call:search”. Jäljitys näyttää koko toimintoketjun.

Käyttöliittymän jäljitysnäkymä:

Trace abc-123 (12.3s total)
├─ classify_intent (450ms) [gpt-5-mini]
├─ retrieve_documents (1.2s) [embedding + search]
├─ generate_response (8.5s) [claude-4-sonnet]
│   ├─ tool_call: search_internal (320ms)
│   ├─ tool_call: lookup_customer (180ms)
│   └─ generate_final_text (7.5s)
└─ judge_response_quality (2.1s) [claude-4-haiku]

Nyt näet, mitä järjestelmä todella teki käyttäjän pyynnölle. Näet hitaat, kalliit ja epäonnistuneet kutsut omassa kontekstissaan.

Tätä tukevat hyvin LangSmith, Phoenix (Arize) ja mukautetulla integraatiolla Helicone. Järjestelmien väliseen jäljitykseen voi käyttää lisäksi yleisiä havainnoitavuusratkaisuja, kuten Datadogia ja OpenTelemetryä.

Sovellustason mittarit

Yhdistä yksittäisten kutsujen lisäksi mittareita:

Ominaisuuskohtaisesti.

• Kutsumäärä.
• Keskimääräinen viive.
• p50-, p95- ja p99-viive.
• Keskimääräinen kustannus pyyntöä kohti.
• Virheprosentti.
• Laatutulos, jos sitä mitataan.

Käyttäjä- tai asiakaskohtaisesti.

• Kutsut käyttäjää kohti päivässä.
• Käyttäjäkohtainen kustannus.
• Paljon käyttävät käyttäjät ja väärinkäytön mallit.

Mallikohtaisesti.

• Mallikohtainen määrä.
• Mallin osuus kustannuksista.
• Mallikohtainen virheprosentti.
• Mallikohtainen laatu, jos sitä mitataan.

Ominaisuus × malli.

• Mitkä ominaisuudet käyttävät mitäkin mallia?
• Missä voisi käyttää edullisempaa mallia?

Nämä koontinäytöt ohjaavat operatiivisia päätöksiä: mitkä ominaisuudet ovat kalliita, mitkä hitaita ja mitkä vaativat optimointia.

Laadunvalvonta

Vaikein kerros on automaattinen laadunarviointi.

Erikseen käsitellyt arvioinnit ajetaan määritetyllä aineistolla. Online-laadunvalvonnassa arvioidaan tuotantoliikennettä.

Lähestymistapoja:

LLM-as-judge otokselle. Ota esimerkiksi 1% tuotantoliikenteestä. Aja jokaiselle arvioija-LLM, joka pisteyttää vastauksen olennaisilla ulottuvuuksilla. Seuraa tuloksia ajan mittaan ja hälytä pudotuksista.

Epäsuorat signaalit. Seuraa uudelleengenerointeja, keskeytyksiä, virheprosentteja, valmistumisaikaa ja jatkoviestien yleisyyttä. Signaalit ovat heikkoja mutta edullisia. Käytä niitä ennakoivina indikaattoreina.

Suora käyttäjäpalaute. Peukku ylös tai alas, ”auttoiko tämä?” -painikkeet ja erilliset ilmoitukset. Vahvin signaali mutta pienin määrä.

Mallien havaitseminen. Tietyt huonot mallit, kuten ”I cannot help with that”, ”I’m just an AI” ja toistuvat kieltäytymiset, merkitään automaattisesti. Näin jotkin regressiot havaitaan välittömästi.

Tyypillinen toteutus:

• Ota 1% tuotantokutsuista.
• Aja jokaiselle moniulotteisesti pisteyttävä LLM-arvioija.
• Yhdistä tulokset ominaisuuskohtaisiksi päivätuloksiksi.
• Hälytä, jos jokin ominaisuus laskee >10% viikosta toiseen.

Kustannus on todellinen mutta rajattu: 1% liikenteestä × pieni arvioijamalli on useimmille tiimeille hallittavissa.

Kustannusten havainnoitavuus

LLM-kustannukset voivat karata. Yksittäinen virhe, kuten hallitsematon uudelleenyrityssilmukka tai odotettua 10x enemmän tokeneita käyttävä ominaisuus, voi kasvattaa laskun 10x ennen kuin kukaan huomaa.

Kustannusten havainnoitavuuskerrokset:

Kutsukohtainen kustannus. Jokaisen kutsun kustannus lasketaan lokitushetkellä. Yhdistelmät ovat heti käytettävissä.

Budjettihälytykset. Päivä-, viikko- ja kuukausibudjetit ominaisuus- ja asiakaskohtaisesti. Hälytä rajojen ylittyessä (50%, 75%, 90%, 100%).

Poikkeamien havaitseminen. Onko päivän kustannus 5x tyypillinen tai yhden kutsun kustannus 100x tyypillinen? Hälytä.

Kustannusten kohdistaminen. Ominaisuus-, asiakas- ja käyttäjäkohtaiset kustannukset paljastavat eniten kuluttavat kohteet.

Ennuste. Mikä kuukauden lopun lasku on nykyisen kehityksen perusteella?

Hyödyllinen koontinäyttö esittää yhdessä paneelissa tämän päivän kustannuksen verrattuna kuluvan viikon loppuosaan ja viime viikkoon ominaisuuksittain eriteltynä.

Käytännön vinkki: aseta mahdollisuuksien mukaan ehdottomat rajat. Jos ominaisuuden pitäisi maksaa €X/day, automaattinen sulku aktivoituu arvossa 10X. Kustannukset karkaavat nopeasti, ja raja pysäyttää ne.

Viiveen havainnoitavuus

LLM-viive on tavallisia rajapintoja moniulotteisempi:

Kokonaisviive. Pyynnöstä lopulliseen vastaukseen.

Aika ensimmäiseen tokeniin (TTFT). Milloin käyttäjä näkee ensimmäisen merkin suoratoistossa? Tämä hallitsee chat-käyttöliittymän koettua viivettä.

Aika viimeiseen tokeniin (TTLT). Kuinka kauan vastauksen valmistuminen kestää?

Tokenia sekunnissa. Tuotosnopeus. Jotkin mallit suoratoistavat muita hitaammin.

Työkalukutsujen viive. Agenttityönkuluissa työkalukutsuihin ja LLM-kutsuihin käytetty aika.

Seuraa kaikkia näitä. Eri optimointistrategiat kohdistuvat eri mittareihin.

Käyttäjälle näkyvässä keskustelussa TTFT on tärkein. Hidas ensimmäinen token tuntuu rikkoutuneelta, mutta pieni tokeninopeus tuntuu asteittaiselta.

Eräkäsittelyssä kokonaisviiveellä on merkitystä mutta läpimenolla vielä enemmän.

Agenteissa työkalukutsujen viive hallitsee usein kokonaisuutta. LLM:n optimointi ei auta, jos työkalut ovat hitaita.

Virheiden havainnoitavuus

LLM-kohtaisia virheitä:

API-virheet. Nopeusrajoitukset, tunnistautumisvirheet ja palvelinvirheet, kuten missä tahansa rajapinnassa.

Validointivirheet. Rakenteinen tuotos ei vastannut skeemaa. Seuraa määrää ominaisuuksittain.

Sisältösuodatinvirheet. Palveluntarjoaja esti pyynnön. Seuraa niitä kehoteongelmien havaitsemiseksi.

Työkaluvirheet. Tietyt työkalut epäonnistuvat. Seuraa työkalukohtaisesti.

Laatuvirheet. LLM-arvioija pisteytti tuotoksen huonoksi. Seuraa ajan mittaan.

Hallusinaatiosignaalit. Todennäköisen hallusinaation havaitseminen, kun malli väitti jotakin, jota lähteessä ei ole. Tätä on vaikea havaita automaattisesti mutta sitä voi arvioida likimääräisesti.

Kustannusvirheet. Odotettua huomattavasti kalliimmat kutsut. Ne kertovat usein ohjelmistovirheestä.

Jokainen virheluokka saa oman koontinäyttönsä ja voi käynnistää hälytyksiä.

Virheenselvitystyökalut

Kun jokin rikkoutuu, se pitää löytää ja ymmärtää. Virheenselvityspinta sisältää:

Jäljityshaku. Etsi tietyn käyttäjän pyyntö jäljitystunnisteella, käyttäjätunnisteella tai aikaleimalla.

Kutsun tarkastus. Näe kutsun koko pyyntö, vastaus, parametrit, viive ja kustannus.

Jäljityksen aikajana. Näe monimutkaisten työnkulkujen kutsuketju visuaalisesti.

Uudelleenajomahdollisuus. Voiko vanhan kutsun ajaa uudelleen eri kehotteella tai mallilla ja nähdä vaihtoehtoisen tuloksen? Tämä on välttämätöntä korjausten testaamisessa.

Eronäkymä. Vertaa rinnakkain kahta kutsua, esimerkiksi saman kehotteen eri versioita tai eri malleja.

Sisältöhaku. Etsi aiempien kutsujen joukosta tiettyjä malleja, kuten kutsut, joissa malli sanoi ”I cannot help”.

Erilliset LLM-havainnoitavuustyökalut tarjoavat nämä kyvykkyydet. Niiden rakentaminen itse vaatii paljon työtä, joten työkalun käyttäminen on yleensä edullisempaa.

Tietosuoja ja henkilötiedot

LLM-havainnoitavuuden lokit ovat arkaluonteisia. Syötteet voivat sisältää henkilötietoja, ja tuotokset voivat lainata niitä. Joskus lokitusta ei voi välttää, koska tietoja tarvitaan virheenselvitykseen.

Käytännöt:

Tokenisointi ja hajautus. Korvaa tunnisteet tokeneilla. Alkuperäinen tieto voidaan hakea erillisellä turvallisella haulla. Suurin osa lokeista ei sisällä henkilötietoja.

Peittäminen lokitushetkellä. Havaitse ja peitä henkilötiedot ennen niiden päätymistä havainnoitavuustallennukseen. Korvaa tietyt mallit, kuten sähköpostiosoitteet, puhelinnumerot ja SSN-tunnisteet, paikkamerkeillä.

Asiakaseristys. Eristä usean asiakkaan havainnoitavuustiedot asiakaskohtaisesti. Yhden asiakkaan tiedot eivät näy toiselle.

Käyttöoikeuksien hallinta. Määritä, kuka voi nähdä raakoja syötteitä ja tuotoksia, ja lokita käyttö.

Säilytyskäytännöt. Poista X päivää vanhemmat lokit tai siirrä ne kylmäsäilytykseen. Henkilötietojen säilytyksellä on monilla lainkäyttöalueilla oikeudellisia rajoja.

Oikeus tulla unohdetuksi. Kun käyttäjä pyytää GDPR:n nojalla poistamista, hänen lokinsa pitää pystyä löytämään ja poistamaan.

Nämä eivät ole valinnaisia henkilötietoja käsittelevässä järjestelmässä. Tee ne oikein varhain, sillä jälkikäteinen lisääminen on vaikeaa.

Hälytykset

Hälytyksen edellyttäviä rajoja ja signaaleja:

Kustannus.

• Päiväkustannus > 2x tyypillinen.
• Yksittäisen kutsun kustannus > €5.
• Tuntikustannuksen piikki > 5x.

Viive.

• p95-viive > 2x perustaso.
• TTFT > 5s keskustelukäyttöliittymässä.
• Työkalukutsujen aikakatkaisut lisääntyvät.

Virheprosentti.

• Virheprosentti > 1% (tyypillinen perustaso on 0.1-0.5%).
• Tietyn virhetyypin, kuten validointivirheiden tai nopeusrajoitusten, piikki.

Laatu.

• Jonkin ominaisuuden laatutulos laski > 10% viikosta toiseen.
• Käyttäjäpalautteen negatiivinen osuus > perustaso.
• Uudelleengenerointien osuus > perustaso.

Malli.

• Tietyt huonot ilmaukset esiintyvät aiempaa useammin.
• Syötejakauma muuttuu äkillisesti.

Jokaisen hälytyksen pitäisi olla täsmällinen ja toimintakelpoinen. ”Kustannus on suuri” ei auta. ”Ominaisuus X käytti viimeisten 30 minuutin aikana 10x budjettinsa — todennäköinen hallitsematon silmukka asiakkaan Y istunnossa” auttaa.

Usean asiakkaan ympäristön huomioita

B2B SaaS -sovelluksissa:

Asiakaskohtaiset mittarit. Jokainen asiakas näkee oman käyttönsä, kustannuksensa ja laatunsa.

Asiakaskohtaiset hälytykset. Niiden rajat ovat asiakaskohtaisia.

Asiakaskohtainen virheenselvitys. Tukihenkilöstö näkee asiakkaan jäljitykset asianmukaisin käyttöoikeuksin.

Asiakaskohtainen kokoonpano. Joillakin asiakkailla voi olla eri mallit, kehotteet tai käytännöt. Havainnoitavuuskerros heijastaa tätä.

Tämä lisää monimutkaisuutta mutta on välttämätöntä mittakaavan B2B-toiminnassa. Asiakastuki ei voi selvittää väitettä ”tekoäly ei toimi minulla” ilman asiakaskohtaisia jäljityksiä.

Työkalujen ekosysteemi (2026)

Kirjoitushetken yleiskuva LLM-havainnoitavuustyökaluista:

Erillinen LLM-havainnoitavuus:

• Helicone. Välityspalvelinpohjainen, helppo integroida ja vahvat koontinäytöt.
• LangSmith. Sidoksissa LangChain-ekosysteemiin ja tarjoaa syvän jäljityksen.
• Phoenix (Arize). Ystävällinen avoimelle lähdekoodille ja vahva laadunvalvonnassa.
• Braintrust. Vahva arviointien ja havainnoitavuuden yhdistelmä.
• PromptLayer. Kehotepainotteinen ja vahva versioseurannassa.
• Weights & Biases Weave. Sopii koneoppimistiimeille ja integroituu W&B:n laajempaan kokonaisuuteen.

Yleinen APM LLM-laajennuksilla:

• Datadog LLM Observability. Yritystasoinen ja kallis.
• New Relic LLM Observability. Vastaava ratkaisu.
• OpenTelemetry ja valitsemasi APM. OTel tarjoaa GenAI:n semanttiset käytännöt: instrumentoi kerran ja tarkastele monissa työkaluissa.

Oma toteutus:

• Yksi Postgres-taulun rivi kutsua kohden vie useimmat tiimit pitkälle.
• Lisää yksinkertainen käyttöliittymä hakemiseen ja näyttämiseen.
• Integroi olemassa olevaan lokitusinfrastruktuuriin.

Oikea valinta riippuu tiimin koosta, mittakaavasta, budjetista ja nykyisistä työkaluista. Useimmat tiimit aloittavat erillisestä työkalusta ja siirtyvät kattavampaan ratkaisuun mittakaavan kasvaessa.

Käytännöllinen käyttöönotto

Tyypilliselle keskikokoiselle, tyhjästä aloittavalle tiimille:

Viikko 1: valitse työkalu; Helicone on tavallinen helppo aloitus. Integroi se pääasialliseen LLM-kutsupolkuun ja varmista kutsujen lokittuminen.

Viikko 2: rakenna peruskoontinäytöt ominaisuuskohtaiselle kustannukselle, viiveelle ja virheprosentille.

Viikko 3: määritä hälytykset kustannuspiikeille ja virheprosentin kasvulle.

Viikko 4: lisää jäljitystason instrumentointi ja yhdistä spanit usean kutsun työnkulkujen läpi.

Kuukausi 2: toteuta laadun otanta. Valitse muutama ominaisuus ja ota LLM-as-judge-pisteytys käyttöön 1% liikenteestä.

Kuukausi 3: lisää käyttäjäpalautteen keruu, kuten peukku ylös tai alas.

Kuukausi 4: lisää usean asiakkaan tuki, hienojakoiset hälytykset ja virheenselvitystyökalut.

Tämä muodostaa toimivan havainnoitavuuspinon. Jokainen kerros lisää kyvykkyyttä ja kannattaa rakentaa. Jonkin kerroksen ohittaminen jättää katvealueen.

Mitä ilman havainnoitavuutta tapahtuu

Lyhyt luettelo puutteellisen LLM-havainnoitavuuden tiimeissä toistuvista poikkeamista:

• Virhe sai ominaisuuden yrittämään kutsuja uudelleen tiiviissä silmukassa. Viisinumeroiset odottamattomat kulut kertyivät viikonlopun aikana ja havaittiin vasta kuukausilaskusta. Tämän tarinan muunnelmia toistuu niin usein, että täsmällisiä lukuja tärkeämpi on toimintamalli.

• Mallipäivitys muutti toimintaa huomaamatta. Tärkeän ominaisuuden laatu laski. Käyttäjät valittivat, mutta insinöörit pitivät tilannetta ”satunnaisena outoutena”. Yhteys mallimuutokseen löytyi vasta kaksi kuukautta myöhemmin.

• Uusi kehoteversio julkaistiin ja heikensi vahingossa tärkeää käyttäjäpolkua. Ilman polkukohtaisia mittareita kukaan ei huomannut asiaa viikkoihin.

• Agenttijärjestelmä alkoi jäädä silmukkaan. Joissakin käyttäjäistunnoissa oli 200+ LLM-kutsua. Silmukan löytäminen vei tunteja, koska jäljitystason instrumentointia ei ollut.

• Työkalun tunnistautumisvirhe johti agentin sekaannukseen. Agentti jatkoi ”asioiden kokeilemista” ja kasvatti kustannuksia. Ilman hälytyksiä tämä jatkui tunteja.

• Kehoteinjektio sai tekoälyn vuotamaan järjestelmäohjeita. Henkilötietoja paljastui. Ilman havainnoitavuutta tiimin oli vaikea tunnistaa vaikutuksen kohteeksi joutuneita käyttäjiä.

Nämä eivät ole teoreettisia tapahtumia, vaan niitä tapahtuu. Havainnoitavuus ehkäisee useimmat tai havaitsee ne nopeasti.

Instrumentoi ennen poikkeamaa

LLM-havainnoitavuus on oma tieteenalansa. Perinteinen APM on välttämätön mutta riittämätön. Kaikkia erityisiä kerroksia tarvitaan: kutsutaso, jäljitystaso, laatu, kustannus, viive, virheet ja virheenselvitys.

Työkaluja on olemassa. Valitse yksi, integroi se varhain ja panosta koontinäyttöihin, hälytyksiin sekä prosesseihin, jotka havaitsevat ongelmat ennen käyttäjiä.

Näin toimivat tiimit:

• Havaitsevat virheet tunneissa viikkojen sijaan.
• Hallitsevat kustannuksia ennustettavasti yllätyslaskujen sijaan.
• Ylläpitävät laatua ajan mittaan ajautumisen sijaan.
• Selvittävät virheitä järjestelmällisesti arvailemisen sijaan.

Muut tiimit kohtaavat lopulta poikkeaman, joka pakottaa ne tekemään tämän. On parempi instrumentoida ennen poikkeamaa kuin sen jälkeen.