Google 和 Anthropic 在检索这件事上英雄所见略同。
他们都把检索从应用里抽离了出来，做成了 Agent 调用的独立服务。
- Anthropic 的 MCP 把检索变成了 Agent 可以调用的工具。
- Google 也差不多，RAG Engine 放在 Gemini Agent 平台下，跟 MCP server 待在一起。
之所以这么做，是因为老旧的 naive RAG 是应用内部的单次流水线，这会导致两个痛点：
- 一是向量（embeddings）容易过时。索引反映的是采集那一刻的状态，文档一变，索引就失效了，除非重跑整个流水线。
- 二是架构太耦合。检索逻辑死在应用里，换个应用就得重搞一遍连接器、切片和向量化，根本没法复用。
把“数据摄取（ingestion）”和“查询（query）”分开，让摄取作为常驻层运行，就能解决这些问题。
摄取层通过内容哈希同步持续运行，只重新向量化变动的数据。再加上统一的 API，不管是聊天机器人还是 Agent，用的都是同一个索引。
Agent 在循环里把这一层当工具使：先推理，搜一下，读结果，再优化查询，而不是上来只搜一次就完事。
下图展示了三个阶段：从 naive RAG 到常驻层，再到被 Agent 调用的过程。
但这还没搞定所有问题，因为这三个阶段的检索单元还是没变：依然是“文本切片（chunk）”。
切片本质上没有语义边界、版本或来源信息。切分器主要按 token 计数来切，导致切片经常断在表格中间或者论据一半的地方。
结果就是，你可能搜到了表头却没搜到内容，或者只有结论却没有论据。
解决办法是转向“结构化单元”：把问题和验证过的答案打包嵌入。
我写了一篇深度拆解。核心是用自带来源和版本的“结构化块”取代原始切片。
这套方案把语料库缩小了 40 倍，向量相关性提升了 2.3 倍。
全文点击下方阅读。
他们都把检索从应用里抽离了出来，做成了 Agent 调用的独立服务。
- Anthropic 的 MCP 把检索变成了 Agent 可以调用的工具。
- Google 也差不多，RAG Engine 放在 Gemini Agent 平台下，跟 MCP server 待在一起。
之所以这么做，是因为老旧的 naive RAG 是应用内部的单次流水线，这会导致两个痛点：
- 一是向量（embeddings）容易过时。索引反映的是采集那一刻的状态，文档一变，索引就失效了，除非重跑整个流水线。
- 二是架构太耦合。检索逻辑死在应用里，换个应用就得重搞一遍连接器、切片和向量化，根本没法复用。
把“数据摄取（ingestion）”和“查询（query）”分开，让摄取作为常驻层运行，就能解决这些问题。
摄取层通过内容哈希同步持续运行，只重新向量化变动的数据。再加上统一的 API，不管是聊天机器人还是 Agent，用的都是同一个索引。
Agent 在循环里把这一层当工具使：先推理，搜一下，读结果，再优化查询，而不是上来只搜一次就完事。
下图展示了三个阶段：从 naive RAG 到常驻层，再到被 Agent 调用的过程。
但这还没搞定所有问题，因为这三个阶段的检索单元还是没变：依然是“文本切片（chunk）”。
切片本质上没有语义边界、版本或来源信息。切分器主要按 token 计数来切，导致切片经常断在表格中间或者论据一半的地方。
结果就是，你可能搜到了表头却没搜到内容，或者只有结论却没有论据。
解决办法是转向“结构化单元”：把问题和验证过的答案打包嵌入。
我写了一篇深度拆解。核心是用自带来源和版本的“结构化块”取代原始切片。
这套方案把语料库缩小了 40 倍，向量相关性提升了 2.3 倍。
全文点击下方阅读。
Google and Anthropic agree on one thing about retrieval.
They both moved it out of the app and turned it into a standalone service that agents invoke.
- Anthropic's MCP exposes retrieval as a tool that an agent invokes.
- Google ships it similarly, with its RAG Engine sitting under the Gemini agent platform next to MCP servers.
They did this because the old naive RAG setup was built as a one-time pipeline inside a single app, and it caused problems in two places:
- The first is stale embeddings. They reflect the source at indexing time, so the index drifts from the source when a doc or a row changes, and stays wrong until the pipeline is rerun.
- The second is coupled infrastructure. The retrieval logic sits inside one app, so another app duplicates the connectors, chunking, and embedding instead of reusing them.
Both failure modes are resolved by separating ingestion from query and running ingestion as a standing layer.
Ingestion runs continuously with content-hash sync, so only changed data is re-embedded, and the layer sits behind one API, so a chatbot and an agent hit the same index.
The agent then calls that layer as a tool inside a loop. It reasons, runs a search, reads the result, and issues a refined query, instead of retrieving once at the start.
The diagram below depicts all three stages, covering naive RAG, the standing layer, and the agent consuming it.
This helps, but it didn't solve all problems yet because across all three stages, the unit of retrieval is the same, i.e., a chunk of text.
And inherently, a chunk has no idea of a semantic boundary, version, or source info. The splitter cuts documents mostly on token count, so a single chunk can end mid-table or mid-argument.
Because of that, it can pull the top half of a table without the rows, or a conclusion without the reasoning that supports it.
Moving to a structured unit, embedding a question with its validated answer, addresses this.
I wrote wrote a full breakdown on solving this. It replaces raw chunks with structured blocks that carry their own source and version.
The approach reduces corpus size 40x and improves vector relevance 2.3x.
Read it below.
They both moved it out of the app and turned it into a standalone service that agents invoke.
- Anthropic's MCP exposes retrieval as a tool that an agent invokes.
- Google ships it similarly, with its RAG Engine sitting under the Gemini agent platform next to MCP servers.
They did this because the old naive RAG setup was built as a one-time pipeline inside a single app, and it caused problems in two places:
- The first is stale embeddings. They reflect the source at indexing time, so the index drifts from the source when a doc or a row changes, and stays wrong until the pipeline is rerun.
- The second is coupled infrastructure. The retrieval logic sits inside one app, so another app duplicates the connectors, chunking, and embedding instead of reusing them.
Both failure modes are resolved by separating ingestion from query and running ingestion as a standing layer.
Ingestion runs continuously with content-hash sync, so only changed data is re-embedded, and the layer sits behind one API, so a chatbot and an agent hit the same index.
The agent then calls that layer as a tool inside a loop. It reasons, runs a search, reads the result, and issues a refined query, instead of retrieving once at the start.
The diagram below depicts all three stages, covering naive RAG, the standing layer, and the agent consuming it.
This helps, but it didn't solve all problems yet because across all three stages, the unit of retrieval is the same, i.e., a chunk of text.
And inherently, a chunk has no idea of a semantic boundary, version, or source info. The splitter cuts documents mostly on token count, so a single chunk can end mid-table or mid-argument.
Because of that, it can pull the top half of a table without the rows, or a conclusion without the reasoning that supports it.
Moving to a structured unit, embedding a question with its validated answer, addresses this.
I wrote wrote a full breakdown on solving this. It replaces raw chunks with structured blocks that carry their own source and version.
The approach reduces corpus size 40x and improves vector relevance 2.3x.
Read it below.
19
21
166
19.5K
