LLMアプリケーションのための新しいアーキテクチャ

xguru · 2023-07-03T11:04:02+09:00

a16zがまとめた「LLMアプリスタックのためのリファレンスアーキテクチャ」 Emerging LLM App Stack Contextual Data Data Pipelines: Databricks, Airflow, Unstructured,.. Embedding Model: OpenAI, Cohere, Hugging Face Vector Database: Pinecone, Weaviate, Chroma, pgvector Prompt Few-shot Examples Playground: OpenAI, nat.dev, Humanloop Orchestration: Pytion/DIY, LangChain, LlamaIndex, ChatGPT APIs/Plugins: Serp, Wolfram, Zapier,... Query & Output App Hosting: Vercel, Steamship, Streamlit, Modal LLM Cache: Redis, SQLite, GPTCache Logging/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone Validation: Guardrails, Rebuff, Guidance, LMQL LLM APIs and Hosting Proprietary API: OpenAI, Anthropic Open API: Hugging Face, Replicate Cloud Provider: AWS, GCP, Azure, Coreweave Opinionated Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,... Design Pattern: In-context Learning In-Context Learning: LLMをファインチューニングせずそのまま使い、賢いプロンプティングと一部の「Contextual」データに基づく条件を利用すること例）法律文書について回答するチャットボットを作るとき、ナイーブに作るならすべての文書をChatGPTに入れて質問すればよいが、それが可能なのは小さなデータセットに限られる。ChatGPTの最大モデルでも処理できるのは約50ページ程度にすぎない In-Context Learningでは、関連する文書だけを送り、その中から回答を得る方式を取るそのため、次のような3段階のワークフローで構成される Step 1. データ前処理 / 埋め込み Step 2. プロンプト生成 / ベクターDBから関連文書をRetrieval Step 3. プロンプト実行 / 推論多くの作業が必要に見えるが、LLM自体を訓練・ファインチューニングするよりはるかに簡単 Step 1. [Data preprocessing / embedding] → Contextual DataがData Piplineを通ってEmbdeing Modelを経由し、Vector Databaseに保存される Contextual Data テキスト文書、PDF、CSVおよびSQLテーブル多くの場合、データのロードと変換には既存のETLツール（Databricks、Airflow）をそのまま使う一部では、LangChainやLlamaIndexのようなオーケストレーションフレームワークに組み込まれたドキュメントローダーを利用するスタックのこの部分はまだ相対的に開発が進んでおらず、LLMアプリ向けに特化したデータレプリケーションソリューションには機会がある Embeddings ほとんどの開発者はOpenAI APIを使用している（text-embedding-ada-002モデル）使いやすく、十分に良い結果を出し、しかもますます低コストになっている一部の大企業はCohereを検討中。特定のシナリオではより良い性能を提供するオープンソースを好む開発者にとっては、Hugging FaceのSentence Transformersライブラリが標準また、ユースケースに合ったさまざまな種類の埋め込みを生成することも可能これはニッチなケースだが、有望な研究分野でもある Vector Database 前処理パイプラインで最も重要な部分はベクターデータベース最大で数十億件の埋め込み（ベクトル）を効率的に保存・比較・検索する役割を担う市場で最も一般的な選択肢はPinecone 完全にクラウドでホスティングされており、始めやすい大規模企業が本番環境で必要とする多くの機能を備えている（高い性能、SSO、アップタイムSLAなど）ただし、利用可能なベクターデータベースは非常に多い。特に: Weaviate、Vespa、Qdrantのようなオープンソース優れたシングルノード性能を提供し、特定のアプリ向けに調整できるカスタムプラットフォーム構築を好む熟練したAIチームに人気 Chroma、Faissのようなローカルベクター管理ライブラリ優れた開発者体験小規模アプリや開発実験のために容易に運用できる完全な大規模データベースの代替ではない pgvectorのようなOLTP拡張あらゆるデータベース要件にPostgresを当てはめたい開発者や、単一クラウドプロバイダーから大半のデータインフラを調達する企業にとって、ベクター対応のよい解決策長期的に見て、ベクターとスカラーのワークロードを密結合するのが妥当かどうかは明らかではない今後を見ると、ほとんどのオープンソースベクターデータベース企業がクラウド製品を開発中私たちの調査によれば、クラウド上で多様なユースケースに対して優れた性能を出すのは非常に難しいしたがって、こうした選択は短期的には変わらないかもしれないが、長期的には変わる可能性が高い核心的な問いは、ベクターデータベースがOLTPやOLAPのように、1つまたは2つの著名なシステムへ統合されるのかどうかもう1つの問いは、ほとんどのモデルで利用可能なコンテキストウィンドウが大きくなるにつれて、埋め込みとベクターデータベースがどう進化するかという点コンテキストデータをすべてプロンプトに載せられるのだから埋め込みは不要になる、と言いたくなる誘惑はあるが、これに対する専門家のフィードバックでは、埋め込みパイプラインはむしろますます重要になる可能性があるという大きなコンテキストウィンドウは強力なツールだが、相当な計算コストを伴う。したがって、それを効率よく使うことが優先される今後はさまざまな種類の埋め込みモデルが一般化し、モデルの関連性を持って直接訓練され、それを効率的に有効化・活用するベクターデータベースが見られるようになるだろう Step 2. [Prompt construction / retrieval] LLMプロンプティングと状況に応じたデータを統合する戦略はますます複雑になっており、製品差別化の源泉としても重要性が増しているほとんどの開発者は、直接的な指示（ゼロショットプロンプティング）またはいくつかの例を含むもの（Few-shotプロンプティング）から成るシンプルなプロンプトで新しいプロジェクトを始めるこうしたプロンプトでも良い結果が出ることはあるが、本番投入に必要な精度レベルには達しないプロンプティングの次の段階は、モデル応答の根拠を何らかの真実のソースに置き、モデルが訓練されていない外部コンテキストを提供するよう設計すること Prompt Engineering Guide では12の高度なプロンプト戦略が整理されているこのときLangChainやLlamaIndexのようなオーケストレーションフレームワークが真価を発揮するこれらはプロンプトチェーンの多くの詳細を抽象化する外部API連携、ベクターデータベースからの文脈データ検索、複数回のLLM呼び出し間でのメモリ保持などまた、多くの一般的なプログラム向けテンプレートも提供するこれらの出力は、言語モデルに送るプロンプト、または複数のプロンプト群スタートアップやホビー開発者の間ではLangChainが最も多く使われている LangChainはまだ新しいプロジェクトである（現在のバージョンは0.0.220）それでも、すでにこれを使ったアプリが本番環境に載り始めている一部の開発者、特にLLMのアーリーアダプターは、依存関係を減らすため本番では素のPythonへ切り替えることを好むしかし私たちは、このDIY方式はWebアプリスタックと同じように徐々に減っていくと考えている（多くはフレームワークを使うようになる）注意深い読者なら、オーケストレーションの枠の中にChatGPTがあるのを見つけたはず一般にはChatGPTは開発者ツールではなくアプリだが、API経由でアクセスできるある意味では、こうしたオーケストレーションフレームワークと似た動作をする（プロンプトの抽象化、状態保持、プラグインによる文脈データ検索など）ここで挙げたツール群の直接的な競合ではないが、ChatGPTは代替ソリューションとみなせる。素早く構成して使えるシンプルな代替になりうる Step 3. [Prompt execution / inference] 現時点でOpenAIは言語モデル分野のリーダーほぼすべての開発者がGPT-4、GPT-4-32kモデルでLLMアプリ開発を始める使いやすく、さまざまなドメインで利用でき、ファインチューニングやセルフホスティングも不要本番に入り規模が大きくなると、さまざまな選択肢が出てくる gpt-3.5-turbo へ切り替える: 50倍以上安く、GPT-4よりはるかに高速 GPT-4レベルの精度が不要で、速い応答時間が必要、あるいは無料ユーザーを効率よく支援したいときの選択肢他ベンダーのモデルを試す（特にAnthropicのClaudeモデル） Claudeは高速な推論、GPT-3.5レベルの精度、より多くのカスタムオプションを提供し、最大100kのコンテキストウィンドウを持つ（ただし長くなると精度は落ちる）一部のリクエストをオープンソースモデルへ振り分けるさまざまなクエリ複雑度があり、無料ユーザーを低コストで提供しなければならない検索/チャットのような大規模B2Cユースケースでは有効になりうるオープンソースモデルは現在、独占的な製品を追う立場だが、その差は縮まり始めている MetaのLLaMAモデルはオープンソース精度の新たな基準を打ち立て、さまざまな派生を生み出した LLaMAは研究用途にのみ許諾されていたが、代替となる基盤モデル（Together、Mosaic、Falcon、Mistral）を訓練するために多くのプロバイダーが参入した Metaは真のオープンソースLLaMA 2モデルをリリースする方向で議論中オープンソースLLMがGPT-3.5に近い精度水準へ到達すれば、テキスト分野でもStable Diffusion Momentのようなものが期待される大規模な実験、共有、ファインチューニング済みモデルの本番化など Replicateのようなホスティング企業は、開発者がこうしたモデルをより簡単に使えるよう、すでにツールを追加しているより小さくてもファインチューニングされたモデルが最先端モデルの精度に到達できるという開発者の確信は強まっている私たちが話を聞いた開発者の大半は、LLM向けの運用ツールについてはまだ深く踏み込んでいなかったキャッシングは一般的で、通常はRedisが使われる（応答時間とコストを改善するため） Weights & Biases、MLFlow、PromptLayer、Heliconeのようなツールも多く使われている迅速なプロンプト作成、パイプライン調整、モデル選定のために、LLM出力をログ・追跡・評価できる LLM出力の検証（Guardrails）や、プロンプトインジェクション検知（Rebuff）のようなツールも数多く登場しているこうした運用ツールの大半は、自前のPythonクライアントを使ってLLM呼び出しを行うことを推奨しており、今後どのように共存していくかを見るのも興味深い最後に、LLMの静的部分（モデル以外のすべて）もどこかでホスティングされる必要がある最も一般的な解決策はVercelまたは主要クラウドプロバイダーしかし、新たに2つのカテゴリが出現している SteamshipはLLMアプリ向けのエンドツーエンドホスティングを提供し、オーケストレーション（LangChain）、マルチテナントのデータコンテキスト、非同期タスク、ベクターストア、キー管理などの機能を提供する AnyscaleとModalは、開発者がモデルとPythonコードを同時にホスティングできるようにする Agentは？このリファレンスアーキテクチャで欠けている最も重要な要素はAI Agent Framework AutoGPT は「GPT-4を完全に自律化するためのオープンソース実験」として、この春に史上最速で成長したGitHubリポジトリだった最近のあらゆるAIプロジェクトには、何らかの形でエージェントが含まれている私たちが対話した開発者の多くは、エージェントの潜在力に非常に興奮しているこの記事で説明したインコンテキスト学習パターンは、コンテンツ生成タスクをよりよく支援し、ハルシネーションとデータ鮮度の問題を解決するのに適している一方でエージェントは、AIアプリに根本的に新しい機能を与える複雑な問題を解決したり、外部世界に対してアクションを起こしたり、デプロイ後も経験から学習したり高度な推論/計画、ツール利用、メモリ/再帰/自己省察などの組み合わせによってこれを実現するエージェントはLLMアプリのアーキテクチャにおける中心的な部分になる可能性がある（再帰による自己発展を信じるなら、スタック全体を占めることさえありうる）すでにLangChainのようなフレームワークはエージェントの概念を統合しているただ1つの問題は、エージェントはまだきちんと動作しないこと現在のエージェントフレームワークの大半はPoC段階にある。驚くようなデモは可能だが、安定しておらず再現性もないそれらがどう進化するかを注視している今後を見据えて事前学習済みAIモデルは、インターネット以降のソフトウェアにおける最も重要なアーキテクチャ変化であるこれにより各開発者は、大規模チームが構築するのに数か月かかる教師あり機械学習プロジェクトを上回るAIアプリを、数日で構築できるここで紹介したツールとパターンは最終形ではなく、LLM統合の出発点にすぎない可能性が高い

