Local search from entities to evidence

Local search answers questions anchored to specific entities or concepts by combining graph neighborhoods with source text and other indexed artifacts. The typical plan resolves query mentions to entity candidates, scores starting entities, expands a bounded neighborhood, gathers supporting claims and source units, adds selected community context, packs a context window, and generates an answer. Every step should expose scores, budgets, and evidence.

Entity linking is the first risk. A query for “Atlas” may refer to several entities. Use query context, entity descriptions, type expectations, user scope, aliases, and neighboring terms. If confidence is low, ask a clarifying question or search multiple candidates while labeling ambiguity. A wrong seed makes precise traversal confidently irrelevant.

Expansion should be typed and budgeted. One hop over a meaningful depends-on relation may be more valuable than three hops over generic associations. Score edges using relation relevance, source quality, recency, distinct evidence count, and path length. Maintain per-relation and per-node budgets so hubs do not consume the context. Preserve path objects with ordered edges and claims; a path reconstructed only from endpoint labels cannot explain itself.

Microsoft GraphRAG local search combines entity information with connected relationships, covariates or claims, community reports, and associated text units. The exact mixture should be query-dependent. A factual attribute question may prioritize direct claims and source units. An impact question may need multi-hop relations. A “why” question benefits from source passages and causal language, not merely graph proximity.

Candidate retrieval and context packing are different. Retrieval should gather a generous but bounded set with component scores. Packing selects a diverse, nonredundant subset under token limits. Allocate budgets across entity descriptions, relationships, claims, reports, and raw units. Prefer the lowest-level evidence that directly supports an answer, using summaries for orientation. Deduplicate overlapping source units and retain surrounding headings or table context.

Hybrid local search includes lexical and dense results because the graph can omit an entity or relation. Fuse ranked lists through a documented method such as reciprocal rank fusion, then rerank with query-specific features. Do not normalize incomparable scores casually. Preserve which channel retrieved each item so evaluation can attribute wins and failures.

Authorization applies to seed resolution, graph expansion, and every retrieved artifact. A hidden alias must not improve entity linking for an unauthorized user. A restricted edge must not make a public node rank higher. Build the candidate set from an authorized projection rather than filtering only the final context.

The answer contract should require claim-level citations, distinguish direct evidence from inference, and abstain when support is insufficient or contradictory. A generator can mention uncertainty found in sources. It should not bridge two edges into a causal conclusion unless the relation semantics and evidence justify that inference.

Evaluate retrieval before answer prose. For each query, label relevant entities, claims, paths, and source units. Measure seed accuracy, candidate recall, evidence precision, path validity, citation coverage, and context utilization by query type and hop count. Then evaluate answer correctness, support, completeness, and abstention. Latency and cost are part of quality: log time and tokens per stage.

Failure analysis should name the first broken layer. “The model hallucinated” is not enough when the true cause was an alias missing from the resolver, an over-merged seed, a pruned edge, or relevant evidence excluded during packing. Local search becomes reliable when those errors can be reproduced from a query trace.