🧠
HtmlRAG論文読んでみた

2024/11/24に公開
論文解説
ご無沙汰しております。なかなか記事を投稿できず久々の投稿となってしまいました。

私は現在LLMに非常に興味関心を持っておりまして、特にRAGの構築にお仕事でも関わっていることもあって興味津々です。

この分野は日進月歩が激しく、関連する論文がどんどん投稿されてます。その中でもHtmlRAGと呼ばれる手法の提案がおもしろそうだったので読んでみました。そこで備忘録がてら記事にして投稿してみようと思った次第です。

 対象論文https://arxiv.org/html/2411.02959v1

 概要（by NotebookLM）この論文は、Retrieval-Augmented Generation (RAG)システムにおいて、検索で得られた知識を表現するフォーマットとして、プレーンテキストではなくHTMLを用いることを提案するものです。HTMLは構造情報と意味情報を保持できる一方、ノイズとなる要素も多いことから、HTMLクリーニングと、埋め込みモデルと生成モデルによる2段階のHTMLプルーニング手法を提案し、6つのQAデータセットを用いた実験でその有効性を示しています。

 興味を持った背景直近のお仕事でAmazon Bedrockのナレッジベースを使ってRAGを構築し、それに基づいて回答するチャットボットを社内チャットツール(Discord)のBotとして実装しました。これは採用していたチャットボットツールであるCozeというサービスを内製化できたら嬉しいね、という趣向で割り当てられたタスクでした。Cozeは簡単にチャットボットを作ることができるサービスで、参照させる情報源を簡単に管理できます。そして情報源としてとWebページを指定することもできます。
そこで「Webページを参照するときって実際に処理としては何が行われているのか」が気になりました。つまり、参照されたタイミングでそのページを見に行き、テキストを抽出して渡しているだけなんじゃないのか？と思ったわけです。イメージとしてはBeautifulSoupのような形でLLMに渡されるもの自体はプレーンテキストなんじゃないか？と考えました。さらに言えば、そのプレーンテキストはHTMLのタグが大量に含まれているノイジーなテキストデータなんじゃないか？と思い至りました。
そんなときに偶然見かけた論文が「HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems」だったというわけです。

 この論文を読んで知りたかったことHTMLタグを大量に含んでいるテキストは含まないテキストに比べてRAGに対してどのように影響するか？
HTMLの情報源をRAGに有効に活用させるにはどうしたらいいか？

 論文を読んでわかったこと
 ざっくり理解従来のRAGパイプラインでのHTMLドキュメントの処理について
多くのRAGパイプラインではプレーンテキストに変換されている
変換の過程でHTMLドキュメントが持っていた構造情報と意味情報が失われている
特に「¡code¿」や「¡a¿」といったタグを失うと意味情報が損なわれる



図1.HTMLからプレーンテキストへの変換時の情報損失(元論文から引用)


!「¿」記号の意味について

正直見たことないんですけどNotebookLM曰はく
「¡html¿¡body¿¡div¿¡p¿block content…」という表記における「¿」記号は、HTMLタグを識別するための特殊な記号です。

ソースでは、生成モデルによる細粒度ブロックプルーニングにおいて、各ブロックを一意に識別するために「ブロックパス」という概念を導入しています。ブロックパスは、ルートタグから対象ブロックまでのタグ列を、特殊な記号で囲んで表現します。

論文では、この特殊な記号として「¡」と「¿」を用いています。

例えば、「<html><body><div><p>block content</p></div></body></html>」というHTML文書において、「block content」を含むブロックのブロックパスは、「¡html¿¡body¿¡div¿¡p¿block content…」となります。

ブロックパスを生成モデルに入力する際、HTMLタグと通常のテキストを区別する必要があります。そこで、HTMLタグを「¡」と「¿」で囲むことで、生成モデルがHTMLタグを特別なトークンとして認識できるようにしていると考えられます。
だそうです。とりあえずは<>のことを指していると思ってます。
多くのLLMは事前学習の段階でHTMLドキュメントに触れており、特別なファインチューニングなどをしなくともHTMLを理解できる能力を既に持っているらしい
また多くのLLMでコンテキストウィンドウが長くなってきていることもHTMLタグを情報として扱うことに対して追い風になっている
とは言えHTMLタグをなんでもかんでも放り込んでしまうとノイズの大きなコンテキスト処理を強いることになる
論文中の予備実験ではWebページから取って出しだと平均で80Kトークンが含まれる
その90％以上がCSSスタイル、JavaScript、コメント、またはその他の意味のないトークン

