I wonder if the graph part is a distraction (data representation / syntax), and once you step back, if/how this relates to the wider concept of 'durable task lists' used in this kind of structured dynamic planning.
Ex: Durable task lists generally use more textual representations, eg, a hierarchical text list that supports named references -- so a graph. Likewise, they're mutable, contain statuses, etc. They're fairly popular and AI models at this point have internalized them at this point.
I mean, sentences themselves are graphs of data and context with connectors of various types. Embeddings within these models help form the links to the underlying semantic concepts.
Directly representing things as a graph would likely reduce some of the 'translation overhead', done correctly.
I'm not so sure on the latter -- that introduces a bunch of tool calls, while the text patches are much closer to the semantic space imo and easy for harnesses
If we rephrase this as instruction following alignment, what is the concern here in practice vs a skill? (Which a model eventually internalizes)
It doesn't detract from the research - as a paper, it shows more crisply the structure is useful. I'm just not sure how necessary the encoding, and given durable tasks, novel the insight. Is there new alpha here somewhere, esp given the similarity?
It's been interesting investing into different classic verification & testing methods for gfql (CPU/GPU graph queries on dataframes) and Louie (agentic investigation harness) over the last couple of years with different model & harness generations. The ones below are fewer but more longitudinal efforts compared to the shallower ones Dan worked through, and seem largely consistent:
Overall, my takeaway on standard software has been LLMs favor smart, guided fuzzing, natural language specifications deployed as iterative parallel adverserial AI review (e.g., context-reset subagents) after the functional prototyping. For formal methods / static analysis, cheaper/faster/lighter ones, though for the next level of quality, I can see this changing. The concolic testing world's heuristic results carried through a lot for me vs most others, which is unsurprising as they went deep on engineering ROI curves for fuzzing large code bases and specializing for different bug classes.
Highlights:
- alloy for gfql fell on its face relative to fuzzing, even with guidance. This was disappointing as it was intended as a cheap experiment to justify doing more expensive formal methods.
- prompts & skills need tuning: auto-memory doesn't transfer across harnesses by default, and one-shot auto-authored skills evals badly. More about iterating. Manual version of iterating would be editing skills when we hit new/repeat classes of bugs, though not guaranteed faithfulness: this is what we do the most. Positive experiments automating here, but not enough to invest deeper when we have to do manual anyways.
- natural language specifications are now a thing. Our significant new features now come with a security.md, policy.md, concurrency.md, etc., and important for them to be close to the code and taught to the review skill. Coding and review agents then can triangulate between tests, specs, code, and their own skills & general knowledge. However, we find we prefer not to do localized invariants in method comments as that gets verbose and drifts, and instead, do those as tests. This gets a bit into the global cost question of better code gen iterations and/or better review phases.
- staging coding vs reviewing. Overtesting early kills progress, so we stage heavier quality engineering at the end, and architectural research at the beginning.
- Lessons from the concolic execution era: staging static LLM analysis early with dynamic LLM testing later. Test amplify findings by area, kind, etc to convergence.
- We love community suites. GFQL builds against known Cypher language standards correctness conformance and benchmark suites, and Louie tools often start with community agent evals/benchmarks before we add our own specializations.
I don't know how big and deep the experiment Dan ran was. Something like formal methods is generally a big & invasive investment, and the target of each kind is often a much higher quality rating for a narrow set of properties. This complicates benchmarking setup. Imagine building entire compilers, and experimenting with different combos of methods & having those methods come in at different times & places.
I expect the AI security vulnerability analysis world to have similar findings. We end up baking that into our review harness as well without changing our overall methods above.
... And it looks like everyone keeps using the same security startup to run the higher risk tasks, where individual staffers may be great yet, yet as an organization, the biggest labs got hosed in different ways
That indemnity card excuse is burned, multiple public security fails in a year makes a repeat a "shame on you" moment
(The one org who didn't use the startup did seem to learn: AISI supposedly stopped intentionally pointing attack agents at the public internet and switched to simulating it)
Moving towards streaming and generally out-of-core is great
We recently added a Polars backend to GFQL (cypher graph queries on dataframes, no DB needed), both CPU and GPU mode, and super impressive. Noticeable improvements vs pandas/cudf, and enabled GFQL to beat out popular systems on more categories like low-latency, not just big datasets: https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-gra...
For those into the `pip install ...` flow and kuzu, is gfql: we started around the same time in a non-VC-funded oss manner with overlap in key architectural ideas:
- cpu columnar vectorized engine + optionally the only open source gpu engine mode for bigger graphs / faster queries
- removes the need for a database / file: pure compute-tier engine you can write to parquet/json if you want, plays with parallel reader/writers in simple ways b/c that, and TBD iceberg
- adds full graph analytic pipeline support, eg, for feature engineering in real-time fraud & memory pipelines
- also millisecond/submillisecond times on small graphs like that small 100K edge graph benchmark
Main box not formally checked is streaming. Funny enough, we're designed for GPU firehose workloads, so would be fun to demo and see what gaps are left.
Interestingly, while we don't fine-tune generative models for Louie.ai, we found fine-tuning embedding models to be a major $ saver. Instead of 1K-2K wide frontier embedding vector lens... Just 64. Huge savings on vector DB $$$.
I'm curious how that works with something like turboquant. Not needed any more, still dominant, better together, ... .
It's been fascinating doing a custom variant for GFQL, the first OSS embeddable Cypher property graph query engine for CPU+GPU -
- accelerated launch of our new backends like polars, including a new lazy mode & planner, which are fundamentally new paths
- while we initially aimed for top GPU benchmark scores, we now also maintain top CPU scores too!
Long-term, more interesting to me is this opens rethinking what it means to be a query engine. Right now we are making it the fastest in general, especially on workloads from our own use, major industry benchmarks, and our users. At the same time, similar to jit and multistage computing, we're looking at new ahead-of-time optimization techniques users can do that are more interesting than plugging in custom indexes. Essentially, if our agents can do fast specializations, there should be safe hooks that we can expose to our user's agents too!
Fwiw, without naming names, I helped someone at a hackathon make their first app on something he was passionate about, later found out he had been recently homeless living on an abandoned boat, and now years later, afaict he turned that into a $10m/yr business with ~millions of users
Persistence > Intelligence , and being able to code isn't some sort of superiority thing, it's just one skill of many
Edit: being able to take risks, and doing so, does lead to higher variance outcomes, so that is something I have also come to appreciate and look for in people. It may look reckless, and attracts weirder people almost by definition, but that is what startups are ultimately about, betting you can do better than the regular path!
When I decided to code (later in life) I was determined to give it my best shot, not sweat the small stuff, just keep going. Previously I tried to learn but gave up assuming that it just wasn't my thing, but I decided this was my last shot and I was going to make it happen.
Some classmates of mine were (like everyone gets) frustrated at one point and actually complained that they were paired up "with those two". Those classmates thought that the other guy and I knew what we were doing and "just got it". Truth was we just kept our hands on the keyboard, had really not made anymore progress than anyone else in class had ... we just kept typing / trying things.
Years later I would say I'm still not a talented programmer, I just stay positive, help my coworkers, and keep gong until I make it happen, and as far as my employer is concerned that's pretty great.
Being homeless doesn't mean he's not intelligent though. He could have had some really bad luck or mental illness, while otherwise being analytically smart.
But I love the anecdote and agree with your point completely. Thanks for sharing.
Ex: Durable task lists generally use more textual representations, eg, a hierarchical text list that supports named references -- so a graph. Likewise, they're mutable, contain statuses, etc. They're fairly popular and AI models at this point have internalized them at this point.
reply