AI 平台自建还是采购：先看差异化能力

去年底帮一个团队做架构评审，发现他们的 AI 中台已经是一个庞然大物：模型网关、Prompt 管理、向量检索、评测系统、成本控制面板，全是自建。负责维护的后端工程师占了团队 40% 的工时，但业务负责人说不清这些自研模块里哪些真正影响了产品质量。

这个场景不罕见。2025 年以来，越来越多团队在业务中接入了大模型能力，从最初的 API 调用，逐步膨胀出一套完整的「AI 平台」。问题在于，这套平台里有多少能力是真正需要自建的？

我的经验是：先区分差异化能力和通用能力，再谈自建还是采购。这个顺序反了，决策几乎一定会出错。

差异化能力决定边界

不是所有 AI 平台能力都值得自建。模型推理 API、向量数据库、基础 Prompt 模板、Token 计费、用户认证——这些是通用能力，市场上有成熟的商业产品和开源方案。替换掉它们，你的产品质量不会发生任何变化。

真正值得投入工程资源去自建的，是那些替换之后会直接影响产品质量或业务壁垒的能力：

判断标准很简单：如果一项能力被供应商替换后，你的业务逻辑完全不受影响，那它不值得自建。

arXiv 上 2026 年 2 月发表的「Buy versus Build an LLM: A Decision Framework for Governments」提出了一个分层模型：对于多业务线组织，最优策略是购买通用的智能层（commodity intelligence layer），自建专有数据和路由系统 ¹。这个分层思路在企业场景同样适用：

工程投入的杠杆在 L3。这一层是连接器，它的架构质量决定了你能不能灵活切换底层模型和上层业务。L3 做不好，L4 的迭代速度会被拖垮，L2 的替换成本会高到让你放弃切换。

成本结构差异比你想的大

很多团队做 build vs buy 决策时只看「表面成本」——API 调用费 vs 开发人力。真实的成本结构远比这复杂。

以 3 年 TCO 为周期，一个中等规模 AI 应用（日均 10 万次调用）的成本结构大致如下：

关键的成本交叉点在于调用量。根据行业数据，当年度 Agent 对话量超过 100 万次时，自建方案的单位成本优势才能抵消初期投入 ¹。低于这个阈值，采购方案在成本上几乎没有悬念地更优。

隐性成本才是真正的坑

达到成本交叉点之后，真正的挑战才开始。多数团队只算表面数字，结果要么是自建变成了无底洞，要么是采购之后发现处处受限。

自建的隐性成本主要集中在三个方面：

采购方案的隐性成本则是另一个方向：

自建的运维负担是持续的，采购的集成负担是累积的。两者都不便宜，但性质不同——自建的负担你可以通过投入人力来缓解，采购的负担你只能通过架构设计来预防。

案例一：API 直调导致成本失控

某内容团队在 2025 年初启动了一个文章摘要和改写功能。最初直接调用 OpenAI API，工程师在业务代码里写了几十处 openai.chat.completions.create 调用。

场景：产品上线后效果不错，调用量迅速增长。

翻车：三个月后，月均调用量达到 40 万次，每月 API 费用接近 3 万元。业务团队抱怨成本失控，但没人能说清哪些调用是必要的、哪些可以缓存。更麻烦的是，业务逻辑和 AI 调用完全混在一起——改一个 Prompt 需要改代码、跑测试、重新部署。模型选择也是硬编码，无法根据任务复杂度路由到更便宜的模型。

修复：引入模型路由网关层，将业务代码和 AI 调用解耦。通过缓存命中率决定路由策略，同时对每次调用做成本追踪。

# 坏做法：业务代码直接调用模型，难以替换和监控
class ArticleService:
    def summarize(self, text: str) -> str:
        # 模型选择、重试逻辑、成本追踪全部内联
        response = openai.chat.completions.create(
            model="gpt-4",
            messages=[{"role": "user", "content": f"Summarize: {text}"}]
        )
        return response.choices[0].message.content

