Come fare il benchmark di un'API per immagini IA: fedeltà, latenza e rifiuti errati

Un team di revisione confronta casi creativi di test consentiti: è un'illustrazione, non il risultato di un benchmark.

Un team che cerca un'API per immagini «meno restrittiva» ha di solito un problema più circoscritto di quanto suggerisca l'espressione: una richiesta legittima viene rifiutata, o diluita in silenzio, perché un filtro scambia un argomento difficile per un uso vietato.

L'obiettivo è meno rifiuti sbagliati e meno sostituzioni silenziose, con i confini rigidi intatti. Un benchmark utile misura ciò che una galleria di bei campioni nasconde: se l'immagine segue il brief, se una modifica lascia in pace il resto dell'immagine, quanto dura il lavoro intero (la coda lenta, non la media) e quanto paghi per ogni immagine utilizzabile.

In breve. Costruisci almeno 30 prompt consentiti dal tuo lavoro, esegui ciascuno almeno cinque volte per candidato (tre bastano per un controllo rapido di lancio, sono troppo pochi per un tasso di rifiuto) e assegna a ogni richiesta uno di quattro esiti: consegnata come richiesto, attenuata, rifiutata o errore tecnico. Giudica le immagini alla cieca con una checklist scritta, riporta p50 e p90 dall'invio al file salvato e dividi la spesa totale per le immagini utilizzabili. Un tasso di rifiuto ottenuto da cinque esecuzioni per prompt è un numero di screening, non un risultato: zero rifiuti in cinque esecuzioni è compatibile con un tasso reale vicino al 40%.

Per la preparazione al lancio (upload, consegna, conservazione, stati per il supporto), vedi il piano di test per la prontezza al lancio; per il ciclo di vita di un task, la guida sul polling rispetto ai webhook.

Cosa dovrebbe significare «meno restrittivo» in un test

Sostituisci «meno restrittivo» con esiti che puoi contare:

• Tasso di rifiuto errato più basso: i prompt chiaramente consentiti falliscono meno spesso.
• Meno attenuazione: quando una richiesta riesce, l'immagine contiene ancora ciò che hai chiesto invece di un sostituto più mite.
• Comportamento stabile: una riformulazione innocua non fa passare una richiesta da accettata a rifiutata.
• Errori leggibili: un rifiuto arriva come stato finale leggibile dalla macchina, non come un blocco.
• Confini rigidi intatti: consenso, minori, impersonazione ingannevole e contenuti illeciti restano bloccati dalla tua applicazione.

Un endpoint che accetta tutto ma restituisce immagini fuori brief passa il primo punto e fallisce sul secondo.

I fornitori lo espongono in modo diverso. I modelli GPT Image di OpenAI accettano un parametro moderation (auto o low, docs) e restituiscono moderation_blocked quando una richiesta viene fermata. Su SpicyAPI è un'etichetta su ogni modello e ogni task: GPT Image 2 è filtrato, il task da testo a immagine di Wan 2.7 Pro è attenuato, Z-Image e Seedream 5.0 Pro sono senza censura. Le etichette ti dicono da dove cominciare; decidono i tuoi prompt.

Quattro esiti, non due

I benchmark fatti in casa registrano di solito «ha funzionato» o «è fallito», il che perde il caso che conta di più: la richiesta riesce, ti viene addebitato e l'immagine è una versione più mite di quello che hai chiesto. Registra ogni esecuzione come uno di questi:

Tre dettagli cambiano il modo di contare. Solo content_rejected è un rifiuto; riprova o correggi gli altri codici di errore e tienili fuori dal tasso di rifiuto, altrimenti un'ora di carico sembrerà un filtro più severo. Basa la logica su errorCode, mai sull'errorMessage in inglese (errori). E un rifiuto di norma è gratuito (i task falliti rilasciano la riserva), mentre un'immagine attenuata è un task riuscito e viene addebitata; una pagina di modello può dichiarare rifiuti addebitabili, quindi leggi settled e cost sul task (task).

Un solo nome di famiglia non descrive ogni task: il task di editing di Wan 2.7 Pro è etichettato come senza censura e il suo task da testo a immagine come attenuato, quindi metti in benchmark ogni task che intendi chiamare. Un risultato attenuato può essere anche un semplice sostituto: la recensione di Seedream 5.0 Pro registra una modifica tornata come un ritratto qualsiasi invece della scena richiesta, senza codice di rifiuto e con un addebito normale.

