Enhancements

[thiswillbeyourgithub]

Hi!

I'm the dev who made a research fork of repeng to explore some questions about what's possible with repeng and repeng-like techniques. I first mentioned my ideas in these messages

The project is still ongoing but as I kept adding more and more little enhancements it felt a good idea to try to upstream some of them.

Notably, added a utils.py file with function make datasets, joblib caching for the activations, support for chat templates (with auto correction), l1/l2 norm, documentation, more controls on which layer to trigger, numpy v2 compatibility.

Note that I couldn't run the test file because of import issues with flash attention.

I also did not add any modules to the requirements yet.

I mainly wanted your feedback on this.

Also thanks a lot for making repeng, it's really nice and really allowed me to get my hands dirty!

Commits:

• add file settings.py to store settings
• add a utils.py file that contains a make_dataset function
• move DatasetEntry to utils.py
• feat: give more controls to how the user can select the layers to modify
• feat: add joblib memory for caching model activations
• fix: numpy v2 compatibility
• feat: add arg norm_type when training that allows setting l1 or l2 (or other) norm
• feat: add function to accept chat template as inputs + autocorrect
• fix: forgot an import
• minor: add tqdm for getting activations and applying the new directions
• perf: potentially faster one liner to tokenize
• feat: use flag LOW_MEMORY to reduce the amount of memory needed when storing the arrays before computing directions
• fix: imports
• update default model in example from mistral 7B v0.1 to v0.3
• docs: add more details on how to load the model, including quantization, avoiding OOM, etc
• docs: use chat messages in example
• docs: in example, show how to login for models that require it
• docs: add missing declaration of tokenizer
• fix: in example, move the tokens directly to the correct device
• minor: changed default in the example
• docs: add link to github issue about OOM for gguf files
• docs: add more examples of models
• fix: autocorrect chat templates

[vgel]

This is really cool! My first thought is there's probably too much going on here for one PR, but let me look it over more closely and figure out how we can split this up. I've also been considering adding a utils file for a similar reason as you--I might make a PR for that soon-ish and tag you in.

[vgel]

I'm also currently migrating the library from poetry to uv, so no rush on adding dependencies!

[thiswillbeyourgithub]

This is really cool! My first thought is there's probably too much going on here for one PR, but let me look it over more closely and figure out how we can split this up. I've also been considering adding a utils file for a similar reason as you--I might make a PR for that soon-ish and tag you in.

Glad you lile it! I take this opportunity to thank you once again for making repeng, it's been super helpful to get me started on many ideas I had.

I'm fine with splitting this up but I do care about my contribution being credited as I'm a self taught medical student (soon psychiatry resident!) so I want my interests and contributions to appear on my github for exposition :)

In any case I keep breaking and unbreaking my fork as I'm continuously experimenting (since yesterday I've been playing around with filtering samples that are retrievable after a 2 cluster kmeans on the umap projection and I feel good about this one!). Appart from the read_representation method I think the code is mostly stable. I'm sometimes unsure about my chat templating thingy but that might be because of errors in the original templates of their repo too so would appreciate a second look on this if you have the bandwith.

Also I couldn't run the tests on my machine, I'm thinking it would really help to know if my modifications are stable and with no side effects

edit: actually I was able to run the tests. But as I made extensive changes I'll keep them so far in my fork.

[vgel]

definitely, will absolutely make sure you're credited on anything that gets merged :-)

[vgel]

here, a good initial thing to split off would be the ability to pass a string for layer_ids in ControlModel.__init__ . i think we should have three options:

• a list / range object, like we currently have
• "all"
• "middle", which should keep the middle 2/3 (instead of the middle half as it does now)

then in the docstring, we should suggest people use "middle" as the default. i don't think we should support None, because people should be explicit about what layers are being controlled. and i think "only_middle" and the range stuff are marginal enough that we don't need to support them by default--people can always calculate it themselves if they need it, or we can add it later.

if you could split that off into a new PR, i can help make sure the tests are passing etc so we can get it merged, if that sounds good?

[thiswillbeyourgithub]

Sounds good to me, thanks! I'll do that when I have some time in the next week