Spokes.wiki Search Graph Growth About

research-wiki

Article source ↗ source url updated Wed Jun 03 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Why Vector Search Alone Isn’t Enough: Hybrid Retrieval for RAG

InfoQ engineering piece on hybrid retrieval for retrieval-augmented-generation — and the vendor-neutral RAG source the RAG page had been missing (prior data points came from LLM-wiki/gbrain advocates). Thesis: “embeddings are approximation engines — their strength and their limitation,” so production RAG needs more than vector search.

Why vector-alone fails

Dense embeddings capture meaning (“kill switch” ≈ “rollout gate”) but collapse small distinguishing tokens — version numbers, error codes, feature-flag names. Worked example: a query for the runbook to enable payment_v2_enforce returns the disable runbook (both cluster identically). Vectors actively hurt exact-identifier queries.

The layered architecture

Why it matters here

The neutral corroboration this wiki wanted: it independently confirms gbrain‘s hybrid retriever (vector + BM25 + RRF + reranker) as the production-correct design, separating that engineering claim from GBrain’s self-interested benchmark. It also sharpens the RAG critique — the gap isn’t “retrieval is bad” but “semantic retrieval alone misses exact + factual distinctions” (gbrain adds a knowledge-graph for the factual-connection gap; this adds BM25 for the exact-token gap). Relevant to knowledge-as-a-service delivery and the retrieval-survival half of GEO (cross-wiki). Audience: engineers building RAG.

retrieval-augmented-generation · gbrain · knowledge-graph · knowledge-as-a-service