Benchmarking Terminology for Output Behavior Fault Detection in Large Language Model Serving Systems

1.1. Scope

This document defines terminology only. It does not specify test procedures, traffic profiles, injection mechanisms, acceptance thresholds, or service-level objectives. A companion methodology document is intended to specify those. That document does not yet exist. Statements in this document that defer a detail to the methodology identify work still to be done.¶

The behavioral indicators whose degradation is injected are defined by reference. This document does not define hallucination, refusal, or policy violation. It defines the fault classes constructed from them and the detection characteristics measured against them.¶

Benchmarking activity described by this terminology is confined to a test environment. Section 7 states this requirement.¶

1.2. Relationship to Other Work

[RFC1242] and [RFC2544] establish the terminology and methodology pattern this document follows. [RFC8238] and [RFC8239] apply that pattern to data center benchmarking.¶

[LLM-TERMS] defines System Under Test boundaries for LLM serving, and [LLM-METHOD] defines the corresponding methodology. Those boundaries are reused here to locate the observation point of the detector under test. [AI-FABRIC-TERMS] defines terminology for the network fabric beneath those serving boundaries.¶

[RFC9940] defines terms for network fault and problem management. This document adopts its separation between a fault and its detection. It applies that separation to behavioral faults in model serving.¶

3.1. Detector Under Test

Definition:

The observability system whose fault detection capability is characterized by a benchmark using this terminology.¶

Discussion:

The Detector Under Test (DUT) comprises the classifiers, judges, heuristics, sampling logic, aggregation, alerting rules, and thresholds that together determine whether a behavioral degradation is raised. The language model is not under test. The model and its serving stack form part of the test environment, and their configuration is held constant across trials.¶

Issues:

Where the DUT includes a language model as a judge, that model is part of the DUT and its version is reported as DUT configuration.¶

See Also:

Observation Point; Behavior Fault.¶

3.2. Observation Point

Definition:

The boundary within the serving deployment at which the Detector Under Test samples requests and responses.¶

Discussion:

The available boundaries are the Model Engine, the Application Gateway, and the Compound System, as defined in [LLM-TERMS]. A detector observing at the Application Gateway sees responses after output filtering. A detector observing at the Model Engine sees them before. The same injected fault may be visible at one boundary and masked at another.¶

Issues:

A benchmark result is valid only for the Observation Point at which it was obtained. Results obtained at different Observation Points MUST NOT be compared.¶

See Also:

Detector Under Test; Fault Injection Point.¶

3.3. Fault Injection Point

Definition:

The location within the test environment at which an Behavior Fault is introduced.¶

Discussion:

Injection may occur upstream or downstream of the Observation Point. An injection point downstream of the Observation Point produces a fault the detector cannot observe, which is a valid configuration for characterizing detection blind spots. The relative order of the Fault Injection Point and the Observation Point is reported with every result.¶

See Also:

Observation Point; Behavior Fault.¶

4.1. Behavior Fault

Definition:

A controlled, reversible change to the behavior of a serving deployment that shifts one or more behavioral indicators away from their baseline distribution, introduced for the purpose of characterizing a Detector Under Test.¶

Discussion:

An Behavior Fault is defined by the indicator it shifts, the magnitude of the shift, and the fault profile through which the shift is applied. A fault is not defined by its cause. Two faults that produce the same indicator shift are equivalent for benchmarking purposes regardless of the mechanism used to produce them.¶

Measurement Units:

Magnitude is expressed in the units of the affected indicator. For rate-valued indicators, magnitude is expressed as an absolute change in the rate.¶

Issues:

A fault of sufficiently small magnitude is indistinguishable from baseline variation. Reported results state the baseline variability of the affected indicator so that the magnitude can be interpreted.¶

See Also:

Fault Profile; Fault Class; Baseline Interval.¶

4.2. Fault Class

Definition:

A category of Behavior Fault distinguished by the behavioral indicator it shifts.¶

Discussion:

The following classes are defined for use with this terminology. The list is extensible.¶

• Refusal Shift: a change in the fraction of requests declined.¶
• Groundedness Degradation: a change in the fraction of responses unsupported by provided context.¶
• Policy Filter Degradation: a change in the fraction of responses that violate a declared policy and are emitted.¶
• Version-Scoped Degradation: any of the above applied to one model version while sibling versions on the same deployment remain at baseline.¶

Issues:

Detection characteristics are not comparable across Fault Classes. A detector may be fast on Refusal Shift and blind to Groundedness Degradation. Results are reported per class.¶

See Also:

Behavior Fault; Consistency Degradation.¶

4.3. Consistency Degradation

Definition:

A change in the dissimilarity between responses to identical requests issued under identical configuration.¶

Discussion:

Consistency Degradation is noted separately from the Fault Classes of Section 4.2 because it is produced differently. The other classes shift an indicator computed over independent requests. Consistency is computed over repeated requests, and injecting a shift in it requires perturbing the sampling configuration of the serving deployment. That perturbation is a configuration change and not a behavioral fault in the same sense. A benchmark using this terminology MAY include Consistency Degradation, and results for it are reported separately from the Fault Classes.¶

Measurement Units:

The units of the declared dissimilarity measure.¶

Issues:

A serving deployment configured for deterministic decoding has no baseline consistency variation, and Consistency Degradation is not applicable to it.¶

See Also:

Fault Class.¶

4.4. Fault Profile

Definition:

The function describing how the magnitude of an Behavior Fault varies over the duration of its application.¶

Discussion:

