Come read what I've written about how we evaluate Sybil! By drawing parallels to sales and marketing funnels, we can view Sybil as its own funnel where we want to maximize true positives and minimize false positives at every stage of our pipeline. Using this framing, we're able to seed Sybil's state across these different stages, letting us run leaner and faster experiments without sacrificing realism.
AlphaGo moments in security, where agents find attack paths no human would consider, won't come from coercing agents to retrace conventional patterns. That's why we benchmark Sybil on outcomes, not steps. We treat Sybil as a funnel, running against our own range of diverse, production-worthy web apps. We've also adopted a measurement framework that lets us run Sybil at the granularity each product question demands, so we can understand if each change, whether a new model or a new prompt, actually makes Sybil better for users. Take a first look under the hood at how we approach this in our latest blog: https://lnkd.in/gjgggXXH
This is great to see! James Crnkovich if you can share, I'm curious about this > By focusing on whether Sybil’s findings are true positives or false positives, we measure what Sybil achieves instead of how Sybil got there. Prescriptive benchmarks that check "did the agent call API X, then Y?" risk over-indexing on mimicry. > AlphaGo moments for cybersecurity, where agents find attack paths no human would consider, won't come from coercing agents into retracing conventional patterns. Yes but what about having a term in the reward, so to speak, coming from some sort of process judge model? You get one bit of error signal from knowing whether a trajectory yields the right label, but potentially many bits from interrogating the process, yeah?