← Back to search

System overview · Retrieval pipeline

How Yaqeen Search works

Ask a question in plain language; get back the exact moments in Yaqeen's video library and the passages in its written works that answer it — a video plays at that second, an article opens at its page. Here is what happens between the question and the answer.

2,190
videos indexed
~70k
timestamped moments
1,002
written works, incl. 15 full books
<2s
to results

A Building the library

Done once per video, ahead of time.

Every video's transcript comes from Yaqeen's transcription service already carrying sentence-level timestamps, so we never have to align text to audio — the timing is free. We cut each transcript into ~60-second windows that overlap by 15 seconds (so a thought split across a boundary is still findable), and store every window as a searchable record in GoodMem, our vector database. Each record keeps the text plus its source: video_id, title, and start/end seconds — everything needed to build a jump-to-the-moment YouTube link later.

Two video collections are built: one of the ~70,000 transcript moments, and a second of the 2,190 video titles. The title collection is what lets a strong title match ("Malcolm X's Legacy") lift a whole video, not just one line of it.

A third collection holds the written library — 1,002 papers, blogs, curricula, topic pages and the full text of 15 books, pulled from yaqeeninstitute.org. Each work is stored whole and GoodMem splits it server-side into ~512-character passages (64 overlapping) that each remember their article's title, kind and URL — so a hit deep inside a 400-page book still links to the right page.

B Answering a question

The live path, every search, in well under two seconds. One search box, three tabs: All (the default) runs the video and written paths in parallel; Videos and Written content run one of them.

The question "why is there so much suffering"
Semantic · body Transcript moments Embedder finds candidates → Voyage reranker scores each for real relevance
Semantic · title Video titles Same path — how well the video is about the question
Semantic · written Article passages Same embed → rerank path over the written library; passages of one work collapse into one card
Exact · direct Keyword index Any moment containing every query word, verbatim — regardless of the model
Blend Weighted fusion — 0.6 × title relevance + 0.4 × moment relevance A strong title match boosts every moment of that video. Direct keyword hits are injected here and flagged. Articles carry their best passage's relevance and are interleaved with videos on the All tab by that single number.
relevance gate — keep if score ≥ 0.50  ·  exact matches exempt
Tidy up Merge & de-duplicate → one card per video, one per article Adjacent moments combine into a single time range; a title-driven video shows as "full video"; an article's extra matching passages are counted, not repeated. Direct matches rank first, then by score. On the All tab, three or more adjacent videos fold into a carousel.
ResultsResults appear instantly Each links to youtube…&t= the exact second

C Why it's built this way

Four decisions that carry the quality of the results.

PieceWhat it buys us
RerankerA raw vector match is fuzzy. The Voyage reranker re-reads each candidate against the actual question and returns a calibrated 0–1 relevance, which is what makes a meaningful cut-off possible at all.
Title weightingPeople often search for what a video is about, not a passing line. Weighting the title 60% surfaces the right video as a whole, then points inside it.
Keyword indexSemantic search has a blind spot: names. "Osama bin Laden" pulls the companion "Usama ibn Zayd" instead. A direct keyword match is a certainty the model shouldn't override — so it bypasses the reranker and the threshold.
Relevance gateVector search always returns something. The 0.50 floor lets the system say "we don't cover this" — an empty result — instead of showing confident-looking but off-topic cards. It is a deliberate precision-first choice, set from a sweep over the evaluators' 142 queries: below 0.40 the gate stops rejecting off-topic questions ("how do I boil eggs") while recall no longer improves.
Whole works, auto-chunkedWritten works are stored as one record each and chunked by GoodMem, not by us — so the same passages can later serve as grounded context for an LLM, and a book with twelve matching passages still shows as one card.

D A worked example

The keyword index earning its place — a query the model alone gets wrong.

query  osama bin laden
1
The embedder + reranker return "Usama ibn Zayd (ra)" — a companion of the Prophet. Semantically the nearest match, and the wrong one.
2
The real mention — "the letter supposedly written by Osama bin Laden" — lives inside a khutbah on war & justice. It's topically distant, so it never makes the reranker's shortlist.
✓
The keyword index finds it directly: that moment contains all of osama, bin, laden. It's injected past the gate and surfaces at 8:20 — the correct answer the model had buried.
Known limits, being honest: exact matching is literal, so a spelling variant like "usama bin laden" won't connect to "Osama"; bridging transliteration variants (usama↔osama, ibn↔bin) is a small, scoped next step. And the corpus-wide keyword index currently covers the video library — for written works the exact-match override only applies among the passages the semantic search already retrieved. Extending the index to the written library is the same mechanism pointed at the article files.

E The stack, at a glance

LayerWhat we use
Vector storeGoodMem — three collections (moments, titles, written works); runs semantic search + reranking
EmbeddingsVoyage voyage-3-large
RerankerVoyage rerank-2.5 — rescores a pool of 50 candidates per collection per search; every response reports whether reranking was actually applied
Chunkingvideos: 60-second windows, 15-second overlap · written: GoodMem default, 512 characters with 64 overlap
Tuningtitle 0.6 / body 0.4 · relevance floor 0.50 · exact-match override · top 10 cards per search

Snapshot of the current configuration — every weight and threshold above is a single tunable value, adjusted from live query traces.