Engineering vs. policy tensions (DALL·E and DSB)
- We are all on the same team with the same goal: launch things and launch them responsibly. I won’t tolerate product teams thinking of the DSB and RAI practitioners in general as a preventer of progress just because they are tasked with upholding our RAI obligations, nor will I tolerate the DSB and RAI folks thinking of product teams as reckless or irresponsible just because they have launch pressure.
- When working through mitigations, the DSB’s job is advisory. Please, please, please jump in with engineering teams to make suggestions on approach. But it’s ultimately up to the engineering teams to choose technical approaches which work best for them that mitigate the issues raised by DSB. Let’s not confuse what’s (the actual problem) and how’s (the mechanism for fixing the problem) and who is accountable for which piece.
- Let’s make sure that perfect does not become the enemy of the good. I’m fine taking some risk, e.g., imperfect mitigations and constrained cohorts as we work toward better mitigations prior to scaling. Let’s try to seek some pragmatic solutions here so that we can accomplish some measure of our launch goals while not exposing users and ourselves to outright egregious things (like what you all showed me in the slide deck on this thread.)
Again, I probably didn’t need to say all of this, but I’m saying it anyway to you all (and will say to the engineering and product folks) just so we all stay aligned.