先週、LlamaIndexのv0.14.22がリリースされた。
リリースノートを流し読みしたとき、最初は「またdepsのバンプか」と思ってスルーしかけた。
でも少し落ち着いて中身を見たら、自分のプロジェクトに関係あるところが結構あった。
今回のリリースで目立つのは、コールバック系のパッケージがまとめて更新されていること。
llama-index-callbacks-langfuseが0.5.0、llama-index-callbacks-opikが1.3.0、llama-index-callbacks-arize-phoenixが0.7.0という感じで、軒並みバージョンが上がっている。
背景にあるのは、PR #21435の「55ディレクトリにまたがるpipグループの一括バンプ」だ。
地味な変更に見えるけど、55ディレクトリというのはかなりの規模で、依存関係のズレが積み重なってたんだと思う。
自分は今、LLMの推論ログをLangfuseに流して可視化する構成を組んでいる。
コスト管理のために、どのクエリが何トークン食ってるかを追いたかったからだ。
llama-index-callbacks-langfuseが0.5.0になったということで、まずlockファイルの状態を確認した。
これで依存関係が最新になる。
もしpipを使っているなら、pip install --upgrade llama-index-callbacks-langfuse で同様に対応できる。
更新後にLangfuseのダッシュボードが壊れていないかは、念のためローカルで一通り動かして確認した。
あと地味に気にしてるのが、llama-index-agent-agentmeshが0.2.0になった件。
自分はまだagentmeshをプロダクションには入れていないけど、マルチエージェントの実験はしていて、そっちに移行するか迷っている。
0.2.0は初期の0.1.x系からの変更なので、APIが変わってないかリリースノートをもう少し掘り下げるつもりだ。
リリースノートの各エントリに繰り返し出てくる「mass uv lock --upgrade」という言葉が気になった。
これはrun-llamaチームがリポジトリ全体のロックファイルを一括で更新した、という作業記録だ。
つまり今回のリリースは機能追加よりも「依存関係の健全化」が主目的だったと読める。
こういうリリースは見落とされがちだけど、実は重要だと思っている。
コールバック系のパッケージが古いバージョンの依存関係を引いていると、別のパッケージとコンフリクトして解決に時間を取られる。
自分はそれで半日溶かした経験があるので、こういう地味な更新は歓迎している。
あと個人的に「uvを使ってる」というシグナルがリポジトリの公式ワークフローに入ってきたのは地味に嬉しい。
pipとpoetryで管理が分散していた時代より、uvに統一する方向が見えてきた気がする。
自分のプロジェクトもuvに移行を進めているので、upstream側が同じ方向に動いてくれると話が合わせやすい。
今使っているLangfuseのコールバック周りの動作確認、まず自分の手元の環境でちゃんと通るか試してみてほしい。
リリースノートを流し読みしたとき、最初は「またdepsのバンプか」と思ってスルーしかけた。
でも少し落ち着いて中身を見たら、自分のプロジェクトに関係あるところが結構あった。
今回のリリースで目立つのは、コールバック系のパッケージがまとめて更新されていること。
llama-index-callbacks-langfuseが0.5.0、llama-index-callbacks-opikが1.3.0、llama-index-callbacks-arize-phoenixが0.7.0という感じで、軒並みバージョンが上がっている。
背景にあるのは、PR #21435の「55ディレクトリにまたがるpipグループの一括バンプ」だ。
地味な変更に見えるけど、55ディレクトリというのはかなりの規模で、依存関係のズレが積み重なってたんだと思う。
自分のコードのどこを直すか
自分は今、LLMの推論ログをLangfuseに流して可視化する構成を組んでいる。
コスト管理のために、どのクエリが何トークン食ってるかを追いたかったからだ。
llama-index-callbacks-langfuseが0.5.0になったということで、まずlockファイルの状態を確認した。
# uvを使ってる場合
uv lock --upgrade-package llama-index-callbacks-langfuse
uv syncこれで依存関係が最新になる。
もしpipを使っているなら、pip install --upgrade llama-index-callbacks-langfuse で同様に対応できる。
更新後にLangfuseのダッシュボードが壊れていないかは、念のためローカルで一通り動かして確認した。
あと地味に気にしてるのが、llama-index-agent-agentmeshが0.2.0になった件。
自分はまだagentmeshをプロダクションには入れていないけど、マルチエージェントの実験はしていて、そっちに移行するか迷っている。
0.2.0は初期の0.1.x系からの変更なので、APIが変わってないかリリースノートをもう少し掘り下げるつもりだ。
「mass uv lock --upgrade」という一文から読み取れること
リリースノートの各エントリに繰り返し出てくる「mass uv lock --upgrade」という言葉が気になった。
これはrun-llamaチームがリポジトリ全体のロックファイルを一括で更新した、という作業記録だ。
つまり今回のリリースは機能追加よりも「依存関係の健全化」が主目的だったと読める。
こういうリリースは見落とされがちだけど、実は重要だと思っている。
コールバック系のパッケージが古いバージョンの依存関係を引いていると、別のパッケージとコンフリクトして解決に時間を取られる。
自分はそれで半日溶かした経験があるので、こういう地味な更新は歓迎している。
あと個人的に「uvを使ってる」というシグナルがリポジトリの公式ワークフローに入ってきたのは地味に嬉しい。
pipとpoetryで管理が分散していた時代より、uvに統一する方向が見えてきた気がする。
自分のプロジェクトもuvに移行を進めているので、upstream側が同じ方向に動いてくれると話が合わせやすい。
今使っているLangfuseのコールバック周りの動作確認、まず自分の手元の環境でちゃんと通るか試してみてほしい。