|
この記事はコミュニティユーザーによって投稿されました。KAGをご利用の方は、コミュニティのエッセイコンテスト（賞金付き）にぜひご参加ください。 著者：張延波（チャン・ヤンボ）。現在、Dark Matter Intelligence Technology (Guangzhou) Co., Ltd.のシニアNLPアルゴリズム研究者。自然言語処理アルゴリズムの分野で6年以上の経験を持ち、インテリジェント対話システム、音声アシスタント、そして信頼できるインテリジェントエージェント技術のアルゴリズムの研究開発を専門としています。以前は、グループチャットロボット「Wang Er Gou」のアルゴリズム開発や、モバイル音声アシスタント「Transsion」の自然言語理解（NLU）および対話システムの研究開発とシステム設計を主導しました。現在は、主に信頼できるアライメントモデルアルゴリズム、そしてAgenticRAGやGraphRAGなどの信頼できるインテリジェントエージェントアルゴリズムの研究開発と革新的な応用に注力しています。 導入検索強化型生成（RAG）技術は、ドメインアプリケーションと大規模モデルの統合を推進してきました。しかし、RAGには、ベクトル類似性と知識推論の関連性の間に大きなギャップがあること、知識ロジック（数値、時間的関係、エキスパートルールなど）への鈍感さといった問題があり、これらはすべて専門的な知識サービスの実装を妨げています。10月24日、OpenSPGはバージョンV0.5をリリースし、知識強化型生成（KAG）に基づく専門的なドメイン知識サービスフレームワークを正式に開始しました。KAGは、知識グラフとベクトル検索の利点を最大限に活用し、大規模言語モデルと知識グラフを以下の4つの側面で双方向に強化することで、RAGの課題に対処することを目指しています。 （１）LLMに適した知識表現 （２）ナレッジグラフと元のテキスト断片間の相互インデックス （３）論理記号に基づくハイブリッド推論エンジン （4）意味的推論に基づく知識アライメント（KAG）は、マルチホップ質問応答タスクにおいてNaiveRAGやHippoRAGなどの方法よりも大幅に優れており、hotpotQAのF1スコアが相対的に19.6％向上し、2wikiのF1スコアが相対的に33.5％向上しました。 Ant Groupでは、電子政府に関する質問応答とeヘルスに関する質問応答という2つの専門的知識に基づく質問応答タスクにKAGを適用し、RAG法と比較して専門性が大幅に向上しました。ユーザーはオープンソースのKAGプログラミングフレームワークを使用することで、独自にドメイングラフを構築し、独自のドメイン知識ベースに基づいて知識に基づく質問応答を実行できます。 KAGフレームワークの紹介KAG フレームワークに慣れる前に、まず KAG フレームワークが重要なコンポーネントである OpenSPG ナレッジ グラフ エンジン全体を理解する必要があります。 KAGフレームワークは、kg-builder、kg-solver、kag-modelの3つの部分で構成されています。今回のリリースでは最初の2つの部分のみをカバーしており、kag-modelは今後のリリースでオープンソースとして公開される予定です。 kg-builderは、大規模言語モデル（LLM）に適した知識表現を実装しています。DIKW（データ、情報、知識、知恵）の階層構造に基づき、SPGの知識表現能力を向上し、同一の知識タイプ（エンティティ型やイベント型など）におけるスキーマ制約付き情報抽出およびスキーマ制約付き専門知識構築に対応しています。また、グラフ構造と生テキストブロック間の相互索引表現をサポートし、推論および質問応答段階における効率的な検索をサポートします。 kg-solverは、計画、推論、検索という3種類の演算子を含む、ロジック駆動型のハイブリッドな解決・推論エンジンを採用しています。このエンジンは、自然言語の問題を、言語と記号を組み合わせた問題解決プロセスに変換します。このプロセスの各ステップでは、完全一致検索、テキスト検索、数値計算、意味推論などの異なる演算子を活用でき、検索、ナレッジグラフ推論、言語推論、数値計算という4つの異なる問題解決プロセスを統合します。 KAG ナレッジ インデックスプライベート ドメインの知識ベースのシナリオでは、非構造化データ、構造化情報、ビジネス エキスパートの経験が共存することがよくあります。KAG は、DIKW 階層構造を参照して、SPG を LLM 対応バージョンにアップグレードします。ニュース、イベント、ログ、書籍などの非構造化データ、トランザクション、統計、承認などの構造化データ、ビジネス経験やドメイン知識などのルールについて、KAG はレイアウト分析、知識抽出、属性の正規化、セマンティック アライメントなどの手法を使用して、生のビジネス データとエキスパート ルールを統合し、統一されたビジネス ナレッジ グラフを作成します。これにより、同じ知識タイプ (エンティティ タイプ、イベント タイプなど) 内で、スキーマ制約のある情報抽出とスキーマ制約のある専門知識構築の両方と互換性を持つようになり、グラフ構造と生のテキスト ブロック間の相互インデックスをサポートします。この相互インデックスにより、グラフベースの転置インデックスの構築が容易になり、論理形式の統一された表現と推論が促進されます。 知識インデックス構築（KAG-Builder）構造化情報取得：KAGは、OpenIEなどの情報抽出技術を用いてテキストからエンティティ、イベント、概念、関係性を抽出し、予備的な知識グラフ（KG）を構築します。この情報はKG内に断片的に保存され、データの構造と検索性を保証します。 知識意味アライメント：意味アライメントは、異なる粒度で知識をアライメントすることで、ノイズを低減し、グラフの接続性を向上させます。KAGは概念意味グラフを通じて知識をアライメントし、KGとテキストフラグメント間の双方向のインデックス作成を可能にします。このプロセスには、インスタンス分類、概念のハイパー/仮説的関係の予測、意味関係の補完、曖昧性解消などのステップが含まれており、知識グラフの意味的識別力とノードの接続性を高めます。 グラフストレージへの書き込み：最後に、構築された知識グラフをストレージシステムに書き込みます。この部分では、KGストレージ（例：Neo4j）とベクトルストレージ（例：Milvus）を使用して、それぞれグラフデータとベクトル情報を保存し、グラフ構造と元のテキストの効率的な統合を実現します。知識インデックス構築のための大規模モデルプロンプトは次のとおりです。 KAG ナレッジクエリ論理形式誘導ハイブリッド推論（KAG-QA） KAGは、ロジック駆動型のハイブリッド問題解決・推論エンジンを提案しています。このエンジンには、計画、推論、検索という3種類の演算子が含まれており、自然言語の問題を言語と記号を組み合わせた問題解決プロセスに変換します。このプロセスの各ステップでは、完全一致検索、テキスト検索、数値計算、意味推論などの異なる演算子を活用でき、検索、知識グラフ推論、言語推論、数値計算という4つの異なる問題解決プロセスを統合します。公式の例を以下に示します。 LFPlanner分析 コードを直接確認する方が明確です。公式ドキュメントでは、問題解決のための `prompt` コマンドメソッドが定義されており、以下の通り、`get_spo`、`count`、`sum`、`sort`、`compare`、`get` の計6つの関数が含まれています。 "instruction": "", "function_description": "functionNameは演算子名です。基本形式はfunctionName(arg_name1=arg_value1,[args_name2=arg_value2, args_name3=arg_value3])です。パラメータは括弧で囲まれ、[]で囲まれたパラメータはオプションパラメータ、[]で囲まれていないパラメータは必須パラメータです。", "function": [
{ "functionName": "get_spo", "function_declaration": "get_spo(s=s_alias:entity_type[entity_name], p=p_alias:edge_type, o=o_alias:entity_type[entity_name], p.edge_type=value)", "description": "SPO情報を取得します。ここで、's'は主語、'o'は目的語を表します。これらは変数名:entity_type[entity_name]として表されます。エンティティ名はオプションのパラメータであり、クエリする特定のエンティティがある場合に指定する必要があります。'p'は述語、つまり関係または属性を表します。これらは変数名:edge_typeまたはattribute_typeとして表されます。各変数には、後続の参照のために変数名が割り当てられます。's'、'p'、および'o'は同じ式内で繰り返して使用できないことに注意してください。変数が上記の変数名である場合、変数名は参照先の変数名と一致している必要があり、変数名のみが一致する必要があります。名前を指定する必要があります。エンティティ タイプは最初に導入されるときにのみ指定されます。
},
{ "functionName": "count", "function_declaration": "count_alias=count(alias)", "description": "ノードの数をカウントします。パラメーターはカウントするノードのセットであり、get_spo に表示される変数名のみを使用できます。変数名としての count_alias は計算結果を表し、int 型のみを使用できます。変数名は、次のテキストで参照として使用できます。"
},
{ "functionName": "sum", "function_declaration": "sum(alias, num1, num2, ...)->sum_alias", "description": "データの合計。パラメータは合計するセットで、数値または上記の変数名を指定できます。その内容は数値である必要があります。'sum_alias'は計算結果を表す変数名として使用され、これも数値である必要があります。変数名は、後続のテキストで参照として使用できます。"
},
{ "functionName": "sort", "function_declaration": "sort(set=alias, orderby=o_alias or count_alias or sum_alias, direction=min or max, limit=N)", "description": "ノードのセットをソートします。`set` はソートするノードのセットを指定し、`get_spo` に表示される変数名のみを使用できます。`orderby` はソート基準を指定します。これはノードの関係または属性名です。前述の場合は、エイリアスが使用されます。`direction` はソート方向を指定し、`min` (昇順) または `max` (降順) のみを使用できます。`limit` は出力制限で、整数型です。これは最終出力結果として使用できます。"
},
{ "functionName": "get", "function_decl:aration": "get(alias)", "description": "指定されたエイリアスによって表される情報を返します。これは、エンティティ、リレーションシップ パス、または get_spo から取得された属性値であり、最終出力として使用できます。"
}
], 従来の方法は通常、文字通りの意味に依存してエンティティを抽出し、小さなモデルを使用してそれらをリンクし、次にパス検索アルゴリズムを使用してヒューリスティック構成を行うのに対し、このアプローチでは、大規模なモデルを使用してステップごとの自動計画（テキスト自体から意味を導出）を行い、エンティティを抽出してテンプレートを生成します。強化された計画機能と要約機能以外に、パイプライン プロセスは従来のオープン ドメイン KBQA と非常によく似ています（ここで言及しているのはオープン ドメイン KBQA であることに注意してください。垂直ドメイン KBQA パイプラインは一般に、よりシンプルで直接的です）。さらに、従来のオープン ドメイン ナレッジ グラフ質問応答システムでは、テンプレートの定義に多大な時間を費やしています。定義が広すぎると取得される情報の冗長性が高くなる可能性があり、定義が狭すぎるとより多くの質問タイプをカバーするのに不十分です。ここで、KAG は上記の 6 つのカテゴリを正式に定義していますが、これは慎重な検討の結果であると私は考えており、理論的にはテンプレート シナリオをさらに細分化することも可能です。 KAGフレームワークのローカルプラクティス公式チュートリアルに従って練習を始めました。 KAG グラフ バックエンド サービスのインストール KAGナレッジグラフバックエンドサービスは、私たちが以前に研究したOpenSPGナレッジグラフ構築フレームワークをベースにしています。これは、大規模モデルの機能を活用して、大規模モデルの時代にナレッジグラフ構築を強化する数少ないオープンソースフレームワークの一つです。まず、OpenSPG-Serverの公式ドキュメントに従ってグラフサーバーをセットアップしました。私はイメージインストール方式を直接使用しました。 パスを指定してディレクトリに移動し、[email protected]:OpenSPG/openspg.git をクローンし、パスを指定してディレクトリ/openspg/dev/release に移動します。次に、docker-compose.yml のポート番号を「6008:8887」に変更し、以下のコマンドを実行します: docker compose -f docker-compose.yml up -d インストール後、画像に示すように、リンク http://183.220.37.57:6008 から表示できます。 KAG開発環境のセットアップ 次に、KAG のインストール手順に従って KAG 開発環境をインストールします。以下を参照してください。 # Python 仮想環境をインストール: conda create -n kag-demo python=3.10 && conda activate kag-demo # コードをクローン: git clone https://github.com/OpenSPG/KAG.git # プロジェクトのルートディレクトリ (./KAG) に移動し、KAG をインストールします: cd ./KAG && pip install -e . # インストールが成功したことを確認します: knext --version knext --help KAG開発環境がセットアップされたので、KAGが提供する公式サンプルを実践できるようになります。次に、いくつかの典型的なアプリケーションシナリオを検討します。 KAG プロジェクトのケーススタディ - hotpotqa (エンティティレス リレーションシップ ナレッジ グラフ スキーマ) 公式の hotpotqa チュートリアルは非常に明確で、手順に従って簡単に設定できます。 # ステップ 1: ケース ディレクトリに入ります cd kag/examples/hotpotqa/ # ステップ 2: プロジェクトの初期化 knext project restore --host_addr http://127.0.0.1:6008 --proj_path . # ステップ 3: 知識モデリング (このステップの後、フロントエンド http://127.0.0.1:6008 でスキーマの効果を確認できます) knext schema commit # ステップ 4: 知識の抽出と構築 (このステップの後、フロントエンド http://127.0.0.1:6008 でさまざまな知識タイプのサンプリングの効果を確認できます) python ./builder/indexer.py # ステップ 5: QA タスクを実行します python ./solver/evaForHotpotqa.py ビルドが完了したら、http://183.220.37.57:6008 を開いてスキーマを確認します。結果は次のとおりです。 注：KAGグラフは、スキーマタイプとタイプ間の関係または属性のみを表示します。特定のエンティティ値とエンティティタイプ、イベントタイプなどの関係は、ページ上で直感的に表示されません。これは、現在主流のナレッジグラフ可視化ツールとは異なります。これは、私が以前に調査した他のナレッジグラフプラットフォームと比較することができます：Graphrag実践 - 上海交通大学シナリオ（パート1）。ナレッジサンプリング効果のさらなる検証は次のとおりです。 質疑応答の結果は次のとおりです。 KAG プロジェクトのケーススタディ - 医療アトラス (エンティティ タイプ関係を含むナレッジ グラフ スキーマ) 医療アトラスの公式チュートリアルは非常に明確で、手順に従って簡単に構築できます。 # ステップ 1: ケース ディレクトリに入ります cd kag/examples/medicine/ # ステップ 2: プロジェクトの初期化 knext project restore --host_addr http://127.0.0.1:6008 --proj_path . # ステップ 3: 知識モデリング (このステップの後、フロントエンド http://127.0.0.1:6008 でスキーマの効果を確認できます) knext schema commit # ステップ 4: 知識の抽出と構築 (このステップの後、フロントエンド http://127.0.0.1:6008 でさまざまな知識タイプのサンプリングの効果を確認できます) python ./builder/indexer.py # ステップ 5: QA タスクを実行します python ./solver/evaForMedicine.py ビルドが完了したら、http://183.220.37.57:6008 を開いてスキーマを確認します。結果は次のとおりです。 知識サンプリングの結果のさらなる検討は次のとおりです。 質疑応答の結果は次のとおりです。 KAG プロジェクトのケーススタディ - ブラックマーケットの調査 (イベント グラフ スキーマ) ブラックマーケットマイニングの公式チュートリアルは非常に明確で、手順に従って設定するだけで済みます。 # ステップ 1: ケース ディレクトリに入ります cd kag/examples/riskmining/ # ステップ 2: プロジェクトの初期化 knext project restore --host_addr http://127.0.0.1:6008 --proj_path . # ステップ 3: 知識モデリング (このステップの後、フロントエンド http://127.0.0.1:6008 でスキーマの効果を確認できます) knext schema commit # ステップ 4: 知識の抽出と構築 (このステップの後、フロントエンド http://127.0.0.1:6008 でさまざまな知識タイプのサンプリングの効果を確認できます) python ./builder/indexer.py # ステップ 5: QA タスクを実行します python ./solver/qa.py ビルドが完了したら、http://183.220.37.57:6008 を開いてスキーマを確認します。結果は次のとおりです。 知識サンプリングの結果のさらなる検討は次のとおりです。 質疑応答の結果は次のとおりです。 KAG-QA 対 マインドサーチ KAG-QAとMindsearchはどちらもプランナーを組み込んでいますが、前者はローカルな知識ベースと知識グラフを取得するのに対し、後者はウェブページを取得します。ここでは2つのステップに分解し、大規模モデルの観点からフローチャートを描いて比較分析を行います（各モジュールは大規模モデル内のノードです）。 解釈：
1.1 決定条件付きループは通常、より柔軟です。問題が解決できない場合は、最初に戻って再計画することができます。これは、Self-RAGパラダイムなどの典型的なマルチエージェントアーキテクチャです。 1.2 決定条件のないループは、実際にはループバックメカニズムを備えていません。つまり、ループを戻さないと理解できます。これらのループは、大規模モデルの計画および統合機能に完全に依存しています（通常、具体的な微調整が必要であり、反復回数は一般的に2～3ラウンド以内に制御できます）。大規模モデルの独立した検索機能を考慮しない場合、これはReactパラダイムに代表されるシングルエージェントアーキテクチャに類似します。 1.3 システムの複雑さの観点から見ると、KAG-QAは明らかにより複雑です。エージェント技術の発展に伴い、マルチエージェントアーキテクチャはますます普及していますが、現時点では実世界での実装は多くありません。ChatGPTの初期バージョンでも同様のアプローチが見られますが、二次的なバックトラッキングや反復処理を必要とする状況は稀です。実際には、複数回の反復処理後の成功率よりも、1回のヒットの成功率を重視しています。そのため、現在の実用的なアプリケーションでは、Mindsearchのソリューションの方が実装の可能性が高く、実世界での実装では、単純な1ステップの計画と要約プロセス、または計画を2～3ラウンド以内に抑えるなど、特定の最適化が一般的に行われています。
さらなる最適化のための提案
リフレクションセクションにバグがあります。サポートチケットが送信されました。 https://github.com/OpenSPG/KAG/issues/70.
1.個人的には、プランニングの最初のステップの結果は前処理できると考えています。並列プランニングの結果が得られた場合には、マインドサーチのように並列実行を行うことができます（例：クリストファー・ノーランとサティッシュ・カラティルはどちらも映画監督ですか？）。結果が順次得られた場合には、元の方法を維持する必要があります。これにより、プロセス効率が向上します。 2. エンティティのリンク部分は最適化できるか、あるいはより小さなモデルで実行できると思われます。 3. 個人的には、計画セクションの 6 つの機能は、悪い事例に基づいてさらに分析、統合、最適化できると感じています。 4. KAG計画は、マルチホップ推論だけでなく、グローバル質問応答（MicrosoftのGraphragに類似）にも使用できます。ただし、一部のグローバル質問はサブ質問にうまく分解できないため、グローバル性はそれほど高くない可能性があります。この部分は、特定のグローバル評価セットで評価できます。Graphragのグローバル質問応答の利点と統合できれば、良いアイデアだと思います。 5. **高品質なグラフインデックスの構築は不可欠です。** 現在、誰もがグラフクエリに注目していますが、高品質なグラフインデックスへの注目度は低いです。この分野でベンチマークを確立し、プロンプトをエンジニアリングやモデルの微調整のガイドとして活用できれば、graphragのパフォーマンス上限をさらに引き上げることができると考えています。 付録: KAG-QAプロンプトの例 KAGジョイント建設KAG は現在初期段階にあり、ナレッジ サービスとナレッジ グラフ テクノロジーに関心のあるユーザーと開発者の皆様には、新世代の AI エンジン フレームワークの構築にご参加いただきますよう心よりお願い申し上げます。 GitHub OpenSPG は意味的に強化されたプログラム可能な知識グラフです。 https://github.com/OpenSPG/openspg KAGは、知識拡張生成のためのドメイン固有の知識サービスフレームワークです。KAGは、OpenSPGが提供するエンジンの依存関係適応、論理的推論、および実行機能に依存しています。 https://github.com/OpenSPG/KAG ぜひスターを付けてフォローしてください！ |
