top of page
執筆者の写真Cognitech.DEV

Heir-RAG :階層構造データベース篇

更新日:10月4日

今回の記事では、弊社のHier-RAGシステムのデータベーススキーマに焦点を当てます。目的、構造、および実装の理論を詳細に説明していきたいと思います。


はじめに

Retrieval-Augmented Generation(RAG)システムは、大規模な言語モデル(LLM)の能力を強化するために、リトリーバルメカニズムを統合します。このメカニズムは、広範な文書コーパスから関連するコンテキストを提供し、生成された応答の正確性と関連性を向上させます。弊社のHier-RAG(階層構造)は、データを階層的に構造化することで、RAGのプロセスをさらに最適化し、効率的で正確なリトリーバルを可能にします。


階層型リレーションシップとは

データにおける階層型リレーションシップは、データを複数のレベルに分割して整理する方法です。これにより、データの検索やリトリーバルが効率的になり、特定のコンテキストや関連情報を迅速に見つけることができます。

階層型リレーションシップの例として、メーカーの商品マニュアルを取り上げます。この場合、データは以下のようなレベルに整理されます:カテゴリ→マニュアルファイル→チャンク。

カテゴリは、広範なトピックまたは文書のタイプを表すトップレベルのグループです。今回の例で言うと商品の分類と言ってもいいでしょう。

マニュアルファイルは、カテゴリ内の個々の文書を表します。各ファイルは、カテゴリ内の主要なコンテンツを含みます。例えば、仕様書やデータシートなどを指します。

チャンクは、マニュアルファイルを小さなセクションに分割したもので、詳細なリトリーバルを可能にします。例えば、電子レンジの仕様書の中で、注意事項セクションを一つのチャンクとして保存するなどです。


なぜ階層構造を使用するのか?

階層構造を使用する理由は以下の3点に要約されます:

  1. 効率性:各レベルで検索スペースを減らし、リトリーバルを高速化します。階層的にデータを整理することで、関連する情報に素早くアクセスできるようになります。

  2. 関連性:より正確で文脈的に関連する情報のリトリーバルを保証します。階層構造により、特定のトピックやコンテキストに関連する情報を効果的に検索できます。

  3. スケーラビリティ:大規模なデータセットを効果的にクエリできます。階層的なデータ整理により、システムは拡張性を持ち、大量のデータを効率的に処理および検索できます。


データベースの設計

同じ今回の例でデータベースのスキーマを説明します:

  1. カテゴリ、ファイル、チャンクなどうな階層的なリレーションシップで表現する。

  2. ベクター埋め込みを効率的に保存およびリトリーバルする。

  3. データの整合性を保証し、複雑なクエリをサポートする。


データベースのスキーマ概要

  1. カテゴリノード: トップレベルのグループを表し、メタデータと埋め込みIDを含みます。

  2. ファイルノード: カテゴリ内の個々の文書を表し、メタデータと埋め込みIDを含みます。

  3. チャンクノード: 文書の小さなセクションを表し、詳細なリトリーバルを可能にし、テキストと埋め込みIDを含みます。


a node structure explaination for data schema for Hier-RAG
data schema for Hier-RAG

スキーマの詳細説明

1. カテゴリノード


説明:

  • category_id: 各カテゴリの一意の識別子。

  • category_name: カテゴリの名前。

  • category_summary: カテゴリの説明文。

  • embedding_id: VectorDBにあるカテゴリの説明文のベクター埋め込みへのIDです。

理論的背景: カテゴリノードは、クエリのエントリーポイントとして機能し、クエリに関連する広範なトピックや文書タイプを特定することで検索スペースを絞り込みます。ここに保存された埋め込みIDを使って効率的な類似性検索を可能にします。


2. ファイルノード


説明:

  • file_id: 各ファイルの識別子。

  • category_id: 親カテゴリへのキー。

  • file_name: ファイルの名前。

  • file_type: ファイルの種類。

  • file_summary: ファイルの説明短文。

  • embedding_id: VectorDBにあるファイルの説明短文のベクター埋め込みへのIDです。

理論的背景: ファイルノードはカテゴリ内のコンテンツをグループ化し、特定の文書の管理とリトリーバルを容易にします。各ファイルの埋め込みは文書の意味内容を捉え、カテゴリの広範な文脈内での類似性に基づくリトリーバルを可能にします。


3. チャンクノード


説明:

  • chunk_id: 各チャンクの一意の識別子。

  • file_id: 親ファイルへのキー。

  • chunk_text: チャンクの実際のテキストコンテンツ。

  • embedding_id: VectorDBにあるチャンクの意味内容を表すベクター埋め込みへのIDです。

理論的背景: チャンクノードは文書の小さな、管理しやすい部分を表し、詳細なリトリーバルを可能にします。このレベルの埋め込みは特定のテキストセクションの意味を捉え、非常に正確で関連性の高いクエリ応答を可能にします。


4. リレーションシップ

理由:

  • リレーションシップはノードがどのように接続されているかを定義し、直感的なクエリとデータの移動を容易にします。

説明:

  • CATEGORY_HAS_FILE: カテゴリノードをそれぞれのファイルノードに接続し、階層を構築します。

  • FILE_HAS_CHUNK: ファイルノードをそれぞれのチャンクノードに接続し、文書内の詳細なリトリーバルを可能にします。

理論的背景: これらのリレーションシップは階層構造の中核を成し、システムが広範なカテゴリから特定のテキストチャンクまでナビゲートできるようにします。この構造は効率的なクエリ処理をサポートし、最も関連性の高い情報が迅速にリトリーバルされることを保証します。


このアプローチは、最も関連性の高い情報が迅速にリトリーバルされることを保証し、RAGシステムのパフォーマンスと正確性を向上させます。具体な実装ではNeo4jなどGrpah databaseを使ってリレーションシップを管理し、ChromaDBなどVectorDBでベクター埋め込みを処理することで、大規模なデータセットを精密に処理およびクエリできる。

閲覧数:39回0件のコメント

最新記事

すべて表示

Comments


Commenting has been turned off.
bottom of page