A city complaint assistant stores embeddings with the pgvector extension in Azure Database for PostgreSQL. What must align for correct similarity search?
Select an answer to reveal the explanation.
Short Explanation
Distance metric and embedding model are dance partners—pick the metric that matches how those complaint vectors were trained, or the similarity search steps on toes.
Full Explanation
With the pgvector extension on Azure Database for PostgreSQL, correct similarity search depends on choosing a distance metric consistent with how the embedding model produced the complaint vectors (for example, cosine, L2, or inner-product families as appropriate to the model). Metric and vector space must align; otherwise nearest-neighbor ranking does not reflect semantic similarity the city complaint assistant expects.
Using a randomly changing distance metric on every query regardless of the embedding model invalidates comparability of scores and rankings. Storing embeddings as unstructured prose paragraphs without a vector type means pgvector cannot perform vector operations. Disabling pgvector and comparing complaints with binary string equality only tests exact text matches, not semantic similarity.
Exam caveat: distance operators and index types in pgvector must match the chosen metric; mixing cosine-trained expectations with an incompatible operator is a common exam trap. Operational check: record the embedding model id and intended metric in schema metadata, build the vector index with a matching operator class, and validate that known-similar complaint pairs rank above unrelated pairs before promoting the assistant.