【要約】OCI Data Catalog 第4回：Data LakeとADBのRDBMS、Vector Storeを統合し、Select AIとRAGでLakehouseを検索してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
企業が大規模なドキュメント資産を運用する際、情報の所在が分散し、統合的な検索が困難になる問題に直面する。具体的には以下のペインポイントが存在する。
- ・メタデータはData Lake、管理情報はRDBMS、本文はVector Storeに分断されている。
- ・RAG単体では、承認状態や機密区分に基づいた正確なフィルタリングができない。
- ・これらを統合して検索する仕組みがないため、情報の検索精度と信頼性が低下する。
// Approach
開発者が、Oracle SQLを用いて分散した3つのデータレイヤーを論理的に統合する手法を採用する。
- ・DBMS_DCATを用い、Data CatalogのメタデータをADBの外部表として同期する。
- ・document_idと完全Object名を利用し、外部表、RDBMS、Vector StoreをJOINする。
- ・Select AI Profileを、NL2SQL用とRAG用の2系統に分離して定義する。
// Result
利用者が、文書の属性検索と本文のセマンティック検索を適切に使い分けられる環境を実現する。
- ・「承認済み文書の特定」から「その内容の要約」までの一連のフローが可能になる。
- ・Vector Tableを直接LLMに晒さないことで、検索の精度と制御性を向上させた。
- ・将来的なAI Agentによる自動統合を見据えた、拡張性の高い基盤を構築した。
Senior Engineer Insight
> 分散したデータをSQLレイヤーで統合する設計は、実戦におけるスケーラビリティが高い。特に、Vector Storeを直接NL2SQLに公開せず、Viewを介して制御する設計は、LLMのトークン消費抑制と精度維持の両面で極めて合理的だ。運用面では、Profileの分離により権限管理と責任範囲の明確化も図られており、エンタープライズ用途に耐えうる構成と言える。