Model or dataset
ZhuLinsen/alphasift avatar
ZhuLinsen/alphasift

AlphaSift: A Three-Layer Stock Screening Engine With an Audit Trail

AI-native stock screening engine with full-market discovery, LLM ranking, risk-aware scoring, and auditable evaluation. AI选股

360 stars209 forksPythonApache-2.0

At a glance

What is it?
AlphaSift scans a broad A-share universe, applies YAML strategy filters, and optionally adds LLM ranking, then saves each run so it can be scored against later market data. The design bet is auditability over raw signal quality, and the README is honest about the fact that its output is only as good as the data and configuration behind it.
Who is it for?
Adopt AlphaSift if you want a Python screening pipeline where every run is saved and can be evaluated against later snapshots, and if you are comfortable reading YAML strategies and wiring your own market data source. Do not adopt it if you need a validated trading signal, a backtested return series, or a system that works without an external data provider and API keys.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 74 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap AlphaSift is trying to fill

Most stock screeners return a list and stop. You get today's picks, and tomorrow you have no record of what the engine saw, which filters fired, or whether the picks would have worked. AlphaSift treats the run itself as the artifact. The README describes an engine that scans a broad market universe, applies auditable YAML strategies, enriches candidates with optional market context, ranks them, and saves runs for later T+N evaluation. The intended user is someone building an experimental screening workflow in Python, not someone looking for a finished trading product. The disclaimer is explicit: the project is for learning, research, and engineering experiments, and outputs depend on third-party market data, optional LLM providers, local configuration, and strategy parameters. The example runs in the README use A-share close data, which tells you the default universe is Chinese equities, though the architecture does not appear to hard-code that beyond the data provider.

How the three layers actually connect

The pipeline is split into L1, L2, and L3. L1 is deterministic: hard filters and factor scoring over the full market snapshot. In the README's dual_low example, 5190 stocks pass through hard filters and 337 survive, which means the filters are doing most of the narrowing before any scoring. L2 is optional LLM ranking, described as structured cross-candidate reasoning that produces theses, catalysts, risks, confidence, and portfolio risk buckets. L3 is pluggable post-analysis, with a local scorecard by default and optional DSA or external HTTP analyzers. The data flow is one-directional: snapshot in, filters, optional enrichment, ranking, then a saved run. The `--no-llm` flag removes L2 entirely, and `--no-post-analysis` removes L3, so you can run the deterministic core alone. That separation matters because it lets you compare a run with and without LLM ranking on the same snapshot. The `--context` flag injects a free-text market note into the LLM prompt, and `--candidate-context-file` adds per-candidate news, announcement, or fund-flow context from a CSV. Those are the two places where non-numeric information enters the ranking.

Getting a first run out of the CLI

Installation is editable mode from the repository root: `pip install -e .`. Configuration starts by copying `.env.example` to `.env`. LLM ranking needs one of `GEMINI_API_KEY`, `OPENAI_API_KEY`, or `DEEPSEEK_API_KEY`, or alternatively `LITELLM_MODEL`, `LLM_CHANNELS`, or `LITELLM_CONFIG`. The README also shows `alphasift --env-file /home/ubuntu/daily_ai_assistant/.env screen balanced_alpha`, which lets you point the tool at an environment file outside the project directory. To see what is available without spending an API call, `alphasift strategies` lists built-in strategies and `alphasift quickstart` runs a no-key demo. `alphasift overview --explain` shows strategy groups, source health, and recent runs. A deterministic screen is `alphasift screen dual_low --no-llm`. Adding `--save-run` persists the run, `alphasift runs --json` lists saved runs, and `alphasift report <run_id> --output data/reports/dual_low.md` generates a Markdown review. There is also a local read-only JSON API via `alphasift serve --host 127.0.0.1 --port 8765` for dashboards and agents, and `alphasift audit` checks project and strategy configuration. The Python API mirrors the CLI: `from alphasift import screen`, then `screen("dual_low", use_llm=False)`, with `evaluate_saved_run` and `evaluate_saved_runs` exported for the evaluation loop.

The evaluation loop is the part worth studying

Saving a run is only half of it. The README describes evaluating saved runs later using newer snapshots, deducting transaction cost, tagging follow-through and failed-breakout outcomes, reviewing failure samples, and optionally fetching price paths for maximum drawdown and maximum favorable excursion. That last part is the difference between a screener and a measurement instrument: without price paths you cannot tell whether a pick that closed up 3 percent spent the interim down 15 percent. The evaluation is T+N, meaning it is anchored to the run's timestamp and the snapshot available at that time, which is the right structure for avoiding lookahead bias. What the README does not give is a worked evaluation example with actual numbers, so you cannot see from the documentation alone what a typical follow-through rate looks like or how transaction cost is parameterized. That is a gap worth noting before you assume the evaluation output will be self-explanatory.

