ソートリーダー

AI時代にすべての企業がナレッジグラフを必要とする理由

mm
Unite.AI を Google の優先ソースに追加

AIはソフトウェア開発を根本的に加速させましたが、ソフトウェア組織が運営される方法はほとんど変わりません。その不一致は、企業のAIの最大の制限要因になりつつあります。

これまで、エンジニアリングチームは需要に追いつくために更多のリソースを必要としました。今日、小さなチームはAIを使用してコードを生成し、テストを実行し、アイデアから実装までのパスを加速させます。開発者は明らかにコードをより迅速に配信していますが、それが常により良い結果につながるかは不明です。

この速度は新しいボトルネックを作り出しています:調整コスト。AIは、組織が作業を調整する方法を改善するよりも、実行を加速させました。コンテキストの共有、優先順位の付け、運用上の意思決定、ステータスの報告、および機能間の調整は、開発が速くなるにつれても、ほとんど手動で行われているままです。

アトラシアンは、結果として生じる断絶がフォーチュン500社に年間約161億ドルかかることを推定しています。この調査では、89%の幹部がAIが作業を加速させたと述べていますが、6%のみが組織全体の計測可能な成果を示すことができます。

出力の高速化は自動的に賢い組織を作り出すわけではありません。 17%のユーザーだけが、エージェントがチーム内でのコラボレーションを改善したと同意しています、これは最も低い評価の影響です。調整ループは断絶したままです。

毎回の問い合わせでコンテキストを再構築することは巨大なコストです

デモでは、クリーンでキュレーションされたデータソースを使用しますが、実稼働環境では、曖昧で古くなった情報や、断絶したシステムに散在する矛盾した情報が問題になります。ギャップに直面したとき、言語モデルは、次に最も可能性の高い答えを予測します。制御されたデモでは推論のように見えましたが、実際の生産データでは、自信を持って推測することになります。

業界は、この問題に名前を付け始めています。 「コンテキストエンジニアリング」は、エンタープライズAIが成功するかどうかを決定する情報、関係、ガバナンス、品質を設計することに焦点を当てた分野として登場しています。制限要因は、モデル自体ではなく、モデルを取り巻くコンテキストの品質であることがよくあります。

AIシステムが毎回コンテキストを再構築するたびに、コストを支払います。応答は遅く、トークンコストが増加し、組織の知識を取得する順序によって回答が異なるため、信頼性が低下します。2つのAIエージェントは、同じ質問に異なる回答を返すことがあります。各エージェントは、組織の知識の異なるスライスからコンテキストを組み立てるためです。

ほとんどの組織は、すでにAIシステムが必要とする知識を所有しています。問題は、この知識がチケット、リポジトリ、ドキュメント、会話、計画ツールに断片化されていることです。したがって、モデルが推論を開始する前に、毎回のやり取りで組織のコンテキストを再構築する必要があります。

アクセスは知識と同じではありません

よく聞かれる質問は、より大きなコンテキストウィンドウ、より優れた検索、または改善された取得がこの問題を解決するかどうかです。

モデルコンテキストプロトコルは、エージェントがエンタープライズ情報が存在するシステムにアクセスするための標準化された方法を提供することで、実際の統合問題に対処します。ただし、アクセスは理解と同じではありません。エージェントに12のシステムへのアクセスを許可しても、どの決定が他の決定を上書きしたか、どの要件が変更されたか、どのドキュメントがまだ権威あるか、またはどの顧客会話が最終的に何を出荷したかを説明することはできません。構造化された検証されたロジック層がなければ、これは単に矛盾した詳細に遭遇する12の機会を提供するだけです。

ほとんどのエンタープライズAIシステムは、コンテキストを毎回問い合わせるたびに組み立てる必要があるとまだ仮定しています。これにより、分離された質問には答えることができますが、ビジネスを運営するために必要な継続的な推論をサポートするのに苦労します。幹部はまだ、組織内にすでにあるはずの質問の答えを組み立てるために毎週何時間も費やしています:

  • 何が変わったのですか?
  • この優先順位はなぜ変化したのですか?
  • ロードマップはまだ正確ですか?
  • 私たちはまだ正しい問題を解決していますか?

これがナレッジグラフがその地位を占める場所です。グラフは、 エンティティとその関係を格納し、組織の記憶を保存する基盤を提供します。ソフトウェア組織では、これらのエンティティは、顧客、機能、要件、決定、チケット、リポジトリ、プルリクエスト、リリース、人々などを含む可能性があります。

