针对多服务信息检索优化自然语言查询

在 AI 相关技术快速发展的时代，渠道应用如网页、信息亭、IVR 等正变得越来越智能，各行业都在制定策略，将最初的实验扩展为规模化实施，以解决数据质量、治理和负责任的 AI 挑战。尽管如此，仍在不断努力克服这些障碍并扩大实施规模。

以支持基础客户服务的渠道应用为例，传统架构方法中，应用会使用企业暴露的多种不同类型的 API（如体验和流程 API）来提供服务，这种协调信息获取的方式常常导致大量闲聊、网络开销和性能（如响应时间）问题，还会获取过多不必要的信息。后来引入了 GraphQL APIs 来解决传统 REST API 方法的许多问题，但随着渠道应用的日益智能化，需要从传统设计方法转变为将消费者暴露的 API（GraphQL 或 REST）与提供自然语言接口（应用终端用户理解和使用的语言）相结合，并利用该接口提供查询或问题。

这里至关重要的是是否有一种架构方法可以在使用 GraphQL 的能力提供复杂协调信息服务的同时利用这种自然语言接口。本文尝试描述一种利用自然语言接口、AI 和 GenAI、行业信息模型以及 GraphQL APIs 的架构方法。

示例用例场景

以银行客户向渠道应用（如 IVR、网页或信息亭）提问为例，如“能否帮助提供我的投资组合摘要（包括多个账户，如储蓄、活期、定期存款等）？”输入来自注册电话号码表单、用户登录或其他认证/授权令牌，最终形成客户参考 ID/号码。以银行业为例，但该方法可应用于其他行业，如电信、旅游、能源和公用事业，这些行业都有可用的行业信息模型，如能源和公用事业的通用信息模型（CIM）、电信的 TM Forum 等，BIAN 为银行业规定了行业信息模型。

架构概述

下图展示了实现上述用例场景的高级架构、组件和步骤。

关键架构组件/步骤

BIAN 语义 API 端点和描述：BIAN 为能力组件（服务域）提供语义 API 和 API 端点，定义了一组服务操作和业务对象模型或信息模式，可认为 BIAN 利用领域驱动设计来定义这些服务域，并将其规定为有界上下文，以根据 BIAN 规定的语义 API 规范来定义和开发微服务。参考BIAN 语义 API 门户获取所有服务域的语义 API 规范列表，此用例场景中的一些示例 API 端点及其描述如下：
- https://app.swaggerhub.com/ap...：获取储蓄账户信息的端点和操作描述。
- https://app.swaggerhub.com/ap...：获取活期账户信息的端点和操作描述。
- https://app.swaggerhub.com/ap...：获取定期存款账户信息的端点和操作描述。
  客户查询 Python 应用程序将这些 BIAN 语义 API、端点、操作和描述的知识库整理为嵌入。
嵌入模型：客户查询 Python 应用程序为上一步整理的内容创建嵌入，可使用支持结构化和非结构化文本的高级嵌入模型，如 Open AI Ada 嵌入模型，以更好地支持相似性匹配。
向量数据库：客户查询 Python 应用程序使用向量数据库（如 Chroma DB）存储这些嵌入，向量数据库支持基于各种相似性算法（如余弦相似性和欧几里得距离）对自然语言文本或描述进行查询。
图数据库：图数据库能高效存储节点和关系信息模型，并提供快速遍历图以检索与节点和关系相关信息的查询能力，如 Neo4j 数据库。GraphQL 使用 Cypher 查询语言查询数据，与关系数据库使用 SQL 类似，Cypher 查询可支持从图数据库中非常复杂的信息检索，并支持定义复杂查询逻辑的过程。图数据库还支持将图节点和关系通过 JSON 模板导入，BIAN 的层次化业务对象（BoM）模式信息模型适合存储在图数据库中。
GraphQL API 服务器和 GraphQL API 创建器：假设银行采用领域驱动设计和 BIAN 信息模型通过微服务实现 BIAN 语义 API，GraphQL API 服务器配置了银行 API 网关暴露的所有符合 BIAN 的实际 API 端点的响应 JSON 模式的映射，GraphQL API 创建器是一个组件，可利用 GraphQL CLI 基于输入请求和响应 JSON 模式自动生成 GraphQL API 端点、查询和响应，还可实现从各个数据源或端点聚合响应以形成 GraphQL API 查询的最终响应对象。
客户查询 Python 应用程序：该应用程序是架构的核心，实现以下功能：创建 BIAN 语义 API 端点、操作和描述的嵌入；将嵌入推送到向量数据库存储；使用 RAG（检索增强生成）模式从用户自然语言查询到 BIAN 嵌入中检索最匹配的内容；从向量数据库检索 BIAN 语义 API 端点、操作和图数据库中的相应模式对象；创建用户查询所需的请求和响应模式；调用 Graph QL API 创建器组件动态生成 GraphQL 配置和 API 实现并调用结果 Graph QL API；将 API 响应返回给渠道应用程序。
客户查询 Python 应用程序的 RAG 用于 top N 匹配：对于自然语言的客户查询，Python 应用程序调用向量数据库的 RAG 查询以获取最匹配的内容，向量数据库可检索以下 BIAN 语义 API 端点操作。
通过 LLM 从 RAG 结果中获取 top K 推荐：Python 应用程序调用大型语言模型（如 Open AI GPT 4.x、Liama 3.x 或 IBM 基础模型），并提供 RAG 的基础结果和客户查询，以获取 top K（如三个）匹配。
从图数据库获取 API 端点操作的模式：Python 应用程序使用 Cypher 查询图数据库以获取 LLM 在前一步中推荐的 API 端点操作的模式（JSON 格式）。
利用 LLM 生成 REQ/RES JSON、GraphQL 类型、查询和 API 端点：Python 模块可再次利用 LLM 为自然语言的客户查询生成优化的请求响应模式，并将前一步返回的模式作为上下文。
GraphQL API 创建器生成 GraphQL API 端点：给定前一步生成的请求和响应模式，Python 应用程序调用 GraphQL API 创建器在 GraphQL API 服务器中创建 GraphQL API 端点、生成查询、操作、配置和响应聚合。
GraphQL API 服务器执行 GraphQL API 端点：根据配置和请求、响应模式，GraphQL API 服务器检查与所需字段匹配的模式映射到 API 端点，调用这些 API 端点并检索 JSON 结果对象，GraphQL API 子图检查集成规则模板以提取匹配的映射模式和集成 API 端点，然后按编排规则模板中定义的顺序调用这些 API 端点，检索 JSON 结果对象，转换和聚合后将其作为单个响应返回给请求者。这种方法的好处包括简化 API 集成、增强 GraphQL 功能、促进组织内的可重用性以及利用 LLM 和 RAG 加快集成规则模板的创建。
GraphQL API 服务器将响应返回给 Python 应用程序：GraphQL API 服务器按响应模式聚合响应并发送响应。
Python 应用程序将响应发送到渠道应用程序：Python 应用程序可将响应转换为人类语音或交互式聊天格式并响应相应的渠道应用程序。

结论：随着组织的客户变得技术意识和精明，客户交互期望增加，需要更出色的体验。客户不再遵循渠道应用的标准用户指南，而是通过自然语言问题想象协调的洞察，这推动了灵活和 AI 驱动解决方案的发展，而非传统的固定 API 架构。