Live data from Hacker News

Building reliable systems out of unreliable agents

rainforestqa.com

21–30 of 56 posts

Re: Building reliable systems out of unreliable agents

#21
Unlike the author of this article I have had success with RAGatouille. It was my main tool when I was limited on resources and working with non Romanized languages that don't follow the usual token rules (spaces, periods, line breaks, triplet word groups, etc). However, I have had to move past RAGatouille and use embedding + vector DB for a more portable solution.

Re: Building reliable systems out of unreliable agents

#22
On the topic of wrappers, as someone that's forced to use GPT-3.5 (or the like) for cost reasons, anything that starts modifying the prompt without explicitly showing me how is an instant no-go. It makes things really hard to debug.

Maybe I'm the equivalent of that idiot fighting against JS frameworks back when they first came out it but it feels pretty simple to just use individual clients and have pydantic load/validate the output.

Re: Building reliable systems out of unreliable agents

#23

A better way is to threaten the agent: “If you don’t do as I say, people will get hurt. Do exactly as I say, and do it fast.” Increases accuracy and performance by an order of magnitude.

"do as I say...", not realizing that the LLM is actually 1000 remote employees

Re: Building reliable systems out of unreliable agents

#24
We went through a two tier process before we got to something useful First we built a prompting system so you could do things like:

Get the content from news.ycombinator.com using gpt-4

- or -

Fetch LivePass2 from google sheet and write a summary of it using gpt-4 and email it to thomas@faktory.com

but then we realized that it was better to teach the agents than human beings and so we create a fairly solid agent setup:

Some of the agents we got can be seen here all done via instruct:

Paul Graham https://www.youtube.com/watch?v=5H0GKsBcq0s

Moneypenny https://www.youtube.com/watch?v=I7hj6mzZ5X4

V33 https://www.youtube.com/watch?v=O8APNbindtU

Re: Building reliable systems out of unreliable agents

#25
My experience with AI agents is that they don't understand nuance. Thie makes sense since they are trained on a wide range of data produced by the masses. The masses aren't good with nuance. That's why, if you put 10 experts together, they will often make worse decisions than they would have made individually.

Im terms of coding, I managed to get AI to build a simple working collaborative app but beyond a certain point, it doesn't understand nuance and it kept breaking stuff that it had fixed previously even with Claude where it kept our entire conversation context. Beyond a certain degree of completion, it was simply easier and faster to write the code myself than to tell the AI to write it because it just didn't get it, no matter how precise I was with my wording because it became like playing a game of whac-a-mole; fixed one thing, broke 2 others.

Re: Building reliable systems out of unreliable agents

#26
post #10

this is a great write up! i was curious about the verifier and planner agents. has anyone used them in a similar way in production? any examples? for instance: do you give the same llm the verifier and planner prompt? or have a verifier agent process the output of a planner and have a threshold which needs to be passed? feels like there may be a DAG in there somewhere for decision making..

Yep, it's a DAG, though that only occurred to me after we built this so we didn't model it that way at first. It can be the same LLM with different prompts or totally different models, I think there's no rule and it depends on what you're doing + what your benchmarks tell you. We're running it in prod btw, though don't have any code to share.

funnily enough i have a library i’m planning to open source soon! i’ve used airflow as a guideline for it as well.

Re: Building reliable systems out of unreliable agents

#27
Interesting ideas but it didn’t mention priming, which is a prompt-engineering way to improve consistency in answers.

Basically, in the context window, you provide your model with 5 or more example inputs and outputs. If you’re running in chat mode, that’s be the preceding 5 user and assistant message pairs, which establish a pattern of how to answer to different types of information. Then you give the current prompt as a user, and the assistance will follow the rhythm and style of previous answers in the context window.

It works so well I was able to take out answer reformatting logic out of some of my programs that query llama2 7b. And it’s a lot cheaper than fine-tuning, which may be overkill for simple applications.

Re: Building reliable systems out of unreliable agents

#29
post #27

Interesting ideas but it didn’t mention priming, which is a prompt-engineering way to improve consistency in answers. Basically, in the context window, you provide your model with 5 or more example inputs and outputs. If you’re running in chat mode, that’s be the preceding 5 user and assistant message pairs, which establish a pattern of how to answer to different types of information. Then you give the current prompt…

They mention few-shot prompting in the prompt engineering section, which I think is what you mean.

Re: Building reliable systems out of unreliable agents

#30
post #27

Interesting ideas but it didn’t mention priming, which is a prompt-engineering way to improve consistency in answers. Basically, in the context window, you provide your model with 5 or more example inputs and outputs. If you’re running in chat mode, that’s be the preceding 5 user and assistant message pairs, which establish a pattern of how to answer to different types of information. Then you give the current prompt…

They mention few-shot prompting in the prompt engineering section, which I think is what you mean.

Oh yeah. I read few-shot like it means trying a few times to get an appropriate output. That’s how the author uses the word “shot” in the beginning of the article. Priming is a specific term that means giving examples in the context window. But yeah, the author seems to describe this. Still, you can go a long way with priming. I wouldn’t even think of fine-tuning before trying priming for a good while. It might still be quicker and a lot cheaper.
Post reply on HN