langchain-perplexity の 1.3.0 が 5 月 27 日にリリースされた。
changelog を眺めていたら `use_responses_api` というフラグが `ChatPerplexity` に追加されているのに気づいた。
これ、地味にえぐい変更だと思う。
Perplexity には従来の Chat Completions 互換エンドポイントと、Responses API と呼ばれる別のエンドポイントが存在する。
Responses API 側は引用ソースの扱いや一部パラメータの挙動が微妙に違う。
今まで `langchain-perplexity` 越しにどちらを叩いているか意識するのが面倒だった。
1.3.0 では `ChatPerplexity` のコンストラクタに `use_responses_api=True` を渡すだけで切り替えられるようになった。
コードとしては↓みたいな感じ。
たったこれだけ。
以前は自分で requests を直書きしてエンドポイントを切り替えるラッパーを書いていたので、そのコードを丸ごと削除できる。
PR にコメントで「なんでこんな実装になってるの?」と聞かれたとき、うまく説明できなかったやつだ。
やっと消せる。
社内の RAG パイプラインで Perplexity を使っているプロジェクトがある。
ユーザーの質問に対してリアルタイム検索込みで回答を返す部分で、引用 URL の抽出を後処理で雑にやっていた。
Responses API 側だと citations フィールドの構造が整理されているはずなので、後処理が簡潔になるか試す価値がある。
今の後処理コードは正規表現で URL を抜いているんだが、Perplexity のレスポンス形式が微妙に変わるたびに壊れる。
先週もそれで彼女との予定をずらして 2 時間デバッグしていた。
「また Perplexity?」と呆れ気味に言われたのが刺さっている。
今回 `use_responses_api` に切り替えることで構造化された citations を直接受け取れるなら、そのコード自体をほぼ消せる。
依存関係まわりも整理されていた。
`langsmith` が 0.8.0 → 0.8.5、`idna` が 3.10 → 3.15、`urllib3` も 2.6.3 → 2.7.0 にそれぞれ上がっている。
`langchain-core` は 1.3.2 → 1.3.3 とマイナーバップだが、こういう chore 系をきちんと追ってくれているのは地味にありがたい。
セキュリティ系の CVE を踏む前に依存が上がっているのは、ライブラリを本番に入れる側としては助かる。
`use_responses_api` はデフォルト `False` なので既存コードは壊れない。
ただし Responses API 側でモデルのパラメータに差分があることがある。
`temperature` や `max_tokens` の扱いが Chat Completions と微妙に違うケースがあるので、本番に入れる前にユニットテストを回したほうがいい。
自分が意識してチェックするポイントはこのあたりだ。
ストリーミングまわりはまだ手元で確認できていない。
`use_responses_api=True` のときに `stream=True` を渡した場合のレスポンスが Chat Completions と同じ shape かどうか、PR #37359 のコードを直接読まないと確信が持てない。
今夜 GitHub で diff を追うつもりだ。
それと `langchain-tests` の floor が 1.1.9 に上がっている。
自分のプロジェクトで `langchain-tests` を固定で入れていた箇所があるので、バージョン制約が競合していないか pyproject.toml を確認しておく。
こういう見落としで依存解決が壊れるのは地味に時間を食う。
リリースノートのボリュームは小さいが、`use_responses_api` フラグの追加は自分のコードに直接刺さった。
changelog を流し読みして終わりにしていたら確実に見逃していたやつだ。
changelog を眺めていたら `use_responses_api` というフラグが `ChatPerplexity` に追加されているのに気づいた。
これ、地味にえぐい変更だと思う。
use_responses_api フラグとは何か
Perplexity には従来の Chat Completions 互換エンドポイントと、Responses API と呼ばれる別のエンドポイントが存在する。
Responses API 側は引用ソースの扱いや一部パラメータの挙動が微妙に違う。
今まで `langchain-perplexity` 越しにどちらを叩いているか意識するのが面倒だった。
1.3.0 では `ChatPerplexity` のコンストラクタに `use_responses_api=True` を渡すだけで切り替えられるようになった。
pip install langchain-perplexity==1.3.0コードとしては↓みたいな感じ。
from langchain_perplexity import ChatPerplexity
llm = ChatPerplexity(
model="sonar-pro",
use_responses_api=True,
)たったこれだけ。
以前は自分で requests を直書きしてエンドポイントを切り替えるラッパーを書いていたので、そのコードを丸ごと削除できる。
PR にコメントで「なんでこんな実装になってるの?」と聞かれたとき、うまく説明できなかったやつだ。
やっと消せる。
自分のコードのどこを直すか
社内の RAG パイプラインで Perplexity を使っているプロジェクトがある。
ユーザーの質問に対してリアルタイム検索込みで回答を返す部分で、引用 URL の抽出を後処理で雑にやっていた。
Responses API 側だと citations フィールドの構造が整理されているはずなので、後処理が簡潔になるか試す価値がある。
今の後処理コードは正規表現で URL を抜いているんだが、Perplexity のレスポンス形式が微妙に変わるたびに壊れる。
先週もそれで彼女との予定をずらして 2 時間デバッグしていた。
「また Perplexity?」と呆れ気味に言われたのが刺さっている。
今回 `use_responses_api` に切り替えることで構造化された citations を直接受け取れるなら、そのコード自体をほぼ消せる。
依存関係まわりも整理されていた。
`langsmith` が 0.8.0 → 0.8.5、`idna` が 3.10 → 3.15、`urllib3` も 2.6.3 → 2.7.0 にそれぞれ上がっている。
`langchain-core` は 1.3.2 → 1.3.3 とマイナーバップだが、こういう chore 系をきちんと追ってくれているのは地味にありがたい。
セキュリティ系の CVE を踏む前に依存が上がっているのは、ライブラリを本番に入れる側としては助かる。
アップデートで気をつけること
`use_responses_api` はデフォルト `False` なので既存コードは壊れない。
ただし Responses API 側でモデルのパラメータに差分があることがある。
`temperature` や `max_tokens` の扱いが Chat Completions と微妙に違うケースがあるので、本番に入れる前にユニットテストを回したほうがいい。
自分が意識してチェックするポイントはこのあたりだ。
- レスポンスの citations フィールドの有無と構造
- ストリーミング時の挙動 (chunk の shape が変わる可能性)
- エラーレスポンスのスキーマ
ストリーミングまわりはまだ手元で確認できていない。
`use_responses_api=True` のときに `stream=True` を渡した場合のレスポンスが Chat Completions と同じ shape かどうか、PR #37359 のコードを直接読まないと確信が持てない。
今夜 GitHub で diff を追うつもりだ。
それと `langchain-tests` の floor が 1.1.9 に上がっている。
自分のプロジェクトで `langchain-tests` を固定で入れていた箇所があるので、バージョン制約が競合していないか pyproject.toml を確認しておく。
こういう見落としで依存解決が壊れるのは地味に時間を食う。
リリースノートのボリュームは小さいが、`use_responses_api` フラグの追加は自分のコードに直接刺さった。
changelog を流し読みして終わりにしていたら確実に見逃していたやつだ。