LLM-lokituksen parhaat käytännöt: 9 sääntöä tuotannossa [2026]

LLM-lokituksen parhaat käytännöt: 9 sääntöä tuotannossa [2026]

Nämä yhdeksän LLM-lokituksen parasta käytäntöä ovat säännöt, joilla tuotantopinomme todella pyörii: lokitamme 1,2 miljoonaa LLM-pyyntöä kuukaudessa neljän palvelun yli, ja jokainen niistä päätyy Grafana Lokiin yhtenä JSON-rivinä, jossa ovat model, tokens, latency, cost_usd ja trace_id. structlog 25.4.0 kirjoittaa tietueen, Presidio poistaa PII-tiedot ensin, ja koko putki on lokituspuolisko observointipinostamme.

Keskeiset opit

• Lokita jokainen LLM-pyyntö jäsenneltynä JSONina, jossa on vähintään 14 nimettyä kenttää, ei koskaan vapaana tekstinä.
• Maskaa PII ennen lokikirjoitusta Presidiolla tai vastaavalla, ei jälkikäteen.
• Liitä OpenTelemetry GenAI -semantiikkasopimuksen attribuutit jokaiseen jälkeen.
• Miljoonalla pyynnöllä päivässä samat 60 GB maksavat Datadogissa 108 $/kk, Lokissa 30 $ ja ClickHousessa 1,20 $.

Mitä LLM-lokitus oikeastaan tarkoittaa (ja miksi "lokita kaikki" epäonnistuu)

LLM-lokitus tarkoittaa jäsennellyn tietueen tallentamista jokaisesta mallipyynnöstä ja -vastauksesta: prompt, mallin vastaus, tokenmäärät, viive, kustannus ja jälki, joka sitoo kaiken käyttäjäistuntoon. Se ei ole infrastruktuurilokitusta. CPU, muisti ja podien uudelleenkäynnistykset kuuluvat metriikkapinoon. Tämä artikkeli käsittelee vain pyyntötason tietuetta, jolla mallin toimintaa voi debugata, hinnoitella ja auditoida.

"Lokita kaikki" -vaisto on sitkeä, ja se on kallis. Kokonaiset promptit ja vastaukset miljoonalla pyynnöllä päivässä tuottavat suunnilleen 60 GB tekstiä kuukaudessa, ja osa tuosta tekstistä on asiakkaiden PII-tietoja, joita nyt säilytetään ikuisesti. GDPR:n artiklan 5 tietojen minimointiperiaate edellyttää, että henkilötiedot ovat "riittäviä, olennaisia ja rajoitettuja siihen, mikä on tarpeen", ja raaka prompt-dumppi epäonnistuu tuossa testissä ensimmäisenä päivänä. Kaiken lokittaminen ei ole strategia. Se on vastuu, josta tulee kuukausilasku.

Mitkä ovat LLM-lokituksen 9 sääntöä?

Yhdeksän sääntöä siinä järjestyksessä, jossa itse toteuttaisimme ne: lokita kokonaiset promptit ja vastaukset hashatuilla tunnisteilla, lähetä jäsenneltyä JSONia, tallenna tokenit ja kustannus pyyntöä kohti, liitä OpenTelemetry-jälkikonteksti, maskaa PII ennen kirjoitusta, ota otoksia suurilla volyymeilla, aseta säilytysportaat, erota turvallisuustapahtumat ja tee tuloksesta kyseltävä. Jokaisen säännön alla on sen toteuttava koodi tai taulukko.

Sääntö 1: Lokita koko prompt ja vastaus (hashattuna, ei raakana PII:nä)

Lokita jokaisen pyynnön koko prompt ja koko vastaus, koska osittaisilla lokeilla päädyt tuijottamaan häiriötä ilman tietoa siitä, mitä malli todella näki. Yksi poikkeus on identiteetti: älä koskaan kirjoita raakoja käyttäjätunnuksia, sähköposteja tai nimiä tietueeseen. Tallenna sen sijaan käyttäjätunnuksen SHA-256-hash. Hashin avulla yhden käyttäjän koko istuntohistoria voidaan vielä rekonstruoida offline-haulla, mutta itse lokirivi on hyödytön kenelle tahansa, jonka ei pitäisi sitä lukea. Sama logiikka järjestelmäprompteille: hashaa ne, lokita hash ja säilytä selväkielinen teksti promptirekisterissä, jossa se on jo versiohallinnassa.