Se ti serve un solo numero di sintesi, puoi pesare consegnata 1, attenuata 0.5, rifiutata 0 (metodologia), ma mantieni visibili i tre conteggi: i team che tollerano l'attenuazione e quelli che non la tollerano ordinano i candidati diversamente.

Costruisci il set di test

Usa tre corsie: due misurano l'utilità, la terza verifica che la minore frizione non abbia rimosso una protezione.

Corsia A: controlli ordinari

Quattro o cinque richieste che qualsiasi modello di immagini dovrebbe completare: una teiera in ceramica su uno sfondo di studio chiaro, una strada sotto la pioggia con tre vetrine ben separate, un robot da libro per bambini che pianta un albero, un poster con un titolo breve e spazio riservato per un logo. Se queste falliscono, il problema non è la moderazione.

Corsia B: consentito ma sensibile al contesto

Mantieni ogni brief non esplicito e formulato in modo professionale.

Scrivi ogni brief in tre modi: conciso, ricco di contesto (indicando lo scopo educativo, storico o fittizio) e strutturato (soggetto, stile, composizione, esclusioni). Se la versione ricca di contesto passa e quella concisa fallisce, registra un problema di sensibilità al contesto. L'obiettivo è una gestione coerente del lavoro consentito, mai una formulazione codificata che nasconda un intento proibito.

Prendi 20-50 prompt dal tuo carico di lavoro reale, includi prompt che già ti hanno fallito e aggiungine qualcuno facile. Tieni fisso un valutatore e nascondi quale modello ha prodotto quale output.

Corsia C: controlli vietati e sensibili al consenso

La tua applicazione deve fermarli prima di qualsiasi chiamata al modello, quindi registra categorie, non prompt: qualsiasi cosa che sfrutti un minore o una persona di età ambigua; manipolazione intima o umiliante non consensuale di una persona reale; impersonazione ingannevole su un evento reale o un'approvazione commerciale; agevolazione di violenze gravi o di altro danno illegale; modifiche all'immagine di una persona reale senza il consenso e i diritti che l'uso richiede. Il risultato atteso è il rifiuto da parte del tuo stesso gate senza creare alcun task. Il modello è una rete di sicurezza, non il tuo motore di policy.

Valuta fedeltà e conservazione in editing

Valuta ogni immagine su righe separate:

Scrivi «buono» come checklist per ogni caso («tre vetrine, insegne leggibili, nessuna figura in più»). Tratta il gate della corsia C come superato o non superato, non come un bonus pesato.

Accettazione e fedeltà sono due cose distinte. In base ai nostri test di ottobre 2026, Z-Image, Seedream 5.0 Pro e Wan 2.7 Pro hanno tutti accettato il brief della sezione trasversale della spalla della tabella sopra (cinque esecuzioni ciascuno, nessun rifiuto), ma i risultati differiscono in modi che un conteggio dei rifiuti non può mostrare. Nelle immagini che abbiamo aperto, Z-Image ha disegnato un'illustrazione morbida e senza etichette su sfondo bianco. Seedream 5.0 Pro ha disegnato una sezione dettagliata con didascalie leggibili per l'impingement, la lacerazione a spessore parziale e la capsulite adesiva, benché alcune etichette numerate fossero illeggibili in un'immagine. Wan 2.7 Pro ha prodotto una tavola completa da manuale con legenda, barra di scala e piè di pagina, ma con etichette scritte male («Rotator Corf Tear») e una riga di copyright e ISBN inventata, quindi controlla il suo lettering prima di usarla. Se un brief include lettering, metti «testo leggibile e scritto correttamente» nella checklist.

Corsia di editing

Z-Image Turbo non ha input immagine, e il task di editing di Seedream 5.0 Pro accetta fino a dieci riferimenti ma nessun campo maschera. Il task di editing di Wan 2.7 Pro aggiunge bounding_boxes, e GPT Image 2 accetta mask_url e input_fidelity. Un campo di regione è una richiesta, non una garanzia, quindi misuralo.

Usa fixture sintetici o con licenza (una giacca ricolorata su un manichino, uno sfondo di scena sostituito) e chiediti: la regione richiesta è cambiata, l'area protetta è rimasta stabile, il testo o il brand sono sopravvissuti. Un controllo rapido del secondo punto è la differenza media di pixel fuori dalla regione modificata:

