Embedding model choice directly determines storage cost, query latency, and API cost for every document in your system. The legacy text-embedding-ada-002 model is strictly dominated by text-embedding-3-small, which achieves higher retrieval quality at lower cost — there is no justification for using ada-002 in new systems. Using text-embedding-3-large (3,072 dimensions) when text-embedding-3-small (1,536 dimensions) produces equivalent retrieval quality for your dataset wastes storage and doubles query payload size. ISO 25010 performance-efficiency requires that resource choices be calibrated to actual requirements.
Medium because an oversized or legacy embedding model imposes avoidable storage, cost, and latency overhead on every embedding operation and vector query.
Switch from text-embedding-ada-002 to text-embedding-3-small for all new embedding workloads. Use the dimensions parameter to reduce dimensionality further if your dataset is small and full fidelity is not needed.
// Before — legacy model, obsolete for new systems
const embedding = await openai.embeddings.create({
model: "text-embedding-ada-002",
input: text,
});
// After — modern model, better quality at lower cost
const embedding = await openai.embeddings.create({
model: "text-embedding-3-small",
input: text,
// dimensions: 512, // optional: reduce for large-dataset storage savings
});
After switching models, update the vector table's dimension column to match the new model's output. Reindex existing embeddings — they are not compatible across models.
ID: ai-token-optimization.token-efficiency.embedding-dimension-optimization
Severity: medium
What to look for: If the project uses embeddings, find the embedding API calls (e.g., openai.embeddings.create(...) or the Vercel AI SDK embed() function). Check the model parameter — is it text-embedding-3-small (1536 dimensions, cheaper) or text-embedding-3-large (3072 dimensions, more expensive)? Also check whether the optional dimensions parameter is used to reduce dimensionality when full fidelity is not needed. Look at the vector database schema or table definition to see what dimension size is stored. Count all instances found and enumerate each.
Pass criteria: The project uses text-embedding-3-small or an equivalent cost-efficient modern embedding model. If using text-embedding-3-large or similar, the choice is justified by dataset size or retrieval quality requirements. The dimensions parameter is set explicitly if a reduced dimension is appropriate. At least 1 implementation must be confirmed.
Fail criteria: The project uses a legacy or unnecessarily large embedding model (e.g., text-embedding-ada-002 with no justification, or text-embedding-3-large for a small dataset), or uses default maximum dimensions when a reduced size would suffice.
Skip (N/A) when: No embedding model usage is detected in the project.
Signal: No openai.embeddings.create, embed(), or vector database dependencies (@pinecone-database/pinecone, @upstash/vector, pgvector, chromadb) in the codebase.
Detail on fail: "Oversized or legacy embedding model in use — higher storage and query costs than necessary"
Remediation: Embedding models differ significantly in cost and performance. text-embedding-3-small outperforms the older text-embedding-ada-002 at lower cost, making ada-002 an obsolete choice. For most applications, text-embedding-3-small with default dimensions is the right choice.
// Before — legacy model
const embedding = await openai.embeddings.create({
model: "text-embedding-ada-002",
input: text,
});
// After — modern, efficient model
const embedding = await openai.embeddings.create({
model: "text-embedding-3-small",
input: text,
// dimensions: 512, // optional: reduce for storage savings on large datasets
});
After switching models, the vector database schema dimension column must be updated to match. Verify by checking the stored vector dimension against the model's output dimension.