用Amazon Quick统一查询表格与文档

销售表能告诉你哪个地区收入下滑，市场报告可能解释外部需求变化，产品备忘录则记录了下一步押注。麻烦在于，这些信息通常分散在不同系统里，最后还得靠人把数字和文字拼起来。

AWS 这篇教程用 Amazon Quick 搭了一条完整流程：结构化数据走查询，文档走知识库，再交给同一个聊天 Agent 汇总。它值得读的地方，是把数据口径、上下文和权限都放进了搭建过程。但教程跑通，距离分析可靠、团队可用，还有几道需要核验的关。

同一个聊天入口，背后仍是两条数据路径

作者把方案分成三层。

数据层保留两种处理方式：PDF、报告、备忘录放在 Amazon Simple Storage Service（Amazon S3），由知识库建立索引；销售记录等结构化数据作为数据集导入，并补充语义描述，供 Agent 把自然语言转成 SQL。

工作区层用 Space 聚合资源。教程创建了「Business Intelligence Hub」，关联「Business Knowledge Base」和「Product_Sales.csv」。Space 还能容纳仪表盘、上传文件和 action connectors，但这次演示的重点是知识库与数据集。

Agent 层负责选择查询对象：查表、检索文档，或者两者都用，最后组织带引用的回答。

统一的是提问入口和上下文，底层仍然需要分别处理表格与文档。

这也解释了为什么不能只把 CSV 当附件塞给模型：收入排名、区域汇总、季度趋势需要明确的计算口径，而战略重点需要从文字中提取。两类任务各走合适的路径，结果才有机会互相补充。

教程有明确门槛：创建数据集的用户需要 Enterprise 订阅，还要具备创建 integration、知识库、数据集、Space 和聊天 Agent 的权限。S3 bucket 必须与 Amazon Quick 位于同一 Region；连接时可选择 Quick Suite instance account 或 Other AWS account。管理员选中的 bucket 默认授予只读权限。

文档侧使用三个样本：AnyCompany_Business_Review.pdf、AnyCompany_Market_Analysis_Report.pdf、AnyCompany_Product_Strategy_Memo.pdf。知识库可以选择 Add all content，也可以通过 Add specific content 按 S3 prefix 限定范围，且 prefix 区分大小写。

为什么数据描述比 Agent 人设更影响答案

教程上传 Product_Sales.csv 后，由内存计算引擎 SPICE 接收数据。随后作者没有马上开始聊天，而是先修正字段类型：

• Order Date、Date Key 从 String 改为 Date。
• Customer ID、Quantity、Unit Price 从 String 改为 Integer。
• Sales、Discount、Profit 从 String 改为 Decimal。

这个步骤看似琐碎，却直接影响筛选、聚合和时间分析。原文展示的数据集共有 16 列，不过没有提供字段修正前后的准确率对照。

接下来才是语义补充。数据集描述明确了 AnyCompany 的 FY2024-FY2025 销售范围，覆盖 North America、EMEA、Asia Pacific、Latin America。Custom instructions 则规定收入单位为 USD，区域比较按 Region 分组，趋势分析使用 Order Date，财政年度与自然年一致。

作者还写明计算口径：Sales = Quantity x Unit Price x (1 – Discount)。列描述进一步说明 Sales 是折扣后收入，Order ID 格式是 REGION-YYYY-NNNNNN，Segment 包含 Enterprise、Mid-Market、SMB。Product 则限定为 Analytics Pro、Connect、Automate、AI Assistant、Data Catalog、Integration Hub。

这些信息是在减少模型猜测业务含义的空间，而不仅是介绍数据集。

但这里有一处需要打问号：教程把 Date Key 改成 Date，指令里却又将它描述为 Order Date 的数字形式 YYYYMMDD。原文没有解释两者如何兼容。实际采用前，应先核对源数据、解析结果和字段描述，不能把示例指令整段照搬。

Agent 能把答案交付到哪一步

