企業向けAIアシスタントの構築方法

0
読了時間

Mrinal Mohit

エンジニアリング

Arvind Jain

CEO

企業向けAIアシスタントの構築方法
Glean Icon - Circular - White
GleanによるAIサマリー
  • 大規模言語モデル(LLM)を企業データでファインチューニングすると、ハルシネーションの増加や事実の再現性の低下を招く可能性があります。独自のナレッジを統合するには、検索強化型生成(RAG)の活用が望ましいです。
  • 効果的な企業内検索を実現するにはスケーラブルで権限に配慮したクロールと検索機能を備えた集中型インデックスの構築が不可欠です。Gleanは、さまざまなデータソースを統合するための事前構築済みコネクタを提供します。
  • 従来のキーワードベースの手法と最新のニューラルネットワーク型セマンティックエンベデッダーを組み合わせることで、検索の関連性が向上します。Gleanのナレッジグラフは、組織内のコンテンツ、文脈、ユーザーのやり取りを理解し、検索結果をパーソナライズします。

GPT-4やPALMのような大規模言語モデル(LLM)は、現在のテキストベース生成AI体験の基盤を支える強力な推論エンジンです。LLMに質問を投げかけると、通常は的確な答え返します。これらのモデルは、学習データによって得た「ワールドナレッジ」を活用し、質問に対して知的かつ深みのある答えを導き出します。

しかし、社内の機密情報、たとえば社員だけがアクセスできる情報の場合はどうでしょうか?一般的なLLMに最新の顧客取引状況について質問しても、「十分なナレッジやアクセスがないため回答できません」と返される可能性があります。それだけでなく、誤った回答をでっち上げる「ハルシネーション」が発生し、誤情報の拡散や深刻な業務への影響を引き起こすリスクもあります。

ChatGPTのような生成AI技術を企業データに適用するのは、セキュリティ権限の管理、インフラのスケーリング、高品質な広範囲のナレッジグラフの構築といった課題があり、決して簡単ではありません。本ブログでは、企業データでChatGPTを活用する方法、その課題、そしてGlean Chat通じてどのように解決していくかをご紹介します。

企業データにおけるLLMファインチューニングの課題

BERTやRoBERTaといった従来の自然言語処理モデルでは、「ファインチューニング」が広く採用されていました。これは、基盤モデルの重みを活用し、特定のタスクやドメインに適応させる方法です。

しかし、今日の大規模言語モデル(LLM)の時代において、ファインチューニングの手法はどのように活用されているのでしょうか?まず、ChatGPTのような最新のLLMがどのように訓練されているかを見ていきましょう。

  1. まず、「基盤モデル」は膨大なデータ(数兆のトークン)を使用して訓練されます。これには莫大な計算能力が必要で、費用は数百万ドルにも及びます。このプロセスによって、ChatGPTが持つ優れた推論能力や生成能力が実現されています。
  2. 次に、当モデルはファインチューニングの段階に入ります。この段階では、自然言語の指示に従う能力を訓練し、人間の価値観に沿った調整が行われます。このプロセスは、モデルが有害な言動や偏見、プライバシー侵害などを回避し、倫理的に動作することを確保する上で非常に重要です。
 

一見すると、LLMに独自のナレッジを組み込む最適な方法はファインチューニングの段階のように思えます。しかし、ファインチューニングは特定のタスクのパフォーマンスを向上させるためのものであり、新しいナレッジをモデルに教えることを目的としていません。未知のナレッジでファインチューニングを行うと、逆にハルシネーションが増加してしまいます。 これは、モデルが十分な事実理解を持たないトピックに対して回答を生成するように訓練されてしまうためです。このため、OpenAIが述べているように、「ファインチューニングは専門的なタスクやスタイルを教えるのには適しているが、事実の再現には向いていない」という見解に私たちも賛同しています。

