|
著者紹介：薛明氏は、 ヘルスケアおよび小売分野における機械学習と人工知能の応用において10年近くの経験を有しています。以前はゼネラル・エレクトリックや復星医薬などの企業に勤務していました。長年にわたり、医用画像、自然言語処理、データサイエンス（学習／推論フレームワーク、データマイニング、分析など）の研究開発に注力してきました。2024年7月にはAI企業Percenaを設立し、RAGやAgentといった大規模モデルに基づくアプリケーション製品の開発を担当しています。
以前「Microsoft GraphRAGフレームワークのソースコードの解釈」を執筆した薛明氏は、ナレッジグラフと大規模モデルの組み合わせに強い関心を持っています。Ant Financial KAGフレームワークのオープンソース化に際し、薛明氏はそのソースコードの詳細な分析を提供しました。Ant Financial OpenSPGオープンソースコミュニティは、このような貢献者とパートナーを得られたことを大変嬉しく誇りに思います。これがオープンソースの魅力なのかもしれません。 数日前、Ant Financialは、専門分野の知識サービスフレームワーク「Knowledge Augmented Generation（KAG）」を正式にリリースしました。このフレームワークは、ナレッジグラフとベクトル検索の利点を最大限に活用し、既存のRAGテクノロジースタックの課題を解決することを目的としています。 Ant Financialがこのフレームワークを少しばかり紹介し始めてから、KAGのコア機能、特に論理記号推論と知識アラインメントに非常に興味を持つようになりました。この2つの側面は、既存の主流のRAGシステムではあまり議論されていないように思われるので、このオープンソースリリースを利用して調査を行うことにしました。 コードを詳しく調べる前に、まずフレームワークの目標と位置付けについて簡単に理解しましょう。 どのような問題が解決されましたか (何となぜ)? KAGフレームワークを見た多くの人は、私と同じように、なぜRAGではなくKAGと呼ばれるのかと疑問に思うでしょう。関連記事や論文によると、KAGフレームワークの主な目的は、専門的なドメイン知識サービスにおける大規模モデルが現在直面しているいくつかの課題に対処することです。 - • LLM の学生には厳密な思考力と推論能力が欠けています。
- • 事実、論理、および精度に関するエラーにより、モデルの動作を制限するために事前定義されたドメイン知識構造を使用できなくなります。
- • 一般的な RAG は、特に隠された情報や誤解を招く情報を含む LLM 幻覚の解決にも苦労します。
- • 専門知識に基づくサービスの課題と要件、および厳格で管理された意思決定プロセスの欠如。
したがって、Ant Group チームは、専門知識のサービス フレームワークには次の特性が備わっている必要があると考えています。 Ant Financial による KAG の公式な位置付けは、専門分野の知識強化サービス フレームワークであり、具体的には、現在の大規模言語モデルと知識グラフを組み合わせることで、次の 5 つの側面を強化します。 - • ナレッジグラフと元のテキストフラグメント間の相互インデックス構造
このオープンソースリリースは、上記の 4 つのコア機能を完全にカバーしています。 KAG命名規則の問題に戻りますが、私の個人的な推測では、これは知識オントロジーの概念を強化することを意図している可能性が高いです。公式の説明と実際のコード実装から判断すると、KAGフレームワークは、構築フェーズと推論フェーズの両方において、知識そのものから出発して完全かつ厳密な論理チェーンを構築することを一貫して重視しており、RAGテクノロジースタックの既知の問題を可能な限り改善することを目指しています。 どのように実装されますか? KAG-Builder はオフライン インデックス作成に使用され、主に上記の機能 1 と 2 (強化された知識表現と相互インデックス構造) を備えています。 KAG-Solver モジュールには、機能 3 と 4 (ハイブリッド論理記号推論エンジンと知識アライメント メカニズム) が含まれます。 KAG モデルは、エンドツーエンドの KAG モデルの構築を試みます。
このオープンソース プロジェクトには、主に KAG-Builder と KAG-Solver という 2 つのモジュールが含まれており、これらはソース コードの builder サブディレクトリと solver サブディレクトリに直接対応しています。 コードを学ぶ際は、 特定のモジュールを詳しく調べる前に、フレームワーク全体のワークフローを理解するために、 examplesディレクトリから始めることをお勧めします。kag kag/examples/medicine/builder/indexer.py やkag/examples/medicine/solver/evaForMedicine.pyなど、いくつかのデモのエントリファイルパスは似ています。 ビルダーは異なるモジュールを組み合わせているのに対し、ソルバーの実際のエントリポイントはkag/solver/logic/solver_pipeline.pyにあることがわかります。 KAGビルダー
ビルダー セクションには多くの機能が含まれますが、このセクションでは 1 つの主要コンポーネントについてのみ説明します。 ❯ tree .
.
├── __init__.py
├── component
│ ├── __init__.py
│ ├── aligner
│ │ ├── __init__.py
│ │ ├── kag_post_processor.py
│ │ └── spg_post_processor.py
│ ├── base.py
│ ├── extractor
│ │ ├── __init__.py
│ │ ├── kag_extractor.py
│ │ ├── spg_extractor.py
│ │ └── user_defined_extractor.py
│ ├── mapping
│ │ ├── __init__.py
│ │ ├── relation_mapping.py
│ │ ├── spg_type_mapping.py
│ │ └── spo_mapping.py
│ ├── reader
│ │ ├── __init__.py
│ │ ├── csv_reader.py
│ │ ├── dataset_reader.py
│ │ ├── docx_reader.py
│ │ ├── json_reader.py
│ │ ├── markdown_reader.py
│ │ ├── pdf_reader.py
│ │ ├── txt_reader.py
│ │ └── yuque_reader.py
│ ├── splitter
│ │ ├── __init__.py
│ │ ├── base_table_splitter.py
│ │ ├── length_splitter.py
│ │ ├── outline_splitter.py
│ │ ├── pattern_splitter.py
│ │ └── semantic_splitter.py
│ ├── vectorizer
│ │ ├── __init__.py
│ │ └── batch_vectorizer.py
│ └── writer
│ ├── __init__.py
│ └── kg_writer.py
├── default_chain.py
├── model
│ ├── __init__.py
│ ├── chunk.py
│ ├── spg_record.py
│ └── sub_graph.py
├── operator
│ ├── __init__.py
│ └── base.py
└── prompt
├── __init__.py
├── analyze_table_prompt.py
├── default
│ ├── __init__.py
│ ├── ner.py
│ ├── std.py
│ └── triple.py
├── medical
│ ├── __init__.py
│ ├── ner.py
│ ├── std.py
│ └── triple.py
├── oneke_prompt.py
├── outline_prompt.py
├── semantic_seg_prompt.py
└── spg_prompt.py
KAGExtractor の基本的なフローチャートは次のとおりです。 ここで主に行っているのは、大規模なモデルを用いて、非構造化テキストから構造化されたナレッジグラフを自動的に作成することです。ここでは、主要な手順のいくつかを簡単に説明します。 - • まず、エンティティ認識モジュールがあります。ここでは、定義済みのナレッジグラフタイプに対して特定のエンティティ認識が実行され、続いて一般的な固有表現認識が実行されます。この2層の認識メカニズムにより、ドメイン固有のエンティティを確実に捕捉し、一般的なエンティティを見落とすことがなくなります。
- グラフ構築プロセスは実際には
assemble_sub_graph_with_spg_records メソッドによって完了します。このメソッドのユニークな特徴は、システムが非基本型属性をエンティティの元の属性として保持するのではなく、グラフ内のノードとエッジに変換することです。正直なところ、この変更はよく理解できません。エンティティの複雑さはある程度簡素化されるはずですが、この戦略がどれほどのメリットをもたらすかはまだ明確ではありません。構築の複雑さは確実に増加します。 - • エンティティの標準化は、
named_entity_standardization とappend_official_name 2つの方法によって協調的に行われます。まずエンティティ名が標準化され、次に標準化された名前が元のエンティティ情報に関連付けられます。このプロセスはエンティティ解決に似ています。
全体的に、Builder モジュールの機能は、現在の一般的なグラフ構築テクノロジ スタックと非常に似ており、関連する記事やコードもそれほど理解しにくいものではないため、ここでは詳細には説明しません。 KAGソルバー ソルバーセクションは、フレームワーク全体の多くのコア機能、特に論理記号推論に関連する機能に関係しています。まずは全体的な構造を見てみましょう。
以前、ソルバーのエントリ ファイルについて説明しました。関連するコードは次のとおりです。 ❯ tree .
.
├── __init__.py
├── common
│ ├── __init__.py
│ └── base.py
├── implementation
│ ├── __init__.py
│ ├── default_generator.py
│ ├── default_kg_retrieval.py
│ ├── default_lf_planner.py
│ ├── default_memory.py
│ ├── default_reasoner.py
│ ├── default_reflector.py
│ └── lf_chunk_retriever.py
├── logic
│ ├── __init__.py
│ ├── core_modules
│ │ ├── __init__.py
│ │ ├── common
│ │ │ ├── __init__.py
│ │ │ ├── base_model.py
│ │ │ ├── one_hop_graph.py
│ │ │ ├── schema_utils.py
│ │ │ ├── text_sim_by_vector.py
│ │ │ └── utils.py
│ │ ├── config.py
│ │ ├── lf_executor.py
│ │ ├── lf_generator.py
│ │ ├── lf_solver.py
│ │ ├── op_executor
│ │ │ ├── __init__.py
│ │ │ ├── op_deduce
│ │ │ │ ├── __init__.py
│ │ │ │ ├── deduce_executor.py
│ │ │ │ └── module
│ │ │ │ ├── __init__.py
│ │ │ │ ├── choice.py
│ │ │ │ ├── entailment.py
│ │ │ │ ├── judgement.py
│ │ │ │ └── multi_choice.py
│ │ │ ├── op_executor.py
│ │ │ ├── op_math
│ │ │ │ ├── __init__.py
│ │ │ │ └── math_executor.py
│ │ │ ├── op_output
│ │ │ │ ├── __init__.py
│ │ │ │ ├── module
│ │ │ │ │ ├── __init__.py
│ │ │ │ │ └── get_executor.py
│ │ │ │ └── output_executor.py
│ │ │ ├── op_retrieval
│ │ │ │ ├── __init__.py
│ │ │ │ ├── module
│ │ │ │ │ ├── __init__.py
│ │ │ │ │ ├── get_spo_executor.py
│ │ │ │ │ └── search_s.py
│ │ │ │ └── retrieval_executor.py
│ │ │ └── op_sort
│ │ │ ├── __init__.py
│ │ │ └── sort_executor.py
│ │ ├── parser
│ │ │ ├── __init__.py
│ │ │ └── logic_node_parser.py
│ │ ├── retriver
│ │ │ ├── __init__.py
│ │ │ ├── entity_linker.py
│ │ │ ├── graph_retriver
│ │ │ │ ├── __init__.py
│ │ │ │ ├── dsl_executor.py
│ │ │ │ └── dsl_model.py
│ │ │ ├── retrieval_spo.py
│ │ │ └── schema_std.py
│ │ └── rule_runner
│ │ ├── __init__.py
│ │ └── rule_runner.py
│ └── solver_pipeline.py
├── main_solver.py
├── prompt
│ ├── __init__.py
│ ├── default
│ │ ├── __init__.py
│ │ ├── deduce_choice.py
│ │ ├── deduce_entail.py
│ │ ├── deduce_judge.py
│ │ ├── deduce_multi_choice.py
│ │ ├── logic_form_plan.py
│ │ ├── question_ner.py
│ │ ├── resp_extractor.py
│ │ ├── resp_generator.py
│ │ ├── resp_judge.py
│ │ ├── resp_reflector.py
│ │ ├── resp_verifier.py
│ │ ├── solve_question.py
│ │ ├── solve_question_without_docs.py
│ │ ├── solve_question_without_spo.py
│ │ └── spo_retrieval.py
│ ├── lawbench
│ │ ├── __init__.py
│ │ └── logic_form_plan.py
│ └── medical
│ ├── __init__.py
│ └── question_ner.py
└── tools
├── __init__.py
└── info_processor.py
class SolverPipeline:
def __init__(self, max_run=3, reflector: KagReflectorABC = None, reasoner: KagReasonerABC = None,
generator: KAGGeneratorABC = None, **kwargs):
"" "
Initializes the think-and-act loop class.
:param max_run: Maximum number of runs to limit the thinking and acting loop, defaults to 3.
:param reflector: Reflector instance for reflect tasks.
:param reasoner: Reasoner instance for reasoning about tasks.
:param generator: Generator instance for generating actions.
" ""
self.max_run = max_run
self.memory = DefaultMemory(**kwargs)
self.reflector = reflector or DefaultReflector(**kwargs)
self.reasoner = reasoner or DefaultReasoner(**kwargs)
self.generator = generator or DefaultGenerator(**kwargs)
self.trace_log = []
def run(self, question):
"" "
Executes the core logic of the problem-solving system.
Parameters:
- question (str): The question to be answered.
Returns:
- tuple: answer, trace log
" ""
instruction = question
if_finished = False
logger.debug( 'input instruction:{}' .format(instruction))
present_instruction = instruction
run_cnt = 0
while not if_finished and run_cnt < self.max_run:
run_cnt += 1
logger.debug( 'present_instruction is:{}' .format(present_instruction))
# Attempt to solve the current instruction and get the answer, supporting facts, and history log
solved_answer, supporting_fact, history_log = self.reasoner.reason(present_instruction)
# Extract evidence from supporting facts
self.memory.save_memory(solved_answer, supporting_fact, instruction)
history_log[ 'present_instruction' ] = present_instruction
history_log[ 'present_memory' ] = self.memory.serialize_memory()
self.trace_log.append(history_log)
# Reflect the current instruction based on the current memory and instruction
if_finished, present_instruction = self.reflector.reflect_query(self.memory, present_instruction)
response = self.generator.generate(instruction, self.memory)
return response, self.trace_log
全体class SolverPipeline:
def __init__(self, max_run=3, reflector: KagReflectorABC = None, reasoner: KagReasonerABC = None,
generator: KAGGeneratorABC = None, **kwargs):
"" "
Initializes the think-and-act loop class.
:param max_run: Maximum number of runs to limit the thinking and acting loop, defaults to 3.
:param reflector: Reflector instance for reflect tasks.
:param reasoner: Reasoner instance for reasoning about tasks.
:param generator: Generator instance for generating actions.
" ""
self.max_run = max_run
self.memory = DefaultMemory(**kwargs)
self.reflector = reflector or DefaultReflector(**kwargs)
self.reasoner = reasoner or DefaultReasoner(**kwargs)
self.generator = generator or DefaultGenerator(**kwargs)
self.trace_log = []
def run(self, question):
"" "
Executes the core logic of the problem-solving system.
Parameters:
- question (str): The question to be answered.
Returns:
- tuple: answer, trace log
" ""
instruction = question
if_finished = False
logger.debug( 'input instruction:{}' .format(instruction))
present_instruction = instruction
run_cnt = 0
while not if_finished and run_cnt < self.max_run:
run_cnt += 1
logger.debug( 'present_instruction is:{}' .format(present_instruction))
# Attempt to solve the current instruction and get the answer, supporting facts, and history log
solved_answer, supporting_fact, history_log = self.reasoner.reason(present_instruction)
# Extract evidence from supporting facts
self.memory.save_memory(solved_answer, supporting_fact, instruction)
history_log[ 'present_instruction' ] = present_instruction
history_log[ 'present_memory' ] = self.memory.serialize_memory()
self.trace_log.append(history_log)
# Reflect the current instruction based on the current memory and instruction
if_finished, present_instruction = self.reflector.reflect_query(self.memory, present_instruction)
response = self.generator.generate(instruction, self.memory)
return response, self.trace_log
SolverPipeline.run()メソッドは、主にReasoner 、 Reflector 、 Generator 3つのモジュールから構成されています。 全体的なロジックは非常に明確です。まず問題の解決を試み、次に問題が解決されたかどうかを検証します。解決されていない場合は、満足のいく答えが得られるか、最大試行回数に達するまで、さらに深く考え続けます。本質的には、複雑な問題を解決するための人間の一般的な思考プロセスを模倣しています。 次のセクションでは、上記の 3 つのモジュールをさらに分析します。 I. 推論者推論モジュールはおそらくフレームワーク全体の中で最も複雑な部分であり、そのキーコードは次のとおりです。
class DefaultReasoner(KagReasonerABC):
def __init__(self, lf_planner: LFPlannerABC = None, lf_solver: LFSolver = None, **kwargs):
def reason(self, question: str):
"" "
Processes a given question by planning and executing logical forms to derive an answer.
Parameters:
- question (str): The input question to be processed.
Returns:
- solved_answer: The final answer derived from solving the logical forms.
- supporting_fact: Supporting facts gathered during the reasoning process.
- history_log: A dictionary containing the history of QA pairs and re-ranked documents.
" ""
# logic form planing
lf_nodes: List[LFPlanResult] = self.lf_planner.lf_planing(question)
# logic form execution
solved_answer, sub_qa_pair, recall_docs, history_qa_log = self.lf_solver.solve(question, lf_nodes)
# Generate supporting facts for sub question-answer pair
supporting_fact = '\n' .join(sub_qa_pair)
# Retrieve and rank documents
sub_querys = [lf.query for lf in lf_nodes]
if self.lf_solver.chunk_retriever:
docs = self.lf_solver.chunk_retriever.rerank_docs([question] + sub_querys, recall_docs)
else :
logger.info( "DefaultReasoner not enable chunk retriever" )
docs = []
history_log = {
'history' : history_qa_log,
'rerank_docs' : docs
}
if len(docs) > 0:
# Append supporting facts for retrieved chunks
supporting_fact += f "\nPassages:{str(docs)}"
return solved_answer, supporting_fact, history_log
これは推論モジュールの全体的なフローチャートになります (エラー処理やその他のロジックは省略されています)。 class DefaultReasoner(KagReasonerABC):
def __init__(self, lf_planner: LFPlannerABC = None, lf_solver: LFSolver = None, **kwargs):
def reason(self, question: str):
"" "
Processes a given question by planning and executing logical forms to derive an answer.
Parameters:
- question (str): The input question to be processed.
Returns:
- solved_answer: The final answer derived from solving the logical forms.
- supporting_fact: Supporting facts gathered during the reasoning process.
- history_log: A dictionary containing the history of QA pairs and re-ranked documents.
" ""
# logic form planing
lf_nodes: List[LFPlanResult] = self.lf_planner.lf_planing(question)
# logic form execution
solved_answer, sub_qa_pair, recall_docs, history_qa_log = self.lf_solver.solve(question, lf_nodes)
# Generate supporting facts for sub question-answer pair
supporting_fact = '\n' .join(sub_qa_pair)
# Retrieve and rank documents
sub_querys = [lf.query for lf in lf_nodes]
if self.lf_solver.chunk_retriever:
docs = self.lf_solver.chunk_retriever.rerank_docs([question] + sub_querys, recall_docs)
else :
logger.info( "DefaultReasoner not enable chunk retriever" )
docs = []
history_log = {
'history' : history_qa_log,
'rerank_docs' : docs
}
if len(docs) > 0:
# Append supporting facts for retrieved chunks
supporting_fact += f "\nPassages:{str(docs)}"
return solved_answer, supporting_fact, history_log
DefaultReasoner.reason() メソッドは一般に次の 3 つのステップで構成されていることが簡単にわかります。 • 論理フォームプランニング: 主にLFPlanner.lf_planingを使用します • ロジックフォーム実行: 主にLFSolver.solveを使用します • ドキュメントの再ランキング: 主にLFSolver.chunk_retriever.rerank_docsが関与
A. 論理形式計画 DefaultLFPlanner.lf_planing() メソッドは主に、クエリを一連の独立した論理形式 ( lf_nodes: List[LFPlanResult] ) に分解するために使用されます。
具体的な実装ロジックについては、 lf_nodes: List[LFPlanResult] = self.lf_planner.lf_planing(question)
kag/solver/implementation/default_lf_planner.py 、主にllm_outputの正規化解析を実行します。llm_output が指定されていない場合は、LLM を呼び出して新しい論理形式を生成します。 ここでは、 kag/solver/prompt/default/logic_form_plan.py にあるLogicFormPlanPromptの詳細な設計に注目してください。 その核心は、複雑な問題を複数のサブクエリとそれに対応する論理形式に分解する方法にあります。 B. 論理形式の実行LFSolver.solve() メソッドは、特定の論理形式の問題を解決するために使用され、回答、サブ問題の回答のペア、関連するリコール ドキュメント、および履歴を返します。
詳細solved_answer, sub_qa_pair, recall_docs, history_qa_log = self.lf_solver.solve(question, lf_nodes)
kag/solver/logic/core_modules/lf_solver.py のソース コードを見ると、 LFSolver クラス (論理形式ソルバー) が推論プロセス全体のコア クラスであり、論理形式 (LF) を実行して答えを生成する役割を担っていることがわかります。 その主なメソッドは、クエリと論理ノードのセット ( List[LFPlanResult] ) を受け取るsolveです。 LogicExecutor を使用して論理フォームを実行し、回答、ナレッジ グラフ パス、履歴レコードを生成します。 サブクエリと回答のペア、および関連ドキュメントを処理します。 エラー処理とロールバック戦略: 回答または関連するドキュメントが見つからない場合は、 chunk_retriever使用して関連するドキュメントを取得してみてください。
主なプロセスは次のとおりです。 LogicExecutorは重要なクラスです。以下はそのコア コードのスニペットです。
executor = LogicExecutor(
query, self.project_id, self.schema,
kg_retriever=self.kg_retriever,
chunk_retriever=self.chunk_retriever,
std_schema=self.std_schema,
el=self.el,
text_similarity=self.text_similarity,
dsl_runner=DslRunnerOnGraphStore(...),
generator=self.generator,
report_tool=self.report_tool,
req_id=generate_random_string(10)
)
kg_qa_result, kg_graph, history = executor.execute(lf_nodes, query) - 1.
LogicExecutorクラスの関連コードは、 kag/solver/logic/core_modules/lf_executor.pyにあります。executeメソッドの主な実行フローexecute 次の図に示されています。
この実行フローは、構造化グラフ データの取得と推論を優先し、グラフが回答を提供できない場合は非構造化テキスト情報の取得にフォールバックするという、2 つの取得戦略を示しています。 システムはまず、ナレッジグラフを用いて質問への回答を試みます。各論理式ノードに対して、異なるエグゼキュータ（ deduce 、 math 、 sort 、 retrieval 、 outputなどの演算を含む）を用いて処理を行います。この検索プロセスでは、後続の回答生成のためにSPO（主語-動詞-目的語）のトリプルを収集します。グラフが満足のいく回答を提供できない場合（「わかりません」と返答する場合）、システムはテキストブロック検索にフォールバックします。つまり、以前に取得した固有表現抽出（NER）結果を検索アンカーとして使用し、過去の質問と回答の記録を組み合わせることでコンテキスト強化クエリを構築します。その後、 chunk_retriever用いて取得したドキュメントに基づいて回答を再生成します。 - このプロセス全体は、洗練された劣化戦略と捉えることができます。構造化された知識グラフと非構造化テキストデータを組み合わせることで、このハイブリッド検索は、正確性を確保しながら、可能な限り完全かつ文脈的に一貫性のある回答を提供できます。
- 2. 上記の特定の実行ロジックに加えて、
LogicExecutor 初期化時に複数のコンポーネントを渡す必要があることに注意してください。スペースの制約により、ここでは各コンポーネントのコア機能のみを簡単に説明します。詳細な実装については、ソースコードを参照してください。 - • kg_retriever: ナレッジグラフ リトリーバー リファレンス
kag/solver/implementation/default_kg_retrieval.py では、 KGRetrieverByLlm(KGRetrieverABC) 、完全一致/あいまい一致やワンホップサブグラフ一致などのさまざまな一致方法を含むエンティティとリレーションの取得を実装します。 - • chunk_retriever: テキストチャンクリトリーバー参照
kag/common/retriever/kag_retriever.py のDefaultRetriever(ChunkRetrieverABC) 関数は注目に値します。まず、エンティティの扱いが標準化されています。さらに、ここでの検索は HippoRAG を参照し、DPR（Dense Passage Retrieval）と PPR（Personalized PageRank）を組み合わせたハイブリッド検索戦略を採用しています。さらに、DPR と PPR のスコアを統合することで、2 つの検索手法に動的な重み付けを実現しています。 - • entity_linker (el): エンティティリンカーは、
kag/solver/logic/core_modules/retriver/entity_linker.py のDefaultEntityLinker(EntityLinkerBase)から参照されます。 ここでは、まず特徴量を構築し、次にエンティティリンクを並列処理するというアプローチを採用しています。 - • dsl_runner: グラフデータベースクエリエンジンは、
kag/solver/logic/core_modules/retriver/graph_retriver/dsl_executor.py 、具体的にはDslRunnerOnGraphStore(DslRunner) で参照されています。このエンジンは、構造化クエリ情報を特定のグラフデータベースクエリ文に変換する役割を担っています。この部分は、OpenSPG Reasonerが提供する推論インターフェースに基づいており、基盤となる特定のグラフデータベースも利用しています。詳細は比較的複雑なため、 Ant Financialからの正式な解釈と説明を待ちます。
上記のコードとフローチャートを分析すると、ロジックフォーム実行プロセス全体が階層化された処理アーキテクチャを採用していることがわかります。 • 最上位レベルのLFSolver が全体的なプロセスを担当します。 • 中間層LogicExecutor 、特定の論理形式 (LF) の実行を担当します。 • OpenSPG Reasoner によって提供される推論インターフェースに基づく基礎となるDSL Runnerグラフ データベースとの対話を担当します。
C. 文書の再ランク付けchunk_retriever が有効な場合、呼び出されたドキュメントも並べ替えられます。
if self.lf_solver.chunk_retriever:
docs = self.lf_solver.chunk_retriever.rerank_docs(
[question] + sub_querys, recall_docs
)
II. リフレクターif self.lf_solver.chunk_retriever:
docs = self.lf_solver.chunk_retriever.rerank_docs(
[question] + sub_querys, recall_docs
)
Reflector クラスは主に2つのメソッド、 _can_answer と_refine_queryを実装しています。前者は質問に回答できるかどうかを判断するために使用され、後者はマルチホップクエリの中間結果を最適化して最終的な回答の生成を導くために使用されます。 関連する実装リファレンス: 2 つの Prompt ファイルkag/solver/prompt/default/resp_judge.py とkag/solver/prompt/default/resp_reflector.py 方が理解しやすいです。 III. ジェネレータ メインコンポーネントはLFGenerator クラスです。このクラスは、様々なシナリオ（ナレッジグラフの有無、ドキュメントの有無など）に基づいてプロンプト単語テンプレートを動的に選択し、対応する質問への回答を生成します。関連する実装はkag/solver/logic/core_modules/lf_generator.pyにあります。コードは比較的直感的なので、ここでは詳細には触れません。 Ant Financialが新たにオープンソース化したKAGフレームワークは、記号推論や知識アライメントといった革新的な機能を網羅し、ドメイン固有の知識の強化に重点を置いています。徹底的な検討の結果、このフレームワークは、厳格なスキーマ制約が求められる専門知識のシナリオに特に適していると感じています。インデックス作成フェーズでもクエリフェーズでも、ワークフロー全体を通して、グラフや論理的推論は制約された知識ベースから開始する必要があるという考え方が繰り返し強調されています。このアプローチは、大規模モデルにおけるドメイン知識のギャップや錯覚の問題をある程度軽減するはずです。 MicrosoftのGraphRAGフレームワークがオープンソース化されて以来、コミュニティはナレッジグラフとRAGテクノロジースタックの統合について多くの検討を重ねてきました。LightRAGやStructRAGといった最近の取り組みは、多くの貴重な探求をもたらしました。KAGは技術的なアプローチにおいてGraphRAGとは多少異なりますが、GraphRAGの実用的応用として、特に知識の整合と推論における欠点を克服し、特定の分野における知識拡張サービスを提供するものと捉えることもできます。この観点から、私は個人的にこれを「知識制約型GraphRAG」と呼ぶことを好みます。 ネイティブGraphRAGは、異なるコミュニティに基づく階層的な要約を用いることで、比較的抽象的で高レベルの質問に答えることができます。しかし、クエリ重視の要約（QFS）に過度に重点を置くことで、きめ細かい事実に関する質問に対してパフォーマンスが低下する可能性があります。コストを考慮すると、ネイティブGraphRAGは垂直アプリケーション展開において多くの課題に直面しています。一方、KAGフレームワークは、スキーマ固有のエンティティのアライメントや標準化など、グラフ構築段階から大幅な最適化を行ってきました。クエリ段階では、記号論理に基づく知識グラフ推論手法を導入しています。記号推論はグラフ分野で広く研究されてきましたが、RAGシナリオへの実用化は比較的稀です。RAG推論機能の強化は、有望な研究分野です。最近、MicrosoftはRAGテクノロジースタックにおける4つのレベルの推論機能をまとめました。 • レベル1の明示的な事実 • レベル2の暗黙の事実 • レベル3 解釈可能な根拠: (垂直方向の)理由の説明 • レベル4の隠された根拠、隠された（垂直な）理由 現在、ほとんどのRAGフレームワークの推論機能はレベル1に限定されています。前述のレベル3およびレベル4では、垂直ドメイン推論の重要性が強調されています。課題は、大規模モデルにおける垂直ドメイン知識の不足にあります。このKAGフレームワークは、クエリフェーズに記号推論を導入しており、この方向性への探求と見ることができます。RAG推論は、RLやCoTといったモデル自身の推論機能をさらに統合するなど、新たな研究の波を引き起こす可能性が予測されます。現時点では、既存のいくつかの試みは、シナリオ実装の点で依然として限界があります。 KAGは推論段階に加えて、検索面ではHippoRAGを参考に、DPRとPPRを組み合わせたハイブリッド検索戦略を採用しています。PageRankの効率的な利用は、従来のベクトル検索に対するナレッジグラフの優位性をさらに示しています。今後、より多くのグラフ検索アルゴリズムがRAGの技術スタックに統合される予定です。 もちろん、KAGフレームワークは現在、初期の迅速なイテレーション段階にあると推定されており、具体的な実装についてはまだ議論の余地があります。例えば、既存のロジックフォームプランニングとロジックフォーム実行は、設計レベルで完全な理論的裏付けを備えているのでしょうか？複雑な問題に直面した場合、分解不足や実行失敗は発生するのでしょうか？しかし、こうした境界定義や堅牢性の問題は通常、扱いが非常に難しく、多大な試行錯誤コストを伴います。推論チェーン全体が複雑すぎる場合、様々なフォールバック戦略は問題をある程度しか緩和できないため、失敗率は確かに比較的高くなる可能性があります。さらに、フレームワークの基盤となるGraphStoreには増分更新インターフェースが確保されているものの、上位層アプリケーションでは関連機能が実証されていないことに気づきました。これは、GraphRAGコミュニティから強く要望されている機能だと私は理解しています。 総じて、KAGフレームワークは近年非常にハードコアなプロジェクトであり、多くの革新的な機能を備え、細部に至るまでコードが洗練されています。これは間違いなく、RAGテクノロジースタックの実装にとって重要な推進力となるでしょう。 • 専門分野向けのKAG知識強化サービスフレームワークに関する国内初の技術レポート。大規模モデルを垂直分野に展開するのに役立ちます。 • RAG の制限を打ち破り、KAG プロフェッショナル ドメイン知識サービス フレームワークが正式にオープン ソースになりました。 • KAG 知識拡張生成による専門分野の LLM の促進• microsoft/graphrag: モジュール式グラフベースの検索拡張生成 (RAG) システム• OSU-NLP-Group/HippoRAG: [NeurIPS'24] HippoRAGは、人間の長期記憶に着想を得た新しいRAGフレームワークであり、LLMが外部ドキュメント間の知識を継続的に統合することを可能にします。RAG + ナレッジグラフ + パーソナライズされたPageRank。 • 検索拡張生成（RAG）とその先：LLMで外部データをより賢く活用するための包括的な調査 KAGは現在初期段階にあり、ナレッジサービスとナレッジグラフ技術にご関心のあるユーザーと開発者の皆様を、新世代のAIエンジンフレームワークの構築にぜひご参加ください。OpenSPG 技術交流グループを設立しました。参加をご希望の方は、WeChatでアシスタントを追加してください： jqzn-robot。 OpenSPG は意味的に強化されたプログラム可能な知識グラフです。
https://github.com/OpenSPG/openspg KAGは、知識拡張生成のためのドメイン固有の知識サービスフレームワークです。KAGは、OpenSPGが提供するエンジンの依存関係適応、論理的推論、および実行機能に依存しています。 https://github.com/OpenSPG/KAG
|