LLMの一般的な最大コンテキストウィンドウは32K~128Kであり、1ドキュメントで80Kは流石に長すぎる

そこで考案されたのがHTMLクリーニングモジュールで、HTMLを元のサイズの6％まで削減できる
HTML内の意味的に関心のないコンテンツを削除し、メインコンテンツを維持する
意味情報を失うことなくHTMLツリーの構造を調整する
例えば単一のネストされたHTMLタグの複数のレイヤーをマージし、空のタグを削除する


しかしHTMLクリーニングモジュールで処理をしてもLLMにとってはまだ長い（1ドキュメント4K以上）
入力コンテキストを短縮し、元の検索文書に含まれるノイズを除去するために、既存のRAGシステムでは、さまざまな種類のpost-retrieval result refiners（検索結果絞り込み器）を利用している
post-retrieval result refinersはユーザーのクエリとLLMの好みに応じて、ドキュメントから関連するテキストチャンクまたはキーセンテンスを抽出し、他のコンテンツを破棄する
post-retrieval result refinersはプレーンテキストをベースにしているため、HTMLの構造を考慮せずにチャンク分けをしてしまい、タグだけを含むような意味のないチャンクが生成される可能性がある
そこで開発されたのがHTMLの固有のツリー構造に基づいて機能するHTMLプルーニングモジュール
ブロックツリーの構築：
各HTML文書はDOM(Document Object Model)ツリーに解析できるが、DOMツリーは細分化されすぎており、ツリー上のHTMLを単純に刈り込むと計算コストが高すぎる。
そこで、元のDOMツリーノードを階層ブロックにマージした、対応するブロックツリーを構築することを筆者らは提案しており、これであれば、ブロックツリーの粒度は、マージの度合いによって調整可能とのこと。

テキスト埋め込みに基づくブロックの剪定：
次に既存の埋め込みモデルを使用してブロックツリーを剪定します。これは、埋め込みの類似性に基づいて、ユーザーのクエリとブロックの関連スコアを計算するシンプルで効果的な方法だからだそうです。
類似性スコアが低いブロックを削除する貪欲な剪定アルゴリズムを適用し、剪定されたブロックツリーを取得しする。
ただし、これらの小さなブロックに対して学習された埋め込みは通常曖昧で不正確であるため、埋め込みモデルは細粒度のブロックではうまく機能しない可能性がある。
そのため、この剪定手順は粗粒度のブロックツリーに限定されるそうです。

生成的細粒度ブロック剪定：
ブロックツリーをさらに剪定するために、剪定されたブロックツリーのリーフノードを拡張し、より細粒度のブロックツリーを構築する。
生成モデルは、より長いコンテキストウィンドウを持つため、ブロックツリーをグローバルにモデル化でき、一度に1つのブロックをモデル化する必要はない。
そこで、より細かい粒度で分割されたブロックに対して、HTMLをプルーニング（枝刈り）するための生成モデルを開発する。
生成モデルは、ブロックを示す一意のシーケンスの生成確率によって与えられる各ブロックのスコアを計算することになっている。
シーケンスは、ルートタグからブロックのタグとテキストまでたどるHTMLタグのパスによって与えられる（例：“¡html¿¡body¿¡div¿¡p¿block content…”）。
最後に、ブロックスコアに応じて、同様の貪欲剪定アルゴリズムを適用して、最終的な剪定されたHTMLを取得する。


ambiguous QA, natural QA, multi-hop QA, and long-form QAを含む6つのデータセットで実験を行ったところ、RAGが参照する外部知識のフォーマットとしてプレーンテキストよりもHTMLの方が優れていることが確認されたそうです！
この論文のポイントは大きく3つ
RAGシステムにおける知識のフォーマットとしてHTMLを採用し、元のHTMLの情報を保持することを提案
シンプルだが効果的なHTMLクリーニングアルゴリズムを提案
2段階のHTMLプルーニングアルゴリズムを提案


 もうちょっと詳しく理解RAGで取得したドキュメントの処理について
RAG システムは通常、検索後のプロセス (つまり、post-retrieval result refiners) を適用して有用なコンテンツのみを抽出し、LLM に送信される入力コンテキストを短縮する。
チャンクベースのリファイナーは広く使用されているソリューションであり、最初に特定のルールに従ってテキストをチャンク化し、次に再ランキング モデルを使用して関連性の高い上位チャンクを選択する。
別のソリューションとしてabstractive refinerがあり、これはtext-to-textタイプのLLMを利用して結果の要約を生成するものである。
いくつかの研究では、既成の事前に学習済みで、そのまま利用できる要約生成モデルもしくは微調整された抽象モデルを使用して、検索結果をセグメント化して階層的に要約している。
他にも言語モデルが出力するlogitsの情報を利用して、文書内の単語の重要度を判断する手法がある