# 好做法：通过网关层统一路由，支持缓存、降级和成本追踪
class ModelGateway:
    """模型网关：统一管理路由策略、缓存和成本追踪。"""
    def __init__(self, cache, router):
        self.cache = cache       # Redis 缓存，按内容 hash 存储
        self.router = router     # 路由策略：根据优先级和缓存状态选模型
 
    async def complete(self, prompt: str, priority: str = "normal") -> str:
        cache_key = hashlib.md5(prompt.encode()).hexdigest()
        # 缓存命中直接返回，避免重复调用
        if cached := await self.cache.get(cache_key):
            return cached
 
        model = self.router.select(priority, cache_hit=False)
        result = await self._call_model(model, prompt)
        await self.cache.set(cache_key, result, ttl=3600)
        return result
 
 
class SmartRouter:
    def select(self, priority: str, cache_hit: bool = False) -> str:
        # 缓存未命中且高优先级 → 快速模型
        if not cache_hit and priority == "high":
            return "gpt-4o-mini"
        # 默认用性价比更高的模型
        return "gpt-4o-mini"

这个改造花了一周。上线后，月均 API 费用从 3 万降到 1.1 万。更关键的是，Prompt 修改不再需要重新部署——改配置文件即可生效。

教训：模型网关不是差异化能力，但它是一个必要的解耦层。没有这一层，你的业务代码会被 AI 调用绑架，后续任何优化都要从底层改起。

案例二：自建评测系统投入产出失衡

另一支团队决定自建一套完整的评测体系。

场景：团队在做客服问答机器人，需要评估模型回答的质量。技术负责人认为评测是核心能力，决定从零搭建。

翻车：花了三个月开发了一套包含多个评测指标（忠实度、相关性、流畅度、安全性）和 LLM-as-judge 的评测系统。但实际使用中，业务团队只关心两个指标：回答是否包含幻觉、格式是否符合要求。三个月里，底层模型升级了两次，每次升级后评测标准和测试用例都要跟着调整。半年下来，投入了 40 万开发成本，评测系统的使用率不到 20%。

修复：切换到 LangSmith 的评测功能，用内置指标覆盖基础需求，把工程资源集中在构建业务专属的「幻觉检测数据集」上。

# 坏做法：从零构建复杂评测系统，业务真正需要的指标很少
class CustomEvalSystem:
    """自建评测：指标过多，维护成本高，业务实际只用两个。"""
    def __init__(self):
        # 初始化 6 个评测维度，每个都要维护评分模型
        self.metrics = [
            FaithfulnessScorer(),  # 自建
            RelevancyScorer(),     # 自建
            FluencyScorer(),       # 自建
            SafetyScorer(),        # 自建
            CoherenceScorer(),     # 自建
            CompletenessScorer(),  # 自建
        ]
 
    def evaluate(self, input_text, output_text, context):
        # 每次评测要调用 6 个评分模型，耗时且昂贵
        return {m.name: m.score(input_text, output_text, context)
                for m in self.metrics}

# 好做法：用成熟平台覆盖通用指标，自建只聚焦差异化数据
from langsmith import Client
 
client = Client()
 
# 平台内置指标覆盖通用评测需求
dataset = client.create_dataset("hallucination-check")
# 团队精力集中在构建业务专属的幻觉检测数据集
# 这才是真正的差异化资产——外部平台无法提供你的业务数据
 
example = {
    "input": "退货政策是什么？",
    "output": "30 天内可退",
    "expected": "7 天内无理由退货，15 天内有理由退货"
}
client.create_example(**example, dataset_id=dataset.id)

教训：评测体系的差异化不在于评测框架本身，而在于评测数据。框架可以用现成的，但「什么样的回答在你的业务场景下算好回答」——这个判断标准必须自己定义。

决策流程