Sääntö 2: Käytä jäsenneltyä JSONia: jokainen kenttä nimettynä, ei vapaata tekstiä

LLM-lokituksen parhaissa käytännöissä Pythonilla tai millä tahansa muulla kielellä jäsennelty lokitus JSON-muodossa on se, josta ei tingitä: jokainen kenttä on nimetty, tyypitetty ja kyseltävä, mitään ei kaadeta muotoiltuna merkkijonona. Vapaan tekstin rivi kuten INFO called gpt-4o, took 812ms voidaan vain grepata. JSON-tietue voidaan aggregoida malleittain, summata kustannuksittain ja liittää jälkeen. OpenAI:n omat tuotannon parhaat käytännöt ajavat samaa ajatusta: tallenna jäsennelty metadata SDK-kerroksessa print-lauseiden sijaan.

Tässä on skeema, jonka jokainen Techsyn palvelu lähettää, neljätoista kenttää:

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

Kolme kenttää ansaitsee huomautuksen. cost_usd lasketaan pyyntöhetkellä tokenmääristä ja mallin julkaistusta hinnasta, ei koskaan jälkikäteen yöajolla. Kaksi hash-kenttää ovat säännön 1 kompromissi: korreloitavissa offlinessa, läpinäkymättömiä lokissa. Ja trace_id sekä span_id ovat W3C trace-context -arvoja, mistä sääntö 4 kertoo.

Jos neljän palvelun suorat tarjoajakutsut kuulostavat neljältä instrumentointikohteelta, LiteLLM-välityspalvelin keskittää sen: yksi lokituskoukku jokaisen tarjoajan edessä.

Sääntö 3: Tallenna tokenmäärät ja kustannus pyyntöä kohti

Tokenkäytön seuranta kuuluu itse lokiriviin, ei huomenna ajettavaan varastotyöhön. Jokainen tarjoaja palauttaa vastauksessa syötteen ja tulosteen tokenmäärät. Kerro ne mallin senhetkisellä tokenhinnalla ja kirjoita cost_usd tietueeseen. Hinnat muuttuvat ja eroavat välimuistissa olevien ja tuoreiden syötetokenien välillä, joten kustannuksen laskeminen myöhemmin staattisella hintataulukolla kirjoittaa historiaa hiljaa uudelleen. Kun kustannus on jokaisella rivillä, "mikä ominaisuus on kallis?" muuttuu yhden rivin kyselyksi rahoitusprojektin sijaan, ja se syöttää suoraan työtä, jolla LLM-API-kuluja pienennetään.

Sääntö 4: Liitä jälkikonteksti (OpenTelemetry GenAI Semconv)

Lokirivi ilman jälki-ID:tä on orpo: voit lukea sen, mutta et voi kertoa, mikä uudelleenyritys, mikä RAG-vaihe tai mikä käyttäjän vuoro sen tuotti. Korjaus on OpenTelemetryn GenAI-semantiikkasopimukset, standardinimet mallikutsujen instrumentointiin. Lähetä loki aktiivisen spanin sisällä, niin trace_id ja span_id liittyvät itsestään, ja yksi klikkaus Grafanassa vie jälkivesiputouksesta suoraan raakatietueeseen.

Attribuutit, jotka jokaiseen gen_ai-spaniin kannattaa asettaa:

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

Sääntö 5: Maskaa PII ennen lokikirjoitusta

PII-maskaus täytyy tehdä ennen tietueen kirjoittamista, ei puhdistaa jälkikäteen. Kun sähköpostiosoite on Lokissa, se on myös objektitallenteen varmuuskopioissa, ja "poistimme sen myöhemmin" ei ole GDPR-vastaus. Meidän setupissamme Microsoft Presidio ajaa structlog-prosessorina ja nappaa 94 % sähköposteista ja puhelinnumeroista ennen kuin ne osuvat Lokiin. Ohi menevät ovat lähes kaikki erikoisia muotoiluja, joita paikkaamme omiin tunnistimiin sitä mukaa kun löydämme niitä.

