2月末のGPT-3.5のリリースは、インテリジェント時代の到来を告げるものでした。この時代は、企業にかつてない機会と課題をもたらします。情報システムチームは、この大規模AIモデルを最大限に活用し、社内の課題解決と業務効率向上につなげる方法を模索し始めました。同時に、管理部門もGPTの可能性に注目し、日常業務における煩雑で反復的なコミュニケーション課題に対処するためのシステムレベルのカスタマーサービスプラットフォームの構築が可能かどうかについて、私たちと議論を重ねました。その過程で、データ応用チームが既にプライベートドメイン知識ベースプラットフォームを構築していることに気づきました。このプラットフォームは、大規模モデルへの接続、テキストベクトル変換、検索などの機能を備えています。そこで、データ応用チームとの綿密な議論を通じて、プライベートドメイン知識ベースアプローチを用いて、住宅購入ビジネスを基盤としたカスタマーサービスシステムを実装できると確信しました。このシステムは、標準的なカスタマーサービスを提供し、ユーザーがビジネスニーズに合わせて独自のコーパスをカスタマイズできるAI応用プラットフォームへと迅速にアップグレードできます。 R&D チームによる議論の結果、システム展開の全体的なタイムラインは次のようになりました。実装プロセス全体は二つの並行したラインに沿って進められました。製品ラインはプライベート知識ベースの構築と質疑応答パフォーマンスの最適化を主導し、技術ラインは大規模モデルプラットフォームの開発に注力しました。各ラインの進捗状況は以下のとおりです。プライベートドメイン知識ベースの構築とパフォーマンスの最適化
2.1.1プライベートドメイン知識ベース - コーパスの準備
GPTシリーズ、Wenxin Yiyan、Xunfei Xinghuoなど、私たちが日常的に使用する大規模モデルは、自然言語を理解し生成するように設計されています。これらのモデルの注目すべき点は、膨大な量のテキスト情報を分析・学習することで、入力に関連した新しいテキストを生成できることです。この自動テキスト生成機能により、GPTモデルは複雑な問題の解析、レポートの自動生成、顧客サービスの最適化に優れています。しかし、社内の企業アプリケーションの場合、各企業独自のプロセスやシステムを大規模モデルに組み込んで、ターゲットを絞ったトレーニングを行うことはできません。自社開発または非公開で展開した大規模モデルであっても、企業の知識ベース内のテキスト量は、大規模モデルのトレーニングに使用されるデータの量と比較してごくわずかであるため、トレーニングだけでモデルの応答パフォーマンスに直接影響を与えることは不可能です。これらの問題に対処するために、プライベート ドメイン ナレッジ ベースが登場しました。プライベート ドメイン ナレッジ ベースの基本原理は、企業内の質疑応答コーパス、ポリシー、専門文書、その他の情報を埋め込み、ベクトル化し、ローカル データベースに保存することです。ユーザーが質問すると、埋め込みモデルによってユーザーの質問もベクトル化されます。次に、知識ベース内のベクトルと質問から変換されたベクトル (通常はコサイン関数を使用) 間の角度を測定することで、コサイン類似度が計算されます。リコール戦略により、類似度が P を超える上位 N 件の結果が、この質疑応答セッションのコーパスとして使用されます。これとコンテキスト ロール設定 (プロンプト語) を組み合わせることで完全なプロンプトが形成され、その後、要約と応答のためにより大きなモデルにプッシュされます。大規模モデルとプライベートナレッジベースを組み合わせることで、企業はドメイン特化型のAIアシスタントを構築し、企業運営に関する様々な質問に答えたり、従業員のニーズに基づいたレポートを生成したりすることができます。このアプローチは、業務効率を向上させるだけでなく、従業員が企業リソースをより深く理解し、活用するのを支援します。では、知識ベースコーパスを準備する際にはどのような点に注意すべきでしょうか？既存のプロジェクトでの経験に基づくと、埋め込みモデル自体には次のような特徴があります。 1.ベクトル化後の「出産」と「子育て」の類似度が0.8以上になるなど、意味を理解できます。 2. 類似度は単語数と関連しています。例えば、文書の単語数が多すぎると、質問との類似度は低下します。 3. 全く無関係な2つの文が、高い類似性を示す場合があり、これが通常の反応に影響を与えることがあります。これは、類似性アルゴリズムの基本原理が数学的ベクトル間の角度にあるためです。異なるコーパス間でベクトルを変換する際に、類似性が見られる場合があります。これは、大規模モデルの学習に使用されたコーパスの構文と意味論にも深く関連しており、アプリケーションユーザーである私たちが直接解決できるものではありません。 「年次休暇」と質問すると、年次休暇とは関係のないコーパスも結果に含まれ、類似度は0.7以上になります。
前述の問題と特性に対処するために、次の方法でコーパス データの準備を最適化できます。
1. 限られた文字数の中で、出産、育児休暇、授乳休暇などの関連用語を使って、できるだけ多くの角度から質問を記述するなど、質問と回答を重複して記述することで、類似度を計算する際に回答がより優先的に思い出されるようになります。ただし、単語を使いすぎると類似度スコアも下がってしまうので注意が必要です。 2. 大規模モデルにおいてよくある「重大なナンセンス」という問題に対処するため、回答したくない質問がある場合、それらの質問のコーパスを用意し、回答に「この質問は回答しにくいです」や「申し訳ありませんが、この種の質問についてはXXXにご相談ください」といった内容を記述することができます。こうすることで、ユーザーがそのような質問をした際に、知識ベース内のコーパスに基づいてより理想的な回答が返されるようになります。 3. 長すぎる文書やテキストに対しては、2つの解決策があります。1つは、再帰的な文字テキスト分割、例えば500文字ごとにブロックに分割する方法です。ただし、この分割では、完全な文が2つのブロックに分割されます。そのため、分割時に繰り返し文字数の設定も追加します。例えば、繰り返し文字が100文字ある場合、分割時に1～500文字が最初のブロック、400～900文字が2番目のブロックになります。これにより、文や完全な導入部分が2つのコンテンツブロックに分割されるのを防ぐことができます。2つ目は手動分割で、コンテンツ全体を実際の意味に基づいて2つのブロックに分割します。 4. 専門用語のみの使用は避け、専門用語には対応する口語的な説明を添えてください。これは、質問をするユーザーの多くは専門用語に精通しておらず、質問内容はより口語的になる傾向があるためです。コーパスに対応する口語的な説明がない場合、再現率は不十分になる可能性があります。 テキスト分割の例図
2.1.2 トレーニング？プロンプトチューニング
プライベートナレッジベースの準備が完了したら、トレーニングと最適化のプロセスを開始できます。現在のアプリケーションのビジネスシナリオでは、大規模なモデルに基本的なロール設定（プロンプトワードと呼ばれることもあります）、パラメータ設定、プライベートナレッジコーパス、過去のチャット内容、その他の情報を与える必要があります。これらを組み合わせることで、完全なプロンプトが作成されます。ロール設定とは、モデルが出力を生成する前に、特定のテキストプロンプトやガイド情報をモデルに提供することを指します。これにより、モデルは入力データをより適切に理解し、期待される出力を生成できるようになります。ロール設定は、特定のタスクやデータセットに応じてカスタマイズでき、モデルのパフォーマンスと精度を向上させることができます。 1. 基本的な役割情報を設定し、実行できないことや実行する必要があることなどの要件を指定します。 2. 回答を直接提供する：シナリオによっては、モデルに期待される回答を直接提供できます。例えば、利用可能な情報の範囲外の質問をされた場合、「申し訳ありませんが、わかりません」という回答が考えられます。 3. 関連する知識情報の提供：テキスト生成シナリオでは、記事のトピック、重要なキーワード、関連する背景知識などのコンテキスト情報をモデルに提供することで、モデルが入力データをより深く理解し、高品質な出力を生成できるようになります。質問応答シナリオでは、これはプライベートナレッジベースから取得されたコンテンツとプラグインによって返されるコンテンツに相当します（詳細は以下のプラグインのセクションをご覧ください）。 4. 過去のチャット内容: これは通常、複数ターンのダイアログ シナリオで使用され、大規模なモデルがチャットのコンテキストを理解して、現在のユーザーの質問を完了し、より適切な回答を提供できるようにします。 5. 温度、最大トークン数、ペナルティ係数、その他の一般的に使用される GPT パラメータなどの基本パラメータ設定。 プロンプトワードの設定例
プライベート データベースを対象としたトレーニングを実施するには、次の手順に従う必要があります。
1. 基本的なキャラクター設定とパラメータ構成を定義します。 2. テストの質問をして、その回答を評価することから始めます。 1) 再現率は正確か？理想的な知識ベースコーパスは正確に再現されているか？ここで注目すべきは、設定した再現率と最小再現率スコアです。対象コーパスのランキングが低く、再現率が得られない場合は、コーパス内の文言を調整して類似度を可能な限り高めるか、上位コーパスの類似度を下げる必要があります。類似度スコアが低いことが再現率の低さの原因である場合は、コーパス内の文言を最適化して類似度スコアを向上させる必要があります。 2) 想起は正確でしたが、大規模モデルは理解と回答が不十分でした。役割設定の中でニーズをより明確に記述するか、関連する知識ポイントやサンプルデータなどを提供する必要があります。大規模モデルは創造よりも模倣に優れています。 3 ) 大規模モデルは自由度が高すぎて、すべきでないことを言っていました。キャラクター設定の要件を強調し、どのように対応すべきかの例を示します。GPT温度パラメータを下げて、自由度を減らします。 4. 最適化後、以前の悪いケースを繰り返して、効果が期待どおりになるまで検証します。 リコール戦略設定例
2.1.3 プラグインの反復と拡張
大規模モデルの使用経験から、事前学習済みコーパスとプライベート知識ベースはどちらも、過去のデータに基づく静的な情報であることがわかりました。そのため、大規模モデルでは「今日の天気はどうですか？」や「経費報告書は誰が承認しましたか？」といったリアルタイムの質問に答えることが困難です。ニーズがあれば、解決策があります。現在、市場で主流となっている大規模モデルのほとんどは、プラグインモデルをサポートしています。いわゆるプラグインモードでは、特定のシナリオに対応するシステムインターフェースを開発します。ユーザーが関連する質問をすると、大規模モデル（分かりやすくするために、人と考えることができます）が特定のインターフェースを呼び出すかどうかを判断します。プラグインは、大規模モデルが自然音声をインターフェースが認識できる形式（JSONなど）に変換し、インターフェースから返される様々なパラメータを自然言語に連結するように設定および記述する必要があります。その後、大規模モデル（ここでは、プラグインを呼び出した人とは全く異なる設定を持つ第二の人と考えることができます）にプロンプトが与えられ、質問を要約して回答します。 プラグインの文字設定例
プラグインモデルを通じて、より多くのシナリオで問題を解決できます。最も効果的なプラグインは、検索エンジンに接続し、リアルタイムの検索結果を大規模モデルを用いてより実用的な知識ポイントに要約するものです。Baiduの「文心一言」機能の前回のリリースでは、優れた応用シナリオが披露されました。例えば、大規模モデルは旅行計画の作成に役立ちます。まずオンラインでガイドを検索し、要件、交通手段、時間に基づいて要約・分類し、パーソナライズされた旅行プランを作成します。非常に実用的です。企業内では、主に社内システムドキュメントの照会やシステムプロセス（スケジュール作成、経費精算、休暇申請など）の合理化に活用しています。プラグインモデルに加えて、大規模モデル技術を逆方向に応用し、業務システムに組み込むことも可能です。例えば、採用業務において、採用担当者が履歴書を開くと、システムは大規模モデルインターフェースを呼び出し、履歴書と職務内容の一致度を自動的に分析し、分析結果と面接の提案を提供します。このようなアプリケーションは、既存の業務ワークフローを変更することなく、従来の業務プロセスに欠けているインテリジェントな分析機能を強化・補完することができます。もちろん、ナレッジベースとプロンプトを最適化するために最善を尽くしたにもかかわらず、予期せぬ状況が数多く発生しました。例えば、アシスタントにジョークを言わせたくないという状況もありました。設定では、ユーザーは購買アシスタントであり、購買関連の質問にしか答えられないとされていました。ジョークを言ってほしいと尋ねると、大型モデルは「私は購買アシスタントなので、ジョークは言えませんが、購買担当者に関するジョークなら言えます」と答えました。大型モデルを「出し抜く」過程で、私たちは共に成長していきました。技術ラインは、大規模なモデルプラットフォームの構築を推進します。
プロジェクト開発の過程で、プライベートナレッジベースは優れた統合メカニズムとドキュメントを提供していましたが、実際のビジネス統合には依然として多大な開発リソースが必要であることを認識しました。さらに、新しいビジネスラインの統合には、高い開発コストと、反復的なコミュニケーションと学習曲線が伴いました。そこで、開発チームは綿密な議論を経て、共通機能をプラットフォームにカプセル化するという新しいビジネス統合モデルを提案しました。これにより、社内の新規事業の統合コストをほぼゼロ、あるいは開発コストゼロにまで削減できます。この取り組みは、ビジネスレベルでのインテリジェントAIの適用と推進を加速させるのに役立ちます。データアプリケーションチームとクラウドプラットフォームチームとの綿密な議論を経て、私たちは大規模なモデルプラットフォームを構築するというコンセプトを提案しました。その主要コンポーネントは次のとおりです。
1. クラウドプラットフォームチームは、ネイティブAPI統合とインフラストラクチャサポートの提供を担当します。これには、ChatGpt、Wenxin Yiyan、Keda Xinghuo、Tongyi Qianwenといった大規模モデルを含む、様々なベンダーや企業との統合が含まれます。この統合により、プラットフォームは多様なビジネスニーズに対応できる幅広い機能を備えています。
2. データアプリケーションチームは、システム全体の中核となるプライベートナレッジベースの構築を担当します。また、プラグインの登録、プロンプトの設定、言語ベクトルの取得、パラメータの調整といった機能も担当します。これらの機能は、システムがユーザーのニーズをより深く理解し、パーソナライズされた応答を提供するのに役立ちます。
3. 情報システムおよびフロントエンドチームは、ビジネスサイドの機能のカプセル化を担当します。統一されたアクセスセキュリティポリシーの作成、フロントエンドセッションサービスとユーザーインタラクションの処理、バックエンド管理機能の提供を担当します。これにより、システムの安定性、セキュリティ、そしてビジネス統合における使いやすさが確保されます。
チーム間の連携は、冗長な開発作業の削減、統合・習熟コストの削減、そしてビジネス統合の効率向上に役立ちます。全体として、このコンセプトは、ビジネスレベルでのインテリジェントAIアプリケーションの導入を加速し、将来のビジネス拡大のための柔軟性と拡張性を提供することが期待されます。
システムコンセプトの全体的なアーキテクチャは次のとおりです。
このプレゼンテーションでは、主にプラットフォーム層の設計と成果について紹介します。プラットフォーム層の設計は、以下の4つの点に重点を置いています。
2.2.1 ビジネス統合開発コストを削減し、迅速なビジネス展開をサポートする:
この目標を達成するために、さまざまなニーズを満たす 2 つのアクセス オプションを提供しています。
2.2.1.1 直接フロントエンド統合:
これは、ビジネス統合プロセスを簡素化するソリューションです。ビジネスシステムに特別な要件がない場合は、適切なスクリプトをインポートして設定するだけで十分です。このアプローチは、様々なフロントエンドテクノロジースタックとの互換性を確保する必要があるため、開発時にはネイティブJavaScriptを使用することで互換性を確保しています。このスクリプトは、カスタマイズ可能なフローティングチャットアシスタントボタンを提供します。ユーザーはボタンをクリックするだけでチャットアシスタントコンテナを表示でき、ボタンを自由にドラッグして位置を変更できます。チャットアシスタントコンテナは、埋め込まれたiframeを介して特定のURLを読み込み、チャットアシスタントコンテンツを表示します。
チャット アシスタントが埋め込まれた iframe を作成し、そのスタイルとソース URL を設定します。
ページにチャット アシスタント コンテナーとボタンを追加します。
フローティング ボタンにクリック イベントを追加して、クリックするとチャット アシスタント コンテナーが表示されるようにします。
フローティング ボタンにドラッグ イベントを追加して、ユーザーがボタンの位置をドラッグできるようにします。
ビジネスシステムアクセスコード
ご覧のとおり、各業務システムが共通のフロントエンド アクセス メソッドを使用している場合は、スクリプトをインポートして業務ライン ID を提供するだけで、ほぼコストをかけずに簡単にアクセスして使用できます。
2.2.1.2 バックエンド統合:
様々なビジネスシナリオの具体的な要件を考慮し、フロントエンドのカスタマイズが必要な特殊なケースでは、バックエンドAPIアクセスメソッドを直接提供することで、特別なニーズに対応します。そのため、ビジネスプラットフォームは、セッションサービス、チャットサポート、バックエンド管理データ統合などの機能を網羅し、ビジネスニーズを満たす3つの主要カテゴリと11のサブカテゴリの機能インターフェースを提供しています。
WebSocket 経由でバックエンド セッション サービスに接続するフロントエンドの例:
フロントエンドはセッションを開始し、WebSocketを使用してバックエンドサービスに直接アクセスします。ここで、businessLineIdはビジネスラインを表し、encryptedDataは暗号化されたチケット情報を表します（その目的は後述します）。
2.2.2 ビジネス統合プロセスのセキュリティを確保する。
システムのセキュリティを確保するために、以下の対策を導入しています。 2.2.2.1 トークン検証メカニズム:
これにより、許可されたユーザーのみがシステムリソースにアクセスできるようになります。この目的のため、将来的には以下の2種類の業務システムがプラットフォームに統合される予定です。まず、社内イントラネットのオフィスシステムについては、これらのシステムはすべてSSOログインプラットフォームに接続されているという共通点があります。そのため、アクセスの容易さを考慮すると、業務システムから暗号化された認証情報を送信してもらう必要はありません。代わりに、SSOプラットフォームに直接接続してID情報を取得し、その認証情報をCookieに書き込むことでリンクの正当性を確保しています。主な実装は以下のとおりです。 01. SSOプラットフォームに直接接続して現在のユーザー情報を取得する02. リクエストを暗号化されたチケットに変換し、Cookie に書き込み、各リクエストの正当性を確認します。フロントエンドシステムとの統合を簡素化するため、Cookieベースの認証方式を採用しました。これは、バックエンドでCookieを解析し、リクエストごとにその有効性を検証するものです。しかし、このアプローチには問題があります。統合する業務システムのルートドメインとiframe組み込みミドルウェアアシスタントのルートドメインが一致している必要があるのです。一致していないと、ドメイン間のCookieの読み取りと書き込みに問題が発生します。また、これはフロントエンド業務システムの統合コストを増加させます。そこで、corpautohome.comとautohome.com.cnというルートドメインを持つ2つのスクリプトインポートパスを直接提供します。各業務システムは、それぞれのドメインに応じて、異なるパスからスクリプトを直接インポートできます。すべての適応作業はプラットフォームによって処理され、業務システム側では一切考慮する必要はありません。 2 つのドメイン パス インポート ファイルが提供されます。コンポーネントのレンダリング中に異なるリクエストパスを挿入します。バックエンドはデータを処理し、異なるドメインの Cookie に書き込みます。
次に、外部システム、またはSSOプラットフォームに接続されていないシステムについては、外部システムは合意された暗号化標準に従って暗号化認証インターフェースを開発する必要があります。初期化時に暗号化資格情報が提供されます。その後、プラットフォームは暗号化資格情報の有効性を検証します。検証が成功すると、暗号化チケットが作成され、Cookieに保存され、リンクの正当性が保証されます。
01. フロントエンドビジネスシステムとの暗号化された統合の例:ビジネス システム バックエンド: 合意されたビジネス ライン ID とキーを取得した後、ビジネス システムは暗号化されたテキスト生成プログラムを開発します。ビジネス システム フロントエンド: スクリプトをインポートした後、ページはインターフェイス パラメータを初期化します。プラットフォーム側：注入された暗号文の正当性を検証します。正当であれば、暗号化されたチケットを生成し、最初のアクセス方法と同じ方法でCookieに書き込みます。
2.2.2.2 ブラックリストメカニズム:
このプラットフォームは対話型サービスを提供しており、クライアント側のスクランブルなどの潜在的なリスクを防ぐため、IPブラックリストを設定する機能を提供しています。アクセスログから関連するリスク情報を確認し、リスクが特定された場合は、直ちに該当のIPアドレスをブラックリストに追加してアクセスをブロックできます。
プラットフォームは、システム ログを表示したり、ブラックリストに項目を追加したりするためのインターフェイスを提供します。
ユーザーが通信接続を確立するときに、その IP アドレスがブラックリストに登録されているかどうかを確認し、登録されている場合は接続の確立を拒否します。
2.2.3 制御性と安定性:
システムの制御性と安定性を向上させるため、フロントエンドとバックエンドの通信に WebSocket を採用し、接続の確立、接続の中断、ユーザーの強制オフライン化など、オンラインユーザーの制御には Redis を使用しました。 1. WebSocket チャネルを確立し、構成クラスをカスタマイズし、後続のユーザー認証のためにすべての要求属性をコピーします。 4. レート制限制御：将来、複数の業務ラインが社内外のネットワークからネットワークにアクセスする可能性を考慮し、また、導入可能なコンテナインスタンス数が限られていることを踏まえ、一部の業務ラインが強制的にリフレッシュされ、全体のパフォーマンスリスクに影響を与えることを防ぐため、プラットフォーム構築時に業務ラインに対するレート制限対策を追加しました。具体的には、メッセージチャネルを確立する際に、チャネルを確立しているインスタンス数をカウントし、インスタンスがオフラインになったり、ハートビート検出に失敗したりすると、カウント数を減らします。新しい接続が確立されるたびに、現在のライブインスタンス数が上限に達しているかどうかを確認します。 5. リアルタイムオフライン機能：システムの問題をタイムリーに処理し、異常な状況によるサービス中断のリスクを軽減するために、リアルタイムオフライン機能が導入されています。
バックエンドは、オンラインのユーザーインスタンスをRedisから直接削除します。フロントエンドがWebSocket通信を開始すると、フロントエンドはセッションを再開します。現在のユーザーがRedisから離れると、セッションは終了します。コードについては、前述のユーザーオフライン関数を参照してください。
2.2.4 一般的な機能とパーソナライズされた設定:
さまざまなビジネス ラインの多様なニーズを満たすために、豊富な構成機能と統合されたデータ監視および管理機能を提供します。
2.2.4.1 事業ラインの構成:
アイコン構成、ウェルカム メッセージ構成、および表示構成が含まれます。さまざまなビジネスやブランド アイデンティティのニーズに合わせて、アイコン、ウェルカム メッセージ、および表示方法のカスタマイズされた構成オプションを提供します。
2.2.4.2 ビジネス向けオフラインナレッジベースの構成:
これにより、同じ事業ライン内の異なる機能を切り替えて統一的に表示できるようになります。
2.2.4.3 リアルタイムデータ統計:
リアルタイム統計機能を導入すると、ビジネス ユーザーはシステム パフォーマンスを監視および最適化して、意思決定をサポートできるようになります。 これらの包括的な対策は、ビジネスアクセスプラットフォームの構築を全面的に支援し、システムの可用性、セキュリティ、柔軟性を向上させ、迅速なビジネス展開を促進することを目的としています。同時に、これらの機能の導入により、プラットフォームは一般的な要件と個別のビジネス構成の両方に対応できるようになります。
アプリケーション統合: 大規模モデル プラットフォームに基づいて、APP と PC の両方のコンポーネントを迅速に構築し、Haocai Assistant、Employee Assistant、Cangjie 大規模モデル アプリケーション、サプライヤー ポータルなどのビジネス向けのインテリジェント アプリケーションをサポートします。
今後、人工知能技術の継続的な発展に伴い、プライベートドメイン知識ベースと大規模モデルプラットフォームは、企業のインテリジェント変革を支える重要な基盤となるでしょう。これらの技術をさまざまな業務分野に適用することで、業務効率の向上、インテリジェントな意思決定能力の強化、そして従業員と顧客のより良いサービス体験の提供が可能になります。同時に、大規模モデル技術の進化に伴い、より多くの機能をアップグレードし、さまざまな業務ラインの具体的なニーズに対応できるようになります。プラグインモデルの普及により、大規模モデルの柔軟性が向上し、より複雑なシナリオや問題に対応できるようになります。つまり、プライベートドメイン知識ベースと大規模モデルプラットフォームは、エンタープライズインテリジェンスの未来の潮流を象徴しており、[会社名]にさらなる機会と競争優位性をもたらし、ビジネスの継続的な革新と発展に貢献するでしょう。
