Qlik 基于 Amazon Bedrock 构建企业级问答系统 Qlik Answers，Discovery Agent 已产生超 10 万条发现
来源AWS Machine Learning查看原文
速览
- Qlik Answers 自 2026 年 2 月 GA 后进入日常使用，Discovery Agent 已产生超 10 万条发现。
- 架构核心是分层解耦：路由只负责快速分流，答案层再决定快路径或深度推理路径。
- 检索层用 Amazon OpenSearch Service，模型访问层用自研 LLM 网关接 Amazon Bedrock。
- Guardrails 在模型访问层统一施加，新专家智能体自动继承同样的安全与接地校验。
- 通过 Bedrock 跨区域推理服务 11 个区域，兼顾全球覆盖与数据主权。
- 模型未在区域内可用时先用 SageMaker AI 托管，区域可用后再迁回 Bedrock。
- 容量按 3–6 个月提前预测，并用实际用量回校，避免采用量增长压垮系统。
- Lintech 响应速度提升 75%、每周省 7 小时；Bystronic 15 分钟完成部署。
- Qlik 用租户级功能开关逐步放开新能力，避免影响核心体验稳定性。
- Qlik 正在评估 Amazon Bedrock AgentCore，用于部分可降低运维负担的工作负载。
AWS 官方博客披露了 Qlik 如何基于 Amazon Bedrock 构建企业级问答产品 Qlik Answers。Qlik 服务全球超过 40,000 家客户，其核心痛点是员工不缺数据，缺的是能快速向数据提问并获得可信答案的方式。Qlik Answers 自 2026 年 2 月正式可用以来，其 Discovery Agent 已为客户产生超过 100,000 条发现，且开启智能体工具的 Qlik Cloud 账户中大多数在持续使用。架构上，Qlik 没有采用单一通用助手，而是划分了入口层、路由层、答案层、专家智能体层、对话式分析层、检索层和模型访问层七层，检索层基于 Amazon OpenSearch Service，模型访问层通过自研 LLM 网关接入 Amazon Bedrock，并统一施加 Amazon Bedrock Guardrails 做内容过滤与接地校验。为满足数据主权要求，Qlik 借助 Bedrock 跨区域推理（CRIS）服务全部 11 个区域，同时保持数据留在合规要求所在地；当某模型尚未在区域内通过 Bedrock 提供时，Qlik 会先在 Amazon SageMaker AI 上托管，待区域可用后再迁回 Bedrock。客户案例方面，Bystronic 在 15 分钟内完成 AI 聊天机器人部署；Lintech International 索引了超过 17,000 份技术文档，响应速度提升 75%，业务经理每周最多节省 7 小时；TouchPoint Support Services 为 650 个医疗站点、15,000 名员工提供合规对齐的快速指引。
关键事实
- Qlik 服务全球超过 40,000 家客户，Qlik Answers 于 2026 年 2 月正式可用（general availability）。
- Discovery Agent 自发布以来已为客户产生超过 100,000 条发现，开启智能体工具的 Qlik Cloud 账户中大多数在持续使用。
- Qlik Answers 采用七层架构：入口层、路由层、答案层、专家智能体层、对话式分析层、检索层、模型访问层。
- 检索层基于 Amazon OpenSearch Service 做非结构化文档索引与检索。
- 模型访问层通过 Qlik 自研 LLM 网关接入 Amazon Bedrock，用于聊天、流式输出、嵌入和重排序，并对每个请求和响应施加 Amazon Bedrock Guardrails。
- Guardrails 用于提示注入、PII、密钥和拒绝话题的内容过滤，并对生成答案做接地校验。
本站视角
对正在做企业级 RAG 和 Agent 的中文团队来说，这篇文章的价值不在「Qlik 用了 Bedrock」这个结论，而在它暴露出的工程取舍。第一，分层解耦是明确的信号：把路由和深度推理拆开，让简单请求不付复杂请求的代价，这是很多国内 Agent 团队目前用一个大模型加一堆工具硬扛时最容易忽略的优化点。第二，把安全与接地校验放在模型访问层统一施加，而不是每个功能各自实现，这个做法值得直接借鉴——它让新增专家智能体自动继承同样的防护，而不是每加一个能力就重新做一遍合规评审。第三，用 SageMaker AI 作为区域内模型未就绪时的过渡、待 Bedrock 区域可用后再迁回，这套「先自托管、后托管」的路径，对需要满足数据驻留要求又不想被单一区域模型可用性卡住的团队有参考意义。我们的判断是，这篇文章本质上是 AWS 的客户成功案例，架构描述可信、细节具体，但成效数字全部来自 Qlik 自述，没有第三方审计，读者应把它当作一份可参考的工程实践清单，而不是可验证的行业基准。对国内做企业知识库问答的团队而言，最该带走的是「租户级功能开关逐步放开新能力」这一条——它解决的是新能力不稳定时如何不拖垮核心体验，这在 To B 场景里比模型选型更影响续约。需要观察的是，Qlik 提到的 AgentCore 评估仍处于「评估」阶段，尚未落地，说明即便是体量如 Qlik 的厂商，在托管 Agent 运行时上仍持谨慎态度。
背景与影响
企业级生成式 AI 落地长期卡在三个问题上：答案没有出处、结果无法验证、难以在受监管环境中部署。Qlik 作为数据集成、数据质量、分析和 AI 领域的老牌厂商，选择用 Amazon Bedrock 作为模型底座来回答这些问题。从这篇 AWS 官方博客披露的架构看，Qlik 的思路不是做一个大而全的通用助手，而是把系统拆成入口、路由、答案、专家智能体、对话式分析、检索、模型访问七层，让每层只做一件事。这意味着当企业问一个简单查数问题时，请求走快路径；问一个需要跨结构化数据、非结构化文档、术语表和自动化流程的复杂问题时，才走拆解子问题、多源拉取的深度路径。这种设计直接回应了通用助手「能力越加越慢、越加越不准」的问题。数据主权方面，Qlik 借助 Bedrock 跨区域推理在 11 个区域提供服务，同时把数据留在合规要求所在地，并用 SageMaker AI 作为区域内模型尚未就绪时的过渡方案。需要观察的是，这套架构的复杂度本身也是成本：七层解耦、租户级功能开关、自研 LLM 网关都意味着更高的工程投入，中小团队未必能照搬。另外，文中引用的客户成效数据（Lintech 75%、Bystronic 15 分钟）来自 Qlik 自身的客户案例页面，属于厂商自述，缺少第三方验证。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。