Add non-breaking TemperatureOpt field to ChatCompletionRequest that can be set to explicit zero. #983
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.
This PR adds a
TemperatureOpt *float32
field toChatCompletionRequest
, that allows distinguishing between an unset (default) temperature and explicit zero. This has been reported in several issues (e.g., #9), but this solution explicitly proposes a non-breaking change.OpenAI doc: https://platform.openai.com/docs/api-reference/chat/create#chat-create-temperature
The new field is taken into account via custom JSON marshaling/unmarshaling functions, resorting to the legacy
Temperature
field (now marked as deprecated) wheneverTemperatureOpt
is not set. The unmarshaling logic prioritizes the legacyTemperature
field whenever unambiguous to avoid incompatibilities;TemperatureOpt
is only used when necessary to represent an explicit zero. A newly addedGetTemperature()
method allows programmatic users to get the temperature value that would be used for marshaling.Note: There is one breaking change, which I think however can be regarded as sufficiently minor to justify ignoring it: when unmarshaling a
ChatCompletionRequest
with an explicit temperature setting of zero, then setting the legacyTemperature
field to zero, and then re-using/re-marshaling the request, the result will be a request with an explicit zero temperature, rather than (as would previously be the case) a default temperature setting. But this seems pretty fabricated to me.Testing is done via unit test, ensuring correct marshaling and unmarshaling behavior in various scenarious (no field set - default temperature, legacy field set, new field set, both field sets, explicit zero temperature).
Issues:
omitempty
option of request struct will generate incorrect request when parameter is 0. #9