Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ah, I see. IMO the other response [0] I gave is probably the closest to what I had in mind. Interestingly, retry very well might not be better, especially when measured on a pareto frontier including cost.

I have a reasonably strong prior that it should be better though. That comes from my observations that whenever I notice the difference in distribution the retry method is better (obvious sampling bias, but what kind of person ignores their own experiences). As a stronger piece of evidence and intuition, the entire goal of these systems is to reproduce a certain distribution. If that distribution says that you should use ripgrep 10x as often as you should use grep then that's a signal you probably don't want to throw away. Constrained decoding might very well do so and place them on even footing or skew 10x the other direction. Retry faithfully captures that original distribution. I'm skeptical of solutions which want to shy too far away from it (similarly with most applications of changing the model's temperature).

The more important point is just that they're different, so we should probably measure the impact.

[0] https://news.ycombinator.com/item?id=50245714



(Not sure you'll see this, ofc.) After percolating on this for a couple days, is retrying the tool calls enough? Maybe the reason the tool call is requiring three retries is because the AI simply got locked into too difficult of a way to solve the problem, and if it retried the entire response it would have gone in a different direction entirely. How far back do we feel comfortable?

These edge-cases are why the simplest answer works best: just scale your model to be good enough that it can work through the problem on its own



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: