01
社内文書AI検索
規程、マニュアル、議事録、FAQ、PDFを横断し、答えと参照元を同時に表示します。
01 SYMPTOMS
01
社内資料はあるが、どれが最新版か分からない
02
検索しても文書が多すぎて、答えにたどり着けない
03
AI検索を試したが、根拠が弱く業務で使いにくい
02 CAPABILITIES
社内資料を生成AIへ入れるだけで終わらせず、検索方式、回答根拠、閲覧権限、更新運用まで含めて構築します。
01
規程、マニュアル、議事録、FAQ、PDFを横断し、答えと参照元を同時に表示します。
02
全文検索、意味検索、文書構造、情報同士の関係を質問に応じて組み合わせます。
03
社内ヘルプデスクや顧客対応で、回答できる範囲と人へ引き継ぐ条件を設計します。
04
部署別の閲覧権限、最新版の扱い、引用箇所、検索ログ、改善手順まで実装します。
課題、実装、成果、Beekleだからできたことまで確認できます
課題
問い合わせ履歴やマニュアルが大量にあるのに、キーワード検索では言い回しの違いを取りこぼし、複数文書にまたがる手順や例外対応を追えませんでした。
解決策
メタデータ・全文・ベクトル・グラフ近傍・対応根拠の複数経路を統合し、引用元を示しながら自然文の質問に答えるHybrid GraphRAGを構築しました。
成果
Beekleだからできたこと
通常のベクトル検索だけでは実際のデータ量で精度とスケールに限界が出ると分かっていたため、最初から関係をたどれる構成を選びました。フロントからAI基盤、インフラまで自社で運用しています。
技術スタック・構成
課題
実際のデータ量では、文書単位のベクトル類似度だけでは必要な情報にたどり着けませんでした。回答の根拠を示せないと、業務の判断には使えません。
解決策
メタデータ・全文・ベクトル・グラフ近傍・根拠(Claim)の5経路をRRFで統合し、回答後に根拠を検証する構成にしました。ナレッジグラフはNeo4jで構築し、回答には必ず引用元の本文を提示します。資料に無いことは「資料上は確認できません」と返します。
成果
Beekleだからできたこと
検索方式を先に決めず、精度が出ない理由から設計します。デモで終わらせず、実データを投入して運用を継続しているため、入れたあとに何が起きるかを織り込めます。
課題
過去の問い合わせ対応履歴やサポート文書はあるのに、担当者が毎回探して回答していました。チャット画面を置くだけでは、探す作業が利用者側に移るだけで問い合わせは減りません。正しい情報を検索し、根拠付きで答えられる裏側の仕組みが必要でした。
解決策
過去対応とサポート文書を横断検索し、自然文の質問へ引用元付きで回答するチャットボットを構築しました。回答は必ず引用元の本文を提示し、資料にない内容は断定しない設計です。
成果
Beekleだからできたこと
回答品質が出ないときにプロンプトだけを調整して粘るのではなく、検索そのものを作り替えられます。この案件では全文・メタデータ・ベクトル・グラフ近傍・根拠の5経路を統合して精度を確保しました。
04 WHY BEEKLE
検索技術の名前から入らず、実際の質問で答えられるか、根拠が正しいか、運用できるかを先に確かめます。
01
よく聞かれる質問、間違えると困る質問、根拠が必要な質問を用意し、方式を比較します。
02
単純な全文検索で足りるものから、複数検索やGraphRAGが必要なものまで過剰構成を避けます。
03
出典表示、権限制御、人への引き継ぎ、更新、評価ログまで本番運用へ組み込みます。
実案件ログ
単純なベクトル検索だけでは届きにくい質問に対して、文書構造と検索経路を組み合わせました。
成果物サンプル
答えだけでなく、参照元と該当箇所を一緒に確認できるようにします。
判断材料
よくある質問で回答品質、根拠、失敗パターンを見ます。
次に確認すること
部署別閲覧権限、最新版管理、機密情報の扱いを確認します。
05 MATERIALS
提案資料だけで終わらせず、社内説明や見積もり比較に使える形へ戻します。
01
質問、期待回答、参照文書、回答の良否、改善点を並べます。
02
対象文書、除外文書、更新頻度、権限を整理します。
03
答え、引用元、該当箇所、人への引き継ぎを確認できる形にします。
06 CONDITIONS
相談者側が社内で判断しやすいように、今すぐ着手しない条件も言語化します。
01
最新版の文書が特定できない
02
閲覧権限や機密区分を決められない
03
評価質問がなく、検索品質を判断できない
07 SERVICES