Recurring bigasp flesh monstrosities

#6
by bbbla - opened

I've been testing and red-teaming the model over a couple of weeks now and it is amazingly fun, creative and extremely uncensored. However I am perplexed as to why we are still seeing the same flesh monstrosity artifacts seen in the earlier bigasp models on the SDXL architecture even in this klein finetune (I find bigasp3 closer to a base model though).

What are your thoughts on this? Is it something with your dataset or training process? OR is it simply that a 9b model can't fully learn all the params of your diverse dataset and we see the same "limb confusion" as on SDXL?

I think the planned RL training phase will help with prompt alignment and aesthetics

I've been testing and red-teaming the model over a couple of weeks now and it is amazingly fun, creative and extremely uncensored. However I am perplexed as to why we are still seeing the same flesh monstrosity artifacts seen in the earlier bigasp models on the SDXL architecture even in this klein finetune (I find bigasp3 closer to a base model though).

What are your thoughts on this? Is it something with your dataset or training process? OR is it simply that a 9b model can't fully learn all the params of your diverse dataset and we see the same "limb confusion" as on SDXL?

Could you share a gen via Catbox so we can see your workflow and settings? I haven't had the problem you're describing.

Let me just add that it happens way less than with the SDXL checkpoints, but still not something I've experienced in other "non-asp" models.
And it feels strange to share my prompts and generations, never done that before πŸ˜†

Here's a workflow that should be better suited for bigasp3; I've also adapted your prompt about the female pianist. As you can see, it's better to use LoRa "flux-2-klein-9b_extracted_lora_rank_256-bf16.safetensors" with at least 30 steps.

https://files.catbox.moe/kuknaq.png

I'll check it out, but was not really looking for a way to "fix my generations". More interested in the topic itself.

The original intention was to give you an optimized workflow so you wouldn't run into bad generations. As I said, the latest beta version of bigasp3 generally produces good results, but you just need the right settings combined with a better way to prompt.

Thank you both for sharing workflows and reporting issues!

More interested in the topic itself.

Having gone through several experiments with bigASP, I've blown through a bunch of theories and kind of landed on the best guess as of today. The short version is that this isn't an issue with my dataset or training methodology or something like that. For any large scale model or finetunes there's just no way to really fix the meat-puddles without doing RL on the model, or highly focused SFT. All previous bigASP models have come fresh out of the box; no post training whatsoever, not even SFT.

I mostly go over my modern theory on why RL is needed and what it does exactly here: https://aerial-toothpaste-34a.notion.site/How-OpenAI-Misled-You-on-RLHF-1f83f742d9dd80a68129d06503464aff

The short of the long is that, if you ask a finite model to understand how to generate all possible images, it's of course going to fail. No matter how much training compute you pour into it. What happens in practice is that as the model tries to navigate the inference landscape it will often run into terrain that is too difficult for it based on its current strength. In those cases its predictions greatly weaken, and the probability of the model making a wrong prediction increase. And that often leads it further down paths it cannot strongly handle, which eventually leads to a failed gen.

We can avoid that by using highly curated SFT datasets. Those A) greatly limit what the model has to use its capacity to understand and B) limit the model to paths we guess it can handle safely. This gives us the old generation of diffusion models like SDXL, etc. All LORAs basically fall into this, and most medium scale finetunes since those tend to limit domain coverage and have highly curated datasets. The result is a model that's good, but limited in flexibility. Same face, same poses, same compositions, etc.

But the better choice is RL, which lets the model itself find and discover what parts of the terrain it can and cannot handle. We then teach it to avoid paths it cannot reliably handle, and gravitate towards paths it's good at.

Both SFT and RL by necessity "trim" down the potential paths the model will follow. i.e. they will both decrease the model's overall creativity. You have to, to build a model that is less likely to throw itself off a meat-soup waterfall.

But if done carefully you can limit the trimming as much as possible while still increasing the model's reliability. I think Krea 2 is a great example of that. Based on their blog they went through great lengths to keep the model's creativity up throughout their post training processes. And from what I've seen in the community people are happy with it.

That's roughly my goal on bigASP 3, which is why RL is taking so long to even get started. It's not a terribly complicated training procedure, but I'm taking my time with the prompt set and reward models to ensure the model doesn't get neutered.

And of course that's why I released the pretrained bigASP 3, so the community at large are always welcome to pick and choose whatever works best, experiment with your own workflows.

A nice thing about post training is that it can be iterated on a few times, which is likely to be the case here. I'll publish any meaningful versions along the way until I get RL nailed down.

Great, that sounds like the most plausible explanation in my eyes. I will check out your write-up. It's gonna be fun to test the RLed checkpoint too :)

Sign up or log in to comment