跳到正文
AWS Machine Learning Blog· Sunil Yerkola·· 3 小时前AI 评分31

Qlik 如何基于 Amazon Bedrock 构建有据可查的企业级 AI

How Qlik built grounded, enterprise-scale AI with Amazon Bedrock

AI 导读

Qlik 基于 Amazon Bedrock 构建的 Qlik Answers 自 2026 年 2 月正式上线以来,为全球超过 40,000 家客户提供有来源、可验证的自然语言问答,其 Discovery Agent 已发现超过 100,000 个异常结果。

正文 · AI 翻译

在 Amazon Bedrock 上构建接地(grounded)AI,Qlik Answers 解决了一个常见的企业难题:员工并不缺数据,缺的是快速就数据提出真实问题并获得可信答案的途径。分析师往往要花数小时在文档、仪表板和机构记忆中搜索,只为回答同事一句话就能问出的问题。而当组织试图用生成式 AI 弥补这一差距时,许多人都碰到了同一堵墙:答案没有出处、结果无法验证,也没有在受监管环境中部署该工具的路径。

Qlik 是数据集成、数据质量、分析和 AI 领域的全球领导者,其构建 Qlik Answers 正是为了为全球超过 40,000 家客户解决这一问题。自 2026 年 2 月正式全面发布以来,Qlik Answers 已从早期功能发展为日常使用:Qlik 的 Discovery Agent 是一个 AI 驱动的异常和离群值检测智能体,自发布以来已为客户发现了超过 100,000 条洞察,并且开启了智能体工具的 Qlik Cloud 账户中大多数都在积极使用这些工具。

本文介绍了 Qlik 是如何构建这一被广泛采用的工具的,以及 Amazon Bedrock 如何在全球范围内为其提供支持。

挑战

Qlik 确定了三个需要同时解决的问题,才能将 Qlik Answers 在其客户群中推向生产环境:

  • 在不拖慢任何人的前提下编排专业化推理。企业问题五花八门:有的只需快速查询,有的则需要从结构化分析、非结构化文档、术语表定义或自动化中提取信息。单一通用助手随着功能不断增加,往往会变得更慢、更不准确。
  • 满足跨区域的数据主权要求。Qlik 服务于欧洲、亚太和美洲的客户,各区域都有自己的数据驻留期望。单一的全球部署模式无法满足这些要求,而 11 套独立的区域构建又难以持续维护和一致改进。
  • 提前数月预测模型容量。Token 消耗和模型可用性需要在重大发布前 3–6 个月进行规划。Qlik 随后在客户开始使用产品后,根据实际使用情况验证这些预测,从而确保采用率的增长不会演变成容量问题。

解决方案概述

Qlik Answers 让员工(不仅仅是分析师)可以在同一个地方提出自然语言问题,并获得有出处、可溯源的答案。根据问题的不同,答案可能来自知识库、实时分析应用、术语表定义或文档。底层系统会决定采用哪条路径。

三个部署案例说明了这在客户中的实际效果:

  • 全球钣金加工专家 Bystronic 在 15 分钟内部署了一个 AI 聊天机器人,让员工能够查询实时运营数据,并获得跨部门、带出处的答案。
  • Lintech International 在 Qlik Answers 中为超过 17,000 份技术文档建立了索引,将人工研究时间缩短,响应速度提升了 75%,为业务经理每周节省了多达 7 小时。
  • TouchPoint Support Services 服务于 650 个医疗健康场所,并计划将规模扩大一倍,它使用 Qlik Answers 为在受监管、快节奏环境中工作的 15,000 名员工提供快速且符合合规要求的指导。

