Open9

RAGアプリ検討

hiraokuhiraoku

構造。具体的なアプリはあくまで参考。

  1. データ収集層:

    • PCの操作ログを収集するエージェント
    • ブラウザ履歴を取得するブラウザ拡張機能
    • その他のアプリケーションログ収集ツール
  2. データ処理層:

    • 収集したデータを統合し、構造化するETLプロセス
    • テキストデータの前処理(クリーニング、正規化)
  3. インデックス化層:

    • ベクトルデータベース(例:Pinecone、Milvus、Qdrant)
    • 全文検索エンジン(例:Elasticsearch)
  4. 知識ベース:

    • 処理されたデータを格納するデータベース
  5. 検索・質問応答エンジン:

    • 自然言語処理モデル(例:GPT、BERT)
    • RAGアルゴリズムの実装
  6. ユーザーインターフェース:

    • チャットボットインターフェース
    • Web アプリケーションまたはデスクトップアプリケーション
  7. セキュリティ層:

    • データ暗号化
    • アクセス制御
    • プライバシー保護機能
hiraokuhiraoku

要件の整理

  • 目的: ブラウザの履歴を活用し、ユーザーが過去に訪れたが忘れてしまったウェブサイトを見つけ出す。
  • データ:
    • ブラウザ履歴: URL、タイトル、アクセス日時。
    • ウェブページの内容: 各URLから取得したテキストデータ。
  • ユーザーの質問:
    • 自然言語で曖昧な期間やキーワードを含む。
    • 例:
      • 「10日前くらいでカレーのレシピについてのサイトを見たのですが、どこのサイトだったか忘れてしまいました。検索履歴から候補を10件ほど見つけてもらえますか?」
      • 「1ヶ月前から現在までで、React19の情報について記載したサイトを見て、そこにuseの使い方について書いたサイトがあったのですが、忘れてしまいました。検索履歴から近しいものを何件かピックアップしてもらえますか?」

技術選定

1. ブラウザ履歴の取得

  • 言語: Python
  • ライブラリ:
    • browser-history: 複数のブラウザ(Chrome、Firefox、Edgeなど)から履歴を取得可能。
  • 理由:
    • クロスプラットフォームでのブラウザ履歴取得を簡素化。
    • SQLiteデータベースへの直接アクセスを避け、抽象化されたAPIで安全に取得。

2. ウェブページの内容取得

  • 言語: Python
  • ライブラリ:
    • Requests: HTTPリクエストを送信。
    • BeautifulSoup(bs4): HTMLパースとテキスト抽出。
  • 理由:
    • シンプルで強力なウェブスクレイピングが可能。
    • エラー処理やリクエストの制御が容易。

3. データのベクトル化

  • ライブラリ:
    • SentenceTransformers(Hugging Face Transformers): テキストデータを高品質なベクトル表現に変換。
  • 理由:
    • テキストの意味的な類似性をキャプチャできる埋め込みを生成。
    • 多言語対応で日本語のテキストも扱える。

4. ベクトルデータベース

  • 選択肢:
    • FAISS(Facebook AI Similarity Search): ローカル環境で高速なベクトル検索が可能。
    • Pinecone: クラウドベースでスケーラブルなベクトル検索サービス。
    • Weaviate: オープンソースのベクトル検索エンジン。
  • 理由:
    • ベクトル化されたデータから意味的に類似した項目を高速に検索。
    • データ量や運用コストに応じて選択可能。

5. 自然言語処理(NLP)と質問解析

  • ライブラリ:
    • spaCy: 高速で効率的なNLPライブラリ。エンティティ抽出に使用。
    • dateparser: 自然言語で表現された日付や時間を解析。
  • 理由:
    • ユーザーの質問文から期間やキーワード、件数を抽出。
    • 日本語モデルを使用して精度の高い解析が可能。

6. 大規模言語モデル(LLM)の活用

  • フレームワーク:
    • LangChain: LLMを組み込んだアプリケーションを構築するためのフレームワーク。
  • サービス:
    • OpenAI GPT-3.5 / GPT-4: 質問解析と回答生成に使用。
  • 理由:
    • 複雑な自然言語の理解と応答生成が可能。
    • LangChainを使うことで、LLMの活用が容易に。

7. バックエンド

  • フレームワーク:
    • FastAPI(Python)
  • 理由:
    • 高速な非同期処理が可能。
    • Pythonで統一された技術スタックにより、学習コストを削減。

8. フロントエンド

  • フレームワーク:
    • React + Next.js
  • 理由:
    • ユーザーインターフェースの構築に柔軟性が高い。
    • サーバーサイドレンダリングによりSEO対策も可能。

