Auf dieser Seite
Die kurze Antwort
Eine Benchmark-Kontamination tritt auf, wenn Informationen über Testfälle das System auf eine Weise beeinflussen, die die beabsichtigte Messung untergräbt. Ein privater Satz reduziert einige Lecks, aber wiederholte Abstimmungen, gemeinsame Beispiele und während der Evaluierung erfasste Informationen können das Ergebnis dennoch beeinträchtigen.
Was zum Mitnehmen
- Entwicklungsfeedback von endgültigen Entscheidungsnachweisen trennen.
- Zeichnen Sie den Werkzeugzugriff und die während jedes Laufs verfügbaren Informationen auf.
- Offenlegen Sie die Unsicherheit über eine Kontamination, anstatt einen sauberen Test ohne Beweise zu deklarieren.
Quellen überprüft . Forschungssynthese und Rubrex-Empfehlungen. Beispiele und lokale Experimente sind gekennzeichnet; es handelt sich nicht um Kundenergebnisse.
Eine aktuelle Taxonomie erweitert die Frage
Ein Vorabdruck vom August 2026 ordnet die Kontamination nach den Abhilfemaßnahmen, die sie verhindern kann, einschließlich der während der Bewertung ermittelten Exposition. Sie meldet auch Einschränkungen in der Zuverlässigkeit von Teilen ihres Offenlegungsinstruments. Sein Beitrag ist eine Möglichkeit, schärfere Fragen zu stellen, und kein Detektor, der beweist, dass ein Benchmark unbelastet ist.
Beweis: Benchmark-Kontamination: Eine von Defeated Mitigation organisierte Taxonomie [1]
Verfolgen Sie, wie Auswertungsinformationen zum System gelangen können
Listen Sie die Orte auf, an denen Testmaterial erscheinen kann: Eingabeaufforderungen, abgerufene Dokumente, Beispiele für wenige Aufnahmen, Entwicklernotizen, Feinabstimmungsdaten, gemeinsame Gespräche und Tools. Ein Fall kann außerhalb des Modelltrainings bleiben und nach wiederholtem Debuggen dennoch in die Eingabeaufforderung der Anwendung integriert werden. Das ändert, was Erfolg in diesem Fall bedeutet.
Berücksichtigen Sie bei webfähigen Systemen auch, ob eine Testfrage direkt zu ihrer veröffentlichten Antwort führt. Dies kann für eine Abrufaufgabe legitim und für einen Anspruch auf Closed-Book-Fähigkeit ungültig sein. Je nach Bewertungsvertrag kann das gleiche Verhalten akzeptabel oder kontaminierend sein.
Verwenden Sie Steuerelemente, die dem beabsichtigten Anspruch entsprechen
Rubrex empfiehlt die Beibehaltung separater Entwicklungs-, Regressions- und Entscheidungssätze. Ein bekannter Fehler gehört in den Regressionstest, auch wenn die Ingenieure ihn gesehen haben. Ein zurückgehaltener Satz dient einem anderen Zweck: der Messung des Transfers über diese Fixes hinaus. Löschen Sie den Regressionswert nicht, nur weil ein Fall nicht mehr geheim ist.
Beschränken Sie den Zugriff auf den Entscheidungssatz, zeichnen Sie auf, wann er verfügbar gemacht wurde, und frieren Sie die Bewertungsregeln ein, bevor Sie den endgültigen Vergleich durchführen. Wenn Werkzeuge erlaubt sind, notieren Sie deren Zugriffsgrenzen. Neue Fragen sollten auf Ähnlichkeit mit früheren Beispielen und auf zufällige Hinweise in Identifikatoren oder Referenzdokumenten überprüft werden.
Anschauliches Beispiel: die auswendig gelernte Eskalation
Ein Team repariert einen Assistenten nach einer Support-Eskalation und fügt als Beispiel die genaue Interaktion zu seiner Eingabeaufforderung hinzu. Die nächste Auswertung besteht diese Interaktion. Dies ist ein nützliches Regressionsergebnis, aber ein schwacher Beweis dafür, dass der Assistent unbekannte Fälle der gleichen Art bearbeitet.
Erstellen Sie separate Fälle, die dieselbe zugrunde liegende Regel mit unterschiedlichen Beweisen, Formulierungen und Randbedingungen anwenden. Behalten Sie die ursprüngliche Eskalation bei, kennzeichnen Sie die Aufdeckung und melden Sie Verallgemeinerungsfälle separat. Eine transparente Unterscheidung ist sinnvoller als eine größere Erfolgsquote.
Fügen Sie neben der Partitur eine Belichtungsaufzeichnung hinzu
Ein kompakter Datensatz sollte die Herkunft des Datensatzes beschreiben, wer die Fälle gesehen hat, wie die Anwendung optimiert wurde, ob Tools zugehöriges Material abrufen konnten und was noch unbekannt ist. Hängen Sie es an den Lauf an, da sich die Belichtung zwischen den Ausführungen ändern kann. Ein Benchmark-Label allein beschreibt nicht die Bedingungen, unter denen eine Bewertung erzielt wurde.
- Benennen Sie die Fähigkeit oder den Workflow-Anspruch, den der Test unterstützen soll.
- Notieren Sie bekannte Trainings- oder Tuning-Expositionen, sofern verfügbar.
- Erklären Sie die Abruf- und Netzwerkberechtigungen während der Auswertung.
- Halten Sie den endgültigen Entscheidungssatz vom routinemäßigen Debugging-Feedback getrennt.
Grenzen der Beweise
Kontaminationen sind oft nur teilweise erkennbar. Neuartige Formulierungen beweisen nicht die Unabhängigkeit, und die private Speicherung beweist nicht, dass die Informationen niemals ein System beeinflusst haben. Bei der zitierten Taxonomie handelt es sich um einen Vorabdruck mit angegebenen Messeinschränkungen.
Häufige Fragen
Sollten aufgedeckte Fälle gelöscht werden?
Nicht automatisch. Sie können wertvolle Regressionstests bleiben, wenn ihre Exposition dokumentiert wird und ihre Ergebnisse nicht als unabhängige Verallgemeinerungsbeweise präsentiert werden.
Beseitigt ein neuerer Benchmark Lecks?
Nein. Der Zeitpunkt der Veröffentlichung befasst sich mit einigen Pfaden, schließt jedoch abgeleitete Beispiele, schnelle Anpassungen oder während des Laufs erfasste Informationen nicht aus.
Quellen & weiterführende Literatur
Primäre Quellen hinter diesem Briefing. Die Erkenntnisse einer Quelle gelten für ihre eigenen Studienbedingungen; Die Veröffentlichung auf arXiv begründet kein Peer-Review.
- Benchmark-Kontamination: Eine von Defeated Mitigation organisierte Taxonomie arXiv · 2026 · VorabdruckBewertet: Zusammenfassung und Veröffentlichungsnachweis. Zugriff 25. Sept. 2026.
Fragen oder Korrekturen? Schreiben Sie an Rubrex. Lesen Sie unseren redaktionellen Ansatz.