Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 78 posts

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#21

Post by bicx »

threeseed wrote: post #19

> This agent is a combination of separate LLM agents each responsible for a single step of the runbook Someone needs to explain to me how this is expected to work. Percentage of Hallucinations/Errors x Steps in Runbook = Total Errors 0.05 x 10 = 0.5 = 50%

Getting tired of seeing this concept of practically guaranteed hallucinations from any LLM used in production. I've used LLMs for various tasks, and if you tune your system correctly, it can be very reliable. It's just not always plug-and-play reliability. You need to set up your fine-tuning and prompts and then test well for consistent results.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#22

Post by wilson090 »

threeseed wrote: post #19

> This agent is a combination of separate LLM agents each responsible for a single step of the runbook Someone needs to explain to me how this is expected to work. Percentage of Hallucinations/Errors x Steps in Runbook = Total Errors 0.05 x 10 = 0.5 = 50%

We separated out the runbook such that each step is a separate LLM in the agent. Between each step, there's sort of a "supervisor" that ensures that the step was completed correctly, and then routes to another step based on the results. So in reality, a single step failing requires two hallucinations. Hallucinations are also not a fixed percentage across all calls -- you can make them less likely by maintaining focused goals (this is why we made runbooks agentic rather than a single long conversation)

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#23

Post by threeseed »

bicx wrote: post #21
threeseed wrote: post #19

> This agent is a combination of separate LLM agents each responsible for a single step of the runbook Someone needs to explain to me how this is expected to work. Percentage of Hallucinations/Errors x Steps in Runbook = Total Errors 0.05 x 10 = 0.5 = 50%

Getting tired of seeing this concept of practically guaranteed hallucinations from any LLM used in production. I've used LLMs for various tasks, and if you tune your system correctly, it can be very reliable. It's just not always plug-and-play reliability. You need to set up your fine-tuning and prompts and then test well for consistent results.

> it can be very reliable

You need to quantify this. With actual numbers.

I am getting very tired of seeing everyone pushing LLMs and being disingenuous about exactly how often it is getting things wrong. And what the impact of that is. There is a reason that AI is not taking off in the enterprise and that is because people who take their job seriously are getting tired too.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#24

Post by threeseed »

wilson090 wrote: post #22
threeseed wrote: post #19

> This agent is a combination of separate LLM agents each responsible for a single step of the runbook Someone needs to explain to me how this is expected to work. Percentage of Hallucinations/Errors x Steps in Runbook = Total Errors 0.05 x 10 = 0.5 = 50%

We separated out the runbook such that each step is a separate LLM in the agent. Between each step, there's sort of a "supervisor" that ensures that the step was completed correctly, and then routes to another step based on the results. So in reality, a single step failing requires two hallucinations. Hallucinations are also not a fixed percentage across all calls -- you can make them less likely by maintaining focus…

And what is your average error rate per runbook step.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#25

Post by nerdjon »

bicx wrote: post #21
threeseed wrote: post #19

> This agent is a combination of separate LLM agents each responsible for a single step of the runbook Someone needs to explain to me how this is expected to work. Percentage of Hallucinations/Errors x Steps in Runbook = Total Errors 0.05 x 10 = 0.5 = 50%

Getting tired of seeing this concept of practically guaranteed hallucinations from any LLM used in production. I've used LLMs for various tasks, and if you tune your system correctly, it can be very reliable. It's just not always plug-and-play reliability. You need to set up your fine-tuning and prompts and then test well for consistent results.

> You need to set up your fine-tuning and prompts and then test well for consistent results.

Tell that to Google...

Seriously, it is well established that these systems hallucinate. Trying to say otherwise shows you are trying to push something that just is not true.

They can be right, yes. But when they are wrong they can be catastrophically wrong. You could be wasting time looking into the wrong problem with something like this.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#26

Post by nerdjon »

Well the website seems to be down so I can't actually see any information about what LLM you are using, but I seriously hope you are not just sending the data to OpenAI API or something like that and are forcing the use of a private (ideally self hosted) service.

I would not want any data about my infrastructure sent to a public LLM, regardless of how sanitized things are.

Otherwise, on paper it seems cool. But I worry about getting complicit with this tech. It is going to fail, that is just the reality. We know LLM's will hallucinate and there is not much we can do about it, it is the nature of the tech.

SO it might work most of the time, but when it doesn't and you're bashing your head against the wall trying to figure out what is broken. This system is telling you that all of these things are fine, but one of them actually isn't. But it worked enough times that you trust it, so you don't bother double checking.

That is before we even talk about having this thing running code for automatic remediation, which I hope no one seriously considers ever doing that.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#27

Post by jtsaw »

threeseed wrote: post #24
wilson090 wrote: post #22

Earlier quoted context omitted.

We separated out the runbook such that each step is a separate LLM in the agent. Between each step, there's sort of a "supervisor" that ensures that the step was completed correctly, and then routes to another step based on the results. So in reality, a single step failing requires two hallucinations. Hallucinations are also not a fixed percentage across all calls -- you can make them less likely by maintaining focus…

And what is your average error rate per runbook step.

one thing we're experimenting to help with the hallucinations/error rate issue is using a committee framework where we take a majority vote.

If the error rate of 1 expert is 5%, then for a committee of 10 experts, the probability a majority of the committee errors is around 0.00276% (binomial distribution with p=0.05). For 10 steps, this would be an error rate of 0.0276%

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#28

Post by nerdjon »

wilson090 wrote: post #22
threeseed wrote: post #19

> This agent is a combination of separate LLM agents each responsible for a single step of the runbook Someone needs to explain to me how this is expected to work. Percentage of Hallucinations/Errors x Steps in Runbook = Total Errors 0.05 x 10 = 0.5 = 50%

We separated out the runbook such that each step is a separate LLM in the agent. Between each step, there's sort of a "supervisor" that ensures that the step was completed correctly, and then routes to another step based on the results. So in reality, a single step failing requires two hallucinations. Hallucinations are also not a fixed percentage across all calls -- you can make them less likely by maintaining focus…

That second step hallucinating is far more likely when you are feeding it incorrect information from the first hallucination.

LLM's are very easy to manipulate.

At one point with a system prompt telling Claude it was OpenAI, I was able to ask what its model is and it would confidently tell me it was OpenAI. Garbage data in, garbage data out.

Admittedly that is an extreme case, but you're giving that second prompt wrong data in the hopes that it will identify it instead of just thinking it's fine when it is part of its new context.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#30

Post by wilson090 »

nerdjon wrote: post #26

Well the website seems to be down so I can't actually see any information about what LLM you are using, but I seriously hope you are not just sending the data to OpenAI API or something like that and are forcing the use of a private (ideally self hosted) service. I would not want any data about my infrastructure sent to a public LLM, regardless of how sanitized things are. Otherwise, on paper it seems cool. But I wor…

Hmm we're not seeing any issues with the website on our end -- tryparity.com is down for you?

The data security point with LLMs is definitely relevant. There's a broader conversation ongoing right now about how teams will securely use LLMs, but from our conversations so far teams have been willing to adopt the tech. We've been working with startups up to this point, so we'll likely need to offer support self-hosted LLMs if we were to support enterprise or bring-your-own-keys for larger startups.

The hallucination point is interesting. I think a lot of products will need to solve this problem of having so much trust with the user that they'll blindly follow the outputs, but occasionally failing due to hallucination. Our approach has been to 1) only focus on investigation/root cause and 2) make sure it's easy to audit the results by sharing all of the results + supporting evidence

Post reply on HN