Pyramid
Pyramid is VSAG’s hierarchical, path-partitioned graph index. Every vector is
tagged with a path string such as "a/d/f", and Pyramid builds a graph per node
in that path tree. At query time you supply a path prefix, and Pyramid restricts
the search to the corresponding sub-tree.
This is ideal for multi-tenant deployments, tag-partitioned catalogs, or any scenario where one logical index serves many groups that must not cross-contaminate results.
- Source:
src/algorithm/pyramid.{h,cpp},src/algorithm/pyramid_zparameters.{h,cpp} - Example:
examples/cpp/107_index_pyramid.cpp
How it works
- Path tree. Each vector carries a
pathin addition to its id. Paths use/as separator (e.g."tenant_a/lang_en/topic_news"). Pyramid builds one sub-index for every path prefix seen during build. - Per-level sub-graphs. By default every level gets its own proximity graph.
Use
no_build_levelsto skip levels that are too small or too coarse to benefit from graph indexing — those levels still exist as passthrough containers, but search degrades to a scan. - Graph construction. Each sub-graph is built with the same machinery as
HGraph:
nswinsertion orodescentwithgraph_iter_turn,neighbor_sample_rate, andalphafor pruning. Base vectors are stored inbase_quantization_type; optional reordering keeps a high-precision copy. - Search. Query vectors also carry a path. The search walks down the tree
to the most specific sub-graph matching the query path and runs a graph search
there with
ef_search(andsubindex_ef_searchfor intermediate levels).
Quick start
#include <vsag/vsag.h>
std::string params = R"({
"dtype": "float32",
"metric_type": "l2",
"dim": 128,
"index_param": {
"base_quantization_type": "sq8",
"max_degree": 32,
"alpha": 1.2,
"graph_type": "odescent",
"graph_iter_turn": 15,
"neighbor_sample_rate": 0.2,
"no_build_levels": [0, 1],
"use_reorder": true,
"build_thread_count": 16
}
})";
auto index = vsag::Factory::CreateIndex("pyramid", params).value();
// Build with per-vector paths.
auto base = vsag::Dataset::Make();
base->NumElements(n)
->Dim(128)
->Ids(ids)
->Paths(paths) // std::string* of length n, e.g. "a/d/f"
->Float32Vectors(data)
->Owner(false);
index->Build(base);
// Search restricted to a path prefix.
std::string query_path = "a/d";
auto query = vsag::Dataset::Make();
query->NumElements(1)
->Dim(128)
->Float32Vectors(q)
->Paths(&query_path)
->Owner(false);
auto result = index->KnnSearch(
query, /*topk=*/10,
R"({"pyramid": {"ef_search": 100}})").value();
Build parameters
Build-time parameters live under index_param.
| Parameter | Type | Default | Description |
|---|---|---|---|
base_quantization_type | string | — | Coarse storage quantizer (fp32, fp16, bf16, sq8, sq4, sq8_uniform, sq4_uniform, pq, pqfs, rabitq). See the Quantization chapter for per-quantizer details. |
max_degree | int | 64 | Maximum out-degree per node within a sub-graph. |
graph_type | string | "nsw" | nsw or odescent. |
ef_construction | int | 400 | Candidate list size for nsw builds. |
alpha | float | 1.2 | Pruning factor during graph construction. |
graph_iter_turn | int | — | ODescent iterations (effective with graph_type: "odescent"). |
neighbor_sample_rate | float | — | ODescent neighbor sampling rate. |
no_build_levels | int[] | [] | Tree levels that skip graph construction (0-indexed from the root). |
use_reorder | bool | false | Keep a high-precision copy for rescoring. |
precise_quantization_type | string | "fp32" | Quantizer for reordering. |
index_min_size | int | 0 | Minimum sub-index size; smaller groups fall back to scan. |
support_duplicate | bool | false | Allow duplicate ids. |
build_thread_count | int | 1 | Threads used for parallel build. |
Search parameters
Search-time parameters live under the pyramid sub-object:
| Parameter | Type | Default | Description |
|---|---|---|---|
ef_search | int | 100 | Candidate list size for the leaf-level graph search. |
subindex_ef_search | int | 50 | Candidate list size used when traversing intermediate sub-graphs on the path. |
auto result = index->KnnSearch(
query, topk,
R"({"pyramid": {"ef_search": 200, "subindex_ef_search": 80}})").value();
When to use Pyramid
- Multi-tenant services where each tenant must see results only from its own partition, and you would otherwise maintain one index per tenant.
- Content catalogs with hierarchical tags (language / region / category) where queries always scope to a known prefix.
- Workloads with many small partitions:
no_build_levelsandindex_min_sizelet you skip graph construction for partitions too small to benefit.
If you don’t need path-based scoping, HGraph is simpler and generally faster.