本日のLangChainもくもく会のための差分まとめです。
この辺気になるよね、というところ
GPT Researcher x LangChain
GPT Researcherとは以下のような動きをするAIエージェント。
そもそもはgpt-3.5-turboとgpt-4を利用するシステムなのだけど、新しく追加されたOpenAIアダプタを利用することで異なるLLMをGPT Researcherで使うことができようになるのが統合のポイント。
どの程度実用的かは分からないけど、ご家庭用GPUでも動作するLlama2をメインエンジンとして利用することで、AIエージェント活用の悩みの種であるAPI使用料を削減する一助になるかも知れない。
一方で「どの程度実用的かは分からない」と書いたのは、エージェント利用にあたってOSS LLMよりも商用LLM(API based LLM)の方が性能的に優位という論文を過去に読んだから。
とはいえ、OSS LLMとして挙げられているLLMのパラメータ数は低いものしかないので、70Bぐらいのモデルだと違ってくるかも知れない。
Label Studio x LangChain
ブログ記事の具体例で挙げられているのは、LangChainで作成したQAシステムのコールバック先にLabel Studioを仕込み、蓄積されたデータを人手で評価(注釈付け)し、そのフィードバックをQAシステムに反映することで、QAシステムの品質向上を目指すというもの。
読んでいても具体的な実装についてはあんまりピンと来なかったのだけど、以下にfull exampleが用意されております。
https://github.com/HumanSignal/label-studio-examples/tree/master/question-answering-system
Conversational Retrieval Agents
レトリバー可愛いっすね。
ブログ記事によるとLangChainにおけるConversational Retrieval Agents(会話型探索エージェント)は以下の要素から構成されるとされています。
なぜ会話型である必要があるか?
使いすぎるとコンテキストウィンドウが埋まっちゃうので注意な、と書いてあるけど、一定過去のやりとりはセルフリフレクションで要約したものを持たせておくみたいな仕組みが必要でして、高度な記憶システムはやっぱり自前で実装した方が良いということになりそうです。
もくもく会でも話題になっていましたけど、記憶システムのベンチマークを取れるような仕組みが欲しいですねー。そのうち論文で出てきそうな案件。
NeumAI x LangChain
データソースとAIアプリケーションを直接接続すると問題になるのはデータの質の劣化。AIアプリケーションの品質はデータの質によって担保されるので、データソースの品質をいかにして高めるのかがポイントになる。
というわけで、NeumAIのアプローチはデータソースと検索用に用意したベクトルストアを同期させて、AIアプリケーションから直接アクセスするベクトルストア側のデータ品質を高めることによってAIアプリケーションの品質も担保しようというもの。
単にベクトルストアに突っ込むだけで品質がどうこうという訳でもないので品質トラッキングの仕組みも必要だと思うわけですが、NeumAIではそのあたりどう扱っているのかな、という意味で気になる。
v0.0.250 (2023.08.02)
v0.0.251 (2023.08.03)
v0.0.252 (2023.08.05)
v0.0.253 (2023.08.06)
v0.0.254 (2023.08.07)
v0.0.255 (2023.08.07)
v0.0.256 (2023.08.08)
v0.0.257 (2023.08.08)
v0.0.258 (2023.08.09)
v0.0.259 (2023.08.09)
v0.0.260 (2023.08.10)
v0.0.261 (2023.08.10)
v0.0.262 (2023.08.11)
v0.0.263 (2023.08.13)
v0.0.264 (2023.08.15)
v0.0.265 (2023.08.15)
個人的なお気持ちとしては全然LangSmithを触れていないので、もくもく会の時間でLangSmith触ってみたいっす。
そんなわけで今日もよろしくお願いします!
現場からは以上です。