/ Traverse,
/ Graph,
/ QueryTraverse query
#
Term and full-text queries match document content; none of them can
ask “what is connected to these documents?” — the question citation
graphs, reference data and knowledge graphs are made of. The traverse
query answers it: a bounded graph traversal over a relation-typed
edge field — starting from seed documents, walk the edges up to
max_depth hops and emit every reached node as a hit.
Scores encode distance — 1.0 / (1.0 + depth) — so seeds outrank
1-hop neighbors, which outrank 2-hop neighbors, and the standard top-K
collector orders the results.
.../ Graph,
/ Projection,
/ RequestGraph projection block
#
Add a graph block to any search request and the response carries a
graph — nodes and edges — built from the hit set, alongside the
normal hits. Where the
traverse query searches
by walking edges, the graph block renders: it takes the documents
a query already found and projects them into a node/edge structure a
UI (or a GraphRAG pipeline) can consume directly.
graph LR
subgraph walk["traverse — searches by walking"]
S("seeds") -->|"walk edges
up to max_depth"| H1["hits — every reached node,
scored by distance"]
end
subgraph render["graph — renders what was found"]
Q("any query") --> H2("hit set")
H2 -->|"project the relation field"| G["nodes + edges
for a UI or GraphRAG"]
end
.../ Tutorial,
/ GraphLesson 5 — Graph traversal
#
Relations are the first of the two features that most distinguish Pizza
from a plain text index: edges as a first-class query target. This
lesson walks edges inside one collection — the traversal sections run
live in the browser widget, and the modeling section at the end is
curl against a live node.
Graph queries are also the one lesson without a SQL pairing:
traverse stays DSL-side — it is demand-gated outside the
SQL M1 subset, which stops at the
single-collection statement.
...