[BUG] Explicitly specifying `output_dimension` doesn't work for Gemini embedding API

[AurumnPegasus]

What is the use case?
Have some way of native implementation of either IVFFlat or HNSW (both of which are natively supported by pgvector) or allow for sending metadata to EmbedText class (say, to use MRL which Gemini provides via parameter config=types.EmbedContentConfig(output_dimensionality=768) )

Describe the solution you'd like
ideally as simple implementation where we can add config or params to EmbedText or Vector to implement these changes.

Additional context

---

❤️ Contributors, please refer to 📙Contributing Guide.
Unless the PR can be sent immediately (e.g. just a few lines of code), we recommend you to leave a comment on the issue like I'm working on it or Can I work on this issue? to avoid duplicating work. Our Discord server is always open and friendly.

[georgeh0]

Hi @AurumnPegasus , thanks for filing this feature request!

To make sure we understand correctly about your request. Two parts are mentioned here:

1. IVFFlat / HNSW. Currently we default to HNSW. We can expose an option to change the default and use IVFFlat instead of HNSW, by adding an option to VectorIndexDef.

2. For extra parameters passing to embedding, we already support specifying output_dimensionality in the EmbedText function. Does this already serve for your need? Or is there any other parameters you're looking for?

Thanks!

[AurumnPegasus]

For 1, extra option would be perfect (maybe additional param to also define number of clusters but a appropriate default should be fine too)

For 2, output_dimension doesn't work as expected. Here, what I wanted was to use MRL in gemini via the output_dimensionality parameter which is the input to the gemini client. In cocoindex's case, I dont understand how output_dimension works but I dont think it acts as an input to the client (since I constantly get

[2025-09-24T18:34:09Z ERROR cocoindex_engine::execution::source_indexer] Error in processing row from flow `CodeEmbedding` source `files` with key: {"utils.py"}

    Caused by:
        0: error returned from database: expected 256 dimensions, not 768
        1: expected 256 dimensions, not 768

error while doing cocoindex update main.py.

if helpful, here is my context:

@cocoindex.transform_flow()
    def code_to_embedding(
        text: cocoindex.DataSlice[str],
    ) -> cocoindex.DataSlice[NDArray[np.float32]]:
        """
        Embed the text using Google's Gemini model.
        """
        start_time = time.time()
        result = text.transform(
            cocoindex.functions.EmbedText(
                api_type=cocoindex.LlmApiType.GEMINI,
                model=Config.EMBEDDING_MODEL,
                output_dimension=Config.EMBEDDING_DIMENSION,
            )
        )
        elapsed = time.time() - start_time
        # Only log if it takes significant time
        if elapsed > 0.1:
            logging.debug(f"Text embedding completed in {elapsed:.3f}s")
        return result

    return code_to_embedding

here, the Config.EMBEDDING_DIMENSION = 256

[georgeh0]

Thanks for the detailed info. This is a bug - output_dimension is supposedly to be able to achieve this goal. We just fixed it and release a new version v0.2.13. Please have another try.

I created a separate issue #1049 for the request of vector indexing options.

[AurumnPegasus]

Hey @georgeh0 ,
took the latest fix, the solution seems to be working for text-embedding-004 where it directly takes output_dimensionality as input, but for gemini-embedding-001 (which takes config as input) it doesn't seem to work.

This is how it is supposed to work using gemini api

result = client.models.embed_content(
    model="gemini-embedding-001",
    contents="What is the meaning of life?",
    config=types.EmbedContentConfig(output_dimensionality=768)
)

[banrovegrie]

For gemini-embedding-001, I think the request has to carry the dimension twice. Once as outputDimensionality and again inside config={"outputDimensionality": …}, otherwise Gemini ignores the override.

I guess adding that nested entry should make the custom dimension stick without affecting models that already respect the top-level field?