为了大规模支持这一能力,Qlik 围绕清晰的架构边界而非单个大型助手来构建该系统。其主要层次如下:

  1. 入口层。Qlik Cloud 内一个稳定的对话入口,这样即使新增后端能力,也不会改变客户与助手的交互方式。
  2. 路由层。一个轻量级层,读取用户的消息和对话上下文,并决定请求应发往何处。它唯一的职责是做出快速、准确的路由决策,而不是解决任务本身。
  3. 答案层。在请求被路由后协调响应的生成,在面向简单请求的快速路径和更审慎的路径之间做出选择——后者会将一个问题拆分为多个子问题,并从多个来源获取信息。
  4. 专家智能体层。一个共享的 swarm 运行时定义了专家智能体、工具、状态和人机协同(human-in-the-loop)步骤的工作方式,因此新增专家智能体时,无需每个都自建一套编排模型。
  5. 对话式分析层。处理结构化数据问题,将其路由到一个面向分析构建的、具备应用感知能力的推理路径,而不是通用的文本生成。
  6. 检索层。非结构化文档的索引和检索运行在 Amazon OpenSearch Service 上,它存储并搜索相应内容,为 Qlik Answers 对知识库和文档问题的回答提供依据。
  7. 模型访问层。该层通过 Qlik 自己的大语言模型(LLM)网关接入,连接到 Amazon Bedrock 以实现聊天、流式传输、嵌入(embedding)和重排序(reranking)。它还会对每个请求和响应应用 Amazon Bedrock Guardrails:针对提示词注入、个人身份信息(PII)、机密信息以及被拒绝主题的内容过滤,外加对生成答案的接地验证(grounding-validation)检查。当客户依赖的某个模型在相应区域内尚未通过 Bedrock 提供时,Qlik 会改为在 Amazon SageMaker AI 上托管该模型,待该区域的可用性跟上后,再将该工作负载迁回 Bedrock。有关各 AWS 区域的模型可用性,请参阅 Amazon Bedrock 中的 Supported models by AWS Region。

Architecture diagram showing the layered platform design

图 1:员工的问题流经入口层、路由层和答案层,然后分支到专家智能体、分析智能体和检索智能体(由 Amazon OpenSearch Service 支撑),最终汇聚到模型访问层,该层可访问 Amazon Bedrock 上提供的基础模型,并以 Amazon SageMaker AI 作为区域内的后备方案

让回答立足于真实来源

接地(grounding)是该框架中较为重要的设计决策之一。答案层会根据问题从多种上下文中获取信息:结构化的应用元数据、检索到的知识库内容、术语表定义、自动化上下文,以及用于摘要的文档内容。在构成完整答案的各要素返回后,系统会组装出完整的响应并呈现给用户。

仅靠检索并不能保证准确性。Qlik 还会对生成的答案运行落地验证检查,使用 Amazon Bedrock Guardrails 中的 contextual grounding 功能,将每个答案与其所依据的源内容进行比对。这将落地性从单纯的检索步骤转变为经过核验的生产控制环节。对于非结构化问题,该工具会从 Amazon OpenSearch Service 中检索与问题相关的内容,并将该上下文传递下去,使最终答案包含引用。对于结构化问题,它会把工作交给对话式分析路径。更多功能,包括术语表查询、自动化和文档摘要,将随功能控制一起推出,这样 Qlik 可以扩展工具的能力,同时不会让所有客户的默认体验同时失去稳定性。租户级的功能选项意味着 Qlik 可以针对每个请求重建可用的编排路径,因此可以选择性地开启功能,同时整体架构在所有客户之间保持一致。

Diagram showing the specialist agent swarm architecture

图 2:专业智能体集群,其中共享状态、工具和人在回路中的步骤让新的专业智能体能够接入一个共同的运行时

为何选择 Amazon Bedrock

Qlik 根据前文描述的三个问题评估了其模型策略,而 Amazon Bedrock 直接解决了每一个问题。

多模型灵活性。借助 Bedrock,Qlik 可以为每个智能体的任务分配最合适的模型,而不必让整个系统受限于单一模型的取舍。

大规模的数据主权。借助 Amazon Bedrock 跨区域推理(CRIS),Qlik 可以服务全部 11 个区域,同时让数据驻留在合规要求所在的位置。这在单一托管能力中兼具了全球覆盖和主权控制。

