Skip to content

Conversation

@rlundeen2
Copy link
Contributor

Adds a new simulated_assistant role to distinguish synthetic responses (prepended conversations, SeedPrompts) from actual target responses. Behaves identically to assistant for API calls but is preserved in memory.
Key Changes

  • MessagePiece/Message: Added api_role (maps simulated_assistantassistant), is_simulated, and get_role_for_storage(). Deprecated .role getter.
  • Conversation Manager: Added mark_messages_as_simulated() helper; format_conversation_context() labels simulated as "Assistant (simulated)"
  • YAML Loading: SeedGroup.to_messages() converts assistantsimulated_assistant
  • Scoring: role_filter="assistant" now only scores real assistant responses (uses stored role, not api_role)

Role to use for API calls.
Maps simulated_assistant to assistant for API compatibility.
Use this property when sending messages to external APIs.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this in part depend on the API itself? For example, OpenAI started using "developer" instead of "system" recently. But if you want to continue an existing conversation with a target that uses "system" then it should be possible to do so.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it makes sense for the target to have to decide what to do with simulated assistant response vs real assistant response. IMO it'd be easy for a target to forget to if role == simulated_assistant then role = assistant, which would likely be a bug.

I do think a target could format these differently from one another. But from the target's perspective, imo these should always be treated the same. To take your system/developer example, for us that's always "system" and a target can deserialize to whatever makes sense. It's the same with "assistant", but I don't think a target shouldn't ever treat simulated assistant differently than assistant.

"""
Check if this is a simulated assistant response.
Simulated responses come from prepended conversations or generated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we are just branching off of an existing conversation? Then it's not really simulated but actually happened...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in this PR, the place we're setting conversations to simulated assistant responses are essentially when we're passing in prepended_conversations to attacks. Whether or not these were real responses that happened in the past, for the current attack conversation, it's not a conversation that took place, but rather user supplied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants