chimera-when-two-results-contradict-suspect-the-apparatus
Quando due tue misurazioni divergono di un margine che nessun meccanismo potrebbe produrre, il difetto è nello strumento. Verifica l'harness prima di costruirci sopra una teoria.
Conferita da chi ha letto la scheda, non rivendicata dal file su se stesso. Una scheda che l'agente distilla durante un'esecuzione che ha consumato contenuti non affidabili nasce contaminata e resta in attesa di revisione prima di essere mai recuperata.
Quando viene in mente
- due esecuzioni divergono enormemente
- l'esecuzione più piccola ha fatto meglio
- una metrica si muove in direzione impossibile
- spiego un risultato di benchmark sorprendente
Il valore di solito sta in Evita e Verifica. Fai è la sezione che scrivono tutti.
Il corpo della scheda qui sopra è una traduzione. L'originale inglese è ciò che la CLI importa, ciò che l'agente legge in esecuzione e ciò che l'hash qui sotto attesta.
Trigger
Due misurazioni prodotte da te divergono di una quantità che non riesci a spiegare: l'esecuzione con una frazione dei dati ottiene un punteggio migliore di quella grande; un componente segna 0% su un task che una misurazione adiacente lo mostra fare di routine; una modifica sposta un numero nella direzione che essa stessa rende impossibile.
L'innesco è la dimensione del divario, non la sua esistenza. Due esecuzioni che differiscono dentro la loro banda di rumore sono una questione di campionamento, e questa card non ha nulla da dire al riguardo. Non si applica nemmeno al tuo numero contro un numero pubblicato da qualcun altro — dati, prompt, seed e versioni diversi spiegano quelli tutto il giorno, e trattarlo come un allarme sull'apparato ti porterà a fare l'audit di un harness che sta benissimo. Il caso qui è: entrambi i lati della contraddizione sono tuoi, ed entrambi non possono essere veri.
Fai
- Scrivi prima di tutto la contraddizione, in due righe: i due numeri, e i comandi e i commit esatti che li hanno prodotti. Smetti di teorizzare finché non è sulla pagina — una contraddizione non scritta viene ammorbidita in un rompicapo nel giro di circa un paragrafo.
- Fai il diff delle due esecuzioni prima di ragionarci sopra: configurazione, commit, percorso di codice, hash del file di input, versione dello scorer. Preferisci un diff che puoi leggere a una spiegazione che puoi costruire.
- Fai passare risposte note attraverso la misurazione stessa. Esegui le soluzioni di riferimento/gold attraverso il tuo grader prima di fidarti di qualsiasi punteggio di un modello. Se una risposta notoriamente corretta viene valutata come fallimento, il difetto è nel grader e ogni numero che ha prodotto è nullo, compreso quello che ti piaceva.
- Solo una volta che l'apparato sopravvive al passo 3 spendi energie a spiegare il fenomeno.
- Se la colpa era dell'apparato, ritratta i numeri invece di reinterpretarli. Un punteggio prodotto da uno scorer rotto non è una stima rumorosa della verità; non ha alcuna relazione con essa.
Evita
Costruire diverse ipotesi accurate per spiegare entrambi i numeri e poi testarle con rigore. È la versione costosa di questo errore: il rigore è reale, lo sforzo è reale, e tutto quanto viene misurato su un artefatto. La qualità del metodo a valle di uno strumento rotto ti porta solo alla risposta sbagliata con barre d'errore migliori.
Evita di riconciliare con l'aritmetica — facendo la media dei due, o tenendo in silenzio quello che coincide con ciò che ti aspettavi. Evita un grader a mondo chiuso, che è il bug specifico che produce più spesso questa forma:
# and the score then reads as "the model cannot do this at all"
CITIES = {"lisbon", "porto"}
ok = answer.lower() in CITIES
# yes — grade against a rule that the real world can satisfy
ok = geocode(answer) == geocode(expected)
Ed evita la frase "dev'essere un caso" come punto d'arrivo. È un'ipotesi sull'apparato, quindi è testabile — testala o abbandonala.
Verifica
Una frase, ad alta voce, con dentro un ordine di grandezza: "X produce una differenza così grande perché …". Se non riesci a finirla — "dieci volte meno dati che producono un punteggio migliore perché …" — l'indiziato è lo strumento, e il passo 3 è dove vai adesso.
Poi quella binaria: le risposte gold hanno superato il grader? Ogni elemento gold che il grader segna come sbagliato è un tetto su ciò che la misurazione avrebbe mai potuto significare, e la frazione di essi che fallisce è il primo numero da riportare.
Rischio
A volte la contraddizione è reale e il risultato sorprendente è la scoperta. Il riflesso di dare la colpa all'harness scarta proprio quelle e — peggio — è esattamente la mossa a disposizione di chiunque voglia far sparire una misurazione scomoda. Quindi ponile un limite: il controllo dell'apparato è una lista fissa e breve (diff delle esecuzioni, gold attraverso il grader, conferma degli hash degli input). Se quella lista torna pulita, credi alla contraddizione e vai a indagare il fenomeno. Questa card ordina il lavoro; non sceglie la risposta.
Il secondo costo è ricorsivo. Codice nuovo scritto per controllare il codice vecchio è un'altra cosa che può essere sbagliata, e uno script di audit bacato ha ora prodotto un terzo numero. Preferisci controlli che usano artefatti che hai già e input le cui risposte sono note, rispetto a un harness nuovo scritto sotto la pressione di un'anomalia.
Come usarla
La scheda è un dato. Clona il repository e importala per percorso — ciò che arriva dalla rete è trattato come contaminato e trattenuto in attesa di approvazione, che è il comportamento desiderabile e il motivo per cui qui non c'è un installatore in una riga.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-when-two-results-contradict-suspect-the-apparatus/SKILL.mdIntegrità
SHA-256 del file così com'è pubblicato. Chi lo importa può verificare che ciò che ha ricevuto sia ciò che questa pagina mostrava.
c33d19c446e5da887d8aee039d0e58690472bd2db3c6d8322497b6cebfbb62bf