上述の処理の問題点
上述の検索検索結果後の絞り込み手法はいずれもプレーンテキストをベースとしている。既存のチャンクベースの手法は、構造を考慮せずに単純にHTMLをチャンク化すると不合理なチャンクが生成される可能性があるため、HTMLに直接適用することはできない。
さらに、抽象的絞り込み手法は、長すぎるHTMLの処理が困難、計算コストが高い、HTMLの理解が限られているなどの問題を抱えている可能性がある。
これらの問題を軽減するために、本稿では、DOM構造に基づいてHTMLをプルーニングすることを提案している。



図2.RAGのためのHTMLのパイプラインの概要(元論文より引用)

!目標1達成！

HTMLタグを大量に含んでいるテキストは含まないテキストに比べてRAGに対してどのように影響するか？

長すぎるHTMLの処理が困難、計算コストが高い、HTMLの理解が限られているなどの問題を抱えている可能性がある。
構造化データの理解について
これまでの研究で、HTMLおよびExcelテーブルはプレーンテキストに比べてより豊富な情報を含むことが示されている。
そういった構造化データを扱うための2つの主要なアプローチは以下のものが挙げられる。
特殊なタスクの設計: 構造化データに対して特定の課題を解決するための、特化したタスクを設計するアプローチ。
言語モデルのファインチューニング: 言語モデルを構造化データを理解できるように、ファインチューニングするアプローチ。

本研究が特定のデータ形式の理解に焦点を当てるのではなく、よりリッチなデータ形式を一般的なRAGシステムで使用することを推奨している。
論文著者らの知る限り、RAGシステムの入力としてHTMLを使用することを提案したのは著者らが初めてだそう。


 HtmlRAGについて本稿では、RAGシステムで検索される知識の形式としてプレーンテキストではなくHTML を使用するHtmlRAGを提案する。
これは、プレーンテキストでは欠落してしまう、より豊富な意味と構造化された情報を保持することを目的としている。
HTMLは知識ベース内のドキュメントの一般的なデータ形式であり、他のドキュメント形式は簡単にHTMLに変換できる。

 HTMLクリーニングについて元の HTMLドキュメントは長すぎる (1ドキュメント80K以上) ため、意味的特徴を含める必要はなく、このステップではモデルベースの方法は不適切。
したがって、最初にルールベースの HTMLクリーニングを設計する。
これは、ユーザーのクエリを考慮せずにHTMLを前処理することを意味する。
このクリーニングプロセスでは、無関係なコンテンツを削除し、冗長な構造を圧縮して、元のHTMLのすべての意味情報を保持する。
HTMLクリーニングの圧縮されたHTMLは、ロングコンテキストLLMを備えたRAGシステムに適しており、生成前に情報を失うことはない。
クリーニングされたHTMLは、HTMLプルーニングの基礎としても機能する。
HTMLコンテンツのクリーニング
Webから取得したHTMLドキュメントには、HTMLタグ、CSS、JavaScriptなど、人間のユーザーには見えない余分なコンテンツが大量に含まれている。
HTMLタグのほとんどは、LLMがHTMLを理解するのに役立つ豊富な構造情報を提供するが、CSSとJavaScriptコンテンツはほぼ役に立たない。
そのため、ほとんどロスのない具体的なクリーニング手順は次のとおりになる。
CSS スタイル、コメント、JavaScript を削除
長いHTMLタグ属性をクリア


ロスレス構造圧縮
ほとんどのHTML文書では、元のHTML構造に冗長性が含まれていることがわかった。
そのことを利用して意味情報を失うことなく、HTML構造を次のように圧縮できる。
複数の層の単一ネスト タグを結合します。たとえば、“¡div¿¡div¿¡p¿some text¡/p¿¡/div¿¡/div¿” を “¡p¿some text¡/p¿” に簡略化。
“¡p¿¡/p¿” などの空タグを削除。



 粒度調整可能なブロックツリー構築取得したHTML文書全体を整理するために、まず取得したHTML文書を連結し、Beautiful Soupを使用して、連結されたHTMLドキュメントを単一のDOM ツリーに解析する。