(a16z.com)

38 ポイント投稿者 xguru 2023-07-03 | 6件のコメント | WhatsAppで共有

a16zがまとめた「LLMアプリスタックのためのリファレンスアーキテクチャ」

Emerging LLM App Stack

Contextual Data

Data Pipelines: Databricks, Airflow, Unstructured,..
Embedding Model: OpenAI, Cohere, Hugging Face
Vector Database: Pinecone, Weaviate, Chroma, pgvector

Prompt Few-shot Examples

Playground: OpenAI, nat.dev, Humanloop
Orchestration: Pytion/DIY, LangChain, LlamaIndex, ChatGPT
APIs/Plugins: Serp, Wolfram, Zapier,...

Query & Output

App Hosting: Vercel, Steamship, Streamlit, Modal
LLM Cache: Redis, SQLite, GPTCache
Logging/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone
Validation: Guardrails, Rebuff, Guidance, LMQL

LLM APIs and Hosting

Proprietary API: OpenAI, Anthropic
Open API: Hugging Face, Replicate
Cloud Provider: AWS, GCP, Azure, Coreweave
Opinionated Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,...

Design Pattern: In-context Learning

In-Context Learning: LLMをファインチューニングせずそのまま使い、賢いプロンプティングと一部の「Contextual」データに基づく条件を利用すること
例）法律文書について回答するチャットボットを作るとき、ナイーブに作るならすべての文書をChatGPTに入れて質問すればよいが、それが可能なのは小さなデータセットに限られる。ChatGPTの最大モデルでも処理できるのは約50ページ程度にすぎない
In-Context Learningでは、関連する文書だけを送り、その中から回答を得る方式を取る
そのため、次のような3段階のワークフローで構成される
- Step 1. データ前処理 / 埋め込み
- Step 2. プロンプト生成 / ベクターDBから関連文書をRetrieval
- Step 3. プロンプト実行 / 推論
多くの作業が必要に見えるが、LLM自体を訓練・ファインチューニングするよりはるかに簡単

