如何创建人工智能：从 API 原型到自建模型

如何创建人工智能取决于你想构建什么。面向客户的聊天机器人、文档分类器，以及从零开始训练的语言模型是不同的项目。对大多数产品团队而言，可行的第一步是创建一个通过 API 使用现有模型的应用程序，测试一项真实任务，并控制数据、成本和质量。只有当你拥有足以证明这一选择合理的数据、经验和计算能力时，才适合从初始权重开始训练模型。

快速回答：定义一项可衡量的任务，收集 30 到 100 个具有代表性的示例，使用现有模型构建原型，评估错误，然后再决定是否需要文档检索、微调或自行训练。“创建 AI”并不要求第一个版本就训练一个新模型。

先选择项目类型，再选择技术

即使基础模型来自供应商，聊天界面也可以是“你的 AI”。产品价值在于它解决的任务、用户体验、访问规则、与数据的集成以及持续评估。在投入基础设施之前，Google 的机器学习实践入门是了解训练、验证和指标的良好起点。

步骤 1：描述一项小而可验证的任务

不要从“一个无所不能的 AI”开始。选择诸如“将支持邮件分为五个类别”“总结工单并列出后续步骤”或“回答有关帮助知识库的问题”这样的任务。对于每项任务，定义输入、输出、用户、限制条件和成功标准。

创建一组初始的真实示例，避免包含不必要的个人数据。标注预期结果和困难案例：混合语言、不完整的请求、知识库中不存在的内容、恶意指令以及相互矛盾的文档。将开发示例和测试示例分开。如果你使用所有示例来调整提示词，之后就没有独立样本来判断系统是否有所改进。

选择与任务相匹配的指标。分类可以使用各类别的准确率和人工复核率。支持回复可能需要衡量事实正确性、来源引用、响应时间以及每个已解决案例的成本。单凭 token 数并不能衡量实用性。

步骤 2：使用模型 API 构建原型

API 减少了托管 GPU 和提供模型服务的初始工作。它并不会消除产品决策：你的团队仍需要保护密钥、格式化输入、验证输出并处理故障。Flatkey 的兼容接口记录了如何通过 OpenAI SDK 使用 https://router.flatkey.ai/v1 调用 chat completions。请使用 Flatkey 签发的密钥以及目录中的当前模型别名；不要将此密钥与由 OpenAI 直接签发的凭据混淆。

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://router.flatkey.ai/v1",
    api_key=os.environ["FLATKEY_API_KEY"],
)

answer = client.chat.completions.create(
    model=os.environ["FLATKEY_MODEL"],
    messages=[
        {"role": "system", "content": "Classifique a mensagem em: compra, suporte, cobrança ou outro. Responda apenas com uma categoria."},
        {"role": "user", "content": "Não consigo encontrar a fatura do mês passado."},
    ],
)
print(answer.choices[0].message.content)

这段代码是集成测试，不是可直接投入使用的应用程序。 请根据允许列表验证返回的类别，只记录必要的数据，设置超时，并测试 400、 401、429 和 5xx 错误。将密钥保存在 服务器或密钥管理器中；切勿将其发布在公开的 JavaScript 中或移动应用内。

如果选择直接调用供应商，请阅读其当前的端点参考文档。 被称为“兼容”的端点可能覆盖不同的功能范围：请检查模型、工具格式、 流式传输、限制和计费。对于首次测试，小规模调用比一次性迁移全部流量 更有价值。

第 3 步：在训练前改进结果

当原型失败时，请对原因进行分类。请求是否存在 歧义？是否缺少数据？模型是否接收了过多上下文？回答 是否未遵循格式？这些原因需要不同的解决方案。

• 提示词和格式：要求简短且可验证的输出， 提供输入和输出示例，并检查结果的 模式。
• 外部数据：对于会变化的政策、文档和 目录，请从您的系统中获取当前信息，并仅发送 相关片段。同时评估访问控制；拥有良好权限控制不足的搜索可能会暴露数据。
• 应用流程：将复杂任务拆分为 可验证的步骤。当业务规则需要确定性时，请在模型之外使用这些规则。
• 模型：在同一套测试中比较多个模型。 更大的模型并不一定更适合简短 分类。