Three profiles are defined. A Step profile applies the full magnitude at the Fault Onset and holds it. A Ramp profile increases magnitude linearly from zero over a stated interval. An Intermittent profile alternates between full magnitude and baseline at a stated duty cycle and period.¶

Measurement Units:

Ramp interval and Intermittent period are expressed in seconds. Duty cycle is expressed as a fraction.¶

Issues:

Detection Latency is defined relative to Fault Onset for all profiles. For Ramp and Intermittent profiles the detector may reasonably raise the fault well after onset, since the fault is not at full magnitude at that time. Results for these profiles are interpreted with the profile parameters.¶

See Also:

Fault Onset; Detection Latency.¶

5.1. Fault Onset

Definition:

The time at which an Behavior Fault begins to be applied at the Fault Injection Point.¶

Discussion:

Fault Onset is known by construction. It is recorded by the injection apparatus and is not inferred from detector output. This is the property that distinguishes a benchmark from an observation of a production incident.¶

Measurement Units:

A timestamp with resolution of one millisecond or finer.¶

Issues:

The injection apparatus and the Detector Under Test may run on different hosts. Clock synchronization requirements are stated in the companion methodology. Reported Detection Latency values are valid only to the accuracy of that synchronization.¶

See Also:

Detection Event; Detection Latency.¶

5.2. Detection Event

Definition:

The time at which the Detector Under Test emits a signal attributable to an applied Behavior Fault.¶

Discussion:

The signal may be an alert, a threshold crossing, a state change, or a log record, according to the DUT configuration. The form of signal that constitutes a Detection Event is declared before the trial begins. Changing it after observing results invalidates the trial.¶

Measurement Units:

A timestamp with resolution of one millisecond or finer.¶

Issues:

Attribution of a signal to a specific applied fault requires that only one fault be applied at a time, or that the signal carry sufficient information to identify the affected indicator. The companion methodology states the requirement.¶

See Also:

Fault Onset; False Detection.¶

5.3. False Detection

Definition:

A signal emitted by the Detector Under Test during a Baseline Interval, in which no Behavior Fault is applied.¶

Discussion:

False Detection is measured over Baseline Intervals of stated duration under stated traffic. A detector can achieve arbitrarily low Detection Latency by lowering its thresholds, at the cost of False Detection Rate. The two are reported together.¶

Measurement Units:

Count per unit time, with the interval duration and traffic profile stated.¶

See Also:

Baseline Interval; Detection Latency.¶

5.4. Baseline Interval

Definition:

A period during which traffic is offered to the serving deployment and no Behavior Fault is applied.¶

Discussion:

Baseline Intervals serve two purposes. They establish the baseline distribution of each affected indicator, against which fault magnitude is expressed. They provide the observation period for False Detection.¶

Measurement Units:

Seconds.¶

Issues:

A Baseline Interval that is short relative to the DUT aggregation window does not establish a stable baseline. The companion methodology states a minimum.¶

See Also:

False Detection; Behavior Fault.¶

6.1. Detection Latency

Definition:

The interval from Fault Onset to the Detection Event attributable to that fault.¶

Discussion:

Detection Latency is defined per trial. A trial in which no Detection Event occurs before the end of the fault application yields no Detection Latency value. Such trials are counted separately and are reflected in Detection Coverage.¶

Measurement Units:

Seconds.¶

Issues:

Detection Latency depends on offered load. A detector observing a rate indicator requires a number of requests to accumulate evidence, and that number takes longer to accumulate at low request rates. A reported value is valid only for the offered load at which it was obtained. Results are reported across a range of loads.¶

See Also:

Fault Onset; Detection Event; Detection Coverage.¶

6.2. Detection Coverage

Definition:

The fraction of applied Behavior Faults of a given Fault Class and magnitude for which a Detection Event occurred.¶

Discussion:

Detection Coverage is measurable in a benchmark because the number of applied faults is known. It is not measurable from production records, where undetected faults leave no trace. Detection Coverage is the term that gives a Detection Latency figure its meaning. A detector that raises one fault in ten may report a low mean Detection Latency across the faults it raises.¶

Measurement Units:

A fraction between zero and one.¶

Issues:

Detection Coverage is a function of fault magnitude. A coverage figure reported without the magnitude at which it was obtained is not interpretable. Results are reported as coverage against magnitude.¶

See Also:

Detection Latency; False Detection.¶

6.3. Detection Threshold Magnitude

Definition:

The smallest fault magnitude of a given Fault Class at which the Detector Under Test achieves a stated Detection Coverage.¶

Discussion:

This term characterizes detector sensitivity. It is obtained by repeating trials at decreasing magnitude until coverage falls below the stated level. The coverage level used MUST be reported with the value.¶

Measurement Units:

The units of the affected indicator.¶

Issues:

Detection Threshold Magnitude approaches the baseline variability of the affected indicator as a lower bound. A reported value at or below baseline variability indicates that the trial was not correctly configured.¶

See Also:

Detection Coverage; Baseline Interval.¶

6.4. Boundary Masking

Definition:

The reduction in observed fault magnitude between the Fault Injection Point and the Observation Point.¶

Discussion:

A fault injected at the Model Engine may be partly or wholly suppressed by output filtering before it reaches an Application Gateway Observation Point. Boundary Masking quantifies that suppression. A masking value near one indicates that the intervening components absorb the fault, and that detection at the Observation Point characterizes those components as much as the detector.¶

Measurement Units:

A fraction between zero and one.¶

See Also:

Observation Point; Fault Injection Point.¶