データアナリスト

これはベンダーの手順書と参照実装であって、どこかの企業で使われているという報せではない —— 原文は、それを動かしている雇用主を一社も名指ししていない。技術的能力として記録しており、この層はこのサイトでは評価を動かすことが決してない。三つの業務への紐づけが、それぞれ何に基づいているか:テンプレート付属の指示書は、表を見つけること、読み取り専用の SQL、そして分かったことを説明することを扱う(問い合わせを書く);その前提条件と第 3 段は、指標の定義、信頼できる絞り込み条件、そして以前に査閲された問い合わせを使う側のチームが用意することを求めており、第 9 段は、人が明示的に頼んだときにだけ訂正を保存する(道具が頼っている指標の定義を自分のものとして持つ);そして例として印字されている絞り込み —— 従業員とテスト用の口座を除く、当日の未完成な分を除く、8 月 18 日に携帯での決済の計測が変わった —— は、データがどこで嘘をつくかについてのアナリストの知識であり、agent が見つけたものではなく人が与えたものである。日付は、この例を加えた cookbook の commit から取った。展示のページ自体に日付がないからである。

実演、ベンチマーク、あるいは論文が、その業務をやれることを示している。技術に何ができるかを更新するのであって、雇用主が何をするかを更新するのではない。

このベンチマークの著者自身が書いたものであり、著者らは競合する系(Rubicon)も売り込んでいる——つまりここでの利害関係者は「簡単なベンチマークのほうが間違っている」と論じている。もとになっている主張は確かめられる。Beaver は MIT の1,400テーブルの Oracle 基盤と他の三つの実際の問い合わせ記録からつくられており、順位表は公開されている。挙げられている四つの理由は、モデルの出来ではなく構造に関わるものである——公開ベンチマークのデータは学習資料に入っている、現実のスキーマは腐って「salary」という名の列が六つに増える、基盤にはその土地固有の言い回しがある、そして現実の問い合わせは一つではなく二つ三つのテーブルを結合する。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

英国の法定の統計規制当局が、公的統計の体系について報告したものである。公的統計の作成や伝達にAIを使う作成者は、ほかの統計手法やモデルと同じように「Code of Practice for Statistics」(統計の実務規範)を適用すべきであること、改訂される指針は品質保証、人による監督、そして出力についての明確な責任の所在を扱うこと、そして公的統計におけるAIの利用は、定常的な作成ではなく、主に研究、試験、事務の補助にとどまっていることを述べている。対象は事業のアナリストではなく政府の統計家であり、指針はまだ改訂の途中である。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

LinkedIn の社員による、社内の text-to-SQL チャットボットについての論文である。このボットは2024年7月から LinkedIn の問い合わせの基盤で使えるようになっており、週あたり300人を超えるアクティブな利用者が継続的に使っている。土台は知識グラフであり、そこではデータセットの所有者が各列を指標、ディメンション、属性のいずれかとして注記し、よく使われるテーブルには人が書いた説明が付いている。これらの構成要素によって、正しい、またはほぼ正しいと採点される答えは9%から48%に上がった。本番の答え124件を専門家が見直したところ、53%が正しい、または軽微な問題のみと評価され、最も多い問題は誤った絞り込み条件(24%)だった。著者らは、最新のクリック率を求める依頼がチームによって違う意味になることを指摘している。一社の社内の道具であり、測ったのはそれをつくった人たちである。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

Grab のエンジニアが、自社の社内のデータの道具について書いたものである。最も頻繁に問い合わせられるテーブルのうち、説明文があったのは20%だけだった。チームは最も重要なテーブルにAIが生成した説明文をあらかじめ入れてデータの作成者に見直すよう通知し、作成者が受け入れるか手直しするまでは「AI生成」の札を付けて表示した。こうしてそれらのテーブルの文書化率は70パーセントポイント上がっておよそ90%になり、そのあとで LLM による探索のボットが公開された。ボットは Grab が使っているベンダーのプラットフォームの上で動いており、数字は会社自身のものである。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

一社での限定的な展開である。Uber の基盤では対話的な問い合わせが月におよそ120万件動いているので、これはごく一部にあたる。記事自身が、存在しないテーブルや列の捏造と、指示文の質を未解決の問題として挙げている。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

SQL の腕だけで入るのは以前より弱い。そこは道具がやる部分だからである。強い入り方は、領域とデータの組み合わせである——ある事業領域を、その数字が何を意味しどう壊れるかが分かるくらい深く学び、問い合わせのほうは道具に任せる。定義を書き残すという地味な仕事に手を挙げること。新しいアナリスト像はそこで形になりつつあり、いまのところ誰もやりたがらない。

一週間の大半がレポートの依頼をさばくことなら、依頼者が自分で触れるようになるにつれてその行列は縮むと見ておくこと。そして、ダッシュボードを何枚出したかではなく、自分の仕事がどの判断を変えたかで測られるようになると見ておくこと。データがどこで壊れるかについての蓄えた知識が資産である。それを意味の層と定義に変えれば、自分で触れる道具が正しい答えを返す理由そのものが、あなたになる。

職の形を組み替える

問いに答える側から、定義を持つ側へ

利用者が自分で分析できるようになると、詰まりどころは問い合わせを書くことから、その下の指標が正しいかどうかへ移る。そう言っているのはベンダー自身である:OpenAI がこの仕事のために公開している agent の template は、指標の定義、信頼できる絞り込み条件、そして以前に査閲された問い合わせを、始める前にチームが用意しなければならないものとして並べている。その層を引き受けることは、ダッシュボードを引き受けるより長持ちし、より上級である。

隣へ移る

アナリティクスエンジニアリングへ

手前でデータを整えるモデルと取り込みをつくることは、アナリストの労力が移りつつある先であり、報告より報酬も高い。

隣へ移る

事業部門に組み込まれたアナリストになる

財務、オペレーション、プロダクトの各チームは、依頼票を受け取る中央の窓口ではなく、その領域を分かっている自分たちのアナリストを望むようになっている。領域の知識が堀である。

ある。ただし以前とは理由が違う。書く量は減り、読んで確かめる量はずっと増える。問い合わせが何をしているかを分かっていることこそが、曖昧なスキーマから道具が出した自信たっぷりの誤答を捕まえさせてくれる——そしてその捕まえることが、いまの仕事である。編集者が文法を知っているのと同じ意味で SQL を学ぶこと。すべての文を自分で書くためではなく、間違っている文をその場で見抜くために。

信号は、誰が問い合わせを走らせているかである。管理職が自分の問いをあなたに送らず、自分で触れる道具のなかで自分で答えはじめたとき、変化はもう届いている——そして最初に失うのは職ではなく、データとの日々の接触、つまりそれが間違っているときに気づけるようにしていたものである。

問い合わせを書くこととダッシュボードをつくることであり、ここでは自動化と印をつけている。問いを立て直すことと、データが嘘をついていると気づくことはそうではないが、どちらも文脈を持てるだけ仕事に近いことに依っており、利用者が自分で触れるようになるほど、あなたはそこから遠ざかる。

それは本物の仕事であり、このサイトも新たに生まれた業務と印をつけている。同時に、組織に一つしかない職であり、問いに答えることより小さい。人員がそこへ「振り向けられる」という言い方は、より小さいチームが別の仕事をすることの丁寧な表現である。