Zenn
Closed3

[論文] HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems

論文
RAG
kun432kun432

ここで見つけた

https://x.com/omarsar0/status/1857870511302390013

論文

https://arxiv.org/abs/2411.02959v1

Claude-3.5-sonnetによる落合プロンプトの結果

1.どんなもの？

Retrieval-Augmented Generation (RAG)システムにおいて、従来の平文(プレーンテキスト)ではなくHTML形式で知識を扱うことを提案した研究です。大規模言語モデル(LLM)は幻覚(誤った情報の生成)や知識の忘却などの問題を抱えており、RAGはこれを外部知識の取得で補完します。従来のRAGは検索結果のHTMLから平文を抽出して利用しますが、この過程で見出しやテーブル構造などの重要な構造的・意味的情報が失われます。本研究では、HTMLをそのまま利用することでこれらの情報を保持し、より効果的な知識利用を実現しています。

2.先行研究を比べてどこがすごい？

従来のRAGシステムは、HTMLから平文を抽出して利用する手法が一般的でした。しかし、この方法では文書の構造情報が失われ、知識の理解が不完全になる可能性があります。本研究の特筆すべき点は、HTMLの構造情報を保持したまま利用する点です。これにより、見出しやテーブル、リンクなどの重要な文脈情報を維持できます。また、事前学習時にHTMLに触れているLLMの特性を活かし、追加の微調整なしでHTML理解が可能という利点もあります。

3.技術や手法の肝はどこ？

本研究の核となる技術は、HTMLクリーニングと2段階のHTML pruning（不要部分の削除）です。具体的には：

  1. HTMLクリーニング: CSS、JavaScript、コメントなどの不要な要素を削除し、HTMLの構造情報を保持したまま文書を圧縮
  2. ブロックツリーベースのpruning:
    • テキスト埋め込みベースのpruning: 粗い粒度でブロックを評価・削除
    • 生成モデルベースのpruning: より細かい粒度で関連性の低いブロックを特定・削除

これらの技術により、HTMLの構造を保持しながら、LLMの文脈窓に収まるサイズまで文書を効率的に圧縮しています。

4.どうやって有効だと検証した？

6つの質問応答データセット（ASQA、HotpotQA、NQ、Trivia-QA、MuSiQue、ELI5）を用いて評価を実施しました。検証には以下の手法を用いています：

  • 短い文脈設定（4K tokens）と長い文脈設定（128K tokens）での比較実験
  • 既存の手法（BM25、BGE、E5-Mistral等）との性能比較
  • アブレーション実験によるそれぞれのコンポーネントの有効性検証

実験結果から、提案手法HtmlRAGは比較手法を上回る性能を示し、特に曖昧な質問や複数ホップの推論が必要な質問に対して効果的であることが確認されました。

5.議論はある？

主な議論点として以下が挙げられています：

  • HTMLクリーニングの効果：元のHTMLから94.07%のトークンを削減できる一方で、重要な構造情報は保持
  • モデルの能力との関係：より高性能なLLM（70B）の方が、HTML形式の知識をより効果的に活用可能
  • 計算コストの考慮：生成モデルベースのpruningは計算コストが若干高いものの、LLMの推論コストと比較すると許容範囲

6.次に読むべき論文は？

以下の関連研究が参考になります：

  • WebFormerに関する論文（Qifan Wang et al., 2022）: HTML文書の構造情報を活用した情報抽出について
  • Self-RAG（Asai et al., 2024）: LLMの自己反省に基づく検索と生成の制御に関する研究
  • FlashRAG（Jin et al., 2024）: 効率的なRAGツールキットについての研究

これらの論文は、HTML処理、RAGシステムの改善、効率的な実装など、本研究の異なる側面に関連する内容を扱っています。

kun432kun432

HTML無駄な情報が多すぎて無理じゃん、と最初思ったのだけど、なるほど、CSSとかはクリーニングするのね。それならば納得。ClaudeなんかだとXMLに最適化されていることもあるし、理解してくれそう。

少しQA

Q
- テキスト埋め込みベースのpruning: 粗い粒度でブロックを評価・削除
- 生成モデルベースのpruning: より細かい粒度で関連性の低いブロックを特定・削除
ここを詳しく教えて下さい。

これら2つのpruning手法について、論文の詳細を説明します。

