広義のRAGでは！！！！！！！！
RAGが銀の弾丸じゃないってのは現場の総意だよな。エージェント型が主流になるのも納得
RAGって文字通りIR(Information Retrieval: 情報検索)の拡張なのに、IRの要素はベクトル検索ばかり話題になっててhype味を感じるんよな
Amazonとか巨大なサイトで使うRAGと普通の企業が使うものを一緒にするのが間違いの発端
コードベースの調査には仰る通りAgentic Search、「で、なんで今このコードになってるの？」はGraphitiで賄う感じで今試してる
Agenticかどうかは最初から検索結果を強制的にプロンプトに入れるか、それともツールの形でLLMが主体的に検索を起動するかの差じゃないの?ただBoris氏の発言はベクトルDB使わないという意味に読めるな
どんどんと進化していく。
追記の "「AIに何を持たせるか」よりも 「人間がAIに対してどんな環境を用意するか」の方が、実はずっと重要なのではないか" を見て、ルンバが思い浮かんだ。
“論文 ”
RAGとAgentic Searchとembeddingがこんがらがってるのよねgrepの横並びにembeddingベクトル検索があってAgentic Searchはユーザーに回答を返す前に何回検索するかの話でRAGはaiが学習してない外部知識を使うこと全般
現在では王道RAGを先に試す理由は減ってきているかも。
"ルンバが物とぶつからないように 人間が事前に障害物を整理して 導線を確保"
黎明期だから好き勝手名前つけてるだけでそのうち収束すると思う
Agentic Searchの結果を RAG化するといったアプローチではだめなんだろうか。トークン基準でチャンク分割するのが筋が悪いのだと思うんだが
社内ドキュメントを用いた回答も、「事前にAIにタグづけさせる/ドキュメント階層を整理させる（構造化）」→Agentic Searchの方がうまくいきそうな気配を感じる
VectorDB hypeは下火だけどGraphRAGは盛り上がってきているわけで、要はretrievalにも予測可能性や説明可能性があった方が良い(ケースが多い)よね、という話では。LLM/Agent側の計画能力の向上もあるだろうし
“実務では、両者を組み合わせるハイブリッドが最も現実的”
実際はripgrepなどの高速なgrepをcodexもやってる。多分誰もベクトルDBやってない
ドキュメント検索やナレッジ管理では、今でも王道RAGは最強です。コードのように構造化された世界ではAgentic Searchが向いているだけです
結局他人に任せられる環境を作っておけばAIにも任せられるっていう
ベクトルDBを使った狭義のRAGの話だった。Agentic Searchというのも広義のRAG。まあ簡易的に実装できる自作邪道RAGでバランス取れてるかな今のところ。
HNSWやagent searchはメダリオンアーキテクチャのようなものであり古い意味のRAGはメダリオンアーキテクチャ以前のDWHどう作るかの議論に似ている気がする
ベクトルDBを全面採用したのは扱えるコンテキストが小さいが故の苦肉の策だからね、過渡期のハック／今後は複数の手段を利用する情報収集専門のAgentと組み合わせるようになると思われ
なぜかRAGと聞くと前処理段階をイメージしてしまっていたけど要は取得と生成だったな
実際問題、狭義のRAGを使ったPoC開発がたくさんあるけど、上手く行ってないよね
この内容で冒頭の図がAI生成じゃなくていらすとやなの、謎の味がある
そりゃそうだろうとしか。時間含むコスト度外視なら全部調べさせたほうが良いけど、それだと金銭・時間コストが高いから事前のドキュメンテーションとその検索が有効だという話であって。
なるほど納得感がある。学習次第という側面もあるのかな。
claude.aiやClaude DesktopのProject Knowledgeでは分量が多くなるとRAG管理になるので、知識のストックをしたければそちらで
Claude Code は従来の RAG（検索強化生成）ではなく、AI が探索・実行・検証を自律的に回す Agentic Search を採用。単純検索より複雑タスクへの適応力向上を重視した設計選択が背景にある。
無能と優秀な人の共著みたいな文章。正しい論述の合間に思い込みの駄文が挟まってる。タイトルは駄文。全部ひと繋がりの技術。この「Agentic Search」が何やってるのか不明なのに、分かった気でいるコメントに笑うわ（笑
なぜ、Claude Codeは、RAGを捨ててAgentic Searchを選んだのか？
広義のRAGでは！！！！！！！！
RAGが銀の弾丸じゃないってのは現場の総意だよな。エージェント型が主流になるのも納得
RAGって文字通りIR(Information Retrieval: 情報検索)の拡張なのに、IRの要素はベクトル検索ばかり話題になっててhype味を感じるんよな
Amazonとか巨大なサイトで使うRAGと普通の企業が使うものを一緒にするのが間違いの発端
コードベースの調査には仰る通りAgentic Search、「で、なんで今このコードになってるの？」はGraphitiで賄う感じで今試してる
Agenticかどうかは最初から検索結果を強制的にプロンプトに入れるか、それともツールの形でLLMが主体的に検索を起動するかの差じゃないの?ただBoris氏の発言はベクトルDB使わないという意味に読めるな
どんどんと進化していく。
追記の "「AIに何を持たせるか」よりも 「人間がAIに対してどんな環境を用意するか」の方が、実はずっと重要なのではないか" を見て、ルンバが思い浮かんだ。
“論文 ”
RAGとAgentic Searchとembeddingがこんがらがってるのよねgrepの横並びにembeddingベクトル検索があってAgentic Searchはユーザーに回答を返す前に何回検索するかの話でRAGはaiが学習してない外部知識を使うこと全般
現在では王道RAGを先に試す理由は減ってきているかも。
"ルンバが物とぶつからないように 人間が事前に障害物を整理して 導線を確保"
黎明期だから好き勝手名前つけてるだけでそのうち収束すると思う
Agentic Searchの結果を RAG化するといったアプローチではだめなんだろうか。トークン基準でチャンク分割するのが筋が悪いのだと思うんだが
社内ドキュメントを用いた回答も、「事前にAIにタグづけさせる/ドキュメント階層を整理させる（構造化）」→Agentic Searchの方がうまくいきそうな気配を感じる
VectorDB hypeは下火だけどGraphRAGは盛り上がってきているわけで、要はretrievalにも予測可能性や説明可能性があった方が良い(ケースが多い)よね、という話では。LLM/Agent側の計画能力の向上もあるだろうし
“実務では、両者を組み合わせるハイブリッドが最も現実的”
実際はripgrepなどの高速なgrepをcodexもやってる。多分誰もベクトルDBやってない
ドキュメント検索やナレッジ管理では、今でも王道RAGは最強です。コードのように構造化された世界ではAgentic Searchが向いているだけです
結局他人に任せられる環境を作っておけばAIにも任せられるっていう
ベクトルDBを使った狭義のRAGの話だった。Agentic Searchというのも広義のRAG。まあ簡易的に実装できる自作邪道RAGでバランス取れてるかな今のところ。
HNSWやagent searchはメダリオンアーキテクチャのようなものであり古い意味のRAGはメダリオンアーキテクチャ以前のDWHどう作るかの議論に似ている気がする
ベクトルDBを全面採用したのは扱えるコンテキストが小さいが故の苦肉の策だからね、過渡期のハック／今後は複数の手段を利用する情報収集専門のAgentと組み合わせるようになると思われ
なぜかRAGと聞くと前処理段階をイメージしてしまっていたけど要は取得と生成だったな
実際問題、狭義のRAGを使ったPoC開発がたくさんあるけど、上手く行ってないよね
この内容で冒頭の図がAI生成じゃなくていらすとやなの、謎の味がある
そりゃそうだろうとしか。時間含むコスト度外視なら全部調べさせたほうが良いけど、それだと金銭・時間コストが高いから事前のドキュメンテーションとその検索が有効だという話であって。
なるほど納得感がある。学習次第という側面もあるのかな。
claude.aiやClaude DesktopのProject Knowledgeでは分量が多くなるとRAG管理になるので、知識のストックをしたければそちらで
Claude Code は従来の RAG（検索強化生成）ではなく、AI が探索・実行・検証を自律的に回す Agentic Search を採用。単純検索より複雑タスクへの適応力向上を重視した設計選択が背景にある。
無能と優秀な人の共著みたいな文章。正しい論述の合間に思い込みの駄文が挟まってる。タイトルは駄文。全部ひと繋がりの技術。この「Agentic Search」が何やってるのか不明なのに、分かった気でいるコメントに笑うわ（笑