お疲れ様です、桑野です。

最近、こちらの hopop_data さんの記事 を興味深く読みました。

月10,000件の分析自動化AIエージェントを1年運用したというエントリで、「セマンティックレイヤー必須論」に対する違和感が言語化されていて、読んで色々考えるところがありました。 なので、ちょっと別の角度で「自分はセマンティックレイヤーをどう位置づけてるか」を書いておきたくなった、というのが今日のこのブログの目的です。

最初にお断りなんですが、論破合戦をしたいわけじゃなく、選択肢を整理しておきたいだけですので、その前提で読んでいただけると、、、!

「Genie Space 使うならセマンティックレイヤー必須」って案内はしてないはず?

たまに「Databricks Genie Space を使うならセマンティックレイヤー作らないとダメ」みたいな空気感の話を聞くんですが、自分の観測範囲では、Databricks 側から絶対にそう!という意味ではそういうご案内はしていないです。

Databricks Genie Spaceを一言で噛み砕くと 「自然言語で質問するとSQLを書いてデータを返してくれるエージェント」 で、これは Gold レイヤー(メダリオンアーキテクチャの最終層、整形済みのきれいなデータ)をそのまま食わせても動きます。

つまり「セマンティックレイヤー作らないと Genie Space 使えません!」というのはちょっと事実と違っていて、「セマンティックレイヤーがあると、より組織的にKPIを揃えやすくなる」という価値の話、というのが個人的な整理です。

ここのニュアンスは割と伝わりきれてないのかなぁとは思いました。

で、セマンティックレイヤーって結局なんやねん?

一文で噛み砕いて書くと、セマンティックレイヤー(Databricks なら Metric View なんかが該当)は KPIや指標の定義を一箇所に集めて、誰がどこから引いても同じ値が返るようにする層 です。

何が嬉しいかというと、

  • 組織で決めた値が組織に浸透する: 「売上」「アクティブユーザー」みたいな定義を、人によって計算式がブレないようにできる
  • 横串で同じ定義を使い回せる: アドホックなSQLでも、定常運用のダッシュボードでも、AIエージェントへの問いかけでも、同じ「売上の定義」を引っ張ってこれる

こういうのがハマるユースケースだとめちゃ強い武器になります。

Genie に Gold そのまま食わせる場合

「じゃあ Gold そのまま Genie Space に入れて使うのは何がしんどいの?」というと、自分が触った範囲では、Genie Space をうまく動かすには データに対してメタデータをある程度付与していく必要がある場合もあります。

ここでいうメタデータというのは、

  • カラムの説明(このカラムは何を意味してるか)
  • テーブル間の関係性
  • ビジネス用語との対応(「売上」って言ったらこのカラム、みたいな)
  • サンプルクエリ(こういう質問にはこういうSQLを書いてね、という例示)

みたいな、Genie Space が自然言語からSQLに翻訳する時に「これはこういう意味だよ」と教えてあげる情報のことです。

これを丁寧に整備すれば、生のテーブルでもけっこうな精度で動かせるんですが、「組織の指標定義を、組織全体に正として浸透させたい」という目的に対しては、ちょっとファットというか、用途が一致しない という感覚があります。

セマンティックレイヤーはあくまで「指標のマスターデータを置く場所」で、Genie Space に食わせるメタデータは「自然言語SQL変換のための補助をするための情報」。似てるけど別物、と思ってます。

そもそも目的が違う、と思うんですよね

ここが 記事を読んで個人的に一番引っかかった点で、「分析自動化AIエージェント」と「セマンティックレイヤー」って、一次的な目的が違うと思いました。以下の様な違いだと思います。

  • 分析自動化AIエージェント: AIが自然言語の質問を解釈してデータを返す、AIに最適化されたデータ基盤の話
  • セマンティックレイヤー: 人間が組織として共通言語で指標を扱うための、指標のマスター管理の話

どっちが正しい・間違ってるというよりは、解こうとしている課題が違う気がしています。

なので「AIエージェント運用にセマンティックレイヤーだけで必要十分か?」という問いに対しては、自分も「必要十分ではない」というのは深く同意です。けど、それはセマンティックレイヤー不要論ではなくて、セマンティックレイヤーは別の課題を解いているという話だと思っています。

精度はいける、けど「そこまでの手間」が違う

精度面でいうと、Genie Space にしっかりメタデータを整備すれば、セマンティックレイヤー経由と同等の精度を出せるケースは多いと思います。

ただ、そこに持っていくまでの労力 は大きく変わるんじゃないかと。

セマンティックレイヤーで指標を定義しておくほうが、Genie のメタデータをカラムレベルでガッと整備するより、すんなりと進むケースが自分の観測範囲では多い印象です。もちろんユースケースによりますし、そこまでの手間をかけなくても成果が出せるパターンもあると思いますが。

特に「同じ指標定義を、複数のダッシュボード・複数のSQLクエリ・AIエージェント、全部に展開したい」みたいな話だと、セマンティックレイヤーの構造がそのまま効いてくるのではないかと。

横串で同じ定義を使い回せるのが、地味にデカい

繰り返しになりますが、ここがセマンティックレイヤーの一番の価値だと思ってます。

  • アドホックな分析クエリ
  • 定常的なダッシュボード
  • AIエージェント(Genie でも Text-to-SQL でも)

これら 全部に同じ「売上の定義」を引っ張れる、というのは、組織が大きくなればなるほど効いてきます。

「うちの売上ってどう定義してる?」と聞いて、人によって違う答えが返ってくる組織、、、きっと、あると思います。これを揃えるための装置として、セマンティックレイヤーは効いてくるわけです。

どちらか、じゃなくて使い分け

ということで、自分の結論としては、

  • セマンティックレイヤー: 組織の指標を正として揃えたい時/人間とAI両方に共通言語を提供したい時に効く
  • Gold 直の Genie(生データ+メタデータ): 探索的な分析/深掘りの要件/まだ指標定義が固まりきっていないドメインで効く

ユースケースによってどちらも必要 という立場です。どっちかに寄せる議論ではなくて、「何を解きたいか」で選ぶ、というのが現時点での自分の整理だと思います。

セマンティックレイヤーがハマる組織・ハマるユースケースでは、これは間違いなく組織の強い武器になります。一方で、AIエージェント運用の文脈で「セマンティックレイヤーがあれば全部解決」と言うほどでもない、という hopop_data さんの観察にも、その視点では自分は正しいなと思います。

ようするに 見方と立場で有用性は変わってくるんじゃないかなー という結論でした。

Semantic View是非使ってみてください!(宣伝)

“セマンティックレイヤーはいる?いらない?の巻” への1件のフィードバック

  1. Keita FUJIMOTO のアバター
    Keita FUJIMOTO

    同記事を読んで違和感と言うかモヤモヤを感じていたので、このエントリーを読んですっきりしました。

    いいね

コメントを残す

Trending