OrgForge: A Multi-Agent Simulation Framework for Verifiable Synthetic Corporate Corpora

OrgForge は、決定論的な Python エンジンがシミュレーションの真実を管理し、LLM がその制約に基づいて文章のみを生成するマルチエージェントフレームワークであり、一貫した時系列と検証可能な合成企業コーパスを生成することで RAG パイプラインの評価を可能にします。

要約

🏭 問題：なぜ「本物の会社」のデータではダメなの？

AI（特に RAG という技術）をテストする時、私たちは「AI が正しい答えを見つけられるか」を知りたいですよね。
でも、現実の会社（例えば過去のメールデータ）を使うには大きな問題があります。

1. 秘密が多い： 実際のメールはプライバシーや法律の問題で使えません。
2. 正解がわからない： 「このメールの正解はこれだ！」と証明する「答えの鍵」が元々ありません。
3. 嘘つきなデータ： 最近、AI に「架空の会社」を作らせてデータを作ろうと試みましたが、AI は**「自分自身で矛盾した嘘をついてしまう」**ことがありました。
   • 例： 「朝 3 時にサーバーが止まった」と Slack に書いておきながら、別の JIRA（作業管理ツール）のチケットでは「朝 9 時に始まった」と書いてある。
   • これでは、AI のテストになりません。「偶然、間違った答えを正解だと思い込んでしまう」からです。

🛠️ 解決策：OrgForge（オーグフォージ）とは？

OrgForge は、**「事実を管理する厳格な監督役（エンジン）」と「文章を書く天才（AI）」**を完全に分けたシステムです。

🎭 例え話：映画の撮影現場

このシステムは、**「脚本家と監督が分離した映画撮影」**のようなものです。

• 監督（Python エンジン）：
  • 「事件は何時に起きたか」「誰が関与したか」「誰がストレスを感じているか」といった**「事実（フィジクス）」**をすべて厳密に管理します。
  • 監督は「朝 3 時にサーバーが止まった」と決定すれば、それは絶対的な事実です。
• 脚本家・俳優（LLM/AI）：
  • 監督が決めた「事実」だけを受け取り、「では、エンジニア A はどう言い訳するかな？」「チャットではどんな口調で書くかな？」という**「文章（プロース）」**だけを書きます。
  • 脚本家は「朝 9 時に止まった」と勝手に書き換えることは許されません。監督の「事実リスト」に反する台詞は即座に却下されます。

この仕組みのおかげで、**「矛盾のない、完璧に整合性の取れた架空の会社」**が作れるのです。

🧩 仕組みの 3 つの魔法

このシステムには、現実の会社のように「人間関係」や「時間」をシミュレートする 3 つの魔法があります。

1. ストレスの伝染（ストレス・プロパゲーション）：
   • 重要な人物（キーパーソン）が忙しくなると、そのストレスが近しい同僚に「伝染」します。
   • 例え： 部長がパニックになると、その直属の部下が「あーあ、大変だ」と言いながら作業が遅くなる。これを数値で計算して、誰がいつ疲れるかをシミュレーションします。
2. 人間関係の距離（エッジの減衰）：
   • 一緒に働かないと、人間関係は冷えていきます（距離が広がる）。逆に、一緒にトラブルを解決すると、関係は深まります。
   • 例え： 毎日チャットで雑談している同僚とは仲良しですが、半年連絡していない部署の人は「見知らぬ人」扱いになります。
3. エスカレーション（責任の押し付け合い）：
   • 問題が起きた時、誰に報告するかは「最短経路」で決まります。
   • 例え： 一番近い上司に報告し、解決できなければその上の上司へ。これを「地図上の最短ルート」のように計算して、誰がいつ介入したかを正確に記録します。

⏰ 時間の魔法：「誰の時計もズレない」

これまでの AI 生成データでは、チャットとメールの「時間」がバラバラで、**「未来のメールが過去のチャットより先に届く」**というバグが起きることがありました。

OrgForge では、**「一人ひとりが持っている独立した時計」**を使います。

• A さんがチャットを書いている間、B さんは別の作業をしています。
• しかし、誰かが「これに返信する」と言うと、「返信する人の時計」が「元のメッセージの時間」より必ず先になるように調整されます。
• これにより、「タイムトラベル」のような矛盾が一切起きません。

📊 何ができるの？（テストの仕組み）

このシステムで作られたデータを使って、AI に以下の質問を投げかけます。

• 事実確認： 「サーバーが止まった最初の報告はどのチャット？」
• 因果関係： 「このチケットが作られた原因は何？」
• 時間推理： 「その日、A さんはこの文書を読めていた？」
• 欠落発見： 「顧客からの苦情メールに、誰も反応しなかった？」（あえて反応しないメールも作ります）

