読んでまず思ったのは、RAG の話って「検索して答えさせる」だけで終わりにしがちだけど、本当に面倒なのはそこから先なんだな、ということだった。デモなら動く。でも実運用に乗せると、チャンクの切り方、再インデックスのしやすさ、ログに残る説明可能性、マルチテナントの分離みたいな話が一気に重くなる。記事はその泥臭い部分をちゃんと見ていて、そこは素直に好感が持てた。
特に引っかかったのは、MCP を「接続の標準」として置いているところだ。RAG と vector database だけなら、まだ「まあよくある構成」で済む。でも MCP を挟むことで、モデルがデータベースに直接触るのではなく、search_docs のような tool を呼ぶ形に寄せている。これ、地味だけど大きいと思う。各チームが個別に glue code を作るのではなく、検索能力そのものをひとつのサービスとして扱えるからだ。モデル周りの話はつい賢さに目が行くけれど、実際に壊れやすいのは接続面なんだよな、と改めて感じた。
もう一つ、地味に刺さったのは semantic cache の話だった。RAG の議論では「どう賢く検索するか」に寄りやすいけれど、現場では同じ質問が何度も来る。そうなると、毎回 embedding を作って vector DB を叩くのは贅沢すぎる。速度もコストも食う。この記事はそこを「入れたほうがいい」ではなく、かなり現実的な前提として扱っていて、その感覚はわかる。派手ではないけれど、こういう層がないと production では息が続かない。
逆に言うと、この記事は「AI の新しさ」より「システムとして普通に運用できるか」に関心がある。そこが面白いし、少し冷静でもある。RAG を魔法みたいに語るのではなく、chunking、metadata、idempotent な upsert、filter、cache といった、あまり華やかではない部品の積み上げとして見ている。こういう視点は、派手なデモに慣れた後で読むと効くと思う。
