なぜエンタープライズAIは、いつも問いの半分にしか答えないのか。

エンタープライズ・データAIは重ならない二つのカテゴリに分裂している。統制された指標に問い合わせられない文書検索ツールと、元の文書を読んだことがないtext-to-SQLツールである。事業の成果を決める問いはほぼ必ず両方にまたがる。数値はデータベースの中にあり、理由は契約書や報告書やメールのやり取りの中にあるからだ。両方にまたがる仕組みは突き合わせを行わなければならない。つまり、文書と表の食い違いを黙って一方に寄せるのではなく、提示する必要がある。各カテゴリから一つずつ買っても、つなぎ目は生まれない。生まれるのは二つの答えと、その間で手作業の照合をする人間である。

エンタープライズ・データAIの二つの半分と、それを繋ぐ者がほとんどいない理由

購買責任者に、なぜ先四半期に特定航路の陸揚げ費用が上がったのかを尋ねると、その人は二つのものを開く。BIダッシュボードと、輸送契約のPDFである。ダッシュボードには数値がある。契約書には理由がある。両方を読めるツールが存在しないので、アナリスト本人が統合レイヤーになり、答えが出るまでに二日かかる。

この隙間は、特定の製品の手落ちではない。市場そのものの形である。

文書の側

一方のカテゴリは、企業の文書資産――契約書、報告書、届出、社内wiki、チケット、メール――を索引し、そこから答える。GleanやHebbiaのような企業向け検索・検索拡張製品がここにあり、自分の仕事をよくこなす。該当箇所を見つけ、ページを示し、千のファイルを横断して要約する。

持っていないのは、統制された数値とのつながりである。「サーチャージは実費で転嫁する」という条項は見つけられる。しかし成都―ロッテルダム航路のサーチャージ科目が先四半期に3.4ポイント動いたことは言えない。その数値はどの文書にもないからだ。それはウェアハウスの表の中、指標定義の裏、さらに権限モデルの裏にある。

指標の側

もう一方はウェアハウスから始まる。text-to-SQLと対話型分析の製品――Dot、Zenlytic、Tellius、SnowflakeのCortex Analystなど――は、普通の言葉の問いをセマンティックレイヤーへのクエリに変換し、数値を返す。出来のよいものは慎重で、結合を推測せず定義済みの指標に寄りかかり、SQLを見せる。

持っていないのは、文書への感知である。粗利が3.4ポイント下がったとは言える。しかし7月の輸送業者変更が理由だとは言えない。その変更は契約書の条項であり、物流レビューの一段落であって、どれだけSQLを重ねても届かない。

問いは必ず両方にまたがる

ここからが製品比較を超える部分である。安く答えられる問いは片側に収まっている。高くつく問い――実際に上に上がっていく問い――はつなぎ目にある。

粗利はいくらか。片側。
粗利はなぜ動いたのか、契約上それを回収できるのか。両方。
支払期日を過ぎた取引先は何社か。片側。
そのうち、まだ行使していない違約条項があるのはどれか。両方。
このプロジェクトにいくら使ったか。片側。
その支出は作業範囲記述書が承認した範囲内か。両方。

右の列の問いは、どれも役員が尋ねる問いである。そしてどれも、一つの推論の中で数値と条項を同時に握れる仕組みを必要とする。

各カテゴリから一つずつ買っても解けない理由

素直な策は、文書ツールと分析ツールを両方買って使い分けさせることだ。それではつなぎ目は生まれない。理由は三つある。

誰も突き合わせない。 報告書と表が食い違うとき――企業規模では日常的に食い違う。その報告書は前四半期の定義で書かれているからだ――独立した二つのツールは、自信のある答えを二つ返し、矛盾しているという合図は一切出さない。両方にまたがる仕組みだけがそれに気づける。そして正しい振る舞いは、平均で均すことでも索引の質がよい方を黙って採ることでもなく、食い違いを提示することである。

二つの権限モデルは合成できない。 文書ツールには独自のアクセス制御があり、分析ツールはウェアハウスのものを継承する。問いが両方にまたがったとき、「この人が今何を見てよいか」を単独で決められる場所がどこにもない。実務では片方がもう片方より緩くなり、社内AI展開はそうやって止まる。

推論がどこにも残らない。 つなぎ目がアナリストの頭の中で起きるなら、方法そのもの――どの情報源を確認し、どれを信頼し、何を調整したか――はその人と一緒に去る。翌四半期に同じ作業が少し違うやり方で繰り返され、二つの数値は一致しない。

両方にまたがるために本当に必要なもの

一つのモデルを二つのデータソースに向ければ済む話ではない。四つのことが同時に成り立つ必要があり、どれも地味である。

文書を平らにせず構造として解析すること。 誤った行に潰れた結合セルは、索引していない文書よりたちが悪い。静かに失敗するからだ。これ自体が一つの工学的課題である。
指標が定義され、バージョン管理され、再現可能であること。 今日引用する数値が4月に引用した数値と同じであるか、違うなら何が変わったかを正確に言えること。
両方の経路に一つの権限モデルを適用すること。 検索のたびにサーバー側で効かせる。プロンプトでモデルに配慮を求めるのではなく。
分析手法そのものを再利用可能なオブジェクトとして保存すること。 問いごとに即興で組み立てるのではなく。ここはほとんど誰もやっておらず、速い答えと弁明できる答えを分ける境目である。

DataFactの立ち位置

私たちはこのつなぎ目のために作った。だから構造がこうなっている。文書とデータベースに一つの取り込み口、その上に両方を覆う統制されたメモリー、さらにその上に二つの経路をまたいで検索を計画し結果を突き合わせるエージェント。サブスクリプションでも、データが外に出せないなら自社ネットワーク内でも動く。

最後の選択肢は、聞こえる以上に重い。この問題のもっとも価値ある版を抱えている企業――20年分の契約書、誰も全容を説明できないウェアハウス、日程どおりに来る規制当局――は、その一切を第三者のクラウドに送れない企業であることが多い。他社のテナントの中にしか存在しないつなぎ目は、彼らにとって存在しないのと同じである。

私たちの資料ではなくあなたの資料でこのつなぎ目が成り立つかを見たいなら、実際に議論になる報告書を一つと表を一つ送ってほしい。走らせる価値があるのはその試験である。