第9回LangChainもくもく会開催レポート！第10回は8/17（木）開催予定
第9回LangChainもくもく会も無事開催することができました。いつもお集まりの皆さま、ありがとうございます！
次回は8月17日（木）20時からの開催になります。ご都合のつく方はぜひご参加くださいませー！夜のラジオのお供にもどうぞ。
前回のトピックふりかえり
久しぶりの開催だったこともあって、尋常ではない量の差分を見ることになりました。LangChainのCoreとExperimentalが分かれた影響か、Coreのリファクタリング差分が多い傾向にあり、いよいよLangChainもそういうフェーズなのかーと興味深く眺めておりました。
日本語のEmbeddingの話：Multilingual-E5
LangChainのEmbedding Distance周りの差分を見ている際に「英語のEmbeddingはOpenAIのtext-embedding-ada-002を使うのが定番だけど、日本語の場合はどんなモデルを選択することが適切なんですかね？」という質問があがったのもあって盛り上がったのが日本語のEmbeddingの話でした。
「JapaneseEmbeddingEval」という日本語のEmbeddingモデルを評価するというマニアックなリポジトリがあり、その評価結果を見るとtext-embedding-ada-002よりもmultilingual-e5の方が評価が高かったのでした。
詳細についてはこちらの記事に詳しいです。
Hugging Faceのリポジトリはこちら。
text-embedding-ada-002よりも一度に扱えるトークン数は少ないものの、非力なVPCサーバでもローカルで動くっちゃ動く性能のようでして、Embeddingのコストもできるだけ削りたい勢にとっては嬉しいモデルなのではないでしょうか。
npakaさんも記事の中で使ってますねー。
一点、Embeddingを作成する際は「query: 」もしくは「passage: 」プリフィクスをつけないと性能が出ない点に注意が必要とのことです。
Zep Memoryからのメモリ評価の話
差分の中でZep Memoryというメモリ機構が追加されていました。
こちらは新しいメモリのアルゴリズムが追加された、というわけではなく、メモリを管理するプロダクトに接続できるというインテグレーションみたい。プロダクトのドキュメントは以下↓
Zepは以下の機能を提供してくれるようです。作り込むのは大変な部分なので、結構嬉しいですね。
長期的なメモリの永続化
メモリの自動要約
メモリ保存時にメタデータを自動生成
メモリと自動生成されたメタデータ上でのハイブリッド検索
人間の意図を自動的に識別しメタデータに保存
メッセージから名前付きエンティティを自動的に抽出しメタデータに保存
自動トークンカウント
ただ、メモリ管理って細かく自身でチューニングしたい部分でもあるので、プロダクトに丸投げするのってどうなのかなーというお気持ちと、そもそもメモリ管理の実装を比較評価する仕組みがないと、いずれにせよ意思決定が難しいよねという話をしておりました。
しかし評価すると言ってもどんな観点で評価するのが良いのか、何かしら評価の観点を与えてくれるような論文がないかなぁという感じです。
FacTool: Factuality Detection
ChatGPTプラグインとしてファクトチェックの仕組みをChatGPTに導入できるやーつ。LLMの回答を複数タスク（知識、学術、数学、コード）に分割し、それぞれで正確性をチェックする仕組みのようです。
Form Recognizer
Azure Cognitive Search周りの差分を見ながら「Cognitive Searchは高すぎて今世使う機会がないかも」と呟いたら、Form Recognizerは比較的お手頃なので使う機会があるのではという話が。
ドキュメントをレイアウト分析した上でテキスト抽出してくれるサービス。ドキュメント検索の信頼性を高める上でかなり重要なところですね。
気になるお値段は、まぁそれなり。まとまったドキュメントを分析させようとすると、そこそこの予算は必要そうです。要PoC。
XorbitsとのAgentインテグレーション
PandasとかNumpyとか、データ分析系のいろんなライブラリのインターフェースを共通化したXorbitsというライブラリをAgentから使う仕組みが追加されていました。
そもそも有名ライブラリのインターフェースを共通化することに需要があるのかというのは謎ですが、Agentから使うことを考えるとコンテキストが小さくなるので有用そうです。
AIがコードをゴリゴリ書く現代としては、人間がコードを生成しやすいライブラリよりも、AIがコードを生成しやすいライブラリの方に需要が出てくるのかも知れません。
そうなるとCoCのように人間が気持ち良くなれることを重視した設計よりも、機械的な判断を助けるため全てを明示的に記述する設計の方に力点が置かれていく気がします。人間の書くコードはいよいよ伝統工芸化していきますな。文芸的プログラミングから工芸的プログラミングへ。
Google Cloud Enterprise Search
Google Cloud Enterprise Searchとのインテグレーションの差分もありました。面白いのは、Googleの中の人が直接プルリクを送ってきていること。LangChainにインテグレーションされることにはそれだけの価値があるということなのかも知れません。LLMアプリケーション界のプロモーションエコシステムって感じがして、大変面白い動きだと感じます。
Meilisearchとのインテグレーション
全然知らなかったのですが、Meilisearchって全文検索的な仕組みの世界では老舗なんですね。Meilisearchのベクトル検索対応のプロモーション記事でもLangChainとのインテグレーションがうたわれており、中の人がプルリクを出している形跡がありました。
所感
後半はLangChainのCoreを整備していく差分が多かった印象です。
面白いなーと話題になったのは、Coreをゼロから作り直すのではなく、リファクタリングでコツコツ積み上げながらテストやトレーサー（LangSmithで使う）を整備していっているところ。
インターフェースをゴリっと変えてしまうとそれなりにインパクトがあるということもあると思うのですが、あまりにブレイキングチェンジが多いライブラリって使い手としては引いてしまうので、長期目線で考えると好感の持てる戦略だなと感じています。
現場からは以上です。
この記事が気に入ったらサポートをしてみませんか？