Step 1. [Data preprocessing / embedding]

→ Contextual DataがData Piplineを通ってEmbdeing Modelを経由し、Vector Databaseに保存される

Contextual Data

テキスト文書、PDF、CSVおよびSQLテーブル
多くの場合、データのロードと変換には既存のETLツール（Databricks、Airflow）をそのまま使う
一部では、LangChainやLlamaIndexのようなオーケストレーションフレームワークに組み込まれたドキュメントローダーを利用する
スタックのこの部分はまだ相対的に開発が進んでおらず、LLMアプリ向けに特化したデータレプリケーションソリューションには機会がある

Embeddings

ほとんどの開発者はOpenAI APIを使用している（text-embedding-ada-002モデル）
- 使いやすく、十分に良い結果を出し、しかもますます低コストになっている
一部の大企業はCohereを検討中。特定のシナリオではより良い性能を提供する
オープンソースを好む開発者にとっては、Hugging FaceのSentence Transformersライブラリが標準
また、ユースケースに合った さまざまな種類の埋め込みを生成 することも可能
- これはニッチなケースだが、有望な研究分野でもある

Vector Database

前処理パイプラインで最も重要な部分はベクターデータベース
最大で数十億件の埋め込み（ベクトル）を効率的に保存・比較・検索する役割を担う
市場で最も一般的な選択肢はPinecone
- 完全にクラウドでホスティングされており、始めやすい
- 大規模企業が本番環境で必要とする多くの機能を備えている（高い性能、SSO、アップタイムSLAなど）
ただし、利用可能なベクターデータベースは非常に多い。特に:
- Weaviate、Vespa、Qdrantのようなオープンソース
  - 優れたシングルノード性能を提供し、特定のアプリ向けに調整できる
  - カスタムプラットフォーム構築を好む熟練したAIチームに人気
