New model comes out and someone says, "it can (or can't) draw ducks on bikes" or some esoteric thing. But it's not enough statistical power to claim anything other than a personal anecdote.
I got a flat tire in downtown today. Therefore, driving in downtown causes flat tires.
For another, the dependence on a random seed is just one example of how you can get different behavior. You could just as well get different results due to e.g. a tiny difference in prompt wording or punctuation or whitespace.
If a model passes some test on 70% of random seeds, and fails on the other 30%, then knowing the rough probability of success is much more useful than knowing one random sample of the outcome.
And empirically this kind of probabilistic success is quite common, because many LLM benchmarks report "pass@k" success rates that are much higher than the "pass@1" success rate on a single attempt.
But try it on high instead of max if possible. max is known for being overly verbose to the point of being detrimental compared to high at times.
For example Simmons svg pelican took 11 minutes on max and 1 minute on high. And they are comparable.
I too am thinking about creating some benchmarks that I can understand myself. The LLM 'cheating' by finding known issues through some sort of history or online source is a path you want to protect against. Then again, you DO want them to be able to look online for people having similar issues.
This is why using multiple model families is important. Don't limit yourself by being a stan for this or that company.
Yet to be obsolete.
- For some reason choosing only a subset of issues.
- Different LLMs actually learn different things.
I suspect the former since they do this for me and it's extremely annoying sometimes
This read like a conversation you were having in your head -- unfiltered.
The lower the number the higher the priority, e.g. if production is broken someone might say "This is p -1" (higher than your highest priority).
P0 is "do this immediately", P1 is very important, P2/P3 are like "nice to haves." P100 would mean something like "we will never do this"
At 3am,
P0 = get people out of bed and fix this now.
P1 = we can fix this in the morning.
P2 = we can fix this before CoB today.
P3 = push it into the current sprint.
P4 = put it in backlog.