遇到具体场景时，我按这个流程走一遍：

决策树的关键节点是前两个判断：「AI 能力是否构成核心竞争力」和「是否涉及专有数据」。两个都是肯定的，自建才有充分的理由。任何一个是否定的，采购或混合方案的性价比更高。

2025 年 Omdia 的一项调查显示，95% 的受访专业人士认为定制开发提供更好的控制力，同时 91% 承认现成方案在快速部署上有明显优势 [^3]。这两个数据看似矛盾，实际上反映了一个现实：大多数团队在不确定自己需不需要自建的时候，答案通常是「不需要」。

混合策略的工程实践

多数成熟团队不会做非此即彼的选择。一个更现实的路径是按层混合：

原则是：通用能力外购，专有数据和流程自建。 对于一人公司或小团队，策略更简单：模型推理外购（不要自己管 GPU），向量数据库外购（不要自己运维 Milvus），评测基础设施外购（不要自己搭 LangSmith）。把精力放在检索策略、工作流编排和评测标准上——这些是你的差异化能力。

# 坏做法：一步到位全部自建，半年还没上线
class AIPlatform:
    """试图自建所有组件，上线周期被拉到 6 个月以上。"""
    def __init__(self):
        self.gpu_cluster = self._setup_gpu_cluster()     # 2 周
        self.model_server = self._deploy_model_server()   # 3 周
        self.vector_db = self._setup_vector_db()          # 1 周
        self.eval_system = self._build_eval_system()      # 4 周
        self.monitoring = self._build_monitoring()        # 2 周
        # 还没开始写业务逻辑，已经过了 3 个月

# 好做法：渐进演进，API 先行，逐步内化
# Phase 1: 直接用 API 验证业务价值（1-2 周上线）
from openai import OpenAI
client = OpenAI()
 
# Phase 2: 效果验证后，引入开源组件降低成本
# 把高频简单任务迁移到本地推理（如 Ollama + Llama 3）
 
# Phase 3: 差异化能力成熟后，考虑自部署关键模型
# 只对核心场景的模型做自部署，非核心继续用 API

渐进演进的核心是：每一步都能独立交付价值，不需要等到所有组件就绪才能上线。先采购快速验证，再逐步内化差异化能力。这比「先建好平台再做业务」的成功率高得多——Aisera 的报告显示，95% 的自建 AI 项目会失败 ³。

检查清单

阶段一：评估启动前

• 已列出团队所有 AI 相关能力，逐项标注「通用」或「差异化」
• 已评估数据敏感度：是否涉及用户隐私、行业合规或数据出境限制
• 已计算预期调用量，确认是否达到 TCO 交叉点（年 100 万次调用）
• 已明确团队规模和工程能力：是否有专职 ML 工程师或平台工程师
• 已评估自建方案的运维投入：模型升级、评测维护、安全补丁由谁负责
• 已考虑人员流动风险：关键知识是否有文档化，是否过度依赖个别人
• 已评估模型替换成本：如果当前供应商涨价或下线功能，切换需要多久
• 已制定退出策略：采购方案的合同是否包含数据导出和迁移条款

阶段二：方案决策

• 已按 L1-L4 分层评估，每层独立决定自建或采购
• 已从最成熟的方案开始验证（API → 开源 → 自部署），不是一步到位
• 采购方案已验证关键集成能力：数据接入、权限系统、审计日志、私有化部署
• 自建方案已采用模型无关设计，通过适配器模式隔离供应商 API
• 已设定成本红线和切换触发条件（如月度 API 费用超过阈值即启动自部署评估）

阶段三：持续运营

• 已建立 Token 消耗和成本监控，月度成本对团队透明
• 已建立 Prompt 管理和版本控制机制，修改不需要重新部署
• 评测体系在有效运转，评测数据集随业务变化持续更新
• 每季度评估供应商依赖程度，确认替换可行性和预估成本

参考资料