コンテンツにスキップ

仕組み

パイプライン全体図

公開ニュースソース(RSS、Yahoo Finance、...)
        │ 20 分ごとの共有インジェスト(Celery Beat)
┌─────────────────────────────────────────────────────────┐
│  ユーザー別ファンアウト                                   │
│                                                          │
│   各アクティブユーザーについて:                           │
│     1. そのユーザーのウォッチリストのエイリアスに対し     │
│        raw item をフィルタ(安価なローカルキーワード照合)│
│     2. 通過した各 item に対し合成エンジンが 5 つの        │
│        エージェントを並列実行                             │
│     3. 集計 + Reflexion でトップシグナルを生成            │
│     4. Signal 行を永続化(Postgres、RLS スコープ)        │
│     5. ユーザーの ChromaDB コレクションへ埋め込み         │
│        *(計画中 — `embedding_worker` は 2026-04-22 時点  │
│        でスタブ。Claw チャットは現在 BM25 のみで取得)*  │
│     6. Redis チャネル signals:<user_id> に発行            │
│     7. FLASH + ALERT を Telegram に配信(連携済みの場合) │
│     8. FLASH + ALERT を Web Push に配信(購読済みの場合) │
└─────────────────────────────────────────────────────────┘
あなたのダッシュボード(WebSocket 経由リアルタイム)、スマホ、デスクトップ。

キーアイデア

共有インジェスト、ユーザー別合成

公開ニュースのスクレイピングはグローバルに 1 度だけ行います——そうしないと NVDA をウォッチしている 10 人のユーザーそれぞれが Yahoo を 10 回叩くことになってしまいます。一方で LLM 負荷の高い合成ステップは (user, news-item) ペアごとに 1 度実行されるので、スコアリングとティッカーインパクトは「あなたの」ウォッチリストの文脈を反映した、画一的ではないスコアになります。

1 つの巨大プロンプトではなく 5 つの専門エージェント

「このニュースは重要か、なぜか」を 1 つの大きなプロンプトに聞くのではなく、5 つの小さく絞り込んだエージェントを並列実行します——それぞれに独自のレーン(ティッカーレベルの事実、マクロコンテキスト、セクターダイナミクス、リテールセンチメント、規制)があります。各出力を加重平均して最終シグナルにまとめます。エージェント を参照。

信頼度の低いドラフトに対する Reflexion

集計スコアがボーダーラインのときは、エンジンが Reflexion パスを実行します:ドラフトを批判して書き直す 2 回目の LLM 呼び出しです。各シグナルの エージェント内訳 パネルでどの程度の頻度で発動しているか確認できます。

データベース層のロウレベルセキュリティ

ユーザー所有のすべてのテーブル(signalswatchlistsuser_settingsrag_query_logs、...)には PostgreSQL の RLS ポリシーが設定されています:user_id = current_setting('app.current_user')。FastAPI セッションは Postgres ロール authenticated で動作し——スーパーユーザーではなく——RLS がアクティブに強制されます。クロスユーザーのデータ漏洩はアプリケーションコードではなく Postgres 自身によってブロックされます。

次へ