LangChainの概要をざっくり把握

## LangChain

### 概要

- AIベンダーのAPIコールするときに楽にしてくれるライブラリ
- 新しいアーキテクチャを簡単に実装できる
- エコシステムが発展しておりそれらのまとめ役

### 良いところ

- RAGやreAct, 長期記憶メモリなど、AIモデルをより活用するためのアーキテクチャを楽に実装できる
- 他のAIを活用するためのエコシステム(SaaSなど)との連携が容易
- LangChainを介することで、他AIベンダーへの切り替えコストが限りなく小さくなる

### 悪いところ

- ライブラリ内部クラスの多段の抽象化による巨大化, ブラックスボックス感
- OSSで人気ライブラリであることによる不安定さ

### LangChain独自記法 LCEL

- LangChainのコンセプトはAIモデルとエコシステム, ツールの連鎖 (Chaining)
- 簡単に再現するためにほかでは見ない独自記法が途中で用意された
- 以下のように シェルスクのパイプのような書き方をする
- `input_dict | エコシステム | AIモデル1 | AIモデル2 | ツール | AIモデル3 | -> output_dict`
- 最初は難しいが コンポーネントに dict が流れるだけと考えると楽
- 条件分岐や枝分かれして非同期同時実行もできる
- 以降で登場する [Agents, Prompts, Memory, Parser, RAG] などはLCELで簡単に適用できる

### Tools

- 一連の手続きを関数としてまとめたもの
- AIモデルと対比される要素であり、例としては以下のようなものがある
    - Google検索や外部APIとの連携
    - 特定のデータ処理や変換

### Agents

- 上記のツールをよしなに使用して問題を解決するもの
- つまり会話するだけでなくなにか実行能力をもって問題を解決することができる
- 特定のタスクに対して、Toolを使用することでAIの不安定という欠点を補うことができる

**ロジック**

- ToolsはToolの概要をテキストでもっています
- LangChainが内部(System Promptなどのイメージ)で単純にToolのリストと概要をAIに渡して使う必要があれば会話ではなくToolを呼ぶように指示しておく
- AIはユーザーと会話する必要があれば会話するし、Toolsを呼ぶ必要があれば呼ぶ

### Prompts

- Prompt Templateという機能が用意されている
- LCEL記法にて使用可能なフォーマット機能

### Memory

- 会話履歴を付加できる
- 会話履歴のClassを提供
- 永続化はDBとの連携が必要
- 色々な種類が提供されている
    - 文字数で切り捨てる
    - n 会話で切り捨てる
    - 切り捨てる会話を要約して末尾に保存する
    - 特定の情報を定期的に抽出する ( ユーザーのプロフィール)

### Parser

**Structed output parser**

- AIのレスポンスとしてjsonとかPydanticによる出力がほしいときに使う
- 前段のAIモデルに構造化出力のためのフォーマット指示をおこなう
- `input | AIモデル | Output parser | -> output_json`
- ただこの分野は、このような簡単な指示で出力を期待するより、AIベンダー側で実行されるアーキテクチャが最強
    
    [OpenAI Platform](https://platform.openai.com/docs/guides/structured-outputs)
    
- これらの機能を利用する場合、AIベンダーのAPIでリクエストする必要がります
- つまりこちらの責務はAIModel側にあるので`ChatOpenAI.with_structured_output()`で提供されている
    
    [How to return structured data from a model | 🦜️🔗 LangChain](https://python.langchain.com/docs/how_to/structured_output/)
    

### 関連アーキテクチャ ( LCEL で実装楽になる系)

**RAG**

- Retrieval argumented generation
- AIに会話リクエストするタイミングでAIに必要な情報を検索して**付加**して会話すること
- 検索の方法はいろいろ工夫できる箇所
    - 意味検索 (Semantic Search)
        - cos類似度などを用いた意味の近さで数値的に近いものを検索
            - embeddingモデルを用いて最初に数値にしておく必要がある
                - 文字を数値の配列に圧縮するため埋め込みと呼ばれる
                    - 1026次元とかあっても結局デジタルで表現するには、意味の切り捨てが起きてしまうイメージ
            - embeddingモデル自体もニューラルネットワークを利用する形とコーパス (AI用辞書) を利用する形があるっぽい( 要勉強 )
            - ベクトルDBに保存する必要がある
                - cloud db使ったり in memory でやったり docker image hostingしたりできる
    - ハイブリッド検索 (Hybrid Search)
        - 意味検索とキーワード検索をどちらも使う手法
    - キーワード検索
        - 従来の部分一致など

**Graph RAG**

- 情報のレコードとレコードに結びつきをもたせる
    
    https://tech.gmogshd.com/graphrag/
    
![c828680d7be53e881af09d6e5image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3716127/7ce81f42-b402-4196-baa4-81c99df2beeb.png)
    
- 意味的やキーワード的には遠いものにも、関係が設定されているため拾うことができる
    - 連鎖して3つノードを辿ったら、意味やキーワードは全く異なることがある
    - 人間の脳みそは、そういった関係のなさそうなことにも、関係を見出して考えることができる。それに近づけることができるのが、強みだと思います
    - e.g. User: プロジェクトに付いてのアドバイスを求める
        - プロジェクトの概要 → プロジェクトの顧客情報 → 顧客企業の市場 → **関係した市場**
        - このようにたどることができ 関係のなさそうな **関係した市場** のような情報も鑑みてアドバイスできるかも
    - Obsidianを使っているとイメージがつく

### LangSmith (observability)

- Chainの実行をLCELコンポーネント単位で詳細に監視できる
- データセットを作成したり、回答を評価する基盤を提供

### LangFlow

- 初級者向け
- 個人的に好き
- GUIでLCELコンポーネントを構築できる (ローコード, ノーコード)
- Astraという Cloud Databaseのプロバイダが、SaaSとして提供している

https://www.langflow.org/

- Difyと同等の製品で、こちらのほうが完成度が高い印象

### LangGraph

- 状態管理とLCELコンポーネントの自由なハンドルができる (ステートマシンの概念を取り入れている)
- LCELではできない、状態管理して自由にコンポーネントを使いまわしたり、無限にコンポーネントをループさせたりができるようになる
- 上級者向け

### **LangServe**

- FastAPIを用いて一瞬でLCELロジックをホスティングできる