DOM ツリーを使用してHTMLを整理するのが最も自然な方法だが、DOMツリーは非常に細かい粒度であるため、多数のノードと深いツリー構造を持つため、計算コストが膨大になる。
上記の問題を考慮して、それほど細分化されていないHTMLをモデル化した最適化されたツリー構造を提案する。理想的には、ツリー構造の粒度は、さまざまな剪定要件に合わせて調整できる。これを「ブロックツリー」と呼び、ブロックあたりの最大単語数maxWordsを設定し、ブロックツリーの粒度を制御する。
ブロックツリーを構築する際に、単語数がmaxWordsを超えないという条件下で、ブロックや子ノードを再帰的に親ノードにマージして、より大きなブロックを形成できる。
マージ後、マージできない元のリーフノードもブロックとみなされます。
アルゴリズムの詳細は割愛。

 ブロックツリーベースのHTMLプルーニングブロックツリーベースの HTML プルーニングは2つのステップで構成され、どちらもブロックツリー構造に対して実行される。
最初のプルーニング ステップでは、埋め込みモデルを使用してHTMLクリーニングモジュールによって出力された結果をプルーニングする。
次に生成モデルを使用して最初のプルーニング ステップによって出力された結果をプルーニングする。
テキスト埋め込みに基づくブロックのプルーニング
絞り込みプロセスでは、キー情報を可能な限り保持しながら検索結果を短縮することが期待される。
簡単なのは、ブロック内のプレーンテキストを抽出し、テキスト埋め込みを使用してユーザーのクエリとの類似度スコアを計算すること。
類似度スコア計算後、貪欲アルゴリズムを使用して、類似度の低いブロックを削除し、類似度の高いブロックを再トレーニングすることで、ブロックツリーを刈り込む。

実際には、HTMLドキュメントの合計長が設定したコンテキストウィンドウを満たすまで、関連性が最も低いブロックを削除し続ける。
ブロックの削除後、冗長なHTML構造が再び現れるため、HTML構造を再調整します。つまり、単一ネストされたタグの複数のレイヤーを結合し、空のタグを削除する。
詳細な刈り込みアルゴリズムは割愛。
埋め込みベースのHTMLプルーニングアルゴリズムは軽量ですが効果的。
プレーンテキストベースのリファイナーに比べて、HTML形式への適応性は優れていますが主に次のような側面もある。
埋め込みモデルのコンテキストウィンドウは、毎回ブロック内のテキストの範囲に制限される。
Embeddingモデルは、一度に1つのブロックしか処理しないため、文書全体の情報を考慮することができまない。つまり、あるブロックが文脈全体の中でどの程度重要なのかを判断することが難しい。
ほとんどのブロック内のテキストは埋め込みモデルがセマンティック機能を取得するのに十分な長さではないため、埋め込みモデルはより細かい粒度のブロックツリーを処理できない。



図3.ブロックスコアの計算。ブロックツリーはトークナイザーによってトークンツリーに変換され、対応する HTML タグとトークンは同じ色でマークされます。トークン生成確率は右上隅にあり、破線ボックス内のトークンは推論を必要としません。ブロックツリーの右上隅には、対応するトークン確率から導き出せるブロック確率が表示されます。(元論文より引用)


生成的細粒度ブロックプルーニング概要
より細かい粒度でブロックをさらに刈り込むために、刈り込まれたブロックツリーのリーフノードを展開し、より細かい粒度のブロックツリーを取得。
埋め込みモデルベースのブロック刈り込みの制限を考慮して、ブロックツリー全体をカバーするための長いコンテキストを持ち、一度に1つのブロックをモデル化することに限定されない生成モデルを使用することを考える。
しかし、クリーンアップされたHTMLを生成モデルで直接処理することは、クリーンアップされたHTMLが長く（平均60K）、計算コストが高くなるため不適切。
同様に、生成モデルはブロックのスコアを計算することになっています。**CFIC(後述)**は、テキスト チャンクのシーケンス生成確率をそのチャンクのスコアとしてとらえる手法ですが、本稿はブロックを識別するためにタグのシーケンスを使用することを提案している。
具体的には、シーケンスはルートタグから始まり、ブロックのタグまでたどっていくタグで構成され、このシーケンスを「ブロック パス」と呼びます。推論フェーズでは、生成モデルはブロック ツリーの構造に従い、ブロックツリー内のブロックのスコアを計算します。ブロックのスコアは、図 3に示すように、トークンロジットから導出されます。最後に上述したのと同じブロックプルーニング操作を使用して、洗練されたHTMLドキュメントを取得します。

