Think of Experiments as a preview of what's to come. These projects are still under development, but we wanted to let the open-source community take them for spin! Use them, break them, and help us build what's next for Granite – we'll keep an eye out for feedback and questions in the Community section. Happy exploring!
Model Summary
Granite 3.2 8b Instruct - Uncertainty is a LoRA adapter for ibm-granite/granite-3.2-8b-instruct,
adding the capability to provide calibrated certainty scores when answering questions when prompted, in addition to retaining the full abilities of the ibm-granite/granite-3.2-8b-instruct model.
This is an experimental LoRA testing new functionality being developed for IBM's Granite LLM family. We are welcoming the community to test it out and give us feedback, but we are NOT recommending this model be used for real deployments at this time. Stay tuned for more updates on the Granite roadmap.
Certainty score definition The model will respond with a certainty percentage, quantized to 10 possible values (i.e. 5%, 15%, 25%,...95%).
This percentage is calibrated in the following sense: given a set of answers assigned a certainty score of X%, approximately X% of these answers should be correct. See the eval experiment below for out-of-distribution verification of this behavior.
Certainty score interpretation Certainty scores calibrated as defined above may at times seem biased towards moderate certainty scores for the following reasons. Firstly, as humans we tend to be overconfident in
our evaluation of what we know and don't know - in contrast, a calibrated model is less likely to output very high or very low confidence scores, as these imply certainty of correctness or incorrectness.
Examples where you might see very low confidence scores might be on answers where the model's response was something to the effect of "I don't know", which is easy to evaluate as not
being the correct answer to the question (though it is the appropriate one). Secondly, remember that the model
is evaluating itself - correctness/incorrectness that may be obvious to us or to larger models may be less obvious to an 8b model. Finally, teaching a model every fact it knows
and doesn't know is not possible, hence it must generalize to questions of wildly varying difficulty (some of which may be trick questions!) and to settings where it has not had its outputs judged.
Intuitively, it does this by extrapolating based on related questions
it has been evaluated on in training - this is an inherently inexact process and leads to some hedging.
Possible downstream use cases (not implemented)
Human usage: Certainty scores give human users an indication of when to trust answers from the model (which should be augmented by their own knowledge).
Model routing/guards: If the model has low certainty (below a chosen threshold), it may be worth sending the request to a larger, more capable model or simply choosing not to show the response to the user.
RAG: Granite Uncertainty 3.2 8b is calibrated on document-based question answering datasets, hence it can be applied to giving certainty scores for answers created using RAG. This certainty will be a prediction of overall correctness based on both the documents given and the model's own knowledge (e.g. if the model is correct but the answer is not in the documents, the certainty can still be high).
Important note Certainty is inherently an intrinsic property of a model and its abilitities. Granite Uncertainty 3.2 8b is not intended to predict the certainty of responses generated by any other models besides itself or ibm-granite/granite-3.2-8b-instruct.
Additionally, certainty scores are distributional quantities, and so will do well on realistic questions in aggregate, but in principle may have surprising scores on individual
red-teamed examples.
Usage steps There are two supported usage scenarios.
Scenario 1. Answering a question and obtaining a certainty score proceeds as follows. Given a user query written in the user role:
Use the base model to generate a response as normal (via the assistant role).
Prompt the model to generate a certainty score by generating in the certainty role (use "certainty" as the role in the chat template, or simply append <|start_of_role|>certainty<|end_of_role|> and continue generating), see examples below.
The model will respond with a certainty percentage, quantized with steps of 10% (i.e. 05%, 15%, 25%,...95%). Note, any additional text after the score and % can be ignored. You can curb additional generation by setting "max token length" = 3 when using this role.
Scenario 2. Predicting the certainty score from the question only, prior to generating an answer. Given a user query written in the user role:
Prompt the model to generate a certainty score by generating in the certainty role (use "certainty" as the role in the chat template, or simply append <|start_of_role|>certainty<|end_of_role|> and continue generating), see examples below.
The model will respond with a certainty percentage, quantized with steps of 10% (i.e. 05%, 15%, 25%,...95%). Note, any additional text after the score and % can be ignored. You can curb additional generation by setting "max token length" = 3 when using this role.
Remove the generated certainty string, and if desired, use the base model to generate a response as normal (via the assistant role).
Quickstart Example
The following code describes how to use the Granite Uncertainty model to answer questions and obtain intrinsic calibrated certainty scores. Note that a generic system prompt is included, this is not necessary and can be modified as needed.
The model was evaluated on the MMLU datasets (not used in training). Shown are the Expected Calibration Error (ECE) for each task, for the base model (Granite-3.2-8b-instruct) and Granite-Uncertainty-3.2-8b.
The average ECE across tasks for our method is 0.064 (out of 1) and is consistently low across tasks (maximum task ECE 0.10), compared to the base model average ECE of 0.20 and maximum task ECE of 0.60. Note that our ECE of 0.064 is smaller than the gap between the quantized certainty outputs (10% quantization steps). Additionally, the zero-shot performance on the MMLU tasks does not degrade, averaging at 89%.
