pgvector supports more than RAG: related products, similar cases, content-based recommendations, duplicate detection, and candidate generation for ranking. The same rules apply—filter eligibility first, choose a task-appropriate embedding, diversify results, measure outcomes, and avoid treating similarity as identity, causation, quality, or a sensitive personal attribute.
Apply category, region, safety, age, inventory, and seller rules as hard predicates. Rerank for diversity, business goals, and user context only after eligibility.
Duplicate detection asks whether a pair crosses a reviewed threshold or should enter human review. Thresholds depend on model, metric, domain, and costs of false positives/negatives. Use labeled positive and hard-negative pairs; do not reuse a retrieval top-k setting.
User profiles can create privacy and fairness risk. Obtain a lawful purpose and consent where required, minimize and expire data, provide controls, and exclude sensitive attributes. Prefer transparent session or explicit-interest features when they satisfy the need.
Use offline relevance/diversity metrics followed by guarded online experiments. Monitor exposure, catalog coverage, novelty, conversion or task success, complaints, and disparate outcomes. For duplicates, report precision/recall at the review threshold and preserve human override.
Design a pgvector candidate system for [recommendation/related items/duplicate review]. Define eligibility, embedding unit, SQL, diversity, labels, offline metrics, online guardrails, privacy, fairness slices, and human override. Separate candidate generation from final ranking.
Verification contract: No automatic destructive action may rely only on vector distance, and every online metric must have safety and quality guardrails.