クライアントサイド技術を用いたLLM搭載Webアプリの構築
WebアプリケーションのためのローカルLLM統合
ローカルモデルとクライアントサイド技術のみを使用してWebアプリケーションを構築することで、OpenAIやAnthropicのようなプロバイダーへの高価なAPIコールを回避できます。このアプローチには、主に3つの利点があります。開発者にとっての追加の計算コストがゼロであること、データがローカルマシンを離れないためユーザーのプライバシーが強化されること、そしてHTTPコールのオーバーヘッドを排除することで速度が向上する可能性があることですが、これはユーザーのハードウェアの制限によって相殺される可能性があります。
ローカルRAGパイプラインの実装
Retrieval-Augmented Generation (RAG) は、非構造化データから情報を抽出することで、ユーザーが「自分のドキュメントとチャットする」ことを可能にします。完全にローカルなRAGパイプラインは、主に「データの取り込み」と「検索/生成」の2つのフェーズで構成されます。
データ取り込み
データ取り込みは、3つのステップを通じて、生のドキュメント(PDFやウェブページなど)を検索可能な形式に変換します:
- Semantic Chunking: ドキュメントをより小さく、意味のある断片に分割すること。
- Vector Representation: 埋め込みモデルを使用して、各チャンクの埋め込み(embeddings)を作成すること。
- Vector Storage: これらのチャンクとベクトルを専用のベクトルストアにロードすること。
この実装では、LangChainがドキュメントのロードと分割を担当しました。埋め込みは Transformers.js パッケージを介して量子化されたHuggingFaceモデルを使用して生成され、ベクトルストアはWeb Assemblyベースのベクトルストアである Voy によって管理されました。
検索と生成
ユーザーのクエリに答えるために、システムはベクトルストアから入力に意味的に最も類似したドキュメントチャンクを検索します。これらのチャンクは、元の質問と組み合わされて、LLMが最終的な回答を生成するためのガイドとなります。
代名詞や以前のチャット履歴への参照を含むフォローアップの質問に対しては、デリファレンシング(参照解除)のステップが追加されます。このステップでは、ベクトルストアの検索が正確に保たれるように、最初のクエリを「スタンドアロン」な質問に言い換えます。
ローカルWebアプリにおけるOllamaの役割
タスク特化型のモデル(埋め込みなど)はブラウザ内で効率的に実行できますが、フルスケールのLLMは通常、Webアプリケーションに直接バンドルするには大きすぎます。著者は、ブラウザベースのLLMプロジェクトは、高品質な回答を生成できないか、あるいは数ギガバイトのダウンロードが必要となり、大幅な遅延が発生するという問題に直面することが多いと指摘しています。
Ollamaは、シェルコマンドを介してローカルで実行されているモデルをWebアプリケーションに公開することで、この問題を解決します。説明されているプロジェクトでは、Mistral 7B モデルが使用され、16GB M2 MacBook Pro上で効果的に動作しました。これにより、Webアプリは、モデルをアプリのバンドル内に含めて配信するオーバーヘッドなしに、ユーザーのマシン上でプリインストールされた強力なLLMを活用できます。
将来の展望とブラウザAPIの提案
オープンソースモデルがより小さく、より高速になり、コンシューマー向けハードウェアにGPUが搭載されることが増えるにつれて、ローカルLLMの実行はより現実的なものになりつつあります。しかし、非技術的なユーザーがCORSを設定したりサーバーを起動したりするためにシェルコマンドを実行する可能性は低いため、よりシームレスな統合が必要です。
著者は、Webアプリケーションがポップアップを介してローカルで実行されているLLMへのアクセス権をリクエストできる新しいブラウザAPIを提案しています。これにより、アプリは手動の技術的な設定を必要とせずに、他のブラウザ内技術とともにローカルの計算能力を活用できるようになります。
Sources
関連
- Dispatch
- プロジェクト
- プロジェクト
- プロジェクト
- プロジェクト