-
-
Notifications
You must be signed in to change notification settings - Fork 492
New design for logs involving tool calls (and maybe tool classes) #1080
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The list of all tools made available to a model is important context, because even the fact that a model did not chose to execute a tool is important information. Log output should emphasize actual tool executions more than it does at the moment though. Also: right now a sequence of prompt->tool->tool-response->tool->tool-response-and-reply is represented as 3 full prompt-and-responses in the logs, even though the user only said one thing and got one response at the end. Maybe the header levels should adjust for that to help represent some responses as automated parts of that flow? |
Just running these two commands: llm -T simple_eval '1234 * 123415'
llm -c '* 33' Produced the following sequence of _four* logs entries, grouped under one conversation. I added
|
Here's a demo with multiple tool rounds from a single prompt: llm --functions '
def lookup_population(country: str) -> int:
"Returns the current population of the specified fictional country"
return 123124
def can_have_dragons(population: int) -> bool:
"Returns True if the specified population can have dragons, False otherwise"
return population > 10000
' 'Can the country of Manganolia have dragons?' --td Output:
logs -c With added
|
Here's a neater design for the logs without getting into the tool classes thing:
|
That example assumes tools stay constant throughout the conversation. I want to let users use I think replacing makes more sense: keep people in full control of what tools are available. Better for if you want to avoid accidental data exfiltration attacks - although it's not safe to hit potentially malicious tokens either before OR after obtaining private data so maybe that's completely irrelevant here. |
... but OK, if I assume that new design what could it look like with class-based tools like Playwright? Maybe this - with a special note for when the
|
I haven't thought very hard about what happens if the arguments or output from a tool call are really long. Or if a tool call returns an attachment, see: |
I'm bumping this from the stable tools release milestone for lack of time - currently it does this which isn't perfect (no instance information) but is usable:
|
Originally posted by @simonw in #1059
The text was updated successfully, but these errors were encountered: