Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GraphRAGのKnowledge Graphを 直接!見る/View-GraphRAG's...
Search
tyumugiko
September 05, 2026
Programming
110
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
GraphRAGのKnowledge Graphを 直接!見る/View-GraphRAG's-KnowledgeGraph-directly!
tyumugiko
September 05, 2026
More Decks by tyumugiko
See All by tyumugiko
Tokenomicsを知る日/A-Day-to-Learn-About-Tokenomics
tyumugi1113
0
44
AWSのコスト見積もりを簡単にしたいツールを作った件/Created -a-tool-to-AWS-cost-estimation
tyumugi1113
0
74
エンジニアが好きそうな、おススメ小説3選!/Engineer-Osusume-Novel-3
tyumugi1113
0
48
「AWS CDK入門」の前日譚/Prequelto-Introduction-To-AWSCDK
tyumugi1113
0
260
生成AIとお絵描き対決! ~テーマ:AWSシステム構成図~/genaiarchitecture-20250912
tyumugi1113
0
250
Other Decks in Programming
See All in Programming
片田舎のおっさん、 Swift Buildのダイアモンド問題解決の不具合修正PRを出すが、解決方法がキャッシュをしないようにすることであり、ビルド時間が伸びると言われてマージされないので高速化もする/swiftbuild
yimajo
0
340
週末にAI-DLCを本気で回したら$1,600溶けた
hbashimizu
0
120
Webエンジニアなのにブラウザの仕組みがわからないので、Pythonで自作してみた
tatsuki12
4
1.6k
FastAPI の並行処理モデルを完全に理解する
hoto17296
9
3.5k
How I Won Prize Money at a Hackathon Using Codex and Symphony Alpha
yasei_no_otoko
0
140
LL言語やWebフレームワークのPostgreSQL対応 〜DBの機能がユーザーに届くまで〜
kentaroutakeda
0
130
go-spidermonkeyでAIエージェントのCode Modeを実装する
syumai
3
1.5k
異なる設計思想のフレームワークを経験して得た学び
amekuhideki
2
1.4k
信頼性の目標を誰も求めてない
shubox
0
480
PHPプロジェクトの結合バランスを可視化する #php_night
kajitack
0
190
まだ間に合う!今年の夏こそSchemeのマクロ展開器を完全理解!
omasanori
0
610
高専、大学編入、そして未踏へ〜プロダクト開発とキャリアの歩み - Technical College, University Transfer, and On to “Mitou” / My Journey in Product Development and Career
pkmiya
0
130
Featured
See All Featured
Being A Developer After 40
akosma
91
590k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.2k
Documentation Writing (for coders)
carmenintech
77
5.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3k
Building AI with AI
inesmontani
PRO
1
1.2k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
[RailsConf 2023] Rails as a piece of cake
palkan
59
7k
Embracing the Ebb and Flow
colly
88
5.2k
Utilizing Notion as your number one productivity tool
mfonobong
4
560
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
360
Mobile First: as difficult as doing things right
swwweet
225
10k
Transcript
#jawsug #jawssonic2026 GraphRAGのKnowledge Graphを 直接!(ここでお決まりのあのポーズ)見る JAWS-UG島根支部 中林風真 @tyumugiko
自己紹介 株式会社テクノプロジェクト 中林 風真 ⚫ 2026 AWS Community Builders(Serverless) ⚫
2026 Japan AWS Top Engineers 2025年11月ごろから、島根支部の運営に join! 好きなAWSサービス: AWS CDK
島根県について どちらが、島根県でしょう? このへん!
島根県について こっち!! 左側で覚えてね! • 小泉八雲 モチーフの朝ドラ • 某 別班員 の実家
ということで最近観光客が増えてます! 皆さんもぜひ島根に来てください! Ruby Logo © 2006 Yukihiro Matsumoto, licensed under CC BY-SA 2.5
島根支部について • 2013~ 始動! • 最近、サメのアイコンが出来ました! • ←電車で懇親会!(8月) • 冬にはおでん熱燗電車を企画中で
す!!
GraphRAG の KnowledgeGraph を見たいんだよォーー!! こんな感じのヤツ ⇒
GraphRAG の KnowledgeGraph を見たいんだよォーー!! なんで??? → おもしろいから!
GraphRAGってなに? • RAG(検索拡張生成)にナレッジグラフを組み合わせたアプローチ 1 - Query 2 - RAG 質問
起点を類似検索 自然言語の問をベク トル化 物語チャンクの埋め 込みと質問の近さで、 グラフの入口を選ぶ。 3 - Knowledge Graph 回答を生成 関係をたどる 出会う 起点 + たどった関 係をLLMに渡す 老婆 下人 飢える 正当化 1.飢え死にか盗人か Q. 下人はなぜ 盗人になったのか? 飢え 2. 老婆の髪を抜く 3. 羅生門と死人 雨宿り 生 動機 羅生門 4 - Answer 盗人 A.飢えに苦しむ下人が、死 人の髪を抜く老婆と出会い、 「生きるためなら仕方ない」 という論理に背中を押され て盗人になる。 因果・関係まで答えられる GraphRAGで読む『羅生門』- https://zenn.dev/tyumugiko/articles/cf6b12ecba8127
GraphRAGってなに? • RAG(検索拡張生成)にナレッジグラフを組み合わせたアプローチ 1 - Query 2 - RAG 質問
起点を類似検索 自然言語の問をベク トル化 物語チャンクの埋め 込みと質問の近さで、 グラフの入口を選ぶ。 Q. 下人はなぜ 盗人になったのか? 3 - Knowledge Graph 回答を生成 関係をたどる 出会う 起点 + たどった関 係をLLMに渡す 老婆 下人 正当化 通常、この部分は飢える 1.飢え死にか盗人か フロントエンドから参照はしない 飢え 2. 老婆の髪を抜く 3. 羅生門と死人 雨宿り 生 動機 羅生門 4 - Answer 盗人 A.飢えに苦しむ下人が、死 人の髪を抜く老婆と出会い、 「生きるためなら仕方ない」 という論理に背中を押され て盗人になる。 因果・関係まで答えられる GraphRAGで読む『羅生門』- https://zenn.dev/tyumugiko/articles/cf6b12ecba8127
GraphRAG の KnowledgeGraph を 直接! (ここでお決まりのあのポーズ)
前提 / やりたいこと • 弊社の中に 社内技術ブログ があります(Amplify Hosting) • 記事はmarkdownで管理、所定のパスでS3に格納
• それらの記事から「ナレッジグラフ」を作る機能を追加したい。 • すでに、Bedrock Knowledge Base によるベクトル検索は構築済み • → 質問応答(RAG)の機能は必要ない • 社内システムのため、なるべくお金はかけたくない • 構築されたグラフのノードとエッジをUIから確認して、各記事の関係性を眺めた い
つまり 要件を整理するとこうです。 upload Document Amazon Simple Storage Service (Amazon S3)
なにかしら の処理 Graph定義 JSON Client
ナレッジグラフの作り方 • graphrag-toolkit(lexical-graph)の構築ロジックを使う • AWSの開発する、GraphRAGを作成するためのオープンソースの Python ライブラリ Toolkitを用いてナレッジグラフを構築・保存するために、必要なストアは2種類 グラフストア(graph store)
抽出したエンティティやその関係を、ノードと エッジのグラフ構造として格納する。ナレッジ グラフの本体はここに入る ベクトルストア(vector store) グラフ内の一部の要素の埋め込み(ベクトル) を格納する。GraphRAG のクエリ時に、グラ フを辿る「起点」を類似検索で見つけるために 使う。 例: Amazon Neptune, Neo4j, FalkorDB 例: OpenSearch Service, PostgreSQL (pgvector), Amazon S3 Vectors
ナレッジグラフの作り方 • graphrag-toolkit(lexical-graph)の構築ロジックを使う • AWSの開発する、GraphRAGを作成するためのオープンソースの Python ライブラリ Toolkitを用いてナレッジグラフを構築・保存するために、必要なストアは2種類 グラフストア(graph store)
抽出したエンティティやその関係を、ノードと エッジのグラフ構造として格納する。ナレッジ グラフの本体はここに入る 例: Amazon Neptune, Neo4j, FalkorDB ベクトルストア(vector store) グラフ内の一部の要素の埋め込み(ベクトル) を格納する。GraphRAG のクエリ時に、グラ フを辿る「起点」を類似検索で見つけるために 使う。 RAGは不要なので、 使いません 例: OpenSearch Service, PostgreSQL (pgvector), Amazon S3 Vectors
グラフストアの選定 • Amazon Neptune 使いません! なんで??? AWS使えよ! Amazon Neptune •
• → クソ高いからです 32 m-NCU × $0.19 × 730時間 ≒ 約 $444/月 停止していても、10%の課金が発生 記事更新の時にしか使わないグラフストアで常時起動は重い 更新するときだけ、起動してそれ以外は停止(削除)しておける、 軽量なストアがあればよい
グラフストアの選定 • FalkorDB • Redis ベースの軽量なグラフDB • 単一プロセスとして起動でき、状態を RDB スナップショットで丸ごと保存・復元できる
1. 元状態のグラフストアを復元 2. KnowledgeGraph作成 graphrag-toolkit falkordb.rdb graph store Graph定義 JSON 3. Graph定義と 新スナップショットを 作成 falkordb.rdb 4. 次回の実行に利用
FalkorDBのうれしさ • 起動コストが安い = 固定のVM/DBサーバを持たなくても良い • • 状態が S3 の1ファイルに集約される
• • FalkorDB は処理のたびに起動して、終われば消える。アイドル時間のコストはゼロ バックアップもバージョン管理も S3 に任せられる。 重い処理を差分だけに抑えられる • 過去のグラフは復元するだけなので、毎回全記事を再構築する必要がない 実測: 既存グラフ(5万ノード超)の RDB 復元: 約1秒 (S3 からダウンロード → FalkorDB 起動 → ready まで)
実行基盤をどこにするか 1. イベント駆動 • 記事更新 = S3 イベントで起動 2. 使い捨て
/ 従量課金 • AWS Lambda 週に数回程度。常時起動は避けたい Amazon Elastic Container Service (Amazon ECS) 3. VPC 不要 • VPC・NAT・サブネットの管理をしたくない 4. FalkorDB が動く実行環境 • FalkorDB のバイナリをそのまま起動できること 5. 15分では終わらない可能性がある • AWS App Runner 全件再構築は記事数ぶんの処理がかかる Amazon Lightsail AWS Batch
CodeBuild 1. VPC 不要 • デフォルトで VPC 外で動き、S3・Bedrock・ECR にそのまま出られる 2.
任意のカスタムイメージが動く • FalkorDB 公式イメージをそのままベースにできる AWS CodeBuild 3. 時間制限が緩い • 最大8時間。全記事を作り直す全件モードでは記事数ぶんの抽出がかかるため、Lambdaの15分 では足りない場面でも余裕がある 4. イベント駆動 • EventBridge から `StartBuild` を直接呼べる(間に Lambda を挟まなくていい)
最終構成 upload おもしれー source=aws.s3 Document S3(記事) Amazon EventBridge 私 falkordb.rdb
AWS CodeBuild graph store Json取得 graphrag-toolkit Graph定義 JSON Client react-force-graph-2d Amazon Bedrock S3(graph)
できあがったもの • □ が記事ノード • 〇 が関連ノード • 記事同士が関連ノードで結 合され、知識のつながりが
見えてくる
まとめ • KnowledgeGraphを、直接! みることができた • KnowledgeGraphを見るだけなら、常時稼働のインスタンスは不要 • CodeBuildをバッチ処理的につかうのは、VPCを持ちたくない、かつシンプル な処理であればあり! •
CodeBuildは万能ではない • 本来 CI サービスなので、CI 前提のフェーズが挟まる • ジョブのリトライ・依存関係・キュー・配列ジョブといった本格的なバッチ制御などの機能は劣る
Thank you! 島根に来てね!