Choosing and Matching Embedding Models

How to pick an embedding model for a Spojit Knowledge collection, why the choice is locked in when the collection is created, and the rule that you must always embed and query with the same model.

Overview

When you store documents in a Spojit Knowledge collection, each document is broken into chunks and turned into a numeric representation so that the Knowledge node can later find the passages most relevant to a question. The model that produces those representations is the embedding model. Spojit offers two: Gemini Embedding 001 (the default, 3072 dimensions) and Text Embedding 004 (768 dimensions). The "dimensions" number is the length of the representation each model produces, and it is the main practical difference between the two: a higher-dimension model can capture more nuance, while a lower-dimension model produces smaller, faster-to-search representations.

The key thing to understand is that an embedding model is chosen once, at collection creation, and cannot be changed afterward. Every document you upload into that collection, and every query you run against it, must use the same model. Spojit applies the collection's model automatically when you query, so the main decision you make is at the moment you create the collection. This guide explains how to make that choice well, and how the matching rule plays out across Embed mode, Query mode, and transient collections.

Where You Choose the Model

You set the embedding model when you create a persistent collection. Open the Knowledge section in the sidebar, click New Collection, and give the collection a name and an optional description. The same dialog includes the embedding model selection. This is the only place the model is set, and once the collection exists the value is fixed.

The Knowledge node in Embed mode also exposes an Embedding Model field, but for a persistent collection this follows the collection's setting rather than overriding it. The field matters most for transient collections, described below, where there is no pre-created collection to inherit from.

Gemini Embedding 001 vs Text Embedding 004

Both models are good general-purpose choices. Use these guidelines to decide:

Gemini Embedding 001 (3072 dimensions, default): the best fit when retrieval quality matters most: dense technical content, policy documents, product catalogs, or any collection where questions are nuanced and the answer depends on small distinctions in wording. Start here unless you have a specific reason not to.
Text Embedding 004 (768 dimensions): a leaner option that produces smaller representations and faster searches. Reasonable for large collections of short, plainly worded documents, or when you simply prefer a more compact footprint and your test queries already return good matches.

If you are unsure, keep the default. The difference in retrieval quality for everyday content is usually modest, and the default avoids second-guessing.

The Matching Rule

The single most important rule is: always use the same embedding model to embed and to query a collection. Representations from Gemini Embedding 001 and Text Embedding 004 are not comparable to each other, so mixing them inside one collection produces poor or meaningless matches. Because Spojit fixes the model at collection creation and applies it for you on query, you generally cannot break this rule on a persistent collection by accident. The place to be careful is transient collections, where you select the model yourself in the Knowledge node.

For a transient collection, the embed step and the later query step run within the same workflow execution and share the same temporary collection, so you simply leave both on the default model (or set both the same) and the rule holds. Trouble only appears if you deliberately set different models on two Knowledge nodes that target the same transient collection. Keep them identical.

Steps

To create a collection and lock in its model:

Open the Knowledge section from the sidebar.
Click New Collection and enter a name and optional description.
Choose the embedding model: keep Gemini Embedding 001 for the strongest general retrieval, or pick Text Embedding 004 for a more compact, faster-search collection.
Create the collection, then open it and click Upload Document to add files with Upload & Embed. Every document you add now uses the model you selected.
When you build a workflow that reads from this collection, add a Knowledge node in Query mode and pick the collection. Spojit uses the collection's embedding model automatically; you do not re-select it.

For a one-off "embed then query and discard" within a single run, choose Transient in the collection dropdown on each Knowledge node instead, and leave both nodes on the same model.

Tips

Decide the model before you do a large upload. The model is fixed at creation, so if you change your mind later the only path is a new collection and a fresh embed of every document.
If you are not sure which model suits your content, create a small test collection with each model, upload a few representative documents, and compare the answers a Query-mode Knowledge node returns. Pick the model that retrieves the right passages.
For transient collections, let the Embedding Model field stay at its default on every node in the run so the embed and query steps always match without extra thought.
Keep your model choice consistent across collections that hold similar content. It makes results easier to reason about when you compare or troubleshoot collections side by side.

Common Pitfalls

Expecting to switch models later. There is no in-place change. Treat the choice at New Collection as permanent for that collection.
Mixing models in one transient collection. Setting one Knowledge node to Gemini Embedding 001 and another to Text Embedding 004 while both point at the same transient collection breaks retrieval. Use one model for both the embed and query nodes.
Blaming the model for empty or weak results. Poor matches are often caused by too few chunks, the wrong document type, or a vague prompt rather than the model. Check that documents show status READY and raise the Result Count on the Query node before swapping models.
Re-uploading into a wrongly configured collection. If a collection was created with the wrong model, uploading more documents will not fix it. Create a new collection with the right model and re-embed.