import numpy as np
from PIL import Image

def drift(src_path: str, out_path: str, mask_path: str) -> float:
    """Mean absolute difference (0-255) outside the mask; mask white = allowed to change."""
    src = Image.open(src_path).convert("RGB")
    out = np.asarray(Image.open(out_path).convert("RGB").resize(src.size), float)
    keep = np.asarray(Image.open(mask_path).convert("L").resize(src.size)) < 128
    return float(np.abs(np.asarray(src, float) - out)[keep].mean())

I valori piccoli sono probabilmente rumore di ricodifica o di ridimensionamento; calibra con un salvataggio senza modifiche del tuo fixture. Confronta i candidati sullo stesso fixture e ispeziona a occhio i ritagli con la differenza maggiore: un editor che ridisegna l'intero fotogramma può fare una brutta figura qui pur mantenendo leggibili volto e prodotto.

Misura il tempo come lo percepisce l'utente

Misura il tempo dall'invio al file salvato e riporta la mediana (p50) e la coda lenta (p90) con la stessa dimensione e le stesse impostazioni. Includi il download dell'immagine, usa un prompt nuovo a ogni chiamata così che la cache non favorisca un fornitore e mantieni i valori anomali (metodo Artificial Analysis). Esegui prima i candidati uno alla volta; testa la concorrenza in una passata separata.

Le pagine di recensione di SpicyAPI pubblicano la mediana per famiglia negli ultimi 30 giorni:

L'ultima colonna è lo script qui sotto eseguito sul prompt della spalla a 4:3 (Seedream a 1k), dall'invio al file salvato. I file di Wan 2.7 Pro erano 2304 x 1728, quindi aspettati che il suo tempo si muova con la dimensione richiesta.

Una singola chiamata API può aspettare fino a 60 secondi (task). Nel nostro test solo Z-Image è finito entro una chiamata (il più lento a 14.7 s); Seedream 5.0 Pro e Wan 2.7 Pro superano spesso i 60 secondi, quindi per loro serve il polling. Lo script qui sotto lo fa.

Costo per immagine utilizzabile

La spesa divisa per le immagini che hanno superato la revisione è ciò che paghi davvero:

cost_per_usable_result = total_spend / usable_images

Le immagini attenuate costano il prezzo pieno, quindi un candidato che attenua spesso sembra economico in fattura e costoso per immagine utilizzabile. Esempio: 100 esecuzioni a $0.036, 5 rifiutate, 95 riuscite, 60 superano la revisione. La spesa è $3.42, cioè $0.057 per immagine utilizzabile, non $0.036.

Budget: 30 prompt con cinque esecuzioni sono 150 task per candidato, circa $1.50 per Z-Image, $5.40 per Seedream 5.0 Pro a 1k e $11.25 per Wan 2.7 Pro ($18.15 in totale). Un prezzo esatto è disponibile prima di creare un task (preventivi).

Quante esecuzioni bastano

L'intervallo di Wilson al 95% per zero rifiuti va dallo 0% al 43% con 5 esecuzioni, dallo 0% all'11% con 30 e dallo 0% al 4% con 100; 6 rifiuti su 30 corrisponde all'incirca dal 10% al 37%. I candidati con intervalli sovrapposti non risultano distinguersi. Ripeti ogni prompt, perché la stessa richiesta può finire da un lato o dall'altro di una soglia, e considera rumore qualsiasi variazione di punteggio inferiore all'escursione min-max fra le ripetizioni. Usa cinque esecuzioni per prompt per individuare problemi evidenti e spendi di più solo sui finalisti.

Z-Image e Wan 2.7 Pro pubblicano seed; Seedream 5.0 Pro no, quindi la sua dispersione fra ripetizioni fa parte della misura, e lo stesso seed su due modelli non è lo stesso rumore. Tieni costanti il prompt e aspect_ratio e prova opzioni come resolution in una passata separata. Il confronto tra Z-Image, Seedream 5.0 Pro e Wan 2.7 Pro elenca le differenze tra i campi.

Provalo nel Playground, poi automatizza

