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
社内規程RAGの精度を73.3% → 100%に改善した話
Search
oharu121
February 26, 2026
Programming
9k
13
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
社内規程RAGの精度を73.3% → 100%に改善した話
RAGの精度を73%から100%に引き上げた、実録・チャンキング戦略とデータ前処理の工夫
oharu121
February 26, 2026
Other Decks in Programming
See All in Programming
実装をデザインガイドラインに追従させるための取り組み / 260731-dip-mosh-design-system
dachi023
0
6.6k
freeeにおけるEvalsの実践例の紹介
freee
PRO
0
130
仕様駆動開発の消費期限
watany
20
8.8k
不幸な GC
chencmd
0
300
AWS DevOps AgentのAzure接続機能を検証して見えた活用法/Use Cases Verified for the AWS DevOps Agent's Azure Connectivity Feature
masakiokuda
1
250
Discordを用いたラボオートメーション関連情報収集の自動化
noguhiro2002
0
170
源内ハンズオン概要編
hideg
0
200
仕様書を書く前にハーネスを作る - Agent Native開発は「探索を速く、判定を固く」
gotalab555
4
1.7k
関東Kaggler会_NVIDIA_Nemotron_コンペ_振り返り
rick_ds
0
670
React本体のコードリーディング
high_g_engineer
1
150
GDG Korea Android: 2026 I/O Extended ~ What's new in Android development tools
pluu
0
230
楽しそうなつよつよエンジニアと目が死んでる僕/A brilliant engineer having a blast, and dead-eyed me.
3l4l5
2
210
Featured
See All Featured
[SF Ruby Conf 2025] Rails X
palkan
2
1.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.9k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
790
Scaling GitHub
holman
464
140k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
490
Done Done
chrislema
186
16k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
460
エンジニアに許された特別な時間の終わり
watany
108
250k
Facilitating Awesome Meetings
lara
57
7.1k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
3
460
The Limits of Empathy - UXLibs8
cassininazir
1
610
Transcript
社内規程RAGの精度を73.3% → 100%に改善した話 複雑な手法より、まずは「チャンクサイズ」を見直 すべき理由 Yuchen Lin(リン ユウチェン)
自己紹介 & プロジェクト概要 自己紹介 • 名前:リン ユウチェン • 実績:AIハッカソンのファイナリスト10組 •
最近のマイブーム:OpenClaw(旧ClawdBot) プロジェクト概要 • RAGを探索するデモプロジェクト • 目的:チャンキング戦略を検証する • 開発:Next.js + FastAPI + Gemini 2.0 Flash • 課題: 社内規程(通勤手当、休暇など)を対象にした RAG。最初は「正解率 73.3%」という微妙な結果に。
RAGを「Google検索」で例えると? ステップ1:検索 ステップ 2:読解 クエリを送信すると、システムは「 上位K件」の結果を見つける →(Google検索結果1ページ目 のようなもの) そのK件の結果をLLMに渡します →人間がスニペットを読む
ように 検索結果をもとに、ユーザのクエ リに回答する ステップ 3:回答 答えが検索結果の2ページ目にある場合、LLMはそ れを見ることができない。 どんなに「賢い」LLMであっても、読んでいないこと には答えられない。
RAGが失敗する「あるある」 3選
解決への体系的アプローチ:3つの改善軸でボトルネックを特定 精度低下の要因を特定するため、以下の 3つの改善軸 に沿って複数の技術的な戦略を評価しまし た。これにより、最も効果的な打ち手は何かをデータに基づき判断します。 データ (Data) チャンキング (Chunking) 検索
(Retrieval) 生成 (Generation) 1. データ自体の最適化 (Data Preprocessing) 検索対象のドキュメント構造 そのもの を改善できるか。 テスト項目:従業員種別ごと のドキュメ ント分割 2. チャンキングの最適化 (Chunking Strategy) テキストをどのように分割・保持する か。 テスト項目:標準、大きめ、親子チャン ク、HyDE(仮説的質問) 3.検索後処理の導入 (Post-Retrieval) 検索結果をどう絞り込み、順位付けす るか。 テスト項目:クロスエンコーダーによる 再ランク付け
検証結果:データ最適化がほかの手法を凌駕 テスト条件 • 評価クエリ: 15問(例外規定の取得をテスト) • 各戦略で同じクエリセットを実行 • 正解判定: 必須キーワード
の有無で自動判定
チャンキング戦略の比較分析:なぜ「大きなチャンク」が勝ったのか 1. 標準チャンク イメージ Google検索に表示される 1段落だけ を読 んで回答しようとする状態。 イメージ 検索結果リンク(子)
をクリックして、前後 の文脈を含めた「 ページ全体(親) 」を LLMに渡す状態。 イメージ Google検索に表示される 数段落分 を読 んで回答しようとする状態。 2. 大き目チャンク 3. 親子チャンク
さらなる精度向上に向けた高度なアプローチ 1. 「聞き返す」検索 2. マルチインデックス振り分け 3.「意味の切れ目」の自動認識 ユーザーの質問が曖昧なとき、勝手に 検索せずエージェントが 逆質問 する。
規程の種類ごとに DBを分け、クエリにお じてエージェントが 最適な DBを選択する。 文書の構造や意味のまとまりを理解し、 動 的にチャンクサイズを変える。
Zenn 記事をチェック! ご視聴ありがとうご ざいました。 Githubをチェック!