企業全体のナレッジグラフを構築してエージェントの作業を劇的にスピードアップする

Building full-firm knowledge graphs to dramatically speed up agents

エージェントに企業全体のナレッジグラフを与えて複雑な質問をさせたところ、以下のような精度を保ちつつ、

73%

回答時間短縮

92%

入力トークン読み込み量削減

66%

モデル呼び出し回数削減

で回答しました。

グラフの構築には、モデルトークンはほとんどかかりませんでした。一般的なドラフティングルールは、LLMマッピングが必要な場合のみ補強され、既存のままマターレコードを読み取ります。

シミュレーションされた企業のグラフを、レイヤーごとにアニメーション化したもの：マターやドキュメントから条項、法律、ノウハウ、クライアント、担当者、やり取り、締め切り、資金まで。

グラフは、企業の担当事項やドキュメントから個々の条項まで、そしてクライアント、それに依存する法律、ノウハウ、メール、締め切り、時間記録まで網羅しています。

実際にグラフを構築するにはどうすればよいか？

企業の知識の多くは人々の頭の中にあり、それをグラフに入力する時間を確保することは稀です。一部は、やり取りやドキュメント間のリンクから暗黙的に捉えることができます。残りのどれだけが手の届く範囲にあるかは、企業が既に記録しているデータがそれをエンコードしているかどうかに依存します。例えば、法律事務所の担当事項では、相手方が誰で、どのドキュメントが彼らのものかは既に正確にわかっています。

私たちは4つのレベルで考えます。第一に、知識はデータの構造化の方法に暗黙的に含まれているか？第二に、ルールで抽出できるか？第三に、ルールではできない接続（意味的なものを含む）を言語モデルがどこで追加できるか？第四に、それらの接続のうちどれが最も価値があり、どのようにすれば安価にできるか、そしてどのような一般的なグラフの形状が最適か？すべての回答はドメインに依存し、それぞれに実験が必要です。

グラフのほとんどは既に存在する

企業のシステムには、既にグラフの大部分が含まれています。プラクティスマネジメントシステムは、各担当事項のクライアント、相手方、パートナー、チームを把握しています。会社登録簿は各会社の親会社を提供し、時間記録は誰が何をしたか、請求されたかどうかを示します。これらを一つの場所にロードすることで、これらの結合が明示的かつ解析可能になります。スパース検索ではMeridian Grid ServicesがHalcyon Groupに属していることはすぐにはわかりませんが、ネットワーク検索ではわかります。ドキュメントは、これらのマーカーの基盤となる詳細を提供します。

まずルール、次に不足分をモデルで

ルールは安価で高速、予測可能であり、なぜ何かを見つけたかを正確に説明できますが、書かれていないものを見逃します。モデルはあらゆるものを読み取れますが、文ごとにコストがかかり、時にはでっち上げをします。

そのため、まずルールが適用されます。文が、解析できない月や金額のない責任制限など、ルールが読み取れなかった事実の兆候を示した場合、その文のみが小さなモデルに送られます。モデルにはグラフのフィールドのみを尋ねられ、その回答は保存されるため、再構築では新しいテキストのみに費用がかかります。

私たち自身のドラフティングの助けなしにこれをテストするために、別のモデルに245のドキュメントすべてと、日付を示す5つの提出済みメールを、6つの異なるドラフティングスタイルで書き直させました。その後、4つの方法でグラフを構築し、毎回スコアリングしました。

モデルにフラグ付けされた141文（部屋の文の2%未満）を送信したところ、コストは5セント未満で、判断と上限の質問は100%に達しました。すべての文を読み取ったモデルは27倍のコストがかかりましたが、全体としてはそれほど良くありませんでした。すべての締め切りを見つけましたが、サービスクレジットを月額料金の15%として責任上限と誤認し、私たちのドラフティングではルールが見つけた4つの締め切りを見逃しました。

ハイブリッドアプローチの見落としには明確な原因があります。2つの締め切りは、スキャンされたPDF形式の裁判所命令にあり、行の区切りによって「午後4時まで」が短い番号付き行の末尾に残っていました。ルールはその行を見出しと見なしたため、その下の日のコンテキストがなくなり、単なる日付はギャップとしてカウントされませんでした。

構築にかかったコスト

