問題

2025年2月現在LangChain v0.3
全くの無知識からだと種類が多すぎて訳が分からない

LangChain

ChatGPT等のLLMは種類が色々ある
それぞれの使い方に微妙な違いがある

ものすごいざっくり言うとLLMへデータを送る、データを受け取るを共通化したwrapperのようなもの

v0.2で古いが、参考にはなった

これも古いが、参考にはなった

この人達はよく分かってる人と全く知識のない人とで一緒にやっていくので、よく分かってないこっちの気持ちを代弁してくれる感じで分かりやすい

LangChain Expression Language (LCEL)

linuxのコマンドで使える「|」と同じような役割、書き方でprompt -> llm -> outputみたいな一連の流れをchainとして一体化させて、invoke出来るという仕組み

tool

通常LLMはtool_callingが出来る

手順としては

LLMにbind_toolsして関数等をtoolとして渡しておく
toolにはdocstring等でLLMに詳しくどう言うものかを説明しておく
LLMに問い合わせた際に適切にtoolを使ってもらうように説明しておく
そうすることで適切にtoolを使って回答してくれる

例えばLLMだけでは分からない社内の情報はRAGやデータベースに保存されているので、そういう質問の場合はtoolを使って回答するとか
どのtoolへどういうパラメーターを使うかはLLM次第

APIを細かく見ると更に

Core
Langchain
Text Splitters
Community
Experimental

などがある

Core

LangChainの本質的な部分のみ切り出したもの

Langchain

とりあえずこれさえimportしておけば全部あるバージョン？

Text Splitters

RAG等で処理したいテキストデータが大量すぎる場合に、処理しやすい単位で切り分ける必要がある
そういう時のためのもの

Community

サードパーティー用などその他細々したもの（特に使った事がないのでよく分からない）

Experimental

名前の通り

LangGraph

ある種のステートマシーン
LangChainを元にnode作ってedgeで繋いで...をコードで書くので、パッと見分かりにくいと評判
その内Xstateみたいにdictで表現できればいいなと思うけけど

でLangGraphの無料コースがある（約6時間）

LangGraph Studio

視覚的にLangGraphを動かせるIDE
現状LangGraphを視覚的に操作できるだけで、graphの編集機能はないと思う
Xstateのvisualizerに似てる

LangSmith

LangChain、LangGraphが複雑になる程に何がどうしてこうなったのか？とわからなくなるので、printデバッグ以外のトレーサーが必要になる
それがLangSmith

RAG

簡単に言うと検索できる外部記憶
結局LLMへ送信できるトークン数には上限があるので専門的な知識を全部渡して理解してもらおうとするには限度がある
なので、事前処理した（documentをembeddingしてvector storeに保存）データを元に、LLMへ投げる前に検索しておいて、LLMへ主要な部分だけを質問内容に繋げて聞くという手法

RAGはまだ成熟中のようで、どう言うchunkでembeddingした方が良いのかとか、Graph RAGとかAgentic RAGとか色々手探りな状況っぽい
その内LLMへ投げるトークン数が飛躍的に上がって、料金も下がる（又はローカルでも十分に動かせる）とかになればRAGは要らない？

なんとなく近い将来は専門知識を事前にトレーニングさせたプライベートなLLMを個別に持っておいて（ローカルなのかサービスとしてなのか）、その時々に適切なLLMを使うっていう感じになりそうだけど

AI Agent

LangGraphを組み上げていって、半自動で動くエージェントのようなものに仕立て上げたものって感じ

Human in the loop (HITL)

特定の処理で人間にその場で処理の判断を委ねる場合に使う

interruptで人間側に処理の判断を委ねる
Commandで人間の回答を返す

Functional API

LangGraphってもっさりして書きにくいし読みにくいよねを解消するβ版

memory

結局生のLLMはトレーニングした状態しか保持しておらず、毎度の問い合わせはstatelessなので、事前に聞いた事は何も考慮してくれない
（HTTPサーバーにcookieなしでアクセスしてるようなもの）

Agentまでくると事前に聞いた内容などを保持しておいて、それら過去の内容と合わせて回答を貰えるようにしたい、のでこれら以降のmemoryの使い分けが必要になる

Short term memory

StateやCheckpointが通常使われる

State

Agentみたいなものまででもなく普通にLangGraph（state machineとして）利用時には使うが、Xstateで言う所のcontextであり、LLMとのmessageを保存しておいたり、LLMとの会話で出てきた結果で重要なことを保存したりだとか
何を保存するかは自由

reducer

Stateを保存する際に各要素をどのように更新していくのかを決めるもの

例：

add_messages
- listにmessageを通常は簡単にappendする
- RemoveMessageをID付きで渡すとそのmessageをlistから消してくれる
operator.add
- 一般的なlistへのappendとしてのaddだったり、要は+演算子で出来ること
などで、独自に作ることも出来る

Module 2 - Lesson 2: State Reducers
https://academy.langchain.com/

MessagesState

LLMへのmessageは通常保存しておくものなのでMessagesStateが用意されている
これはadd_messagesをreducerとしているので、どんどん追記していく
なので、会話を続ければ続ける程流すトークン数が増えていく（最初からの会話を全部流すので）

やり方は色々あるんだろうけど、例えば10件messageが溜まったのならその10件をLLMへ投げて一旦summaryとして要約してもらい、その10件はmessagesから消して次回の問い合わせはsummary + messagesとか工夫が必要

summaryにするので情報は一部削られる事になる

Module2 - Lesson 5: Chatbot w/ Summarizing Messages and Memory
に例が出てくる
https://academy.langchain.com/

トークン数の上限がなくなるとか、ローカルで十分耐えれるLLMが動かせるとかになればこういう工夫も要らなくなりそう

Checkpoint

Stateの履歴のようなもの
Stateへの状態が変わる度にそれらをcheckpointとして保存しておいてくれて、例え同プロセスでなくても同じthread-idなら同じ情報が引き出せるし、過去のあるpointへ戻って再度LLMへ問い合わせたりとか出来る

必ずthread_idを指定して使う必要がある
InMemorySaverは開発時にサラッと簡単に使うため
小規模ならSqliteSaver
一般的にはPostgresSaver

Long term memory

Checkpointerはthread単位の保存
Long termはuser単位の保存

threadはある一定の会話（話題）についての長期的な保存であり、threadで出てきた内容で長期的に、且つ別threadでも使いたい情報（ユーザーの氏名とか住所とか）がある場合にこれを使う

thread間で同じ情報を共有したい場合の要はデータベース

InMemoryStore（開発時）とかPostgresStoreを使う

長期記憶のコンセプトとして3つに分けられ

Semantic
Episodic
Procedural

こういう概念で保存していくと良いよ的な話が書いてある

Trustcall

Module 5 - Lesson 4: Memory Schema + Collection

LLMには.with_structured_output()で定義したデータ型で返答してもらうように頼めるが、そのデータ型が複雑な場合はちゃんと処理できずに終わってしまう
これを解決するのがTrustcall

LLMに問い合わせる際にJSON丸ごとで返してと言わずに、JSONのpatch（差分）で返してくれといい具合に問い合わせてpatchを当てた最終的なJSONデータをstructured_outputとしてTrustcallが返してくれるようなイメージ

まとめ

全体的に使いこなせればすごいけど、まだv0.3とか0.2辺りで仕様変更も多いし（productionで使ってるところもあるらしいけど）、ライブラリ群の構成がゴロゴロ変わってるし、1ヶ月単位で追いつかないといけないぐらい
ちょっと古い情報を見てると全然違ったりするのでimportするだけでも大変