- Chroma、Faissのようなローカルベクター管理ライブラリ
  - 優れた開発者体験
  - 小規模アプリや開発実験のために容易に運用できる
  - 完全な大規模データベースの代替ではない
- pgvectorのようなOLTP拡張
  - あらゆるデータベース要件にPostgresを当てはめたい開発者や、単一クラウドプロバイダーから大半のデータインフラを調達する企業にとって、ベクター対応のよい解決策
  - 長期的に見て、ベクターとスカラーのワークロードを密結合するのが妥当かどうかは明らかではない
今後を見ると、ほとんどのオープンソースベクターデータベース企業がクラウド製品を開発中
- 私たちの調査によれば、クラウド上で多様なユースケースに対して優れた性能を出すのは非常に難しい
- したがって、こうした選択は短期的には変わらないかもしれないが、長期的には変わる可能性が高い
- 核心的な問いは、ベクターデータベースがOLTPやOLAPのように、1つまたは2つの著名なシステムへ統合されるのかどうか
もう1つの問いは、ほとんどのモデルで利用可能なコンテキストウィンドウが大きくなるにつれて、埋め込みとベクターデータベースがどう進化するかという点
- コンテキストデータをすべてプロンプトに載せられるのだから埋め込みは不要になる、と言いたくなる誘惑はあるが、
- これに対する専門家のフィードバックでは、埋め込みパイプラインはむしろますます重要になる可能性があるという
- 大きなコンテキストウィンドウは強力なツールだが、相当な計算コストを伴う。したがって、それを効率よく使うことが優先される
今後はさまざまな種類の埋め込みモデルが一般化し、モデルの関連性を持って直接訓練され、それを効率的に有効化・活用するベクターデータベースが見られるようになるだろう

