Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Two ways to search and why one alone keeps letting you down. Your search box has been doing only half the job for years. It reads the exact words you type, which is perfect when you need a policy code, but useless when you ask about time off and the document says vacation. Azure AI search fixes that by running two different searches at the same time and blending them into one ranked list. That blend is called hybrid retrieval, and it sits underneath the answers you already get from Microsoft's AI tools. By the end, you'll know both halves, how they get stitched together, and where this quietly touches your daily work. Search was never one skill. It's two, and each one solves a different problem. One matches the exact words you typed and the other matches what you actually meant. Most tools you've used only ever did one of those jobs. Well, that gap explains a lot of annoying moments. A search box can nail a part number and still miss a plain question about your holiday policy. Someone types time off and the system shrugs because the page they needed says vacation and shares not a single letter with the query. When a system runs both jobs at once and compares the answers, the result stops feeling like a lookup and starts feeling like understanding that difference matters more than it used to. Because AI tools now lean on search results as the raw material for their answers. If the search misses, the answer is wrong. No matter how clever the model is, the stakes rise again. Once AI enters the picture, a language model doesn't know your files, so it answers from whatever text you hand it. And that text comes from search. A weak search feeds the model weak material, and no amount of model quality can fix a page that was never retrieved in the first place. So we'll take this in three steps. First, the exact word half the one you already know. Even if you've never named it, then the meaning half, which is where the surprise lives. Then how Azure AI search fuses the two into a single ranked list, and why the whole thing shows up in tools you already open every morning. One of the most common assumptions about hybrid search also turns out to be wrong, and knowing why will save you from a mistake plenty of teams make. What keyword search actually does. Keyword search starts by building a map of your content as documents arrive. The system records which words appear in which documents, and that map is called an inverted index. It sounds dull, and it's the reason search can answer in milliseconds across millions of pages. Before any of that, the text gets cleaned up. Language analyses split sentences into words, drop the filler, and fold variations like running, and ran toward a common root. So a search for run still finds both. None of this needs your attention to work, but it explains why the results arrive so fast. Once you type a query, the system scores how well each document matches. That scoring method has a name Bm25, and you can understand it without touching the math. Bm25 gives more weight to words that appear often inside one document, and less weight to words that appear in almost every document. Take the word the for a second. It shows up nearly everywhere, so it tells you almost nothing. A rare code like x z four thousand and seventy one shows up once, so it tells you a great deal. B-25 captures that instinct automatically, so keyword search stays strong on part numbers, exact names, dates, and specialized terms. A small example shows how that plays out. Suppose you're hunting for invoice template Forty four seventy one in a shared drive with ten thousand files. The word invoice appears everywhere, so it barely moves the needle, but forty four seventy one is rare enough to pull the right file straight to the top. That's Bm25 doing its arithmetic in the background. Microsoft's own tests make the point on queries built from nothing but keywords. Plain keyword search scored far higher than meaning based search alone. When you already know the exact identifier you need. Precision beats cleverness every time that precision has a blind spot, though, keyword search only finds the words you handed it and nothing more. Search for a remote work policy and a page titled Telecommuting Guidelines stays invisible because the two phrases share no letters. That single flaw is exactly what the other half of hybrid retrieval was built to cover. What vector search actually does. Now for the half that feels like magic. Until you see the trick vector search turns text into a long list of numbers, and that list is called an embedding. The numbers aren't random. They place the meaning of the text somewhere in a huge space where similar meanings end up close together. Something has to create those embeddings, and it's usually an embedding model, such as one from Azure OpenAI. This is where a lot of beginners first get stuck, because the model is a separate service with its own cost and its own rate limits, the search engine stores and compares the vectors and the model makes them. The size of an embedding is fixed by the model, and it's usually somewhere in the hundreds or low thousands of numbers per passage. Those numbers are also why, meaning search isn't perfect. Two passages can sit close together in the space without being a true match, and that kind of near miss is what the later ranking steps are there to clean up once meaning has coordinates matching changes completely, the word refund and the phrase money back land near each other so a query can find one using the other. Even when they share zero words, the system isn't matching letters anymore, it's matching closeness. Two bonuses fall out of that design because meaning sits in the same space across languages. A search in English can surface a German document without any translation step. The same idea works across content types, so text and images can share one space and be compared side by side to find the nearest meanings. The engine runs a nearest neighbor search. Azure AI search gives you two engines for that job. One is a graph based method called NSW, which is fast and handles large indexes well, and the other is exhaustive KNN which checks more candidates and trades speed for thoroughness. Vector scores run from about zero point three three three to one pal when cosine similarity is used, so a higher number means a closer match. That range is nothing like the keyword scores, which have no upper limit at all. Keeping the two apart matters because the next step has to merge two lists that don't even speak the same numerical language. Hybrid search runs both at once and blends the results. Hybrid search is a single request that carries both a text query and a vector query, and the two run together. There's no separate third algorithm doing the work. You send your words and the meaning version of those same words in one call, and the engine fires both jobs in parallel. Now you have two ranked lists. One is ordered by Bm25, the other by meaning. And they rarely agree on the exact order. Azure AI search merges them with a method called reciprocal rank fusion, or RF, and the core idea is simple enough to hold in your head. RF gives each document a score of one divided by its rank, plus a small constant. The constant is sixty in practice, and its job is to keep the top spot from completely dominating the result. A document that ranks high on both lists collects two good scores and rises, one that only a single list loved still gets a seat just lower down. Picture a policy page that keyword search ranks fifth and meaning search rank second. It collects a solid score from each site and climbs above a page that only one method noticed. That agreement is the whole trick. When two different methods point at the same passage, you can trust it more than either one alone. Hybrid queries also keep the ordinary search features you'd expect. Filters still work, facets still work, and sorting still works, so you don't lose the practical tools just because meaning joined the party. You can even weight the vector side up or down if you find that your users lean one way. Say your users mostly type short, messy phrases rather than exact identifiers. Nudging that weight up tells the engine to trust, meaning a little more. The default is an even split, and you only change it after watching what real queries look like. By default, a hybrid query returns the top fifty matches from the fused list, and the text side stops looking after one thousand matches. Those defaults are generous for a chat app, which usually needs only a handful of good passages to answer a question well. Microsoft's benchmark results show hybrid beating either method alone across customer data and public test sets, which is why it became the default recommendation for grounding AI answers. Nothing got thrown away along the way, and that matters more than it might seem. The second pass that reorders the shortlist. Now here's where it gets interesting. Merging two lists gets you a better shortlist. Not a perfect one. So Azure AI search adds a second ranking pass and it's called semantic ranking. The name makes it sound like it repeats the vector work, but it does something different. Semantic ranking takes the best fifty results from the previous step and reads each one alongside your query. It uses language models adapted from Bing to judge how well a passage answers the actual question, then scores each one from zero to four. A four means the passage answers the question well, and a zero means it's irrelevant. Two honest limits shape what this pass can do. It only ever looks at those top fifty results. So it can reshuffle that shortlist, but it can't rescue a document. The first pass never found. It also can't invent anything. The captions and answers it returns are pulled word for word from your own content, never written from scratch. None of this replaces the first pass. The ranker can only reorder what it was handed, so anything that never made the shortlist gets no second chance. Good retrieval upstream is what gives the second pass something worth polishing. There's a cost attached to semantic ranking is a paid feature billed by usage, with a free monthly allowance that most people never exhaust while testing. That's a fair trade for sharper results, and it's also why you switch it on deliberately instead of everywhere at once. Reranking a shortlist is far cheaper than reranking an entire corpus, which is why the second pass exists as a second pass. Microsoft's tests showed hybrid plus semantic ranking, pulling clearly ahead of hybrid alone, and the gap was widest on the kind of messy real world questions people actually type. The features here go a little further than scoring. Semantic ranking can hand back a short caption that summarizes why a passage matched, which is handy when you're showing results to a person. A newer option can even rewrite your query into several variations to catch typos and missing synonyms before the search runs. What the second pass actually reads matters because it works on text alone. A document that's mostly numbers or an image with no description attached gives the rank of very little to judge. Pros rich content like documentation and knowledge bases gains the most, and Microsoft says as much in its own guidance. All of this adds a little time to each query, and the trade is deliberate. You're buying sharper ordering at the cost of a slower response, which is usually a fair deal for a chat assistant and a worse one for an instant type ahead box. The unglamorous step that decides everything before any of that clever matching can work. Your content has to be prepared, and the main move is called chunking. Chunking means cutting long documents into smaller passages so each passage can be matched separately. A policy handbook stops being one giant blob and becomes a few hundred focused pieces. There's a good reason to bother here. A single vector has to squeeze the meaning of an entire document into one set of numbers, and long documents carry several topics at once. When you flatten all of that into one vector, the detail blurs and the tail of the document often gets ignored altogether. The numbers here are striking in Microsoft's tests. Representing a whole document with one vector scored twenty eight point two on queries whose answer sat inside a long document chunking the same documents lifted that to forty five point seven, and for answers buried deep in a document, it climbed to fifty one point four. Size and boundaries matter as much as the decision to chunk passages of about five hundred and twelve tokens scored forty two point four, while four thousand and ninety six token passages dropped to thirty six point four, letting chunks overlap by a quarter and ending them at sentence breaks pushed the score higher still because context never gets sliced in half. Picture an HR handbook that runs eighty pages long, chunked well. A question about parental leave lands on the four paragraphs that actually cover it chunked badly. The same question drags in a summary of the entire policy and buries the real answer somewhere in the middle. You don't always have to do this by hand. Azure AI search can run chunking and vectorization inside an indexer pipeline, pulling from sources like blob storage, Azure SQL or One Lake and generating the embeddings along the way. The work still happens. It just happens for you. This is the part nobody puts on a slide, and it decides how good everything downstream can be. Get chunking wrong and even perfect ranking has nothing decent to work with. Where this already touches your Microsoft three hundred sixty five work. The retrieval engine we just walked through is Azure AI search, and it also powers foundry IQ, Microsoft's managed knowledge layer that turns enterprise content into knowledge bases for agents. You meet it in Copilot Studio, where Azure AI search slots in as a knowledge source. Agents there also pull from SharePoint, Dataverse, uploaded documents, public websites, and connectors, and each of those sources feeds the same answering pipeline. Then there's Microsoft three hundred sixty five copilot. Copilot connectors bring outside and line of business content into the graph, so the same retrieval ideas show up even when you never touch an index yourself. A question typed into the chat window can be answered from a document you'd forgotten existed. Security is handled in a way that should put you at ease. Answers respect each person's permissions through Microsoft Entra ID so a user only ever surfaces content they're allowed to see. A finance question from someone outside finance gets a different answer than the same question from the finance lead, which is the access model doing its job? A concrete version of that looks like this. An employee asks an internal agent how many days of study leave they get? The agent searches indexed SharePoint content finds the current policy page and answers with a citation, and the whole exchange never leaves the tenant. There's a setting in Copilot Studio that leads directly on this idea. Tenant graph grounding with semantic search uses the semantic index behind Microsoft three. Sixty five copilot to sharpen retrieval, and Microsoft notes it helps most with SharePoint content. That's the real payoff. A well-built assistant feels like it read the right page because keyword search, meaning search, fusion, and the second ranking pass all line up under a chat box you already use. No single clever model does that work on its own. Then the honest limits and the mistakes beginners make. Let's be straight about where this breaks because knowing the walls saves you time. Mistake one is assuming hybrid is automatically better at everything. It isn't. And that difference matters. Microsoft's own results show that on queries made of pure keywords, keyword search alone still came out on top. Hybrid is a strong default, not a universal winner. And the right answer depends on the questions your users actually ask. The second trap is skipping, chunking, or feeding the system. Enormous passages. If your chunks are too big, meaning blurs and the end of each passage goes to waste. The fix is boring and effective. Cut at sentence boundaries. Keep passages small and let them overlap a little. Then there's the habit of switching on semantic ranking everywhere without watching the meter. It's built by usage, so a busy app can turn a small testing habit into a real line on the invoice. Start with the free allowance measure and expand on purpose. The hard limits are the ones you'll bump into first. Semantic ranking only ever Re ranks the fifty best results, so it can polish a shortlist but never widen it. Vector storage is capped per partition. The cap changes with your tier and the age of your service, and hitting it stops indexing rather than slowing it down. There are smaller ceilings to a vector field tops out at four thousand and ninety six dimensions, and a single vector query can target at most ten fields. The free tier is fine for learning with one service and fifty megabytes of storage, but it can be deleted after long idle stretches. Concurrency has a ceiling as well. Semantic ranking runs on a queue, and each search unit can only handle a couple of requests at once, with a short queue behind it before requests start getting rejected on a busy app that shows up as retries, so capacity planning stops being optional once real users arrive. One small mercy on billing is easy to miss. An empty query string isn't charged for semantic ranking even when the query type is set to semantic, so a filter only request doesn't add cost. Pricing comes in two shapes, and the choice matters. The dedicated model charges a fixed hourly rate based on capacity, which suits steady workloads, while the serverless model builds by consumption and is aimed at bursty or unpredictable ones. That serverless option is still in preview, so it isn't the place to run anything you depend on. None of that makes hybrid retrieval a bad choice. It makes it a choice with a shape, every point of extra relevance you buy comes from somewhere, whether that's cost, capacity, or the effort you put into preparing content and knowing which trade you're making is the difference between a demo and something that holds up. The short version is that hybrid retrieval rewards preparation clean, chunked, well described content with sensible access rules gets more out of every feature while messy content gets less no matter how many switches you flip. A short recap and one question for you the whole picture fits in a few lines. Keyword search matches the exact words you type. Vector search matches meaning and hybrid retrieval runs both at once and blends the results by rank semantic ranking, then reorders the best fifty and all of it rests on content that was chunked properly. First, my question for you is simple and I genuinely like the answer. Where in your own work would a search that understood meaning, not just words, change the most? Drop it in the comments because the answers usually reveal more than any product page ever does. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.