OSEF: One-Step Evidence Fusion for Cross-Video Scene Procedure Planning

Sintesi Tecnica: OSEF: One-Step Evidence Fusion per la Pianificazione di Procedure di Scena Cross-Video

1. Definizione del Problema: Pianificazione di Procedure di Scena Cross-Video (CVSPP)

Il documento affronta una lacuna nei sistemi esistenti di Pianificazione di Procedure di Scena Video (VSPP). I sistemi VSPP tradizionali assumono che il video di evidenza corretto e la finestra temporale siano forniti come input per predire una sequenza di azioni che trasformi una scena iniziale in una scena obiettivo. In scenari pratici, tuttavia, l'evidenza corretta non è disponibile; un sistema deve prima recuperare il video corretto da un set di candidati e localizzare la finestra temporale rilevante prima di pianificare.

Gli autori introducono la Pianificazione di Procedure di Scena Cross-Video (CVSPP) come un compito benchmarked in cui un modello riceve:

1. Una query legale: una descrizione testuale di una transizione start-goal con le risposte oscurate (es. "inizio: patate crude; obiettivo: patatine fritte dorate servite") senza rivelare l'ID del video, i timestamp o la sequenza di azioni.
2. Un set di candidati ($K$ video), ciascuno diviso in $M$ celle temporali.

Il modello deve simultaneamente:

• Recuperare (Retrieve) il video di supporto corretto.
• Localizzare la finestra temporale rilevante all'interno di quel video.
• Pianificare la sequenza ordinata di azioni a set chiuso che colma il divario tra gli stati iniziale e obiettivo.

Il compito è definito da due sfide accoppiate:

• Ambiguità dell'evidenza per lo stesso task (Same-task Evidence Ambiguity): Più video candidati possono dimostrare la stessa procedura nominale con stadi quasi identici e finestre adiacenti, rendendo insufficiente il condizionamento basato solo sul nome del task.
• Propagazione dell'errore dal Recupero alla Pianificazione (Retrieval-to-Plan Error Propagation): Nei classici sistemi a cascata "recupera-e-pianifica", una selezione precoce e rigida (hard selection) del video o della finestra errata trasmette una catena di scene incorretta al pianificatore, causando il fallimento irreversibile della perdita di pianificazione.

2. Metodologia: One-Step Evidence Fusion (OSEF)

Per affrontare queste sfide, gli autori propongono One-Step Evidence Fusion (OSEF), un framework che ritarda l'impegno irreversibile sull'evidenza. Invece di selezionare un singolo video e ritagliare una finestra prima della pianificazione, OSEF valuta tutte le celle candidate e alimenta il pianificatore con la rappresentazione completa dell'evidenza "soft" in un unico percorso differenziabile.

L'architettura consiste in tre componenti principali:

1. Query-Conditioned Evidence Lattice (Reticolo di Evidenza Condizionato dalla Query):

   • Il modello valuta ogni cella $(k, m)$ in un reticolo di $K \times M$ candidati rispetto alla query legale $q$.
   • Un "lift" simmetrico privo di parametri costruisce intervalli chiusi validi $(i \le j)$ per formare un reticolo di punteggi $H_\theta(q, k, i, j)$.
   • L'argmax di questo reticolo determina il video riportato e l'intervallo localizzato per la valutazione, ma il percorso del pianificatore mantiene tutte le $K \times M$ celle.

2. Token-Global Evidence-to-Plan (E2P) Adapter:

   • Questo componente evita la perdita di segnali a livello di cella che si verifica nella standard pooling.
   • Appiattisce l'intero reticolo $K \times M$ (senza ritaglio) e lo elabora attraverso un encoder Transformer a singolo strato.
   • $2T$ query di endpoint apprese (che rappresentano gli stati iniziale e finale per ciascuno dei $T$ step) effettuano una cross-attention su tutte le celle del reticolo.
   • Ciò produce un tensore di catena di stati di scena ($B \times T \times 2 \times d_v$) dove l'evidenza di ogni candidato rimane disponibile per il pianificatore, anche se la selezione hard tramite argmax è errata.

