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

LLM that can call multiple tool APIs with one request

cohere.com

Post reply on HN
Print view View original

11–20 of 69 posts

Re: LLM that can call multiple tool APIs with one request

#11

Post by verdverm »

TZubiri wrote: post #8
madrox wrote: post #2

I have a saying: "any sufficiently advanced agent is indistinguishable from a DSL" If I'm really leaning into multi-tool use for anything resembling a mutation, then I'd like to see an execution plan first. In my experience, asking an AI to code up a script that calls some functions with the same signature as tools and then executing that script actually ends up being more accurate than asking it to internalize its a…

I think you are imagining a scenario where you are using the LLM manually. Tools are designed to serve as a backend for other GPT like products. You don't have the capacity to "audit" stuff. Furthermore tool execution occurs not in the LLM but in the code that calls the LLM through API. So whatever code executes the tool, it also orders the calling sequence graph. You don't need to audit it, you are calling it.

People want to audit the args, mainly because of the potential for destructive operations like DELETE FROM and rm -rf /

How do you know a malicious actor won't try to do these things? How do you protect against it?

Re: LLM that can call multiple tool APIs with one request

#12

Post by TZubiri »

verdverm wrote: post #11
TZubiri wrote: post #8

Earlier quoted context omitted.

I think you are imagining a scenario where you are using the LLM manually. Tools are designed to serve as a backend for other GPT like products. You don't have the capacity to "audit" stuff. Furthermore tool execution occurs not in the LLM but in the code that calls the LLM through API. So whatever code executes the tool, it also orders the calling sequence graph. You don't need to audit it, you are calling it.

People want to audit the args, mainly because of the potential for destructive operations like DELETE FROM and rm -rf / How do you know a malicious actor won't try to do these things? How do you protect against it?

"the args"

You need to be more specific. In a systems, everything but the output is an argument to something else. Even then the system output is an input to the user.

So yeah, depending on what argument you are talking about you can audit it in a different way and it has different potential for abuse.

Re: LLM that can call multiple tool APIs with one request

#13

Post by viraptor »

verdverm wrote: post #11
TZubiri wrote: post #8

Earlier quoted context omitted.

I think you are imagining a scenario where you are using the LLM manually. Tools are designed to serve as a backend for other GPT like products. You don't have the capacity to "audit" stuff. Furthermore tool execution occurs not in the LLM but in the code that calls the LLM through API. So whatever code executes the tool, it also orders the calling sequence graph. You don't need to audit it, you are calling it.

People want to audit the args, mainly because of the potential for destructive operations like DELETE FROM and rm -rf / How do you know a malicious actor won't try to do these things? How do you protect against it?

Whitelisting and permissions. You can't issue a delete if anything not starting with SELECT is rejected. You can't have edge cases that work around that via functions, if the user the agent uses doesn't have permissions other than SELECT.

Re: LLM that can call multiple tool APIs with one request

#14

Post by fzeindl »

madrox wrote: post #2

I have a saying: "any sufficiently advanced agent is indistinguishable from a DSL" If I'm really leaning into multi-tool use for anything resembling a mutation, then I'd like to see an execution plan first. In my experience, asking an AI to code up a script that calls some functions with the same signature as tools and then executing that script actually ends up being more accurate than asking it to internalize its a…

> ... code up a script that calls some functions with the same signature as tools and then executing that script actually ends up being more accurate than asking it to internalize its algorithm.

This is called defunctionalization and useful without LLMs as well.

Re: LLM that can call multiple tool APIs with one request

#15

Post by darkteflon »

TZubiri wrote: post #9
darkteflon wrote: post #6

Earlier quoted context omitted.

You mean manually pre-baking a DAG from the user query, then “spawning” other LLMs to resolve each node and pass their input up the graph? This is the approach we take too. It seems to be a sufficiently performant approach that is - intuitively - generically useful regardless of ontology / domain, but would love to hear others’ experiences. It would be nice to know if this is sort of how OpenAI’s native “file_search”…

No. The DAG should be "manually pre-baked" ( defined at compile/design time). In runtime you only parse the "user question" (user prompt) into a starting and end node, which is equivalent to a function call. So the question "What league does Messi play in?" Is parsed by the llm as League("Messi") So if your dag only contains the functions team(player) and league(team), you can still solve the question. But the llm is…

That’s very interesting. Does designing the DAG in advance imply that you have to make a new one for each particular subset of end-user questions you might receive? Or is your problem space such that you can design it once and have it be useful for everything you’re interested in?