代替案として、基礎的な事前学習段階で会社の機密データを取り入れるドメイン適応(BloombergGPTMedPALMのような手法)を試すこともできます。この方法は広範なドメインにLLMを適応させる際に効果的ですが、企業向けAIコパイロットを構築する際にはいくつかの根本的な制約があります。

  1. フレッシュネス – モデルを会社データのスナップショットで微調整することは可能ですが、データが毎時間更新される場合はどうなるでしょうか?ユーザーは最新かつ関連性の高い情報を求めますが、それに対応するための継続的なモデル訓練は、コストがかかり維持をするのも困難です。
  2. 権限の問題 – 社内データへのアクセス権は社員ごとに制限されています。たとえば、CEOとCFOの間での機密会話、マネージャー限定の業績評価、エンジニアがアクセスできないSalesforceのデータなど、明確な権限管理が必要です。「すべて」のデータをLLMに投入すると、機密情報が含まれる回答が生成されてしまうリスクがあります。
  3. 説明可能性 – 社員がアシスタントに頼って仕事を進める場合、回答が正しいだけでなく、裏付けが取れることが重要です。たとえば、サポート担当者がチケットの解決策をアシスタントを通じて提案する場合、その提案の元となったドキュメントを確認できる必要があります。そのドキュメントは実際に存在しているのか。モデルが「ハルシネーション」を起こして架空の情報を生成していないか、ドキュメントは公式なものなのか、10年前に更新された古いものなのか。また、提案に関連する追加の文脈がドキュメント内に記載されているかもしれません。これらを確認せずにLLMの生成結果を盲信することは大きなリスクを伴います。
  4. 破滅的忘却 – 会社の独自データは、ベースとなるLLMの訓練に使用される膨大なデータ量に比べてはるかに少量です。そのため、モデルをファインチューニングすると、もともと持っていた幅広い一般的なナレッジを失ってしまったり、独自データの微妙なニュアンスを正しく学習できない可能性があります。

結論として、LLMをファインチューニング・再訓練してタスク特化型のパフォーマンスを向上させる手法は魅力的ですが、職場向けAIアシスタントにおいては、このアプローチには多くの制約やリスクが伴います。

検索拡張生成:ベクトル検索だけでは不十分

LLMが一貫性のある推論や説得力のある回答を生成する能力と、事実を正確に取得する能力(またはその欠如)を分離するために、システムはパイプライン形式で設計できます。まず、別の検索システムを使って知識を取得し、それをLLMに提供して、推論や統合の基盤とします。この手法は「検索拡張生成 (RAG)」として広く知られています。

  • ナレッジは常に最新かつ関連性の高い状態が保たれます。これは、定期的に更新される検索インデックスがクエリ実行時にLLMに挿入されるためです。
  • LLMは、ユーザーがアクセス権を持たない情報には決してアクセスしません。
  • ユーザーは、LLMに入力された文書の一部を確認し、生成された回答が正確な情報に基づいていることを検証できます。
  • 破滅的忘却は発生しません。これは、モデル内にすべての知識を保持しようとするのではなく、クエリ実行時に関連するナレッジを取得する仕組みだからです。

RAGの核となるのは検索機能です。この機能が企業データのセキュリティを守り、従業員が成功に必要とする関連性の高い回答を生成します。ここでは、これが検索の課題として重要である理由と、企業での実装における技術的要件を解説します。

データ: スケーラブルで権限に配慮したインデックス作成

企業向け検索ソリューションのデータ層を構築する際には、いくつかのアプローチを検討する必要があります。

個別のアプリAPIを横断する連合検索は一つのアプローチですが、重大な欠点があります。各アプリの検索APIには独自の仕様や要件、レート制限があり、スケーラビリティが制限されます。また、連合検索ではランキングアルゴリズムが最適化されず(各アプリ内のデータしか理解できず、SaaSの検索機能への投資が十分でないことが多いため)、結果として質の低い検索エクスペリエンスを提供することになります。

より良い解決策は、すべてのデータソースからデータをクロールし、インデックス化して集中型インデックスを構築することです。しかし、スケーラブルで権限に配慮したクロール機能と検索プラットフォームを構築するのは、数年を要するエンジニアリング上の課題です。数十億件規模のドキュメントを処理するスケーリングから、多種多様なデータソースを扱える統一されたドキュメントモデルの作成に至るまで、多くの技術的な取り組みが必要です。

Gleanは、Google Drive、Slack、Jira、Salesforceなどのアプリに対応する100以上の事前構築済みコネクタを提供しており、ユーザーが迅速にデータのインデックス化を開始し、数年分の開発工数を省くことを可能にします。数十万人の従業員、数十億件のドキュメント、数百テラバイト規模のデータを抱える企業様に対しても、Gleanのインフラ(約5年にわたり構築されたもの)がこの規模のデータを見事に処理します。

