xai-org/x-algorithm · error · ValueError

Unknown loss_type: {loss_type}

Error message

Unknown loss_type: {loss_type}

What it means

continuous_loss_compute supports a fixed set of loss_type strings for regression targets; the branches handle (per the source) absolute error and 'huber' (plus the preceding cases), and any other loss_type reaches the trailing ValueError. The loss is then normalized by num_loss_samples, so an unknown type cannot be silently defaulted.

Source

Thrown at phoenix/xrex/models/loss_recsys.py:88

    if mask_negatives:
        loss_mask = valid_mask & (~negative_sample_mask)
    else:
        loss_mask = valid_mask

    weights = loss_mask if raw_weights is None else loss_mask * raw_weights
    num_loss_samples = jnp.sum(weights)

    if loss_type == "mse":
        errors = (pred_norm - gt_norm) ** 2
    elif loss_type == "mae":
        errors = jnp.abs(pred_norm - gt_norm)
    elif loss_type == "huber":
        delta = 1.0
        abs_diff = jnp.abs(pred_norm - gt_norm)
        errors = jnp.where(abs_diff <= delta, 0.5 * abs_diff**2, delta * (abs_diff - 0.5 * delta))
    else:
        raise ValueError(f"Unknown loss_type: {loss_type}")

    loss = jnp.sum(errors * weights) / jnp.maximum(num_loss_samples, 1.0)

    return loss, gt_clamped, pred_in_original_units, loss_mask, errors


def tweedie_loss_compute(
    gt_raw: jax.Array,
    pred_raw: jax.Array,
    valid_mask: jax.Array,
    negative_sample_mask: jax.Array,
    p: float = 1.5,
    norm_scale: float = 300.0,
    mask_negatives: bool = True,
    raw_weights: jax.Array | None = None,
) -> tuple[jax.Array, jax.Array, jax.Array, jax.Array, jax.Array]:
    gt = jnp.clip(gt_raw.astype(jnp.float32), 0.0, norm_scale)
    pred = jnp.maximum(pred_raw.astype(jnp.float32), 1e-6)

View on GitHub (pinned to 24c60942c5)

Solutions

  1. Use one of the implemented loss_type values (check the if/elif arms in loss_recsys.py, e.g. 'huber').
  2. Match exact casing/strings from the config schema.
  3. Add a new elif branch implementing the loss if genuinely required.

Example fix

# before
loss_type: mse

# after
loss_type: huber
Defensive patterns

Strategy: validation

Validate before calling

assert loss_type in {"l1", "huber"}, f"Unknown loss_type: {loss_type}"  # mirror implemented branches

Type guard

def is_supported_loss(t: str, supported: set[str]) -> bool:
    return t in supported

Prevention

When it happens

Trigger: Calling loss()/continuous_loss_compute with loss_type like 'mse', 'l2', or a typo such as 'Huber' (case-sensitive) in the model config.

Common situations: Experiment configs renaming loss types; switching from another training framework whose loss names differ; case-sensitivity mistakes.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors


AI-assisted analysis of xai-org/x-algorithm@24c60942c5 (2026-08-28). Data as JSON: /api/errors/ac6e44e91623fae7. Report an issue: GitHub.