本文内容摘录自MongoDB白皮书《应用程序驱动型智能：定义下一代成功的现代应用程序》，若需获取白皮书原版pdf，请见文末获取方式。
要在数字经济时代保持竞争力并站稳脚跟，您需要让自己的应用程序变得更加智能。更智能的应用会使用数据、AI 和分析技术以自然语言与用户互动，生成见解并自主采取相应行动。这样可以带来两个好处：
1、与您的业务进行交互时，应用可通过提升客户体验和满意度来提高竞争优势。
2、应用可通过更快地制定明智的决策来提高效率和盈利能力。
对于这些提供价值的更智能、采用AI 技术的应用，它们必须直接在应用流内实时处理实时数据。思考以下应用场景：
在客户浏览电商网站时，提供高度个性化的服务，并使用自然语言、通过聊天机器人与客户互动。
在支付处理过程中检测并阻止欺诈交易。
在用户叫车时动态调整定价。
为音频流和视频流提供实时字幕和翻译。
除此之外，企业还希望针对运营流程自动制定决策并提供预测见解，以便应对当下情况，例如：
监控库存，以便在最佳时间推出限时抢购活动或调整供应链订单。
汇总支持案例并根据在线评价提取情感，以不断改进产品和促销活动。
通过分析传感器遥测数据预测设备故障。
生成并测试经过SEO 优化的网页的多个副本，以提高发现率和点击率。
为了构建这样新一代的智能应用程序，我们不能再仅仅依靠将数据从我们的操作系统复制到集中式分析数据仓库和数据湖中——在不同系统之间移动数据不仅耗时，并且会导致分析应用程序事件与采取行动之间出现分离。
相反，我们必须将一种新的AI和分析处理直接引入数据源，即应用程序本身，以便采用通过实时处理新鲜数据来提供价值所需的新工具、技术和工作流程。我们将这种方法称为应用程序驱动型智能。
这些示例虽然来自不同的行业和场景，但它们都有一个共同的关键需求：需要使用实时系统中的最新数据，提供实时智能、机器学习模型推理，以及采取相应行动。其输出控制着应用程序的行为，并为生成式AI提供了基准真值上下文。
白皮书用表格深入分析了「应用程序」（操作型数据库）与「集中式分析系统」（数据湖仓）处理数据方式的差异。
过去，这两者分别负责业务的运行和管理、由不同的团队管理、服务于不同需求的受众。「集中式分析系统」设计用于运行繁重、高度复杂的BI 报告和数据科学查询，未被设计为用于满足操作型应用程序（服务于数以千计的并发用户）的需求。它们无法对应用程序查询为代表的记录子集提供毫秒级的细粒度访问、不支持应用程序不断添加到、更新且随后实时查询以检索LLM 提示或模型推理的最新业务上下文的数据集。
传统的BI报告和离线机器学习模型，已无法满足实时智能和机器学习模型推理的需求。除此之外，还有部门孤岛的问题：分析团队往往被安置在集中式后勤部门，每当业务有新的分析报告需求时，都需要分析团队花费较多的时间和精力执行整个分析流程。应用程序与分析的交付速度不一致，进一步阻碍了向应用程序驱动型智能的转变。
因此，我们需要将AI和分析处理直接引入数据源——即应用程序本身，以实现应用程序驱动型智能。
应用程序驱动型智能不是试图将数据仓库或数据湖引入应用程序。相反，这是一种新型的AI 和分析，能够为数千个并发用户以低延迟的智能方式自动处理新鲜数据并提供见解。软件和模型通常会使用推理、提示和分析输出，以产生上下文体验，提供即时见解并促使采取行动。它们不是用于管理业务的仪表盘，也不是用于训练和调整离线自定义模型的信号。因此，应用程序中的分析和AI 查询仅接触几十到数千条记录，而不是数百万条记录。它们使用的是应用程序正在处理的实时数据，而不是经过数月甚或数年从几十个不同的数据源获取和合并的数据。
开发者和分析团队对于数据平台的功能有着各种不同的需求。白皮书中直观汇总了实现应用程序驱动型智能所需的各种功能，您可以下载pdf以查看更详细的内容。
超大规模服务提供商可以提供所需的功能，但是，这些服务是孤立的基本单元，而不是集成的平台。这意味着您的团队需要完成许多自定义工程工作，例如拼凑多个数据库、构建ETL 数据管道、设立自己的API 层等。所有这些复杂性都会带来巨大开销，和导致碎片化且低效的开发者体验，以及阻碍团队尝试采用应用程序驱动型智能，使得企业竞争力处于劣势。
但是，MongoDB 为您提供了一种更好的方式。
扫码咨询