ビジネスを学習し続けるコンテキスト

データカタログは人が読むためにデータを文書化したもので、クエリの処理経路の外にあります。一方、Connect AI のコンテキストレイヤーはモデルが参照することを前提に記述され、クエリの経路そのものに組み込まれています。学習できるのは、この仕組みがあるからです。また、コネクタに関するナレッジは CData 自身が持っているため、最初から情報がそろった状態で使い始められます。さらに、多くのカタログが扱わない非構造化コンテンツもカバーします。

いいえ。ソースレベルのコンテキストは CData のコネクタにあらかじめ組み込まれているため、最初のクエリから的確に処理できます。派生ビューや独自に作成した定義は、社内で解釈が分かれがちな指標の精度を高めます。ただし、これらはすでに機能しているシステムをさらに改善するためのものであり、利用の前提条件ではありません。

ありません。学習による変更は、あくまで提案です。OKF バンドルに対するレビュー可能な差分として提示され、本番環境のロジック変更と同じようにオーナーが承認します。どの種類の変更を自動で適用し、どの種類は必ず人が確認するかも、自由に設定できます。

それはごく一般的なケースで、グラフはまさにそれを想定して設計されています。同じ用語でも、Salesforce と NetSuite でそれぞれ別の意味として扱えます。グローバル用語集のコンセプトを親とし、その下にソースごとのコンセプトを配置する構造です。すべてのソースを最大公約数的な 1 つのモデルに押し込めることなく、システム全体で一貫して適用されます。

はい。virtual_schemas/ 配下のコンセプトはソースをまたぐ論理モデルを記述し、派生ビューでは接続をまたいで結合できます。CRM、ERP、データウェアハウスのデータを組み合わせた指標も、1 つのコンセプトとして文書化できます。

むしろ逆です。取得されるのはカタログ全体ではなく、一致したコンセプトとそのエッジだけなので、エージェントは探索にコストをかける必要がなくなります。ベンチマーク環境では、複数ソースにまたがるクエリのツール呼び出しが 22 回から 1 回に、トークン数が 183,541 から 4,427 に減少しました。

いいえ、むしろ逆です。コンテキストバンドルはゲートウェイに保持されるため、Claude、Gemini、GPT、Copilot、そして自社でホストするモデルのいずれも、同じインターフェースを通じてコンテキストを取得できます。プロバイダーの変更や追加はルーティングの設定だけで済み、再実装は不要です。蓄積したビジネスナレッジがモデルに縛られることもありません。

多くの場合、使えます。チームがフロンティアモデルの料金を払って行っている処理の多くは、自社のスキーマに関する推論です。この処理は、コンテキストレイヤーが一度正しく行えば、あとは再利用できます。クエリの実行前に定義が解決されるため、モデルのグレードは精度ではなくコストで選べるようになります。さらにゲートウェイは、単純な検索を高速なモデルに振り分け、高価なモデルは本当に難しい推論のために温存できます。