In the last video, you learned how to evaluate an output in an example where it had the correct answer. You were able to write down the function to explicitly tell us if the language model (LM) outputs the right categories and list of products. However, when the LM is used to generate text, there isn’t just one right piece of text. Let’s take a look at an approach for evaluating that type of output.
Here’s my usual helper functions given a customer message. Tell me about the SmartX profile and the camera, and so on. Here are a few utils to get me the assistant answer.
This is basically the process that the user has stepped through in earlier videos. And here’s the assistant answer: ‘Sure, we have the Hope smartphone, the SmartX Pro phone, and so on and so forth.’
So, how can you evaluate if this is a good answer or not? It seems like there are lots of possible good answers. One way to evaluate this is to write a rubric, which is a set of guidelines to evaluate this answer on different dimensions and then use that to decide whether or not you’re satisfied with this answer.
Let me show you how to do that. Let me create a little data structure to store the customer message as well as the product info. So here, I’m going to specify a prompt for evaluating the assistant answer using what’s called a rubric. I’ll explain in a second what that means.
But this prompt says, ‘In the system message, you’re an assistant that evaluates how well the customer service agent answers the user question, but look in the context that the customer service agent is using to generate a response.’ So, this response is what we had further up the notebook, which was the assistant answer. And we’re going to specify the data in this prompt, which is the customer message, the context, the product, and category information, and the output of the LM.
This is a rubric, and it specifies what we think the answer should get right for us to consider it a good answer. Then finally, we want to print out ‘Yes’ or ‘No’ and so on.
If we were to run this evaluation, this is what you get. It says the assistant response is based on the content provided. It does not, in this case, seem to make up new information. There isn’t any disagreement between the response and the context. So, we would look at this output and maybe conclude that this is a pretty good response.
One note here, I’m using the GPT-3.5 Turbo model for this evaluation. For a more robust evaluation, it might be worth considering using GPT-4 because even if you deploy GPT-3.5 Turbo in production and generate a lot of text, if your evaluation is the most sporadic exercise, then it may be prudent to pay for the somewhat more expensive GPT-4 API call to get a more rigorous evaluation of the outputs.
One design pattern that can help you take away from this is that when you can specify a rubric, meaning a list of criteria by which to evaluate an LM output, then you can actually use another API call to evaluate your first LM output.
Another design pattern that could be useful for some applications is if you can specify an ideal response. So here, I’m going to specify a test example where the customer message is ‘Tell me about the SmartX profile and so on,’ and here’s an ideal answer. This is if you have an expert human customer service representative write a really good answer. The expert says this would be a great answer.
Of course, the SmartX profile and so on. It goes on to give a lot of helpful information. Now, it is unreasonable to expect any LM to generate this exact answer word for word. But it turns out there’s an even better way.
You can use a prompt, which you want to specify here to ask the LM to compare how well the automatically generated customer service agent output corresponds to the ideal expert human-written response. And so, we’re going to give it the data, which is the customer request, the expert-written ID response, and what the LM actually output.
This rubric comes from the OpenAI open-source evals framework, which is a fantastic framework with many evaluation methods contributed both by OpenAI developers and by the broader open-source community. In this rubric, we tell the LM to compare the factual content and the stylistic answer of the expert answer, ignore differences in style, grammar, or punctuation, and feel free to pause the video and read through this in detail.
The key is we ask it to carry the comparison and output a score from A to E, depending on whether the submitted answer is a subset of the expert answer and is fully consistent with it, or the submitted answer is a superset of the expert answer but is fully consistent with it. This might mean it hallucinated or made up some additional facts, or it contains all the details as an expert answer. Whether there is disagreement or whether the answers differ, but these differences don’t matter from the perspective of actuality.
The LM will pick whichever of these seems to be the most appropriate description. So here’s the assistant answer that we had just now. I think it’s a pretty good answer, but now let’s see what happens when it compares the assistant answer to the test set. It looks like it got an A and concludes that there’s no disagreement between the submitted answer and the expert answer. It correctly assesses this to be a pretty terrible answer.
So, I hope you take away from this video two design patterns. First, even without an expert-provided ideal answer, if you can write a rubric, you can use one LM to evaluate another LM’s output. And second, if you can provide an expert-provided ideal answer, then that can help your LM better compare if a specific assistant output is similar to the expert-provided ideal answer. I hope that helps you to evaluate your LM system’s outputs so that both during development and when the system is running and you’re getting responses, you can continue to monitor this performance and also have these tools to continuously evaluate and keep on improving the performance of your system.
