CPN、LLM、および分散アプリケーション

LLM 対応のソフトウェア開発における大きなテーマは、検証可能な正しさにより、LLM でより大きな飛躍を遂げやすくなるということです。例: テスト、コンパイラ、ステート マシンなど。データビルドについて調べているときに、最近見つけたものです。 着色されたペトリネット、そしてすぐにチャンスを見つけました。

カラーペトリネット (CPN) はペトリネットの拡張です。ペトリ ネットは本質的に有向二部グラフであり、場所にトークンを含めることができ、場所は遷移 (副作用が発生する場所) によって接続されます。ペトリ ネットでは、単一のトークンにはデータが含まれず、ネット内の ID のないトークンの位置を表します。重要なのは、グローバルに入力と出力が 1 つだけ、トークンが 1 つだけある遷移を持つペトリ ネットは、有限状態マシンと同等であるということです。色付きのペトリ ネットはこのモデルを拡張し、個々のトークンにデータを関連付けることができます。これにより、CPN が Rustタイプステートパターン、そしてRustがCPNセマンティクスを簡単に実装できるかもしれないことを示唆しています。

CPN が特に興味深いのは、a) 同時実行アプリケーションを作成するのがまだ難しいこと、b) ビルド時に同時実行プログラムを正式に検証できる可能性があるためです。また、その下に高性能データストアを実装できれば、CPN フレームワークは、状態の同期、競合検出、デッドロックの回避、共有リソースへのアクセスの調整など、同時実行アプリケーションの難しい部分を処理できる可能性があります。これらは、CPN の他の 2 つの機能、ガードとマルチトークンの消費/生成によって有効になります。

ガードは、遷移に適用される可能性のあるブール条件のリストです。つまり、トークンがその遷移を行うためには true でなければなりません。たとえば、接続を要求するには、接続プール内に 0 個以上の接続が使用可能である必要があります。マルチトークンの消費/生成とは、文字通りの意味です。P1 -> T1 -> (P2, P3) という遷移を介したネットワークのフォークです。したがって、T1 が P1 からのトークンを消費すると、P2 と P3 のそれぞれで同時にトークンが生成されます。逆に、(P1, P2) -> T1 -> P3 という遷移を介してネットワークに参加するには、P1 と P2 の両方に、T1 を介して P3 に遷移できるトークンが存在する必要があり、これも同時に行われます。

軽い同時実行性が関係するアプリケーションの 1 つは、リースされたプロキシとスクレイピング ターゲットを使用した Web スクレイピングです。リクエストのプロキシに使用できるプロキシの数は限られているため、特定のターゲットを過剰にリクエストしないように、すべてのプロキシの使用量をレート制限する必要があります。また、責任あるユーザーになるためには、同じターゲットを同時に複数回リクエストすることを避け、ドメインへのリクエストを頻繁に行いすぎることも避けたいと考えています。従来、この問題は、中央データベースを介したリソースのリースによって解決され、 select for update データベース内のスタイル セマンティクス。 CPN セマンティクスを使用してこれを実装すると、次のようになります。 scrape_target トランジションは、 available_proxies そして prioritized_targets スクレイピングは、プロキシが利用可能で、優先ターゲットが利用可能な場合にのみ開始されます。 CPN セマンティクスを使用して他の複雑な分散スクレーパー機能を実装することも想像できます。

• ターゲットのクールダウンを削り取る: スクレイピングされた後、ターゲット トークンは に移行します。 cool_down この状態では、時間指定されたペトリ ネットを使用することで、元の状態に戻るのを遅らせることができます。 prioritized_targets 遅延期間の後。
• ドメインレベルのレート制限: 別途追加 domains トークンなので、 scrape_target 移行は 3 方向結合です domains x available_proxies x prioritized_targets。
• バックオフを使用して再試行します: 失敗したスクレイピングはフォークします: 1 つのトークンは failed_log に、もう 1 つは priorityd_targets に戻り、再試行回数が増加し、クールダウンが長くなります。 Guard は、最大試行回数を超える再試行を防ぎます。
• 結果パイプライン — スクレイピング後、トークンは raw_html → 解析 → 検証 → 保存という流れで、それぞれに独自の同時実行制限があり、自然にバック プレッシャーが実装されます。

もう 1 つのアプリケーションはデータビルドです。この場合、ネットワークはパーティション (ジョブの実行に事実上リースされます)、ウォンツ、およびジョブの実行で構成されます。データのデプスを伝播し、ユーザーが指定したパーティションのウォンツを安全、効率的、高速な方法で解決するための自己組織化された動的プロセスの恩恵を受けることができます。しかし、その男については後で詳しく説明します。

