採用情報
お問い合わせ技術情報
Bot基盤：Microsoft Teams
エージェントフレームワーク：Mastra
LLM：GPT-5.4-mini
Embedding：text-embedding-3-large
ベクトルDB：Qdrant
MCPサーバー：Python（FastMCP）
データ連携：Debezium／RabbitMQ／Python
検索方式：密ベクトル検索、疎ベクトル検索、ハイブリッド検索、リランキング、マルチクエリ検索
セキュリティ：Presidioによる個人情報マスキング、記事属性情報を利用したアクセス権限考慮検索
エージェントフレームワーク：Mastra
LLM：GPT-5.4-mini
Embedding：text-embedding-3-large
ベクトルDB：Qdrant
MCPサーバー：Python（FastMCP）
データ連携：Debezium／RabbitMQ／Python
検索方式：密ベクトル検索、疎ベクトル検索、ハイブリッド検索、リランキング、マルチクエリ検索
セキュリティ：Presidioによる個人情報マスキング、記事属性情報を利用したアクセス権限考慮検索
開発ストーリー
生成AIエージェントを構成する仕組みを自社で実装し、RAG（社内情報などを検索し、その内容を基に生成AIが回答する技術）を実用化するための知見を得ることを目的として、社内Wikiの情報をMicrosoft Teamsから検索できる生成AI Botを開発しました。
社内Wikiのデータ更新はDebeziumで検知し、RabbitMQを経由してPythonプログラムへ通知します。更新された記事は、意味の近さで検索できるベクトルデータへ変換してQdrantに登録することで、Wikiの更新を検索結果へ反映できる構成としました。
利用者は普段使用しているTeams上で自然な文章による質問ができます。Mastraで構築したBotは、自作したMCPサーバーを通じて検索基盤へアクセスし、社内Wikiから関連情報を取得して回答を生成します。
また、Presidioによって質問に含まれる個人情報をマスキングしてからLLMへ送信する仕組みや、Wiki記事の属性情報を検索条件に利用し、利用者の閲覧権限に応じて検索対象を制御する仕組みも実装しました。
苦労した点
最も苦労したのは、評価用データセット上の改善を、利用者が実感できる検索品質へ結び付けることでした。
最初に、埋め込みモデル、記事を検索用データへ分割するチャンクサイズ、前後の文脈を引き継ぐオーバーラップ量などを調整しました。評価結果には変化が見られたものの、実際の利用時に体感できるほどの改善には至りませんでした。
次に、文章の意味の近さを捉える密ベクトル検索へ、固有名詞や製品名などのキーワード一致に強い疎ベクトル検索を加え、両者を組み合わせたハイブリッド検索へ変更しました。しかし、これだけでは期待する情報を安定して取得できませんでした。
そこで、取得した候補を質問との関連度に基づいて並べ直すリランキングを追加したところ、体感精度は大きく向上しました。さらに、質問の意図に合わせた検索クエリを複数生成し、より広く候補を集めてからリランキングするマルチクエリ方式を採用することで、表現の違いや検索語の不足による取りこぼしを減らし、検索精度を安定させました。
最初に、埋め込みモデル、記事を検索用データへ分割するチャンクサイズ、前後の文脈を引き継ぐオーバーラップ量などを調整しました。評価結果には変化が見られたものの、実際の利用時に体感できるほどの改善には至りませんでした。
次に、文章の意味の近さを捉える密ベクトル検索へ、固有名詞や製品名などのキーワード一致に強い疎ベクトル検索を加え、両者を組み合わせたハイブリッド検索へ変更しました。しかし、これだけでは期待する情報を安定して取得できませんでした。
そこで、取得した候補を質問との関連度に基づいて並べ直すリランキングを追加したところ、体感精度は大きく向上しました。さらに、質問の意図に合わせた検索クエリを複数生成し、より広く候補を集めてからリランキングするマルチクエリ方式を採用することで、表現の違いや検索語の不足による取りこぼしを減らし、検索精度を安定させました。
注意した点
RAGでは、検索候補を増やし、詳細に評価するほど回答精度の向上が期待できる一方、処理量が増えて応答が遅くなるという課題があります。そのため、精度だけを追求するのではなく、利用者が待たされていると感じにくい体感速度との両立を重視しました。
検索クエリの生成、複数方式による検索、リランキングなどの処理には用途に適したモデルを選定し、並列化できる処理は同時に実行することで、検索精度を高めながら応答性能を維持しました。
また、評価用データセットによる比較だけでなく、実際の利用時に必要な情報へ到達できるかも確認しました。安全性の面では、個人情報をマスキングしてからLLMへ送信するとともに、Wiki記事に付与した属性情報を検索条件として利用し、閲覧権限を考慮した情報だけを回答生成に使用するよう設計しました。
検索クエリの生成、複数方式による検索、リランキングなどの処理には用途に適したモデルを選定し、並列化できる処理は同時に実行することで、検索精度を高めながら応答性能を維持しました。
また、評価用データセットによる比較だけでなく、実際の利用時に必要な情報へ到達できるかも確認しました。安全性の面では、個人情報をマスキングしてからLLMへ送信するとともに、Wiki記事に付与した属性情報を検索条件として利用し、閲覧権限を考慮した情報だけを回答生成に使用するよう設計しました。
開発にかける想い
研究開始時は「RAGはベクトル検索を実装すれば成立する」というイメージを持っていました。しかし、実用レベルの検索品質を得るには、埋め込みモデルやチャンク設計だけでなく、密・疎ベクトルを組み合わせた検索、リランキング、マルチクエリ、データ更新、応答速度、個人情報保護、アクセス制御など、多くの仕組みを組み合わせる必要があることを実感しました。
また、生成AIエージェントはLLM単体で成り立つものではなく、外部の情報や機能へ接続するハーネス、検索基盤、データ連携、セキュリティを含む全体設計が重要です。実際に一連の仕組みを自社で構築したことで、個々の技術だけでは得られない実践的な知見を獲得できました。
本研究で得られた知見を、今後の社内AI活用だけでなく、お客様向けの生成AIシステム開発にも活かしていきたいと考えています。
学習と技術検証を目的として開始した活動でしたが、検索精度の改善を重ねた結果、現在は社内ナレッジの検索や問い合わせへの一次回答を行う、社内ヘルプデスクのような役割も担っています。
利用者は社内Wikiの構成や情報の保管場所、登録時の表現を詳しく知らなくても、Microsoft Teamsから自然な文章で質問できます。ハイブリッド検索、リランキング、マルチクエリを組み合わせることで、質問とWiki記事で使用されている言葉が異なる場合にも関連情報を見つけやすくなり、社内ナレッジを活用するための入口として継続利用されています。
また、生成AIエージェントはLLM単体で成り立つものではなく、外部の情報や機能へ接続するハーネス、検索基盤、データ連携、セキュリティを含む全体設計が重要です。実際に一連の仕組みを自社で構築したことで、個々の技術だけでは得られない実践的な知見を獲得できました。
本研究で得られた知見を、今後の社内AI活用だけでなく、お客様向けの生成AIシステム開発にも活かしていきたいと考えています。
学習と技術検証を目的として開始した活動でしたが、検索精度の改善を重ねた結果、現在は社内ナレッジの検索や問い合わせへの一次回答を行う、社内ヘルプデスクのような役割も担っています。
利用者は社内Wikiの構成や情報の保管場所、登録時の表現を詳しく知らなくても、Microsoft Teamsから自然な文章で質問できます。ハイブリッド検索、リランキング、マルチクエリを組み合わせることで、質問とWiki記事で使用されている言葉が異なる場合にも関連情報を見つけやすくなり、社内ナレッジを活用するための入口として継続利用されています。
