1772106520
2026-02-26 21:30:00
1 日の平均トークン使用量が 1 日あたり 80 億である場合、大規模な問題が発生します。これは AT&T の場合に当てはまり、最高データ責任者の Andy Markus と彼のチームは、すべてを大規模な推論モデルで推し進めるのは単純に実現不可能 (または経済的) ではないことを認識していました。そこで、社内の Ask AT&T パーソナル アシスタントを構築する際に、オーケストレーション層を再構築しました。結果: LangChain 上に構築されたマルチエージェント スタックでは、大規模な言語モデルの「スーパー エージェント」が、より簡潔で目的主導の作業を実行する、より小規模で基盤となる「ワーカー」エージェントを指示します。この柔軟なオーケストレーション層により、レイテンシ、速度、応答時間が大幅に改善されたとマーカス氏は VentureBeat に語った。最も注目に値するのは、彼のチームが最大 90% のコスト削減を達成したことです。 「エージェント AI の将来は、非常に多くの小さな言語モデル (SLM) になると信じています」と彼は言いました。 「小規模な言語モデルは、特定のドメイン領域においては、大規模な言語モデルと同等ではないにしても、ほぼ同じくらい正確であることがわかりました。」
ごく最近、Markus 氏と彼のチームは、この再設計されたスタックを Microsoft Azure と併用して、従業員がタスクを自動化するためのグラフィカルなドラッグ アンド ドロップ エージェント ビルダーである Ask AT&T Workflows を構築および展開しました。
エージェントは、文書処理、自然言語から SQL への変換、および画像分析を処理する一連の独自の AT&T ツールを利用します。 「ワークフローが実行されるとき、決定を実際に左右するのは AT&T のデータです」とマーカス氏は言います。一般的な質問をするのではなく、「私たちはデータに疑問を持ち、意思決定を行う際にデータが私たちの情報に焦点を当てていることを確認するためにデータを活用しています。」それでも、人間はエージェントの「連鎖反応」を常に監視しています。すべてのエージェントのアクションがログに記録され、プロセス全体でデータが分離され、エージェントが相互にワークロードを渡すときにロールベースのアクセスが強制されます。 「物事は自律的に行われますが、ループ上の人間は依然としてプロセス全体のチェックとバランスを提供します」とマーカス氏は言います。
過度に構築せず、「交換可能で選択可能な」モデルを使用する
AT&T は「すべてをゼロから構築する」という考え方を採用していない、と Markus 氏は述べています。それは、「交換可能かつ選択可能」かつ「商品を再構築しない」モデルに依存しているのです。業界全体で機能が成熟するにつれ、既製のオプションの代わりに自社製ツールが廃止されるだろうと同氏は説明した。 「なぜなら、この分野では毎週、状況が変化するからです。運が良ければ、週に複数回変化することもあります」と彼は言いました。 「さまざまなコンポーネントを試行し、接続したり取り外したりできる必要があります。」彼らは、利用可能なオプションと自分自身のオプションを「非常に厳密に」評価します。たとえば、リレーショナル ナレッジ グラフを使用してデータに聞く機能は、Spider 2.0 のテキストから SQL への精度リーダーボードでトップとなり、他のツールは BERT SQL ベンチマークで高いスコアを獲得しています。自社開発のエージェント ツールの場合、彼のチームはコア フレームワークとして LangChain を使用し、標準の検索拡張生成 (RAG) やその他の社内アルゴリズムでモデルを微調整し、マイクロソフトと緊密に提携して、ベクター ストアにテクノロジー大手の検索機能を使用しています。しかし最終的には、目的のためにエージェント AI やその他の高度なツールをすべてに融合させるだけではないことが重要だとマーカス氏はアドバイスしました。 「私たちは時々、物事を複雑にしすぎてしまうことがあります」と彼は言いました。 「時々、過剰に設計されたソリューションを目にすることがあります。」代わりに、ビルダーは、特定のツールが実際にエージェントである必要があるかどうかを自問する必要があります。これには、次のような質問が含まれる可能性があります。より単純な 1 ターンの生成ソリューションであれば、どの程度の精度レベルを達成できるでしょうか?マーカス氏の言葉を借りれば、どのようにしてそれをより小さな部分に分割し、各部分を「より正確に」提供できるでしょうか?精度、コスト、ツールの応答性が基本原則である必要があります。 「解決策がより複雑になったとしても、これら 3 つのかなり基本的な原則は依然として私たちに多くの方向性を与えてくれます。」と彼は言いました。
10万人の従業員が実際にどのように使用しているか
Ask AT&T Workflows は 100,000 人以上の従業員に展開されています。マーカス氏によると、半数以上が毎日使用していると回答しており、積極的に導入している人は生産性が90％も向上したと報告しているという。 「私たちは、彼らがシステムを繰り返し使用しているかどうかを調べています。なぜなら、粘り強さは成功の良い指標だからです」と彼は言いました。エージェント ビルダーは、従業員に「2 つの旅」を提供します。 1 つはプロコードで、ユーザーが舞台裏で Python をプログラムして、エージェントがどのように機能するかに関するルールを指示できます。もう 1 つはノーコードで、「非常に軽快なユーザー エクスペリエンス」を実現するドラッグ アンド ドロップのビジュアル インターフェイスを備えています。興味深いことに、熟練したユーザーでさえ後者のオプションに惹かれています。技術者向けの最近のハッカソンでは、参加者には両方の選択肢が与えられ、半数以上がローコードを選択しました。 「この人たちは皆、プログラミングの面で非常に有能だったので、これは私たちにとって驚きでした」とマーカス氏は語った。従業員はさまざまな職務にわたってエージェントを使用しています。たとえば、ネットワーク エンジニアは、アラートに対処し、顧客が接続を失ったときに再接続するために一連のサービスを構築する場合があります。このシナリオでは、1 人のエージェントがテレメトリを関連付けてネットワークの問題とその場所を特定し、変更ログを取得して既知の問題を確認できます。その後、トラブル チケットを開くことができます。その後、別のエージェントが問題を解決する方法を考え出し、パッチを適用するための新しいコードを作成することもできます。問題が解決されると、第 3 のエージェントが将来の予防策を含む概要を作成できます。 「 [human] エンジニアはすべてを監視し、エージェントが期待どおりに機能し、適切なアクションを実行していることを確認します」とマーカス氏は言いました。
AI を活用したコーディングが未来です
同じエンジニアリングの規律、つまり作業をより小さな目的に特化した部分に分割することは、現在、マーカスが「AI を活用したコーディング」と呼ぶものを通じて、AT&T 自体のコードの書き方を再構築しています。彼はそのプロセスを RAG と比較しました。開発者は、統合開発環境 (IDE) でアジャイル コーディング手法を使用し、コードの相互作用方法を決定する「機能固有の」ビルド アーキタイプを使用します。出力はルーズコードではありません。コードは「製品グレードに非常に近い」ものであり、1 回でその品質に達する可能性があります。 「私たちは皆、エージェントのようなコード エディターを使用して、バイブ コーディングに取り組んできました」と Markus 氏は述べています。しかし、AI を活用したコーディングでは、「雰囲気コーディングでよく見られる、行ったり来たりの繰り返しの多くが排除されます」。同氏は、このコーディング手法がソフトウェア開発サイクルを「明確に再定義」し、最終的に開発タイムラインを短縮し、実稼働グレードのコードの出力を増加させるものであると考えています。技術者以外のチームも、平易な言語プロンプトを使用してソフトウェア プロトタイプを構築することで、アクションに参加できます。たとえば、彼のチームはこのテクニックを使用して、社内で厳選されたデータ製品を 20 分で構築しました。 AI がなければ、構築には 6 週間かかったでしょう。 「私たちはそれを使ってソフトウェアを開発し、それを使ってソフトウェアを修正し、それを使ってデータサイエンスを行い、それを使ってデータ分析を行い、それを使ってデータエンジニアリングを行っています」とマーカス氏は言いました。 「つまり、これはゲームチェンジャーなのです。」
#日あたり #億のトークンによりATT #は #オーケストレーションの再考を余儀なくされコストが #削減されました