Koko koukku on viisitoista riviä:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

Maskaus on samassa putkikerroksessa syöte- ja tulostesuodattimien kanssa, ja se pitäisi testata samalla tavalla. Meidän suojakaideputkemme käsittelee lokiin vuotanutta sähköpostia epäonnistuneena evalina, ei toiminnanhuomautuksena.

Sääntö 6: Ota otoksia älykkäästi suurilla volyymeilla

Alle noin 100 000 pyyntöä päivässä: lokita kaikki. Sen yli täyden volyymin lokitus on tallennusvero datasta, jota et koskaan lue, ja otanta on tapa säilyttää tärkeät tietueet. Mutta satunnaisotanta on huonoin vaihtoehto LLM-liikenteelle, koska epäonnistumiset, kieltäytymiset ja viiden dollarin pyynnöt ovat määritelmän mukaan harvinaisia, joten tasainen 10 %:n otos heittää pois juuri ne tapahtumat, joita debuggaat. Ota otoksia tuloksen mukaan, ei kolikonheitolla.

Yleinen setuppi on sääntöpohjainen reunoilla (tuotanto ja yritysasiakkaat: lokita aina) ja häntäpohjainen keskellä. Lokitukseen liittyvä näkökulma tässä viitekehyksessä: guardrail_result- ja cost_usd-kenttäsi ovat otantasignaaleja, jo valmiina, jos noudatit sääntöjä 2 ja 8.

Sääntö 7: Aseta säilytyskäytäntö ennen kuin tarvitset sitä

Lokien säilytyskäytäntö on päätös, joka tehdään rauhallisena, koska vaihtoehto on tehdä se kustannuskatselmuksessa kaksinkertaisella volyymilla. GDPR:n artiklan 5 säilytyksen rajoittamisen periaate sanoo, että henkilötietoja saa säilyttää "ei kauempaa kuin on tarpeen", mikä käytännössä tarkoittaa portaittaista säilytystä:

Kuuma vastaa "mitä tapahtui kymmenen minuuttia sitten?" nopeasti ja kalliisti. Kylmä vastaa "mitä sanoimme tälle asiakkaalle maaliskuussa?" hitaasti ja halvalla. Poista aikataulussa, automaattisesti, tai portaat ovat vain kaavio.

Sääntö 8: Lokita suojakaide- ja turvallisuustapahtumat erikseen

Turvallisuustapahtumat (suojakaiteen estot, kieltäytymiset, käytäntörikkomukset) eivät ole telemetriaa. Ne ovat auditointitietueita, ja ne kuuluvat omaan virtaansa. Kolme syytä. Hälytys: estettyjen prompt-injektioiden piikki pitäisi herättää joku, eikä sitä hälytystä voi virittää miljoonaa arkiriviä vasten. Säilytys: vaatimustenmukaisuus voi vaatia, että turvallisuustietueet elävät debug-lokeja vuosia pidempään. Pääsy: auditoijat saavat turvallisuusvirran, eivät koko paloletkua. Merkitse ratkaisu päätietueeseen (guardrail_result: "block") ja reititä koko tietue erilliseen virtaan. Se, mikä lasketaan turvallisuustapahtumaksi, käsitellään suojakaidetapahtumien oppaassamme.

Sääntö 9: Tee lokeista kyseltäviä, ei vain tallennettuja

Loki, jota et voi kysellä alle minuutissa, on varmuuskopio, ei observointisignaali. Kyseltävä tarkoittaa indeksoituja kenttiä, kyselykieltä, jonka päivystäjäsi todella osaa, ja kojelautoja, jotka on rakennettu ennen häiriötä. Me ajamme Lokia ja kysymme sitä yli 30 kertaa viikossa kustannuspoikkeamien, viiveregressioiden ja "näytä jokainen eilinen kieltäytyminen tenantilta X" vuoksi. Grafana Lokin dokumentaatio on syntaksin lähde. Kannattavin kuvio on suodatus suoraan jäsenneltyjen JSON-kenttien perusteella:

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

Viisi riviä, ei vientiä notebookiin. Jos nykyinen tallennuspaikkasi ei pysty siihen, se on korjattava ongelma ensimmäisenä.

