知湖橋プラットフォームにおける大型モデルの応用と実践

1. 事業の状況及び背景

まずはブリッジプラットフォームを紹介します。

Bridge は、Zhihu 内の運用分析プラットフォームです。主なシナリオには、人物の検索、コンテンツの検索、人物の監視、コンテンツの監視、機会の発見、問題のチェックなどがあります。提供される機能には、スクリーニング、パッケージ化、分析、監視などがあります。

このプロセスでは、どのように大きなモデルと統合するのでしょうか?

Zhihu の事業発展はインスピレーションから始まり、それは外部インスピレーションと内部インスピレーションに分けられます。外部からのインスピレーションは、主にサイト外のニュースから得られます。サイト外のニュースをナレッジシステムに基づいてイベントに集約し、イベントに基づいて質問を生成し、最後に質問に基づいてディスカッションフォーラムを形成します。ディスカッションによって、ユーザーが利用できるサイト内のコンテンツが生成されます。内部のインスピレーションは主にサイト上の既存のコンテンツから得られ、整理、分析、統合、分類されます。これを作業知識システム組織と呼んでいますが、これはブリッジプラットフォームでの大規模モデルの適用の最初の部分でもあります。

2 番目の部分は、Zhihu 内のコンテンツエコロジーの構築についてです。ビッグモデルを使用して、自然言語による推奨システムに基づいてコンテンツエコロジーをマクロ制御します。

3 番目の部分では、大規模なモデルを使用して自然言語でデータを分析するビジネス分析に焦点を当てます。

上記は、ブリッジプラットフォーム上の大規模モデルの適用シナリオです。これら 3 つのシナリオは、ビジネスとテクノロジーの両面でユニークかつ代表的なものです。

2. 知識体系の分類と整理

以下では、最初のシナリオである知識体系の分類と組織化について詳しく紹介します。

このシナリオには 2 つのビジネスフォームがあります。1 つ目はイベント集約です。従来のアプローチでは、外部のニュースソースからニュースを取得し、クラスタリングアルゴリズムを使用して集約し、クラスタリング結果に基づいて手動で新しいイベントを追加し、適切な角度を選択してイベントに基づく質問を作成し、多角的な議論を促します。 2 つ目は、コンテンツを沈殿させることです。対応する多段階の分類ツリーと対応するコンテンツを再編成し、既存の知識を構造化し、沈殿したコンテンツがさらに議論を喚起できるようにする必要があります。

大規模なモデルを使用して上記の 2 つのビジネスニーズを解決する際に、クラスタリング精度、最大トークン、プロセスの複雑さなど、多くの問題が発生しました。

上の図は、ビッグモデルに基づいて設計したイベント集約プロセスを示しています。これは 4 つの段階に分かれています。

ニュースは重要な情報を抽出し、それをベクトルに処理します。
クラスタリングが不可能になるまで、高精度のクラスタリングが複数回実行されます。この段階での大規模モデルの役割は、ノードの下のニュースまたはイベントに名前を付けることです。
高レベルのクラスタリングを 1 回実行した後、大規模モデルを使用して、クラスタリングノード内のイベントが同じかどうかを判断します。同じ場合は、マージされます。
イベント→ニュースの最終結果を生成し、ビジネス側に配信して利用します。

ニュースの階層的クラスタリングを、ビッグモデルによって生成されたイベントの階層的クラスタリングに置き換えると、クラスタリングできないケースが効果的に解決されます。また、クラスタ化されたニュースまたはイベントが実際に同じイベントであるかどうかをビッグモデルに判断させ、その結果に基づいて対応する対策を講じると、過剰集約のケースが効果的に解決されます。

ノード下のコンテンツは階層的クラスタリングによってグループ化されているため、大規模モデルに入力されるプロンプトは比較的小さく、最大トークン問題も効果的に解決されます。

大規模なモデルに基づいてタスクプロセス全体を完了するのは比較的難しいため、このタスク用に MapReduce のようなソリューションを設計および開発し、複雑なプロセスの問題も効果的に解決しました。

この新しいソリューションには次の利点があります。

イベント名は、手動による介入なしに自動的に生成できます。
精度の向上。

知識組織化については、大きなモデルに基づいて上図のようなプロセスを構築しました。全体的なプロセスは、おおよそ次のステップに分けられます。

プロンプトが最大トークンを超えないようにコンテンツを分割します。
マップフェーズ: コンテンツグループごとにカテゴリ名を生成します。
削減フェーズ: カテゴリ名は、マージできなくなるまでペアでマージされます。
結果はファイルに書き込まれ、group by ステートメントの数に基づいて、初期段階から再帰的に実行するかどうかを決定し、最終的にすべてのファイルを 1 つの結果ファイルにマージします。

このプロセスでは、いくつかの問題にも遭遇します。具体的な解決策は次のとおりです。

最大トークンをバイパス: 最初にコンテンツを最大トークンに従って分割してカテゴリを形成し、次にカテゴリを結合します。
大量のコンテンツを迅速に処理します。タスクを MapReduce ノードに抽象化し、同じステージ上のノードを同時に実行して並列処理を確保します。
大規模モデルの速度制限: MapReduce タスクは共通タスクであり、タスクのスケジュールキューにはクラスター統合の速度制限が実装されています。

最終的なビジネス効果は上図に示されています。この新しいプロセスの利点は、コストが低く、人間の介入が不要で、完全に自動化されていることです。欠点もまた明らかで、基本モデル自体のコンテンツ理解に大きく依存する点です。

3. 自然言語をスクリーニング条件に変換する

次に、自然言語をフィルタリング条件に変換する部分を紹介します。この部分は、主にパッケージング、人物の検索、コンテンツの検索のシナリオを対象としています。

私たちのビジネスでは、ビジネスマンは条件に基づいてユーザーやコンテンツを見つける必要があります。このようなタスクには次のような特徴があります。

審査基準は多数あります。
さまざまな条件の間には多くの論理的な組み合わせがあります。

上記の特性に基づいて、タスクを完了するために大規模モデルの微調整方法を使用することを選択しました。当初は、純粋な PE 方式で実装しようとしましたが、この方法は単純ですが、ビジネスニーズを十分に満たすことができませんでした。私たちが構築した微調整データは、上図の右半分の表に示されています。モデルに入力した質問と回答のペアは、それぞれ表のコンテンツ列と結果列です。データ構築に関しては、次のようなアイデアがあります。

フェーズ 1: アトミック条件に基づいてフィルタリング条件を構築します。
ステージ 2: 原子条件の交差と差を完成させて、スクリーニング条件を構築します。
ステージ 3: ファジーステートメントを使用してスクリーニング条件を構築します。
ステージ 4: 明らかな論理エラーのあるフィルター条件の構築。

このタスクを完了するプロセスは、大きく分けて 2 つの段階に分けられます。最初の段階では、3 つのバージョンを繰り返しました。

バージョン 1 では、出力と入力が互いに関係がないという問題が発生しました。主な理由は、基本モデルの論理的能力の欠如です。コードと数学の問題をモデルに入力してトレーニングすることで、この問題を効果的に解決しました。

バージョン 2 では 2 つの問題が発生しました。 1 つ目は JSON 切り捨ての問題です。主な原因は最大トークン制限です。最大トークンを増やすことで、この問題を効果的に解決しました。2 つ目は出力の重複の問題です。主な原因は、一定の確率を入力した後、同じ単語の確率が常に最も高くなることです。この問題を効果的に解決するために、ランダムサンプルを使用しました。

バージョン 3 では、主に次の問題を解決しました。

JSON 形式が正しくありません。多数の JSON サンプルを作成しました。
追加の条件が存在する場合、条件のランダムな組み合わせを使用してサンプルを構築しようとします。
より大きいまたはより小さい記号が間違っています。スクリーニング条件を使用して、より大きいまたはより小さいさまざまなサンプルをランダムに生成します。
おそらくそれは誤解ではないのですが、スクリーニング条件をランダムに組み合わせてサンプルのバッチを構築しようとしています。
時間間隔は瞬間として理解され、複数の時間ベースのフィルタリング条件を使用してサンプルのバッチを構築しようとします。
条件が部分的に欠落していたため、条件をランダムに組み合わせてサンプルを作成しようとしました。