Gleanは、すべてのデータソースを単一のプラットフォームにインデックス化することで、組織全体のコンテンツ、コンテキスト、そして共同作業者を深く理解するクロスアプリ型ナレッジグラフを構築します。その上で高度なランキングアルゴリズムを適用し、最も関連性の高い結果を提示することで、個別のアプリAPIを使用するシステムを大幅に上回る検索エクスペリエンスを提供します。

データの価値を最大限に引き出したい企業にとって、事前構築済みのコネクタを備えたスケーラブルなインデックス化プラットフォームは、連合検索を超える最適な選択肢です。Gleanは、現代のSaaS主導の職場向けに設計されたインデックス化ソリューションを提供し、エンタープライズサーチを手軽に実現します。

トピックの関連性: リランク付きハイブリッド検索

スケーラブルでインデックス化されたコーパスを構築した後の課題は、特定のクエリに対して最も関連性の高いナレッジを取得することです。膨大な数の企業のドキュメントの中から、どのようにして最も有用で正確かつ最新の情報を含むものを見つけるのでしょうか?

これらの「関連性の高い」ドキュメントを取得してLLMに提供するために、ベクトル検索が有力な候補として浮上しています。このシステムでは、各テキストを数値のベクトルに「埋め込み」し、それをベクトルデータベースに保存します。クエリが入力されると、それも同様にベクトルに埋め込みます。ベクトル空間内でクエリに最も近いドキュメントが、関連性の高い情報として取得されます。

最近では、PineconeやWeaviateといったベクトルデータベースプロバイダーが注目を集めています。しかし、埋め込みをホストするデータベースそのものよりも、ベクトル埋め込みの品質が課題になることが多い点はあまり議論されていません。

これまで、企業特有のデータで埋め込みエンコーダーをファインチューニングすれば、「一般的な」埋め込みモデル、オープンソースのMPNetやE5、Instructor、クローズドソースのOpenAI、Cohereを上回るマッチング精度を達成できることを実証しました。しかし、このプロセスには、高度なモデル訓練の専門的なナレッジと、継続的に運用するためのインフラが不可欠です。Gleanは過去数年にわたり、この仕組みを着実に構築し、洗練させてきました。

 

しかし、埋め込みが強力である一方で、従来のキーワードベースの手法が完全に不要になるわけではありません。実際には、クラシックな情報検索技術と最新のニューラルネットワークベースのセマンティック埋め込み技術を組み合わせた「ハイブリッド」手法が効果的であることが示されています(Thakur et al. (2021))。ハイブリッド検索とリランキングシステムを調整することは非常に複雑な作業であり、セマンティック類似性、キーワード一致、ドキュメントの新鮮さ、パーソナライズ機能など、数十種類のランキングシグナルを組み合わせて最終的な関連性スコアを生成するためのモデル訓練が必要です。私たちの検索モデルは、各クエリから学習し続け、従業員一人ひとりに最も関連性の高い結果を提供するよう改善を重ねています。

{{richtext-banner-component}}

パーソナライズ機能: 広範なナレッジグラフ

どれだけ優れたテキスト検索システムでも、検索クエリに関連するドキュメントが必ずしもユーザーの質問に答える正確な情報を含んでいるとは限りません。例えば、エンジニアが最新の設計仕様がどこに保管されているかを尋ねた場合、検索結果には関連する数百件のドキュメントやプルリクエスト、メッセージが表示される可能性があります。このようなシナリオがあるため、100万トークンほどの大規模なコンテキストウィンドウを使用しても、検索の関連性が不要になるわけではありません。誤った情報や古い情報が提供されると、言語モデルが間違った回答を生成してしまうからです。

現実には、テキスト以外のデータも数多く存在しますが、密ベクトルメソッドは主にテキストを扱うように設計されています。検索を個々のユーザーに合わせてパーソナライズするために、Gleanは、企業内で生成されるすべての情報を継続的に統合するナレッジグラフを構築しています。このナレッジグラフのノードには次のような要素が含まれます

  • コンテンツ - 個別のドキュメント、メッセージ、チケット、エンティティなど。
  • 従業員 - ID情報や役職、チーム、部門、グループなど
  • アクティビティ - 重要なシグナルやユーザーの行動、共有や利用パターンなど。  
 

