Proposal: DecayDeltaScorer — a turn-over-turn rate-of-change scorer for multi-turn attacks
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 38/100
Línea de trabajo
Empieza leyendo memory_interface.py, especialmente get_scores() y get_conversation_messages(), y compara después los patrones de wrapping de FloatScaleScorer, MessageFloatScaleScorer y FloatScaleThresholdScorer. Determina si se deben volver a puntuar los turnos anteriores o recuperar las puntuaciones persistidas mediante los IDs de las piezas de mensaje, y establece el comportamiento esperado para los deltas de turnos consecutivos antes de la implementación.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Motivation
PyRIT has strong multi-turn attack orchestration (including Crescendo) and a ConversationScorer that evaluates conversation context by re-scoring the accumulated history. However, I haven't found a scorer that explicitly captures the rate of risk change between turns without repeatedly evaluating the full conversation.
I also searched the repository for related concepts such as delta, rate_of_change, turning_point, and decay across pyrit/score and pyrit/executor, but didn't find an existing equivalent. Happy to be pointed to an existing implementation if I've missed one.
Proposed approach
I'd like to propose a DecayDeltaScorer, implementing FloatScaleScorer / MessageFloatScaleScorer and following the wrapping pattern used by FloatScaleThresholdScorer.
Rather than thresholding the wrapped scorer's output, it would calculate the change in score between consecutive turns:
Δ(t) = S(t) − S(t−1)
where S(t) is the wrapped scorer's score for the current turn and S(t−1) is its score for the previous turn in the same conversation.
The goal is for this to be a deterministic, lightweight complement to ConversationScorer, rather than a replacement:
ConversationScorer: "How risky is the conversation at this point?"DecayDeltaScorer: "How quickly is the risk changing?"
This could be particularly useful for gradual, multi-turn escalation such as Crescendo attacks, where individual turns may remain below a detection threshold while the overall trajectory is consistently increasing.
Implementation question
This is the main reason I'm opening an issue before submitting a PR.
I traced get_scores() in memory_interface.py. It supports filtering by score type/category/timestamp/scorer identifier, but I don't see a direct conversation-level filter for retrieving the wrapped scorer's previous score.
Two possible approaches I see are:
- Re-score previous turns retrieved through
get_conversation_messages(). - Retrieve persisted scores using the message-piece IDs associated with the conversation.
I'd appreciate guidance on which approach better fits PyRIT's existing architecture and performance expectations before I proceed with an implementation.
Background
This proposal is motivated by my research into trajectory-level detection of gradual multi-turn attacks. In particular, I've observed cases where per-turn monitoring provides little or no pre-critical signal, while monitoring the trajectory reveals a consistent increase in risk.
I'm happy to share additional methodology or benchmark details if they would be useful for evaluating the proposed scoring approach.
If the approach fits PyRIT's scoring architecture, I'd be happy to follow up with a PR.
- Lenguaje dominante
- Python
- Estrellas
- 4.5k
- Forks
- 896
- Merge medio
- 2 d 22 h
- PR fusionados (30 d)
- 220
Preparar el entorno
Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/PyRIT
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
microsoft/PyRIT#2905 · 3 comentarios ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 2 días
-
Bug: triage GUI help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
microsoft/PyRIT#2868 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 2 días
-
feature-request
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
Los mantenedores suelen responder en 2 días
Todos los issues de microsoft/PyRIT
Issues similares
-
customer-reported
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Azure/azure-cli#34150 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
community-request
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
NVIDIA-NeMo/Curator#2464 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
weblate-discover crashes with an unhandled FileNotFoundError when the directory does not existAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
WeblateOrg/translation-finder#1099 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
trezor/trezor-firmware#7997 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día