9. データベース

  • 選択肢:
    • PostgreSQL: 履歴メタデータやユーザー情報の管理。
    • MongoDB: 柔軟なスキーマが必要な場合。
  • 理由:
    • 構造化データの保存と管理が容易。

10. デプロイとインフラ

  • コンテナ化:
    • Docker: アプリケーションの環境を一貫性を持って管理。
  • オーケストレーション:
    • Docker Compose: 開発環境での複数コンテナの管理。
    • Kubernetes(必要に応じて): スケーラブルな運用が必要な場合。
  • クラウドサービス:
    • AWS / GCP / Azure: サーバーやデータベース、LLMのホスティング。
    • Vercel: フロントエンド(Next.js)のホスティングに最適。

アーキテクチャの概要

  1. データ取得・更新フェーズ:

    • ブラウザ履歴の取得:
      • browser-historyライブラリで定期的にユーザーのブラウザ履歴を取得。
    • ウェブページ内容のスクレイピング:
      • 新規または更新された履歴項目について、RequestsBeautifulSoupでページ内容を取得。
    • データのベクトル化:
      • ページ内容をSentenceTransformersでベクトル化。
    • ベクトルデータベースへの保存:
      • ベクトルデータと対応するメタデータ(URL、タイトル、アクセス日時)をベクトルデータベースに保存。
  2. ユーザーの質問解析フェーズ:

    • 質問の入力:
      • フロントエンドでユーザーが自然言語で質問を入力。
    • 質問の解析:
      • バックエンドでspaCydateparserを使い、質問からキーワード、期間、件数を抽出。
    • 質問のベクトル化:
      • 抽出したキーワードや質問全文をベクトル化。
  3. 検索・推論フェーズ:

    • ベクトル検索:
      • ベクトルデータベースで質問のベクトルに類似した履歴項目を検索。
      • 期間やアクセス日時でフィルタリング。
    • LLMによる回答生成:
      • LangChainを使い、検索結果とユーザーの質問をコンテキストに、OpenAIのGPT-3.5やGPT-4で回答を生成。
  4. 結果の表示フェーズ:

    • フロントエンドでの表示:
      • ユーザーに対して、見つかった候補サイトのリストや要約を表示。
      • リンクをクリックすると該当のサイトにアクセス可能。

技術選定の理由

  • Pythonによる統一されたデータ処理:

    • データ取得、スクレイピング、ベクトル化、NLP解析などをPythonで一貫して行える。
  • ベクトル検索とLLMの組み合わせ:

    • 意味的な検索が可能になり、曖昧な質問にも対応できる。
    • LLMで高度な質問理解と自然な回答生成が可能。
  • LangChainの活用:

    • LLMとのインタラクションを簡素化し、チェーンとしてワークフローを組み立てられる。
  • FastAPIとReactによるモダンなアプリケーション構築:

    • フロントエンドとバックエンドの分離により、開発効率と保守性が向上。

追加の考慮点

  • プライバシーとセキュリティ:

    • ユーザーのブラウザ履歴や閲覧内容は機密性が高いため、データの暗号化やアクセス制御を厳格に実装。
    • データはローカル環境で処理し、クラウドに送信しない設計も検討。
  • データの更新と同期:

    • 履歴やウェブページ内容の変更に対応するため、定期的なデータ更新の仕組みを実装。
  • パフォーマンス最適化:

    • データ量が増加しても高速に検索できるよう、インデックスの最適化やキャッシングを検討。
  • ユーザー体験の向上:

    • フロントエンドでの入力補完や検索結果のフィルタリング機能を実装。
    • モバイル対応やレスポンシブデザインを考慮。
hiraokuhiraoku

ブラウザの履歴をブラウザ拡張機能を使ってベクトルデータベースに保存する。

hiraokuhiraoku

アーキテクチャ構成について

  1. Next.jsは、Vercelにデプロイし、フロントエンドとバックエンドのAPIを管理します。
  2. Chrome拡張がユーザーのブラウザ上で実行され、Next.jsのAPIと通信します。
  3. Cloud Runを使用して、Next.jsからのリクエストを処理し、ベクトルデータベースやVertex AIと連携します。
  4. Vertex AIは、Cloud Runから呼び出され、AIの処理を行います。
  5. ベクトルデータベースもCloud Runと同じGoogle Cloudリージョンに配置します。

hiraokuhiraoku

memplify-web(Next.jsフロントエンド)
memplify-auth (認証サーバー)
memplify-api(APIサーバー)
memplify-extension(Chrome拡張)
memplify-database(ベクトルデータベース設定・管理)
memplify-infrastructure(デプロイやインフラ関連)
memplify-docs(プロジェクト全体のドキュメント)※必要であれば
memplify-utils(共通ライブラリ・ユーティリティ)