客户在-AI-项目中真正需要的东西

客户在 AI 项目中真正需要的东西

原文：towardsdatascience.com/what-clients-really-ask-for-in-ai-projects/

在处理 AI 项目时，客户和利益相关者不希望出现意外。

他们期望的是清晰、一致的沟通和透明度。他们想要结果，但也希望作为开发者或产品经理，你能保持脚踏实地并与项目目标保持一致。同样重要的是，他们希望对整个过程有全面的了解。

在这篇博客文章中，我将分享实用的原则和技巧，以帮助 AI 项目保持正轨。这些见解来自超过 15 年的管理和部署 AI 项目的经验，并是对我博客文章“在 AI 项目中设定期望的技巧”的后续。

在处理 AI 项目时，不确定性不仅仅是一个副作用，它可能会使整个项目成功或失败。

在整个博客部分，我会包括你可以立即付诸实践的实际项目。

让我们深入探讨！

ABU（始终更新）

在销售中，有一个著名的规则叫做 ABC——Always Be Closing。 其理念很简单：每次互动都应该让客户更接近达成交易。在 AI 项目中，我们还有一个口号： ABU（始终更新）。

这条规则的意思就是它所说的：永远不要让利益相关者处于黑暗中。即使进展很小或没有进展，你也需要快速沟通。沉默会创造不确定性，而不确定性会摧毁信任。

应用 ABU 的一个简单方法是通过每周向每个利益相关者发送简短的电子邮件。保持一致性、简洁性，并关注四个关键点：

  • 本周在性能或关键里程碑方面取得的突破；

  • 与交付成果相关的问题或上周计划的变更，以及影响利益相关者期望的问题；

  • 团队或资源的更新；

  • 达成成功指标方面的当前进展；

这种节奏让每个人都保持一致，而不会因为噪音而感到压倒。关键洞察是，人们实际上并不讨厌坏消息，他们只是讨厌意外的坏消息。如果你坚持 ABU 并每周管理期望，你将建立信誉并在挑战不可避免地出现时保护项目。

将产品放在用户面前

在 AI 项目中，很容易陷入为自己而不是为实际使用你正在构建的产品/解决方案的人构建的陷阱。

太多次了，我看到了团队对那些对他们来说很重要但最终用户并不关心的功能感到兴奋。

因此，不要假设任何事情。 尽可能早地、尽可能频繁地将产品放在用户面前。真实的反馈是无法替代的。

实施这一点的实用方法是轻量级原型或有限的试点项目。即使产品远未完成，向用户展示它也有助于你测试假设并优先考虑功能。当你开始项目时，尽快承诺一个原型日期。

不要陷入技术陷阱

工程师热爱技术——这是对这个角色的热情的一部分。但在 AI 项目中，技术只是一个推动者，永远不是最终目标。仅仅因为某件事在技术上可行（或者在演示中看起来令人印象深刻），并不意味着它解决了客户或利益相关者的实际问题。

因此，指南非常简单，但很难遵循：不要从技术开始，要从需求开始. 每个功能或代码都应该追溯到明确的用户问题。

应用这一原则的一个实用方法是，在解决方案之前验证问题。花时间与客户在一起，映射他们的痛点，并问：“如果这项技术完美无缺，它对他们实际上有意义吗？”

酷炫的功能无法拯救一个没有解决问题的产品。但当你将技术锚定在真实需求上时，采用就会自然而然地发生。

工程师们通常专注于优化技术或构建酷炫的功能。但最优秀的工程师（10 倍工程师）将这种技术实力与罕见的能力相结合，即能够与利益相关者产生共鸣。

业务指标优于技术指标

容易陷入技术指标的迷雾——准确性、F1 分数、ROC-AUC、精确率、召回率。客户和利益相关者通常不关心你的模型是否比其他模型准确 0.5%，他们关心的是它是否减少了客户流失、增加了收入或节省了时间和成本。最糟糕的是，客户和利益相关者经常认为技术指标是重要的，而在商业环境中，它们很少是重要的。而且这取决于你来说服他们改变看法。