このグラフのエッジは、これらのエンティティがどのように相互作用しているかを示しています。

  • ドキュメントのリンク関係 – 他のドキュメントからリンクされている、または他のユーザーによって言及されているドキュメントは、関連性が高い可能性があります(Googleの原点となったPageRank理論)
  • ユーザー同士のやり取り – 同じチームのメンバーが作成したドキュメント、過去にやり取りしたことがある人のドキュメント、または今後会議を予定している人のドキュメントは、自分にとってより関連性が高い可能性があります。
  • ユーザーによるドキュメントの操作 – 自分や自分が属するチームのメンバーが作成、編集、共有、コメントしたドキュメントは、自分にとってより関連性が高い可能性があります。

LLMの統合: 検索機能の強化

LLMは検索結果の要約や統合に役立つだけでなく、検索エクスペリエンス全体を向上させることもできます。たとえば、LLMは高度なクエリプランニングを可能にし、システムが自然言語の指示を解釈して、意図した結果を得るための検索クエリセットに変換することができます。たとえば、以下のような指示が考えられます。

"先月のGlean Chatのコード変更を確認し、改善点のリストを作成してください。#project-glean-chatチャンネルのディスカッションも確認してください。

上記の指示は以下のような2つの検索クエリに変換され、これらの結果を統合することができます。

  • 先月のGithubのプルリクエストで「Glean Chat」に言及しているもの
  • #project-glean-chat Slackチャンネルでプロジェクトの進捗について話しているメッセージ

LLMは、新規顧客向けのドメイン特化型エンコーダーを迅速に構築する際にも役立ちます。実世界の希薄なデータを機械生成の例(Promptagator, InPars)で補完することで、お客様にとって固有のエンコーダーを効率的にトレーニングできます。各顧客データは専用エンコーダーのトレーニングにのみ使用されるため、合成データは大規模なドメイン内データセットの不足を補いながら、顧客特有の言語や用語を保持します。この結果、各顧客のデータに最適化され、より良い汎化性能を発揮するエンタープライズ対応エンコーダーが実現します。

 

生成AIの可能性を、今すぐ最大限に引き出しましょう

エンタープライズ対応のChatGPTシステムを構築するのは容易なことではありません。企業データにLLMを適用するには、新鮮さ、権限管理、説明可能性、破壊的忘却といった重要な要件を満たす必要があります。最近注目を集めているベクトル検索や埋め込み技術ですが、高品質な埋め込みを作成し、それをスケールに対応させるインフラストラクチャを構築すること自体が大きなエンジニアリングの課題です。ほとんどの企業にとって、職場データでLLMの力を引き出す社内ソリューションを開発するには、機械学習、検索、スケーラブルなデータインフラストラクチャに関する高度な専門知識と数年の開発期間が必要です。

Gleanは、ゼロから開発する代わりに、最新の生成AI技術を活用したエンタープライズサーチおよびナレッジマネジメントの即時利用可能なソリューションを提供します。また、Gleanの基盤プラットフォームにより、APIを使用して多くの企業ワークフローに対応するカスタムソリューションを簡単に構築することができます。これにより、内製ソリューションと比較して、コストと複雑さを大幅に削減しながら、生成AIのメリットを最大限に活用できるエンタープライズ実装を実現します。

Gleanを利用すれば、企業は新規事業の拡大やイノベーションといった高度な目標に集中しながら、生成AIの最新技術を活用して成功への道筋を加速させることができます。Gleanがどのようにして企業のデータ価値を最大限に引き出しているかを知りたい方は、今すぐデモにお申し込みください。 手間をかけることなく、業界トップクラスのエンタープライズサーチとAIチャットアシスタンスを通じて、組織のナレッジ活用を大きく進化させることができます。

Related articles

No items found.
エンタープライズサーチ 購入ガイド

エンタープライズサーチ 購入ガイド

Enterprise search solutions have become essential to ensuring employee satisfaction, workflow efficiency, and business success. Discover what features and capabilities to look for when considering the best search solution for you.

エンタープライズサーチ 購入ガイド
Work AI for all.
Get a Demo
CTA Section Background Shape

Work AI for All.

デモを申し込む
Background GraphicBackground Graphic