そして、AI の答えが「監督（エンジン）が持っている正解リスト」と一致するかを厳しくチェックします。

🏁 まとめ：なぜこれが重要なの？

OrgForge は、**「AI がビジネスの文書を理解できるか」をテストするための、世界で最も公平で、矛盾のない「練習用シミュレーター」**です。

• 現実のデータは秘密が多く、正解がわからない。
• 普通の AI 生成データは、自分自身で矛盾した嘘をつく。
• OrgForgeは、監督が事実を管理し、AI が文章を書くことで、**「矛盾ゼロ、正解あり」**の完璧なテストデータを作ります。

これにより、企業が「この AI 導入して大丈夫かな？」と判断する前に、**「この AI は、複雑な会社の出来事を正しく理解できるか」**を、安全に、そして正確にテストできるようになります。

まるで、**「飛行機が墜落する前に、風洞実験で空気の抵抗を完璧にシミュレートする」**ようなものですね。OrgForge は、AI という「飛行機」を安全に飛ばすための、究極の練習用空域なのです。

技術概要

OrgForge: 検証可能な合成企業コーパスの技術的概要

Jeffrey Flynt 氏による論文「OrgForge: Verifiable Synthetic Corporate Corpora」は、検索拡張生成（RAG）システムの評価において、現実的な企業環境の複雑さを反映しつつ、厳密な正解（Ground Truth）が保証された合成データセットを生成するためのフレームワーク「OrgForge」を提案するものです。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 背景と問題定義

RAG システムの評価には、以下の 4 つの特性を持つコーパスが必要ですが、既存のリソースはこれらを同時に満たしていません。

1. 追跡可能な正解（Traceable Ground Truth）: 各事実の権威あるソースが存在し、評価が可能であること。
2. 時間的構造（Temporal Structure）: 事実が時間とともに変化し、時間的推論が可能であること。
3. クロスアーティファクトの整合性（Cross-Artifact Coherence）: 同一の事実が Slack、JIRA、メールなど複数のドキュメントタイプで一貫して現れること。
4. 構成可能な複雑さ（Configurable Complexity）: 組織規模やインシデントの深刻度などを調整可能であること。

既存の課題:

• Enron コーパスなどの実データ: 法的な曖昧さ、デモグラフィックな偏り、構造化された正解の欠如、単一の病理的な組織文脈に限定されるなどの問題がある。
• LLM による完全合成データ: 生成モデルが事実を自己矛盾させる（ハルシネーション）リスクがあり、異なるドキュメント間でタイムラインや事実が矛盾する可能性がある。これにより、RAG 評価の信頼性が損なわれる。

2. 手法とシステムアーキテクチャ

OrgForge は、「事実の制御」と「文章の生成」を厳密に分離する多エージェントシミュレーションフレームワークです。

2.1 形式的定義: $M = (S, P, V, E)$

シミュレーションは以下の 4 つの要素で構成されます。

• $S$ (State): 可変なシミュレーション変数（システム健全性、チームの士気、アクティブなインシデント、エンジニアのストレス値など）を表す Pydantic モデル。
• $P$ (Planners): 状態 $S$ とイベント履歴を観察し、その日の活動計画を構造化された JSON 提案として生成する LLM ベースのエージェント。
• $V$ (Validator): 提案されたイベントを決定論的に検証し、実行前に承認または拒否する関数。LLM のハルシネーションを防ぐための重要な境界層です。
• $E$ (Events): すべての重要なアクションを記録する「SimEvent」ログ（不変の正解バス）。LLM はここからコンテキストを取得しますが、直接書き込みは行いません。

2.2 主要なメカニズム

1. 決定論的なグラフダイナミクス:

   • ストレス伝播: 媒介中心性（Betweenness Centrality）に基づき、キープレイヤーのストレスが周囲に伝播するモデル（式 3）。
   • 時間的エッジ重みの減衰と強化: 相互作用の有無に基づき、人間関係の強さが毎日更新される（式 4）。
   • Dijkstra によるエスカレーション経路: インシデントの報告経路を、関係性の強さに反比例するコストを持つグラフ上の最短経路問題としてモデル化し、決定論的に経路を決定する（式 7）。

2. 提案 - 検証ループ:
   LLM が生成した提案（例：「エンジニア A が JIRA チケットを作成する」）は、Validator によって以下のチェックを経て承認されます。

   • アクターの整合性（存在する人物か）。
   • 状態の妥当性（システム障害時に祝賀会を開かない等）。
   • 冷却期間（イベントの頻度制限）。
   • 士気のゲート（士気が低い時のみ介入提案を許可）。