3. Goal-Conditioned Planner (Pianificatore Condizionato dall'Obiettivo):

   • Un Transformer a tre strati mappa le coppie di stati in logit per azione per ogni step.
   • La query legale condiziona il pianificatore tramite due meccanismi: un'affine scale/shift in stile FiLM sugli stati dei token e come un token distinto prepennato per l'attenzione.
   • Una testa condivisa decodifica i $T$ step.

Obiettivo di Addestramento:
Il modello utilizza la Joint-Cascade Supervision. La perdita ($L_{JC}$) combina la perdita di cross-entropy del piano generato dalla catena soft globale ($\hat{S}$) con una somma pesata delle perdite dei piani generati dalle singole catene candidate ($S_k$), pesate dalla probabilità di recupero $p_k$. Ciò consente alla perdita di pianificazione di rimodellare la rappresentazione dell'evidenza.

3. Costruzione del Benchmark

Gli autori hanno costruito un benchmark partendo da 11 fonti di video istruttivi (3 benchmark di pianificazione nativi: COIN, CrossTask, NIV; e 8 fonti convertite come YouCook2, Ego4D, ecc.).

• Audit della Query Legale: Un controllo "fail-closed" garantisce che le query non contengano fughe di informazioni sulla verità di base (nessun ID video, timestamp o sequenza di azioni).
• Ruoli Negativi: Il benchmark include ruoli negativi tipizzati per testare specifici modi di fallimento: Video Errato (WV), Finestra Errata (WO) e Task Errato (WA).
• Metriche:
  • Asse dell'Evidenza: Exact-video R@1, MRR e span-IoU.
  • Asse del Piano: Per-step Mean Accuracy (MAcc) ed Exact-Sequence Success (PLAN-SR).
  • Metrica Completa: FULL-SR, ovvero la probabilità di recuperare correttamente il video, localizzare la finestra e predire simultaneamente l'esatta sequenza di azioni.

4. Risultati Chiave

Il documento valuta OSEF contro nove famiglie di pianificatori adattati (inclusi pianificatori latenti, grafici, generativi e a sequenza discreta) attraverso 14 celle sorgente-orizzonte.

• Prestazioni di Ranking: OSEF si posiziona primo su tutte le sei celle native (COIN, CrossTask, NIV) dove il ranking del metodo è valido.
• Guadagni di Prestazione: Su quattro celle con lo stesso task (COIN-T3/T4 e CrossTask-T3/T4), OSEF migliora il FULL-SR di 2,9 - 10,7 punti percentuali rispetto a un baseline SOTA potenziato basato su hard-selection.
• Analisi dei Componenti: Uno studio di ablazione rivela che l'interfaccia token-globale (mantenere tutte le celle invece di fare pooling) rappresenta il maggior incremento singolo nelle prestazioni. La sola soft pooling è insufficiente; la capacità di leggere l'intero reticolo tramite query apprese è critica.
• Modi di Fallimento:
  • Il recupero è quasi saturo sui candidati con task distinti per specifiche fonti (es. NIV-T3 raggiunge il 99,20% R@1), ma la pianificazione rimane il collo di bottiglia.
  • La localizzazione è debole; un piano corretto non garantisce una finestra corretta (il FULL-SR rimane alto anche quando lo span-IoU è basso).
  • Sulle fonti convertite con etichette grossolane (es. CEgo, TACoS), le prestazioni si collocano spesso vicino al "pavimento della sequenza maggioritaria" (majority-sequence floor), indicando che queste celle sono test di stress per la degenerazione delle etichette piuttosto che per il ranking dell'evidenza.

5. Significato e Rivendicazioni

Il documento afferma di essere il primo benchmark che valuta insieme recupero, localizzazione e pianificazione a partire da una query con risposte oscurate. La sua importanza risiede nel:

1. Formalizzare il Problema Accoppiato: Separa esplicitamente l' "ambiguità dell'evidenza per lo stesso task" dalla "propagazione dell'errore dal recupero alla pianificazione", dimostrando che le cascate di hard-selection sono fragili.
2. Introdurre la Soft Fusion: OSEF dimostra che mantenere l'evidenza "soft" su tutto il reticolo dei candidati e alimentarla al pianificatore tramite un adattatore token-globale supera significativamente i baseline di hard-selection.
3. Benchmark di Trasferimento: Fornisce un banco di prova rigoroso per capire come i pianificatori VSPP esistenti si trasferiscano quando l'evidenza non viene fornita, rivelando che la maggior parte dei pianificatori ereditati fallisce senza la specifica interfaccia OSEF.

Gli autori notano modestamente alcune limitazioni: l'attuale configurazione utilizza feature congelate e query deterministiche, e il costo del reticolo cresce con il numero di candidati ($K$). Identificano la decodifica fedele dello span e backbone più forti come sfide aperte. Il pacchetto supplementare include costruttori di modelli, codice di valutazione e audit per ogni cella.