Hotspot discovery and its fallback metadata

Separate from screening, AlphaSift has a hotspot workflow. `alphasift hotspots --provider akshare --top 12 --output data/hotspots.json --history data/hotspot.history.jsonl --explain` discovers topics and writes cache and history sidecars. `alphasift hotspot "AI compute" --top-stocks 10 --timeline --fallback-cache data/hotspots.json --explain` resolves one topic into a detail payload. The cache format carries `schema_version` (currently 2), `generated_at`, `metadata` with provider, row count, source errors, and stale/fallback state, plus normalized `hotspots` rows. The design decision worth calling out is how fallbacks are surfaced. When live constituent APIs fail and cached leaders are used instead, the returned stocks carry `source="last_good_cache.leader_stocks"`, `source_confidence`, and `fallback_used=true`. The README states this is intentional, so downstream code can distinguish live data from cached data rather than silently mixing them. Hotspot details keep a raw `timeline` for auditability and a compact `route` list for applications, grouped by day, newest first, and trimmed for display. If no timeline evidence exists, `route` falls back to a short heat, stage, and leader summary. There is also an offline check, `alphasift hotspots --provider none --explain`, which is useful for confirming the pipeline runs without network access.

Where it breaks down

The most obvious limitation is that AlphaSift has no bundled market data. The README lists akshare as a provider for hotspots, but the screening examples depend on A-share close data without stating how that data is fetched or what happens when the provider is unavailable. The disclaimer says outputs can be delayed, incomplete, or wrong, which is the project telling you the data layer is your responsibility. The LLM layer adds a second dependency: if no provider key is configured, L2 is skipped, and the ranking you get is purely deterministic. That is a reasonable fallback, but it means two people running the same strategy can get different output depending on whether they have an API key. The scoring itself is not explained in the README beyond the fact that it is deterministic factor scoring in L1. There is no formula, no weight documentation, and no sensitivity analysis. For a tool that produces a numeric score like 72.7, that is a real gap: you can see the rank but not what drove it, unless `--explain` surfaces enough detail. Finally, the examples are from April 2026 using April 10, 2026 close data, and the README labels them as examples of engine output, not recommendations. They are a sanity check on the output format, not evidence that the strategy works.

How it differs from a plain screener

A conventional screener such as a simple pandas script over a CSV applies filters and prints rows. AlphaSift adds three things that script does not have: a persisted run record, an evaluation step that compares the run against later snapshots with transaction costs deducted, and a hotspot layer with explicit source-confidence metadata. The closest comparison in spirit is a backtesting framework like backtrader or vectorbt, but the approach is inverted. Those tools replay historical data to estimate how a strategy would have performed. AlphaSift runs forward on today's snapshot, saves the result, and evaluates it after the fact. That means it cannot tell you how a strategy performed over the last five years, only how it has performed since you started saving runs. The trade-off is that forward evaluation avoids the survivorship and lookahead problems that historical backtests often carry, at the cost of needing time to accumulate evidence. If you need a historical performance number today, AlphaSift is the wrong tool. If you want a disciplined record of what the engine actually picked and what happened next, it is built for exactly that.

Licence, maintenance, and what to check first

The licence is Apache-2.0, which permits commercial use, modification, and redistribution provided you include the licence and notice files and state significant changes. It also includes a patent grant. That is a permissive licence with no copyleft obligation on your own code, but if you redistribute AlphaSift or a modified version you need to carry the notices. This is not legal advice; check the full text if you plan to ship it. On maintenance, the repository shows a last push in July 2026 and no retrieved releases, so there is no tagged version to pin to. Installing with `pip install -e .` pulls the current main branch, which means an upgrade is a `git pull` and a reinstall, and any local changes to the code will conflict. The safer pattern is to fork or vendor the repository at a specific commit. Before adopting, run `alphasift audit` to check the project and strategy configuration, then run the quickstart and a saved run, and inspect the report output. The thing to verify first is whether the market data source works in your environment and whether the evaluation loop produces output you can interpret, because those two pieces are where the README is thinnest.

Editorial conclusion

Adopt AlphaSift if you want a Python screening pipeline where every run is saved and can be evaluated against later snapshots, and if you are comfortable reading YAML strategies and wiring your own market data source. Do not adopt it if you need a validated trading signal, a backtested return series, or a system that works without an external data provider and API keys. Before committing, run `alphasift audit`, then `alphasift quickstart`, then `alphasift screen dual_low --no-llm --save-run` and inspect the saved run and its report to confirm the data source, the filter counts, and the evaluation output match what you expect.

Official sources

  1. Issues
  2. License: Apache-2.0
  3. README
  4. ZhuLinsen/alphasift on GitHub
Community notes

Community notes