本記事では、Anewsの「社内情報検索機能」の裏側を紹介いたします。 本機能は複数の要素技術が組み合わさって実現されており、設計・実装において考慮すべきポイントが多数ありました。 本記事では、それらの全容についてご紹介します。
本記事の構成は次のとおりです。
- 社内情報検索機能とは？
- 設計の全体像
- 設計・実装のポイント
- 今後に向けて
社内情報検索機能とは？
調査レポートや技術報告書、実験データなど、組織に眠る様々な情報を、ビジネスニュースや論文・特許などの外部情報と同時に検索できる機能です。 これまでもAnewsでは、国内外のビジネスサイトや学術雑誌、プレプリントの論文などから情報を提供していましたが、さらなるイノベーションを創造するためには、外部情報だけではなく、組織がこれまで蓄積した内部情報の活用が必要です。その活用を促進する機能が本機能になります。
設計の全体像
まず、全体像を説明します。社内情報検索の大まかな処理フローは次のとおりです。
データ連携処理
まず、お客様の社内情報をAnewsのクラウド環境へ取得する必要があります。お客様のクラウドストレージからデータを連携する部分がここです。
データ登録処理（インデクシング）
1で取得した情報を検索エンジンに登録するまでの一連のデータ処理です。具体的にはデータのパース、前処理（クリーニングやチャンキング）、ベクトル生成といった処理が含まれます。
検索処理
本機能のコアとなる実際の検索処理です。ハイブリッド検索をベースに、LLMを用いた検索クエリの拡張、検索結果の要約生成(RAG)といった処理パイプラインで構成されます。
上記を実現するための、全体アーキテクチャは下図のとおりです。それぞれの実装コンポーネントは、AWSの各機能を活用して実現されています。
設計・実装のポイント
ここからは、設計・実装のポイントを5点、個別に紹介します。
1. データ連携コネクター
お客様のクラウドストレージ上の社内情報をAnewsのシステムへ取り込むコネクターモジュールを、クラウドストレージ毎に実装しています。 各コネクターは定期実行で、ストレージAPIから取得したデータをS3（Anews）へアップロードするのが基本的な処理となります。その際、ファイルメタデータの更新日付に基づき、新規に変更差分のあったデータのみを連携対象とします。 データの差分連携の実装においては、Webhookを利用したイベントドリブン方式も検討しましたが、実装難易度や機能要件（連携タイミング・頻度）を踏まえて、上記方式を採用しています。
2. 検索基盤
社内情報の検索処理フローは以下のようなパイプライン構成となっており、検索基盤はこの中のハイブリッド検索、及びリランキングの処理を担います。
ハイブリッド検索については、キーワード（レキシカル）検索及びベクトル検索（セマンティック）の各方式で得られた検索結果を、Reciprocal Rank Fusion (RRF) で統合します。その後、結果の上位のリストに対し、検索クエリとのベクトル類似度に基づいたリランキングを実行しています。 ベクトル検索、リランキングのそれぞれに用いるベクトルの生成には、我々のユースケースに合わせてファインチューニングした Multilingual-E5モデルを採用しています。 また検索エンジンにはAmazon OpenSearch Serviceを採用しており、ベクトル検索は多量のチャンクデータに対する⾼速な検索を実現するために、近似k-NN（Approximate k-NN）を利用しています。 これらの仕組みにより、我々のお客様のドメインにより適応した検索精度やパフォーマンスの実現に努めています。
3. Indexerパイプライン
Indexerパイプラインは、データ登録（インデクシング）処理の実行部です。連携されたデータを検索可能な形式に変換し、OpenSearchやS3 といったストレージに登録するまでの一連の処理を担当します。
主に以下の各処理から構成されます：
- ドキュメントのパース
- 様々なファイルタイプ（PDF、Word、PowerPoint文書など）の文書から、テキストデータを抽出します。ここでは、ファイルタイプごとに適した変換・抽出処理を行っています。
- テキストデータの加工
- 抽出されたテキストデータを検索処理に適する形式に加工します。具体的には、テキストのノイズ除去や正規化といったクリーニング処理、並びにテキスト分割（チャンキング）です。
- チャンキングは Recursively split 方式で、固定長・文単位での分割を行っています。
- ベクトル生成：
- 先述のmultilingual e5モデルを用いて、上記チャンクテキストのベクトルを生成します。
- データ登録
- 最後に、上記で処理されたデータをOpenSearch及びS3に出力します。
各処理はデータ量に応じて柔軟にスケールする必要があるため、Amazon EMR ServerlessならびにAWS Batchを採用しています。GPUが必要な物については後者を利用しています。 また最後のデータ登録処理についても、OpenSearchへの流量制限の観点から、コンピューティングリソースを制御可能なAWS Batchを利用しています。 そして、各処理をまとめる全体のワークフローにはAWS Step Functionsを採用しています。
4. LLM活用部
次に、大規模言語モデル（LLM）の活用箇所について説明します。先述の検索処理パイプラインにおける、クエリ拡張と要約生成の処理を、フルスクラッチで自社開発した Stockmark-13Bモデル1 によって実現しています。 クエリ拡張は、ユーザーが入力した検索クエリからキーワードを抽出し、それらに関連するキーワードや同義語を追加します。例として、「自動車の電動化」というクエリが入力された場合、「EV 電気自動車 バッテリー技術」のように変換されます。これにより、検索の再現率（recall）を向上させています。 要約生成はRAG（Retrieval-Augmented Generation）と呼ばれる手法で、検索結果として得られた複数の文書の内容を入力とし、LLMがその要約を引用付で生成します。これにより、検索結果の概要を把握した上で詳細をドリルダウンといったような、効率的な検索体験をユーザーに提供しています。 またLLMの推論APIの実装においては Text Generation Inferenceを採用し、高速な推論パフォーマンスを実現しています。
5. セキュリティ
社内の機密情報を扱うシステムであるため、セキュリティには特に注意を払っています。ベースとして、AWSのセキュリティベストプラクティスに沿った設計・実装にしており、堅牢性を保っています。
その他に、社内情報を一般的なデータ基盤と完全に分離しています。これにより、万が一、他のシステムにセキュリティ上の問題が発生しても、社内情報への影響を最小限に抑えられます。
今後に向けて
本機能の開発においては、事業上の背景からディスカバリーのスピードを優先し、まずはミニマムな機能セットでリリースしました。1stリリースを終えた今も、対応ストレージやファイルタイプの拡充といった基本機能の強化や、コア機能である検索/RAGの性能改善といった開発が鋭意継続中です。それらに加え、Anewsの元々の強みである公開情報と、社内情報がよりシームレスに、価値ある形で結びつくようなUI/UXの進化に向けた改善も計画しています。
上記は実現したいことの一部であり、他にも実現したいことがたくさんあります。一緒にプロダクトと組織を成長させていただける方を広く募集しています。カジュアル面談からぜひお気軽にご連絡ください！
（作成）岩瀬義昌、水田浩明
