GenAI落地的胜负手，不在模型
DoorDash工程师复盘内部GenAI平台：从厂商优先转向开源权重、用LLM与Agent网关服务5000+内部用户；The New Stack则指出关系型证据该用Graph RAG。两件事指向同一结论——企业GenAI的胜负手在网关、检索与权衡机制，不在模型本身。
两份看似不相关的材料，最近同时摆上了我的案头：一份是 DoorDash 工程师 Swaroop Chitlur 和 Siddharth Kodwani 分享的内部 GenAI 平台架构复盘，另一篇是 The New Stack 关于 Graph RAG 适用边界的技术文章。前者讲的是平台怎么搭，后者讲的是检索怎么选。
把它们放在一起看，会得出一个这几年被反复验证、却总被人绕开的判断：企业 GenAI 的分水岭，从来不在选哪个模型，而在模型之外的基础设施。
🚪 从买模型到养模型：DoorDash 的一次转向
“平台化的第一步，往往是承认自己会换供应商。
DoorDash 的起点非常典型：vendor-first，厂商优先。业务要快速验证 GenAI 能不能提效，最短路径就是直接接闭源模型的 API，几个星期就能让内部用户用上东西。这套打法在验证期几乎无可指摘。
但规模一上来，问题就换了一副面孔。这个平台要服务的是超过 5000 名内部用户——不是几个 PoC 团队，而是整条业务线上形形色色的场景：客服辅助、内部知识问答、代码与文案、数据分析。当使用方从个位数团队变成四位数用户，厂商优先的三个结构性缺陷会同时暴露：
- 议价与成本失控：所有流量走单一厂商，价格没有第二选项；
- 能力锁定：模型的能力边界就是平台的能力边界，厂商排期决定你的路线图；
- 切换成本随时间递增：接得越深，迁移越痛。
于是 DoorDash 做出了一个关键架构赌注：从 vendor-first 转向 open-weights，开源权重模型。注意，这不是简单地“换掉闭源”，而是把模型层从“外部服务”重新定义为“可运营的内部资产”——权重在自己手里，托管方式、微调策略、上下线节奏都由平台团队掌控。
据多位接近大厂平台团队的人士透露，这个转向正在成为普遍动作：头部公司在 2024 年前后普遍完成“闭源验证”，2025 年的共识变成了“开源权重必须是可选项之一”。没人敢把公司级 AI 的命脉押在单一 API 上。
这里的产业逻辑值得说透：模型正在从“采购品”变成“耗材”。耗材的特征是可替换、可组合、可按场景分级。当一个企业内部同时跑着前沿大模型、微调小模型和任务专用模型时，模型本身的差异被平台层抹平了——这正是下一节要讲的网关。
🧭 网关才是 GenAI 平台的真正中枢
“谁控制了路由，谁就控制了成本和体验。
DoorDash 的分享里有两个容易被轻描淡写、实则分量最重的词：LLM Gateway 和 Agent Gateway。
先说 LLM 网关。它的本质是把“调用模型”这件事从业务代码里抽出来，变成平台统一管控的一个层。所有请求经过网关，意味着平台团队第一次拿到了全局视图：哪个团队在用哪个模型、token 花在哪、失败率多少、延迟分布如何。没有这一层，5000 个用户的成本和体验就是一笔糊涂账。
网关之上还有一层更值得关注的：Agent Gateway。2025 年以来，企业内部的应用形态明显从“单次问答”转向“多步智能体”——一个任务要拆解、调用工具、多次往返模型。智能体的请求模式与聊天完全不同：调用链长、重试逻辑复杂、出错放大效应强。如果每个智能体各自直连模型，平台团队会彻底失去可见性。
`mermaid
graph TD
A --> B["Agent网关"]
B --> C
C --> D
C --> E
C --> F
B --> G`
这张图里藏着一个判断：网关是 GenAI 平台事实上的内核。它同时承担三件事——
1. 路由：按场景把请求分配到最合适的模型，贵的大模型只用在刀刃上；
2. 观测：统一的指标、日志与审计，这是治理的前提；
3. 解耦：业务代码不感知模型变更，换模型、降版本、做灰度，都在网关后面完成。
一位做过类似平台的架构师私下说过一句很传神的话：“我们花了一年才明白，GenAI 平台一半的工程量在网关，另一半在检索。”
检索，正是第三节的主题。
🕸️ 关系即证据：Graph RAG 补上检索的另一半
“向量能找到相似的内容，找不到“谁依赖谁”。
The New Stack 那篇文章的标题起得很准：当关系本身是证据的一部分时，用 Graph RAG。文章举了一个企业里极其常见的提问：
- 哪个团队拥有那个依赖了漏洞库的服务？
- 哪些客户在用这个服务？各自的影响是什么？
这两个问题的共性在于：答案不藏在任何一段文本里，而是藏在实体之间的边上。团队—服务—依赖库—客户，这是一条关系链。你把文档切片扔进向量库，语义检索会把“漏洞库介绍”“服务说明”各自召回一堆，但永远拼不出“影响面”这条完整链路。因为向量检索擅长的是“相似”，而这两个问题要的是“可达”。
Graph RAG 的做法是在向量召回之外，引入图谱遍历：从问题中识别实体，沿着预构建的关系图走边，把“直接证据 + 邻接证据”一起交给模型。这与 DoorDash 平台里的检索层设计恰好互补——RAG 不是一种技术，而是一族按证据形态选型的方案：
`mermaid
graph TD
Q --> P["意图解析"]
P --> V
P --> G
G --> H
G --> I
V --> M
G --> M
M --> A`
落到工程上，我认为选型可以归纳为一张表：
| 证据形态 | 典型问题 | 适配方案 | 建设成本 |
|---|---|---|---|
| 语义相似 | 文档里怎么定义X | 向量 RAG | 低 |
| 结构化事实 | 上季度GMV是多少 | Text2SQL | 中 |
| 关系链路 | 谁依赖这个漏洞库 | Graph RAG | 高 |
| 混合形态 | 分析漏洞影响面并给出客户清单 | 向量+图谱融合 | 高 |
需要提醒的是，Graph RAG 不是免费午餐。图谱的构建与维护本身就是一项数据工程：实体对齐、关系抽取、图 schema 演进，每一项都是持续的投入。如果企业本身没有较好的数据治理基础，先建图再建 RAG，等于把两个难题叠在一起做。我的建议是：先盘点你的高频问题里有多少个是“关系型问题”，再决定要不要为它付建图的成本。
⚖️ 5000 人的精度、延迟与成本三角
“平台的价值，是把权衡从业务手里接过来。
回到 DoorDash 分享里最朴素也最难的那句话：为 5000 多名内部用户平衡 accuracy、latency、cost。
这三个词每个团队都挂在嘴边，但“平台级”的平衡和“单应用级”的平衡完全是两回事。单个应用可以为了效果无视成本，或者为了省钱牺牲延迟——它只对自己负责。而平台不行：平台上有几十上百个场景，有的要求毫秒级响应，有的可以接受长思考；有的是内部高频工具，一天被调用几万次；有的是低频高价值任务，允许用最贵的模型。
`mermaid
graph TD
T --- L["延迟"]
L --- C
C --- T
P --> T
P --> L
P --> C
`
把这个三角拆开看，每条边背后都是一项具体的平台能力：
- 精度 ↔ 成本：靠模型分级与路由实现——简单任务走小模型，复杂任务才升级，这一刀切下去，成本结构立刻不同；
- 精度 ↔ 延迟：靠缓存、流式输出、投机解码等推理优化，以及“快模型预答 + 慢模型兜底”的分层策略；
- 延迟 ↔ 成本：靠自托管开源权重的弹性伸缩，把峰谷成本抹平。
而支撑这一切的前提，还是回到网关的统一观测。没有按场景、按团队、按模型的细粒度度量，任何优化都是盲调。
把 DoorDash 的演进路线串起来，其实是一份可以直接抄的企业 GenAI 平台路线图：
1. 阶段一：vendor-first，闭源 API 快速验证，用最小成本证明价值；
2. 阶段二：引入 LLM 网关，建立统一入口与观测，管住成本与质量；
3. 阶段三：转向开源权重，把模型层变成可运营资产，摆脱单点依赖；
4. 阶段四：Agent 网关支撑多步智能体，同时按证据形态升级检索层（向量 RAG → Graph RAG）。
据多位接近行业一线的平台负责人反馈，能完整走完这四步的公司屈指可数，大多数团队卡在阶段二——因为网关是一个“看不见短期收益、但决定长期上限”的投入，在内部争取预算时天然吃亏。
小结
DoorDash 的平台复盘和 Graph RAG 的选型讨论，表面上一南一北，内核却是同一句话：模型会持续贬值和迭代，围绕模型的基础设施才会沉淀为公司资产。网关、检索层、权衡机制，这三样东西决定了 5000 个用户用起来是“玩具”还是“生产力”。2026 年，随着智能体形态进一步普及，Agent 网关与关系型检索会从“进阶选项”变成“平台标配”。还在裸接模型 API 的团队，欠的债迟早要还——不如现在就开始还。