Conciseness
Conciseness checks whether an output conveys its content without unnecessary length, repetition or filler. It mirrors the RAGAS aspect critic for conciseness.
What the evaluator does
Jev returns p(yes) for “no unnecessary length, repetition or filler”, given the output and optionally the input for expected scope.
`output` conveys its content without unnecessary length, repetition, or filler.
The question, verbatim
This is the question the API sends for the example below, generated from the same code path the playground and API use. Jev sees the request fields as state and returns a probability for each outcome. Nothing is generated, so there is nothing to parse.
`output` conveys its content without unnecessary length, repetition, or filler.
Reach for it when
- Chat products where verbosity hurts.
- Controlling for length bias in Battle-style comparisons.
- Cost control: verbose outputs cost tokens downstream.
Not the right tool when
- The task asks for exhaustive detail.
Watch out for
- Concise and incomplete are different; pair with answer_relevancy or task_completion.
What to send
score 0–1 (p of the good outcome), label “nn% yes”, confidence |p − 0.5| × 2, probabilities yes/no, passed at 0.5.
{
"evaluators": [
"conciseness"
],
"input": "Minimum Node version?",
"output": "Great question! Node versions matter a lot. The SDK needs Node 20 or newer, which is to say version twenty or any later version."
}Low p(concise): filler and repetition.
Aggregate with
One result per item is a fact; a dataset of them is a metric. These are the aggregations that fit this evaluator's output shape.
- Does conciseness penalise long answers?
- Only unnecessary length. A long answer to a question that needs it can still be concise.