Apache Kafka 如何作为 Elemental Cognition 中可信 GenAI 解决方案的支柱。
译自 5 Best Practices for Building Reliable GenAI Apps，作者 Mike Barborak。
企业领导者渴望开发人员构建满足客户需求并通过生成式 AI (GenAI) 和 大型语言模型 (LLM) 加快结果的应用。然而，三个核心问题破坏了仅限 LLM 的解决方案：幻觉、黑匣子决策逻辑以及无法可靠地解决复杂推理问题。
希望 采用 GenAI 的组织需要实时整合形式逻辑和约束优化功能——这是 LLM 所缺乏的一项关键要求。Elemental Cognition (EC) 是一个深度推理平台，它通过将 LLM 与其他 AI 技术相结合来解决复杂问题，从而在信任、准确性和透明度至关重要的动态情况下加速和改进关键决策。
该公司开发了一个 AI 平台，该平台使用 Apache Kafka 在将客户数据输入 EC 推理引擎之前对其进行持续流式传输和审查。Elemental Cognition 的平台在构建时使用 LLM 来帮助用户编写其应用程序规范。它们还用于在运行时与最终用户进行通信。但是，答案是由推理引擎生成的，而不是 LLM。
这是神经符号 AI 的一个示例，其中我们将神经系统和形式符号系统的优点相结合，以提供可靠的 AI 解决方案。
在 EC 的平台上，AI 驱动的解决方案始终由 EC 推理引擎生成，该引擎使用透明、可证明正确的形式推理生成解决方案。应用程序的定义、要求和约束是用自然语言编写的，使了解它的业务流程所有者能够对其进行审查和审查。
该 AI 平台以 Confluent Cloud 为基础，还具有云原生架构，它需要使用溯源数据实时做出规模化决策，确保用户输入按正确顺序排列且永不丢失，无论可能发生的任何基础设施故障或代码更改。
以下是开发人员和架构师可以从 EC 在 GenAI 用例中采用混合方法的经验中学到的内容。
具有实时推理的应用不能仅依赖 GenAI
在当今软件消费的世界中，开发人员不断被要求使用 AI 构建解决方案，以便快速做出决策并对复杂问题生成答案。通常，这些问题归结为约束满足问题——其中可行解决方案受限于满足预先建立规则的有限组合。
无论我们讨论的是构建可以生成可预订旅行行程或最佳供应链路线的应用程序，都可能轻松地有数千、数百万甚至数十亿种可能的配置与资源可用性和最终用户输入（以及其他约束）进行比较。并非所有配置都是有效的，开发人员有责任构建应用程序和服务，以便每次都能快速引导用户找到正确的答案。
前端体验可能看起来很简单，但后端流程可能涉及通过数千条业务规则过滤信息。当约束和变量值实时更改时，工程挑战会呈指数级增加。
例如，想象一家金融公司希望使用 AI 构建一个用于智能投资的系统。AI 解决方案需要在动态约束集内可靠地做出决策，例如账户的可用余额、投资者的风险承受能力、税收影响、监管条件以及感兴趣的每种投资工具的市场表现。
仅使用 GenAI 解决约束满足问题意味着开发人员及其最终用户必须应对 LLM 经常产生的幻觉。这些不准确或无意义的响应使得 GenAI 在物流、复杂研究、教育规划甚至旅行预订等关键任务用例中本质上不可信。
当 LLM 在黑匣子中构建时，这个问题只会变得更加复杂，从而使底层机器学习 (ML) 模型和业务逻辑免于审查，并使补救措施几乎不可能。虽然 LLM 降低了进入门槛，并使构建会话应用程序变得更容易，但它们根本不是为了可靠地解决复杂的约束优化问题而设计的。这是一个特性，而不是一个错误。
通过混合 AI 方法获得两全其美
纯 LLM 驱动的解决方案最适合专家作为最终用户并且具备知识和时间来立即审查和更正输出的情况。当最终用户不是专家或无法访问做出复杂问题正确决策所需的所有信息时，他们需要具备 LLM 所缺乏的精确、准确推理的 AI 解决方案。
例如，在 基准测试 中，随着推理问题的复杂性增加，OpenAI 的 GPT-4 生成的响应的准确性从 32% 下降到 14%。相比之下，我们在 EC 构建的平台保持了 100% 的准确性，即使对于需要可选计划构建和计划验证的问题的响应也是如此——在这种情况下，底层 AI 必须评估其自身输出的有效性。
这些结果表明了为什么企业在利用生成式 AI 来应对关键业务用例（如 多大陆旅行预订、高等教育 中的学位规划和供应链公司的 物流和履约优化）时需要采取混合方法。
使用 Kafka 来大规模加速 AI 决策制定
提供可靠推理很大程度上取决于在云中部署分布式、容错 AI 平台，该平台能够实时集成新数据。
我们的平台依赖于通过 Kafka 进行基于流的数据摄取，以从客户端的数据源收集信息。为了让 EC Reasoning Engine 和 LLM 访问此信息，源数据需要在没有任何错误或服务中断的情况下进行处理、同步和索引。
每天有数亿条消息通过 Elemental Cognition 平台上的多达 12 个处理阶段。使用以 云原生 Kafka 引擎为核心的流式架构可确保所有数据都通过每个阶段。
Kafka 的排序保证、持久性和容错性允许 EC 在 EC Reasoning Engine 内构建事务性工作流，该工作流基于预定义的业务规则准确处理用户输入，因为它们确信：
- 该平台具有基于用户请求的顺序的正确上下文。
- 即使在出现扩展问题、代码更改或意外停电的情况下，请求也不会丢失或被丢弃。
- 随着请求变得越来越复杂，输出将保持准确性，并且可以追溯到源数据的来源。
EC 使用 Confluent Cloud 逐步添加数据，而不是花费更多资金来重新处理所有内容。这也意味着该平台可以通过我们的 Cogent 应用程序轻松地合并来自用户输入和新的或更新的业务规则的数据。
未来，EC 计划使用 Confluent 来开发数据管道以生成数据来训练 ML 模型。Kafka 将成为生成数据的支柱，并且可用于微调现有的 ML 模型，并为更窄的用例添加新的补充模型或从头开始构建全新的模型。EC 客户有某些用例，他们需要保护专有数据；EC 将能够在 Confluent Cloud 之上构建模型，而无需客户在训练过程中公开该数据。
构建可信赖的生成式 AI 应用程序的最佳实践
企业及其开发人员如何利用生成式 AI 的优势，而不让其用户和关键业务决策受到其弱点的影响？
对于需要复杂推理的用例，我们建议遵循以下最佳实践：
- 切勿将真实来源放入 LLM 中：在我们的平台上，真实来源来自 EC 推理引擎，该引擎使用经过同行评审或由了解该数据的业务流程所有者审查的数据，因此业务对数据的正确性有一定信心。然后，推理引擎生成解决方案，并使用 LLM 根据事实支持与最终用户进行交互式规划对话。
- 使用能够解决约束满足和优化问题的推理引擎：此引擎应该能够理解和应用客户定义的业务规则，以解决仅靠自动化或其他技术无法解决的复杂物流、调度或规划问题。
- 使用 GenAI 促进与最终用户的自然对话：将他们的输入形式化，以便与推理引擎交互，并使用自然语言将输出传达给他们，以促进无缝交互。将 EC 推理引擎与经过微调的 LLM 紧密集成以与最终用户进行通信至关重要。
- 使用 GenAI 捕获专家知识：自动记录现有的业务规则，定期更新它们，并收集对推理引擎输出的反馈。
- 使用云原生架构在 LLM 和推理引擎之间传输数据：AI 解决方案的价值与其数据一样好。使用容错、可扩展的流式引擎，如 Kafka 将数据流传输在 LLM 和推理引擎之间，而平台的其他部分管理所有计算和事务。
在 EC 平台的核心，推理引擎在云中运行，并实时连接到关键数据，以便最终用户可以根据最新信息配置计划。通过这种方法，LLM 充当系统、算法和计算设备之间解决复杂推理问题并对其进行自动化的自然语言接口。最终用户通过与解决方案进行用户友好的交互获得个性化帮助，而企业拥有可靠、透明的推理，他们需要利用 AI 做出更快速、更明智的决策。
