企业 RAG 的边界：托管流水线、向量库与「可写回」检索

#

当基础模型跨过「能答」的门槛，企业真正卡住的多半不是再训一个 7B，而是：私有数据如何进索引、检索如何选对库、生成如何只信该信的源。Google 把这条链收成 Vertex AI RAG Engine 的托管流水线；Weaviate 则长期站在向量存储与数据建模一侧。二者在 2024 年底至 2025 年初的集成，把争论从「要不要 RAG」推回到更硬的问题：单 corpus 文档索引是否够、解析与分块谁优先、RAG 何时该变成可写回的双向回路。

下文按工程主题组织：常见做法 → 嘉宾主张 → 可核对证据与未证边界。不强行给出单一结论。

托管 RAG 流水线：为什么存在、边界在哪

#

为什么

#

自研 RAG 往往重复实现：数据源接入、分块、嵌入、索引生命周期、检索 API、与生成模型的上下文拼接。团队规模小时可行；一旦 corpus 变大、合规与 IAM 变严，运维与版本锁定（尤其 embedding 与 corpus 绑定）会吃掉大量精力。官方文档将 RAG Engine 描述为六步：ingestion → transformation（含 chunking）→ embedding → indexing（corpus）→ retrieval → generation；默认向量后端为托管 RagManagedDb（基于 Spanner），也可接 Vector Search、Feature Store、Weaviate、Pinecone 等。

机制与约束

#

• 不自研向量库：产品定位是编排层，而非替代 Weaviate/Pinecone 的数据库。（文献/文档支持）
• Corpus 与嵌入模型生命周期绑定：文档写明 “association between your embedding model and the RAG corpus remains fixed for the lifetime of your RAG corpus”——换嵌入通常意味着重建索引。（文献/文档支持）
• GA 时间线：发布说明记载 2024-12-20 RAG Engine GA；介绍博客 datePublished 为 2025-01-10。嘉宾称团队约「2024 年初」启动——官方未见对应表述。（访谈观点 vs 发布说明）

怎么做（最小路径）

#

快速入门见 RAG quickstart。若已有 Weaviate 实例，专页 将 Weaviate 与 RAG 搭配使用 要求 CreateRagCorpus / UpdateRagCorpus 与 collection 一对一，并通过 Secret Manager 配置 API Key；支持 hybrid search 与 dense/sparse 权重调节。

常见误区

#

• 把 RAG Engine 当成「又一个聊天机器人」——发布博客 强调其作为 Gemini API 的 tool 嵌入现有应用。（文献/文档支持；「非 chatbot」为产品定位表述）
• 假设换 embedding 是改配置即可——需按文档规划 corpus 重建。
• 将「几分钟跑通 notebook」等同于生产最优：嘉宾与文档均指向 手动调参（chunk_size、chunk_overlap 等），尚无 AutoML 式自动搜参。（见后文 P05）

外部向量库：Weaviate 在流水线中的位置

#

为什么

#

客户已在用开源或自管 Weaviate 时，迁移到云厂商托管索引的切换成本高。集成诉求是：少改应用逻辑、保留 schema 与 hybrid 能力、在 Vertex 侧扩展 ingestion/检索。（访谈观点；与 Google 专页方向一致）

机制与约束

#

怎么做

#

按 use-weaviate-db 配置 schema 字段（如 fileId、corpusId、chunkId、chunkData）。Marketplace 上的 Weaviate Shared Cloud 解决的是部署订阅，不等于 RAG Engine 连接器本身。

常见误区

#

• 把 Preview 当 GA 做 SLA 承诺。
• 忽略 ingestion 在 Google 侧、向量在客户侧 的双运维边界。

解析与分块：杠杆在 transformation，而非只堆 rerank

#

为什么

#

检索失败常源于 chunk 语义断裂、表格被切碎、标题层级丢失。嘉宾（Vertex PM）认为当前 RAG 质量提升的 最大杠杆在 parsing/chunking，rerank 有帮助但次之；另一位嘉宾同意 parsing 优先，并补充 re-index 与 embedding 推理成本 的优化空间。（访谈观点；Google 未书面排序「parsing > rerank」）

机制与约束

#

• Document AI layout parser：按 layout entity（标题、表格、列表）生成 context-aware chunks。
• Reranking：semantic-ranker-default@latest、LLM reranker（Gemini 相关性打分）并存——两者皆为官方一等能力。
• 可调参数：嵌入模型页 默认推荐 text-embedding-005；fine-tune transformations 给出默认 chunk_size 1024、overlap 256（token）。嘉宾所称「90–95% 质量、先上手后极致」——无官方数值。（访谈观点）

Anthropic Contextual Retrieval（2024-09-19）报告 failed retrievals 降 49%，叠加 rerank 降 67%——指标定义与 Vertex layout parser 不可直接移植数值；Vertex 文档 未 宣称采用 Anthropic 同名方案。

