[再掲】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 ファイルを見ると、ツールコールとツールレスポンス用に追加された特別なトークンを見ることができる：

{
"</think>": 151668,
"</tool_call>": 151658,
"</tool_response>": 151666,
"<think>": 151667,
"<tool_call>": 151657,
"<tool_response>": 151665
}

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

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

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

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

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

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

全体的なプロセス

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

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

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

主な技術的ポイント

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

user_question = input('请输入你的问题：')
max_search_times = 5
prompt = f"""You are Qwen QwQ, a curious AI built for retrival augmented generation.
You are at 2025 and current date is {date.today()}.
You have access to the web_search tool to retrival relevant information to help answer user questions.
You can use web_search tool up to {max_search_times} times to answer a user's question, but try to be efficient and use as few as possible.
Below are some guidelines:
- Use web_search for general internet queries, like finding current events or factual information.
- Always provide a final answer in a clear and concise manner, with citations for any information obtained from the internet.
- If you think you need to use a tool, format your response as a tool call with the `action` and `action_input` within <tool_call>...</tool_call>, like this:\n<tool_call>\n{{ "action": "web_search", "action_input": {{ "query": "current stock price of Tesla" }} }}\n</tool_call>.
- After using a tool, continue your reasoning based on the web_search result in <tool_response>...</tool_response>.
- Remember that if you need multi-turn web_search to find relevant information, make sure you conduct all search tasks before you provide a final answer.
---
User Question:{user_question}"""

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

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

from transformers import (
AutoModelForCausalLM,
AutoTokenizer,
StoppingCriteria,
StoppingCriteriaList
)
import torch
import re
tool_call_regex = r"<tool_call>(.*?)</tool_call>\s*$"
end_regex = r"<\|im_end\|\>\s*$"
# 同时监测: <tool_call> 或 <|im_end|>
class RegexStoppingCriteria(StoppingCriteria):
def __init__(self, tokenizer, 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, decoded_text, re.DOTALL):
return True
return False
stopping_criteria = StoppingCriteriaList([
RegexStoppingCriteria(
tokenizer,
patterns=[tool_call_regex, end_regex]
)
])
#model.generate(..., stopping_criteria=stopping_criteria) # 加上停止符

• ウェブ検索API::

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

プラクティスコード

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

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

テストケース

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

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

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

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

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

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