An image, a product description, or a search question can all be transformed into a string of numbers through an embedding model. This string of vectors is not the content itself, but a mathematical representation built by the model based on the training results; the distance between vectors can be used to estimate their similarity under a specific model.
I. From content to vectors: enabling machines to compare similarity
Embedding models map text, images, or other data into a multi-dimensional space. If the model considers two pieces of data to be semantically or feature-wise similar, their vectors will usually be closer together. This allows the system to handle queries that are "similar in meaning but use different words," such as linking "speakers suitable for outdoor parties" with product features such as waterproof, long battery life, and portability.
The same concept can be applied to images and usage behavior: two photos of chairs with similar appearances may appear close in the visual vector space; a set of long-term browsing and purchase records can also form a feature representation for recommendations. However, different embedding models learn different "similarities," and text models, image models, and multimodal models cannot be used interchangeably; they must be verified with real data before importation.
II. What does a vector database do?
Vector databases or databases with vector capabilities store vectors, original data identifiers, and metadata, and provide similarity search, indexing, and conditional filtering. The query process is typically:
- Convert product descriptions, images, or documents into vectors and write them into the database.
- Convert user questions into query vectors in the same vector space.
- Perform necessary filtering based on brand, inventory, price, or permissions.
- Find similar results and then rearrange them using business rules or ranking models.
- Return products, files, or content that can be used by generative AI.
Metadata filtering is crucial. Simply looking at semantic similarity might recommend out-of-stock, priced incorrectly, or inaccessible content; combining vector search with structured conditions is the only viable business search approach.
III. KNN vs. ANN: Trade-offs between accuracy and speed
| Methods | Implementation | Suitable Scenarios |
|---|---|---|
| Precise KNN | Compare the query vector with all vectors that meet the conditions to find the truly nearest result. | When the data volume is small and high recall is required, the scope can be significantly narrowed down using metadata first. |
| ANN | Quickly finding "approximate" nearest neighbors through indexing reduces latency but may miss a small number of truly nearest results. | Online services with large vector volumes, frequent queries, and a need for low latency. |
Common ANN indexes include HNSW, IVF, and ScaNN. When choosing an ANN, speed should not be the only consideration; recall, latency, index size, update cost, and filtering conditions must also be tested. Google Cloud's indexing guidelines also recommend choosing between exact or approximate search based on data volume, latency, and recall requirements, rather than assuming that an ANN is always better.
HNSW builds a multi-layered graph structure, quickly approaching the target region from the sparser upper layers during queries, and then searching more thoroughly in the lower layers; IVF first groups the vector space, searching only the closest groups during queries. The former often has good low latency and recall, while the latter is easier to control the query range with large-scale data, but both require parameter adjustments based on data distribution and update methods.
IV. Real-world Applications of Vector Databases
A stable system also requires product synchronization, version management, offline evaluation sets, access control, and monitoring. Simply "vectorizing" data does not automatically result in a good search experience.
V. Is a dedicated vector database always necessary?
Not necessarily. The original text described traditional SQL databases as incapable of vector searching, which is no longer consistent with the current state of tools. Taking PostgreSQL as an example, pgvector can store embeddings and supports distance calculations and indexes such as HNSW; if the data volume, query volume and team architecture are suitable, an existing relational database may be sufficient.
Dedicated vector databases are generally more suitable for scenarios requiring large-scale vectors, distributed queries, multiple indexing strategies, or independent expansion. When evaluating, four questions should be answered first: how many vectors are there, what is the query volume per second, what is the update frequency, and how complex is the metadata filtering and permissions?
Conclusion: The database is only part of the system.
Vector databases make it feasible to "find similar content based on meaning or features," but search quality still depends on the embedding model, product data, index parameters, ranking logic, and continuous evaluation. Choosing the right infrastructure is important, but more importantly, defining the customer's problem and measurable good results is even more crucial.