如何将你的 AI 想法转化为可扩展的产品：技术指南-平芜编程栈

原文：towardsdatascience.com/how-to-turn-your-ai-idea-into-a-scalable-product-a-technical-guide-aec143668a8b

如何将你的 AI 想法转化为可扩展的产品：技术指南

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/f0c94e6552eb096cb4c730923b91555e.png

图片由Abhijeet Wankhade在Unsplash提供

你有没有想过一个 AI 驱动的应用程序或数据科学产品的伟大想法？

我知道我有。我在 iPhone 上有一个叫“想法”的笔记，里面有 50 多个想法。

但你如何将你的想法转化为一个具有真实用户群体的可扩展产品？

当然，你可能知道如何开发一个 ML 模型或微调一个 LLM。但如果一个模型如果只停留在 Jupyter 笔记本中或运行在localhost上，对任何人都没有用。

本指南将向你展示如何从想法到生产产品的转变。

如果你是一个想要创业的人或初创公司员工，这将为你提供离开localhost、推出你的产品并开始获取用户所需的知识。

正如你所看到的，构建一个 AI 驱动的产品并没有单一的方法——有许多可能的选择。我的目标不是提倡特定的策略或深入代码，而是从技术架构的角度提供一个广泛的概述。这样，当你阅读展示特定部署策略的博客时，你将拥有知识和信心来批判性地评估该博客，并决定它是否是你的应用的最佳选择。

模型：使用自己的，还是调用别人的？

任何数据/AI 产品的核心是模型。

当我说“模型”时，你可能立刻会想到像 GPT-3.5 这样的大型语言模型或像 GPT-4o 这样的多模态模型。但数据科学远不止于 GenAI，还有许多不同类型的模型。

例如，一个 AI“模型”可以是：

一种像 GPT-3.5 这样的大型语言模型（LLM），用于生成文本
一种机器学习（ML）分类器，根据训练数据中观察到的模式生成数值预测
一种基于历史趋势逐步预测的机器学习时间序列模型

…或者别的什么。你可能还有一个非 AI 模型，尽管如此，它仍然进行了一些聪明的数据科学：

一种优化模型（例如，线性规划模型），为一系列输入生成最佳分组/顺序/解决方案
一种基于规则的/确定性模型，遵循复杂的预定义规则进行分类或决策

我的观点是：有很多可能性！

但无论模型类型如何，构建和部署模型都有三个高级策略：

在本地构建自己的模型并部署它
通过 API 调用他人的现有模型（例如，GPT-3.5）
前两种方法的混合

让我们讨论这些选项。

选项 1：在本地开发自己的模型

如果你需要一个针对你特定数据或任务的定制模型，你可能在你的电脑上（或在 Google Colab 或 Vertex AI 等平台上的托管环境/笔记本中）本地开发自己的模型。

例如，你可能：

训练一个用于特定任务，如手机价格预测的 LightGBM 回归器
微调预训练的 RoBERTa 分类器，
微调开源的 LLM，如 Llama-3，或者
构建梦幻足球优化算法

所有这些共同之处在于，在训练/微调你的自定义模型之后，你最终会得到一个包含你的模型（例如，model.txt）或参数的文件。

为了让你的自定义模型有用，你现在必须定期运行该模型并生成新的预测/输出。

有几种方法可以实现这一点。

将模型作为独立的“微服务”部署

一种策略是在网络上使用 Python 框架（如 FastAPI、Flask 或 Django Rest Framework）将你的模型作为其自己的微服务部署。

例如，你可以在 FastAPI 应用程序中包装你的模型，并在 AWS、Render 或 Heroku 等服务上部署它。其他人可以通过向应用程序端点发出 API 调用来与你的模型交互。

如果用户想要直接与你的部署应用程序交互（例如，从他们的终端/笔记本发送 cURL 请求到你的应用程序），设置将如下所示：

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/616a7bd710cc95dde276fcc5d54a106f.png

图片由作者提供

然而，更有可能的是，你希望有一个友好的用户界面，使用户能够间接地与你的模型/应用程序交互（通过另一个具有良好视觉界面的应用程序/网站）：

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/6d174e593b80dc31735c34e068566fe5.png

图片由作者提供

如果你想要一个更详细的关于此策略实施的示例，我强烈推荐以下教程，它展示了如何使用 FastAPI、Heroku 和 Docker 部署基本的 scikit-learn 模型。

使用 Sklearn、FastAPI 和 Docker 提供机器学习模型

用户可以通过向/predict路径发送 GET 请求来让模型生成预测，之后模型会返回预测结果。

将模型直接集成到你的单体应用程序中

对于小型模型，将独立应用程序部署以托管你的模型有时可能是过度设计。一种替代策略是将模型直接集成到你的主要应用程序中（一个“monolith-first”架构）。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/50d1ae962576c3bf5ecbe13d85c6ecf4.png