作者为聊天 Agent 配置了「Business Intelligence Assistant」身份，选择 Executive 回复风格，并关联前面的 Space。下面这段原始指令要求它连接不同来源，并交代回答依据：

You are a Business Intelligence Assistant designed to help organizations break down information silos. Your primary functions are:

1. Analyze business data stored in S3
2. Retrieve relevant findings from the reports and memos in the knowledge base
3. Provide comprehensive insights that connect internal data with external trends
4. Generate clear, actionable recommendations based on data analysis

When answering questions, always cite your sources and explain how you arrived at your conclusions. Focus on delivering practical business value and highlighting patterns across different information sources.

最需要关注的是最后一段：它要求引用与解释，但指令本身不能保证计算正确，也不能保证引用足以支持结论。

关联 Space 后，Agent 使用 LLM 自身知识和关联资源回答，并非完全限制为资料库内容。它还支持直接附加 PDF、TXT、HTML、MD、CSV、DOC、DOCX，最多从上传的参考文档提取 100,000 个字符。

作者展示了三类提问：2025 年各地区销售如何变化；产品战略备忘录有哪些重点，包括 FY2026 路线图和投资要求；2025 年销售结果与市场分析报告中的趋势是否一致。第三类最能体现组合价值，因为它要求将实际业绩与文字判断放在一起比较。

不过，提供的正文没有列出具体销售数字、生成的 SQL 或核验结果。我们能确认的是教程展示了回答与引用流程，无法据此判断分析准确率。

交付还能继续延伸到文件。原文演示了根据 Q4 2025 区域业绩生成 PowerPoint，并展示了可下载的八页 AnyCompany_FY2025_Sales_Performance.pptx；另给出了生成 Excel 收入前 10 笔订单，以及生成 Word 季度业务回顾的提示词。后两者在正文中属于使用示例，没有同等程度的结果展示。

我的判断

我认同这套方案把数据口径放在聊天体验之前。相比只接一个文档检索库，它保留了结构化查询能力；相比由业务人员分别查表、读报告，它减少了手工搬运上下文的步骤。

但作者没有给出准确率、响应耗时、成本或与其他方案的对照。所谓语义补充让 SQL 更准确，在这里是合理的机制解释，尚不是经过量化验证的结论。相比自己组合 SQL 查询工具与文档检索服务，Amazon Quick 提供了现成的资源组织和分享流程；定制程度与费用是否合适，原文不足以支持判断。

带引用的回答可以检查来源，却不能自动证明推理成立。

报告说某市场需求增长，销售表显示当地收入增长，两者并列出现，仍不能直接推出因果关系。

团队使用还有权限前提。Agent 启动后默认私有，分享时可分配 Owner 或 Viewer；接收者还需要拥有 Space、知识库和数据集的访问权限。知识库默认仅创建者可用。文档级 ACL 必须在创建知识库时决定，之后不能更改，这一步需要提前规划。

内置内容安全筛查，以及管理员最多配置的 50 个屏蔽词或短语，只能作为一层控制。S3 最小权限、文档访问范围和可信内容仍由使用方配置。通过 API 创建知识库时，可以为单个 S3 数据源提供自定义 IAM role；使用 AWS KMS 加密的 bucket 还需要相应配置。

能拿来做什么

• 如果团队已有销售 CSV 和业务报告，可以先限定一个业务范围，建立小型 Space，用「查数字」「找文档」「跨来源比较」三类代表问题验证结果，再决定是否扩充数据源。
• 准备数据集时，先写清字段类型、金额单位、日期口径和计算公式，并修正 Date Key 这类描述冲突。它们比调整欢迎语更值得优先投入时间。
• 把引用、汇总数字和关键结论作为验收对象。尤其是市场趋势与销售结果的关联判断，应检查来源是否支持结论，不能只看回答是否流畅。
• 分享前用实际接收者的权限验证访问；试验结束后清理 Agent、Space、数据集、知识库和 S3 integration，专用 bucket 也按需清理。订阅与账户费用独立计费，删除这些资源不能替代订阅费用管理。