07 · 从 Google AI 调研理解平台选型：先分清系统职责

定位：研究归纳。 docs/google/ 有六篇生态与实践资料，但仓库没有据此交付完整的 Vertex AI、企业 RAG 或云端 Agent 系统。下文保留可迁移的选型方法，不将原文型号、额度、价格、地区或数据政策复述为当前事实。

讨论 AI 技术选型时，人们经常把几个不在同一层次的名字放到同一张比较表：一个是模型，一个是开发控制台，一个是企业平台，另一个是面向个人的知识工具。最后比较的往往不是技术能力，而是哪个名字更熟悉。

Google AI 调研的长期价值，并不在“这一代哪个模型领先”，而在于帮助我们拆开这些层次。先知道系统需要承担什么责任，再决定由哪类产品承担。

一、模型不是平台，平台也不是应用

原始资料覆盖了 Gemini、AI Studio、Gemini API、Vertex AI、NotebookLM、Gemma，以及面向编程或 Agent 的工具。整理成技术决策时，可以分成五层：

层次	解决的问题	选型时首先核查
模型能力	输入输出、理解和生成	支持模态、上下文、任务质量、稳定性
开发入口	如何试验和发起调用	SDK、认证、配额、调试体验
企业治理	如何持续、安全地提供服务	身份、区域、审计、网络、成本归属
应用工作流	如何完成一个业务目标	检索、工具执行、状态、人工确认
最终产品	用户如何消费结果	来源展示、交互、协作、分发

同一家厂商可以同时提供这些层，但购买或接入其中一层，不意味着其余责任自动完成。例如，能调用模型并不表示拥有数据权限继承；能部署服务也不表示生成答案符合业务规则。

二、从实验入口到企业平台，变化的是责任

原文用开发者 API 与企业平台作对照。对项目最有帮助的读法，不是直接复制某个“支持/不支持”表格，而是问：我们是否开始需要以下能力？

• 按团队或应用区分身份、预算和访问范围。
• 按数据敏感性限制存储、传输、日志与处理区域。
• 在请求失败、配额耗尽、版本迁移时维持业务可用性。
• 追查某个输出用了哪些数据、工具、提示版本和模型配置。

当这些要求成为合同或组织责任时，架构复杂度往往已超出“换一个 SDK 初始化参数”。即使平台提供相关能力，也要逐项确认适用产品、服务等级、地区和实际配置；不能用一句“企业版保证合规”代替核验。

对于一次性、低敏感的可行性实验，过早引入完整云平台也可能增加成本。正确的选择是与责任匹配，而不是总选功能最多的一项。

三、长上下文与检索增强，不是二选一的信仰

资料同时讨论了大文档直接输入与企业知识库检索。两者解决的是不同条件下的上下文组织问题。

直接放入上下文适合数据规模可控、资料相对固定、任务需要跨全文推理的场景。它的风险是每次传输与处理成本、无关内容干扰、引用定位困难，以及权限边界变得粗糙。

检索增强适合资料持续更新、需要精确来源或访问控制的场景。它增加了切分、索引、召回、排序和版本一致性的工程负担。模型答错时，必须先判断是没有召回证据，还是有证据却没有正确使用。

一个可靠的比较实验，应让两种方案回答同一组带标准出处的问题，记录检索命中、答案依据、拒答、成本和延迟，而不是只看演示答案是否流畅。较长的上下文窗口不自动消除检索问题，加入向量库也不自动降低幻觉。

四、工具调用的返回值不是执行许可

工具调用资料讨论了函数名、描述和参数约束。这里可以提炼出一条与厂商无关的边界：模型负责提出结构化意图，宿主程序负责决定是否执行。

flowchart LR Question["用户请求"] --> Model["模型提出工具调用"] Model --> Gate["参数校验与权限检查"] Gate --> Confirm["必要时人工确认"] Confirm --> Tool["宿主执行工具"] Tool --> Result["结构化结果或错误"] Result --> Model

一个名为“查询订单”的工具，即使参数是合法 JSON，也必须检查请求者是否能读取该订单。一个“生成预览”的调用，也不应通过隐藏副作用直接发布作品或触发付款。

可以把失败整理为可恢复的结构化错误，但不能机械地认为所有异常都应该吞掉。权限失败、无效参数、临时故障和宿主程序缺陷需要不同处理。超时重试还必须考虑幂等性，避免模型重复调用导致重复写入或重复计费。

图 07：模型生成工具名和参数；宿主执行参数校验、权限检查及按风险设置的人工确认。工具可连接不代表调用者有业务权限。

五、知识工具与开放权重，各自保留了什么责任

围绕个人知识资料工作的产品，可以降低资料组织与问答的起步成本，但它并不等同于可自由嵌入业务的后端服务。要研究自动化接入，应先核对产品实际提供的接口和条款，而不是从界面功能推断 API 能力。

开放权重则把更多部署责任交给使用方：运行时兼容、量化方式、硬件、模型版本、分发和许可证都需要自己管理。“权重可下载”不能直接等同于任何用途都免费或无限制。是否适合端侧，也取决于峰值工作集和任务质量，而非仅看参数大小。

这两类选择与企业云平台没有必然的高低关系，只是在便利性、控制权和运维责任之间分配不同。

六、怎样把研究变成可验证的选型

下面是一份建议实验，而不是仓库已经完成的集成：

1. 选择一组允许进入模型系统的低敏感资料，标注代表性问题、正确答案出处和应当拒答的情况。
2. 用最小接口实现一种直接上下文方案，再实现一种检索方案；不要同时更换模型、资料和提示词。
3. 对工具调用加入越权、错误参数、重复请求和超时案例。
4. 分开记录任务质量、输入处理成本、输出成本、检索/工具成本及人工接管比例。
5. 把候选平台的数据政策、区域可用性、认证方式和版本限制作为独立检查项。
6. 只有满足业务质量门槛的方案，才进入成本与运维比较。

结语

生态调研最好的输出不是一张永久有效的产品排行榜，而是一张责任分配图。模型能力会变，平台名称会变，但身份、证据、资源、权限和失败处理始终需要有人负责。