有选择地采用托管服务的空间。AWS 的区域部署模型和容量预留选项让 Qlik 如今仍有继续扩展的余地。待时机成熟时,像 Amazon Bedrock AgentCore 这样的服务为 Qlik 提供了为特定工作负载卸载更多运维开销的选项,而无需为此进行完全迁移。

Qlik 通过自己的 LLM 网关使用 Bedrock,而不是将应用逻辑直接绑定到某一个模型。产品团队可以按任务更换模型,而无需重写周围的应用程序。这种分离对于一个预期模型策略会持续演进的系统来说至关重要。

在需求到来之前规划容量

由于 Qlik 会在重大发布前 3–6 个月预测模型容量,团队建立了一个按功能和区域预测 token 消耗的工作模型,并在每次发布后对照这些预测核查实际使用情况。正是这种纪律性,使得 2 月的正式发布在没有因自身采用而造成压力的情况下顺利扩展。

业务成果与客户影响

自 2026 年 2 月 Qlik 的智能体体验正式发布以来,Discovery Agent 已为客户呈现了超过 100,000 项发现,并且开启了智能体工具的 Qlik Cloud 账户中,大多数都在积极使用其智能体,而不是试用一次就放弃。

单独报告的客户层面成果包括 Lintech International 的响应时间缩短 75%,业务经理每周节省多达 7 小时,以及 Bystronic 的 15 分钟聊天机器人部署。

经验教训

在 40,000 多家客户中构建并扩展 Qlik Answers 的过程中,我们总结出了一些经验,或许能帮助其他在 Bedrock 上构建智能体工具的团队:

  • 尽早将快速路由与深度推理分离。把两者捆绑在一起,意味着每个请求都要为其并不需要的更多处理付费。
  • 为多智能体执行统一采用一个编排框架,而不是让每个新的专项智能体自创一套运行时。运维一个应用程序比运维一组彼此割裂的智能体系统要容易得多。
  • 将安全性与接地检查视为系统级的关卡,而不是各功能的事后补充。在模型访问层统一运行一次,意味着每个新的专项智能体都会自动继承相同的保护机制。
  • 在租户级别使用功能标志(feature flags)来逐步扩展能力。这可以防止新的、尚未经过充分验证的能力影响核心体验的可靠性。
  • 在需要之前就养成容量预测的习惯。每次发布后将预测用量与实际用量进行对比验证,才能让容量规划从凭空猜测变成可重复的流程。

下一步计划

Qlik 的路线图有意保持架构的开放性与适应性。团队正在针对部分工作负载评估 Amazon Bedrock AgentCore——在托管式智能体运行时能够降低运维开销的场景中使用它,同时继续在开放标准及其自研编排层之上进行构建,以便在成本、延迟或可移植性方面让 Qlik 保持更大的控制权。其目标是在托管服务有帮助时保留采用它们的选项,而不是让框架围绕其中任何一个来设计。Qlik 还在构建一个系统化的模型性能评估框架。这意味着当更合适的模型可用时,Qlik 可以迁移过去,而不会干扰客户已经依赖的体验。

结语

Qlik Answers 自 2026 年 2 月发布以来的采用情况,反映出一种“不添乱”的架构设计:在速度重要的地方快,在准确性重要的地方审慎,全程基于真实来源,并且安全到足以让受监管行业放心依赖。Amazon Bedrock 提供的模型灵活性、区域主权控制以及基于 Guardrails 的内容过滤与接地验证,为 Qlik 在全球规模上构建这一体验奠定了基础。迄今为止的成果包括:呈现了超过 100,000 条发现,为 Lintech 和 TouchPoint 等公司的员工节省了大量时间,并且开启了智能体工具的大多数账户在试用后仍在继续使用其智能体。

想看看 Qlik Answers 能为您的数据做些什么?可以开始 Qlik Cloud Analytics 免费试用、申请 Qlik Answers 演示 或 Qlik 与 AWS 演示,或访问 Qlik Answers 产品页面了解更多信息。


关于作者

来源:AWS Machine Learning Blog · aws.amazon.com