1. テキスト埋め込みベースのpruning

  • 目的：HTMLドキュメントの長さを最初に大まかに削減すること
  • 処理単位：比較的大きなブロック（256ワード程度）
  • 具体的な手順：
    1. ブロックツリーの構築
      • DOM木から、指定した最大語数（maxWords=256）以下のブロックに分割
      • 階層構造を保持したまま、大きなブロックとして扱える部分はマージ
    2. 類似度計算
      • 各ブロックのテキストと質問文の埋め込みベクトルの類似度を計算
      • BGE-Large-ENモデルを使用
    3. 貪欲法による削除
      • 最も類似度の低いブロックから順次削除
      • 指定したコンテキストウィンドウサイズに収まるまで繰り返し

2. 生成モデルベースのpruning

  • 目的：より細かい粒度で、文脈を考慮した精密な削減を行うこと
  • 処理単位：より小さなブロック（128ワード程度）
  • 特徴：
    • より長いコンテキストを考慮可能
    • ブロック単位ではなく、文書全体を見渡した判断が可能
  • 具体的な手順：
    1. ブロックパスの生成
      • 各ブロックへのパスを、ルートタグから順にタグの連鎖として表現
      • 例：<html><body><div><p>ブロックの内容...</p></div></body></html>
    2. スコア計算
      • 3Bパラメータの軽量なLLM（Phi-3.5-Mini-Instruct）を使用
      • ブロックパスの生成確率をスコアとして利用
      • 同じタグ名の子要素は番号付けして区別（例：div1, div2）
    3. 効率的な推論
      • トークンツリーを構築し、深さ優先探索で処理
      • シングルトンノードや必須トークンはスキップして効率化
    4. 貪欲法による削除
      • スコアの低いブロックから順次削除

重要なポイント

  • 2段階のpruningを組み合わせる理由：
    1. 埋め込みモデルは大きなブロックには効果的だが、小さなブロックの意味理解が不十分
    2. 生成モデルは文脈理解に優れるが、計算コストが高い
  • そのため、最初に埋め込みモデルで大まかに削減し、その後生成モデルで精密に調整する戦略を採用
  • 実験では、この2段階アプローチが単独の手法よりも優れた性能を示しています

この2段階のpruning手法により、HTMLの構造を保持しながら、効率的かつ効果的にドキュメントの長さを削減することができます。

Q
課題はありませんか？

論文から明示的な課題と、私が分析した潜在的な課題をまとめます：

1. 計算コストに関する課題

  • 生成モデルベースのpruningは、軽量なLLM（3Bパラメータ）を使用しているものの、従来の手法と比べて計算コストが高い
  • 特に多数のドキュメントを処理する必要がある場合、スケーラビリティの問題が発生する可能性がある

2. HTMLの品質に依存する問題

  • Webから取得したHTMLは必ずしも整形式（well-formed）ではない
  • 異なるウェブサイトで異なるHTML構造が使用されており、一貫した処理が難しい
  • 動的に生成されるコンテンツの処理が考慮されていない

3. ブロック分割の粒度設定

  • 最適なブロックサイズ（maxWords）の設定が状況依存的
  • 粒度が粗すぎると重要な情報が失われる可能性
  • 細かすぎると計算コストが増大し、文脈理解が困難になる

4. 評価の限界

  • 主に質問応答タスクでの評価に限定されている
  • より多様なタスク（要約、分類など）での有効性は未検証
  • 人間による定性的評価が含まれていない

5. モデル依存性

  • より大きなLLM（70B）の方が良い性能を示すことから、モデルの性能に依存する傾向がある
  • 小規模なLLMでの効果が限定的である可能性

6. 技術的な課題

  • HTMLの構造変更（pruning後の再構築）による意図しない情報の損失リスク
  • 複数ドキュメント間の関係性の考慮が不十分
  • クロスリファレンスやリンク構造の活用が限定的

7. スケーラビリティの課題

  • リアルタイムの応答が必要な場合の処理時間
  • 大規模なWebページコレクションへの適用時の効率性
  • メモリ使用量の最適化

8. 実用化に向けた課題

  • 産業応用における具体的な実装ガイドラインの不足
  • 異なるドメインやユースケースへの適応方法が不明確
  • システムの保守や更新に関する考慮が必要

これらの課題に対する解決策として、以下のような研究の方向性が考えられます：

  1. より効率的なpruningアルゴリズムの開発
  2. HTMLの前処理や正規化手法の改善
  3. タスク特化型の評価指標の開発
  4. 軽量なモデルでも効果的に機能する手法の研究
  5. マルチモーダル情報（画像、表、グラフなど）の統合
  6. リアルタイム処理のための最適化技術の開発

