使い続けてもらうためDifyによる社内文書 AI検索継続的改善 / Dify-Powered Document Search Improvement

2025年10月30日に開催された「kaonavi Tech Talk #21 〜 カオナビの業務におけるAI活用 〜」での登壇資料です 。
https://kaonavi.connpass.com/event/372337/

Transcript

1. 使い続けてもらうための Difyによる社内文書 AI検索の継続的改善 2025.10.30 | プラットフォーム本部 ソフトウェアサービスグループ 加藤元 © kaonavi, inc. 1
2. 名前：加藤元 職種：DevOpsエンジニア 経歴概略： バックエンドやサーバサイドのエンジニアを 経て、前職ではコーポレートIT。 カオナビでは主にDifyの運用と保守、改善 を担当してます。 自己紹介 © kaonavi, inc. 2 2
3. INDEX © kaonavi, inc. 3 • なぜ社内文書検索が必要だったか • Difyとシステム構成について • 改善活動について • 改善活動の裏話 • まとめ
4. なぜ社内文書検索が必要だったか © kaonavi, inc. 4
5. © kaonavi, inc. • 社内文書の情報はどこかにあるはずだけど、たどり着けない ◦ コンフルエンス標準検索では表記揺れが原因で キーワードが完全に一致しないと目的の文書が見つからない 例：❌「入館証を忘れた」 　 ⭕「入館カードを忘れた」 ＊コンフルエンスのAIアシスタント「Atlassian Rovo」がまだ無かった頃 5 目的の社内文書が見つからない課題
6. © kaonavi, inc. 1. 意味の理解（セマンティック検索） ◦ キーワードの一致ではなく、 単語や文章の「意味」を理解して検索して欲しい。 2. 自然な文章での対話 ◦ 単語の羅列での検索ではなく、 人に質問するように自然な文章で調べたい。 3. 回答の提示 ◦ AIが文書の内容を読み込み、質問に対する「答え」を分かりやすく 教えて欲しい。 6 理想の検索体験とは？
7. © kaonavi, inc. 7 表記揺れに強く、 「知りたい」という意図を汲み取ってくれる検索を 素早く低コストでどうやって作るか？ この仕組みを実現する技術が RAG (Retrieval-Augmented Generation) でした どうやったら実現できるか？
8. Difyとシステム構成について © kaonavi, inc. 8
9. © kaonavi, inc. 9 RAGとは (2) Retrieval（検索） 質問をベクトル化、意味の近 さで検索 (4) 質問＋マッチした文書 　 　回答生成の指示 (3) マッチした文書 (5) Generation（生成) 情報を基に回答を生成 (1) 質問 (6) 回答 ベクトルDB AI （LLM） カオナビの住所を教えて 株式会社カオナビ 〒150-6138 東京都渋谷区渋谷2-24-12 渋谷スクランブルスクエア38F… あなたは社内文書検索システムのアシスタントです。 「ユーザーの質問」に対して、「社内文書」の情報のみを 使用して回答してください。 社内文書から以下の情報が 見つかりました。 現在の住所： 〒150-6138 東京都渋谷区渋谷2-24-12 渋谷スクランブルスクエア38F
10. © kaonavi, inc. 10 • ノーコード、ローコードでRAGアプリケーションが実装出来る ◦ チャットボットやワークフローアプリ ◦ それぞれ外部から呼び出せるAPIとして公開が可能 • 環境構築の容易さ ◦ docker composeで簡単に環境を構築できる ▪ EC2上でセルフホストしてます • コスト面 ◦ セルフホストならDifyは無料、AWSのインフラとLLMの利用料金のみ • データセキュリティ ◦ 全てのデータ処理が社内AWSアカウント内で完結するため 機密情報を外部に送信することなく取り扱える Difyを選んだ理由
11. © kaonavi, inc. 11 アプリケーション設定や 取り込んだ社内情報な どを保管する PostgreSQL 意味の近さで検索する Weaviate Difyの心臓部である 2つのデータベースが検 索の要で、 後の改善活動の裏話に 関わってきます。 Difyのdocker composeで動いているコンテナ
12. © kaonavi, inc. 12 Difyへ社内文書情報を取り込む仕組み Difyで利用するデータは、内製のデータパイプライン「dify-batch」から 集約・加工し、DifyのAPIを介してナレッジベースを最新の状態に保っています
13. © kaonavi, inc. ユースケース毎の検索ドメインで選択、チャット形式で質問 13 Web版の社内文書検索
14. 改善活動について © kaonavi, inc. 14
15. © kaonavi, inc. 15 • Web版社内文書検索アプリの利用が横ばい ◦ Webアプリの社内文書検索にアクセスの手間がある • 検索範囲の絞り込みもうまく利用されてない ◦ 検索対象のドロップダウンリストから、選択肢が選ぶのに迷う ◦ そもそもどこの検索範囲が適切なのか分からない • 詳しそうな「人に聞く」という手段に流れてしまいがち 社内文書検索の悩み
16. © kaonavi, inc. 16 「ほんの少しの手間」が積み重なることで、 利用者は無意識のうちにWebアプリから足が遠のいてしまう。 「業務の中心で日常的に利用している」 Slackから社内文書検索に直接検索できるようにすることが、 利用者を増やす鍵だと考えました。 外部サービスの Slackと社内のDifyを安全に繋ぐ構成が必要 利用者が常にいる Slackに連携
17. © kaonavi, inc. API Gateway(mTLS認証)で Slackからの正規リクエストかを証 明書で検証 Slack認証Lambdaでリクエスト内 容の正当性をコードで検証の2段 階セキュリティ Lambdaの役割を「認証」と 「Difyへの検索実行」に分離し変更 や機能追加が容易な設計 17 Slack版社内文書検索インフラ構成
18. © kaonavi, inc. Slack版は仕事をしている場所に 情報が届く体験 会話と同じインターフェースで検 索でき、気軽に利用できる 全体からの検索のおかげで 以前は見つけられなかった情報 も見つかるようになった （検索範囲が広がった分ノイズが 増える場合も有り・・・） 18 Slack版の社内文書検索アプリ
19. © kaonavi, inc. 19 改善1 ドキュメントデータの洗い替え更新 1. ノイズになって役に立たない文書情報があった • 解決策： 検索品質を低下させるノイズデータを一括削除 ◦ 中身が空の記事 ◦ 非公開になった古い記事 2. タイトル名で検索して見つかるはずの記事が、検索で見つからない • 解決策： 検索対象に「タイトル名」を追加 ◦ 検索対象外だった「タイトル名」も、検索対象に含めるように更新 このデータの洗い替え更新によって、検索のノイズが見つかるという問題と、 あるはずの記事がタイトル名で見つからないという、 2つの課題が同時に解決され検索品質が向上しました。
20. © kaonavi, inc. 20 改善2 親子チャンクモードで取り込み直し 汎用チャンクモード 親子チャンクモード 困ったこと 単語や文の途中でチャンク分割されて 情報が欠落して、検索で見つけれなく なり、LLMが期待通りの回答が作れな かった 解決策（親子モードの特徴） 文書を「親」となる大きなチャンク（段落 やセクション全体など）と、「子」となる 小さなチャンク（文など）に階層的に分 割 その原因（汎用モードの特徴 ) 指定した文字数でチャンク分割するた め、単語や文の途中で切れて意味の まとまりが無視される 悪い例 ”ボタンは押さない” “と動作しません” 良い例 “ボタンは押さないと動作しま せん” 結果、どう良くなったか 精度の高い「子」チャンクで検索を行 い、回答生成時には、その「子」チャン クを含む「親」チャンク全体をLLMに渡 し、回答品質が向上。 チャンクとは情報を検索しやすい「一口サイズ」に切り分けたかたまりの単位
21. 改善活動の裏話 © kaonavi, inc. 21
22. © kaonavi, inc. 起こったこと 大量のドキュメントデータの更新を連続的に行なったため、 EC2のDifyがディスク容量が枯渇して停止した。 原因 　　見た目と内部の動きに違いがあった 通常はAUTO VACUUMという定期的なお掃除機能によって片付けられる だが、今回はお掃除が追いつかないほどの猛烈なペースで デッドタプルがディスクを埋め尽くしてしまいました 22 裏話1 Dify（見た目の動き） • 上書き更新される PostgreSQL（内部の動き） • 更新後のデータを追加 • 更新前データがデッドタプル (不要データ)として残る
23. © kaonavi, inc. 対応 　EBSディスク容量を追加し、十分な余裕を持たせた さらなる工夫として、更新手順も変更 • AUTO VACUUMが作動しやすいように大量データから更新した • 利用がない時間帯にVACUUM FULL手動実行 2種類のVACUUMの挙動の違い 23 ドキュメントデータの洗い替え更新によるディスク枯渇対応 安心して更新作業を実施できるようになった！ AUTO VACUUM 閾値に達したら自動でデッドタプル削除を実行 VACUUM FULL 完全なディスク解放、テーブルロック発生
24. © kaonavi, inc. 24 裏話2 起こったこと 親子チャンクモードでデータを入れ直した後 社内文書検索の動作が重い、エラーを返すようになった 原因 • Weaviateがメモリを占有して、他のコンテナが使うメモリ不足 ◦ 親チャンクモードでベクトルデータ + 子チャンクのベクトル を生成 汎用チャンクモードに比べて1.3〜1.5倍ほどベクトルの数が増え、 メモリ使用量も比例して増加 ◦ Weaviateはベクトル検索のパフォーマンスを最適化するため、 利用可能なメモリを惜しみなく消費していた。 ▪ 結果、新たなリクエストを受け付けれない状態 になった
25. © kaonavi, inc. 25 対応①　WeaviateだけでEC2全体のメモリを使い切らないように 　　　　Weaviateコンテナのメモリ使用上限を設定 ▪ Difyのdocker-compose.ymlのweaviateの部分に追記 • LIMIT_RESOURCES: “true“ • mem_limit: OSや他コンテナを除いた利用可能メモリ分 • GOMEMLIMIT: mem_limitの9割 対応②　親子チャンクモードの子チャンク分割単位を大きめに変更 ▪ 子チャンク数が減る == ベクトル総数が減る • 結果、Weaviateの使用するメモリ消費量が削減。 Weaviateメモリ消費対応 システム全体の空きメモリに余裕が生まれ、安定稼働するようになった！
26. まとめ © kaonavi, inc. 26
27. © kaonavi, inc. 27 使いやすさ（ UX）と安定運用（技術）の両輪 • 便利な機能も、使いやすい入口（導線）がなければ「使われない」 ◦ 全社員が日常的に利用するSlackからの社内文書検索が 可能になったことで利用のハードルを下げることに成功した • Difyを「ただ使う」では、データ増加や品質改善の負荷に耐えられなかった ◦ docker compose内の各コンポーネント 特にPostgreSQL, Weaviateの特性を理解し、 利用状況に合わせて制御することが安定運用の鍵だった まだまだやるべき改善は山積み 役立つ「相棒」あり続けられるように改善を続けていきます。
28. © kaonavi, inc. 28 ご清聴ありがとうございました！