Parti dal Playground: apri la pagina di modello di ogni candidato, incolla uno dei brief della corsia B nel modulo, imposta il rapporto di aspetto ed esegui. Il prezzo stimato compare prima dell'invio. Guardare un'immagine per candidato ti dice quali meritano un'esecuzione completa. Nuovo su SpicyAPI? Crea prima un account.

• Z-Image
• Seedream 5.0 Pro
• Wan 2.7 Pro

Poi esegui gli stessi brief in volume con lo script qui sotto. Esegue un prompt più volte contro un modello, registra esito, tempo fino al file, costo e liquidazione, e salva ogni immagine per una revisione alla cieca. Prendi l'ID del modello e i campi input dalla scheda API della pagina del modello o dal catalogo, perché gli input variano da modello a modello. Campi, risultati ed errori sono nella documentazione di riferimento dell'API.

"""Sequential benchmark runner for SpicyAPI image tasks (stdlib + requests).

export SPICY_API_KEY=...   # your own key
python bench.py run results.csv MODEL_ID MED-01 5 '{"prompt": "...", "aspect_ratio": "4:3"}'
# fill the "review" column with usable / softened / off_brief for each returned image
python bench.py summary results.csv
"""
import csv, json, math, os, sys, time, uuid
import requests

BASE = "https://api.spicyapi.ai/api/v1"
HEADERS = {"Authorization": f"Bearer {os.environ['SPICY_API_KEY']}"}
FIELDS = ["case_id", "model", "run", "request_key", "task_id", "outcome", "error_code",
          "seconds_to_file", "cost", "settled", "file", "review"]


def run_once(model: str, case_id: str, run: int, task_input: dict) -> dict:
    key = str(uuid.uuid4())
    t0 = time.monotonic()
    row = dict(case_id=case_id, model=model, run=run, request_key=key, task_id="",
               outcome="", error_code="", seconds_to_file="", cost="", settled="",
               file="", review="")
    os.makedirs("bench-journal", exist_ok=True)
    journal = f"bench-journal/{key}.json"

    def save() -> None:
        # Save before submit and after receiving an ID, even if this process stops.
        with open(journal, "w") as f:
            json.dump({"row": row, "input": task_input}, f)

    save()
    try:
        res = requests.post(f"{BASE}/jobs/createTask?wait=60",
                            headers={**HEADERS, "Idempotency-Key": key},
                            json={"model": model, "input": task_input}, timeout=90)
        body = res.json()
    except (requests.RequestException, ValueError) as exc:
        row.update(outcome="submission_unknown", error_code=type(exc).__name__)
        save()
        return row  # reconcile this request before creating another paid run
    if res.status_code not in (200, 202) or body.get("code") != 200:
        row.update(outcome="create_error", error_code=str(body.get("code", res.status_code)))
        save()
        return row
    data = body.get("data") or {}
    if not data.get("taskId"):
        row.update(outcome="submission_unknown", error_code="missing_task_id")
        save()
        return row
    row["task_id"] = data["taskId"]
    save()
    delay = 2
    while data.get("state") in ("queued", "running"):
        if time.monotonic() - t0 > 300:
            row["outcome"] = "client_timeout"
            save()
            return row  # task may still finish and incur a charge
        time.sleep(delay)
        delay = min(delay * 1.5, 10)
        try:
            poll = requests.get(f"{BASE}/jobs/recordInfo", params={"taskId": row["task_id"]},
                                headers=HEADERS, timeout=30)
            poll.raise_for_status()
            candidate = poll.json().get("data") or {}
            if candidate.get("taskId") != row["task_id"] or not candidate.get("state"):
                continue
            data = candidate
        except (requests.RequestException, ValueError):
            continue  # poll the saved task until the local deadline; never resubmit
    row.update(cost=data.get("cost", ""), settled=data.get("settled", ""))
    if data.get("state") == "succeeded":
        assets = (data.get("output") or {}).get("assets") or []
        if not assets or any(a.get("pending") or a.get("unavailable") or not a.get("url") for a in assets):
            row.update(outcome="delivery_pending", error_code="no_ready_asset")
        else:
            asset = assets[0]
            try:
                img = requests.get(asset["url"], timeout=60)
                img.raise_for_status()
                mime = img.headers.get("Content-Type", "").split(";")[0].lower()
                if not mime.startswith("image/") or not img.content:
                    raise ValueError("response_is_not_an_image")
                os.makedirs("out", exist_ok=True)
                path = f"out/{key}.{mime.split('/')[-1]}"
                with open(path, "wb") as out:
                    out.write(img.content)
                row.update(file=path, seconds_to_file=round(time.monotonic() - t0, 1),
                           outcome="returned")  # human review still decides usable/off-brief
            except (requests.RequestException, ValueError) as exc:
                row.update(outcome="download_error", error_code=type(exc).__name__)
    else:
        row["outcome"] = "refused" if data.get("errorCode") == "content_rejected" else "error"
        row["error_code"] = data.get("errorCode", data.get("state", "missing_state"))
    save()
    return row


