创造真正商业价值的生成式 AI 需要付出真正的努力，但这绝对值得。
生成式 AI (Generative AI) 已经无处不在。各行各业的组织正迫切要求他们的团队加入这场风潮 — 有 77% 的商业领导 担心他们已经错过了利用生成式 AI 的机遇。
数据团队正在努力应对这一挑战。但是，打造一个真正能促进商业增长的生成式 AI 模型并非易事。
长期来看，仅依靠快速接入 OpenAI API 是远远不够的。我们谈论的是生成式 AI，但你的竞争优势在哪里？为什么用户会选择你而不是 ChatGPT？
这种照本宣科接入 AI 的做法看似是进步，但如果你还没有开始思考如何将大语言模型 (LLM) 与你独有的数据和商业环境相结合，以实现真正的差异化价值，那你就已经落后了。
这不是夸张。就在这周，我就和多位数据领域的领导者讨论了这个问题。他们都清楚，这是一场竞赛。在终点，将会有赢家和输家，就像 Blockbuster 和 Netflix 的故事。
如果你感到比赛已经开始，但你的团队还在起跑线上犹豫不决，困惑于“泡沫”和“炒作”，这里有 5 个残酷的真相，帮你认清现实。
残酷真相 #1：你的生成式 AI 功能使用率很低，变现缓慢
“Barr，既然生成式 AI 这么关键，为什么我们当前推出的功能却没什么人用呢？”
这里面有几个原因。首先，你们的 AI 项目并不是为了解决用户的具体问题而设计的。对于许多数据团队来说，这只不过是因为你们正处于激烈竞争中，希望在初期探索阶段收集些数据和积累一些经验。但不久的将来，当你的产品能用生成式 AI 来去帮助用户解决真实的问题时 —— 相比于你们的专案小组（tiger team）头脑风暴如何将生成式 AI 应用到具体场景，你们会获得更高的用户接受度。
由于还在初期阶段，目前接入的生成式 AI 功能就像是“ChatGPT 的另一个版本”。
以一个例子来说明。想象一下你可能每天都在用的一个提高工作效率的应用，它用来分享组织知识。这样的应用可能会提供一些功能，比如执行“总结这部分内容”，“扩写这些内容”或“改变写作风格”等命令来处理非结构化的文本。每个命令就消耗一个 AI 积分。
没错，这些功能确实有用，但并不具备特色。
团队可能会决定购买一些 AI 使用机会，或者他们可能会简单地切换到另一个标签使用 ChatGPT。我不想完全忽略不使用 ChatGPT 从而避免泄露专有数据的好处，但这种做法在愿景和解决方案的规模上，与全国各地的财报电话会议上所描述的相比，显得较为有限。
所以，你需要考虑的是：你的生成式 AI 有哪些独特之处和附加价值？我来给你一点提示：高质量的专有数据。
这就是 RAG 模型（或有时是微调模型）对于生成式 AI 计划至关重要的原因。它让大语言模型（LLM）能够接触到企业的专有数据。（我将在后面解释这个原因。）
残酷真相 #2：你不敢深入集成生成式 AI，担心可能产生的风险
确实，生成式 AI（Generative AI）的潜力和复杂性让人望而却步。
你当然可以将 AI 模型更加深入地融入到组织的运作中，但这样做似乎充满了风险。让我们坦白说，ChatGPT 有时会给出不切实际的回答，其结果很难预料。它存在一个知识更新的限制，可能导致用户接收到过时的信息。更不用说，在处理数据上的失误和无意中向消费者提供错误信息可能带来的法律问题了。
你的数据处理失误可能会带来严重后果。因此，了解你提供给生成式 AI 的数据，并确保这些数据的准确性是至关重要的。
在我们向数据领导者发出的一项匿名调查中，询问他们离实现生成式 AI 应用还有多远时，有人回答说：“我认为并非我们的基础设施在阻碍我们。我们在这方面非常小心——随着技术快速变化和一个失误可能造成的巨大声誉损害，我们正在观望，等待这波热潮稍微退去。”
这是我在与许多数据领导者交流时经常听到的观点。如果数据团队突然暴露了面向客户的敏感数据，他们就必须承担责任。数据治理是一个重要的考虑因素，达到这一标准并非易事。
这些都是真实存在的风险，需要找到解决办法。但只是站在一旁观望，并不会解决问题。同样真实的风险是，如果你不采取行动，可能会看着自己的业务被那些率先解决这些问题的团队所颠覆。
将大语言模型（LLM）通过微调和 RAG 方法结合到你自己的数据中，是解决这个难题的关键一环，但这并非易事……
残酷真相 #3：做好 RAG 和微调其实并不容易
我认为，RAG（检索增强生成）和微调是未来企业级生成式 AI 的核心技术。虽然从大体上来看，RAG 在多数情况下是一个较为简单的方法，但开发 RAG 应用程序仍具有一定的复杂性。
RAG 看似是个为你的大语言模型量身定制的理想选择。然而，RAG 的开发过程涉及一定的学习曲线，即使是最优秀的数据工程师也需要花时间掌握。他们需要学习prompt engineering、向量数据库与嵌入向量、数据建模、数据协调以及数据管道等技术，所有这些都是为了更好地运用 RAG。由于 RAG 是一种新技术（2020 年由 Meta AI 提出），很多公司还没有足够的经验来形成最佳实践。
以下是对 RAG 应用架构的一个简化说明：
- RAG 架构结合了信息检索和文本生成模型，这使得它在尝试回答用户问题时能够访问数据库。
- 数据库应该是一个可信赖的来源，它包含专有数据，允许模型在回应和推理时融入最新和可靠的信息。
- 在后台，一个数据管道会将各种结构化和非结构化的数据源输入数据库中，确保其内容的准确性和时效性。
- RAG 链接接收用户的查询（文本），从数据库中检索相关数据，然后将这些数据及查询一起传递给大语言模型，以生成高度准确且个性化的回答。
这种架构虽然复杂，但却带来了重要的好处：
- 它确保了大语言模型基于精确的专有数据，大大增加了模型的价值。
- 它采用了一种将模型带到数据而非将数据带到模型的方法，这种方法相对简单且成本效益高。
我们可以看到，这种做法正在现代数据架构中逐渐成为现实。行业的主要参与者们正以极快的速度努力简化 RAG 的使用，他们在自己的环境中提供大语言模型服务，这些环境中储存了企业的数据。
Snowflake Cortex 现在让各个组织能够在 Snowflake 平台上快速分析数据，并直接开发 AI 应用。Databricks 推出的新 Foundation Model APIs 使得用户能够在 Databricks 内即时接入大语言模型 (LLMs)。微软推出了 Microsoft Azure 的 OpenAI Service，而亚马逊也最近发布了 Amazon Redshift Query Editor。
我认为这些功能很有可能被广泛采用。但同时，它们也让我们更加关注这些数据存储中的数据质量。如果你的 RAG (可重用生成模型) 管道所依赖的数据存在问题，比如数据异常、过时或不可靠，那么你的生成式 AI 项目的前景又该如何呢？
残酷真相 #4：你的数据还没有准备好
仔细检查你的数据基础设施。如果你已经有了一个完美的 RAG 管道、经过微调的模型，以及明天就能用的清晰案例，你可能仍然缺少一个整洁、结构良好的数据集来实现这一切。
例如，你想让你的聊天机器人与客户交流。为了做到有效沟通，它需要了解你的组织和客户之间的关系。对于现在的企业组织来说，这种关系可能分散在 150 个数据源和 5 个孤立的数据库中，其中还有 3 个是本地部署的。
如果你的组织也是这种情况，那么可能还需要一到两年的时间，才能让你的数据基础设施准备好集成生成式 AI。
这意味着，如果你想在不久的将来利用生成式 AI 做出一些成果，你就需要尽快在现代数据平台上整合并创建出有用的、高度可靠的、完善记录的数据集。否则，当机会来临时，你可能会措手不及。
数据工程团队是保障数据健康的核心力量。现代数据技术栈能够帮助数据工程团队持续监控数据质量，确保未来数据的健康和可用性。
残酷真相 #5：你可能不自觉地忽视了生成式 AI 中的关键角色
在生成式人工智能的发展中，团队合作至关重要。不少数据团队在组建生成式 AI 专案小组时，常常忽略了一些关键角色，这种做法最终会影响项目的长远发展。
那么，谁是 AI 专案小组不可或缺的角色呢？首先是领导层或主要业务干系人，他们负责推动项目并时刻提醒团队其商业价值。接着是软件工程师，他们负责编写代码、开发用户界面应用和 API 调用。数据科学家则需要思考新的应用场景，对模型进行精细调整，并引导团队探索新方向。但在这个团队中，还缺少了哪个重要角色？
那就是数据工程师。
数据工程师在生成式 AI 项目中扮演着至关重要的角色。他们能够深入理解那些能够为公司在像 ChatGPT 这样的产品中提供竞争优势的专有业务数据，并负责搭建将这些数据通过 RAG 传输到大语言模型的数据管道。
如果没有数据工程师的参与，AI 专案小组就无法发挥最大效能。那些在生成式 AI 领域处于领先地位的公司已经开始在所有开发团队中加入数据工程师。
赢得生成式 AI 竞赛
如果上述的难以接受的事实适用于你，也不必过于担忧。生成式 AI 目前仍处于发展的早期阶段，现在重新开始并接受挑战仍不晚。
你需要退一步，深入理解 AI 模型能够解决的客户需求，从项目初期就将数据工程师纳入开发阶段，以确保从一开始就建立竞争优势。同时，花时间构建一个能够提供稳定、高质量、可靠数据流的 RAG 管道。
此外，投资于现代化的数据处理技术，确保数据质量成为优先考虑的因素。因为缺乏高质量数据的生成式 AI，不过是虚有其表的泡沫而已。
