本文想要分享当引入生成式AI创建新产品或升级原有产品的时候，项目流程会有哪些变化。
当公司想要引入生成式AI创建新产品或升级原有产品的时候，整个项目周期是怎么样的呢？这其中有哪些地方和原来没有相比没有变化，又有哪些地方因为引入生成式AI而需要变化呢？
第一步依旧需要决定我们要做什么，就像在之前的文章AI时代下，产品经理的“变”与“不变”中分享的观点，本质上来说，我们就是要让机器找一个函数，这不是一个技术的问题，而是你要做什么样的应用，满足什么样的需求，解决了一个什么问题。
当我们找到这个函数之后，我们需要思考并明确这个项目的目标，以及什么范围包含在这个项目中，什么范围不包含在这个项目中，为什么这个范围可以帮助我们达成这个项目目标。
在这一步中，作为产品经理，需要过滤需求里的场景是否适合引入AI，如果不适合的话则需要把相应的场景过滤以避免投入产出比产生问题。
例如，当我们想要做一个企业内部的问答产品，以提高前台部门应对客户问题的质量及效率。那我们需要了解前台有哪些部门，这些部门通常会应对客户哪些问题（例如新产品介绍，产品方案问题，产品操作疑问等等），他们之前是如何应对的，客户不满意的点在哪里等等。最终定义出这个项目的合适的范围。
这一步就进入了产品细节设计和研发流程，大家都会非常熟悉。但是笔者认为，在这个过程中，引入AI后的产品和普通的数字化产品有三个最大的不同
1）引入AI的产品搭建一个初始的版本会相当快，更多的时间是在调整引入模型和我们期待它达到我们要求的GAP。
2）需要更加详细的定义验收标准，通常这个验收标准会包括
3）需要和测试一起定义测试集，确保我们选择的测试集是可以匹配上我们的验收标准，通常包括
例如，假设在第一步我们的范围是前台的项目负责人可以使用这个助手快速的解决客户在操作产品过程中的疑问。
其实我们会发现，当我们利用LLM+RAG就可以快速的构建这个产品，可能一周之后产品的雏形已经出来了。而针对这样的产品和原本的功能产品不同，产品经理需要花比较多的时间和相关的专家去整理这个私有知识库，并确定这些知识的分类，定义及示例。从而帮助后续和开发测试沟通的过程中更快速的互相理解。
其次，产品经理需要定义验收维度，比如在这个例子中，我们可能会定义正确性、相关性、合规性等验收维度。并且需要定义有90%的Good Case才能代表验收通过。
最后，我们需要从知识的分类、定义维度出发去建立测试集的标准，并明确测试集的覆盖和数量的要求。这些步骤都是在一个引入AI产品后必要的步骤，这可以帮助我们在这个过程中和开发测试人员快速迭代产品最终完成这个产品。
这一步在传统数字化产品可能会非常简单，大致就是上线前让相关的Stakeholder做一下简单的验收。但是在引入AI的项目中，这一步至关重要。
为什么这么说？我们在数据漂移（Data Drift）：AI+产品的隐形风险这篇文章中有提到，AI+产品有个很典型的隐形分享，就是“数据漂移”。这种情况在自造数据比重高的新项目中特别容易发生。
所以在这个步骤中，我们通常会要求所有的内部团队人员都参与到这个内部评估中。
例如，假设在第一步我们的范围是前台的项目负责人可以使用这个助手快速的解决客户在操作产品过程中的疑问。那么我们会让所有的内部团队成员每人写指定个数的操作疑问，从而去测试产品给出正确反馈的比例是否依旧符合我们预期。如果不符合我们的预期，则需要重新回到第二步。
这个步骤可以很好的规避上线前由于自造数据权重较高而产生的风险。很多时候，这个步骤产生出来的Bad Case是一个很好的分析步骤，帮助我们重新调整步骤二中验收标准定义和数据集定义。
经过充分的内部评估，我们会部署产品上线，并持续监控。
在传统数字化产品中，我们可能会监控这个功能上线有没有人使用，使用率如何，使用反馈如何，使用过程中产生的Bug需要及时修复。而在引入AI的项目中，除了这些常规监控，我们更需要监控真实用户在使用这个产品的过程中是否依旧存在数据漂移。根据我们的项目经验，大多数时候，真实用户的数据和自造数据，无论在问法，复杂度等都有可能发生变化。
我们需要定期监控用户的反馈，并回到“内部评估”做进一步的分析，是不是针对某一类问题表现的不够好，甚至需要回到“迭代产品”重新调整某些定义。
总结来说，构建AI+产品的项目是一个高度实验性的过程，这意味着这类项目需要我们快速的反复尝试，发现并修复错误。而在整个项目周期中这些“变化”的步骤，都在为这个实验更好的服务，帮助我们可以更快速，更准确的做出我们想要的AI+产品。
本文由 @AI 实践干货 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。