“人工智能不应该浪费时间重新发明ETL”
AI should not waste time reinventing ETL.
人工智能（AI）最近取得的进展非常令人兴奋。人们正在以各种新颖的方式使用它，从改善客户支持体验、编写和运行代码，到创作新音乐，甚至加速医学影像技术。
但是在这个过程中，出现了一个令人担忧的趋势：AI社区似乎正在重新发明数据移动（也称为ELT）。无论他们称之为连接器、提取器、集成、文档加载器还是其他名称，人们都在编写相同的代码，从相同的API、文档格式和数据库中提取数据，然后将其加载到矢量数据库或索引中供其LLMs使用。
问题在于，从头开始构建和维护稳健的提取和加载流水线是一项巨大的承诺。而且在这个领域已经有很多先前的成果，对于几乎所有AI领域的工程师或公司来说，重新构建是一种巨大的时间浪费。在一个新闻每小时出现一次的领域里，主要的焦点应该是让你的核心产品为用户提供令人难以置信的体验，而不是进行其他任务。对于几乎所有人来说，核心产品不是数据移动，而是你正在酿造的AI魔力。
关于构建稳健的ETL（数据提取、转换和加载）流水线涉及的挑战已经有很多文章进行了阐述，但是让我们将其放在AI的背景下来看。
为什么AI需要数据移动？
基于公共数据训练的LLMs很棒，但你知道什么更好吗？能够回答与我们、我们的公司和我们的用户相关的问题的AI。如果ChatGPT能够学习我们整个公司的维基百科、阅读我们所有的电子邮件、Slack消息、会议记录和转录，并与我们公司的分析环境连接，那么当回答我们的问题时，它可以使用所有这些信息。或者，当将AI集成到我们自己的产品中（例如Notion AI）时，我们希望我们应用的AI模型在帮助用户时能够了解我们拥有的有关用户的所有信息。
这就需要进行数据移动。
无论你是在微调模型还是使用检索增强生成（RAG），你都需要从存储在任何地方的数据中提取数据，将其转换为你的模型可以接受的格式，然后将其加载到一个数据存储中，以便你的AI应用程序可以访问并为你的使用案例提供服务。
上图展示了在使用RAG时的情况，但你可以想象，即使你不使用RAG，基本的步骤也不太可能改变：你需要进行ETL（数据提取、转换和加载），以便构建AI模型，使其了解你和你的使用案例特定的非公开信息。
为什么数据移动很困难？
从API或数据库提取数据构建一个基本的功能性MVP通常可以在短时间内（小于1周）完成，但真正困难的部分是使其达到生产就绪状态并保持稳定。让我们看一下在构建提取流水线时可能遇到的一些常见挑战。
增量提取和状态管理
如果你有任何有意义的数据量，你将需要实现增量提取，以使你的流水线只提取之前未见过的数据。为此，你将需要一个持久化层来跟踪每个连接提取的数据。
临时错误处理、退避、失败后恢复和空隙隔离
上游数据源有时会出现故障，而没有明确的原因。你的流水线需要具备对此的弹性，并使用正确的退避策略进行重试。如果故障不是很临时（但仍然不是你的错），那么你的流水线需要足够弹性，以便在上游修复后从同一位置继续进行。有时，上游问题足够严重（比如API从记录中删除了一些关键字段），你希望将整个流水线暂停，直到你检查发生了什么，并手动决定如何处理。
识别和主动修复配置错误
假设你正在构建用于提取客户数据的数据提取流水线。在这种情况下，你需要实施一些防御性检查，以确保客户为了代表他们提取数据而给出的所有配置都是正确的，如果不正确，需要快速给出可行的错误消息。大多数API并不容易做到这一点，因为它们不会发布全面的错误表，即使它们这样做，它们也很少为你提供可用于检查权限分配的端点，例如API令牌，因此你必须找到方法在全面检查和为用户提供快速反馈之间取得平衡。
身份验证和秘密管理
API的简单性从简单的承载令牌认证到“创造性”的会话令牌或单次使用令牌OAuth的实现不一。您需要实现执行身份验证的逻辑以及管理密钥，这些密钥可能每小时刷新一次，并且可能需要在多个并发工作器之间协调密钥刷新。
优化提取和加载速度、并发性和速率限制
谈到并发工作器，您可能希望实现并发性以实现高吞吐量的数据提取。尽管这在小数据集上可能无关紧要，但在大数据集上绝对至关重要。即使API发布官方的速率限制，您仍需要经验性地确定最佳并行性参数，以在不被IP列入黑名单或永久限制速率的情况下充分利用API提供给您的速率限制。
适应上游API的变化
API经常变化并采用新的未记录的行为或特性。许多供应商每季度发布新的API版本。您需要关注所有这些更新可能如何影响您的工作，并投入工程时间来保持其更新。新的端点随时出现，有些会改变其行为（您并不总是得到提前通知）。
调度、监控、日志记录和可观察性
除了从特定API中提取数据的代码之外，您还可能需要构建一些水平能力，为所有数据提取器提供支持。您可能需要一些调度功能，以及在调度失败或其他问题发生时进行日志记录和监控，并进行调查。您还可能需要一些可观察性，例如昨天、今天、上周等提取的记录数量以及它们来自哪些API端点或数据库表。
数据阻塞或哈希
根据您提取数据的位置，您可能需要一些隐私功能，以在将其发送到下游之前阻塞或哈希列。
明确一点，如果您只是想作为一次性事务移动一些文件，则以上内容不适用。
但是，当您构建需要数据移动的产品时，这些内容就适用了。迟早，您将需要处理其中大部分问题。尽管没有一个问题是不可解决的，但是将它们一起考虑，它们可能很快累积成一个或多个全职工作，尤其是当您从更多数据源中提取数据时。
这正是维护数据提取和管道的困难之处：其大部分成本来自于持续增量投资，以保持这些管道的功能和稳定性。对于大多数AI工程师来说，这并不是为他们的用户增加最大价值的工作。他们最好将时间花在其他地方。
那么，AI工程师在这里需要做些什么才能移动一些数据呢？
如果您需要数据提取和加载管道，请先尝试已经提供的解决方案，而不是自动构建自己的解决方案。很可能它们可以解决很多，如果不是全部，您的问题。如果不能，作为最后手段再构建自己的解决方案。
即使现有平台不支持您所需的所有功能，您仍应该能够借助一个可移植和可扩展的框架来实现大部分功能。这样，您不必从头开始构建所有内容，而是可以通过平台上的现成功能完成90%的工作，只需构建和维护剩下的10%。最常见的例子是长尾集成：如果平台没有与您需要的API集成的集成，那么一个好的平台将使编写一些代码甚至无代码解决方案来构建该集成并获得平台提供的所有有用功能变得容易。即使您希望灵活性，只需将连接器作为Python包导入并从您的代码中以所需方式触发，您也可以使用诸如Airbyte或Singer连接器之类的许多开源EL工具之一。
明确一点，数据移动并非完全解决。存在现有解决方案无法满足的情况，您需要构建新的解决方案。然而，这并不是大多数AI工程师的情况。大多数人不需要一次又一次地重新构建与Jira、Confluence、Slack、Notion、Gmail、Salesforce等的相同集成。让我们使用已经经过实战测试并对所有人开放使用的解决方案，这样我们就可以继续增加我们的用户实际关心的价值。