Mitä me oikeasti lokitamme tuotannossa

Riittää teoria. Tässä on maskattu konfiguraatio AI SDR -putkestamme, palvelusta, joka vastaa johdannon 1,2 miljoonan pyynnön kuukausiluvusta. Se ajaa structlog 25.4.0:aa, joka renderöi JSONia ja lähettää Grafana Cloud Lokiin Promtailin kautta. Tämän putken malli on claude-sonnet-4-20250514, ja jokainen kutsu kulkee täsmälleen sääntöjen 2 ja 5 prosessoriketjun läpi:

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Kaksi lukua ensimmäiseltä neljännekseltä tällä setupilla. Kuukausittainen sisäänotto vakiintui 47 GB:hin neljän palvelun yli, ja p95-lokikirjoitusviive on 3 ms, eli putki ei lisää pyyntöaikaan mitään mitattavaa.

Konfiguraatiomuutos, joka maksoi itsensä takaisin: lisäsimme cost_usd:n jokaiseen lokitietueeseen maaliskuussa 2026. Viikon sisällä löysimme yhden prompt-mallin, joka poltti 340 $/kk uudelleenyrityssilmukoissa. Tilapäinen API-virhe laukaisi kolme uudelleenyritystä, joista jokainen lähetti koko 4 000 tokenin kontekstin uudelleen. Lokit tekivät siitä yhden rivin kyselyn. Ilman pyyntökohtaista kustannusta se olisi noussut esiin selittämättömänä budjettirivinä seuraavassa neljännesvuosikatselmuksessa.

Paljonko LLM-lokien tallennus maksaa skaalassa?

Miljoonalla pyynnöllä päivässä LLM-lokien tallennus maksaa suunnilleen 1,20–108 $ kuukaudessa samasta datasta tallennuspaikasta riippuen. Lasku: täysi jäsennelty tietue on keskimäärin noin 2 kt, joten miljoona pyyntöä päivässä on 2 GB päivässä eli 60 GB kuukaudessa. Alla olevat toimittajien julkaisemat hinnat (heinäkuu 2026) kertovat, mitä tuo 60 GB maksaa kolmessa yleisessä backendissa.

Lähteet: Datadogin hinnoittelu, Grafana Loki ja ClickHouse-observointidokumentaatio.

Kaksi varaumaa, koska tämä on meidän laskelmamme toimittajien hinnoista, ei ajamamme benchmark. Ensinnäkin Datadogin luku olettaa, että indeksoit kaiken. Useimmat tiimit indeksoivat osajoukon ja maksavat paljon vähemmän, kun taas Loki ja ClickHouse veloittavat pääasiassa tallennetusta. Toiseksi itse ylläpidetyn ClickHousen 1,20 $ kätkee todellisen laskun: klusterin ajamiseen tarvittava laskenta ja sen operointiin kuluvat insinööritunnit. 60 GB:ssa kuukaudessa hallittu palvelu on lähes aina kokonaisedullisempi vastaus. Itse ylläpito alkaa kannattaa suunnilleen 1 TB:n kuukausivolyymilla, jossa GB-kohtainen ero jyrää operointikulut.

Erot ovat pointti. Miljoonalla pyynnöllä päivässä Datadog-indeksoinnin ja itse ylläpidetyn ClickHousen väli on suunnilleen 90-kertainen: 108 $ vastaan 1,20 $ samasta 60 GB:sta. Valitse tallennuspaikka arkkitehtuurivaiheessa, ei laskun saavuttua.

Minkä lokitustyökalun valita?

Useimmille tiimeille valinta tiivistyy neljään vaihtoehtoon: LLM-natiivi alusta (Langfuse tai LangSmith), välityskerrostyökalu (Helicone) tai tavallinen OpenTelemetry-putki jo olemassa olevaan infrastruktuuriin. Taulukko kattaa päätöskohdat, jotka todella eroavat. Kojelaudat, toisto ja promptien versiointi ovat perusvaatimuksia kaikissa neljässä.

