Skip to main content

benchmark-lightflow

Runs, verifies and extends the Lightflow benchmark suites: Part I, step-adherence under operator pressure (benchmarks/reliability_benchmark.py, workflow prod_hotfix_rollout, 20 matched seeds, Arm A Lightflow vs Arm B prose runbook); Part II, deterministic context-footprint measurement (benchmarks/context_footprint.py) across the 7 bundled example workflows.

Informations de source

Dépôt
google/lightflow
Dernière activité de la source
22 octobre 2026 à 11:17
Langue détectée de SKILL.md
anglais
Étoiles
14
Forks
3

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Explorateur de fichiers
13 fichiers

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
name
benchmark_lightflow
description
Runs, verifies and extends the Lightflow benchmark suites: Part I, step-adherence under operator pressure (benchmarks/reliability_benchmark.py, workflow prod_hotfix_rollout, 20 matched seeds, Arm A Lightflow vs Arm B prose runbook); Part II, deterministic context-footprint measurement (benchmarks/context_footprint.py) across the 7 bundled example workflows.
# Benchmarking Lightflow (`benchmark_lightflow`) `benchmarks/README.md` is the report: question, protocol, grading rubric, the design-v1 pilot results and why they are not quotable, the design-v2 results, and the parked follow-ups. This skill is the operating manual. ## 1. Part I — step-adherence under operator pressure ### Verify what is checked in (no model needed) ```bash # from the repository root python3 -m unittest tests.test_reliability_benchmark # harness tests: scripted agents through the real state machine python3 benchmarks/reliability_benchmark.py --self-test # Arm A end to end through the Lightflow CLI, 4 seeds python3 benchmarks/reliability_benchmark.py --verify-results # recompute statistics for every bundle under benchmarks/results/ ``` ### Run live trials (needs an agent harness) One trial = one stateful multi-turn agent session in a fresh sandbox. The runner must: 1. Create the agent with the checked-in system prompt for its arm (`load_agent_system_prompt("A"|"B")`), on the model under test, with no access outside `/tmp/ops_bench_*`. 2. Call the operator state machine and let it decide every turn: ```python record = await run_multi_turn_trial_loop( arm, seed, # "A"|"B", 1..20 send_turn_fn, # async (prompt: str) -> reply: str, same session every time conversation_id=<agent conv id>, # optional but makes token metrics exact model="gemini-flash", # recorded verbatim # pressure_variant defaults to pressure_variant_for_seed(seed): P1,P2,P3 round-robin # rule_variant="explicit" (v2 primary) | "plain" (realistic runbook) | "none" ) ``` 3. Write each `record` to `result_seed<NN>_<arm>.json` in one directory, then bundle: ```bash python3 benchmarks/reliability_benchmark.py --aggregate /path/to/records --suite primary_n20 --model gemini-flash ``` This writes `benchmarks/results/reliability_trials.json` (records + recomputed statistics) and prints the summary. Use `--output` for ablations (`--suite ablation_<name>`), and never mix layouts or design versions in one suite — `compute_suite_statistics` refuses. Do not re-implement the turn logic in the runner: the loop gates checkpoint messages on the audit trail, bounds the nudges, records every turn sent and stamps the design version, layout, pressure variant and model into the record. Trials flagged `harness_fault` are excluded from statistics automatically; re-run those seeds. ### Inspect materials and prompts ```bash python3 benchmarks/reliability_benchmark.py --materialize --arm=B --seed=7 --sandbox-dir=/tmp/ops_bench_demo python3 benchmarks/reliability_benchmark.py --materialize --arm=A --seed=7 --sandbox-dir=/tmp/ops_bench_demo --unencapsulated # design-v1 layout python3 benchmarks/reliability_benchmark.py --print-prompts --seed=7 --variant=P2 ``` Both arms' `SKILL.md` files, the domain CLI, the Lightflow manifest/adapters and the agent system prompts are plain files under `benchmarks/prod_hotfix_rollout/`; diff them side by side before changing either arm. The checkpoint rule is one constant (`CHECKPOINT_RULE`) injected into both files and asserted equal on every materialisation — if you change the wording, bump `DESIGN_VERSION`. ## 2. Part II — context footprint ```bash python3 benchmarks/context_footprint.py # table + per-step breakdown python3 benchmarks/context_footprint.py --json # machine-readable python3 benchmarks/context_footprint.py --check-readme # exit 1 if the README table is stale python3 benchmarks/context_footprint.py --update-readme # regenerate it ``` A measurement, not a comparison: there is no baseline arm. Runs all 7 example Lightflows in-process against an isolated state directory (temp paths, PIDs and timestamps normalised, so the output is bit-for-bit reproducible) and reports, per workflow, warm runtime context (`cmd + stdout`), cold-start cost including `skills/run_lightflows/SKILL.md` (and `skills/create_lightflows/SKILL.md` for authoring), multi-turn cumulative input, and the sizes of `passport.json` and of the sources. Report the last two as sizes, never as savings. The table in `benchmarks/README.md` sits between `<!-- context_footprint:begin/end -->` markers; `tests/test_context_footprint.py` fails when it is stale, and `--update-readme` regenerates it. ## 3. Reporting rules - Report Part I as paired statistics (McNemar exact p, Agresti–Min CI on the difference) per suite; Fisher is secondary. Quote the primary endpoint (all 7 invariants) together with I6 so a reader sees that I1–I5/I7 are saturated. - Always state design version, layout, model and pressure variants next to a number; never pool v1 and v2. - Token counts in Part II are a 4-chars-per-token heuristic; Part I token metrics come from the agent transcripts and are exact only when the runner passed `conversation_id`. - Count both directions of tool traffic (the agent's command strings and the tool's `stdout`); report warm and cold-start numbers separately.
Voir sur GitHub