CFIC（Chunking-Free In-Context Retrieval）とは？CFICは、チャンクフリーな文脈内検索を行う新しい手法です。 これは、Retrieval-Augmented Generation (RAG) システムで使用される、より高度なブロックプルーニング手法の一部として提案されています。 RAGシステムでは、関連性の高い情報を効率的に取得するために、文書をブロックと呼ばれる単位に分割し、重要度の低いブロックを削除するブロックプルーニングという処理が行われます。 従来のブロックプルーニング手法では、文書を固定長のチャンクに分割するチャンクベースの手法が主流でしたが、CFICはチャンクを使用しないため、より柔軟で効率的な検索が可能になります。

 CFICの仕組みCFICでは、各ブロックを識別するために、HTML文書の構造を反映したタグのシーケンス（ブロックパスと呼ぶ）を用います。 例えば、「<html><body><div><p>ブロックの内容...</p></div></body></html>」のようなシーケンスがブロックパスとなります。
推論段階では、生成モデルがブロックツリーの構造に従ってブロックパスを生成し、その生成確率に基づいて各ブロックのスコアを計算します。 生成確率が高いブロックパスほど、対応するブロックが重要であると判断されます。

 CFICの利点CFICは、従来のチャンクベースの手法と比較して、以下の利点があります。

チャンクの境界を明示的に定義する必要がない: チャンクベースの手法では、文書を事前にチャンクに分割する必要があり、その境界の定義が性能に影響を与える可能性があります。CFICでは、チャンクの境界を明示的に定義する必要がないため、より柔軟な検索が可能になります。

文脈情報をより効果的に活用できる: CFICでは、ブロックパスを生成することで、ブロックの文脈情報をより効果的に活用することができます。ブロックパスは、ブロックが文書全体のどの部分に位置しているのかを示す情報を含んでいるため、文脈に応じた適切なブロックの選択が可能になります。

 CFICと他のブロックプルーニング手法との比較ソースでは、CFICとEmbeddingモデルを用いたブロックプルーニングが比較されています。 Embeddingモデルは、ブロック内のテキストをEmbedding（意味をベクトルで表現したもの）に変換し、クエリとの類似度に基づいてブロックの重要度を計算します。
しかし、Embeddingモデルは、一度に1つのブロックしか処理しないため、文書全体の情報を考慮することができません（グローバルビューの欠如）。 一方、CFICは、生成モデルを用いることで、ブロックツリー全体、つまり文書全体の情報を考慮することができます。

 要約CFICは、チャンクフリーな文脈内検索を行う新しい手法であり、生成モデルを用いたブロックプルーニングにおいて有効な手法です。 CFICは、チャンクベースの手法と比較して、チャンク境界の定義が不要であり、文脈情報をより効果的に活用できるという利点があります。

!生成的細粒度ブロックプルーニングモジュールの詳細はここでは割愛します。

元論文を読んでいただくか、私が別記事として書いているものを後ほど公開するのをお待ちください。

 実験以下の6つのデータセットで実験が行われた:
ASQA  (Stelmakh et al . ,2022) : QAデータセットは、異なる知識源によってサポートされた複数の回答で回答できる曖昧な質問で構成されています。
Hotpot-QA  (Yang et al .、2018) : QAデータセットはマルチホップ質問から構成される。
NQ  (Kwiatkowski et al .、2019) : Googleが収集した実際のユーザーのクエリを含むQAデータセット
Trivia-QA  (Joshi et al .、2017) : 実際のユーザーの質問を含むQAデータセット
MuSiQue  (Trivedi et al .、2022) : 合成マルチホップQAデータセット
ELI5  (Fan et al .、2019) : Reddit フォーラムから収集された質問を含む長文のQA データセット

評価のために、元のデータセットのテストセット (存在する場合) または検証セットから400 件の質問をランダムにサンプリングしている。
実際の産業用 Web 検索環境をシミュレートするには、取得するドキュメントとして、HTML 形式の Web からの実際の Web ページが必要。
ただし、広く使用されている Wikipedia検索コーパスは、主にプレーンテキスト形式の前処理された文章で構成されている。
そのため、US-EN地域でBing検索APIを適用して関連するWebページを検索し、返された検索結果のURLを通じて静的HTMLドキュメントをスクラップ。

 評価指標RAGシステム全体の性能を向上させるために、LLMの応答をエンドツーエンドの結果として評価するため、評価に用いるデータセットは、質問と回答の形式に応じて異なる評価指標を採用しています。以下の指標を用いることで、異なる形式の質問と回答を持つデータセットに対して、RAGシステムの性能を包括的に評価することができます。

Hotpot-QA と MuSiQue のデータセットの場合、各質問には単一の短い回答が注釈として付けられているため、Exact Match を指標として使用します。

