Skip to main content

Intent-based search

Search in GriMoire is not a single API call. It is a pipeline that understands what the user wants, routes to the right tool, plans query variants, retrieves from multiple sources in parallel, fuses results, and retries with recovery branches when recall is weak.

The full pipeline

User query
Intent routing
Heuristic + ML classification
First pass (parallel)
Copilot Search
Raw query, semantic
Copilot Retrieval
Raw query, RAG
SharePoint Search
Planner lexical query
Search planner
Nano LLM, query variants
RRF fusion
Weighted rank fusion
Recall check
< 5 unique results?
Recovery branches (sequential)
Semantic rewrite
Spelling correction
Translation fallback
Keyword fallback
UI blocks
Ranked results

Intent routing

Before any search API is called, the system classifies the user's intent using a two-stage approach:

  1. Keyword matching — catches obvious signals like "email from", "meeting with", "Teams message about"
  2. ML classification — when keywords are inconclusive, a Nano model classifies the query
IntentTool familyWhat it searches
Files and documentssearch_sharepointSharePoint, OneDrive
Emailsearch_emailsOutlook mailbox
Peoplesearch_peopleOrganization directory
Calendarsearch_calendarOutlook calendar
Teams messagessearch_teamsTeams chats and channels

Asking "find the budget email" searches mail, not SharePoint. Asking "who works on the design team" searches people, not files. Intent routing makes this automatic.

Query planning

For file search, the system runs a first pass where three things happen in parallel:

  1. Copilot Search receives the raw user query for semantic retrieval
  2. Copilot Retrieval receives the raw user query for RAG-based retrieval
  3. Search Intent Planner uses the Nano LLM to produce query variants
Raw user query
Search planner
Nano LLM (parallel)
Planned variants
Lexical query
For SharePoint
Semantic rewrite
For Copilot retry
Correction
Spelling fix
Translation
Tenant language
Keywords
Fallback tokens

Each variant is confidence-gated — only used when the planner's confidence exceeds a threshold. Low-confidence variants are rejected. If the Nano model is unavailable, search still works — the fallback mainly contributes language detection.

SharePoint Search only runs on the first pass if the planner produces a lexical query with sufficient confidence. Otherwise it is skipped.

Multi-source retrieval

SourceQuery usedWhat it does
Copilot SearchRaw user querySemantic search via Copilot APIs
Copilot RetrievalRaw user queryRAG-based retrieval with relevance scores
SharePoint SearchPlanner lexical query (if available)Classic lexical search

Result fusion

The fusion step combines results from all sources using Reciprocal Rank Fusion (RRF):

  1. Score each item based on its rank position and source weight
  2. Apply source weights — retrieval is weighted highest, then Copilot Search, then SharePoint
  3. Deduplicate — the same document may appear across sources; scores are accumulated
  4. Apply rerank boosts — items found by multiple sources, matching the query language, or containing the query in the title get boosted
  5. Truncate to the requested result count

Documents found by all three sources tend to rank highest because their scores accumulate across sources.

Recovery branches

After the first pass, the system checks whether the fused result set has at least 5 unique results. If recall is weak, recovery branches run one at a time — each one re-fuses after adding its results:

BranchConditionWhat it does
Semantic rewriteAlways, if planner produced oneRuns Copilot Search + Retrieval with a rewritten query
Spelling correctionOnly if < 5 results after prior branchesRetries with the corrected query
Translation fallbackOnly if < 5 results and multilingual tenantRetries in the tenant's primary language
Keyword fallbackOnly if < 5 results after all aboveRuns SharePoint Search with a pure keyword query

Each branch is deduplicated against already-executed queries so the same search is never run twice.

First pass
Raw query, 3 sources
Fuse + count
Semantic rewrite
Immediate if available
Correction
If < 5 results
Translation
If < 5 results
Keyword fallback
If < 5 results

What the user sees

The search result block shows:

FieldValue
QueryThe original user query
ResultsFused and ranked result list
Total countNumber of unique fused results
SourcesWhich backends contributed
Query variantsCorrections, translations, or keywords used
note

Semantic rewrite variants are intentionally hidden from the user-facing display. The search may have used semantic expansion even when the block only shows corrections or translations.

From search to action

Search results become UI blocks. Blocks support drill-down. Drill-down leads to action.

  1. Search — "Find the latest project recap"
  2. Recap — GriMoire renders results as a block, the user selects one, and the assistant generates a summary
  3. Action — "Send the recap by mail"

Search results become the context for recap and action, mediated by the HIE. When the user expresses a multi-step intent in a single sentence — "find the budget docs and send them to the team" — the text path can detect and execute the full chain automatically as a compound workflow.

Worked example

Query: "search for SPFx architecture"

1. Loading block created
Appears immediately
2. Parallel launch
Copilot Search
Raw: "SPFx architecture"
Copilot Retrieval
Raw: "SPFx architecture"
Planner
Nano analyzes query
3. Planner returns
Lexical query: "spfx architecture sharepoint framework"
4. SharePoint Search runs
Using planner lexical query
5. Initial fusion
Combine and deduplicate results
6. Semantic rewrite runs
"SharePoint Framework architecture guidance"
7. Fuse again
Enough results — skip remaining branches
8. Block updated
Fused results rendered
9. HIE sends context
Numbered result list sent to model

From this point, follow-ups like "summarize document 2" or "send this by email" depend on HIE context tracking and the interaction flow.