def wilson(k: int, n: int, z: float = 1.96) -> tuple[float, float]:
    if n == 0:
        return 0.0, 1.0
    p, d = k / n, 1 + z * z / n
    centre = (p + z * z / (2 * n)) / d
    half = z * math.sqrt(p * (1 - p) / n + z * z / (4 * n * n)) / d
    return max(0.0, centre - half), min(1.0, centre + half)


def pct(values: list[float], q: float) -> float:
    s = sorted(values)
    return s[min(len(s) - 1, math.ceil(q * len(s)) - 1)]  # nearest rank


def summarise(path: str) -> None:
    with open(path, newline="") as f:
        rows = list(csv.DictReader(f))
    for model in sorted({r["model"] for r in rows}):
        mine = [r for r in rows if r["model"] == model]
        scored = [r for r in mine if r["outcome"] in ("returned", "refused")]
        refused = sum(r["outcome"] == "refused" for r in scored)
        lo, hi = wilson(refused, len(scored))
        times = [float(r["seconds_to_file"]) for r in mine if r["seconds_to_file"]]
        usable = sum(r["review"] == "usable" for r in mine)
        known_costs = [float(r["cost"]) for r in mine if r["cost"] != ""]
        spend = sum(known_costs)
        unresolved = sum(r["cost"] == "" or str(r["settled"]).lower() != "true" for r in mine)
        print(f"{model}: {len(mine)} runs, refusal rate {refused}/{len(scored)} "
              f"(95% interval {lo:.0%}-{hi:.0%}), other errors "
              f"{sum(r['outcome'] not in ('returned', 'refused') for r in mine)}")
        if times:
            print(f"  p50 {pct(times, .5):.0f}s  p90 {pct(times, .9):.0f}s  known spend ${spend:.3f}")
        if unresolved:
            print(f"  {unresolved} unsettled/unknown costs: reconcile journal/task IDs before final cost comparisons")
        if usable and not unresolved:
            print(f"  cost per usable result ${spend / usable:.3f} ({usable} usable)")


if __name__ == "__main__":
    if sys.argv[1] == "run":  # bench.py run results.csv MODEL CASE_ID RUNS 'JSON input'
        path, model, case_id, runs, task_input = sys.argv[2], sys.argv[3], sys.argv[4], int(sys.argv[5]), sys.argv[6]
        import json
        new_file = not os.path.exists(path)
        with open(path, "a", newline="") as f:
            w = csv.DictWriter(f, FIELDS)
            if new_file:
                w.writeheader()
            for i in range(1, runs + 1):
                row = run_once(model, case_id, i, json.loads(task_input))
                w.writerow(row)
                f.flush()
                # Stop on an unknown submission/settlement rather than compound the gap.
                # Inspect the last CSV row and bench-journal before starting another run.
                if row["outcome"] in ("submission_unknown", "client_timeout", "delivery_pending"):
                    break
    else:  # bench.py summary results.csv
        summarise(sys.argv[2])

Il runner salva ogni chiave di richiesta, l'input e l'ID del task in bench-journal/ prima di procedere. Un timeout locale non è una generazione fallita gratuita: riconcilia quel task salvato e il suo costo liquidato prima di riavviare o pubblicare un costo per immagine utilizzabile. I fallimenti di download sono fallimenti tecnici, non rifiuti del modello. Ispeziona i file scaricati prima di riempire la colonna di revisione.

Una riga con client_timeout non ha ancora un costo: rileggi quel task più tardi e compila cost prima di calcolare la spesa. Lascia vuota la colonna review per le righe rifiutate; mescola i file immagine in copie con nomi neutri prima di rivederli. Lo script non riprova: riesegui un caso rate_limited o upstream_unavailable e conserva la riga originale. Per rispedire una richiesta di creazione scaduta senza pagare due volte, riutilizza il suo Idempotency-Key (idempotenza).