怎么做

#

对 PDF/复杂版式启用 layout parser；对纯文本可先 fixed-size chunking（GA 发布说明提及 fixed-size + overlap）。评估时分别记录 检索失败率 与 生成 grounded 率，勿混用 Anthropic 与 Google 栈的 benchmark。

常见误区

#

• 先上 rerank、后补解析——与嘉宾优先级相反，且可能放大错误 chunk 的分数。
• 把 contextual retrieval 当作 Vertex 默认实现——未证实。

单 corpus 文档模型 vs 企业多源现实

#

为什么

#

Connor 提出：RAG Engine 的隐含模型接近 「一个搜索索引 + 文档块」。企业侧却是营销表、博客、多个 Weaviate collection、数据仓库多表 schema 并存。（访谈观点）

机制与约束

#

语义冲突（如德/奥对「湖/海」定义不同）在传统本体工程里靠 schema 硬约束；Bob 认为 prompt + 向量检索 可缓解部分歧义，Lewis 反驳规则式 prompt 会堆积成「无数条 regex」——最终精确控制仍可能回到 SQL / 形式化查询。（均为演讲者观点）

Lewis 强调：多源 RAG 需要中间 reasoning stack / agentic flow 做语义映射与 pipeline 选择（全发 vs 选择性调用）。这与文档侧「单 corpus 编排」形成 架构留白：需自建路由层。

怎么做

#

为每个 业务域 建独立 corpus/collection；在应用层实现 意图分类 + corpus 路由（或 LangGraph/自研 agent）。ontology 与数仓 schema 的对齐仍是开放问题，勿假设 RAG Engine 自动理解「表即本体」。

常见误区

#

• 把所有表塞进一个 corpus 指望模型自己懂 join。
• 用 prompt 替代数据治理——短期有效，长期维护成本可能不低于规则引擎。

单向 RAG 与「可写回」：generative feedback 的命名差

#

为什么

#

经典 RAG：query → retrieve → generate → 展示，数据流单向。Bob 提出 generative feedback loop：生成结果可 update/delete/校验并写回 向量库；collection 级 instruction 可在 ingest 时拒绝、警告或存修正版；Lewis 将其与 GAN 式双模型互评、agent 架构联系。（演讲者观点）

机制与约束

#

Weaviate 官方相近能力为 Transformation Agent（Technical Preview，文档写明 “Do not use in production”）：fetch → transform/enrich → write back，原地更新对象属性。与 Bob 所称 ingest 闸门式 generative feedback 机制不完全一致；术语 generative feedback loops 在 docs.weaviate.io 未检到同名专页。

Vertex RAG Engine 文档侧重检索增强生成，未 描述将 LLM 输出标准写回 corpus 的路径。MDM（主数据管理）场景：嘉宾称模型自动化约 70% 即重大进展，100% 不现实——无论文编号。（访谈观点）

怎么做

#

若需写回：在 Weaviate 侧评估 Transformation Agent 或自研 post-generate pipeline；在 Vertex 侧仍将 RAG Engine 视为 读路径，写路径单独设计审计与版本。

常见误区

#

• 把营销用语 generative feedback loops 直接等同于 GA 产品能力。
• 在生产环境启用 Preview Agent 且无回滚策略。

Grounding：Search、企业 corpus 与 parametric knowledge

#

为什么

#

企业 RAG 要 保守、可审计：事实来自外部源，而非可能过时的参数记忆。消费端先例是 Gemini 的 Grounding with Google Search——需要公开、最新 Web 知识时启用。

机制与约束

#

• RAG Engine 与 Gemini：原生 tool 集成（博客原文 “natively integrated with Gemini API as a tool”）。（文献/文档支持）
• Lewis 愿景：模型像知道自己何时该 Search 一样，路由到 sales corpus / HR index——无 Google 公开训练卡或企业多 corpus 自动路由规范。（访谈观点）
• 抑制 parametric knowledge：举例「Alphabet Q4 2023 营收」——公开信息或在权重中，但企业要求 只信内部上下文；嘉宾提出 system instruction + 对比样本的 SFT 式行为，并自述 naive、非最终实现。（无法核实为官方能力）

怎么做

#

组合：RAG corpus 检索 + grounding 配置 + 明确 system instruction（禁止未引用断言）。多源时显式实现 router，勿假设模型自发选对库。

常见误区

#

• 仅外挂 RAG、不处理模型「以为自己知道」——检索到了仍可能掺入参数知识。
• 将 Lewis 的训练设想写成已发布 Gemini 功能。

图、本体与 multi-vector：概念桥接，非默认架构

#

为什么

#

