Summary
この文書の要点
- エッジには認証前処理、軽いルーティング、キャッシュを置く。
- 長時間の検索や生成はバックエンドサービスへ逃がす。
- エッジには認証前処理、キャッシュ、軽いルーティングを置き、長時間生成を抱え込まない。
- RAGの検索、生成、ログ保存は、実行時間とデータ近接性を見て配置する。
どこが設計の難所か
RAGでは検索、再順位付け、生成に時間がかかります。エッジで全部処理しようとすると、実行時間、接続先、秘密情報、ストリーミングの制約に当たることがあります。
Cloudflare Workersは配信や軽いAPIには強い一方で、重いDB処理や長時間ジョブには向きません。また、利用者ごとの権限が関係する回答をキャッシュすると、情報露出につながる可能性があります。
RAGは、文書検索、プロンプト構築、生成、ログ保存を含むため、すべてをエッジで完結させるのは向かない場合があります。Cloudflare Workersの速さは魅力ですが、実行時間、接続先、秘密情報、ログの扱いを見なければなりません。
境界をどう切るか
Workersは、認証トークンの検証補助、リクエスト正規化、静的情報のキャッシュ、バックエンドへのルーティングに使います。RAGの検索や生成はHonoや別バックエンドに置き、必要に応じてストリーミングで返します。
設計では、エッジを入口として使い、認証、レート制限、キャッシュ、リクエスト正規化を担わせます。検索や生成は、データベースやベクトルインデックスに近いバックエンドへ渡し、Workersは相関IDと結果の軽い整形を担当します。
実装で効く細部
エッジ側では、リクエストIDを付け、タイムアウトを短く設定し、バックエンドエラーを統一形式に変換します。キャッシュ対象は公開ドキュメントやモデル一覧などに限定し、ユーザー固有の検索結果は保存しません。
HonoをWorkers上で使う場合でも、RAG本体のservice interfaceは分けておきます。エッジ側では、ユーザーコンテキスト、リクエストサイズ、キャッシュ可否、trace_idを決め、バックエンドへ明示的に渡します。
- 長時間の生成処理は直接Workersで抱えず、ストリーミングやジョブ化の境界を検討する。
- キャッシュできるのは公開情報や低リスクの検索補助に限定し、個人別回答を不用意に共有しない。
- エッジとバックエンドで同じtrace_idをログに残す。
壊れ方を観測する
検証では、バックエンド遅延、認証失敗、キャッシュ誤用、ストリーミング中断、リージョン差を確認します。ログはエッジとバックエンドで同じリクエストIDを使い、追跡できるようにします。
検証では、エッジのタイムアウト、バックエンド遅延、レート制限、キャッシュ誤共有を確認します。特に、認証済みユーザーごとの回答が他ユーザーへ混ざらないことを重点的に見ます。
捨てた選択肢とトレードオフ
エッジに処理を寄せると応答は速くなりますが、状態管理とデバッグは複雑になります。RAGの品質改善はバックエンド側で行うことが多いため、エッジは薄く保つ方が運用しやすい場合があります。
エッジへ寄せると初動は速くなりますが、状態を持つ処理や長時間処理は難しくなります。バックエンドへ寄せると制御はしやすいものの、遅延は増えます。RAGでは、入口の軽さと中核処理の観測性を分ける判断が重要です。
現場に残す判断軸
Cloudflare WorkersはRAGを速くする魔法ではありません。エッジに置くべき軽い処理と、バックエンドで扱う重い処理を分けることが、安定した構成につながります。
Cloudflare WorkersはRAG全体の置き場所ではなく、入口の境界として使うと強みが出ます。速さだけでなく、データ、秘密情報、ログの位置を見て役割を決めるべきです。
