What this prompt does
This prompt makes the model act as a vector-database architect and design a complete schema and indexing strategy for your embedding application. You describe the [use_case], [data_types], [data_scale], [query_patterns], [latency_target], and chosen [vector_db], and it returns embedding-model recommendations, a chunking strategy, a collection schema, index tuning, query optimization, and operational guidance.
The structure works because retrieval quality is set early — at the chunking and indexing layer — and those choices are painful to change once you've embedded millions of records. By tying recommendations to your [data_scale] and [latency_target], the prompt picks an index type (HNSW, IVF-PQ, or flat) with a real trade-off table, recommends a chunking method per content type, and designs metadata fields for filtering. The [embedding_concern] and [optimization_technique] slots let you steer it toward your specific problem, like mixing code with prose or contextual retrieval.
When to use it
- You're starting a RAG or semantic-search system and need to lock in a collection design before mass embedding.
- Retrieval quality is poor and you suspect chunking, index type, or filtering is the bottleneck.
- You're choosing between vector databases and want a schema mapped to your
[vector_db]of choice. - You're mixing
[data_types]— docs, code, short messages — and need different chunking per type. - You need to hit a strict
[latency_target]with metadata filtering and want pre- vs post-filtering guidance. - You're planning for growth and need a reindexing and embedding-versioning strategy up front.
Example output
You get a layered design: an embedding-model table per content type with dimensions and cost, a chunking-strategy table (method, size, overlap, rationale) covering long documents, code, and short content, a collection schema with vector and filterable metadata fields, an index-comparison table with a recommendation tuned to your [data_scale], query-optimization patterns with filter and reranking techniques, and an operations section on backup, embedding versioning, and cost projection for your [vector_db].
Pro tips
- Be precise in
[data_scale](current chunk count plus growth rate); the index recommendation hinges on it. - List every distinct content type in
[data_types]so you get tailored chunking rather than one-size-fits-all. - Use
[embedding_concern]to flag mixed code-and-prose or multilingual needs that change the model choice. - Set
[optimization_technique]to something concrete like contextual retrieval or hybrid search to get a deeper treatment of it. - Decide pre- vs post-filtering based on your
[query_patterns]— ask the model to justify which is faster for your filters. - Plan embedding versioning early; ask a follow-up on what happens to existing vectors when you switch embedding models.
