# The best way to handle vector search for semantic matching in video transcripts > Run vector search alongside a keyword index, and build both on the same time-stamped chunks so every hit points to a place in the recording. Canonical URL: https://vivu.ai/guide/what-is-the-best-way-to-handle-vector-search-for Run vector search alongside a keyword index, and build both on the same time-stamped chunks so every hit points to a place in the recording. Chunk by speaker turn and cap each chunk by time, with a little overlap, and store the start and end times with every vector. Merge the two result lists, then rerank the top of the merged list. How you chunk tends to matter more to result quality than which embedding model you pick. ## Why vectors alone disappoint on transcripts A clean transcript for every episode or lecture can still leave an archive hard to search. Text search over published transcripts matches words and lands on a page, and someone still has to read down that page to find the minute. Vectors fix part of that because they match meaning: a query about being nervous before a talk can match a speaker who never uses the word "nervous". They also blur the things people type most carefully. Names, product terms, course codes and quoted phrases get averaged into the meaning around them, so a query for an exact phrase can rank a vaguely related passage above the one that contains it. Someone asking for phrase search across a set of transcripts wants the passage with that phrase in it, and a list of near-misses is a failure. Keyword search handles that case, which is why the hybrid keeps both. Transcription errors cut the other way. A misheard name breaks keyword matching, while the sentence around it often still carries enough meaning for a vector match. Which way your archive leans depends on the audio, and [how accurate the transcript needs to be](https://vivu.ai/guide/what-s-the-best-way-to-transcribe-noisy-audio) is worth settling before you tune retrieval. ## Chunking is where most of the quality comes from Split on speaker turns first, then cap each chunk by time so a long monologue becomes several pieces. Add some overlap so a thought that crosses a boundary appears whole in at least one chunk. Don't let a chunk span a hard break such as a segment change or an ad read, because the embedding will average two topics into something that matches neither. Small chunks lose their referents. "That's why we stopped doing it" means nothing on its own. A common fix is to prepend a short line of context, such as the episode or lecture title and the speaker's name. Keep the original text for display and the enriched text for the embedding, and store the start time, end time, file ID and speaker with every chunk. ## Merging and reranking Run the keyword query and the vector query separately, then merge the two ranked lists. Reciprocal rank fusion is the simple way to do it, since it uses rank positions and never compares scores that aren't on the same scale. If you can filter by show, course, speaker or date, do it before the vector search. After merging, rerank the top few dozen results with a model that reads the query and the passage together. This is where semantic matching gets sharper, and it stays affordable because it only touches a short list. Expect spread in what comes back. A semantic query about stage nerves can return a whole interview segment on the subject and a passing admission in the middle of a performance, plus the occasional result that's only adjacent, like someone describing how long it took to relax on stage. That spread is the point of semantic matching, and it's why each result should show its snippet and time range so a person can decide. ## Where transcripts stop A transcript only knows what was said. Slides, demos, on-screen text and anything shown without narration are invisible to it, and covering them takes an index that also reads the picture, which is how [indexes that cover what's on screen](https://vivu.ai/guide/how-does-multimodal-video-search-work) work. Embeddings are also tied to the model that made them. Vectors from two models can't be compared, so keep the chunk text and timecodes ready to re-embed when you switch. ## Building it or not If search is a feature in a product you ship, build the hybrid pipeline and own the chunking and ranking. If the goal is finding moments in your own lectures or episodes, a hosted layer takes the pipeline off your hands. In [Vivu](https://vivu.ai/platform), there is no pipeline for you to run: recordings are uploaded to a project, and a described question comes back as time ranges you can open, including moments that were shown on screen and never said. You give up control of chunking and ranking in exchange for not operating any of it. ## When you don't need vectors If nearly every query contains a name or a quoted phrase, a keyword index with timestamps is enough and behaves more predictably. If the archive is small enough that people know where things are, or the questions map neatly onto chapter titles, a table of contents will beat any search. ## How to decide Look at the queries people actually type. If most contain a name or an exact phrase, build the keyword index first and add vectors later. If most describe an idea in words the speaker never used, vectors earn their place, and your time is better spent on chunk boundaries than on comparing embedding models. ## FAQ ### How big should transcript chunks be for embeddings? About the length of one spoken answer, which often works out to somewhere between half a minute and a minute of speech. Split on speaker turns first, cap by time, and keep a small overlap between neighboring chunks. Test with real queries instead of settling on a size in the abstract. If results land in the right area but the snippet reads as off-topic, the chunks are too long. If they match fragments that make no sense alone, they are too short or need a line of context added before embedding. ### How do I make vector search find exact names and jargon in transcripts? Add a keyword index and merge the two result lists, because embeddings are weak at exact tokens. Fix the transcripts as well: a custom vocabulary at transcription time, or a find-and-replace pass for names that are consistently misheard, helps both kinds of search. You can also boost results where the exact query term appears in the chunk text. ### Should I embed the whole transcript or each segment? Each segment, for retrieval. A single vector for an hour-long transcript averages dozens of topics into one point and can't tell you where anything is. A whole-recording summary vector is still useful as a first stage that picks which recordings to search, followed by segment search inside them. ### How do I get a timestamp back from a transcript search instead of the whole transcript? Store the start and end time with every chunk when you index it, alongside the file ID. A match then resolves directly to a range in a specific recording. Start playback slightly before the chunk's start so the viewer hears the lead-in, and show the chunk text next to the player so they can confirm the match without watching the whole range.