RAG を「読み物」として設計する
RAG（Retrieval Augmented Generation）の使い方は大きく 2 系統に分かれる。
- 質問応答: ユーザの問いに対して文書を検索 + LLM で回答
- 読み物: ユーザの興味から関連する文書を提示 + LLM が「読める形」に編集
ChatGPT の検索系 UI は前者寄り。AetherEchoes のような読み物サイトは後者の発想で組むほうが、読者の滞在時間と再訪率が伸びる。
「読み物としての RAG」を組む観点を 5 つ書いておく。
観点 1: 質問より「興味」を入力にする
質問 (「Tailwind v4 の @theme は？」) を入力にすると、答えが返ってきた時点で読者は離脱する。
興味 (「Tailwind v4 を本番で動かしてみたい」) を入力にすると、関連する複数の記事 + LLM の編集（「3 つの観点で読むと良い」）が返る。読者は 連鎖的に複数の記事を読む ことになる。
UI 設計の核は「質問入力欄ではなく興味入力欄」を作ること。プレースホルダや見出しで誘導する。
観点 2: 関連度より「読みやすい順」
検索結果の単純な relevance スコア順は、読み物には向かない。初心者向け → 中級者向け → 専門記事 のような 読みやすさのグラデーション を作るほうが体験が良い。
# 単純スコア（避けたい）
posts.order(score: :desc).limit(5)
# 読み物グラデーション（推奨）
[
posts.beginner.order(score: :desc).first,
posts.intermediate.order(score: :desc).first,
posts.advanced.order(score: :desc).first,
...
]
これは記事側に「難易度」のメタデータが要る。書く時に少し手間だが、結果として 読者の体験が線形になる。
観点 3: 「答え」より「問い」を提示する
RAG が「答え」を出すと、読者は答えを得て満足する。問いを提示する と、読者は次の記事へ進みたくなる。
× 「Tailwind v4 の @theme は CSS 変数を一括管理する仕組みです。」
○ 「Tailwind v4 の @theme は 1 ファイルで色 / 余白 / フォントを統合する。
すると tailwind.config.js は何になるのか？という問いが残る。」
LLM のプロンプトに 「答えを示すのではなく、次の問いを提示する。最後の文は『〜という問いが残る』形で締める」 のような指示を足すだけ。
観点 4: 引用は「短く + 出典明記」
LLM に書かせた文章で 引用元の記事を必ず出典として表示 する。
「コードと詩が同じテーブルにつく」というポジショニングは、
[About ページ §01](/about#01) で書かれている。
これがないと、読者は「LLM が言っているのか / 編集者が言っているのか」が分からない。信頼の通り道を作る ために必ずリンクで戻れる構造にする。
観点 5: 個人ブログなら 50〜200 件で十分
商用 RAG は数万〜数百万件のドキュメントを扱うが、個人ブログは 50〜200 件 で十分価値が出る。
- 50 件未満: RAG 不要、手動で関連記事リンクを貼る方が早い
- 50〜200 件: RAG が価値を出す sweet spot
- 200 件以上: 専用エンジン（Meilisearch / Vespa）に乗せる検討
私のサイトは現在 53 件（オリジナル 3 + seed 50）。50 件で初めて embedding ベースの関連記事推薦が 手動より精度高い 体感が出てきた。
まとめ
「読み物としての RAG」設計の 5 観点:
- 質問より「興味」を入力にする
- 関連度より「読みやすい順」
- 「答え」より「問い」を提示する
- 引用は短く + 出典明記
- 個人ブログは 50〜200 件で十分
これで RAG が「答えを出す機械」ではなく「読書をガイドする編集者」として機能する。
答えを出すと終わる。問いを残すと続く。