この部分についてはまだ検討中ですが、CPN を実装するための賢明な、または興味深い戦略がいくつかあるようです。

1. 従来のアプリ + postgres の組み合わせとして、トランザクションは同時のトークン移動と状態ストレージを実装します。 select for update 二重移動を防ぐために、トランジション用のトークンの要求を有効にします。
2. 単一プロセスの Rust バイナリとして、すべての CPN 状態がメモリに保存され、移動セマンティクスと typestate パターンで CPN セマンティクスを実装できるようになります (これは非常に高速になる可能性がありますが、永続性を理解する必要があります – スナップショットされたイベント ログでしょうか?)

私が理解しようとしているのは、パーティションの問題を解決する方法です。アプリの状態が 1 台のサーバーのメモリを超えて大きくなった場合、ネットワーク/トークンを自動的に分割して、大胆な同時実行性と水平スケーラビリティを可能にする方法はありますか?これまでのところ、答えは、a) ネットワークの一部であるアーカイブ場所/移行を使用してアプリケーションで解決するか、b) これをデータベースレベルで解決するかのいずれかであるようです。それとも、ネットワーク全体が複数の CPN アプリで構成され、それ自体がクエリ/消費インターフェイスを公開する、さらにクレイジーな状況でしょうか?

まとめると、賢明な永続性を備えた CPN アプリ フレームワークを見つけ出すことができれば、エージェントが作成したコードにコンパイル時の制約をさらに課すことができ (開発速度に有利)、制約のない計算アプリでは提供されない正確性の保証とシミュレーション機能をすぐに提供できるようになります。エキサイティング！

---

ランダムな考え

• !!これを検証するためにテスト スイートを使用したり、ベンチマークを実行したりできる既存のオープン ソース サービスはありますか?特に、それに対してクロード コードをオフにするだけの場合はどうでしょうか?
• 時間指定ペトリネット – デフォルトでメトリクスを出力し、システム全体への変更の最終的な影響をシミュレートできますか?
• 結合遷移はデータベース内のリテラル結合として、遷移条件はインデックスを暗示し、トークン遷移はトランザクション内の挿入および削除として行われます。
• データストアや CPN データベースを作成するということについて、どの程度のことを言っているのでしょうか?
• CPN アプリの分散ネットワーク?それとも CPN サービスの分散ネットワークとしてのアプリですか?それはすべてパーティション分割に関するものですか？
• CPN には明示的な再入場は必要ないのでしょうか?すべての「ステップ」はトークンの移動ですが、これは関係するすべてのトークンの状態から完全に実行可能ですか?

潜在的なベット (LLM 作成)

これを検証するには、CPN セマンティクスを使用して何かを再実装し、比較するという実際の坂を登る必要があります。核心的な問題は、「CPN は高速/正確であるかどうか」ではありません。もちろん、高速/正確であることは可能です。その： このパラダイムにより、シンプルで正確かつ高速な同時プログラムの作成が容易になりますか? 形式主義はバグを減らし、オーダーメイドの調整コードを少なくすることで報われますか?

賭け: スクレーパー スケジューラ (spider-rs)

CPN を使用して、スクレイパーの意思決定コア (URL の優先順位付け、ドメイン レート制限、プロキシの割り当て、再試行のスケジュール設定) を実装します。 HTTP 層をモックします。 1 秒あたりのベンチマーク決定を行い、調整コードの複雑さを元の値と比較します。

なぜスクレーパーなのか？従来の実装には、レート制限マップ、クールダウン トラッカー、再試行カウンタ、ドメイン キューなど、アドホックな調整が満載です。これはまさに CPN が形式化したものです。正確さが重要であり（礼儀違反は禁止されます）、時間制限付きの移行が重要であり、付随的なものではありません。 Spider-RS はすでに Rust なので、フォークして直接比較できます。

なぜ他の人が最初ではないのでしょうか？

オプション	なぜだめですか
ジョブキュー (要素)	調整は付随的なものです。 CPN オーバーヘッドが報われない可能性があるよく理解されたパターン
接続プーラー (pgcat)	小さすぎる – 説得力のある十分な CPN 機能を発揮できない可能性がある
CI ランナー (Buildkite)	大きすぎる – 偶発的な複雑さ (アーティファクト、ログ、シェルの実行) により、調整のストーリーが曖昧になります

実装アプローチ

SQLite スナップショットを備えたインメモリ Rust: シングルスレッド、移動セマンティクスが適用され、非常に高速です。パーティショニング = 切り離されたトークン所有権を持つ個別のバイナリ (パーティション キー要件によりネット定義時に強制可能)。シミュレーション = モック効果を使用した同じ CPN の実行。正確性テスト、障害挿入、時間の早送りが可能になります。