langchain-openai の 1.3.1 が 6 月 13 日にリリースされた。
GitHub の releases ページを見たとき、最初は「またマイナーバージョンか」とスルーしかけた。
でも changelog をちゃんと読んだら、自分のコードで直すべき箇所が 2〜3 個あってちょっとハマった。
今回の変更で個人的に一番刺さったのが `feat(core,partners): add package version tracking to tracing metadata (#35295)` だ。
これ、tracing メタデータにパッケージバージョンを自動で乗せる機能で、合わせて `fix(core,partners): rename package version trace metadata (#38110)` でそのメタデータのキー名がリネームされている。
自分のプロジェクトでは LangSmith のトレースを使ってコスト管理をしているから、このキー名変更は普通に breaking に近い影響がある。
ログを Datadog に流して集計しているチームメイトに確認したら、案の定フィールド名でフィルタしているクエリがあった。
メタデータのキーが変わると、既存のダッシュボードやアラートがサイレントに壊れるパターンがある。
バージョンアップするなら先に確認しておくべきだった。
`fix(core,openai): normalize v1 streamed tool calls (#35983)` も見逃せない。
streaming で tool call を使っているコードがあって、chunk をパースするロジックを自分で書いている。
これが今まで微妙に壊れやすかったのは、upstream のこのバグのせいだった可能性がある。
実際、先月「tool call のレスポンスが稀に欠ける」という issue を社内 Slack に投げて、再現性がなくて諦めていた。
そのまま自前のリトライロジックで誤魔化していたけど、今回の fix でそっちが不要になるかもしれない。
もう一個、`fix(langchain): tighten structured output model fallbacks (#38042)` もある。
structured output + fallback の組み合わせを使っているコードがあるので、fallback の挙動が締まるのはありがたい。
ただ「tighten」という言葉が気になっていて、今まで通っていたケースが通らなくなる可能性もゼロじゃない。
とりあえずユニットテストを回してみて、問題がなければ上げる方針にした。
`chore(infra): bump mypy to 2.1 and unify type-check config across the monorepo (#36470)` は地味だけど重要だ。
mypy のバージョンアップで型推論が厳しくなる変更が含まれていることが多い。
自分のリポジトリでは mypy をまだ 1.x で固定していて、langchain-core との型の整合性をあまり気にしていなかった。
彼女に「また夜中まで PC 触ってるの」と言われながらも確認した結果、自分の書いた wrapper クラスで `Any` を雑に使っている箇所が 3 ファイルあった。
これは遅かれ早かれ直すべきものだったから、今回のアップデートがトリガーになった形だ。
あと `test(openai): use gpt-4o for image token counting (#38089)` は、画像トークンのコスト計算を gpt-4o で検証するようになったという変更だ。
トークン数の見積もりがより現実に近くなるので、コスト試算をしているコードには直接影響する。
gpt-4o の vision 系をプロダクションで使っているなら確認しておいたほうがいい。
今回の学びとしては「マイナーバージョンでもメタデータ系の変更は必ず changelog を読む」に尽きる。
次のスプリントで依存を上げる前に、LangSmith のフィールド名リストをコード側で定数管理する PR を先に出しておくつもりだ。
GitHub の releases ページを見たとき、最初は「またマイナーバージョンか」とスルーしかけた。
でも changelog をちゃんと読んだら、自分のコードで直すべき箇所が 2〜3 個あってちょっとハマった。
package version tracking が地味にえぐい
今回の変更で個人的に一番刺さったのが `feat(core,partners): add package version tracking to tracing metadata (#35295)` だ。
これ、tracing メタデータにパッケージバージョンを自動で乗せる機能で、合わせて `fix(core,partners): rename package version trace metadata (#38110)` でそのメタデータのキー名がリネームされている。
自分のプロジェクトでは LangSmith のトレースを使ってコスト管理をしているから、このキー名変更は普通に breaking に近い影響がある。
ログを Datadog に流して集計しているチームメイトに確認したら、案の定フィールド名でフィルタしているクエリがあった。
# 差分を確認したいときはこんな感じで
pip show langchain-core | grep Version
pip show langchain-openai | grep Versionメタデータのキーが変わると、既存のダッシュボードやアラートがサイレントに壊れるパターンがある。
バージョンアップするなら先に確認しておくべきだった。
streamed tool calls の normalize と自分の実装
`fix(core,openai): normalize v1 streamed tool calls (#35983)` も見逃せない。
streaming で tool call を使っているコードがあって、chunk をパースするロジックを自分で書いている。
これが今まで微妙に壊れやすかったのは、upstream のこのバグのせいだった可能性がある。
実際、先月「tool call のレスポンスが稀に欠ける」という issue を社内 Slack に投げて、再現性がなくて諦めていた。
そのまま自前のリトライロジックで誤魔化していたけど、今回の fix でそっちが不要になるかもしれない。
もう一個、`fix(langchain): tighten structured output model fallbacks (#38042)` もある。
structured output + fallback の組み合わせを使っているコードがあるので、fallback の挙動が締まるのはありがたい。
ただ「tighten」という言葉が気になっていて、今まで通っていたケースが通らなくなる可能性もゼロじゃない。
とりあえずユニットテストを回してみて、問題がなければ上げる方針にした。
mypy 2.1 対応と型チェック統一がじわじわくる
`chore(infra): bump mypy to 2.1 and unify type-check config across the monorepo (#36470)` は地味だけど重要だ。
mypy のバージョンアップで型推論が厳しくなる変更が含まれていることが多い。
自分のリポジトリでは mypy をまだ 1.x で固定していて、langchain-core との型の整合性をあまり気にしていなかった。
彼女に「また夜中まで PC 触ってるの」と言われながらも確認した結果、自分の書いた wrapper クラスで `Any` を雑に使っている箇所が 3 ファイルあった。
これは遅かれ早かれ直すべきものだったから、今回のアップデートがトリガーになった形だ。
あと `test(openai): use gpt-4o for image token counting (#38089)` は、画像トークンのコスト計算を gpt-4o で検証するようになったという変更だ。
トークン数の見積もりがより現実に近くなるので、コスト試算をしているコードには直接影響する。
gpt-4o の vision 系をプロダクションで使っているなら確認しておいたほうがいい。
今回の学びとしては「マイナーバージョンでもメタデータ系の変更は必ず changelog を読む」に尽きる。
次のスプリントで依存を上げる前に、LangSmith のフィールド名リストをコード側で定数管理する PR を先に出しておくつもりだ。