エージェントは、単に類似の単語を含むパッセージのコレクションを取得するのではなく、決定から要件へのつながり、チケットへの実装、プルリクエストへの変更、顧客のフィードバックへの挑戦へとつながる関係をたどることができます。

ナレッジグラフは、単にデータを整理する別の方法に過ぎないのではなく、断絶したシステムからコンテキストを再構築するのではなく、組織が実際にどのように機能するかについて、継続的に進化する理解から推論するAIを可能にします。

結果として、AIは、決定、会話、証拠から推論するのではなく、毎回のプロンプトで理解を再構築するのではなく、推論することができます。

構造だけでは十分ではありません

グラフを一度構築するのは難しいですが、正確性を維持するのはさらに困難です。急速に変化する組織では、チケットは変更され、計画は変更され、コードは出荷され、責任は移動し、顧客のフィードバックは優先順位を変更します。つまり、組織の記憶は、現実が変化するにつれて更新され、各変更をその根源に再リンクする必要があります。

82%の開発者は、AIがコードをより迅速に記述するのを助け、71%の開発者は、AIが複雑な問題に取り組む能力を向上させると報告していますが、この速度には、 96%の開発者が、生成されたコードが機能的に正しいという完全な信頼性を欠いているという落とし穴があります。

エージェントが提供するすべての事実は、その根源に遡る必要があります。コミット、チケット、スレッドなどです。如果AIシステムがリーダーにリリースが予定通りに進んでいることを伝えるが、その結論の背後にあるシグナルを示すことができない場合、経験豊富なリーダーはその情報に基づいて行動することをためらうべきです。

私は、ユーザーが回答の根拠を確認できないツールを放棄したチームを見てきました。また、ユーザーがその仕事を見せるツールを使用し続けるチームも見てきました。要約が信頼性のない回答よりも速くあっても、信頼性のない回答は信頼性のない回答です。各主張をその根拠に結び付けることで、「信頼してください」というのは「ここが理由です」ということになります。

正確性は同じ理由で重要です。システムが計画と実際の関係を継続的に追跡すると、チームが決定したことと実際に何が配信されたかとのギャップは、見える漂流ではなく、自信のあるが古くなった回答に静かに吸収されるのではなく、見える漂流になります。これは、周辺的な懸念ではありません。 Thoughtworksは、 コードの漂流を、AIエージェントの特定の危険として旗示しています。検証ループとフィードバックメカニズムの必要性を強調しています。システムが作業の進化に伴う偏差を検出して修正するのを支援するメカニズムです。見える漂流は、有用な情報です。見えない漂流は、AIシステムが信頼を得た人々を欺く方法です。

次のエージェントプロジェクトの前に尋ねるべきこと

エンタープライズエージェントイニシアチブを評価する場合、4つの質問から始めます:

  • システムは、既存のデータソースへのアクセスを提供するのではなく、時間の経過とともに最適化されたコンテキストの表現を維持していますか?
  • 各回答は、チケットまたはドキュメントなどの特定のソースに遡ることができますか?
  • システムは、組織の情報が変更されるにつれて自動的に更新されますか?
  • エージェントは、データポイントへのアクセスのみではなく、関係を理解していますか?

基盤モデルは、改善を続けます。推論能力は強化され、コンテキストウィンドウは拡大し、これらの進歩は誰でも利用できるようになります。しかし、組織の理解は、コモディティ化されることはありません。

CEOの過半数は、 過去1年間にAIからほとんど、またはまったく収益やコストの利益を得ていないと報告しています。私は、ほとんどの場合、モデルがすでに組織が知っていることを推論できるコンテキストレイヤーが欠けていると考えます。

ソフトウェアが劇的に簡単に作成されるにつれて、理解が希少なリソースになります。AIから最も価値を生み出す人は、組織の知識を保存し、接続し、継続的に学ぶのが上手です。それが、推測するAIと知っているAIの違いです。

クリス・ビーは、Devplanの共同創設者兼CEOです。彼は、Amazon、Uber、Zillow、Lessenを含む大規模な製品およびエンジニアリングチームを率いてきた20年以上の経験を持っています。また、AIがソフトウェア開発ライフサイクルとそれを運用するチームに与える影響について頻繁に議論しています。シアトルに住んでいます。