Step 2. [Prompt construction / retrieval]

LLMプロンプティングと状況に応じたデータを統合する戦略はますます複雑になっており、製品差別化の源泉としても重要性が増している
ほとんどの開発者は、直接的な指示（ゼロショットプロンプティング）またはいくつかの例を含むもの（Few-shotプロンプティング）から成るシンプルなプロンプトで新しいプロジェクトを始める
こうしたプロンプトでも良い結果が出ることはあるが、本番投入に必要な精度レベルには達しない
プロンプティングの次の段階は、モデル応答の根拠を何らかの真実のソースに置き、モデルが訓練されていない外部コンテキストを提供するよう設計すること
Prompt Engineering Guide では12の高度なプロンプト戦略が整理されている
このときLangChainやLlamaIndexのようなオーケストレーションフレームワークが真価を発揮する
- これらはプロンプトチェーンの多くの詳細を抽象化する
- 外部API連携、ベクターデータベースからの文脈データ検索、複数回のLLM呼び出し間でのメモリ保持など
- また、多くの一般的なプログラム向けテンプレートも提供する
- これらの出力は、言語モデルに送るプロンプト、または複数のプロンプト群
- スタートアップやホビー開発者の間ではLangChainが最も多く使われている
LangChainはまだ新しいプロジェクトである（現在のバージョンは0.0.220）
- それでも、すでにこれを使ったアプリが本番環境に載り始めている
- 一部の開発者、特にLLMのアーリーアダプターは、依存関係を減らすため本番では素のPythonへ切り替えることを好む
- しかし私たちは、このDIY方式はWebアプリスタックと同じように徐々に減っていくと考えている（多くはフレームワークを使うようになる）
注意深い読者なら、オーケストレーションの枠の中にChatGPTがあるのを見つけたはず
- 一般にはChatGPTは開発者ツールではなくアプリだが、API経由でアクセスできる
- ある意味では、こうしたオーケストレーションフレームワークと似た動作をする（プロンプトの抽象化、状態保持、プラグインによる文脈データ検索など）
- ここで挙げたツール群の直接的な競合ではないが、ChatGPTは代替ソリューションとみなせる。素早く構成して使えるシンプルな代替になりうる

Step 3. [Prompt execution / inference]

現時点でOpenAIは言語モデル分野のリーダー
ほぼすべての開発者がGPT-4、GPT-4-32kモデルでLLMアプリ開発を始める
使いやすく、さまざまなドメインで利用でき、ファインチューニングやセルフホスティングも不要
本番に入り規模が大きくなると、さまざまな選択肢が出てくる
- gpt-3.5-turbo へ切り替える:
  - 50倍以上安く、GPT-4よりはるかに高速
  - GPT-4レベルの精度が不要で、速い応答時間が必要、あるいは無料ユーザーを効率よく支援したいときの選択肢
- 他ベンダーのモデルを試す（特にAnthropicのClaudeモデル）
  - Claudeは高速な推論、GPT-3.5レベルの精度、より多くのカスタムオプションを提供し、最大100kのコンテキストウィンドウを持つ（ただし長くなると精度は落ちる）
- 一部のリクエストをオープンソースモデルへ振り分ける
  - さまざまなクエリ複雑度があり、無料ユーザーを低コストで提供しなければならない検索/チャットのような大規模B2Cユースケースでは有効になりうる
オープンソースモデルは現在、独占的な製品を追う立場だが、その差は縮まり始めている
- MetaのLLaMAモデルはオープンソース精度の新たな基準を打ち立て、さまざまな派生を生み出した
- LLaMAは研究用途にのみ許諾されていたが、代替となる基盤モデル（Together、Mosaic、Falcon、Mistral）を訓練するために多くのプロバイダーが参入した
- Metaは真のオープンソースLLaMA 2モデルをリリースする方向で議論中
オープンソースLLMがGPT-3.5に近い精度水準へ到達すれば、テキスト分野でもStable Diffusion Momentのようなものが期待される
- 大規模な実験、共有、ファインチューニング済みモデルの本番化など
- Replicateのようなホスティング企業は、開発者がこうしたモデルをより簡単に使えるよう、すでにツールを追加している
- より小さくてもファインチューニングされたモデルが最先端モデルの精度に到達できるという開発者の確信は強まっている
私たちが話を聞いた開発者の大半は、LLM向けの運用ツールについてはまだ深く踏み込んでいなかった
- キャッシングは一般的で、通常はRedisが使われる（応答時間とコストを改善するため）
- Weights & Biases、MLFlow、PromptLayer、Heliconeのようなツールも多く使われている
  - 迅速なプロンプト作成、パイプライン調整、モデル選定のために、LLM出力をログ・追跡・評価できる
