GraphLocalSearchDeps
@forge/monorepo / backend/src / GraphLocalSearchDeps
Type Alias: GraphLocalSearchDeps
GraphLocalSearchDeps =
object
Defined in: backend/src/knowledge/graph-retrieval.ts:133
Properties
depth?
readonlyoptionaldepth?:number
Defined in: backend/src/knowledge/graph-retrieval.ts:136
embeddings?
readonlyoptionalembeddings?:EmbeddingProvider
Defined in: backend/src/knowledge/graph-retrieval.ts:154
Ranks the chunks the traversal gathered — #277.
Optional, and the mode is materially worse without it. Measured on this repository's corpus, connectivity-only ranking scored 20.8% success@5 against semantic search's 75%. The gap between its own columns was the tell: it found the right document 45.8% of the time and the right chunk half as often again, because an entity's provenance is every chunk that mentioned it and counting entity touches cannot tell two chunks of one document apart.
So the graph is used for selection and embeddings for ranking, which is what Microsoft's local search does and what ours did not.
Left optional rather than required because a deployment that has a graph and no embedder still gets a
working traversal, and docs/29 says plainly what it costs. rankedBy in the result reports which
happened, so a measurement can never silently be of the other one.
graph
readonlygraph:GraphStore
Defined in: backend/src/knowledge/graph-retrieval.ts:134
knowledge
readonlyknowledge:KnowledgeStore
Defined in: backend/src/knowledge/graph-retrieval.ts:135
neighbourLimit?
readonlyoptionalneighbourLimit?:number
Defined in: backend/src/knowledge/graph-retrieval.ts:137
poolFactor?
readonlyoptionalpoolFactor?:number
Defined in: backend/src/knowledge/graph-retrieval.ts:162
How many candidates to gather before ranking, as a multiple of the caller's limit.
Ranking can only reorder what selection handed it, so a pool of exactly limit makes the re-rank a no-op
— which is precisely the bug: the old code stopped gathering at limit, so the top-k by connectivity were
the only chunks that could ever be returned.