Halley's AI Guide · Article

Beyond the hype: hybrid vector search with structured filters.

Regulated teams need retrieval engineered with rigor, not duct-taped from popular demos. A hybrid architecture fuses vector-based semantic search with structured filters and deep OpenAI tool-API integration — outperforming simplistic RAG pipelines and LangChain-style chains.

The pipeline 4 stages
1Structured filtersScope to the relevant subset.
2Vector searchSemantic similarity, scored.
3Assistant tool callLLM participates in retrieval.
4Rank & synthesizeCited, ordered answer.

3-minute read

Semantic vectors meet structured filters

The popular recipe for retrieval is a single step: embed the question, pull the nearest vectors, hand them to a model. It demos beautifully and fails quietly — semantic similarity has no concept of a hard constraint, so a query scoped to one person, one state, or one date range will cheerfully surface near-matches from everywhere else. For regulated teams, that gap between looks relevant and is in scope is the entire problem.

Hybrid search closes it. It combines dense vector embeddings (for semantic similarity) with structured filtering (for exact attributes and metadata). Query a knowledge base with conditions like state:Texas AND person:"Jane Doe" while also retrieving semantically relevant content. Vector search finds conceptually similar results even without keyword matches; structured filters guarantee hard constraints — semantic recall and precise filtering in one go.

This isn't theoretical. Stack Overflow improved relevance by combining semantic vector search with keyword matching; advanced vector databases pair fast vector search with real SQL filtering and joins. A hybrid system can answer "financial reports by Alice in 2021" by fuzzily matching "Alice" → "Alicia," filtering to 2021, and using vector semantics to find the right content despite varied phrasing — returning ranked similarity scores so results sort by relevance.

Under the hood: architecture walkthrough

(1) Structured filter logic: the query is parsed for structured parameters — location, date range, user ID, product — and those filters scope the search to a relevant subset, with exact and fuzzy matching ("Acme Corp" matches "Acme Corporation").

(2) Vector search: the remaining query text is embedded and run through a vector engine across the pre-filtered subset, returning top-N candidates with similarity scores.

(3) OpenAI Assistant integration: using function-calling, the assistant actively participates — generating a search tool call with query and filters that the system executes, then feeding results back. Clean asynchronous code means the LLM fetches in parallel, handles timeouts, and streams efficiently.

(4) Result ranking & synthesis: similarity scores provide a base ranking, refined by business rules or LLM re-ranking, producing a ranked list or a composed answer that cites top sources.

Engineering for performance, observability & precision

Performance is baked in: structured filtering prunes the search space early, vector searches run on optimized indexes (HNSW, FAISS) in sub-second time, and asynchronous parallelism overlaps the DB fetch, embedding, and LLM call — unlike linear RAG pipelines that waste time in strict sequence.

Observability is a differentiator: because each stage is explicit (filter parsing, DB query, embedding lookup, LLM call, ranking), every part can be instrumented with logging, metrics, and traces — so teams can monitor and tune the pipeline at scale.

Precision is the whole point: structured filters are hard guarantees, not gentle hints, so out-of-scope records never reach the model — a different posture from hoping a re-ranker buries them after the fact. Every answer carries the citations and similarity scores behind it, giving regulated teams an auditable line from question to source instead of a confident paragraph with no provenance.

Retrieval engineered for precision.

See hybrid search grounded in your own corpus — with citations and controlled boundaries.