RAG– tag –

ローカル検索ツールqmdで日本語クエリが0件になる現象に遭遇した。原因はSQLite FTS5の既定トークナイザunicode61が日本語を単語分割できないことだった。同じ問題に遭遇しうる人向けに、原因の仕組みとtrigram/形態素解析/ICU/外部拡張という対処法の選択肢を整理する。

「日本語なら日本語特化モデル」という下調べを信じてruri-v3を第一候補にしていたが、自分のObsidian Vault（622ファイル）で6モデルを実測したら最下位級だった。勝ったのは英語最適化の汎用モデル。借り物のベンチマークと自分の用途がズレていた理由を実測の記録として書く。

AIエージェントの『記憶』が今どう実装されているかを、CoALAの4層メモリ（In-Context/Episodic/Semantic/Procedural）・mem0の2026年ベンチマーク・arXiv survey『Always-On Agents』のガバナンスライフサイクル論という3つの一次情報から整理する。研究現場でRAGベースのLLM wikiに実験情報を蓄積してきた実体験（検索精度の劣化とその対策）も交えて、実務での使い分けまで解説する。

ローカルで無料のRAGを組むとき、埋め込みモデルの選択肢は「完全ローカルのOSSモデル」と「無料枠のあるクラウドAPI」の2系統に分かれる。日本語なら名古屋大学のruri-v3が有力候補で、実測ベンチマークではGemini Embedding-001にわずかな差まで迫る。実際にOllamaで運用して見えたリランキングの必要性も含めて整理する。

社内文書をRAGに入れたのに回答精度が上がらない。原因は検索の仕組みではなく、文書が「人が読む」前提で書かれていることにあります。見出し・節の独立性・メタ情報という3つの手当てを、実際の直し方まで具体的に整理します。

ChatGPT・Claude・Perplexity・Gemini Notebookは、どれも「AIに質問して答えをもらう」という見た目は同じでも、情報源の扱い方がまったく違う。Gemini Notebookが「ソース固定型RAG」と呼べる理由と、実際の使い分けの判断基準を整理する。

「社内文書をAIに検索させたい」と頼まれたとき、RAGが何をしているのか説明できるか。検索→文脈への挿入→生成という3ステップと、それを支えるチャンク分割・ベクトルDBの役割を、情報が増えるほど検索精度が落ちるという実体験を交えて解説する。

AIに知識を渡す方法には、検索時にどう情報を引っ張ってくるかというRAGの技術と、そもそも知識をどうファイル化しておくかというOKFの標準という、レイヤーの異なる2つの視点がある。両者の関係と使い分け、このクラスタで書いた4本の記事への案内をまとめる。

チャンク分割とベクトルDBだけのRAGは、情報量が増えると検索精度が頭打ちになる。その先にあるGraphRAG（グラフ構造からの検索）とAgentic RAG（エージェントによる複数回検索）は何が違うのか、実際にリンク構造と検索回数を調整した経験をもとに整理する。

「AIを第二の脳にする」という言葉の中身は比喩止まりの記事が多い。Andrej Karpathy氏が提唱したとされるLLM-wikiパターン（Raw/Wiki/Schemaの3層＋Lintパス）を、クエリ時点で検索するRAGとの違いから解説する連載第0回。