8:39 - 10:21

より速く予測しやすい検索のためのコンテキストグラフ

この章の要点

大きな組織でエージェントに仕事をさせるとき、必要な情報を見つけること自体が難しくなります。サービスのコードだけでなく、依存関係、担当チーム、関連する文書、過去の障害なども確認しなければならないからです。

この章では、Uberがそれらの関係を一つの**コンテキストグラフ（context graph）**につないでいる、という説明を扱います。グラフは情報を一か所にコピーして置く箱ではありません。情報どうしのつながりを使って、仕事に関係する情報の入口を短くする仕組みです。

何をつなぐのか

話では、サービスの場所、依存関係、所有者、設計上のパターン、コード、データ、文書、作業項目、インシデント（障害や事故）などを、同じグラフの中で結び付けると説明されています。発表者によると、グラフにはノードとエッジを合わせて150種類あり、登録された項目は4,000万件です。

ここでいうノードは、サービスや文書のような対象です。エッジは、「このサービスはこのチームが所有する」「このコードはこのデータを使う」のような関係です。単に検索語と文書を対応させるだけでは、こうした関係を十分に表せません。

この仕組みの中心的な価値は、保存場所の大きさではなく関係です。あるサービスを起点にすれば、そのサービスに関係する担当者、依存先、コード、設計資料などへたどれます。つまり、エージェントは大きなリポジトリや文書群を最初から全部読むのではなく、関係を手掛かりに調査の範囲を絞れます。

図：サービスを中心に、組織とエンジニアリングの対象が型付きの関係でつながっています。

この図は、サービスの周りに異なる種類の対象があることを示しています。したがって、検索は「似た文章を探す」だけではありません。サービスから依存先や所有者などへ関係をたどる、関係を意識した検索になります。図で示された内容を確認するには、YouTubeの9分18秒付近を見ることができます。

グラフは正しい情報そのものではない

コンテキストグラフは、情報の関係を見つけるための案内図です。グラフが、コード、データ、文書、作業項目の中身をすべて置き換えるわけではありません。

例：知らないサービスを変更する

大きなモノレポ（多くのプロジェクトを一つのリポジトリで管理する方式）の中に、初めて触るサービスがあるとします。エージェントがそのサービスを変更する場合、まず次のような調査が必要になります。

そのサービスのコードはどこにあるか。
どのサービスやデータに依存しているか。
どのチームが所有しているか。
どの設計文書や過去のインシデントが関係するか。

グラフがこれらの関係を保っていれば、エージェントは調査の入口を早く見つけられます。これは、関係が発見を短くするという教師側の例です。しかし、グラフに書かれた所有者や依存関係が、その時点で正しいとは限りません。エージェントは、見つかった関係を手掛かりにして、権威のある元のコードや文書を確認する必要があります。

データの意味とSQLを結ぶ

話では、グラフを使って自然言語の質問からSQL（データベースを検索するための言語）を作る例も示されます。質問は、「インドのモビリティーの移動のうち、現金で支払われたものはいくつか」です。

この質問に答えるには、単語をデータベースの列名に置き換えるだけでは足りません。「モビリティーの移動」がどのデータに対応するのか、「インド」がどの地域項目に対応するのか、「現金」が支払い方法のどの値に対応するのかを知る必要があります。

グラフが、業務上の概念とデータの構造の関係を持っていれば、自然言語の意図から技術的なデータ構造へ橋をかけられます。これは、グラフが答えを直接保存しているという意味ではありません。グラフが関連するデータの場所や意味を案内し、その元のデータを使ってSQLを組み立てる、という流れです。

グラフあり・なしの比較をどう読むか

発表のスライドでは、同じ質問をグラフの支援あり・なしで処理した場合が比較されています。グラフを使わない場合は、エージェントが複数の検索経路を試しながら、必要なデータの意味や場所を推測することがあります。グラフを使う場合は、関係を利用して候補を早く絞れます。

発表者は、グラフを使ったケースで、トークン数、やり取りの回数、遅延が改善したと報告しています。スライドの比較では、グラフを使うほうが速度やコスト、ツール呼び出しの数で有利になる様子が示されています。

図：同じ検索について、グラフ支援の有無で速度、コスト、ツール呼び出しなどを比べています。

この図は、一つのクエリについての比較を具体化したものです。「グラフを使えば、どの仕事でも必ず同じ改善が出る」という意味ではありません。検索対象、データの整備状態、質問の難しさによって結果は変わります。数字は、比較されたケースの範囲を保ったまま読む必要があります。該当する比較は、YouTubeの10分09秒付近で確認できます。

新しく生まれる責任：情報の新しさ

関係を利用して検索を速くできる一方で、グラフの**鮮度（freshness）**を保つ責任が生まれます。サービスの担当チームが変わったり、依存関係が更新されたり、文書が古くなったりするからです。

古いグラフは、検索を速くしても誤った方向へエージェントを導く可能性があります。そのため、グラフを作って終わりにはできません。元のシステムで起きた変更を反映し、どの情報を信頼できるかを確認し続ける必要があります。これは、この章で明示された「鮮度が新しいプラットフォーム責任になる」という点からの説明です。

まとめ

コンテキストグラフは、サービス、コード、データ、文書、担当者、作業、インシデントを関係で結び、エージェントの調査範囲を絞ります。発表では、150種類のノードとエッジ、4,000万件の項目、そしてグラフ支援によるトークン数・やり取り・遅延の改善が報告されています。

ただし、グラフは権威のある情報源の代わりではありません。グラフは情報を見つける地図であり、最終確認は元のコードやデータ、文書で行います。また、関係が最新であることを保つ運用も必要です。速い検索の価値は、関係を使って必要な情報へ早く到達し、その後に信頼できる情報源で確かめられるときに生まれます。