グラフは2種類のソースから構築できます。最初のタイプはプレーンなJSONファイルです：クライアント、担当事項、フィーアーナーのレジスタで、各ドキュメントはテキスト形式です。JSONはプラットフォームに依存しないため、どの企業でもCRM、プラクティスマネジメントシステム、またはドキュメントストアからエクスポートすることで生成できます。テストした企業もこの方法で提供されました。2番目のタイプはLexifinaのような担当事項中心のプラットフォームで、人々が作業する際に同じ事実をキャプチャします：担当事項レコード、アップロードされたドキュメント、担当事項に提出されたメール、および財務レジャー。エクスポートする必要はありませんが、ドキュメントがアップロードされる際に一部の読み取りが発生します。フローチャートにはそれぞれタブがあります。

JSONエクスポート616ファイル、1.8 MB。CRMまたはプラクティスマネジメントシステムはそれらをエクスポートできます：ドキュメントインデックス、担当事項レコード、ドキュメント、メール、時間記録、レジスタ、ノウハウ、法律ライブラリ

レジスタ、一度ロード

フィーアーナー0.2 ms · 0 トークン

• 20 フィーアーナー

会社登録簿とクライアント2.7 ms · 0 トークン

• 113 会社

• 16 親子関係リンク

法律ライブラリ1.9 ms · 0 トークン

• 18 権威

• 4 フォロー、適用、無視、考慮リンク

ノウハウ2.1 ms · 0 トークン

• 4 ノウハウ項目

• 1 ケースへのリンク

• 別の先例への1つのリンク

120件の担当事項それぞれについて

担当事項レコード5.0 ms · 0 トークン

• 6つの実務分野における120件の担当事項

• 12 人物

• 120 クライアントリンク

• 126 相手方リンク

• 281 パートナーおよびチームリンク

ドキュメント983 ms · 0 トークン

• 245 ドキュメント

• 3,654 条項（スケジュール段落を含む）

• 288 パーティリンク（各ロール付き）

• 431 定義語

• 条項から権威への183リンク

• 条項から先例への7リンク

• 89 締め切り、期限切れ、イベント

• 37 責任上限（上限対象者と基準付き）

• 1 修正契約（同じ担当事項で一致）

メール378 ms · 0 トークン

• 1,459 メール

• 5 日付付き締め切り

時間記録56 ms · 0 トークン

• 120 レコード

• 記録された時間へのフィーアーナーからの281リンク

置き換え0.2 ms · 0 トークン

• 1 置き換えリンク（変更契約により長期停止日が移動）

企業グラフ6,333ノード、7,563エッジ、7層。約1.6秒で構築（ラップトップ上）、モデル呼び出し0回、トークン0回。ルールが読み取れなかった159文をフラグ付けしましたが、このビルドではそれらは除外されました。

ページレイアウト30 ms · 0 トークン

• 2,211 ドロー可能ノードと3,441 ドロー可能エッジ。各サーバープロセスでキャッシュ済み。

データルームのエクスポートからのビルド。ウォームランでレコーダーが記録した各ステップ。時間はディスクに依存します。再起動後の最初のビルドで、遅いマウントを読み取るのに数秒かかり、そのほとんどがファイルの待機でした。どのステップも言語モデルを呼び出さないため、各コストは0トークンです。

グラフあり・なしの5つの質問

グラフがエージェントを助けるかどうかを確認するために、同じモデルに同じ5つの質問をグラフありとなしで尋ねました。エージェントはデータルームのすべてのファイルをリスト、検索、読み取ることができました。KGを使用すると、7つのグラフツール（検索、ノードを開く、競合チェック、依存関係の追跡、締め切り検索、条項事実の比較、時間と請求額の合計）も呼び出すことができました。

実際の実行例を並べて表示

エージェントがクエリしたナレッジグラフを見る

［画像: テスト企業のナレッジグラフを7つの積み重ねられた平面で表示：時間と資金、日付と締め切り、やり取り、クライアントと担当者、担当事項とドキュメント、企業知識、法律］

これらの実行でエージェントがクエリしたグラフ。製品自身のレンダラーによって描画されています：7層にわたる2,200ノードと3,371エッジ。条項、定義語、上限はドキュメント内にあり、描画されていません。

各セルは、グラフなしの場合の平均、次にグラフありの場合の平均を示しています。モデルの定価では、平均的な実行コストはグラフなしで約17セント、グラフありで約2セントでした。ルールによるギャップを補うモデルのパスは5セントで、最初の質問で元が取れます。グラフへの全アップロード読み込みも考慮すると、約26の質問で元が取れます。

グラフなしでも、エージェントはほぼすべての回答を正しく得ました。賢く検索し、会社登録簿を読み、引用をたどり、レジャーを合計しましたが、それには約4倍の時間と約13倍のトークンを読み込む必要がありました。精度の唯一のギャップは請求に関する質問でした。グラフなしのエージェントは、数十の時間記録を手作業で合計する必要があり、ある実行ではしきい値をわずかに超える未請求時間を持つクライアントを見逃しました。