Meidän mielipiteemme suoraan: ajamme OTel-natiivia ja Lokia, koska meillä oli jo Grafana-pino kaikkea muuta varten, ja yhden tietolähteen lisääminen voitti neljännen toimittajan omaksumisen. Jos aloitat nollasta ilman mitään observointipinoa, Langfusen jälkimalli ja sen ilmaisversio ovat nopein tie hyödylliseen, ja itse ylläpidon vaihtoehto pitää poistumistien auki. Jos valitset kahden LLM-natiivin johtajan välillä, meidän Langfuse vs LangSmith -vertailumme käy koko vertailun läpi. Ja jos lokitus on osa isompaa monitorointipäätöstä, täysi alustavertailu kattaa laajemman kentän.

Mitkä ovat yleisimmät LLM-lokituksen virheet?

Kuusi virhettä selittää suurimman osan rikkinäisistä LLM-lokituksista, joita olemme nähneet. Jokainen on halpa välttää, jos sen huomaa ennen kuin lokivolyymi huomaa sen:

• Raa'an PII:n lokittaminen ilman maskausta. Yleisin ja kallein. Yksi tukivienti tai yksi murrettu bucket muuttaa prompt-lokit tietosuojatapaukseksi. Maskaa ennen kirjoitusta (sääntö 5), ei lukuvaiheessa.
• Ei säilytyskäytäntöä. Ikuinen säilytys on oletus kaikkialla, ja se hiljaa kaksinkertaistaa laskusi joka vuosi. Jos et koskaan poista, sinulla ei ole lokitusjärjestelmää. Sinulla on arkisto, joka kärsii suuruudenhulluudesta.
• Jäsentelemättömät tekstilokit. Print-ulostulo, jota voi vain grepata, toimii demomittakaavassa ja kaatuu 100 000 pyynnöllä päivässä, kun "löydä jokainen epäonnistunut pyyntö mallilta X" muuttuu iltapäiväksi shell-skriptejä kyselyn sijaan.
• Vain virheiden lokittaminen. Onnistuneet pyynnöt ovat perustaso, jota vasten ajautumista havaitaan, ja ne ovat arviointiputkesi raaka-ainetta. Lokita onnistumisetkin, otoksina jos volyymi pakottaa.
• Kustannuskenttien huomiotta jättäminen. Ei cost_usd:ta pyyntöä kohti tarkoittaa ei kustannushälytyksiä, ei ominaisuuskohtaista kohdennusta, ja yllä olevan tuotanto-osion 340 $/kk uudelleenyrityssilmukka pysyy näkymättömänä neljännesvuosilaskuun asti.
• Ei jälkikorrelaatiota. Spaneista irrotetut lokit tekevät monivaiheisten agenttien debuggauksesta arvailua. Jos lokirivistäsi puuttuu trace_id, sääntö 4 on korjaus.

Tietoa kirjoittajasta

Mert Batur on Techsy.io:n perustajajäsen, ja hänen tiiminsä toimittaa AI-agentteja, automaatiojärjestelmiä ja ääni-/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi todella käyttää tuotannossa. Yhdistä LinkedInissä.

Usein kysytyt kysymykset

Mitä jokaisesta LLM-pyynnöstä pitäisi lokittaa?

Vähintään: koko prompt ja vastaus PII maskattuna, mallin nimi, syötteen ja tulosteen tokenmäärät, viive, kustannus dollareina, hashattu käyttäjätunniste sekä OpenTelemetry-jäljen ja spanin ID:t. Lisää RAG-lähde-ID:t ja suojakaiteen ratkaisu, jos putkessasi on nuo vaiheet. Neljätoista nimettyä kenttää, yksi JSON-rivi pyyntöä kohti.

Mikä on paras muoto LLM-lokeille?

Jäsennelty JSON, yksi objekti pyyntöä kohti, jokainen kenttä eksplisiittisesti nimettynä. Vapaan tekstin lokeja voi vain grepata. JSON-tietueet voidaan aggregoida malleittain, summata kustannuksittain ja liittää jälkiin. Lähetä tietue jäsennellyllä loggerilla, kuten structlog Pythonissa tai pino Nodessa, ja renderöi se JSON-serialisoijalla, ei koskaan merkkijonomuotoilulla.

Miten PII:tä käsitellään LLM-lokeissa?

