【要約】社内文書AIにベクトルDBは要らなかった — 全文投入で本番運用した設計と限界 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が社内文書AIを構築する際、従来のRAG構成では運用と精度に課題があった。具体的には以下の問題に直面していた。
- ・ベクトル検索によるチャンク分割が、表形式データの構造を破壊する。
- ・検索漏れと「情報が存在しないこと」の区別が困難である。
- ・文書更新のたびに再インデックス等の複雑な工程が発生する。
- ・ベクトルDBや埋め込みAPIなど、管理すべきインフラが増大する。
// Approach
開発者は、文書の総トークン数を計測し、LLMのコンテキスト内に収まることを確認した上で、全文をプロンプトに投入する設計を採用した。
- ・不変の指示をプロンプトの先頭に配置し、プロンプトキャッシュを最適化する。
- ・更新頻度に基づき、静的な文書は全文投入、動的なデータはツール利用と使い分ける。
- ・インフラをVPS 1台とsystemdに集約し、運用の極小化を図る。
- ・同名セクションが存在する場合、モデルに聞き返させる構造を導入する。
// Result
開発者は、全文投入方式により2社分のSlackボットを本番稼働させた。これにより以下の成果を得ている。
- ・ベクトルDB不要により、インフラ構成が大幅に簡素化された。
- ・表データの構造維持と、情報の有無の正確な判定を実現した。
- ・プロンプトキャッシュの活用により、高頻度な質問へのコストを抑制した。
- ・運用フローが「ファイルを置くだけ」となり、エンジニアの工数を削減した。
Senior Engineer Insight
> RAGを盲信せず、コンテキストサイズから逆算した設計は極めて合理的だ。特に「運用が壊れにくいこと」を優先した判断は、リソースの限られた現場では正解と言える。ただし、コストがトークン量に直結するため、文書肥大化への監視と、20万トークン超を見据えたルーティング設計は必須だ。技術選定において、精度の追求だけでなく、運用の複雑性をいかに排除するかという視点が重要であることを示している。