只有在测试过这些选项并收集到足够的标注示例之后，才考虑 微调。Hugging Face 关于微调的文档说明，微调是在某项任务或领域的数据上继续训练 预训练模型； 这不同于从零开始创建所有权重。请检查模型许可证、 数据来源、训练成本和评估流程。

第 4 步：决定是否真的需要自建模型

从零开始训练模型需要收集和清洗数据、 分词、架构、GPU、存储、实验、 检查点、安全性，以及能够评估回归问题的团队。即使 训练完成后，您仍需以可接受的延迟和 可用性来部署模型。对于许多产品而言，在尚未证明 API 或 开放模型无法满足需求之前，这种成本并不合理。

如果需求是控制权重或在您自己的 基础设施上运行，请将已训练的开放模型与您的 API 原型进行比较。 衡量质量、吞吐量、GPU 内存、每项任务的成本和 运维工作量。Flatkey 的 GPU Compute 页面可作为考察基础设施的起点，但在做出决定时应确认 可用性、价格和配置。不要在实际负载存在峰值和空闲时段时， 按照 GPU 始终满载来计算节省的成本。

混合架构也是可行的：将可预测的任务放在您控制下的 开放模型中，将困难案例交给外部模型 API。为此需要清晰的 路由和可观测性，而不仅仅是配置两个 端点。

第 5 步：让应用程序为实际使用做好准备

在向用户开放之前，请进行一项简单检查：

1. 数据与访问：哪些数据会进入提示词？谁 可以查阅每份文档？哪些内容会写入日志？
2. 质量：分别评估常见、罕见 和对抗性案例；记录可接受的错误率，以及何时应升级 给人工处理。
3. 成本：估算输入和输出 token、 每项任务的调用次数、重复尝试次数以及模型的当前价格。跟踪 每个有效结果的成本。
4. 运营：为 429 定义超时、限额、退避策略、 回退方案，以及一种在不影响产品其余部分的情况下关闭该功能的方法。
5. 变更：更换模型、 提示词、文档、SDK 或提供商时，重新进行测试。对生成 每项结果的配置进行版本控制。

HTTP 200 响应并不能证明产品正确完成了任务。 对于分类器，请与预期标签进行比较。对于基于文档的回答， 请核实引用是否确实支持该 说法。对于生成的内容，请在影响最大的环节安排人工 审核。

创建人工智能需要多少成本？

不存在统一的价格。基于 API 的原型可以从低 流量开始，但成本会随着调用次数、token、价格更高的模型、 工具和重试而增长。带有检索功能的系统还会增加搜索、 存储和文档维护成本。微调和自托管 会增加 GPU 和运营成本。从零开始训练会进一步扩大这些要求。

使用五个变量创建一张电子表格：活跃用户数、每位 用户的任务数、每项任务的调用次数、每次调用的 token 数和重复率。 将其乘以所选模型的当前价格，并在 存在时加上存储、搜索、GPU 和运营工作成本。使用相同的测试集和相同的 任务完成定义来比较不同方案。Flatkey 定价页面是 了解其路由费率的来源；如果使用其他提供商，请查阅其 页面。

常见问题

创建 AI 必须会 编程吗？

要制作想法原型，可视化工具可能会有所帮助。要将 AI 集成到包含用户数据的产品中，则需要有人负责 身份验证、密钥、验证、成本和错误处理。会编程或与技术团队合作， 能让这些控制措施得到验证。

创建 AI 和训练 AI 有什么 区别？

创建 AI 应用是围绕某个 模型构建一个有用的流程。训练是利用数据和 计算资源修改模型参数。产品无需从零训练模型，也可以是创新且有价值的。

我可以只使用 API 创建 AI 吗？

可以，适用于许多任务。API 提供模型能力，但 您的应用仍需负责界面、数据、规则、 评估和安全性。如果需要最新文档，请添加 检索步骤，而不要假设模型了解您的内部 信息。

下一步：选择一项任务，准备好测试 示例并发起一次小规模调用。只有在能够衡量质量和成本后， 才扩大范围。如果同一应用需要通过一次集成测试 多个模型，请评估Flatkey 的 chat completions 路由，并参考您账户中当前可用的模型和限额。