Amazon S3 Vectors と Amazon DynamoDB で社内文書の関連グラフを構築

ダイキン工業株式会社の森本です。

社内には、設計書、手順書、報告書など、形式や用語の異なる文書が大量にあります。キーワード検索やベクトル検索で目的の文書を見つけても、関連資料までは容易にたどれません。そのため、条件を変えながら検索を繰り返す必要があります。

そこで、文書をノード、文書同士の関連をエッジとする「文書関連グラフ」を構築しました。本記事では、Amazon S3 Vectors と Amazon DynamoDB を使って関連候補を計算・保存し、検索ツールとグラフ画面から利用するまでの流れを紹介します。

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

製造業では、製品ごとの設計書や手順書だけでなく、複数の製品で共通して使う規程や標準、過去の資料なども大量に蓄積されます。文書によって用途や対象が異なり、同じ部品や技術に関する情報が複数の文書に分かれていることもあります。

キーワード検索やベクトル検索を使えば、検索内容に関連するチャンクや文書を見つけられます。一方で、検索結果にはチャンクや文書が一覧で並ぶため、その周辺にどのような関連資料があるかまでは分かりません。製品や部品に関する文書と、共通して参照する規程などを横断して確認するには、検索結果を手がかりに条件を変えて検索し直す必要があります。

製品や部品などをエンティティとして関係を定義するナレッジグラフなら、文書をまたいだつながりを詳しく表現できます。ただし、エンティティと関係の設計に加えて、文書から情報を抽出し、更新する仕組みが必要です。種類の異なる文書を共通の仕組みで扱うには、構築と運用の負担が大きくなります。

そこで、エンティティや関係を細かく定義せず、文書の内容の近さだけで文書同士をつなぐことにしました。

1. 文書を分類・変換する : 文書形式に応じて、MarkItDown や OCR で本文を抽出し、Markdown 形式に変換する
2. チャンクに分ける : 文や見出しなどを単位として、話題の境界で本文を分割する
3. タグと要約を生成する : LLM で文書種別や製品名などのタグと、文書全体の要約を生成する
4. チャンクを埋め込む : チャンクごとに埋め込みを生成し、Amazon S3 Vectors に保存する
5. 関連候補を更新する : 要約とチャンクの埋め込みから関連候補を計算し、結果を Amazon DynamoDB に保存する

OCR には Qwen3 VL 235B A22B、タグと要約の生成には Anthropic Claude Sonnet 5、埋め込み生成には Amazon Nova Multimodal Embeddings を使用しました。いずれのモデルも Amazon Bedrock 経由で呼び出しています。

ベクトル検索には、インフラのプロビジョニングが不要で、運用負荷とコストを抑えやすい Amazon S3 Vectors を採用しました。保存したチャンクの埋め込みは、文書検索と関連候補の計算に利用します。

チャンク分割では、Markdown を文や見出しに分けます。隣り合う文章の埋め込みから類似度を求め、意味のある単位で区切ります。1 チャンクの長さは 450〜1,500 文字に収めます。

タグと要約は、文書のタイトル、ファイル名、本文の先頭 12,000 文字から LLM で同時に生成します。タグは 3 個程度で、先頭が文書種別、残りが製品名や機能などを表す名詞句です。生成後のタグは人が追加、編集できます。

関連候補は、ベクトル検索だけで集めます。元の文書の要約をクエリとして、内容の近いチャンクを Amazon S3 Vectors から検索します。

検索結果は文書ごとにまとめ、各文書に含まれるチャンクのうち、最も高い類似度をその文書への関連スコアとして扱います。チャンク単位で比較するため、文書全体としては話題が異なっていても、一部に近い内容を含む文書を候補に残せます。

関連候補は、文書の取り込み時に計算し、画面や検索ツールから利用します。文書の内容が変わった場合は、影響する候補を更新します。

関連候補を求めるには、ベクトル検索と関連スコアの計算が必要です。これらを利用のたびに行わず、文書の取り込み完了時に実行します。文書ごとにスコア上位 20 件を選び、スコアとともに Amazon DynamoDB に保存します。

全体グラフと検索結果の周辺表示では、必要な関連の強さや件数が異なります。そのため、保存時には用途を限定せずに候補を残し、利用時にそれぞれの条件で絞り込みます。

文書の本文を更新すると、要約とチャンクの埋め込みが変わり、周辺文書との関連も変わります。更新した文書の候補はその場で再計算し、影響を受ける周辺文書については別の AWS Lambda 関数を非同期で起動して再計算します。これにより、すべての文書を作り直さずに関連候補を更新できます。

AI エージェントは、文書の検索、関連候補の探索、本文の確認を 3 つのツールに分けて行います。

• 文書検索 : 検索内容と意味の近いチャンクを返し、ヒットした文書ごとに関連候補を最大 2 件追加する
• グラフ探索 : 文書、タグ、または検索語を起点に、1 段先にある関連文書やタグを返す。返された文書やタグを新しい起点にすることで、さらに先まで探索できる
• 本文取得 : 文書 ID を使って、回答の根拠として確認するチャンクを取得する

文書検索は、回答に必要なチャンクとその周辺候補をまとめて探すために使います。さらに関連資料へ候補を広げたい場合は、グラフ探索を使います。グラフ探索で見つけた文書の内容は、本文取得で確認します。

文書検索で周辺候補を加える処理とグラフ探索には、取り込み時に事前計算した関連候補を使います。そのため、利用のたびにベクトル検索を追加で実行する必要はありません。

同じ関連候補は、AI エージェントだけでなく、グラフ画面からも確認できます。

文書の要約をクエリにしたベクトル検索で、関連候補を計算します。この方法で文書関連グラフを構築しました。

チャンクの埋め込みは Amazon S3 Vectors に保存します。関連候補は取り込み時に事前計算し、隣接リストとして Amazon DynamoDB に保存することで、専用のグラフデータベースを使わずに構成しました。計算した関連候補は、AI エージェントの検索ツールとグラフ画面から利用できます。

今後は、実運用における利用状況をもとに、関連候補が AI エージェントの文書探索に与える効果を評価していきます。