ASQA、NQ、Trivia-QA のデータセットの場合、各質問には複数の短い回答が注釈として付けられているため、Exact Match と Hit@1 を指標として使用します。Hit@1 は、注釈付きの回答の少なくとも1つがLLMの応答と完全に一致することを意味します。

ELI5 は長い形式の回答が注釈として付けられているため、ROUGE-L と BLEU を指標として使用します。

 ベースラインRAGシステムで検索された知識のフォーマットとしてHTMLを採用したのは本稿が初めてなので、HtmlRAGを、検索後のプロセスを実行するベースラインと比較します。これらのベースラインは主にプレーンテキストまたはMarkdownフォーマットに基づいています。

本稿では3つのチャンキングベースのリファイナーを選択し、LangChainフレームワークのチャンキング方法で統一しています。リランキングコンパートメントはプラグアンドプレイであり、3つの異なるリランキングモデルを使用します。
BM25  (Robertson and Zaragoza、2009) : 広く使用されているスパースリランクモデル
BGE  (Xiao et al .、2023) : エンコーダのみの構造を持つ埋め込みモデルBGE-Large-EN
E5-Mistral  (Wang et al .、2024b) : LLM、Mistral-7B に基づく埋め込みモデル (Jiang et al .、2023a）、デコーダーのみの構造を持つ。
さらに、2つの抽象リファイナーを用います。
LongLLMLingua(Jiang et al .、2024):Llama7B を用いた有用なコンテキストを選択する抽象モデル
JinaAI Reader(JinaAI、2024):HTMLからMarkdownへの変換タスクデータセットで微調整された 15億のパラメータを備えたエンドツーエンドの軽量LLM

 実験結果主な実験結果は以下表1に示されています。HtmlRAGは、6つのデータセットのすべての評価指標で基準を満たすか上回っています。これは HTMLプルーニングの有効性を示しています。さらに、次の点も観察されています。
チャンクベースのリファイナーについては、LangChainチャンキングルールは、HTMLタグの見出し (h1、h2 など) に従ってチャンク化します。このチャンキング戦略は特定のHTML構造を考慮しますが、構造情報を本稿の方法ほど効果的には利用できません。さらに、最終出力をプレーンテキストに変換すると、HTMLの構造情報と意味情報が失われます。本稿が適用した3つのリランクツールのうち、スパースリトリーバーBM25は2つの密なリトリーバーよりも劣っています。2つの密なリトリーバーのうち、エンコーダーベースのBGEはデコーダーベースのe5-mistralよりもパフォーマンスが優れています (後者の方がパラメーターが多いにもかかわらず)。
抽象的リファイナーのうち、LongLLMLinguaはHTML文書に最適化されていないため、HTMLを扱う場合の抽出能力に差異が出ます。さらに、プレーンテキスト出力は構造情報が失われるためHtmlRAGに比べてパフォーマンスが劣ります。JinaAIリーダーは、HTML入力を与えると、再調整されたMarkdownを生成します。しかし、長い入力と出力長でのトークンごとのデコードは、エンドツーエンドの生成モデルにとって難しいだけでなく、計算コストも高くなります。


表1.ショートコンテキスト設定でのHtmlRAGとベースラインの結果。Hit@1は、少なくとも1つの短い回答が一致するインスタンスの割合です。最良と2番目に良い結果は太字で下線が引かれています。†これは、私たちのモデルが統計的に有意な方法でベースラインよりも優れた結果を達成していることを示しています（t検定、p-値<0.05）


表2.プルーニングなしのHtmlRAGとロングコンテキスト設定でのベースラインの結果。Hit@1は、少なくとも1つの短い回答が一致するインスタンスの割合です。最良と2番目に良い結果は太字で下線が引かれています。†これは、私たちの方法が統計的に有意な方法でベースライン間で優れた結果を達成していることを示しています（t検定、p-値<0.05）(元論文から引用)


表3.HtmlRAG のアブレーション研究
!
 アブレーション研究とは？機械学習モデルやシステムの特定の構成要素が全体的な性能にどのような影響を与えるかを調べるための実験手法です。 特定の構成要素を意図的に削除したり、変更したりすることで、その要素の貢献度を評価します。


図5.ブロック ツリーの粒度の影響に関する実験結果。Prune-Embed と Prune-Gen の結果は棒グラフで表され、赤い破線の水平線は強力なベースライン メソッドである、BGE を使用したチャンク ベースのリファイナー (BGE-Chunk-Rerank) のパフォーマンスを示しています。(元論文より引用)
ブロック ツリーの粒度の影響を見てみると、Prune-Embed と Prune-Gen の結果は棒グラフで表され、赤い破線の水平線は、強力なベースライン メソッド、つまり BGE を使用したチャンク ベースのリファイナーのパフォーマンスを示しています。(詳細はもっと詳しく理解（Further Analysisの内容）内に記載)

 もっと詳しく理解（Further Analysisの内容）さらなる研究
 HTML クリーニングの有効性検索された知識のフォーマットとしてのHTMLの優先順位を検証するために、本稿ではHTMLクリーニングモジュール、すなわちプルーニングなしのHtmlRAGの結果と、
バニラHTML
プレーンテキスト（BeautifulSoup）
マークダウン：マークダウンを自己変換ツールMarkdownify

以上の3つを比較した。

トークン数に関する追加実験では、プルーニングなしのHtmlRAGの結果では元のHTMLの94.07% 以上のトークンが削除されるのに対し、プレーンテキストとMarkdownへの変換ではそれぞれ 96.71% と 90.32% が削除されることが示されています。

→（私見）これはプレーンテキストへの変換は何も考えず無邪気に情報を削除すること、Markdownではある程度構造化情報を保持しており、その程度がHTMLよりも多くのトークンを伴ったという理解でいいはず
クリーニングされたHTMLはそれでもまだ長いため、表2に示すように、長いコンテキスト設定 (128K) で実験を行います。HTMLを外部知識の形式とした場合、プルーニングなしのHtmlRAG は、ほとんどのデータセットでプレーンテキストや Markdown と同等かそれ以上のパフォーマンスを示し、その有効性を実証しています。

さらに、次の点も観察されています。
処理されていないHTMLドキュメントには大量の無関係なコンテンツが含まれているため、すべてのクリーニングアルゴリズムはバニラHTMLよりも改善が見られます。
HTMLを外部知識の形式とした場合、より高性能なLLM (70B) は、より性能の低いLLM(8B) よりも優れたパフォーマンスを発揮します。これは、より強力なモデルの方がHTML内の複雑な情報をよりよく理解できることを示しています。

 アブレーション研究HtmlRAG の各コンポーネント (ブロックツリーの構築 (Block Tree)、埋め込みモデルによるHTMLプルーニング (Prune-Embed)、生成モデルによるHTMLプルーニング (Prune-Gen)) の有効性を実証するために、アブレーションスタディを実施しました。表3の結果から、次のことがわかります。
ブロック ツリーの構築に関するアブレーション スタディでは、ブロック ツリーの代わりにDOMツリーを使用します。DOMツリー内のユニットは非常に断片化されているため、埋め込みモデルは十分な意味的特徴をキャプチャできず、パフォーマンスが低下します。ブロック パスの長さが長くなるため、生成モデルのパフォーマンスも影響を受けます。
埋め込みモデルによるプルーニングに関するアブレーション研究では、生成モデルのみを使用して、クリーンアップされたHTMLをプルーニングします。埋め込みモデルによって基本的にプルーニングされたHTMLがないと、生成モデルへの入力が非常に長くなり (32Kを超える)、計算コストが高くなり、パフォーマンスが低下します。
生成モデルによる剪定のアブレーション研究では、埋め込みモデルのみを使用して、クリーンアップされたHTMLを剪定します。埋め込みモデルの全体的な理解と細分化されたブロックツリーを処理する能力が生成モデルに劣るため、結果は生成モデルを使用してさらに剪定されたHTMLと比較して劣っています。



表4.ELI5 データセットでの推論コストの分析 BGE を使用したチャンキングベースのリファイナー (BGE)、HtmlRAG のテキスト埋め込み (Prune-Embed) と生成モデル (Prune-Gen) に基づく 2 つの HTML プルーニング ステップ、および LLM チャット (LLM Chat) を、モデル パラメーター、ストレージ、平均入力トークン、平均出力トークン別に比較します。(元論文より引用)

 ブロックツリーの粒度の影響HTMLプルーニングにおいて最も重要なハイパーパラメータは粒度です。粗い粒度ではプルーニングの柔軟性が低下し、細かい粒度では小さなブロックのテキスト埋め込みの抽出が難しくなり、生成モデルのブロックパスが長くなりすぎるため、バランスを取るポイントを見つける必要があります。

図5では、64語から512語までのさまざまな粒度でHTMLプルーニングを実験し、その結果を強力なベースラインと比較しています。Prune-Embed は、埋め込みモデルによって基本的にプルーニングされたHTMLを使用することを意味し、Prune-Genは、生成モデルによって細かくプルーニングされたHTMLを使用することを意味します。生成モデルは埋め込みモデルよりも細かい粒度に適応し、一般に埋め込みモデルよりも優れていることがわかります。これにより、2段階プルーニング方法の合理性が検証されます。

 軽量HTMLプルーニング3BパラメータのLLMを使用しても、HTMLプルーニングメソッドが計算コストを大幅に増加させないことを示すために、効率分析を実施しました。

表4は、ベースライン（チャンキングベースのリファイナーを用いているBGE）と比較したメソッドの計算コストとLLMの推論コストを示しています。埋め込みモデルを使用したHTMLプルーニングは、チャンクベースのリファイナーと同様の計算コストを維持していることがわかります。生成モデルの計算コストは​​ベースラインより少し高くなっていますが、チャット用のLLMのコストよりははるかに低くなっています。追加の実験では、スキップできるノードが45%以上あることが示されており、生成モデルの計算コストがわずかに増加した理由を説明しています。
トークン数の分析により、HTML形式で取得されたすべての知識の平均トークン数は160万であることがわかります。20個のHTMLドキュメントを取得したと仮定します。HTMLクリーニングによりトークン数は135Kに削減され、テキスト埋め込みに基づくHTMLプルーニングにより8Kに削減され、生成的HTMLプルーニングにより4Kに削減されます。
!160万→135K→8K→4K
一般的な RAG シナリオでは、HTMLプルーニングの計算コストは​​LLMの推論コストよりもはるかに低いため、最良の結果を得るには完全なHTMLプルーニングを使用することをお勧めします。

一方、HTML プルーニングのコストも懸念されるリソース制限のあるシナリオでは、埋め込みモデルからの基本的にプルーニングされたHTMLのみを使用することをお勧めします。図5からわかるように、基本的にプルーニングされたHTMLは、チャンクベースのリファイナーと同等かそれを上回るパフォーマンスも実現します。

 まとめRAGシステムにおいてHTML情報源を有効活用するためには、HTMLの構造と意味情報を維持しながら、LLMの入力となるテキストの長さを調整することが重要です。

具体的には、以下の3つのステップでHTML情報源を処理することで、RAGシステムの性能を向上させることができます。
HTMLクリーニング:
HTML文書から、CSSスタイルやJavaScript、コメントなどの、意味的に無関係なコンテンツを削除します。
複数の単一ネストされたHTMLタグをマージしたり、空のタグを削除したりするなど、HTMLツリー構造を調整します。
これらの処理により、HTMLの長さを元のサイズの6%に削減できます。
クリーニングされたHTMLは、long-context LLMを搭載し、生成前に情報を失いたくないRAGシステムに適しています。
また、クリーニングされたHTMLは、後続のHTMLプルーニングの基礎となります。

テキスト埋め込みに基づくHTMLプルーニング:
クリーニングされたHTMLを、ブロックツリーと呼ばれるツリー構造に変換します。
ブロックツリーは、HTMLの構造を考慮してチャンクを作成し、各ブロックが意味的にまとまった単位となるように設計されています。
これは、単純にHTMLをチャンク化すると、構造を考慮せずに不合理なチャンクが生成される可能性があるためです。
各ブロックのテキスト埋め込みを計算し、クエリとの埋め込み類似度に基づいて、重要度の低いブロックを削除します。

生成モデルに基づくHTMLプルーニング:
テキスト埋め込みに基づいてプルーニングされたHTMLを、より細分化されたブロックツリーに変換します
生成モデルは、より長いコンテキストウィンドウを持つため、ブロックツリーをグローバルにモデリングでき、一度に1つのブロックをモデリングすることに限定されません。
生成モデルを用いて、各ブロックを示す一意のシーケンスの生成確率によって与えられる、各ブロックのスコアを計算します。
このシーケンスは、ルートタグから始まり、ブロックのタグとテキストに至るまでのHTMLタグのパスによって与えられます。
最終的に、ブロックスコアに基づいて、重要度の低いブロックを削除し、最終的にプルーニングされたHTMLを取得します。

これらのステップにより、HTML情報源をLLMのコンテキストウィンドウに収まる長さに短縮しながら、重要な構造情報と意味情報を維持することができます。

ソースでは、6つのQAデータセットを用いて実験を行い、HtmlRAGと呼ばれる上記の手法が、プレーンテキストに基づく既存の事後検索処理よりも優れていることを確認しています。
!目標2達成！

HTMLの情報源をRAGに有効に活用させるにはどうしたらいいか？