feat: Skunksworks - show consuming the "event" from Star-Search SSE #3367
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is a skunkswork followup to: https://github.com/open-sauced/api/pull/787
which shows how we can consume the "event" type from a SSE (in this case, the function call) and it's associated payload.
This could then be taken to render some components on the client side depending on the function call the model decided to use. This more or less replicates how Vercel's AI SDK works (but without the server side rendering and heavy lifting calling OpenAI happening in the SSE code).
Example, something like:
In this example ^ I asked a question about Brandon and got back from the server the "searchPrsByAuthor" function call that the model decided to make. In the "data" for that event type, we also get parsable JSON that can be used.
The really tricky thing here is the non-deterministic nature of the model:
1. LLM non-determinism
We can't always be sure the model will use the functions properly (for example, sometimes it doesn't include a required argument in the function call parameters and it has to go back and try again, which, on the second attempt, it usually gets right). For example:
Here, in this example, it tried to use "searchPrsByAuthor" and "searchIssuesByAuthor" without the required "author" field in the parameters. Thankfully, the Zod strongly typed parameters made it go back and try again. And on the second attempt it got it.
We can probably correct for alot of this by ensuring that the client here always has very strongly typed parameter classes that are used to insure the incoming json is correct. If not, we simply throw it out and don't render something and let it say what it'll say.
2. Using "special" tools/functions for rendered components
On the API side, we might consider instructing the model to be aware of some special tools/functions it has access to that get used when it thinks it should render some components on a client that's connected. This, again, delves into the realm of prompt-engineering so we should find one or two really good use cases to prove out the pattern. Maybe renderding the lottery factor table would be a good example. We instruct the model that it has a "renderLotteryFactorTable" function it can call when there are queries about lottery factor for specific repos. That would return a payload like:
which could be parsed and using the
kubernetes/kubernetes
repo name, we render that table.Related Tickets & Documents
Related to #3353
Mobile & Desktop Screenshots/Recordings
Steps to QA
You'll need a dev server from the API skunkworks PR mentioned early.
Tier (staff will fill in)
[optional] What gif best describes this PR or how it makes you feel?