Multi-Vector Search Using HNSW Indexes

In many real-world use cases, multi-vector similarity searches must be performed on large data sets, requiring efficient indexing to improve performance. Oracle AI Database supports accelerated approximate multi-vector similarity searches using Hierarchical Navigable Small World (HNSW) vector indexes. An HNSW index can significantly reduce latency and resource utilization compared to scanning an entire table when the columns used to group the results are stored as included columns in the index.

Why Use HNSW Indexes for Multi-Vector Search?

HNSW indexes organize the vector space as a multilayer proximity graph, enabling each query to navigate quickly toward the most relevant vectors. By exploring only the most promising areas of the graph, HNSW indexes can achieve fast response times for multi-vector search workloads that would otherwise take significantly longer with a full table scan.

Benefits

• Fast approximate similarity search: HNSW graph traversal narrows the search to promising vector candidates instead of comparing the query vector with every vector in the base table. This approach can reduce the number of rows read, vector distance computations, and sorting operations required to return the best nested groups.

• Integration with SQL: HNSW index works seamlessly with SQL syntax, supporting approximate searches, including multi-level partitioned row limiting.

• Multi-level grouping: The index supports multiple partition levels, enabling a single query to return the closest rows from the most relevant nested groups.

• Integrated filtering: The optimizer can apply eligible predicates while generating HNSW candidates or after candidate generation. This allows applications to combine approximate vector search with relational filters while retaining the nested row limits.

• Reduced base-table access: Included grouping and filter columns are available directly from the HNSW index. The database can retrieve other projected columns from the base table by row ID only when required.

Usage Notes

• Approximate result count: HNSW search is approximate, the query can return fewer rows than theoretical maximum even when the base table contains enough rows to fill every group.

• Included-column support: Every column referenced by a PARTITIONS BY clause must be a base-table column and must be stored as an included column in the HNSW index. Expressions cannot be used as HNSW multi-vector partition keys. Other projected columns do not have to be included because the database can retrieve them from the base table by row ID.

• Unsupported access paths: HNSW multi-vector access is not supported for external-table or distributed-index paths.

• Recall tuning: The EFSEARCH parameter controls the breadth of HNSW graph traversal at query time. A larger value generally evaluates more candidates and can improve recall, but it also increases CPU, memory, and elapsed-time costs. For HNSW multi-vector search, specify and tune EFSEARCH when direct control over the recall and work tradeoff is required.

• Index compatibility requirements: The distance metric in the query must match the distance metric of the HNSW index.

• Execution-plan visibility: The optimizer plan of the HNSW multi-vector search contains:

  • The ROW LIMIT PARTITION operation and the VECTOR INDEX HNSW PART-SCAN operation.
  • Filtered searches such as IN-FILTER, or POST-FILTER variant of the filtering plans.

See Also:

• Set Up Schema and HNSW Index for Multi-Vector Search
• Overview of Hierarchical Navigable Small World Indexes