Processutvinning — Pipelinesjälvanalys

Tänk om körmiljön kunde analysera sina egna exekveringsmönster — och upptäcka saker som pack-författaren inte förutsåg?

Forskning pm4pyPetri net discoveryconformance checkingmeta-circular analysisFlowTime feedback loop

— — — — —

Forskning | pm4py, Petri-nätupptäckt, conformance checking, metacirkulär analys, FlowTime-feedbackloop

Scenariot

Katarinas team har kört Radar-packet i tre månader — 100 körningar över 12 veckors informationsbevakning och analys. Pipelinen fungerar. Briefingar levereras i tid. Men Katarina har frågor som briefingarna inte kan besvara:

Vilka källor producerar konsekvent innehåll som överlever relevansfiltret? Finns det exekveringsmönster som pack-författaren inte designade för — vägar genom DAG:en som uppstår ur samspelet mellan cachning, LLM-beslut och källtillgänglighet? En källa verkar orsaka omförsök varje tisdag morgon. Är det ett verkligt mönster eller en slump?

Datan för att besvara dessa frågor finns redan. Varje Radar-körning producerade en händelselogg — tidsstämplad, med op-namn, varaktigheter, artefakthashar, beslutsutfall. Hundra JSONL-filer. Liminaras egen exekveringshistorik är, strukturellt, exakt den typ av händelselogg som processutvinning konsumerar.

Systemet kan analysera sig självt.

Pipelinen

PHASE 1: INGEST AND DISCOVER
══════════════════════════════════════════════════════════════════

event logs ──→ parse_logs ──→ normalize ──→ discover_model ──→ conformance_check
(100 JSONL
 from Radar                     │               │                  │
 runs)                          │               │                  │
                                │               │                  │
                                │  case notion:  │  discovered:     │  deviations:
                                │  one run =     │  Petri net with  │  15% of runs show
                                │  one case      │  12 places,      │  unexpected retry
                                │                │  18 transitions  │  on source fetch
                                │  DECISION      │                  │  for source #7
                                │  RECORDED      │  matches the     │  (HN API)
                                │                │  intended plan   │
                                │                │  — mostly        │  4% show a
                                │                │                  │  classification
                                │                │                  │  re-run after
                                │                │                  │  synthesis
                                │                │                  │  (not in the plan)


PHASE 2: ANALYZE AND BRIDGE
══════════════════════════════════════════════════════════════════

                    ┌──→ variant_analysis ──→ bottleneck_stats ──→ report
                    │
conformance_check ──┤
                    │
                    └──→ export_to_flowtime ──→ flowtime_simulate ──→ compare
                                                  │
                                                  │  FlowTime models the
                                                  │  Radar pipeline as a
                                                  │  flow system:
                                                  │
                                                  │  "If source #7 retry
                                                  │   rate drops from 15%
                                                  │   to 2%, pipeline
                                                  │   duration decreases
                                                  │   by 8 minutes (12%)"

Fas 1 — Ingest och upptäck:

parse_logs: Läs 100 Radar-händelseloggfiler. Varje händelse har: tidsstämpel, op-namn, körnings-ID, artefakthashar, varaktighet, utfall. Konvertera till XES-format för pm4py-ingestion. Totalt: ~14 000 händelser över 100 fall (körningar). Executor: Python-process som kör pm4py 2.7.
normalize: Definiera fallbegreppet — vad som utgör ett “fall” i händelseloggen. För Radar-körningar är varje körning ett fall. Men valet är inte alltid självklart. För en pipeline med underkörningar eller fan-out kanske man definierar fall annorlunda. Detta är ett modelleringsbeslut, och det påverkar allt nedströms. Beslut registrerat: “fall = run_id, aktiviteter = op-kompletteringar, tidsstämplar = händelsetidsstämplar.”
discover_model: Kör den induktiva minern på den normaliserade loggen. Producerar ett Petri-nät: 12 platser, 18 transitioner, som representerar det upptäckta exekveringsmönstret över alla 100 körningar. Nätet visar de faktiska exekveringsvägarna, inte den avsedda planen.
conformance_check: Jämför det upptäckta Petri-nätet mot den avsedda Radar-planen (den designade DAG:en). Alignment-baserad conformance. Resultat: 81 % av körningarna överensstämmer perfekt. 15 % visar en extra retry-transition på fetch_source för källa #7 (HN API). 4 % visar en classify-omkörning efter synthesize — en väg som pack-författaren inte designade.

Fas 2 — Analysera och brygga:

variant_analysis: Gruppera de 100 körningarna efter exekveringsväg. Variant 1 (81 körningar): den lyckliga vägen. Variant 2 (15 körningar): inkluderar HN-retry. Variant 3 (4 körningar): inkluderar omklassificering efter syntes. Beräkna frekvens, varaktighetsfördelning, kostnad per variant.
bottleneck_stats: Per-op varaktighetsstatistik över alla körningar. classify är mest variabel: medel 23s, P95 48s, P99 112s (LLM-latensvariation). fetch_source för HN: medel 2,1s, men 15 % av fallen visar 45s+ (timeout + retry). embed är stabilast: medel 1,8s, standardavvikelse 0,2s.
export_to_flowtime: Konvertera det upptäckta Petri-nätet till en FlowTime-modelldefinition. Platser blir köer. Transitioner blir tjänster med betjäningstidsfördelningar härledda från flaskhalsstatistiken. Dirigeringssannolikheter från variantfrekvenser: 81 % lycklig väg, 15 % retry-väg, 4 % omklassificeringsväg.
flowtime_simulate: FlowTime simulerar Radar-pipelinen som ett flödessystem. Tänk-om: “Om källa #7:s retry-frekvens sjunker från 15 % till 2 %, hur mycket snabbare blir pipelinen?” Svar: genomsnittlig körningstid minskar från 67 minuter till 59 minuter (-12 %). “Om vi lägger till en andra LLM för klassificering (parallell, inte sekventiell), sjunker P95-klassificeringstiden från 48s till 28s.”
report: Rendera resultat — visualisering av upptäckt modell, conformance-avvikelser, flaskhalsheatmap, tänk-om-jämförelse från FlowTime.

