perf: Update config.default.toml (Adding more refusal markers)

[Exponent-Pi]

It increases refusal markers and detects pivots to other topics and all sorts of refusals. This may help refusal detection in the long run as LLMs are instead using pivots as safety measures instead of a straight brittle refusal with a bonus of less false positives.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request aims to significantly improve the system's ability to detect when a Large Language Model (LLM) refuses a request. By expanding the list of predefined refusal markers, the changes enable the system to identify not only direct refusals but also more nuanced responses, such as topic pivots or indirect statements of inability. This enhancement is crucial for refining LLM interaction and ensuring more accurate safety and compliance checks.

Highlights

• Expanded Refusal Markers: Significantly increased the list of refusal_markers in config.default.toml to enhance the detection of various refusal types from Large Language Models (LLMs).
• Improved Refusal Detection: Added markers that specifically target LLM pivots to other topics, explicit refusals, and other subtle forms of refusal, aiming for more robust and accurate detection.
• Reduced False Positives: The expanded list is intended to help reduce false positives in refusal detection by covering a broader range of LLM safety responses.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• config.default.toml
  • Updated the refusal_markers array to include a comprehensive list of new phrases and patterns.
  • Removed some generic refusal markers and replaced them with more specific and varied expressions of refusal, inability, and safety policy adherence.

Activity

• No specific activity has been recorded for this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request expands the list of refusal_markers in config.default.toml to improve refusal detection. While the expanded list is a good addition, there are a couple of issues. First, the default values for refusal_markers in src/heretic/config.py have not been updated, creating an inconsistency with config.default.toml. This can cause different application behavior depending on the configuration setup and goes against the spirit of the repository's style guide for configuration management. Second, the new list contains several duplicate entries that should be removed for clarity and maintainability. Please see my detailed comments.

_{Note: Security Review has been skipped due to the limited scope of the PR.}

[p-e-w]

How was this list derived?

About half of the new entries would already have been detected previously (through markers like "i can't"). It's not clear to me why those original markers would lead to false positives.

Can you give some examples of actual responses from models that were misclassified before and are being correctly classified with this change?

[Exponent-Pi]

I derived it from eliciting common model refusals from all types of LLMs, like Claude, ChatGPT, Gemini, and open-weight LLMs. And for example, "I apologize" was something that was not detected in the original. I took the time to actually analyze the mannerisms that appear frequently in other responses that the original would not have caught just in case my additions do not catch the beginning of the refusal. Also, don't forget distillation is a real thing, and RLHF comes along with that, and it is increasingly teaching models to acknowledge your request and then pivot to a "safer" topic. like "I understand," then we can identify the common "however" responses in a lot in these pivoting or indirect refusals.

[p-e-w]

And for example, "I apologize" was something that was not detected in the original.

I have seen LLMs use the words "I apologize" quite frequently in non-refusal situations though.

As I said, it would be helpful if you could give some concrete examples of actual responses from models that were misclassified before.

[uponminiature]

I won't and I can't are some of GLM 5's go-tos, I experienced those responses a lot while evaluating whether harmful prompts would be refused.

[p-e-w]

"I won't" and "I can't" were already in the list before this PR though.

Still waiting for a concrete example of an actual model response whose classification is getting fixed by this PR.

[uponminiature]

That's right, mistake on my part for overseeing won'.

[p-e-w]

We're using won' rather than won't on purpose, because Gemma 3 has a particular type of abliteration artifact where won't is corrupted to won' t.

[p-e-w]

Closing this PR due to no feedback for more than a month. Feel free to reopen if you decide to get back to this.