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

Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

github.com

Post reply on HN
Print view View original

211–220 of 292 posts

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#211

Post by zambelli »

andai wrote: post #203
6r17 wrote: post #30

Very cool work ! I'm running harness system myself and could measure improvement of token use of 2x to 10x on gsm8k only by running a math harness - i'm confident the future is bright for people who will know how to sell tech that is appropriately scaled to one's need. We absolutely do not need to run Claude 123 for most tasks and we better prepare for the rag-pull !

A while back when the latest Big Model came out, very impressive benchmarks, I tested it on some coding tasks. I gave it 3 simple changes to make. It did it perfectly. Then I tried with a much smaller model. It also did it perfectly, except 3x faster and 9x cheaper. I used to think "best model" was what's at the top of the benchmarks, but for most tasks that just means you're going to wait longer and pay more money.…

Definitely! A lot of tasks are within reach of small models, much more than people would think. Big models still shine in vague contexts or for breadth, or for very long running tasks, but yeah. The small ones just need help on longer multi-step workflows.

What small models have you used most/found most stable?

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#212

Post by zambelli »

philipp-gayret wrote: post #185

Nice work! I've worked through all kinds of local models, very extensively for a week on an NVidia Spark. Gemma and Qwen, quantized, somewhat shine but the results overall compared to say a Claude Haiku were so disappointing (in context of tool calling) that I ended up returning the hardware. I'm curious how the same local models and benchmarks I have will hold up, will try this.

Good luck! Frontier models are called frontier for a reason. I've seen Forge get local models close to frontier on these evals, even beat it in some cases, but frontier still has an edge overall - no denying it.

The key I think is to look at what use cases you have that aren't big monsters. Auditing logs, home assistant, reading and summarizing news rss feeds, etc...stuff that's fairly bite-sized per task, but high volume. Then the local models make sense and they just need mechanical reliability to close the gap.

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#213

Post by zambelli »

gcr wrote: post #201

how do you know your harness design isn’t just overfitting on your test set?

Love this question! A few points:

- First, there's totally a "risk" there. I built both the harnesses and the eval suite and that's hardly a double-blind study. There's no world where some bias doesn't leak through.

- I did try to design the guardrails to be domain-agnostic so they aren't tuned to specific scenario failures and return generic nudges to the LLM.

- Most tactically, the guardrails were built on the first 18 scenarios (OG-18) published in the paper, and only after did I had 8 more advanced reasoning ones. I didn't update the guardrails when I added those, and the lift was still there. If they were overtuned, they wouldn't have the same level of impact on an newer set.

- I did dogfood forge post publication using several unrelated consumers and the features I baked in were rarely guardrail related. If they were, it was more model focused (ie, xml-parse-rescue for granite models).

But at the end of the day, there's an explicit connection between the guardrail author and eval author. Happy to take contributions of eval scenarios if you want to stress test things, or hear about your experience running a completely different consumer!

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#215

Post by Charles389no »

simonw wrote: post #92

This is a neat project, but the description made me realize that I don't actually know what the term "guardrails" means. ... which lead me to realize that it's one of those terms with multiple meanings - like "agent" or even "AI" itself - but where people who use it may not be aware of how many different definitions are floating around. In this project it refers to validating tool calls - fixing invalid tool response…

[flagged]

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#216

Post by zambelli »

mc-serious wrote: post #181

Really cool direction. For folks thinking about the “agent safety” stack more broadly, this feels complementary to things like Kontext’s kontext-cli (github.com/kontext-dev/kontext-cli) and OneCLI (github.com/onecli/onecli)

Yeah I would think so!

A lot of current tooling is layered mostly at the workflow level. Auth for the agent, or memory management for the agent (like some smart skills stuff), but Forge sits below that.

In most cases I've looked at, it could be slotted in with other work without much disruption. Forge just increases mechanical reliability of tool-calling, it shouldn't disrupt your workflow-level layers much.

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#217

Post by zambelli »

Dansvidania wrote: post #189
zambelli wrote: post #165

Earlier quoted context omitted.

Within limits, yes. Forge has escalating nudges that will tell the model effectively "stop responding with text, you MUST call a tool" vibes. If the model is emitting something like "ok, let me call the tool: [valid json tool call in the middle of prose]" then we catch it with rescue parsing. But at the end of the day, if the model keeps responding with text, there's nothing forge can do. I've run into that failure m…

sorry if it's a stupid question, but isn't generating valid json tool call in the middle of prose the way tool calling works? what is that missing?

Not stupid at all!

Some of the older models did do this (like 3.5-era ish I think), and the harness would parse the results.

The newer way frontier has setup is structured tool calls. `tool_use` or `tool_calls`. The response is then received as a different tool_result rather than a regular message. That's a bit of the newer way of doing it.

The failure mode in question is more the model mixing the two: "Sure, I'll read the file: {"tool": "read", "args": {"path": "foo"}}" - that'll break stuff. Other failure modes are the json not parsing when sent it as a structured call, and in some cases the model just emitting text and forgetting the tool call.

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#218

Post by zambelli »

ApolloRising wrote: post #180

I went to view the dashboard and it is getting a github 404 error, just thought you should know.

I know :( - I posted the wrong link and now it's there forever.

Dashboard is in here: https://github.com/antoinezambelli/forge/tree/main/docs/resu...

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#219

Post by zambelli »

blurbleblurble wrote: post #174
zambelli wrote: post #152

Earlier quoted context omitted.

I think I'm aligned with the idea that some parts of some workflows are mandatory - auth, read before edit, etc. But otherwise, forge really doesn't own or opine much of the workflow. Step enforcement exists if you want it, so do prerequisites, but the idea is that those could be conditional or optional (you may never need to edit a file). The guardrails are designed to work for non deterministic flows or determinist…

In this blog post I'm reading their call for "control flow" as a generalization of exactly what your work illustrates so nicely. The blog post doesn't say to me "we need to start encoding specifically opinionated conditional branching statements that guide the model" rather I'm hearing a call to realize the broader principles of control flow itself relevant for composing programs with LLMs. I think your work "nudges"…

Nice ;). I'll take a closer read of it, that's on me - I am definitely seeing more people looking in this direction as agents start to ramp in production at the enterprise level, which I suspect is highlighting some of these failure modes at higher stakes. And also the cloud frontier API bills.

Re: Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks

#220

Post by zambelli »

pancsta wrote: post #186

If its so good at coding, why did you use Python aka py-toy? Let me guess…

This is not an agentic coding harness. It's a generic tool-calling guardrail stack. I have built a coding harness built on Forge since, but that's not what this is.
Post reply on HN