You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7bc56fa
Browse filesBrowse the repository at this point in the historyBrowse files
fix(gooddata-eval): count timed-out turns and fix HTML change labels
Review of the latency report found two places where the response-time
population and the scored runs disagree, three where the HTML report
disagrees with the console or labels the wrong run, and one repeated
computation.
A turn that ended in a ChatError (a turn or item deadline, an error
event, an incomplete turn) was never recorded as a trace, although
evaluators score its partial result as a run. The slowest turns went
missing from the per-response percentiles. send_message now records
the turn's wall clock from the partial result before re-raising.
An item that raised outside its evaluator's own failure reporting kept
the turns it had completed but reported no runs, so it showed up in the
per-response table and not in the per-conversation one. Its turns are
now dropped (TraceRecorder.discard), along with the runs it never
reported.
The pass-rate card divided by every test case, skipped ones included,
while the console divides by those evaluated, so 10 passed of 14 with 2
skipped read 71% against 83%. The card, and the recomputed figures of
a filtered view, now use one passRateOf helper. The page's pass_rate
figure was read by nothing and is removed; the JSON field is unchanged.
The Since previous run labels described earlier runs when they should
describe the latest: a test case skipped in the latest run was labelled
Regressed beside a SKIP cell, and one absent from the previous run but
present before it was labelled New instead of Fixed or Flaky. A skipped
latest run now has no label, and New and Removed look at every earlier
run.
EvalReport.by_mode is a cached_property, since the console, the
comparison and both JSON builders each rebuilt and re-sorted it.
The README describes the changed definitions. The HTML rules are tested
by running the page's own functions in Node, skipped where Node is
absent.
jira: trivial
risk: low
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: packages/gooddata-eval/README.md
+8-5Lines changed: 8 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -340,7 +340,9 @@ Each item also states its `mode`, its `trace_latencies_s` and its `run_latencies
340
340
Its latency is that turn's response time, from sending the message to the end of its stream
341
341
(`turn_wall_clock_sec`), recorded where the chat client completes the turn. It holds none of the LLM judge,
342
342
the simulated user or conversation create/delete. `dashboard_summary` is timed the same way around its one
343
-
request. A turn that raised was never completed and has no entry.
343
+
request. A turn cut off by its turn or item deadline (or ended by an error event) still counts, with the
344
+
time it ran for: those are the slowest turns, and the run that scored them is in the per-run figures too. An
345
+
item that errored outside its evaluator's own failure reporting contributes neither.
344
346
-**Single-shot** runs are exactly one trace, so `traces_s` is also the latency of a run.
345
347
-**Multi-turn** runs span several traces, so they get both views: `traces_s` over every turn of every
346
348
conversation (comparable with single-shot), and `runs_s`, the wall clock of each whole conversation from just
@@ -409,8 +411,8 @@ simulated user), which are `single_shot` and `multi_turn` in the JSON.
409
411
the runs in play has it (so "Failed" over previous and latest finds every test case that broke in either), and the
410
412
expression is evaluated once per run in play with the same any-run rule. A filtered page states how many test cases
411
413
it covers, and each tier has its own Reset.
412
-
-**Results** — three headline cards for the latest run: test cases passed, the average quality score and the median
413
-
time per attempt. With an earlier run each card carries one change line in words, "down from 86% on Sep 28", rather
414
+
-**Results** — three headline cards for the latest run: test cases passed (of those evaluated: skipped ones are not
415
+
counted, as in the console's percentage), the average quality score and the median time per attempt. With an earlier run each card carries one change line in words, "down from 86% on Sep 28", rather
414
416
than a signed number. The line is green when that direction is good and red when it is not, with a chevron and
415
417
screen-reader text (*Better* / *Worse*) so colour is not the only signal. From three runs each card also has a
416
418
sparkline of every run: hover a point for its value, click it to compare the latest run with that one instead of the
@@ -428,8 +430,9 @@ simulated user), which are `single_shot` and `multi_turn` in the JSON.
428
430
decimal and no redundant ".0" (`3s`, `4.6s`).
429
431
-**A test case table**, newest first: the latest run's result, a **Since previous run** column, then the earlier runs
430
432
going back in time (click any result to open the drawer on that run). The change column reads *Regressed* (passed in
431
-
the previous run, not in the latest), *Fixed*, *Flaky* (flipped between pass and fail more than once), *New* or
432
-
*Removed*. With several runs the table opens on the regressions. Two time columns
433
+
the previous run, not in the latest), *Fixed*, *Flaky* (flipped between pass and fail more than once), *New*
434
+
(in no earlier run) or *Removed* (in an earlier run, gone from the latest). A test case skipped in the latest run
435
+
has no label, since the change would describe earlier runs. With several runs the table opens on the regressions. Two time columns
433
436
keep the populations apart: **Response time** is the median of the test case's assistant responses, and **Time per
434
437
attempt** is the mean wall-clock of a whole attempt (the responses plus the judge and, for conversations, the
435
438
simulated user). With more than two runs shown they follow the latest run only. Hover a value to see every sample
...(multi ? [{k: 'chg',html: 'Since previous run',help: 'Regressed: passed in the previous run, not in the latest. Fixed: the reverse. Flaky: has flipped between pass and fail more than once across the runs shown. New / Removed: the test case was added to or dropped from the suite.'}] : []),
937
+
...(multi ? [{k: 'chg',html: 'Since previous run',help: 'Regressed: passed in the previous run, not in the latest. Fixed: the reverse. Flaky: has flipped between pass and fail more than once across the runs shown. New / Removed: the test case first appears in the latest run, or was in an earlier run and is gone from the latest. A test case skipped in the latest run has no label.'}] : []),
0 commit comments