mhawksey / GeminiApp

GeminiApp is a library that allows integration to Google's Gemini API in your Google Apps Script projects. It allows for mutli-modal prompts, structured conversations and function calling
Apache License 2.0
67 stars 4 forks source link

support for gemini-1.5-pro-exp-0801 #7

Open sig-mandel opened 2 months ago

sig-mandel commented 2 months ago

When I tried to use that version of the model, the library returns an error about not finding the model. In the library I see the default version is "v1" and I found that changing it to "v1beta" makes it work.

However, if instead of modifying the library I try to use the library mechanism of adding "apiVersion" : "v1beta" to requestOptions, it does pick up that version in const apiVersion = this.requestOptions?.apiVersion || DEFAULT_API_VERSION; but later the API call fails with: Request to Gemini failed with response code 400 - { "error": { "code": 400, "message": "Invalid JSON payload received. Unknown name \"apiVersion\" at 'generation_config': Cannot find field.", "status": "INVALID_ARGUMENT",...

mhawksey commented 2 months ago

Hey @sig-mandel - so you are suggesting something similar to the Google published client libraries which auto switch the endpoint if you are using experimental models?

mhawksey commented 2 months ago

... I see in the Google client libraries they default to v1beta. Perhaps this is better?

sig-mandel commented 2 months ago

ah no, its ok to have to pass the version, but if you try to do so, the library fails because the google api (called from inside this library) doesnt like to receive extra properties.

sig-mandel commented 2 months ago

just to be clear, this library already has a mechanism to change the api version by setting "apiVersion" : "v1beta" in requestOptions, however doing so causes a problem, because that same requestOptions object is passed as-is to the Google API, and the Google api complains that there are extra unexpected properties in the object.

So the fix would be to generate a new, sanitized requestOptions before calling the google api, or to use an extra parameter on this library to set the api version instead of setting it in the requestOptions object (but that requires more code changes)

mhawksey commented 2 months ago

What you are saying is clear now, however, I don't think requestOptions make it into the url fetch as the _makeRequest only passes in params See https://github.com/mhawksey/GeminiApp/blob/main/src/GeminiApp.js#L51-L54

I've encountered issues in the past when making v1beta calls without updating the apiVersion but didn't realise it also extended to what model you used so think defaulting to v1beta makes sense. I need to do a refresh so will incorporate this in as an enhancement

sig-mandel commented 2 months ago

im not sure if its just a matter of the default. I get your point about the requestOptions not getting passed straight, but it does get passed indirectly: makerequest is called by generateContent, called by sendMessage. In there, see this line, where it sets generateContentRequest (called "params" in that called function) including the apiVersion that could be there.

Its easy to reproduce it you use a config like this one in the call: const generationConfig = { "temperature": 0, "top_p": 0.95, "top_k": 64, "maxOutputTokens": 8192, "apiVersion": "v1beta" }

mhawksey commented 2 months ago

Ah - I think it's not clearly documented about where apiVersion is added, it's an additional parameter outside of the generationConfig.

  const generationConfig = {
    stopSequences: ["red"],
    maxOutputTokens: 200,
    temperature: 0.9,
    topP: 0.1,
    topK: 16,
  };

  const model = genAI.getGenerativeModel({ model: "gemini-1.5-pro-exp-0801", generationConfig }, { apiVersion: 'v1beta' });
sig-mandel commented 2 months ago

aha! my issue was I was using the library wrong, sorry :( I was passing generationConfig in there instead of requestOptions, and thats why it was picking the version from there but later failing