如果你的客户流失预测模型达到了 92%的准确性，但营销团队无法从其输出中设计有效的活动，那么这个指标就没有意义。另一方面，如果一个“不太准确”的模型通过可解释性帮助减少了 10%的客户流失，那么这就是成功。

应用这一原则的一个实用方法是，在项目开始时定义业务指标——问：

  • 财务或运营目标是什么？（例如：将呼叫中心处理时间减少 20%）

  • 哪些技术指标与该结果最佳相关？

  • 我们将如何与非技术利益相关者沟通结果？

有时正确的指标根本不是准确性。例如，在欺诈检测中，以最小的误报率捕捉 70%的欺诈案例可能比一个挤压出 90%但阻止数千笔合法交易的模型更有价值。

所有权和移交

一旦解决方案上线，谁将拥有它？在成功的情况下，客户是否能够始终可靠地访问它？当你的团队不再参与项目时会发生什么？

这些问题通常会被传递下去，但它们定义了你工作的长期影响。你需要从第一天开始就规划交接。这意味着记录流程、转移知识和确保客户团队可以在没有你持续参与的情况下维护和操作模型。

交付一个 ML 模型只是工作的一半——部署后的阶段通常是一个重要的阶段，但在业务和技术之间的翻译中往往被忽视。

成本和预算可见性

运行解决方案的成本是多少？你是否使用云基础设施、LLM 或其他客户必须理解的可变成本技术？

从一开始，你需要让利益相关者全面了解成本驱动因素。这意味着分解基础设施成本、许可费用，特别是与 GenAI 相关的使用费用，如令牌消耗。

一种管理这种状况的实际方法是设置清晰的成本跟踪仪表板或警报，并定期与客户审查。对于 LLM，估计在不同场景下的预期令牌使用量（平均查询与重用），以避免后续出现意外。

客户可以接受成本，但他们不会接受隐藏的或可扩展的成本。 预算的透明度允许客户为扩展解决方案进行现实规划。

规模

谈论规模...

规模是完全不同的游戏。这是 AI 解决方案可以带来最大商业价值的阶段，但也是大多数项目失败的地方。在笔记本中构建一个模型是一回事，但将其部署以处理现实世界的流量、数据和用户需求则是另一回事。

因此，要明确你将如何扩展你的解决方案。这是数据工程和 MLOps 发挥作用的地方。解决确保整个管道（数据摄取、模型训练、部署、监控）可以随着需求增长而增长，同时保持可靠和成本效益的问题。

在沟通规模时需要考虑的一些关键领域包括：

  • 软件工程实践：版本控制、CI/CD 管道、容器化和自动化测试，以确保你的解决方案可以在不中断的情况下进化。

  • MLOps 能力：自动重新训练、监控数据漂移和概念漂移，以及保持模型准确性的警报系统。

  • 基础设施选择：云与本地，水平扩展、成本控制和是否需要专用硬件。

一个在孤立状态下表现良好的 AI 解决方案/项目是不够的。 真正的价值在于解决方案可以扩展到数千用户，适应新数据，并在初始部署之后继续产生商业影响。

这里是我们在本文中看到的一些实用技巧：

  • 向所有利益相关者发送简短的每周电子邮件，内容包括突破、问题、团队更新和指标进展。

  • 承诺一个早期原型或试点，以测试最终用户的假设。

  • 首先验证问题——不要从技术开始，从用户需求开始。用户访谈是完成这一任务的好方法（如果可能的话，离开你的办公桌，加入用户，在他们一天的工作中参与其中）。

  • 事先定义业务指标，并将技术进步与之联系起来。

  • 从第一天开始规划交接：记录文档、培训客户团队，并确保所有权清晰。

  • 设置一个仪表板或警报来跟踪成本（尤其是云和基于令牌的通用人工智能（GenAI）解决方案）。

  • 以可扩展性为设计理念：构建持续集成/持续部署（CI/CD）、监控漂移、模块化管道以及可以扩展的基础设施。

你是否还有其他觉得值得分享的小贴士？请在评论区写下它，或者随时通过LinkedIn联系我！

posted @ 2026-03-27 10:41  布客飞龙IV  阅读(1)  评论(0)    收藏  举报