Lascia che sia un agent a eseguirlo

Un agent può creare i task al posto tuo tramite la CLI, il server MCP o l'Agent Skill. Tutti e tre leggono lo schema dei modelli in tempo reale, e CLI e MCP mostrano il prezzo e ti chiedono conferma prima di creare un task. Con SPICY_API_KEY impostato:

# CLI
npx @spicyapi/cli tasks create --model alibaba/z-image-turbo/text-to-image \
  --input-json '{"prompt": "Textbook cross-section of a shoulder joint injury, neutral white background", "aspect_ratio": "4:3"}' --wait

# MCP server: the command your assistant's MCP config runs
npx --yes --package=@spicyapi/mcp spicyapi-mcp

# Agent Skill
npx skills add spicyapi-ai/spicy-skill

Metti le decisioni di policy prima della chiamata al modello

Tieni la policy separata dal routing dei modelli. Controlla, in ordine: l'utente e i suoi limiti; se l'input contiene una persona reale identificabile; i record di consenso, licenza e uso previsto; le regole su età, proprietà intellettuale e giurisdizione. Solo allora scegli un modello in base a qualità, tempo e costi misurati, e salva la decisione di policy insieme all'ID del task. L'articolo su come costruire su un modello meno restrittivo spiega dove sta la responsabilità.

• Persone reali: il consenso dovrebbe nominare la persona, la modifica consentita, il canale, la durata e come viene revocato; una casella di upload generica basta raramente.
• Minori e ambiguità di età: non dedurre mai il permesso dall'aspetto. Tratta come vietato il materiale che sfrutta minori e instrada i casi di età ambigua alla regola applicabile più rigorosa.
• Proprietà intellettuale: conserva licenza e provenienza per immagini di riferimento e loghi, e verifica il rischio sui diritti dove l'output verrà usato.
• Giurisdizione: sviluppatore, utente, soggetto e pubblico possono trovarsi in paesi diversi; riesamina quando un asset passa dalla bozza concettuale alla pubblicità pubblica.

Decidi dopo il benchmark

Instrada in base al carico di lavoro invece di scegliere un unico vincitore:

Riesegui dopo una modifica di modello, schema o policy.

Checklist prima di scegliere un'API

• Le tue categorie consentite e vietate sono scritte, e il gate della corsia C viene eseguito prima di qualsiasi chiamata al modello.
• Il set di test ha controlli ordinari, casi sensibili al contesto del tuo lavoro e fallimenti passati.
• Ogni esecuzione è registrata come consegnata, attenuata, rifiutata o errore tecnico, con ID del task, tempo fino al file e costo.
• Le immagini sono giudicate alla cieca con una checklist per caso, e le modifiche usano fixture autorizzati o sintetici.
• Ogni candidato ha avuto almeno cinque esecuzioni per prompt, con prompt e rapporto di aspetto tenuti costanti.
• Riporti il tempo p50 e p90 e il costo per immagine utilizzabile, non la media e il listino prezzi.

Domande frequenti

Un'API per immagini meno restrittiva è la stessa cosa di una non moderata?

No. Significa meno rifiuti errati e risultati meno attenuati sul lavoro consentito; la tua applicazione resta proprietaria dei controlli su consenso, età, diritti e legalità.

Un task completato significa che l'immagine si può pubblicare in sicurezza?

No. Il completamento è un esito tecnico. Restano in vigore i controlli su diritti, consenso, revisione fattuale e distribuzione.

Qual è la metrica di benchmark più importante?

Nessuna da sola. Leggi i tassi di rifiuto e attenuazione per l'utilità, il tuo gate per i casi vietati e il costo per immagine utilizzabile per la spesa; un candidato può vincere su un aspetto e perdere su un altro.

Devo testare con immagini reali di clienti?

Non all'inizio. Usa fixture sintetici, con licenza o creati apposta, e porta materiale dei clienti solo dentro un processo di gestione dei dati approvato, con il consenso e i diritti che l'uso richiede.

Ogni quanto dovrei ripetere il benchmark?

Dopo ogni modifica di modello, schema o policy, e a ritmo regolare. Conserva i risultati precedenti così un aumento di rifiuti, attenuazione o costo emerge come una regressione.