これが示していないこと

書き直されたルームのテストは、ドラフティングスタイルをテストしており、実際のデータルームが持つすべてのものをテストしているわけではありません。この実験では、モデルは言葉遣いを書き換えましたが、すべての事実を保持しており、そのドキュメントはOCRエラー、テーブル、または変更履歴のあるスキャンではなく、クリーンなテキストです。敵対的な乱雑なテキストは、グラフなしのエージェントがさらに多くを見逃す原因にもなるため、実際の記録での精度のギャップは測定したものよりも大きい可能性がありますが、私たちはそれをテストしていません。

それだけの価値はあるか？

ナレッジグラフは一度きりのコストではありません。新しく変更されたドキュメントはすべて再度読み取る必要があり、その文の一部はモデルに送られるため、トークンコストは企業が働き続ける限り続きます。ソフトウェアにはロジスティクスコストがかかります：グラフが読み取る各システムのアダプター、維持するルール、レコードが変更されるたびに再構築するストアとキャッシュ。各再構築にはコンピューティング時間が必要であり、グラフと保存されたモデルの回答にはストレージが必要です。

そのため、私たちが問い続けているのは、それだけの価値があるかどうかです。取得結果の並列比較は、上記のようなものでも、各アプローチの短期および長期の実行コストと比較されるまで、ほとんど意味をなしません。グラフを新しいパラダイムとして扱うのではなく、2つのより単純な質問がより役立つことがわかりました。エージェントは、企業が既に持っている構造化データを最大限に活用するにはどうすればよいか？そして、作成または言語モデルと結合するのに安価で有用な構造はどれくらい残っているか？

このルームで約3.10ドルの条項メタデータは、担当事項中心のプラットフォームでのモデル支出の大部分を占めます。グラフはそれを読み取りません。したがって、問題は、それが読むべきか、そして条項メタデータがグラフのために計算する価値があるかどうかです。Lexifinaの条項メタデータステップを、変更せずに両方のバージョンのルームで実行しました。フィールドをグラフのフィールドにマッピングしました：参照は引用されたケース、法律、ノウハウになり、有効日とトリガーおよび期限条件の日付は日付になり、その種類は条項タイプと条件から判断されます。次に、メタデータのみからグラフを構築し、ルールにメタデータを追加したものから構築しました。

それ自体では、条項メタデータはグラフにとって貧弱なソースです。責任上限の金額フィールドがないため、10件の上限のうち none を見つけました。両方のバージョンのルームで13件の締め切りのうち7件を見つけましたが、その日付は有効日と条件であり、締め切りではなく、メールでは実行されません。ルールに追加すると、ギャップに対するモデルパスと同程度でした。書き直されたルームでは、ギャップパスも検出した審判の締め切りと、ギャップパスが見逃した2つのスキャンされた裁判所命令のうち1つを回復しましたが、ギャップパスが回復した2つの上限のうちどちらも回復しませんでした。コストは5セントに対して3.15ドルでした。

したがって、グラフのために条項メタデータを計算しないでしょう。レビューと検索のために既に計算されている場合は、それをマージしても追加コストはかからず、ギャップパスが見逃した1つの締め切りを捉えました。しかし、その締め切りに対するより良い修正は、コンテキストのない単なる日付もモデルに送信されるように、より広いフラグ付けルールです。

波及効果

グラフは、何かが変更されたときに最も役立ちます。もし控訴院が以前の決定から逸脱した場合、企業はその以前の決定に依存する現在のドキュメントがどれであるかを知る必要があります。依存関係はめったに直接的ではありません。条項は以前のケースを引用しているかもしれませんし、それをフォローまたは適用する後のケースを引用しているかもしれませんし、あるいは企業の独自の通知先例に従うと述べているかもしれません。そして、その先例のドラフティングノートがそのケースに依存しています。これらのエッジを依存関係としてマークし、ケースから逆方向に歩きます：それをフォローするケース、それを引用するノウハウ、それをフォローする条項、それらの条項、それらのドキュメント、それらの担当事項、および責任を持つパートナーまで。

以前のケースから逸脱した判決の場合、歩行は以前のケースからも始まります。なぜなら、それは企業の仕事が構築された法律だからです。

Lexifinaには引用チェッカーがないため、ドキュメントがどのケースを引用しているかはわかりますが、どの後のケースがどれをフォローまたは逸脱しているかはわかりません。それらのリンクがないと、新しい判決の質問は14件中10件の担当事項を見つけます。

元の主張LocalLLaMAで