Det oväntade omklassificeringsmönstret

Conformance-kontrollen fann att 4 % av körningarna inkluderar ett classify-steg efter synthesize — en väg som inte finns i den designade Radar-planen. Vad händer?

Spårning av dessa 4 körningar i detalj:

Run #34:  ... → classify → cluster → synthesize → classify → synthesize → briefing
                                                   ^^^^^^^^
                                                   not in the plan

Decision record for Run #34, synthesize (first attempt):
  "Synthesis flagged inconsistency: document sha256:a1b2 was classified as
   'regulatory' but cluster analysis placed it with 'technology' documents.
   Re-running classification with updated context."

Decision record for Run #34, classify (second pass):
  "Reclassified sha256:a1b2 from 'regulatory' to 'technology/regulatory-adjacent'
   based on cluster context. Confidence improved from 0.61 to 0.84."

Packet har en implicit feedbackloop: när syntesen upptäcker en inkonsekvens triggar den omklassificering. Pack-författaren designade inte detta explicit — det uppstod ur LLM:ens syntessteg som upptäckte problem och pipelinens felhantering som tillät omkörning. Processutvinning gjorde det synligt. Är det en bugg eller en funktion? Det är en fråga för pack-författaren — men nu vet de att det händer, i exakt vilka körningar, och med vilken effekt på utdatakvaliteten.

Vad du kan fråga efteråt

Fråga	Hur den besvaras
”Vilka källor producerar konsekvent relevant innehåll?”	Variantanalys + per-källstatistik: källa #3 (Riksdagens API) förekommer i 94 % av briefingarna. Källa #11 (nischad RSS-feed) förekommer i 12 % och har aldrig passerat relevansfiltret under de senaste 40 körningarna.
”Är tisdagsmönstret med omförsök på HN verkligt?”	Flaskhalsstatistik med veckodag-overlay: ja. HN API:s svarstider toppar tisdag 08:00-09:00 CET (måndagkväll i USA-trafik). 11 av 15 retry-fall hamnar i detta fönster.
”Vad skulle det kosta att åtgärda retry-problemet?”	FlowTime-simuleringen visar 12 % varaktighetsförbättring. Fixen är infrastruktur (längre timeout, förhämtning på måndagkväll). Ingen ändring av pipelinelogiken behövs. Processutvinning kvantifierade påverkan; FlowTime simulerade förbättringen.
”Finns det andra framväxande mönster vi inte har märkt?”	Det upptäckta Petri-nätet är svaret. Jämför det mot den avsedda planen — varje avvikelse är ett mönster som designern inte förutsåg. För närvarande: omklassificeringsloopen (4 %) och retry-vägen (15 %). Allteftersom fler körningar ackumuleras kan nya mönster framträda.
”Hur skiljer sig vår pipeline från förra månaden?”	Kör upptäckt på två delmängder: körning 1-50 (månad 1-2) vs. körning 51-100 (månad 2-3). Jämför Petri-näten. Strukturella skillnader visar hur pipelinens beteende har utvecklats — kanske uppstod omklassificeringsmönstret först efter en modelluppdatering.

Före och efter

Idag: Katarina vet att pipelinen fungerar för att briefingar kommer. Hon vet inte hur den fungerar i praktiken — vilka vägar som är vanliga, vilka källor som bär sin vikt, om det finns mönster hon bör oroa sig för. När något tar längre tid än väntat kollar hon loggar manuellt. Loggarna är ordrika och berättar vad som hände i en körning, inte vad som händer över körningar. Sambandet mellan källtillförlitlighet och pipelinevaraktighet är osynligt.

Med processutvinning: 100 händelseloggar blir en upptäckt processmodell — en karta över faktiskt beteende, inte avsett beteende. Conformance checking visar exakt var verkligheten avviker från designen: 15 % retry-frekvens på en källa, 4 % framväxande omklassificeringsloop. Flaskhalsstatistik kvantifierar vilka ops som är stabila och vilka som är variabla. FlowTime-bryggan omvandlar den upptäckta modellen till en simulering — så “tänk om vi fixar detta?” har ett kvantifierat svar, inte en gissning.

Den metacirkulära kvaliteten spelar roll: Liminaras egen exekvering är datasetet. Systemet kör inte bara pipelines — det kan lära sig av hur det kör dem. Pack-författaren får feedback de aldrig haft förut: inte “fungerar pipelinen?” utan “hur beter sig pipelinen faktiskt, och vilka mönster har framträtt som jag inte designade?”

Söker processutvinningspraktiker och team intresserade av pipeline-observabilitet. [Kontakt ->]

— — — — —

Intresserad? Hör av dig →