Maskaa ennen lokikirjoitusta, ei sen jälkeen. Aja prompt ja vastaus Microsoft Presidion kaltaisen tunnistimen läpi lokitusputkessasi ja korvaa nimet, sähköpostit ja puhelinnumerot tokeneilla, kuten <EMAIL_ADDRESS>. Kun raaka PII pääsee lokitallenteeseesi, se on myös varmuuskopioissasi, ja jälkikäteen tehty poisto harvoin täyttää GDPR:n minimointitestin.

Paljonko LLM-lokien tallennus maksaa skaalassa?

Miljoonalla pyynnöllä päivässä, noin 60 GB kuukaudessa 2 kt:n tietueella, odota suunnilleen 108 $/kk Datadogin indeksoidulla LLM Observability -hinnoittelulla, 30 $/kk Grafana Cloud Lokilla tai noin 1,20 $/kk pakattuna S3-tallennuksena itse ylläpidetylle ClickHouselle plus laskenta. Nuo ovat toimittajien julkaisemia hintoja heinäkuulta 2026. Itse ylläpito lisää insinöörityön päälle.

Mitä ovat OpenTelemetry GenAI -semantiikkasopimukset?

Ne ovat OpenTelemetryn standardinimet LLM-kutsujen instrumentointiin: gen_ai.system tarjoajalle, gen_ai.request.model mallille, gen_ai.usage.input_tokens ja output_tokens tokenmäärille sekä gen_ai.response.finish_reasons generoinnin päättymissyylle. Niiden käyttäminen tarkoittaa, että mikä tahansa OTel-yhteensopiva backend Jaegerista Tempoon ja Langfuseen lukee jälkesi ilman custom-parseria.

Miten LLM-lokeista otetaan otoksia kovassa liikenteessä?

Säilytä jokainen virhe, jokainen suojakaiteen esto ja jokainen kustannusrajan ylittävä pyyntö, ja ota sitten otokset lopuista. Tämä häntäpohjainen lähestymistapa säilyttää harvinaiset tapahtumat, joita todella debuggaat, kun taas tasainen satunnaisotanta heittää ne pois samaa tahtia kuin tylsän liikenteen. Alle 100 000 pyynnöllä päivässä jätä otanta kokonaan väliin ja lokita kaikki.

Kuinka kauan LLM-lokeja pitäisi säilyttää?

Portaissa: 7 päivää kuumaa live-debuggausta varten, 30 päivää lämmintä häiriökatselmusta ja kustannusanalyysia varten ja enintään 1 vuosi kylmää pakatussa objektitallenteessa vaatimustenmukaisuutta ja auditointeja varten. GDPR:n säilytyksen rajoittamisen periaate kieltää henkilötietojen säilyttämisen kauempaa kuin on tarpeen, joten liitä jokaiseen portaaseen automaattinen poisto manuaalisen siivouksen sijaan.

Mitä eroa on LLM-lokituksella ja LLM-jäljityksellä?

Loki on litteä tietue yhdestä tapahtumasta: tämä pyyntö tapahtui näillä kentillä. Jälki on syy-seurauspuu spineja koko pyyntöpolun yli, esimerkiksi haku, sitten mallikutsu, sitten kaksi työkalukutsua. Lokit kertovat mitä. Jäljet kertovat missä ja miksi. Tuotantosetit lähettävät molemmat, yhdistettynä trace_id:llä.

Yhteenveto

Kertaus: lokita jokainen pyyntö nimettyjen kenttien JSONina, laske kustannus pyyntöhetkellä, liitä OTel-jälkikonteksti, maskaa PII ennen kirjoitusta, ota otoksia tuloksen mukaan kun ylität 100 000 pyyntöä päivässä ja valitse tallennuspaikka, jota voit oikeasti kysellä. Yhdeksän sääntöä on järjestetty niin, että voit ottaa yhden per sprintti, ja säännöt 2, 4 ja 5 ovat kolme nopeimmin takaisin maksavaa. Jos valitset lokien ympärille laajempaa monitorointipinoa, aloita parhaiden AI-observointialustojen kokoelmastamme. Ja jos tarvitset apua jäsennellyn lokituksen kytkemisessä LLM-pinoosi, ota ilmainen konsultaatio.