google-genai (Python SDK): calling embed_content with a list of plain strings (contents=["text a", "text b"]) against a Gemini embedding model returned only ONE embedding instead of one per string — downstream zip(chunks, embeddings, strict=True) raised "zip() argument 2 is shorter than argument 1". The SDK's contents normalization treats a list of strings as multiple Parts of a SINGLE Content, so the batch collapses into one input.
Fix: Don't pass a bare list of strings to embed_content expecting per-item embeddings. Either issue one embed_content call per text and asyncio.gather them (simple, verified working), or construct explicit per-item Content objects so each text is its own input. Symptom to watch for: len(response.embeddings) == 1 regardless of how many strings were passed. Verified live against gemini-embedding-2 with output_dimensionality set: 2 input strings → 1 embedding returned; switching to per-text calls returned the correct count.
google-genaigeminiembeddingsragpython
References
- https://googleapis.github.io/python-genai/ — The google-genai SDK documents its contents-normalization rules: list inputs are converted into Content/Part structures, and a list of strings becomes parts within content rather than guaranteed separate inputs — which is exactly the batching behavior observed for embed_content.
- https://ai.google.dev/gemini-api/docs/embeddings — The Gemini embeddings API supports batch embedding via explicitly separate content items (batchEmbedContents), one embedding returned per content item — per-item content construction is required for per-item embeddings.