- LLM出力の検証（Guardrails）や、プロンプトインジェクション検知（Rebuff）のようなツールも数多く登場している
- こうした運用ツールの大半は、自前のPythonクライアントを使ってLLM呼び出しを行うことを推奨しており、今後どのように共存していくかを見るのも興味深い
最後に、LLMの静的部分（モデル以外のすべて）もどこかでホスティングされる必要がある
- 最も一般的な解決策はVercelまたは主要クラウドプロバイダー
- しかし、新たに2つのカテゴリが出現している
  - SteamshipはLLMアプリ向けのエンドツーエンドホスティングを提供し、オーケストレーション（LangChain）、マルチテナントのデータコンテキスト、非同期タスク、ベクターストア、キー管理などの機能を提供する
  - AnyscaleとModalは、開発者がモデルとPythonコードを同時にホスティングできるようにする

Agentは？

このリファレンスアーキテクチャで欠けている最も重要な要素はAI Agent Framework
AutoGPT は「GPT-4を完全に自律化するためのオープンソース実験」として、この春に史上最速で成長したGitHubリポジトリだった
最近のあらゆるAIプロジェクトには、何らかの形でエージェントが含まれている
私たちが対話した開発者の多くは、エージェントの潜在力に非常に興奮している
- この記事で説明したインコンテキスト学習パターンは、コンテンツ生成タスクをよりよく支援し、ハルシネーションとデータ鮮度の問題を解決するのに適している
- 一方でエージェントは、AIアプリに根本的に新しい機能を与える
  - 複雑な問題を解決したり、外部世界に対してアクションを起こしたり、デプロイ後も経験から学習したり
  - 高度な推論/計画、ツール利用、メモリ/再帰/自己省察などの組み合わせによってこれを実現する
- エージェントはLLMアプリのアーキテクチャにおける中心的な部分になる可能性がある（再帰による自己発展を信じるなら、スタック全体を占めることさえありうる）
- すでにLangChainのようなフレームワークはエージェントの概念を統合している
- ただ1つの問題は、エージェントはまだきちんと動作しないこと
- 現在のエージェントフレームワークの大半はPoC段階にある。驚くようなデモは可能だが、安定しておらず再現性もない
- それらがどう進化するかを注視している

今後を見据えて

事前学習済みAIモデルは、インターネット以降のソフトウェアにおける最も重要なアーキテクチャ変化である
これにより各開発者は、大規模チームが構築するのに数か月かかる教師あり機械学習プロジェクトを上回るAIアプリを、数日で構築できる
ここで紹介したツールとパターンは最終形ではなく、LLM統合の出発点にすぎない可能性が高い

6件のコメント

sysmoon 2023-07-06

洞察に富み、積み重ねた経験が感じられる文章ですね。
この内容をもとにLLMアプリのアーキテクチャを設計するうえで、大いに役立ちそうです。

エコシステムでは分野別に明確な勝者がいないため、多くのソリューションが混在している状況で、
選択の問題が増え、自分の要件に合った適切な組み合わせを見つけること自体が能力になる時期なのだと思います。

nicewook 2023-07-04

これはとても内容の充実した記事ですね。じっくり読み進めています。

cwyang 2023-07-03

LLMにGNを学習させれば、グル様も楽になるでしょうか？ ^^;
ありがとうございます。

cwyang 2023-07-03

おっと、GN+ を作られたんですね :-o

xguru 2023-07-04

便利にはなりそうですが、こういう文章は勉強だと思ってこれからも読み続ける気がします。はは
GN⁺ がほかのニュースを全部処理してくれたら、こういう記事がもっと増える効果が生まれるかもしれません！

cosine20 2023-07-03

良い記事と要約をありがとうございます。

LLMアプリケーションのための新しいアーキテクチャ

Emerging LLM App Stack

Contextual Data

Prompt Few-shot Examples

Query & Output

LLM APIs and Hosting

Design Pattern: In-context Learning

Step 1. [Data preprocessing / embedding]

Contextual Data

Embeddings

Vector Database

Step 2. [Prompt construction / retrieval]

Step 3. [Prompt execution / inference]

Agentは？

今後を見据えて

関連記事

6件のコメント