アーカイブ / LLM / RAG
端末の私的文書とクラウドの公開文書を組み合わせる分散RAG「DRAGON」
DRAGON
DRAGONの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1 . Comparison between different RAG architectures.
概要
- 端末の私的文書とクラウドの公開文書を各側で処理し、次の単語の確率分布を統合する。
- 著者らはWikiTextで、単独モデルからの性能改善幅が集中型RAG比でQwen2.5-1.5Bでは1.9倍、OPT-1.3Bでは1.4倍と報告した。
- 通信遅延300ミリ秒の条件では、同期型に比べ単語当たりの遅延が42.4~49.5%減ったと報告している。
補足:編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、DRAGONの仕組み
- 01質問と両側の文書
- 02各側で文書検索
- 03各側で単語候補生成
- 04候補を照合・統合
- 05端末に回答出力
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
小規模言語モデルは端末で動かしやすい一方、著者らは一般知識と個人向けの質問への対応力に課題があるとする。RAGは、質問に関連する文書を検索して回答生成に使う方法で、モデルを端末上で再学習せずに知識を補える。
公開文書はクラウド、私的文書は端末に置かれることが多い。両方を使うために文書や計算済みの中間状態を移すと、転送や再計算が回答までの待ち時間を増やす。
手法
DRAGONは、質問に関連する文書を端末とクラウドでそれぞれ検索し、各側の言語モデルが文書ごとに次の単語の確率分布を計算する。確率分布とは、どの単語がどれほど出やすいかを表す値の組だ。文書の関連度で重み付けして両側の分布を統合し、端末で回答を一語ずつ作る。本文には、端末の好みの記録とクラウドの人気作品情報を使うゲーム推薦の例がある。
両側は次に続く単語の候補も先に作り、選ばれた側の統合器が届いた候補を非同期に照合する。候補が採用されなければ、過去の計算を再利用するための保存状態を戻して作り直す。文書の検索は質問を受けたときに行い、生成中は文脈に合わせて文書の関連度を更新する設計である。
新規性
DRAGONの新しさは、端末とクラウドで文書をそれぞれ処理し、次の単語の確率分布を統合する分散構成にある。著者らは、文書や計算済みの中間状態を両側間で移さずに済むよう設計した。
さらに、両側が先の候補を作るSpeculative Aggregationと、通信状況などに応じて統合場所を選ぶ仕組みを加えた。著者らは、候補を先に作って照合しても、毎回同期して統合する方法と同じ分布から最終候補を選べると示している。
従来手法との違い
文書を一カ所に集める集中型RAGでは、クラウド側の文書を端末で使う際に、本文を送って計算し直すか、計算済みの中間状態を送る必要がある。著者らは、それぞれ計算時間と転送時間が遅延の原因になると説明する。
文書処理だけを分散し、単語ごとに両側の結果を待つ同期型との違いは、次の候補の生成と通信を重ねる点にある。ただし、候補が採用されない場合は計算をやり直すため、待ち時間の削減幅は条件によって変わる。
実験結果
著者らは実機の試験環境で複数の小規模言語モデルを評価したと報告する。WikiTextでの言語モデリングでは、単独モデルからの性能改善幅が、集中型RAGによる改善幅のQwen2.5-1.5Bで1.9倍、OPT-1.3Bで1.4倍だった。ただし、確認できた本文の範囲では、この性能指標名とデータ分割は分からない。
通信遅延300ミリ秒の条件では、同期型に比べて単語当たりの遅延が42.4~49.5%減ったと著者らは報告する。初回の単語が出るまでの時間に伴う負担も小さいとしているが、ここで確認できる範囲に具体的な値はない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案:端末に置いた担当者の業務メモと、クラウドに置いた公開製品文書を参照し、問い合わせへの回答案を端末で作る。入力は質問と両側の検索対象文書、出力は回答案とし、人が原文を確認してから利用する。
必要なのは検索用に整えた両側の文書で、この試案では追加学習データ、正解ラベル、専用センサーを前提としない。文書の配置、検索対象の選び方、回答文の確認手順を業務に合わせて調整する。回答品質と情報の扱いは別途検証が必要である。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案:端末側の私的メモとクラウド側の公開文書を少量ずつ用意し、検索できる形に整える。質問と参照すべき文書の組を評価用に作り、回答の正しさを判定する正解ラベルを人が付ける。この試験では追加学習データと専用センサーは使わない。
同じ質問群で、端末側文書だけを使うRAGと、文書を一カ所に集める集中型RAGを比較する。回答の正しさ、初回出力までの時間、単語当たりの遅延を測り、通信条件も記録する。対象業務に合わせた検索設定と候補統合の調整を検証に含める。
限界と課題
著者らは、先に作った候補が採用されないと、保存した計算状態を戻して作り直すと説明する。また、生成と通信を重ねる効果は、両側の出力分布が似ている場合に特に期待される。これらの条件について、実運用での損失幅は示されていない。
編集上の検証事項として、私的文書の本文を送らない設計でも、交換する候補や確率情報から何が推測され得るかを調べる必要がある。確認できた本文の範囲では、業務文書での回答品質、通信断への対応、長時間運用時の費用は判断できない。
出典
元のタイトル・要旨を確認する(英語)
Efficient Distributed Retrieval-Augmented Generation for Enhancing Language Model Performance
Small language models (SLMs) support efficient deployments on resource-constrained edge devices, but their limited capacity compromises inference performance. Retrieval-augmented generation (RAG) is a promising solution to enhance model performance by integrating external databases, without requiring intensive on-device model retraining. However, large-scale public databases and user-specific private contextual documents are typically located on the cloud and the device separately, while existing RAG implementations are primarily centralized. To bridge this gap, we propose DRAGON, a distributed RAG framework to enhance on-device SLMs through both general and personal knowledge without the risk of leaking document privacy. Specifically, DRAGON decomposes multi-document RAG into multiple parallel token generation processes performed independently and locally on the cloud and the device, and employs a newly designed Speculative Aggregation, a dual-side speculative algorithm to avoid frequent output synchronization between the cloud and device. A new scheduling algorithm is further introduced to identify the optimal aggregation side based on real-time network conditions. Evaluations on real-world hardware testbed demonstrate a significant performance improvement of DRAGON-up to 1.9x greater gains over standalone SLM compared to the centralized RAG, substantial reduction in per-token latency, and negligible Time to First Token (TTFT) overhead.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新:2026-10-01




