ホームVPN経由では、なぜプライベートRAGの引用元を開くのに時間がかかるのですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Do Private RAG Citations Open Slowly Over a Home VPN? - Zima Store Online

プライベートRAGの引用は、各ソースの表示でネットワーク往復、接続の確立、サーバー側のレンダリング処理が追加されるため、自宅VPN経由では開くまでに時間がかかることがあります。

インデックスのそばで生成が実行されるため、ローカルの回答はすぐに表示されることがあります。しかし、そのPDFの引用をクリックすると、ブラウザーは暗号化されたリモート経路を通ってNASにアクセスします。関連するページが表示されるまでに、DNS、トンネルのルーティング、TLS、認証、レンジリクエスト、プレビュー生成が行われる場合があります。閲覧者が複数の依存するやり取りを必要とする場合、通信速度の公称値よりも遅延のほうが重要です。

引用の表示は依存するネットワーク往復の連鎖

引用のクリックが、1回の転送だけで完了することはほとんどありません。ブラウザーは名前を解決し、VPNルートに到達し、トランスポートセキュリティをネゴシエートまたは再利用し、ドキュメントサービスへの認証を行い、メタデータをリクエストしてから、ビューアーに必要なソースのバイト列またはページ範囲を取得します。

ブラウザーのパフォーマンスモデルを見ると、依存するネットワーク往復によって、ペイロードが小さくても往復遅延が積み重なる理由がわかります。上り回線のスループットが高くても、次のリクエストを発行するために必要な応答を待つ時間をなくすことはできません。

RAGの生成では、モデルとベクトルインデックスがローカルで通信するため、この経路を回避できる場合があります。したがって、表示上の不一致はVPN経由の検索が速かったことを意味するのではなく、回答がすでに利用可能になった後で、引用ビューアーが別のリモートトランザクションを開始していることを意味します。

トンネルのルーティングとMTUが個々のソースチャンクを遅延させる可能性

VPNは暗号化、カプセル化、ルーティングの判断を追加します。トラフィックが直接経路ではなくリレー経路やフルトンネル経路を通る場合、すべてのリクエストの移動距離が長くなります。また、カプセル化されたパケットが利用可能な経路MTUを超えると、損失と再送によってビューアーが必要とする正確なバイト範囲の取得が遅れることがあります。

パスMTUディスカバリーに関する技術分析では、パスMTUディスカバリーに失敗するとサイズ超過のパケットが消失し、平均的な通信速度に比べて不釣り合いに大きな停止が発生する仕組みが示されています。VPNヘッダーによって、同じ外側のパケット内で利用できるペイロードが減るため、それまで安全だったサイズが境界を超えることがあります。

PDFビューアーは、ヘッダー、相互参照テーブル、フォント、サムネイル、ページ範囲を個別にリクエストすることがよくあります。バルク転送の速度テストが正常に見えても、1つの応答が失われるだけでレンダリングが停止する可能性があります。そのため、1秒あたりのバイト数と引用を開くまでの時間は、経路の異なる部分を測定しています。

トンネルが正常でもソースのレンダリングが支配的になる場合がある

自宅のサービスでは、ディスクの復帰、権限の確認、ファイルの解凍、OCRレイアウトの検索、ページプレビューのレンダリングが必要になることがあります。これらの処理はVPNリクエストが到着した後に行われるため、最近開いた引用がすぐに表示される一方で、キャッシュされていないドキュメントでは遅延の大部分を占めることがあります。

認証トンネルの設計では、小規模な認証済みトンネルインターフェースと最新の暗号構成が重視されています。しかし、エンドポイントの背後にあるアプリケーション処理をなくすことはできません。観測されるクリック時間では、暗号化のオーバーヘッド、ネットワーク遅延、ストレージ遅延、プレビュー遅延はそれぞれ別の層として残ります。

引用が遅いときに、VPNのせいだと決めつけるのが誤りの境界です。同じソースが自宅LAN上でも遅く開く場合、またはサーバーのトレースで最初の応答バイトまでに大半の時間がかかっている場合、制限要因はリモートの暗号化経路ではなく、ストレージとレンダリングです。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

両方の経路で引用表示のウォーターフォールを作成する

小さなHTMLファイル、大きなPDF、OCRスキャン、スリープ中のディスクから、キャッシュ済みとキャッシュされていない引用を選びます。クリック時間、DNS、接続の再利用、認証、最初のバイトまでの時間、レンジリクエスト数、転送バイト数、サーバーのレンダリング時間、引用箇所が表示されるまでの時間を記録します。

比較モデルとしてネットワーク遅延の影響を使い、LANとVPN経由で各ソースを繰り返しテストします。1回の実行で複数の変数を変更せず、直接経路とリレー経路、2種類のMTU値、プレビューがウォームな状態とコールドな状態をテストします。

リモートとLANの差がネットワークフェーズに現れる場合に限り、VPNが原因だと判断します。サーバーのレンダリングが両方の経路で支配的なら、安全なプレビューをキャッシュするかソース配信を改善します。多数の往復が支配的なら、帯域幅を増やす前に依存するリクエストを減らします。