AI株式ウォッチリストリサーチエージェント

何を重要な更新とみなすか定義する

ウォッチリストエージェントは、最後にレビューしたリサーチパケットから何が変わったかに答えるべきです。新しい提出書類、訂正された開示、決算説明会、未解決のリサーチ質問に影響する証拠など、重要なイベントを定義します。各発行体のリサーチ質問とソースカバレッジを識別子とともに保存します。これによりモデルには範囲を限定したジョブが、レビュアーには更新を受け取る理由が与えられます。タイマーが発火しただけで無制限の企業分析をスケジュールしないでください。入力に変化がなければ、通常は別の長いレポートではなく変化なしの状態を出すべきです。

収集とリサーチ生成を分ける

まずソースフィードまたは許可されたポーリングでメタデータを集め、その後に新しい資料がモデル作業に値するか判断します。SEC開発者リソースには米国提出者の収集を支えるフィードとインデックスが説明されています。他市場には独自の権威あるソースが必要です。公開時刻、取得時刻、ソースリビジョンを独立に保存します。変化したWebページのラッパーを新しい企業開示と取り違えないでください。関連する文書またはイベントからコンテンツ識別情報を作り、ソースエラーは何も変わらないという判定から分けて保持します。

一つの世界時計ではなく市場とソースでスケジュールする

各証券に取引所のタイムゾーンと休日カレンダーを付けます。情報の可用性には開示タイムスタンプを、レビュアーが要約を求める時刻には別のスケジュールを使います。発行体は取引時間外に公開することがあり、複数市場に上場することもあります。すべてのイベントを一つの暦日に移して順序を失わないでください。定期ジョブでは意図した時間帯と実際の実行時刻を記録します。実行を逃した場合は、区間を黙って飛ばしたり履歴全体を再生したりせず、最後に完了した収集ウォーターマークから再開します。

ジョブと通知の状態を明示する

小さな状態機械によって、定期作業は運用しやすくなります。変化なし、新しい証拠、ソース利用不可、リサーチ保留、レビュー必要を区別します。以下の記録はアプリケーション設計であり、スケジューラー製品の設定ではありません。安定したイベントキーとソースマニフェストハッシュを保持し、同じジョブのリトライで重複作業や重複通知が生成されないようにします。イベント完了とマークする前に成果物を永続化します。通知配信には独自の確認状態を持たせ、レポート生成の成功から推測しないでください。

{
  "issuer_id": "REQUIRED",
  "event_key": "REQUIRED_STABLE_KEY",
  "source_manifest_hash": "REQUIRED",
  "collection_status": "pending",
  "research_status": "not_started",
  "review_status": "pending",
  "notification_status": "not_sent"
}

現在と以前のパケットから変更メモを生成する

新しいソース、以前にレビューしたメモ、未解決の質問をモデルに渡します。ソース位置と、どの以前の記述を更新する必要があるかの明確な説明を含む短い変更ログを求めます。元のメモは上書きせず、リビジョンとして保持します。新しい開示は解釈を強めたり弱めたり、変えなかったりします。すべてのイベントを株価の方向シグナルにしないでください。以前のパケットがない場合は、過去の比較を捏造せず初回リサーチ状態を作ります。

定期予算とリトライポリシーに上限を設ける

スケジュールする前に、発行体、ソース量、モデル試行、実時間作業について実行ごとの上限を設定します。計画には現在のモデル契約を使い、イベントとジョブごとの実際の使用量を保持します。ソースのリトライとモデルのリトライを分け、一時的な提出書類停止で古いデータの分析が繰り返されないようにします。文書とパーサーのバージョンで抽出をキャッシュします。予算を使い切ったら新しい作業の生成を止め、キュー済みイベントを保持し、未解決状態を表に出します。不要なレビュー負荷を減らすため、通知頻度を収集頻度から分けます。

小さな運用ミニフローを実行する

定期配信を有効にする前に、変化のない文書、新しいリビジョン、一時的に利用できないソース、リトライされた通知をテストします。安定したイベント識別情報、正しいリサーチ状態、同じ完了イベントに対して意図した通知が1件だけになることを確認します。その後、元の証拠に対して完全な変更メモを一つ検査します。収集とリサーチのツールは読み取り専用にし、外部メッセージ送信先には明示的な承認を使います。リサーチ承認は注文承認ではありません。放置実行されるからといって、ウォッチリストワークフローにブローカー権限を与えないでください。

証拠と限界

このガイドは、公式の提出書類リソースとソースレビュー済みリサーチアプリケーションから得たワークフロー設計です。このページのために定期ウォッチリストジョブ、通知配信、測定済み使用量ケースは実行していません。定期ワークフローが運用可能だと主張する前に、展開記録には実際のスケジューラー、ソースカバレッジ、モデル、永続化されたイベント状態、通知テストを特定する必要があります。

よくある質問