S3の文書を索引化した知識ベースと、意味の説明を加えたデータセットをSpaceへ集約します。共通のチャットエージェントから両方を参照し、出典付きの回答を作る構成です。 データを集めるだけでなく、列の意味と権限を整えることが焦点です。エージェントの共有先にも、Spaceと各データへのアクセスが必要になります。 数値と文書を同じ会話で参照する AWSは11月3日、Amazon Quickで構造化データと非構造化データを合わせて使う実装手順を公開しました。表計算やデータベースの数値と、報告書や資料の記述を別々に調べる負担を扱います。構造化データは意味の説明を加えたデータセットに、文書はS3を基盤とした知識ベースに用意します。両方をSpaceという作業領域へ接続し、チャットエージェントの参照元とします。質問の内容に応じてデータセットか文書、または両方を使い、出典を付けて回答する構成です。新しい製品の発売というよりも、既存の機能を組み合わせる手順の紹介です。 売上の変化と戦略資料を照らし合わせる 手順では、売上のCSVと、事業レビュー、市場分析、製品戦略の文書を例に使います。表では日付や金額の型を整え、売上の定義や地域の区分を説明します。エージェントはその情報を使って、自然言語の質問をSQLへ変換します。文書の要約だけでなく、売上の傾向が市場分析とどう一致するかも質問できます。結果を基に、資料や表計算ファイルを作る例も紹介しています。影響を受けるのは、社内の報告資料と数値を往復して分析する担当者と見られます。データを一か所に複製することが中心なのではなく、共通の作業領域から参照できる状態にします。引用元が付いていても、数値の集計と文章の説明が正しく対応するかは別に確認する必要があります。共有先の利用者が参照できる範囲も結果に関係します。 権限と索引化の条件を先に決める データセットを作る利用者にはEnterpriseの契約が必要です。S3のバケットはQuickと同じリージョンに置き、管理者が読み取りを許可します。文書ごとのアクセス制御を使うかは、知識ベースの作成前に決める必要があります。原文は、その選択を後から変更できないと説明しています。エージェントを共有するだけでは、Space、知識ベース、データセットへの権限がそろうとは限りません。導入側では、閲覧する人の立場で回答を確認することが論点になります。文書の更新と表データの更新に差があれば、同じ会話に古い説明と新しい数値が混ざる可能性があります。列の意味、参照元の鮮度、共有範囲を一緒に管理する必要があると見られます。生成した資料を配布する前の確認担当も決めることが考えられます。 サンプルの成功から実データの評価へ進む 公開手順は架空企業のデータを使う構成です。実際の分析では、自社の会計期間や売上の定義などを明示する必要があります。次の判断点は、単純な集計だけでなく、表と文書を横断する質問でも根拠を追えるかです。契約や索引の費用に加え、意味の説明を保守する作業も見積もることが論点になります。導入の便利さと、数字を業務の判断に使える確かさは分けて検証する必要があると考えられます。共有先での再確認も、運用に含めることが考えられます。