My choice of words was poor: by “pre-baking”, I just meant: generated dynamically at runtime from the user’s query, _before_ you then set about answering that query. The nature of our problem space is such that we wouldn’t be able to design DAG in advance of runtime and have it be useful everywhere.

The answering process itself is then handled by deterministically (in code) resolving the dependencies of the DAG in the correct order, where each node might then involve a discrete LLM call (with function) depending on the purpose. Once resolved, a node’s output is passed to the next tier of the DAG with framing context.

Re: LLM that can call multiple tool APIs with one request

#16

Post by verdverm »

viraptor wrote: post #13
verdverm wrote: post #11

Earlier quoted context omitted.

People want to audit the args, mainly because of the potential for destructive operations like DELETE FROM and rm -rf / How do you know a malicious actor won't try to do these things? How do you protect against it?

Whitelisting and permissions. You can't issue a delete if anything not starting with SELECT is rejected. You can't have edge cases that work around that via functions, if the user the agent uses doesn't have permissions other than SELECT.

"please get all the entries from the table foo and then remove them all"

SELECT * from foo; DELETE FROM foo ...

...because you know people will deploy a general SQL function or agent

Re: LLM that can call multiple tool APIs with one request

#17

Post by verdverm »

TZubiri wrote: post #12
verdverm wrote: post #11

Earlier quoted context omitted.

People want to audit the args, mainly because of the potential for destructive operations like DELETE FROM and rm -rf / How do you know a malicious actor won't try to do these things? How do you protect against it?

"the args" You need to be more specific. In a systems, everything but the output is an argument to something else. Even then the system output is an input to the user. So yeah, depending on what argument you are talking about you can audit it in a different way and it has different potential for abuse.

The args to a function like SQL or TERMINAL

Re: LLM that can call multiple tool APIs with one request

#18

Post by viraptor »

verdverm wrote: post #16
viraptor wrote: post #13

Earlier quoted context omitted.

Whitelisting and permissions. You can't issue a delete if anything not starting with SELECT is rejected. You can't have edge cases that work around that via functions, if the user the agent uses doesn't have permissions other than SELECT.

"please get all the entries from the table foo and then remove them all" SELECT * from foo; DELETE FROM foo ... ...because you know people will deploy a general SQL function or agent

1. Lots of libraries prevent you from submitting multiple queries. It's a good idea to do that in general.

2. If only the second part of my message covered this...

Re: LLM that can call multiple tool APIs with one request

#19

Post by verdverm »

viraptor wrote: post #18
verdverm wrote: post #16

Earlier quoted context omitted.

"please get all the entries from the table foo and then remove them all" SELECT * from foo; DELETE FROM foo ... ...because you know people will deploy a general SQL function or agent

1. Lots of libraries prevent you from submitting multiple queries. It's a good idea to do that in general. 2. If only the second part of my message covered this...

1 & 2. requires that you audit the agents and have uniform permissions, or additional plumbing to lookup user permissions and pass those along.

Have you looked at the agents prepackaged in popular frameworks? They aren't doing permission propagation or using additional libraries as guardrails.

What are most people going to do? This is why people are hesitant and ask about auditability

Considering 2 further, I only described deletion. A read-only database is of limited value. If you have write permissions, you could alternatively change values maliciously, even if you disable deletions. This might not be a malicious, and could be the result of an LLM error or hallucination.

Re: LLM that can call multiple tool APIs with one request

#20

Post by TZubiri »

verdverm wrote: post #16
viraptor wrote: post #13

Earlier quoted context omitted.

Whitelisting and permissions. You can't issue a delete if anything not starting with SELECT is rejected. You can't have edge cases that work around that via functions, if the user the agent uses doesn't have permissions other than SELECT.

"please get all the entries from the table foo and then remove them all" SELECT * from foo; DELETE FROM foo ... ...because you know people will deploy a general SQL function or agent

That'S not how it works. The user questions are expressed in business-domain language.

"give me the names of all the employees and then remove them all"

is parsed, maybe as: " employees(), delete(employees())".

It's up to the programmer to define the available functions, if employees() is available, then the first result will be provided, if not it won't.

If the functoin delete with a list of employees as parameter is defined, then that will be executed.

I personally work with existing implementations, traditional software that predates LLMs, typically offered through an API, there's a division of labour, a typical encapsulation at the human organizaiton layer.

Even if you were to directly connect the database to the LLM and let GPT generate SQL queries (which is legitimate), the solution is user/role based permission, a solution as old as UNIX.

Just don't give the LLM or the LLM user-agent write permissions.

Post reply on HN