AgentM: A library of "Micro Agents" that make it easy to add reliable intelligence to any application

Community
21

Very true… but you still need to acquire the structured columns to sort on and I’m simply proposing you’d use mapList for that. If you have a bunch of research papers your processing or even just a stack of customer support tickets you can use mapList to do your extraction

1 Like
22

The problem is the data model. But that’s solvable.

23

I’d say the model can give a datamodel / structure / entity.
Which can lead to a nice json which leads to a schema for evaluation. Maybe the example was just not wide enough.

When you have data of bacteria with hundrets of thousands of attributes this might be difficult.

24

I see. You made a good point about the size of the data which I had not considered due to my tunnel vision from the example. I can imagine a big data use case where precision trumps cost. Anyway, thanks again for sharing!

25

So abstracting this a little bit, essentially

the goal of “sort this dataset by release year” devolves into the following subgoals:

if dataset is not annotated: # does not have types of different columns"
       use llm to annotate (and store the annotation for reuse) 
if there is no sort function associated with the specific column: 
       use llm to generate  sort function (and the store the function for potential reuse)

Use traditional means to sort.

So now we can plug in different data catalogs into the mix of things; so that as new data sets are discovered, they cen also be meaningfully governed.

1 Like
26

By the end of the day your response sure had some impact and will be concidered.
Maybe a parameter “cheapmode=true” would be good.

27

I’ve been wondering about how you’d want to implement something like zip, but you’d quickly get into the weeds

  1. do you want it fast? (i.e. parallel, with instruction duplication)
  2. do you want it token efficient? (i.e. sequential, one shot)
  3. do you want to use completion models only (i.e. no embedding)
  4. how robust do you want it to be?
    • against adverse input (i.e. self prompting for anchor/reference optimization)
    • against adversatial input

Can there actually be a “good” first principles implementation, or do you have to benchmark and red-team everything?

Perhaps a cheapmode/velocity/cost/speed might make sense for the standard options parameter in the template

there’s the parallel executions parameter but I don’t know if that’s all that useful on a per-agent basis - I think that you’d want a scheduler handle request buffering, packaging, and dispatch. :thinking:

Edit:

all that said, I’m not trying to dissuade anyone from just slapping something down to get it working from a functional perspective. I think that’s also super valuable.

1 Like
28

I sometimes joke with clients that you can choose 2 of the 3…

  1. Get it fast
  2. Get it Cheap
  3. Get it done well
3 Likes
29

You’re gonna have to settle for one in this case I’m thinking :laughing:

2 Likes
30

If we just look at sort algorithms for a moment, they each have their tradeoffs; some do really well for large sets, some do well for smaller sets, and others do will if the set is mostly sorted.

Most sort algorithms that we actually use, like Tim sort, are actually a hybrid of other algorithms and they’re designed to make tradeoffs based on the set size. They’ll use one algorithm for small sets and a different algorithm for large sets.

I think the same principals apply here. I’m initially focused on building out a raw set of primitives that require you select which primitive or strategy you want to use based on your specific scenario. I think over time we’ll see higher level abstractions layered on top of those primitives that make those choices for you.

2 Likes
31

The Java strategy, I see :laughing:

1 Like
32

Maybe a handful are enough to create abstract layers by themself…

Maybe better spent more time on research for an evaluation with a killswitch…