-
Notifications
You must be signed in to change notification settings - Fork 1
Track metrics in OpenAI functions #16
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
Conversation
| import java.util.Collections; | ||
| import java.util.List; | ||
|
|
||
| public class P99LatencyTracker { |
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.
I’m not completely satisfied that I had to create this class manually. It would have been much better to use the existing Histogram class here. Since this is just a temporary solution until we can integrate the org.apache.flink:flink-metrics-dropwizard dependency, I opted not to implement a more performant solution for 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.
I see your point. I think this is good enough for now and we can adjust once we get customer feedback.
mbroecheler
left a comment
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.
This is a good first stab, thank you. Please DRY a bit.
| @AutoService(ScalarFunction.class) | ||
| public class completions extends ScalarFunction { | ||
|
|
||
| public static final String P99_METRIC = "com.datasqrl.openai.completions.p99"; |
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.
You have the same code here 3 times. Move this into a utility class that takes the function name as the argument and DRYies the code.
| import java.util.Collections; | ||
| import java.util.List; | ||
|
|
||
| public class P99LatencyTracker { |
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.
I see your point. I think this is good enough for now and we can adjust once we get customer feedback.
| @Override | ||
| public void open(FunctionContext context) throws Exception { | ||
| this.openAICompletions = createOpenAICompletions(); | ||
| this.latencyTracker = new P99LatencyTracker(100); |
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.
Make 100 a static variable.
… to difference in formatting
mbroecheler
left a comment
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.
It looks good. I made a suggestion to combine the helper classes. This is not a must-have but I recommend you implement it because we are trying to find the patterns that we can use across functions. Hence, investing some more time into cleaning that up will pay dividends.
| public String eval(String prompt, String modelName, Double temperature, Double topP) { | ||
| return executeWithRetry( | ||
| () -> openAICompletions.callCompletions(prompt, modelName, true, null, temperature, topP) | ||
| if (prompt == null || modelName == null) return null; |
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.
My suggestion is to move the executeWithRetry method into the FunctionMetricTracker so that you can make the code DRYer. In fact, I think we can combine those two helper classes. Whenever you execute some function with retry, you also want to count how many times you executed it and how many failures you have. Keeping these two helper clases orthogonal, makes it awkward to use and leads to more code.
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.
Thanks @mbroecheler! I was thinking about improving it further, but my understanding was that the retry utility is a temporary thing until we start using asynchronous functions. Does it make sense to improve it further if we are going to replace it anyway?
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.
@nandorsoma, yes, we will move to async eventually. That's why it would be nice to have all code related to retries and metrics on function invocations encapsulated in one class. Then we would only have to update the helper class and not the body of every function implementation.
For now, it mostly gives us better architectural encapsulation as we are learning how to implement functions.
|
@mbroecheler I've introduced another helper class because it felt weird to execute through the MetricsTracker. Especially that in good circumstances we could swap out the MetricsTracker to a more robust one. Let me know if it looks good. Based on our recent discussion, later I can add the vector similarity check to this PR, but if you want to merge as is, I can open a separate PR for that. |
mbroecheler
left a comment
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.
Looks good. Thank you
This PR adds metrics to the openai functions.
To test it call this api few times:
Then query for the metrics on these urls. Dont forget to replace the job and vertice id.