-
Notifications
You must be signed in to change notification settings - Fork 25
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
Add support for function call start_callback #101
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
6e6657b
to
13ef0c6
Compare
@@ -7,6 +7,37 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 | |||
|
|||
## [Unreleased] | |||
|
|||
### Added | |||
|
|||
- Added support for function `start_callback` to provide immediate feedback |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
start_callback
feels like an odd name to me, but i see now that it was already established as a name with pipecat
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's a weird name, but it's the same name used in Pipecat...
CHANGELOG.md
Outdated
|
||
```python | ||
# Define a start callback | ||
async def before_check_availability(function_name: str, llm: Any, context: Any) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In context, the args here feel kind of arbitrary to me. I understand that start_callback
in pipecat
happens to be part of LLMService
so the arguments there are scoped to things that an LLMService
would know about, but...in the context of defining a flow, it doesn't make much sense why this callback would only have access to the LLM and the LLM context (as well as a function name, which is something we don't do for any other handler/action/what-have-you...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we could choose the args we wanted for this callback rather than just go with what pipecat
's LLMService
exposes, what would we want? I feel like we might want to provide the FlowManager
wholesale, like we decided to do for pre-/post-actions.
) -> None: | ||
if start_callback: | ||
try: | ||
# Pass flow_manager instead of llm and context |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I was trying to figure out why we had created a wrapper for it. I can see it now. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, this was in response to Paul's comment. We wanted to avoid using the default args from Pipecat and instead offer the FlowManager as an arg.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice improvement. 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥳
Pipecat's LLMServices support a
start_callback
before a function call runs. This callback allows you to execute functionality before the LLM function call. It's handy when you want to push a frame or run functionality before the function call takes place.