From SharePoint Search to RAG: Indexing, Enrichment & the Road to AI Retrieval

If you've spent years configuring SharePoint search — crawling content, mapping managed properties, tuning relevance — you already understand the hard part of retrieval-augmented generation (RAG). The vocabulary has changed (embeddings, chunks, vectors), but the architecture is strikingly familiar. This final article connects the SharePoint search you know to the AI retrieval systems everyone's building now, and shows why SharePoint pros are unusually well-prepared for it.

What SharePoint search actually does

SharePoint search is a full retrieval pipeline, and every stage has a RAG analogue:

• Crawling — a crawler walks sites, lists, and libraries, extracting text and metadata from documents (Word, PDF, etc.) via format handlers (iFilters).
• Content processing — extracted text is parsed, words are tokenised, and properties are mapped.
• The index — processed content is stored in an inverted index optimised for fast keyword lookup.
• Query & ranking — a query is parsed and matched against the index, and results are ranked by a relevance model.

Crawled vs managed properties

The heart of SharePoint search configuration is the search schema. When the crawler finds content, every column and metadata field becomes a crawled property. Crawled properties aren't directly searchable in a useful way until you map them to managed properties — named, typed properties you can search, filter, sort, and refine on.

Crawled property:   ows_ContractStatus  (raw, from the column)
        │  map in the search schema
        ▼
Managed property:   ContractStatus  (Queryable, Refinable, Retrievable)

Setting a managed property as Queryable, Refinable, Sortable, or Retrievable is exactly the schema design you do in a search index today — deciding which fields are searchable, which are facets/filters, and which come back in results. In Azure AI Search you make the identical decisions with field attributes (searchable, filterable, facetable, retrievable).

Content enrichment: the original "embeddings step"

SharePoint Server let you inject custom processing into the indexing pipeline via the Content Enrichment Web Service (CEWS). During crawl, content was sent to your web service, which could read managed properties, compute new ones, and return them to be indexed — classify documents, extract entities, score sentiment, clean text.

That is conceptually identical to the enrichment / embedding stage of a modern RAG ingestion pipeline:

SharePoint (CEWS)                 Modern RAG pipeline
─────────────────                 ───────────────────
Crawl document            →       Load document
Send text to web service  →       Send chunk to embedding model
Compute managed props     →       Compute vector + metadata
Return to indexer         →       Upsert into vector store

The instinct a search consultant has — "intercept content during ingestion, enrich it, and store the enrichment alongside the original for retrieval" — is precisely the RAG ingestion pattern.

The RAG pipeline, in SharePoint terms

A retrieval-augmented generation system has four stages. Each one has a direct SharePoint-search ancestor:

RAG stage	What it does	SharePoint analogue
Chunking	Split documents into passages	Content processing / tokenisation
Embedding	Convert each chunk to a vector	Content enrichment (CEWS)
Indexing	Store vectors + metadata	The managed-property index
Retrieval	Find the most relevant chunks for a query	Query + relevance ranking

Why chunking matters (and SharePoint hints at it)

RAG splits documents into chunks because an LLM has a finite context window and because smaller, focused passages retrieve more precisely. SharePoint search already broke documents into searchable units and ranked passages for query matching — chunking is the same idea, tuned for a different consumer (a language model instead of a results page).

Keyword vs vector — and hybrid

The genuine leap is how relevance is computed. SharePoint's index is fundamentally lexical: it matches terms (with stemming, synonyms, and a ranking model on top). RAG retrieval is typically semantic: it compares the meaning of the query and chunks using vector similarity, so "how do I expense a flight" matches a document titled "travel reimbursement policy" even with no shared keywords.

Building RAG over SharePoint content today

The practical pattern for a SharePoint-grounded AI assistant:

1. Acquire content via Microsoft Graph (sites/drives/lists) — including delta queries to keep the index fresh, exactly like an incremental crawl.
2. Chunk and embed each document, preserving SharePoint metadata (site, author, status, sensitivity) as filterable fields.
3. Index the vectors and metadata in a vector store (e.g. Azure AI Search with vector + semantic ranking).
4. Retrieve with a hybrid query, trim by permissions, and pass the top chunks to the LLM as grounding context.

The throughline

Across this whole series we've traced SharePoint development from server-side event receivers to the cloud, through the add-in model, REST, SPFx, Microsoft Graph, and secured APIs. RAG is the next chapter, not a departure: ingest content, enrich it, index it with the right metadata, retrieve it relevantly, and respect permissions throughout. Every one of those is something SharePoint practitioners have done for years. The models are new; the discipline is the one you already have. That's why the move from SharePoint search to AI retrieval is less a leap than a natural next step — and why the developers and consultants who mastered the platform are exactly the people best placed to build what comes next.