语义网长期投入本体与 KGM；嘉宾（含前 KG 从业者）倾向 向量库 + embedding + LLM 在大规模场景绕开严格实体关系，Lewis 仍保留「可有图结构，但遍历可由 LLM 革新」。（演讲者观点）

机制与约束

#

Weaviate named vectors：Collections can have multiple named vectors，查询需指定 target vector。Connor 类比「每对象多向量 ≈ 图中多条边」——为概念类比，非官方定义。向量库对比表写 Weaviate 具 built-in graph capabilities（cross-references），与 named vectors 是不同机制。

怎么做

#

关系密集域可试验 多向量 + cross-reference；勿在未验证检索收益前全盘放弃数仓 schema 治理。

常见误区

#

• 用 multi-vector 替代 join 与血缘文档。
• 把 schema.org 级本体实施难度低估为「embedding 即可」。

调参、成本与「类 AutoML」空白

#

为什么

#

生产上 token 成本推动 fine-tune / distillation；嘉宾亦转述第三方趋势：RAG 采用上升，prompt engineering 与 fine-tuning 热度下降——Menlo 报告原文本环境未核对（403）。（访谈转述，无法核实）

Bob 观点：基础模型「够好」后，fine-tuning 商业价值下降，企业首要问题是 用自己的数据怎么做。（演讲者观点）

机制与约束

#

Lewis 愿景：LLM 在 corpus 上建议 chunking/embedding，批量试跑（如 10 组）选最优——类似 AutoML，但 RAG Engine 今日无此 API。（访谈 + 文档否定项一致）匿名案例：百万级手册改阈值重跑 pipeline 约 一周——无第三方佐证。

Connor 提及 DSPy 作优化框架——非 Google 内置。

怎么做

#

用手动 fine-tune-rag-transformations 与离线 eval 迭代；蒸馏留给 高频、固定模板 查询。Bob 提议 20% 文档采样 推断其余 80% 重索引质量——研究向想法，无论文。

常见误区

#

• 等待官方 AutoML for RAG 再上线——产品路线图未承诺。
• 为省检索成本跳过 eval 集建设。

Agent、工作流与评估：何时不必「全能 agent」

#

为什么

#

多 pipeline、多 corpus 时，需要推理 选哪条流水线 或并行调用。MDM 菜单式自动化：嘉宾称模型按人类菜单执行约 70%，余下靠经验。（访谈观点）Lewis 称 MDM 仍是 GenAI 浪潮约 2.5 年后 尚未被颠覆 的硬骨头。

机制与约束

#

Agent（开放工具、循环决策）vs Workflow（固定 DAG）的选择取决于：失败成本、可解释性、延迟预算。RAG Engine 提供的是 可嵌入能力块，不是替代 BPM 的全自动 MDM。

评估应覆盖：检索命中率、引用忠实度、写回一致性（若有）、成本 per query——而非仅生成流畅度。

怎么做

#

• 低歧义、单 corpus：workflow + RAG tool 往往足够。
• 多源、需消歧：agent + 显式 router + human-in-the-loop。
• 写回场景：单独定义 审计日志与批准门。

常见误区

#

• 为「显得先进」上 agent，却无工具边界与终止条件。
• 用 thumbs up/down 代替检索层失败分析。

若你要落地

#

1. 先钉死数据模型：按业务域划分 corpus/collection；接受 embedding–corpus 生命周期绑定，规划重建窗口而非假设热切换。
2. 把预算花在 transformation：优先 layout/context-aware chunking 与注入质量；rerank 作为第二层；用与栈匹配的指标（勿照搬 Anthropic 49%/67%）。
3. 多源必须自建 router：RAG Engine + Weaviate（Preview 集成）解决的是单链编排，不会自动替你完成 sea/lake 级语义映射或 MDM。
4. 写回与 MDM 分路径设计：读用 RAG Engine；写用 Weaviate Transformation Agent（或自研）并视为实验特性，直到走出 Preview。
5. grounding 拆两层：检索上下文 + 禁止未引用断言的 instruction；若模型「已知」 públic 事实却与内部政策冲突，需产品层策略而非仅加检索——Lewis 所述训练抑制 未获官方文档支持，应做 POC 验证。

参考与延伸阅读

#

• Vertex AI RAG Engine 概览
• 向量数据库选项（含 Weaviate Preview）
• 将 Weaviate 与 RAG 搭配使用
• RAG 快速入门
• 数据注入
• 使用嵌入模型（text-embedding-005 等）
• 微调 RAG 转换参数
• Document AI 布局解析器
• RAG 检索与重排
• Introducing Vertex AI RAG Engine（产品博客）
• Generative AI 发布说明（2024-12-20 GA）
• 依托 Google 搜索进行接地
• Weaviate 数据概念：named vectors
• Weaviate Transformation Agent
• Anthropic：Contextual Retrieval
• DSPy（提示与权重优化框架）