#tried adding `Foo@...` prefix but then

1 messages · Page 1 of 1 (latest)

glossy sigil
#

(Tangential idea, curious if this had come up in previous discussions)

I had a vague idea while reading the current flat BBI code that it would be interesting to experiment someday w/ a different BBI implementation that gives the LLM tools for constructing IDs, so just primitives like Select, SelectNth, etc. Tricky part is you probably need a hefty context "prelude" explaining how IDs work and the current schema (so it knows what's valid to select, to provide as arg, etc).

I guess it comes down to whether LLMs do better with:

  1. A ton of tools for each specific operation
  2. A limited set of composable tools and more context on how to use them

Which I have no intuition around yet

sleek python
#

the currently-half-implemented GraphQL BBI is kinda sorta close to that

#

it has primarily three tools: install_module <ref>, run_query <query>, learn_schema <type>, plus a tool for converting a query to Go SDK code

glossy sigil
#

Oh nice, I had just skipped over that for now, neat guy_fieri_chef_kiss

sleek python
#

there's a working version of it in this PR: https://github.com/dagger/dagger/pull/9762 - maybe I should just consolidate them, I actually forgot about the BBI one 😅 (I think Solomon just copy-pasted it one day from my hackathon)

#

and yeah, it's a lot of prompt engineering, teaching it how to construct queries, pass IDs around, how queries translate to the Go SDK, etc

#

but the results were pretty good

glossy sigil
#

Nice, yeah and the conversion to code also opens up the possibility of converting between code in different languages too... interesting 🧐

sleek python
#

yup yup - was hoping to do all the SDKs, following the GraphQL as a hub in a hub-and-spokes scheme

#

I started experimenting with teaching it dagger shell over the weekend instead of GraphQL, since being able to set and use vars in one shot would work a lot better than GraphQL, which currently requires multiple trips

#

BUT - theoretically it could pre-construct IDs client-side, too

#

actually that might be hard, it'd need to know the protobuf wire format for them too lol

glossy sigil
# sleek python actually that might be hard, it'd need to know the protobuf wire format for them...

Yeah I guess I was imagining that it could happen server-side and would use the same idea as "flat" where it just sees digests, but it can construct new IDs with select primitives. So then it wouldn't have to figure out protobuf, it just sees digests that it can operate on. I suppose that requires it can keep really good track of digests and what to work with, so may actually just lead back to the same problem you have now where digests confuse it.

#

We just need 10k GPUs to train a foundational model on our API

sleek python
#

I'm not 100% sure if it got confused because it was a digest, or because it couldn't identify that it didn't have the tools it needed because it had to take the next step first, because it had to go Git (current state) -> GitRef (head) -> Directory (tree - desired state for reading the README)

#

I'm leaning towards the latter now that I made a few attempts to clarify the digest

#

The GraphQL BBI might even have the same issue, since it only learns one schema type at a time thinkspin

glossy sigil
#

I'm sure you saw in claude code the /compact option. I haven't used it yet but curious how that actually works and if it would be of use to us

sleek python
#

Yeah I gave that a try, based on its behavior my first guess is that it just generates a text summary of the message history so far, and starts a new chat with that single summary message as the history