3. 因果的タイムスタンプの一貫性:
   各アーティファクトに対して独立にランダムな時刻を割り当てるのではなく、**「アクターローカルクロック（sim clock.py）」**を採用します。これにより、インシデントの発生から Slack 通知、JIRA 作成、PR 合併までの因果関係が保たれ、タイムラインの矛盾が排除されます。

4. 外部メールエンジンと因果チェーン:
   ベンダーアラートや顧客クレームなどの外部イベントをシミュレーションに統合し、内部の因果チェーン（Causal Chain）に追跡可能な形で接続します。また、確率的にメールが「ドロップ（無視）」されるシミュレーションを行い、RAG システムが「証拠の欠如」を検出できるかを評価するためのテストケースを提供します。

5. 評価パイプライン:

   • 8 種類の質問カテゴリ: 検索、因果関係、時間的推論、ギャップ検出、ルーティング、計画、エスカレーション、知識ギャップ。
   • 自動採点: 正解の導出は SimEvent ログから決定論的に行われ、LLM は質問文の生成のみに使用されます。
   • ベースライン評価: BM25 と Dense Retrieval（Stella 1.5B）の両方に対して MRR@10 や Recall@10 を自動計算します。

3. 主要な貢献

1. 事実制御と文章生成の分離アーキテクチャ: LLM のハルシネーションが合成コーパスの正解を汚染することを防ぐ設計。
2. 決定論的な組織行動モデル: 決定論的なグラフダイナミクス（ストレス、関係性、エスカレーション）による組織挙動の制御。
3. クロスアーティファクト追跡可能性: 単一のインシデントが Slack、JIRA、Confluence、Git、メール、ログなど複数の形式にまたがり、一貫した因果チェーンとして記録される。
4. 因果的タイムスタンプの保証: 独立した時刻サンプリングに起因するタイムライン矛盾を排除する「アクターローカルクロック」の実装。
5. 現実的なノイズの導入: 本題とは関係ない雑談（Watercooler）や、処理されなかったメール（ドロップ）など、現実の企業コミュニケーションに見られる「容量ノイズ」をシミュレーションに組み込み、評価の盲点を解消。
6. オープンソースの実装と評価パイプライン: 構成可能な設定、再現性のあるコーパス生成、HuggingFace 形式でのエクスポート機能の提供。

4. 実験結果

22 営業日（約 30 日）、43 名の従業員、8 つの部署をシミュレートしたコーパス（1,079 ドキュメント、83 問）を用いた評価結果は以下の通りです。

• 計算コスト: 約 3 時間の実行時間、LLM 呼び出し 953 回、総コスト約 285 ドル。
• 検索ベースラインの比較:
  • BM25: 全体的に Dense 検索より優れており、特に「CAUSAL（因果関係）」質問で MRR@10 が 0.54 と高い性能を示しました。これは、事後検証（Postmortem）ドキュメントに含まれる特定の用語とキーワードの一致が効果的だったためです。
  • Dense Retrieval (Stella 1.5B): 全体として BM25 よりも低い性能（MRR@10 0.20 vs 0.28）でした。特に「TEMPORAL（時間的）」や「ESCALATION（エスカレーション）」の質問では両手法とも 0 点でした。
  • 特筆すべき点: 「RETRIEVAL（検索）」質問においてのみ、Dense 検索が BM25 をわずかに上回りました（0.39 vs 0.35）。これは大規模で多様なコーパスにおいて、意味的類似性がキーワード一致よりも優れている可能性を示唆しています。
  • 課題: 「PLAN（計画）」と「ESCALATION（エスカレーション）」の質問では、両手法とも 0 点でした。これは、計画文書がテンプレート化されており自然言語の質問と一致しにくいこと、およびエスカレーション経路の推論が単純なキーワードや埋め込みだけでは困難であることを示しています。

5. 意義と結論

OrgForge は、RAG 評価の分野において以下の点で重要な意義を持ちます。

• 信頼性の高いベンチマークの提供: 実データの問題点（法的リスク、正解の欠如）と、既存合成データの問題点（事実の矛盾）を両方解決し、厳密に検証可能な評価基盤を提供します。
• 時間的・因果的推論の評価: 単なる事実検索だけでなく、時間経過に伴う状態変化や、複数のドキュメントにまたがる因果関係の追跡を評価できる点で画期的です。
• 現実的な評価環境の構築: 「証拠の欠如（ドロップされたメール）」や「ノイズ（雑談）」を含めることで、実世界での RAG システムの挙動をより正確にシミュレートできます。
• 将来の研究方向: 本フレームワークは、マルチ組織間のシミュレーションや、歴史的行政文書の合成など、さらに広範な応用が可能であることを示唆しています。

結論として、OrgForge は、組織的に現実的で、正解が注釈付けられた合成コーパスに基づく、新しいクラスの RAG 評価ベンチマークの基盤となるものです。