图片由作者提供

(只需小心你的模型不要太庞大：它可能会让你的整个应用程序停滞/崩溃。)

这是一个将机器学习模型直接集成到 Django 应用程序中的好例子：

使用 Django 创建基于机器学习的网络应用程序

在本地/离线运行模型，并将输出保存到数据库中

有时在网络上“生产化”一个模型可能是过度设计，而定期在本地运行你的模型并将其输出发送到数据库是完全足够的。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/cbc387f418a4b61441fcac7cca46d50f.png

图片由作者提供

这可能听起来像是一种低技术含量的策略，但不要将低技术含量误认为是低价值。

这是独立创业者 Pieter Levels 在他的初创公司 PhotoAI 早期所做的事情。他的用户通过 TypeForm 将照片上传到他的数据库，他下载了这些照片并手动通过他的本地模型进行处理，然后将输出发送回用户。

这听起来是不是很聪明？

技术上的麻烦很少（非常适合验证想法），用户仍然可以与你的模型进行交互。只是这种交互是通过存储模型输出的数据库间接进行的，而不是通过模型的 API 端点直接进行。

将模型在线作为一个无服务器函数运行（例如，通过 AWS Lambda 或 GitHub Actions）

这个选项是介于前面策略之间的一种折中方案。

实质上，这涉及到创建一个score.py文件（或等效文件），使用你的model.txt文件生成预测，并将两者部署到 GitHub 或 AWS Lambda 等平台，并设置 cron 作业以定期运行score.py脚本。这里的模型是“在线”的，意味着你不需要在本地运行它（它是在远程服务器上定期运行的），但你并不是将模型作为应用程序/网络服务部署，它也不通过 API 提供访问。我之前的文章详细介绍了如何进行这一操作：

使用 GitHub Actions 部署 LightGBM 机器学习模型

这是不是最佳选择？说实话，这取决于你的应用程序。我个人非常推崇 GitHub Actions 策略，因为它是一种快速且低维护的部署模型的方法，但不同的应用程序会有不同的需求。只需记住：

不要将低技术含量误认为是低价值。

选项 2：调用他人的模型

并非所有 AI 产品都需要定制模型。

通常，使用一些巧妙的提示向通用的预训练模型（如 GPT-4o 或 Claude 3.5 Sonnet）发送请求就足够了：

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/001f87621742902dc0fc519553f26b8c.png

作者图片

使用公共模型的主要优势是您不需要自己托管或监控模型。您只需在主应用程序中向模型发出 API 调用，并通过提供商的仪表板（例如，OpenAI 的使用仪表板）监控您的应用程序使用情况。

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/ca74387ef414469161d7decbf1fdf38c.png

一个示例使用仪表板。图片来自 OpenAI

这个设置非常适合您只想关注应用程序本身，而不是构建超级定制的模型或担心它们的部署。这是使用 GPT-3.5、Django 和 HTMX 实现此方法的绝佳示例。

选项 3：混合选项

远程微调

微调通常在本地（或托管笔记本中）进行，让您直接访问微调后的模型文件。

然而，对于某些平台/模型，在微调后，您将无法访问原始模型文件。一个例子是 OpenAI。

这种方法比选项 1 和 2 少见，但仍然是一个选择。如果您确实想探索在 OpenAI 等平台上微调模型，您只需像调用通用的托管 LLM（如 GPT-3.5 或 4）一样通过 API 调用这些微调模型。

将链部署为独立应用程序

如果您想使用像 GPTs 这样的预训练模型构建复杂的流程/链，那么将链部署为独立应用程序（而不是直接从您的应用程序中调用模型）可能是有意义的。

这个例子很好地说明了这一点。开发者从复杂的 LangChain 工作流程中调用 OpenAI 模型，然后通过 FastAPI 将链部署为独立应用程序。

哪个选项适合我？

说实话，这取决于。我并不是随便说说。我说这个是因为，嗯，这取决于！

如果您想尽快让某事启动并部署您的应用程序，通过 API 调用他人的模型（或者使用 FastAPI 将您自己的模型作为 API 部署）是一个非常好的选择。这是将您的应用程序快速推向世界、让全世界看到的最快方式，并且这是数据科学家们不愿意与前端框架和复杂的部署管道纠缠在一起时常用的方法。这是我个人开始许多新项目的方法——使用像 FastAPI 或 Django 这样的极简框架让某事启动运行，然后一旦应用程序的基本框架工作起来，再考虑前端和应用逻辑。

最后一条建议：不要过度设计。机器学习项目的真正目标不是“部署一个模型”，而是要创造一些有用的东西，为此，它必须被使用。换句话说，您必须获得用户！这是我在我的 SQL 教程网站 theSQLgym 上采取的方法——我先让基本项目启动运行，然后根据真实用户的反馈，在应用程序运行时迭代改进应用程序。