トレーニングの過程で、トレーニング速度の問題が発生しました。エポックを短縮し、この問題をある程度解決しました。

最初の段階の反復作業の後、基本的にはオンラインで利用できるようにできましたが、非常に矛盾した問題に遭遇しました。トレーニングと推奨を同じマシンで実行する必要がありました。マシン間に違いがあると、例外が発生してしまいます。第 2 フェーズでは、まだいくつかの最適化の方向性が残っています。 1 つ目は、あいまいな質問の構築です。大規模モデルをテストするには、「高品質の作成者が作成した高品質の大規模モデル回答コンテンツ」のような一連の質問を構築する必要があります。次に、実際のユーザーの使用状況でケースをターゲットに解決し、ユーザーからの実際のフィードバックに基づいて微調整するための対応するサンプルを生成する必要があります。

上記はオンライン化後の効果ですが、主なポイントは3つあります。

使用コストが削減され、ユーザーの使用率が向上し、全体的な作業効率が向上します。
使いやすいです。多くの新入生が自然言語処理を使用してこの機能の使い方を習得し、プロモーションのコストを削減します。
新しいラベルや新機能を宣伝する従来の方法は変わりました。新しいラベルがリリースされると、さまざまなビジネス関係者へのアナウンスが新しいラベルへの自動翻訳に変わり、コミュニケーションの効率が向上し、コラボレーションコストが削減されます。

この方向で最適化すべき点はファジー言語であり、この方向ではまだ探求を続ける必要があります。

4. 自然言語データ分析

最後の部分では、主に AdHoc 分析に焦点を当てた自然言語データ分析について説明します。

このタスクは主に次のような困難と課題に直面します。

現在のシナリオにおいて、常に変化する自然言語を適切な SQL に変換するにはどうすればよいでしょうか。
ユーザーによる自然言語入力と可能な限り互換性を持たせるにはどうすればよいでしょうか?
現在の事業を担当する学生に、現在の事業の成果をしっかり見てもらえるようにするにはどうすればいいでしょうか？

この問題を解決するために動的プロンプトを使用します。当初は純粋なプロンプト方式を使用していましたが、この方式はビジネスニーズを十分に満たしていませんでした。主な理由は、広告テーブルが広すぎて最大トークン制限を超えてしまうことでした。さらに、いくつかのショットでは常にクエリステートメントが無視され、効果が悪かったです。微調整も試みましたが、この方法ではサンプルに対する要件が高く、微調整に使用したサンプルは非常に困難でした。最終的に、問題を解決するために動的プロンプトを使用することにしました。主なプロセスは次のとおりです。

初期化:サンプルを質問、クエリフィールド、SQL ステートメントに処理し、質問を埋め込みに変換して FAISS に保存します。

ユーザークエリは次の手順で実行されます。

質問を埋め込みに変換し、MMRを通じて上位10の類似質問を見つける
最大トークン制限を考慮して適切なプロンプトを生成します。
緑: 重複排除後の列名
水色: クエリの例
濃い青: このユーザーの質問

上記はオンライン化後の業績です。もちろん、多くの問題に遭遇しましたが、さまざまな方法を試して最終的に解決しました。

初期にはコサイン類似度が使用されていましたが、類似サンプルが多すぎて効果は良くありませんでした。

解決策:多様性によるプロンプト入力の不足を回避するために MMR を使用します。

クエリをデータソースにできるだけ密接に関連付けるにはどうすればよいでしょうか?

解決策: 製品ソリューションを使用して、ユーザーがクエリに必要なデータソースを選択できるようにします。

ユーザーによる自然言語入力は非常に一般的です。この場合、ユーザーのニーズをできるだけ正確に満たすにはどうすればよいでしょうか?

解決策:サンプルを補充し、ユーザーからのフィードバックに基づいて最適化します。

現在、このソリューションにはまだいくつかの問題があります。精度が不十分です。分析シナリオはまだ非常に柔軟で変更可能であるため、単純なケースのパフォーマンスは問題ありませんが、複雑になると効果は良くありません。今後は、さまざまなビジネスシナリオでのパフォーマンスをさらに向上させるため、微調整を試みます。