Multi-factor Model Pipeline

model pipeline diagram

Job flow

1. Initialization

  1. Triggers AlphaStream job by GithHub action/workflow
    1. A script to send a request containing whatever call to AlphaStream for job creation will be called and can live in the AlphaStream repository.
  2. Ad-hoc request from Starline to Model Scheduler to create AlphaStream job
    1. POST /api/v1/model/job/ with an AlphaStream config that is to be defined
    2. HTTP request is sent to a FastAPI or Flask server running on AlphaStream or can be directly sent to AlphaStream for simplicity or sent through the scheduler for the sake of centralization.

      2. AlphaStream Job

  3. Insert new permissible factor lists (PFLs) into S3
  4. On completion, send Discord webhook, ping team role notifying job status and contain a link to preview/draft a finalized factor list (FFL).

    S3 (Factor List and pickle Storage)

    • Factor lists will be stored in S3, purged after FFL generated.

      3. Starline

  5. Analysts can visit links containing IDs pertaining to a job. GET /api/v1/models/drafts to view PFLs, ordered by time and paginated.
  6. FFLs can be submitted via PATCH /api/v1/models/drafts, sending the FFL to the scheduler or directly to StatPulse, this will also purge the original PFL from S3.

    4. StatPulse

  7. Starline will either send an HTTP request containing the FFL to the scheduler which will deposit it in S3 with its pair as it creates a StatPulse job, or Starline can handle all of this directly. StatPulse will run a FastAPI or Flask server and will receive a new job on POST /api/v1/job and will receive this data.
  8. Alternatively, for non-ad-hoc jobs, the scheduler will call StatPulse via a monthly CRON job using the same endpoint.
  9. StatPulse will create the models and deposit model pickle files in S3 and append this resource ID to the new model specs.
  10. These model specs will be inserted into PostgreSQL.
  11. Finally, StatPulse will send a callback to the scheduler to signal completion.

    PostgreSQL (Model DB)

  12. The model DB will be structured as follows with two options
    1. Either a table containing all models that will have TTLs and are then flushed
    2. These models will look as follows and either contain two tables, one containing the models and the other containing the prod models, or the prod models will be in their own view:
      1. Model table
        1. id: UUID ticker_timewindow
        2. Pickle identifier in S3
        3. tags: an array of strings, containing metadata such as job origin, team, and whether the job was ad-hoc
        4. Model spec, compressed into a string
      2. Prod table: whether model is a production model, this is determined by its R^2 compared to other models of the same type, the best R^2 is a prod model
        1. id: model ID ticker_timewindow
        2. Fkey referenching model spec
      3. This will be recomputed on each run to compare new models to current prod and swap as necessary

        5. Scheduler and Model Runner

  13. The scheduler will perform model runs for a specific model on a trigger factor change, this will then create a request to a model runner which will perform model computations and dump the resulting sector outlooks in ClickHouse.
  14. The alternative for this is ad-hoc model runs where this happens immediately. This behavior has already been defined and implemented in the model runner.

Backtesting

Backtester provides reusable historical evaluation and model-processing infrastructure.

Table of contents

This site uses Just the Docs, a documentation theme for Jekyll.