How to Fix 'embedding dimension mismatch' in AutoGen (TypeScript)

Opening

embedding dimension mismatch means the vector you’re trying to store or compare does not have the same length as the vector index expects. In AutoGen TypeScript, this usually shows up when you switch embedding models, reuse an existing vector store, or mix embeddings from different providers.

The error often appears during retrieval setup, memory writes, or when an agent tries to query a VectorStore backed by pgvector, Pinecone, Chroma, or another embedding database.

The Most Common Cause

The #1 cause is simple: your app is generating embeddings with one model dimension and querying a store built with another.

For example, text-embedding-3-small returns 1536 dimensions by default, while text-embedding-3-large returns 3072. If your collection was created with one and you later insert/query with the other, you’ll get errors like:

• •Error: Vector dimension mismatch
• •QueryFailedError: expected 1536 dimensions, got 3072
• •AutoGen retrieval failed: embedding dimension mismatch

Broken vs fixed pattern

// BROKEN: collection was created earlier with 1536-dim embeddings,
// but now you're using a 3072-dim model.
import { OpenAIEmbeddingModel } from "@autogen-ai/llm";
import { MemoryVectorStore } from "@autogen-ai/memory";

const embedder = new OpenAIEmbeddingModel({
  model: "text-embedding-3-large", // 3072 dims
});

const store = new MemoryVectorStore({
  collectionName: "support_docs", // existing collection may be 1536-dim
});

await store.addDocuments([
  { id: "1", text: "Policy renewal workflow" },
]);

// Later query hits mismatch
const results = await store.search("renewal process");

// FIXED: keep the embedding model and store dimension aligned.
import { OpenAIEmbeddingModel } from "@autogen-ai/llm";
import { MemoryVectorStore } from "@autogen-ai/memory";

const embedder = new OpenAIEmbeddingModel({
  model: "text-embedding-3-small", // 1536 dims
});

const store = new MemoryVectorStore({
  collectionName: "support_docs_v2", // new collection for new dimension
});

// Make sure both indexing and querying use the same embedder config.
await store.addDocuments(
  [{ id: "1", text: "Policy renewal workflow" }],
  { embedder }
);

const results = await store.search("renewal process", { embedder });

If you already have persisted vectors, changing only the code is not enough. You must either migrate the old vectors or create a fresh index/collection.

Other Possible Causes

1) Mixing providers in different parts of the pipeline

You might index with OpenAI and query with Azure OpenAI, Cohere, or local embeddings. Even if both are “OpenAI-compatible,” their dimensions can differ.

// Indexing with one provider
const indexEmbedder = new OpenAIEmbeddingModel({ model: "text-embedding-3-small" });

// Querying with another provider/config
const queryEmbedder = new AzureOpenAIEmbeddingModel({ model: "text-embedding-3-large" });

Keep one embedding source per index.

2) Stale persisted vector data

You changed models but kept the old database table or namespace. This is common with pgvector, where the column was created for a specific size.

-- Example pgvector schema that locks dimension
CREATE TABLE documents (
  id text PRIMARY KEY,
  embedding vector(1536)
);

If you switch to a 3072-dim model, this table will fail on insert/query. Recreate the table or create a new one:

DROP TABLE documents;
CREATE TABLE documents (
  id text PRIMARY KEY,
  embedding vector(3072)
);

3) Incorrect chunking pipeline

Some teams accidentally embed metadata arrays or malformed chunks instead of plain text. The resulting vector generation may not match what downstream code expects.

// Wrong: embedding mixed payloads instead of clean text chunks
await splitter.splitDocuments(rawDocs).then((chunks) => {
  return chunks.map((c) => embed(c)); // c may be object-shaped, not text-only
});

Use normalized strings before embedding:

const chunks = rawDocs.map((doc) => doc.text);
const vectors = await Promise.all(chunks.map((text) => embed(text)));

4) Hardcoded dimension in custom code

If you wrote your own wrapper around AutoGen retrieval and hardcoded 1536, it will break as soon as you swap models.

const EMBEDDING_DIM = 1536; // brittle

Instead, read it from the actual model config or keep it in one place:

const EMBEDDING_DIM = getEmbeddingDimensionFromConfig();

How to Debug It

1. •

   Print the actual embedding length

   • •Log the output vector length before insertion and before query.
   • •If they differ, you found the issue.

   const vector = await embedder.embedQuery("hello");
   console.log("dims:", vector.length);
   

2. •

   Check which model created the index

   • •Inspect your DB schema, collection metadata, or startup logs.
   • •Look for values like vector(1536) or stored collection settings.
3. •

   Verify every AutoGen component uses the same embedder

   • •Check retriever, memory store, document ingester, and agent tools.
   • •A single mismatched helper can trigger:
     • •Error: embedding dimension mismatch
     • •QueryFailedError
     • •InvalidRequestError
4. •

   Delete and rebuild the index if in doubt

   • •If you changed models recently, rebuild from scratch.
   • •This is faster than hunting stale vectors across environments.

Prevention

• •Keep embedding config centralized in one module and import it everywhere.
• •Version your vector stores by model name and dimension:
  • •support_docs_1536
  • •support_docs_3072
• •Add a startup assertion that checks stored index dimensions against live embedder output.
• •When changing models, treat it like a schema migration:
  • •rebuild tables
  • •reindex documents
  • •redeploy retrieval code together

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.