Google Drive資料をRAG化する前に作る、index_sheetの列設計と検索キーの決め方

AI編集部を作ろうとすると、
多くの人は最初に「検索」を作りたくなります。

RAG。

ベクトル検索。

OpenAI embeddings。

全文検索。

もちろん重要です。

でも、
実際にGoogle Driveの資料をAIへ読ませ始めると、
もっと手前で壊れます。

「どの資料を拾えばいいのか分からない」

です。

しかも、
これはAI性能の問題ではありません。

資料側が、
検索される前提で整理されていない。

これが原因です。

人間は、
何となく覚えています。

「あの資料」
「前に作ったやつ」
「価格ルールのやつ」
「失敗した時のメモ」

でも、
AIは違います。

曖昧検索はできます。

でも、
曖昧なまま大量資料を渡すと、
関係ないものまで拾います。

すると、
AI編集部が壊れます。

たとえば、

見出しルールを参照したかったのに、
古い価格ルールを拾う。

禁止事項DBより、
途中メモを優先する。

最新運用より、
昔の仮ルールを返す。

こういう事故が起きます。

ここで重要なのが、
index_sheetです。

私は、
RAGを作る前に、
まずindex_sheetを作るべきだと思っています。

なぜなら、
index_sheetは、
「AIが資料を探すための地図」
だからです。

Google Driveに資料を置くだけでは、
AI編集部は強くなりません。

むしろ、
資料が増えるほど迷います。

だから必要なのが、
「どんな資料なのか」
を事前に整理するシート。

これが、
index_sheetです。

しかも、
ここで重要なのは、
人間向け整理ではありません。

AI検索向け整理です。

つまり、

「AIがどう探すか」

を前提に作る。

これがかなり重要です。

たとえば、
人間向けなら、

「最新」
「メモ」
「仮」
「あとで読む」

でも成立します。

でも、
AI編集部では弱い。

検索キーとして曖昧だからです。

特に、
技術書フェーズでは、
資料数が増えます。

RAG。

API。

GAS。

価格ルール。

禁止事項。

見出し。

JSON。

ログ。

復旧フロー。

管理盤。

この状態で、
Google Driveへ雑に置くと、
検索事故が起き始めます。

だから、
RAG前にindex_sheetを作る。

これがかなり大事です。

ここから、RAG前提のindex_sheet設計へ入ります。