My api result is an array with the response broken up over multiple candidates about gemini-ai HOT 5 CLOSED

Done:

• #6
• Realse: Ruby Gemini AI 3.0.0
  • gem 'gemini-ai', '~> 3.0'
• generate_content
• Streaming vs. Server-Sent Events (SSE)

from gemini-ai.

Got it.

I infer that generateContent will eventually become deprecated, as the new API, Vertex, no longer includes this method. Regardless, you can use streamGenerateContent without streaming by choosing not to enable server-sent events (?alt=sse). Curiously, you can also use server-sent events with generateContent, even though it is not designed for "streaming". Yeah, this is confusing.

I would be inclined to distinguish between the concept of an HTTP request that creates a stream to receive server-sent events and the concept of streaming related to the expected behavior and output format of the endpoints.

Why? We have a lot of possible endpoints in the API:

• generateContent
• streamGenerateContent
• updateExplanationDataset
• predict
• rawPredict

All of them may support "streaming" (Server-Sent Events) or not.

I would prefer to keep the names of the methods faithful to the original names of the raw cURL API:

• client.generate_content
• client.stream_generate_content
• client.update_explanation_dataset
• client.predict
• client.raw_predict

Allowing any of them to be accessed through a standard HTTP request or by enabling server-sent events.

Perhaps the refactoring needed to eliminate ambiguity and confusion for users would be renaming stream to server_sent_events. This change would clearly distinguish the concept of streaming from SSE, I believe:

client = Gemini.new(
  credentials: { ... },
  options: { model: 'gemini-pro', server_sent_events: true }
)

client.stream_generate_content(
  { contents: { role: 'user', parts: { text: 'hi!' } } },
  server_sent_events: true
) do |event, parsed, raw|
  puts event
end

result = client.stream_generate_content(
  { contents: { role: 'user', parts: { text: 'hi!' } } },
  server_sent_events: false
)

result = client.generate_content(
  { contents: { role: 'user', parts: { text: 'hi!' } } },
)

client.generate_content(
  { contents: { role: 'user', parts: { text: 'hi!' } } },
  server_sent_events: true
) do |event, parsed, raw|
  puts event
end

Does that make sense?

from gemini-ai.

Hey @joshdaloewen, thanks for opening an issue.

result is different than what I get when I run a curl command to hit the API

May you please share your cURL command?

By running the code you shared, here's the underlying cURL equivalent generated by the Gem:

curl --request POST \
  --url https://generativelanguage.googleapis.com/v1/models/gemini-pro:streamGenerateContent?key=$GEMINI_API_KEY \
  --header 'Content-Type: application/json' \
  --data '{
  "contents": {
    "role": "user",
    "parts": {
      "text": "Write an essay on the history of Canada."
    }
  }
}'

from gemini-ai.

I figured it out, but I'm not sure how you'd want to handle it.

The problem is that

def stream_generate_content(payload, stream: nil, &callback)
     request('streamGenerateContent', payload, stream:, &callback)
end

uses the endpoint "streamGenerateContent" regardless of whether stream is true or false. But that endpoint should be "generateContent" when not streaming.

In my mind, the refactor that would be the most intuitive for users would be to:

1. remove stream from the user configuration all together
2. create stream_generate_content and generate_content methods, which hit request with the different endpoints and an internal stream parameter (see below)
3. refactor your request method so that it requires the stream argument, and then it handles it as it does currently

All that being said, you could also allow stream to be passed by the user, but perhaps stream_generate_content could have a less confusing name??

from gemini-ai.

Yeah I'm liking that, and I also strongly agree that keeping the method names the same as the raw API urls will be most intuitive moving forward.

from gemini-ai.