Update ChatCompletionSummary attribute datatypes

[kaylareopelle]

While doing an audit on the response header datatypes, I thought I'd check the other event types. It looks like only request.temperature and request.max_tokens needed updates.

Since these values come from the user, we can't be certain of the data type.

In the spec, request.temperature can be a float or an integer. To simplify the logic, I'm always assigning it as a float because a float is more specific than an integer. request.max_tokens must be an integer.

The LLM event tests already use the correct datatypes.

[github-actions]

SimpleCov Report

	Coverage	Threshold
Line	93.71%	93%
Branch	71.21%	71%

[fallwith]

@kaylareopelle @hannahramadan sometime later, possibly post-GA, I'd like to circle back to our earlier discussion about this style of essentially performing ActiveSupport::HashWithIndifferentAccess style look-ups. Earlier I was concerned about DRY from the human dev perspective, and now I'm concerned about all of these new string objects being instantiated every time a look-up is performed. It's possible that Ruby is lazy with the string initialization and won't perform it unless the symbol look-up fails and the || or hit. I'd like to better understand the impact and explore our options.

I'm thinking we could do something like this:

class AiClass
  KEYS = %i[max_tokens model temperature].each_with_object({}) do |k, h|
    h[k] = k.to_s.freeze }.freeze
  end

  def ai_method(parameters = {})
    tokens = hash_lookup(parameters, :max_tokens).to_i
    model = hash_lookup(parameters, :model)
    temp = hash_lookup(parameters, :temperature).to_f
    [tokens, model, temp]
  end

  private

  def hash_lookup(hash, key_as_symbol)
    hash[key_as_symbol] || hash[KEYS[key_as_symbol]]
  end
end

ai = AiClass.new
params = {'max_tokens' => 4, model: 'b', 'temperature' => 85}
result = ai.ai_method(params)
pp result

[hannahramadan]

James I like this and have capture this in a ticket to revist, most likely post GA!