Posting this on behalf of the author (and my colleague) maciejgryka, who has his doctorate in ML but doesn’t have enough karma to post:
If you’ve tried building real-world features with AI, chances are that you’ve experienced reliability issues. It’s common knowledge that AI makes for great demos, but… questionable products. After getting uncannily correct answers at first, you get burned on reliability with some wild output and decide you can’t make anything useful out of that.
Having worked on this problem for a while as we built a QA AI, we identified a set of best practices and came up with a specific approach that gave us a breakthrough in reliability. It might be a good fit for your product, too.
I call it the “complementary agents” approach.
You’ll often feel like you’re playing whack-a-mole when trying to fix specific problems with your LLM prompts. For instance, I often find there’s a tension between creating the correct high-level plan of execution and the ability to precisely execute it. This reminded me of the idea behind “pioneers, settlers, and city planners”: different people have different skills and approaches and thrive in different situations. It’s rare for a single person to both have a good grand vision and to be able to precisely manage the vision’s execution.
Of course, LLMs aren’t people, but some of their properties make the analogy work. While it’s difficult to prompt your way to an agent that always does the right thing, it’s much easier to plan what’s needed and create a team of specialists that complement each other.
I’ve seen a similar approach called an “ensemble of agents,” but I prefer “complementary agents” for this approach because it highlights that the agents are meaningfully different and support each other in ways that identical agents couldn’t.
For example, to achieve a non-obvious goal, it helps to create a high-level plan first, before jumping into the details. While creating high-level plans, it’s useful to have a very broad and low-resolution view of the world without getting bogged down by details. Once you have a plan, however, executing each subsequent step is much easier with a narrow, high-resolution view of the world. Specific details can make or break your work, and at the same time, seeing irrelevant information can confuse you. How do we square this circle?
One answer is creating teams of complementary agents to give each other feedback. LLMs are pretty good at correcting themselves if you tell them what they got wrong, and it’s not too difficult to create a “verifier” agent that checks specific aspects of a given response.
An example conversation between “high level planner” and “verifier” agents might look something like the following:
Planner: OK, we need to make a PB&J sandwich! To do that, we need to get some peanut butter, some jelly and some bread, then take out a plate and a knife. Verifier: Cool, that sounds good. Planner: OK, now take the peanut butter and spread it on the bread. Verifier: (noticing there's no slice of bread visible) Wait, I can't see the bread in front of me, you can't spread anything on it because it's not there. Planner: Ah, of course, we need to take the slice of bread out first and put it on a plate. Verifier: Yep, that seems reasonable, let's do it. The two agents complement each other, and neither can work on its own. Nobody is perfect, but we can build a reliable system out of flawed pieces if we’re thoughtful about it.
This is exactly what we did for our testing agents: there’s a planner and a verifier. The planner knows the overall goal and tries to achieve it. It’s creative and can usually find a way to get to the goal even if it isn’t immediately obvious. E.g., if you ask it to click on a product that’s not on the current page, it’ll often use the search functionality to look for the product. But sometimes the planner is *too* optimistic and wants to do things that seem like they should be possible, but in fact aren’t.
For example, it might want to click on a “Pay now” button on an e-commerce checkout page, because the button should be there, but it’s just below the fold and not currently visible. In such cases, the verifier (who doesn’t know the overall goal and is only looking at the immediate situation) can correct the planner and point out that the concrete task we’re trying to do right now isn’t possible.
Super curious whether anyone has similar/conflicting/other experiences and happy to answer any questions.
[link] [comments]