第6回LangChainもくもく会開催レポート！第7回は6/21（水）開催予定
先日6/7（水）は第6回LangChainもくもく会の日でした！
おかげさまで前回は定員50名という枠でMAX50名お申し込みを頂いており、LangChainへの期待の高まりの強さを感じられます。
とはいえ、もくもく会自体はLangChain自体の話よりは、LangChainの更新履歴を肴にしながらLLM周辺の話を楽しむ感じで進行しています。投資が一気にAI方面に流れているからか、海外を中心に新しいベクトル検索DBやLLMホスティングサービスがガンガン立ち上がっている中で、そのインテグレーションがサービスの中の人からLangChainにプルリクされてくるような流れができているので、LangChainの差分を追っていると自然と周辺サービスに詳しくなってしまう、という算段なのです。
そんな訳でAI周り、特にLLM周りのトレンドを掴みたい場合は、LangChainの更新差分を追うのが早いのではないかと思います。LangChainもくもく会ではそんな感じで更新差分のつっつき会をしておりますので、興味のある方はお気軽に足をお運びください！
前回のトピックふりかえり
もはや恒例ですが、当日に投稿されるLangChain差分まとめを見ながらワイワイ話す流れで進行。
Vectaraとのインテグレーション
信頼性の高い情報源をプロンプトに埋め込むなどして参照できるようにした上でLLMに文章を生成させることをGroundedと呼ぶらしいですが、VectaraはこのようなGrounded Generationを実現することに特化したサービスです。具体的には情報ソースを良い感じにインデックスしたりランキングしたりしてくれるとのこと。「文字列をどのぐらいのチャンクで区切ると良い感じにベクトル検索で引っかけられるんだろう？」みたいな悩みから解放してくれるって感じでしょうか。
一方で「こういうサービスは個人でサクッと利用する分には良いけれども、プロダクションで使うとなるとサービスの継続性がリスクになりますよね」という話がありました。それは確かにそうで、依存する範囲が広ければ広いほどリスクのある技術選定となります。あと、Growthプラン（現在のフリープラン）で使えるリソース量が結構小さいのと、Scaleプランの料金が不透明なので、そのあたりがビミョーな感じですね。
Beamとのインテグレーション
ざっくり差分を見た感じ、コードからLLMのホスティングコンテナを利用の都度起動できる？ような動作をしそうとのことで騒然となりました。もう少し調べたところ、こんな感じの動作をしてくれるようです。
リモート開発環境の設定：
Pythonでランタイムを設定し、必要なGPUの数やインストールしたいライブラリを指定すると、Beamがリモート環境を生成します。
リモートハードウェア上でのローカル開発：
Beamはあなたのターミナルに軽量なラッパーを提供します。Beamの開発セッションを開始すると、実行するコードはすべてクラウド上でリモートで実行されます。
アプリケーションのサーバーレス関数としてのデプロイ：
アプリケーションをサーバーレスのREST API、スケジュールされたcronジョブ、またはウェブフックとしてデプロイできます。これらはすべてPythonの4行のコードだけで可能です。
LangChainのAgentがシュッとサーバレス関数をデプロイする未来が見える。
sqlite-vssが良さげである
以下の記事は昨日公開したものですが、実はその前日に執筆済みだったのでもくもく会で「こんなのあるよー」と紹介しておりました。
SQLite活用の幅はどんどん拡がっているように見えておりまして、特にエッジSQLiteであるD1はマジヤベエと騒然となっていたような気がします。
昨今ではコストをおさえてサクッとWebアプリを作りたい場合はFirebaseが定番という感じでしたが、RealtimeDatabaseやFirestoreのクセがありすぎる、特にセキュリティルールが尋常じゃなくリスクになる割にはベストプラクティスがマジ分からないという課題があったようです。
スケール性を別とすれば、Fly.io + SQLiteであればコストをおさえつつ古き良き技術スタックでも開発ができるのと、スケール性を意識するのであればCloudflare Pages + D1という選択肢も出てきたので、技術スタックの大部分をガチロックインされるFirebaseを選ぶ必要もなくなってきたのかな、という感覚でおります。
とはいえFirebaseがマッチする要件も結構あるので、そんなときに堅く設計したい場合はこちらの書籍をご参考くださいまし。
RDS for PostgreSQLがpgvector拡張に対応
「とはいえSQLiteだと書き込みトランザクションが多いケースに難があるので、RDSみたいなマネージドサービスでベクトル検索がサポートされると良いよね」「いやー、あったら良いけどね」「あ、あった」
というわけでRDSでもベクトル検索できるみたいです。
「これまでRDSでデータベースを運用していて、追加でベクトル検索できるようにしたいけど、Pineconeとかにデータを移行するのも微妙だよなー」
という層は結構いそうなので、なかなかの福音に聞こえました。
LLMの問題というよりは検索システムの問題説
と、DB周りの話をしていく中で「いろんなDBでベクトル検索できるのが嬉しいのは技術的な問題の本質が検索部分にあるからではないか？」という話になり、検索周りの理解を深めることがポイントだよね、という話になりました。以下がオススメ書籍になります。
LangChain AI Handbook
LangChain本家からもリンクが貼られておりました。Pinecone製のLangChainガイドでございます。とりあえずこれを読んでおけばOKなのと、英語が苦手ならChatGPTプラグインでURL食わせながら読み進めると捗ります。
書籍と言えばnpakaさん
我らがnpakaさんがLangChainの内容も含んだ本をリリース！要チェックや。
Andrew先生もLangChainの講座を公開
LangChainクリエイターのHarrison Chaseさんも交えてのセッション「LangChain for LLM Application Development」が公開されています。
guidanceとLangChain
ライブラリとしてはLangChainを楽しく追っていますが、最近メイン使いしているのはguidanceです。というわけで今回は後半guidanceについて追ってみました。
差分をシュッと見ながら、
この辺のコードをコードリーディング。
プロンプトは直感的に書きやすくなるものの、プロンプトインジェクションなど異常系に対応できる仕組みではないので、そのあたりはNeMo-Guardrailsといった他の仕組みでカバーしていくことになります。
guidanceの強みはキャッシュにあり、LLMによる生成結果をキャッシュしておいてくれる機能が標準搭載されています。LLMを利用したアプリケーションで問題となりやすいのはパフォーマンス問題であり、必要以上にLLMを利用しない他にプロンプトのキャッシュヒット率を上げる工夫を考えるところもノウハウになっていきそうです。
所感
推薦システムの話で特に話題となっていたのはチャットUIの向こう側の話でした。コードを書くように手取り足取りLLMに要求を伝えなくてはいけないUXは明らかに上級者向けであり、理想は勝手にリコメンドされたものが的を射ているような状況を作り出すところにあります。コンピューターが個人や経営の的を射ることを考える上でのど真ん中が推薦システムであり、否が応でも注目が集まるよなーと感じました。
そんな感じのことを考えつつ、実現のための基礎技術について追っていくのがLangChainもくもく会です。次回は6/21（水）20時から、みなさまの参戦をお待ちしております！
現場からは以上です。