LangChainコミュニティがDeepSeekのツール結果肥大化を報告、中国語テストでトークン使用量が5.7倍に

LangChainのDeepSeek連携パッケージで、中国語を使うエージェントワークフローに直接関わるシリアライズの問題が報告された。11月1日に投稿された報告によると、langchain-deepseek 1.1.1はリスト形式のToolMessageを処理する際、内容ブロック全体をJSON文字列に変換する。報告者が示した中国語のテストケースでは、188文字だった内容が1,041文字に膨らんだ。別の参加者も同じ結果をオフラインで再現したと報告している。公開された報告と議論

重要なのは、JSONがどの階層に置かれるかだ。報告にあるツールは、まず中国語のJSONテキストを生成してテキストブロックに格納していた。その後、連携レイヤーがリスト全体に対してjson.dumpsを呼び出す。Python公式ドキュメントによると、既定のensure_ascii=Trueは非ASCII文字をエスケープするため、中国語は\uXXXXに変換される場合があり、内側のJSONに含まれる引用符も再度エスケープされる。こうした追加の表現がモデルの読み取る内容文字列に残れば、実際の入力は変わる。Python JSONドキュメント

報告者は、同じ会話とツール設定でdeepseek-chatを呼び出し、ツールメッセージの内容だけを入れ替えて比較した。空文字列を使った基準値は312プロンプトトークン、テキストを直接渡した場合は416トークン、リスト形式のブロックでは903トークンだった。基準値を差し引くと、ツール結果はそれぞれ104トークンと591トークンを占め、約5.7倍の差となる。この倍率が示すのはこのテストにおけるツール結果だけであり、会話全体やすべての中国語リクエストで同じ割合の増加が起きるという意味ではない。テスト設定とデータ

LangChainの公式ドキュメントでは、ChatDeepSeekはツール呼び出しとトークン使用量の報告に対応する連携として掲載されている。中国語の検索結果やナレッジベースの要約を扱うエンジニアリングチームは、最終的に送信されるメッセージ内容を確認し、API使用量でコストを確かめる必要がある。この報告は、ツールの生出力の長さだけを見ていると、変換レイヤーで増えた負荷を見落とす可能性を示している。これは現在の仕組みから導かれるエンジニアリング上の影響であり、複数のワークロードを対象にした測定結果はまだない。連携ドキュメント

コミュニティでは、純粋なテキストブロックは連結してテキストにし、混在ブロックではJSONを維持しつつASCIIエスケープを無効にする案が出ている。確認時点でこのissueはオープンのままで、メンテナーによる確認や関連する修正PRは見つかっていない。今後は、ブロック構造を保持する必要があるか、混在コンテンツの互換性テストが必要かを注視したい。修正に関する議論