AI工程师面试：构建统一查询引擎的五大关键层

You are in an AI engineer interview at Google.

The interviewer asks:

"Our data is spread across many sources (Salesforce, Gmail, etc.)

How would you build a unified query engine over it?"

You: "Embed them in a vector DB and do RAG."

Interview over!

Here's what you missed:

Many devs still think context retrieval is a linear pipeline:

Chunk → Embed → Retrieve → Generate

This works great for simple demos, but production systems need something fundamentally different.

To understand better, consider this query:

"Compare our Q4 sales performance in the Chicago region against last year's projections formulated in a meeting with stakeholders."

This single query requires:

• Sales data from your SQL database - Graph relationships (organizational hierarchy) - Vector search over projection reports - Time-based filtering (Q4 this year vs last year) - Permission checks (for user authorization)

No single embedding lookup can handle this complexity!

To actually solve this problem, you'd need to build an Agentic context retrieval system with five critical layers (as described in the graphic below):

> Indexing layer:

Different content needs different indexing: - Semantic chunking for docs - Hierarchical indexing for nested content - Special indexing for sources like Calendar, Slack, etc.

> Routing layer:

Before retrieval, you need intelligent routing that decides: - Should the query hit a graph DB? - Does it need a structured SQL query? - Or semantic search for conceptual matching?

> Query construction layer:

The original query might need to be: - Decomposed into sub-queries - Translated into different query languages (SQL, Cypher, vector similarity)

> Retrieval layer: - Apply permissions and access checks - Run multiple retrievals in parallel - Rerank based on relevance/recency

> Generation layer: - Synthesize a citation-backed response

The diagram below depicts this whole process.

That said, four of these five layers run after a query arrives. Indexing runs before, which caps what the other four can do.

Even with perfect routing, query decomposition, and reranking, the system returns only what the chunks preserved.

My co-founder wrote about a better unit for that indexing step. The technique:

• cuts corpus size by 40x. - reduces tokens per query by 3x. - improves vector search relevance by 2.3x.

And it doesn't change the retrieval algorithm, the reranker, or the embedding model.

Read it below.