これらの課題は、今後の研究における重要な方向性を示唆しています。

Q
HTMLの品質に依存する問題 については気になるところですね。
以前のようなHTMLのテーブルタグをデザインのために使用するというような使い方は
さすがにかなり少なくなったと思うのですが、最近の技術だとこのあたりはクリアに
なっているのでしょうか？

HTMLの構造化に関する問題は、確かに以前より改善されていますが、現代のWeb開発でも依然としていくつかの課題が存在します。

1. 現代のHTML構造の特徴

良くなった点：

  • セマンティックHTML5の普及により、<header>, <nav>, <main>, <article>, <section>などの意味的な要素の使用が一般的に
  • WAI-ARIAの採用により、アクセシビリティ情報が明示的に記述される
  • CSS Gridやflexboxの普及で、テーブルレイアウトは事実上廃止
  • CSSフレームワーク（Bootstrap, Tailwind等）の普及で、構造化された一貫性のあるマークアップが一般的に

残っている課題：

  1. 動的コンテンツの問題

    • SPAやJavaScriptフレームワークによる動的なDOM操作
    • シャドウDOMの使用
    • コンポーネントベースの開発による複雑な入れ子構造

  2. 新しい構造的な課題

    • レスポンシブデザインによる条件付きレイアウト
    • CSS-in-JSによるスタイリング
    • Web Componentsによるカスタム要素

  3. マークアップの多様性

    • フレームワークごとに異なるコンポーネント設計
    • マイクロフロントエンドによる複数のフレームワークの混在
    • サードパーティウィジェットの埋め込み

2. HtmlRAGへの影響と対策

現状の課題：

  1. 動的コンテンツの取り扱い

    <!-- 動的に生成される複雑な構造の例 -->
<div id="app">
    <component-wrapper>
        <dynamic-content v-if="condition">
            {{ dynamicData }}
        </dynamic-content>
    </component-wrapper>
</div>

  2. 複雑なコンポーネント構造

    <!-- 複雑なコンポーネントの入れ子 -->
<custom-component>
    <slot-wrapper>
        <styled-component css="dynamic-styles">
            <content-block>
                実際のコンテンツ
            </content-block>
        </styled-component>
    </slot-wrapper>
</custom-component>

対策の提案：

  1. プリレンダリングの活用

    • サーバーサイドレンダリング（SSR）された状態のHTMLを使用
    • 静的サイト生成（SSG）のアウトプットを利用
    • ヘッドレスブラウザでの実行後のDOMを取得

  2. 構造正規化処理

    • カスタム要素を標準HTML要素に変換
    • 不要な入れ子構造の単純化
    • コンポーネント境界の適切な処理

  3. メタデータの活用

    • Schema.orgなどの構造化データの利用
    • Open Graph Protocol等のメタデータの考慮
    • WAI-ARIA属性からの意味情報の抽出

  4. 適応的な解析戦略

    def analyze_html_structure(html):
    # フレームワーク検出
    framework = detect_framework(html)
    
    # フレームワーク固有の前処理
    if framework == 'react':
        html = preprocess_react(html)
    elif framework == 'vue':
        html = preprocess_vue(html)
        
    # 共通の構造化処理
    return normalize_structure(html)

3. 今後の展望

  1. Webプラットフォームの標準化

    • Web Componentsの標準化進展
    • HTMLモジュールの導入
    • CSSスコープの改善

  2. 解析技術の進化

    • LLMによる構造理解の向上
    • マルチモーダルモデルの活用
    • ドメイン特化型の前処理パイプライン

  3. フレームワークとの協調

    • フレームワーク開発者との協力
    • 標準的なレンダリングパイプラインの確立
    • セマンティクス保持のためのベストプラクティス

これらの課題に対しては、技術の進化とともに解決策も進化していますが、完全な解決にはまだ時間がかかると考えられます。HTML構造の理解と処理は、今後もRAGシステムにおける重要な研究課題の一つとして残り続けるでしょう。

なるほど。自分はフロントエンドについてあまり詳しくないけども、新しい課題も増えているということなので、なかなかハードルはありそう。

kun432kun432

とはいえ、全部プレーンテキスト化しちゃうとやっぱりコンテキストが欠落しちゃうので、HTMLで文書構造だけうまく残せればコンテキストはある程度保持できそうで、少し興味深い。

あと、Web以外の文書は別の話だな。

このスクラップは1ヶ月前にクローズされました