[再掲】QwQ-32Bのツール呼び出し機能とエージェント型RAGアプリケーション

コンテキスト

と題された最近の記事。 Search-R1：強化学習による検索エンジンの推論と活用のためのLLMのトレーニング 国連の未来」というテーマの論文(arxiv.org/pdf/2503.09516)が注目を集めている。この論文では、推論と検索エンジンの活用のために、強化学習を使って大規模言語モデル（LLM）を訓練する新しい方法を提案している。この論文のアイデアのいくつかは、Qwenのチームが開発した QwQ-32B モデル上の探索は一致している。

Alibabaが最近リリースしたQwQ-32B（qwenlm.github.io/zh/blog/qwq-32b/）は、推論モデルにAgent関連の機能を統合している。これらの機能により、推論モデルはツールを使用しながら批判的に考え、環境からのフィードバックに基づいて推論プロセスを適応させることができる。QwQ-32Bモデルフォルダ内の added_tokens.json ファイルを見ると、ツールコールとツールレスポンス用に追加された特別なトークンを見ることができる：

{
"": 151668、
"": 151658、
"": 151666, "": 151667、
"": 151667.

"": 151665。
}

本稿では、Agentic ラグ その一例として、QwQ-32Bモデルのツール・コールの能力を示す。

エージェント型RAGと従来のRAGの比較

Agentic RAGの利点をよりよく理解するためには、まずAgentic RAGと現在一般的なRAG実践のパラダイムを区別する必要がある：

• 従来のRAG今日のRAGプロジェクトの大部分は、基本的にワークフロー、つまり、あらかじめ定義されたコードパスを通してLLMとツールをオーケストレーションするシステムである。この人工的に事前に定義された「死ぬまで書かれた」ワークフローは、ルーティング、チャンキング、並べ替え、クエリの解釈、クエリの拡張、ソースのコンテキスト化、検索エンジニアリングなど、相互に関連するが壊れやすい多くの部分から構成されている。
  • 欠点人間主導のワークフローでは、すべてのコーナーケースをカバーすることは難しい。特に複数回の検索を必要とする複雑なシナリオでは、その効果はより限定的なものになる。
• エージェントRAGプロセスを単純化するために、エンド・ツー・エンド・アプローチが用いられている。ネットワーク検索のためのAPIツール（今回はTavily APIを使用し、一定の無料クレジットを提供）をモデルに装備させるだけで、残りの作業はすべてモデルによって自律的に行われる：
  • 理解しようとする意思（ネットワークが必要かどうかの判断）
  • 質問の書き換えまたは分割
  • インターフェイスコール
  • プロセスの振り付け（多段階検索の可否と方法を含む）
  • 何かを引用する。
  • ...

簡単に言えば、エージェンティックRAGの核となるコンセプトはこうだ：より少ない構造、より多くの知性、レス・イズ・モア.

まさに アンソロピック エージェントモデルの定義：ディープサーチと同様に、エージェントはターゲットタスクを内部で実行する必要があり、「タスクの達成方法を制御するために、自身のプロセスやツールの使用を動的に指示する」。

全体的なプロセス

次の図は、Agentic RAGの全体的な流れを示している：

1. ユーザーの質問を単語テンプレートに適応させる。
2. 新しいトークンを生成するためにモデルを呼び出す。 ...そして、その結果がそのまま出力される。
3. その場合 ...これは、推論プロセス中にモデルがツール呼び出し要求を開始したことを示す。このリクエストを解析し ウェブ検索でラップし、インターフェイス呼び出しの結果を ... フォーマットで、マクロモデルのコンテキストにスプライスされ、マクロモデル生成のために再度要求される。
4. がなくなるまで上記の手順を繰り返す。 <ツール・コール(またはリクエストの上限に達した）、あるいは .

このプロセスは、Search-R1の論文で説明したものと基本的に同じである：

主な技術的ポイント

• キュー・ワードのテンプレート::

user_question = input('質問を入力してください:')
最大検索回数 = 5
prompt = f"""あなたはQwen QwQ、帰還拡張世代のために作られた好奇心旺盛なAIです。
あなたは2025年、現在の日付は{date.today()}です。
あなたはウェブ検索ツールにアクセスし、ユーザーの質問に答えるための関連情報を検索することができます。
ユーザーの質問に答えるために、最大{max_search_times}回までweb_searchツールを使用することができますが、効率的に、できるだけ少ない回数で使用するようにしてください。
以下にガイドラインを示します。
- web_searchは、時事問題や事実に関する情報など、一般的なインターネット・クエリに使用してください。
- インターネットから入手した情報は引用し、常に明確かつ簡潔な方法で最終的な回答を提供する。
- ツールを使用する必要がある場合は、...内に`action`と`action_input`を記述し、ツール呼び出しとして回答をフォーマットしてください。の中に`action`と`action_input`を記述して、ツール呼び出しとしてフォーマットする。.
- ツール使用後 続ける のweb_search結果に基づくあなたの推論....に記述してください。
- あなたが関連する情報を見つけるためにマルチターンweb_searchを必要とする場合、あなたが最終的な答えを提供する前にすべての検索タスクを実施することを確認してください。
---
ユーザ質問:{user_question}"""

• カスタム・ストップ・サイン::

  の間に、モデルが自己回帰生成過程を引き起こしたことが検出された場合、そのモデルは、自己回帰生成過程を引き起こす。 (.*?)s*$ 生成はフォーマット（正規表現マッチ）の後で停止する：

from transformers import (
AutoModelForCausalLM、
AutoTokenizer, AutoModelForCausalLM, AutoTokenizer, StoppingCriteria
StoppingCriteria, StoppingCriteriaList, StoppingCriteriaList, StoppingCriteriaList
停止基準リスト
)
インポート・トーチ
インポート re
tool_call_regex = r"(.*?)s*$"
end_regex = r"<<im_end}}</s*$"
#同時監視: または。
class RegexStoppingCriteria(StoppingCriteria).
def __init__(self, tokeniser, patterns).
self.patterns = patterns
self.tokenizer = tokenizer
def __call__(self, input_ids: torch.LongTensor, scores: torch.FloatTensor, **kwargs) -> bool.
decoded_text = self.tokenizer.decode(input_ids[0])
for pattern in self.patterns:: if re.search(pattern, decode).decode(input_ids[0])
if re.search(pattern, decoded_text, re.DOTALL):: if re.search(pattern, decoded_text, re.DOTALL).
真を返す
偽を返す
stopping_criteria = StoppingCriteriaList([)
RegexStoppingCriteria(
tokenizer, [tool_call_criteria], [stopping_criteria
patterns=[tool_call_regex, end_regex].
)
])
#model.generate(...)。, stopping_criteria=stopping_criteria) # add stopping_criteria

• ウェブ検索API::

  この実践で使用されている検索APIはTavily APIであり、実験と複製を容易にするために一定量の無料クレジットを提供している。Tavily APIを使用すると、開発者は簡単なAPIコールによってウェブ検索機能をアプリケーションに統合することができる。

プラクティスコード

練習規範の詳細については、以下のリンクを参照のこと：

DeepSearchレプリケーションの章：Agentic RAGを例にしたQwQ-32B ToolCall関数の初見.ipynb

テストケース

テストの問題アリが最近オープンソースでリリースしたQwQ-32Bについて、詳しい情報を教えてほしい。

結果を出す: （全結果はノートを参照）

結果からわかるように、推論モデルは自律的に意図理解（ネットワーク検索が必要かどうかの判断）と検索キーワード生成（質問の書き換えや分割）を行う。また、このモデルは潜在的な複数ラウンドの検索シナリオも考慮に入れている。をトリガーした後 ウェブ検索 その後、このモデルは検索結果に基づいて最終レポートを作成する。

この場合、モデルはサーチ・インターフェースの呼び出しを1回しか完了しなかった。これは、ケース問題が単純であること、あるいは、ベースモデルがまだ複雑な多ラウンド検索をトリガーするほどの能力を持っていないことが原因かもしれない。これはまた、知的体としてのモデルの潜在能力を十分に活用するためには、事後訓練と目標微調整のためにSearch-R1を参照することがまだ必要であることを示している。

しかし、QwQ-32Bモデルですでに実証されている能力からすると、適切に設計された合成（または手動でソートされた）再トレーニングデータと、セグメント化されたシナリオでの再強化トレーニングまたはSFTを組み合わせ、ツールインターフェイスのレスポンスから返される出力をマスクすることができる。 トークン この再トレーニングルートは、対応する損失を様々なアクションや境界ケースに対して事前に考慮することができるため、配備がより簡単になり、設計ワークフローを人間がオーケストレーションする必要がなくなるため、将来のインテリジェンス開発と配備の主流になると予想されます。再トレーニングにより、様々なアクションや境界ケースを事前に考慮することができるため、配備が容易になり、人間による設計ワークフローのオーケストレーションが不要になります。Search-R1論文の3.1節では、「取得された損失に対する損失マスキング」について詳しく説明しています。 トークン" テクノロジーPPOと グルポ 検索されたトークンがロスマスキングされている場合、Search-R1 はトークンを生成するために LLM を最適化し、検索エンジンと対話し推論を実行するモデルの能力を向上させる。

加えて、Search-R1 は、次のような方法で、多ラウンド検索と推論をサポートしている（本論文の3.2節「インターリーブされた多ターンの検索エンジン呼び出しによるテキスト生成」）。 <検索 歌で応える  をトリガーし、取得したコンテンツを <情報 歌で応える </情報 の間にある。一方、最終解答の出力には <回答 歌で応える </回答.