ChatGPT が最初に大流行した頃、元同僚からテキストメッセージが届きました。彼は私にアイデアを相談したいと言っていました。いつもブレインストーミングを楽しむ彼は電話で話し始めました。彼は「いつも私にデータを引き出すように頼んでいたのを覚えてる？自分でデータを引き出せたらどう？」と切り出しました。そして、何千人（何万人？）もの人が同時に考えていたアイデアを私に提案しました。それは、テキストから SQL への変換に LLM を使用すれば、技術に詳しくない人でもデータに関する質問に自分で答えられるようになる、というアイデアです。 私はそのアイデアに夢中になりましたが、飛び込む前に、Lei (現在の私の CTO) に検証が必要だと伝えました。私たちはさまざまな業界の友人や元同僚に連絡を取りました。本物の「セルフサービス分析」に強い関心がありました。見た目よりもはるかに複雑であることはわかっていましたが、この機会を逃すのはもったいないと思いました。そこで、Lei と私は The Shire を離れ、ビジョンを形にする旅に乗り出しました。 。 ファビ この投稿は当社の製品自体に関するものではありません（ただし、興味があれば、以下のアイデアのいくつかが当社の最近の製品開発にどのように影響したかについてさらに読むことができます）。 ）。代わりに、私たちがこの旅の途中で LLM と連携してデータ分析に取り組んで得た中核的な学びを共有したいと思いました。   ここ 注: この旅には魔法使いや中つ国の壮大な戦いがまったくありません。🧙 セルフサービス分析に AI を使用する理由 「なぜ」について長々と語るつもりはありません。これを読んでいるあなたは、おそらく次の 2 つのグループのいずれかに当てはまるでしょう。 セルフサービス分析が利用できることを望んでおり、常にデータチームを待たずに済むことを望んでいる人 あなたはデータ チームに所属しており、AI がアドホック リクエストの問題の解決にどのように役立つかについて聞いてきました。 データ アナリストやデータ サイエンティストの役割に関する懸念を無視すれば、組織のデータに関するあらゆる質問に答えられる全知の AI というアイデアは魅力的に思えます。少なくとも、新しい質問の仕方に対する創造性が際限のない組織やそのビジネス リーダーにとっては魅力的に思えます。この AI は、すべてのリーダーが経験的証拠に基づいて戦略的決定を下す「データ駆動型」組織を作成するためのソリューションになる可能性があります。しかも、通常かかるコストのほんの一部で済みます。ついに、組織は 2010 年以来耳にしていた「新しい石油」を活用できるようになります。 しかし、これが解決すべき非常に価値のある問題であり、AI が非常に優れたものになっているのなら、なぜこれまで これを解決した製品がないのでしょうか? 実際に セルフサービス分析のためのAIがこれまで失敗してきた理由 最近の業界調査では、企業における AI 導入の複雑な状況が描かれています。 AI エージェントを試用している企業は数多くあります。しかし、信頼性とセキュリティを懸念する企業も多く、実際、21% の組織は AI エージェントをまったく使用していません。こうしたためらいは、正確性と信頼性が業務遂行能力にとって極めて重要であるデータ チーム内で特に強く感じられます。   61パーセントの企業が  AI を導入する企業、特に企業では、テクノロジーに対する期待値が非常に高くなっています。データ分析とセルフサービスという夢の文脈において、私たちは AI ツールに次のことを期待しています。 洞察力を提供する: 表やグラフは素晴らしいものですが、これらはいわゆる「洞察力」の一部です。洞察力とは、データ内で直感に反し、そうでなければ考慮しなかったものを発見したときに得られる「なるほど!」という瞬間です。SQL クエリやピボットによってこれらの洞察力が明らかになることもありますが、一般的には干し草の山から針を探すような感じです。 ほぼ 100% の時間、確実に動作します。データがないよりも悪いのは、不正なデータだけです。AI が信頼できない場合や、回答やデータを幻覚で表現する場合は、誰にとっても悪い知らせとなります。つまり、AI にデータがある場合は、それを正しく使用する必要があります。ただし、データが不足している場合は、回答を出さないようにする必要があります (LLM が苦手なことで有名です)。 幅広い技術スキルを持つ人々にアクセス可能: LLM の利点は、Slack で同僚とやり取りするのと同じようにやり取りできることです。あいまいな言葉を使うことができます。ビジネス コンテキストでは、相手や相手があなたの要求を理解できる可能性が高くなります。逆に、正確な用語を正確な形式で使用する必要があるシステムほど、アクセスしにくくなります。このタイプのシステムにはトレーニングと強化が必要ですが、これは誰もが知っているように、困難な場合があります。 残念ながら、現在のソリューションのほとんどは従来のモノリシック AI フレームワークを使用しており、期待に応えられないことがよくあります。過去数年間、Fabi.ai チームと私はこの問題に懸命に取り組んできました。エンタープライズ向けのプロトタイプを構築し、多くのオプションを検討しました。最終的に、現在のモノリシック フレームワークでは、検索拡張生成 (RAG) も微調整もこの問題を解決できないことがわかりました。  このアプローチをテストしたところ、いくつかのことが明らかになりました。  RAG は脆弱です。コンテキストが少なすぎると、AI は質問に答えられず、幻覚を起こす危険があります。コンテキストが多すぎると、AI は混乱し、正確さを失います。 ワンショット AI では何も得られません。世界最高の AI でも、1 回のショットでデータを正確に抽出して分析することはできません。データと質問には、ニュアンスが多すぎるからです。できるだけ単純な例を見てみましょう。「アカウント タイプ」フィールドがあり、その 95% が 10 個の異なる値で埋められているとします。AI にアカウント タイプのセットでフィルター処理するように指示すると、空白の値があることを認識できず、無効な SQL クエリが生成される場合があります。「確かに、各フィールドの統計とサンプル値を計算し、それをコンテキスト ベクトル ストアに保存するだけで済みます」と言うかもしれません。問題の種類はほぼ無限であり、すべてが独自の方法でユニークです。 エンタープライズ データは乱雑です。これは最初の 2 つのポイントに関連しますが、強調する価値があります。たとえ一瞬の間、組織が完璧に定義されたセマンティック レイヤーを持つゴールド テーブルをいくつか持つことができたとしても、RevOps リーダーがビジネス モデルを調整するとすぐにすべてが崩壊します。私は家のアナロジーを引用するのが好きです。一般的に、家はかなりきちんと整頓されていますが、常に掃除や修理が必要な があります。 もの テキストから SQL への変換は制限が多すぎます。ほとんどのデータ分析の質問では、データを引き出す SQL を書くことは、最初のステップにすぎません。これは、より興味深い質問をする前に実行する必要があるステップです。SQL では、ビジネス ユーザーが求める複雑な分析を処理できません。一方、LLM と Python は、このタスクに最適です。これらのツールは、SQL 出力を取得して、干し草の山から針を見つけることができます。また、回帰分析を実行して、より大きな傾向を明らかにすることもできます。 これらの問題を検討した後、私たちは AI を問題にうまく適応させるにはどうしたらよいかを考えました。そこで AI エージェントが登場し、このコンセプトを固めてくれました。 未来: エージェントメッシュ エージェント フレームワークを目にした瞬間、これが状況を変えるだろうと分かりました。突然、AI に質問への回答方法を決定させることができると感じました。AI は、手順を実行し、自動的にトラブルシューティングを行うことができます。AI が「アカウント タイプ」フィールドに null 値がない SQL クエリを記述した場合、クエリをドライ ランしてエラーを見つけ、自動的に修正することができます。しかし、これをさらに進めて、AI が主に Python で動作し、LLM を活用できるようにしたらどうでしょうか。これで、AI はデータを取得する以上のことを行います。通常は手動で探す必要がある外れ値、傾向、独自の洞察を見つけるために、Python パッケージまたは LLM を使用できます。 しかし、まだ問題が1つありました。それは、乱雑な企業データです。私たちは、組織が強力なデータエンジニアリング手法、たとえば そして厳密なセマンティック レイヤーです。しかし、実際にこれを実行している組織はほとんどありませんでした。ほとんどの組織は、スプレッドシート、中途半端な表、常に変化するデータ モデルを使用しています。ここから、特定の一連の質問に迅速に回答できる特殊な AI エージェントを構築するというアイデアが生まれました。 メダリオン建築 企業が成長するにつれて、取り扱うデータやユーザー数も増えます。エージェント メッシュの考え方は、迅速な意思決定とガバナンスに必要な制御のバランスをとるのに役立ちます。専門のエージェントは、各 AI の明確な境界と責任を設定するのに役立ちます。また、エージェントが通信するためのスケーラブルな方法も作成します。さらに、チームや企業全体でリソースを効率的に管理するのに役立ちます。 専門のAIエージェント 特殊エージェントの背後にある考え方は、このエージェントは非常に厳密に定義されたデータセットに関する質問にのみ回答できるというものです。たとえば、マーケティング キャンペーンに関する質問に答える AI エージェントを作成して起動できます。または、マーケティング パイプラインに関する質問に答える別のエージェントを構築することもできます。  、このアーキテクチャを使用しています。初期の兆候は非常に有望です。データセットが慎重にキュレートされ、適切な粒度レベルであれば、これらのエージェントは特定の質問セットに非常に確実に回答できます。これらのエージェントの作成者は、それらを非技術系ユーザーと共有し、AI が範囲外の質問には回答しないことを知って安心できます。   最近、エージェントアナリストをリリースしました ただ 1 つ欠点があります。ユーザーは、どの質問に対してどのエージェントに問い合わせればよいかを知る必要があります。これは、一般的な質問をするのと、質問をする適切なマーケティング アナリストを知る必要があるのと似ています。一般的な質問であれば、チームの誰かが適切な担当者に問い合わせることができます。ここで、「エージェント メッシュ」という概念が役立ちます。 エージェント同士を繋ぐ 単一のエージェントがドメイン固有の質問に確実に回答できるのであれば、エージェント同士が会話できるようにしてはどうでしょうか。たとえば、マーケティング キャンペーン エージェントがパイプライン エージェントに、質問にもっと簡単に回答できるかどうかを直接尋ねられないのはなぜでしょうか。私たちはそれができるはずだと考えています。実際、将来的にはエージェントのネットワークが階層構造になると考えています。「GTM エージェント」が「マーケティング エージェント」に電話をかけると想像してみてください。このエージェントは次に「パイプライン エージェント」と「マーケティング キャンペーン エージェント」の両方に電話をかけます。 このアイデアは、AIの周りで広まっている「 「それは、AI エージェントがさまざまな組織間でスムーズに連携する未来です。セキュリティと信頼を強固に保ちながらこれを実現します。    エージェントのインターネット このメッシュ アプローチは、モノリシック AI (純粋なセマンティック レイヤー上) に比べて、いくつかの重要な利点があります。 可観測性: 単一のエージェントが特定のデータに基づいて回答を提供するため、各回答をそのエージェントまでさかのぼって追跡できます。これにより、監査を通じて精度を確保できます。具体的で、かつ非常に単純化した例を挙げると、マーケティング用と製品用の 2 つのイベント テーブルがあるとします。ユーザーが「どのイベントが最も収益を生み出しましたか?」と質問した場合、AI は製品イベントを意味していると想定する可能性があります。たとえそれが間違っていたとしても、ユーザーはどのエージェントが応答したかを確認し、AI を誘導できます。 保守性: 車のエンジンと同様に、問題を簡単に見つけて部品をすぐに交換できれば、車の信頼性は高まります。データ モデルの変化により 1 つのエージェントに障害が発生した場合、すぐにそれを特定して、そのエージェントを更新できます。 正確性: 各エージェントは独自の制限内で動作するため、軌道から外れる余地はありません。答えは見つからないかもしれませんが、奇抜なことは起こりません。 結局のところ、メッシュというアイデアは目新しいものではありません。これは、LLM の精度を向上させることが実証されている専門家の混合という概念を反映しています。これは、同じアイデアを AI エージェントに取り入れただけです。 エージェントメッシュの技術的課題 Fabi.ai では、アナリスト エージェント メッシュの構築にはまだ長い道のりが残っています。しかし、その過程で、すでにいくつかの大きな技術インフラストラクチャの課題を克服しました。  AI データ アナリスト エージェントには、独自のアーキテクチャが必要です。この設計では、エージェントが Python または LLM を使用して質問に答え、データ ソースと同期し、コラボレーション プラットフォームに適合しながら、セキュリティとスケーラビリティを維持できるようにする必要があります。各エージェントは独自の Python カーネルで動作する必要があり、コストを削減し、ソース データと同期を維持するために、カーネルをすばやく起動または停止する必要があります。  各エージェントに個別のカーネルを提供しないアーキテクチャでは、次のいずれかのリスクが発生する可能性があります。  AI エージェント間の変数の状態競合。2 つの別々のエージェントが質問に答えるために「foo」変数を生成すると、衝突が発生します。一意の識別子を生成する方法は他にもあるかもしれませんが、AI が無効なコードを生成する可能性が高くなります。 異なるチーム間、あるいは異なる組織間でデータを共有することによって生じるセキュリティ リスク。  1 つのエージェントが不均衡な量のコンピューティング リソースを占有すると、パフォーマンスのボトルネックが発生します。 この種のプラットフォームを構築するという課題は、DevOps の課題であると同時に AI の課題でもあります。 将来を見据えて: データに特化した管理されたAIエージェントを採用 企業が業務で管理する AI アプリケーションが増えるにつれて、専門的で適切に管理されたアプローチが必要になります。エージェント メッシュ フレームワークは、データ分析で AI を拡張する手段として、専門の AI データ エージェントを使用します。このアプローチにより、セキュリティ、信頼性、パフォーマンスが維持されます。  AI は今ごろどこにでも存在し、ほとんどのデータに関する質問に答えているだろうと予想していたかもしれません。しかし、よく見ると、ChatGPT がリリースされてからわずか 2 年で進歩が目覚ましいことがわかります。この道のりで学ぶべきことはまだまだたくさんあります。しかし、私の考えでは、エージェントとエージェント メッシュ フレームワークがエンタープライズ AI の鍵となるでしょう。

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This post provides insights into new product. 

このオーディオは、ストーリーの元の言語で制作されています。

テキストから SQL への変換は AI のキラーアプリになるはずでした。しかし、そうではありません。

About Author

コメント

ラベル

この記事は

Related Stories

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユニークなエコシステムを支えるビットコインUTXOのモデル

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

Telegram: クリプト島と本土を結ぶ橋

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユニークなエコシステムを支えるビットコインUTXOのモデル

海を航海する: データレイクを使用した本番環境レベルの RAG アプリケーションの開発

Telegram: クリプト島と本土を結ぶ橋

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps

テキストから SQL への変換は AI のキラー アプリになるはずでした。しかし、そうではありません。

About Author

コメント

ラベル

この記事は

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps

テキストから SQL への変換は AI のキラーアプリになるはずでした。しかし、そうではありません。